From sip-bounces@ietf.org Sat Jul 01 21:04:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwqLx-00036m-5p; Sat, 01 Jul 2006 21:02:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwqLv-00036h-C6 for sip@ietf.org; Sat, 01 Jul 2006 21:02:23 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwqLs-0003K8-Pb for sip@ietf.org; Sat, 01 Jul 2006 21:02:23 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 01 Jul 2006 18:02:21 -0700 X-IronPort-AV: i="4.06,198,1149490800"; d="scan'208"; a="302547112:sNHT35200208" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k6212Kjk025254; Sat, 1 Jul 2006 18:02:20 -0700 Received: from [192.168.1.2] (sjc-vpn1-318.cisco.com [10.21.97.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6212JIs006791; Sat, 1 Jul 2006 18:02:19 -0700 (PDT) In-Reply-To: <00e201c69bcb$555b9710$31713b51@BEMBUSTER> References: <00e201c69bcb$555b9710$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt Date: Sat, 1 Jul 2006 18:02:18 -0700 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=7360; t=1151802140; x=1152666140; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-outbound-04.txt=20; X=v=3Dcisco.com=3B=20h=3DKfG5sG+qcQx1b+Z4qbatP1E7ris=3D; b=q8mKoQyoDTto8Fj4mpnmMmtLZZbmCZHiBSxxIfZYDOZvByWWqIstHonpZfFj+p76Ky1QoZHO S04mcZkZIA4qZhanllKYSjhTV4scMLMX/EM9bt8Gorsjv5saaOdQK93W; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 29, 2006, at 3:28 PM, Jeroen van Bemmel wrote: > We've had some VERY long and extensive discussions on this > (starting with http://www1.ietf.org/mail-archive/web/sip/current/ > msg13677.html) but the draft is still not addressing some of the > issues that were raised > > 1) The UAC needs a positive indication that the selected proxy can > indeed handle STUN packets without choking on them. It is not > sufficient if the URI it is configured with says 'keepalive=stun', > that's a wish but no guarantee. > > Why is this a wish not a guarantee? I'm under the impression that devices that follow the RFCs should not have problems with this. I understand the argument that we might want DHCP or DNS to be a way to discover this configuration information but I think either of theses systems, not to mention the config-framework, can be used to get an URI. Keep in mind the thing that drove us to this approach - sig- comp. We need sig-comp to work too so however we deal with the approach for configuration of the URI so it has the sig-comp tag will also work for this. These options were discussed several times - at one point I was proposing a DNS scheme but I got the input that it could and should be separated. > > 2) Section 5.3: the Edge Proxy MUST Record-Route dialog forming > INVITE requests that it forwards over the flow towards the UA > (reverse direction is not strictly necessary, but probably common > too). If it does not do this, an ACK for 2xx cannot arrive. For > incoming SUBSCRIBE it might work without (the NOTIFY could create a > direct flow towards the target or some other proxy, using the local > socket as a Contact), but then there would be an issue with keeping > that flow alive (the STUN question). Probably safer to say that (in > addition to MUST for INVITE) "the Edge Proxy SHOULD Record-Route > all dialog-forming requests it forwards to the UA" This could be one way to solve the problem - others are possible too. I don't think this is in scope for outbound. I don't think outbound does anything that makes it so this solution (or some of the other proposed ones) can't be used. A long time ago, outbound got stuck in a huge rat hole of trying to define how every system should form it's high reliability and high availability solutions. That was too big a task to take on so I am happy to leave it out of scope as long as people can build good system. > > 3) The Proxy-Require mechanism we have discussed could be useful to > UACs that want to ensure that a selected edge proxy supports > outbound, aborting if not. > I'll let Rohan reply to this but I don't think I see what problem it solves. > 4) (minor remark) Perhaps some words could be added that the UAC > SHOULD perform keepalives when configured to do so, even if it > detects that there is no NAT. There could be a transparent firewall > device that needs to be kept open. > I agree this is the behavior we want - I thought it already more or less said that. It does not suggest detecting if their is a NAT there at all - if the URI has the tag, you do keep alive. > Regards, > > Jeroen I'm sorry my time is limited on this right now but I'm reading a ton of documents and posting comments so forgive me as I suffer from a response implosion problem. Cullen > > > > > > > ----- Original Message ----- From: > To: > Cc: > Sent: Wednesday, June 28, 2006 12:50 AM > Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Session Initiation Protocol >> Working Group of the IETF. >> >> Title : Managing Client Initiated Connections in the >> Session Initiation Protocol (SIP) >> Author(s) : C. Jennings, R. Mahy >> Filename : draft-ietf-sip-outbound-04.txt >> Pages : 34 >> Date : 2006-6-27 >> >> The Session Initiation Protocol (SIP) allows proxy servers to >> initiate TCP connections and send asynchronous UDP datagrams to >> User >> Agents in order to deliver requests. However, many practical >> considerations, such as the existence of firewalls and Network >> Address Translators (NATs), prevent servers from connecting to User >> Agents in this way. This specification defines behaviors for User >> Agents, registrars and proxy servers that allow requests to be >> delivered on existing connections established by the User >> Agent. It >> also defines keep alive behaviors needed to keep NAT bindings open >> and specifies the usage of multiple connections. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-04.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with >> the username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-sip-outbound-04.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-sip-outbound-04.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > > ---------------------------------------------------------------------- > ---------- > > >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 02 13:04:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx5LC-0005pj-AB; Sun, 02 Jul 2006 13:02:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx5LB-0005pe-8u for sip@ietf.org; Sun, 02 Jul 2006 13:02:37 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx5L9-0003gw-W0 for sip@ietf.org; Sun, 02 Jul 2006 13:02:37 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Jul 2006 10:02:35 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k62H2ZMG005501; Sun, 2 Jul 2006 10:02:35 -0700 Received: from [192.168.1.2] (sjc-vpn6-311.cisco.com [10.21.121.55]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k62H2YCU022308; Sun, 2 Jul 2006 10:02:34 -0700 (PDT) In-Reply-To: <017101c69c7f$72d773e0$a7c8000a@acmepacket.com> References: <017101c69c7f$72d773e0$a7c8000a@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <91641765-1056-4D33-9828-8090A246483C@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Sun, 2 Jul 2006 10:02:27 -0700 To: Hadriel Kaplan X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1380; t=1151859755; x=1152723755; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20rosenberg-sip-identity-coexistence; X=v=3Dcisco.com=3B=20h=3DXAcxMa/dOWmfDGIHnzGgkVPXgSQ=3D; b=plxO0zGGPFVRe545HfJVwxx9MDNaIq+ZcGTnfyYSGtzE5XIpfTzS106r6g7o7GrF1ImQIaZl VJ/7hx+dW3NXjIlku4FLBvJhvK4KUC/HbT6b/MrRWONHrYfDjMD2lhVd; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 30, 2006, at 12:57 PM, Hadriel Kaplan wrote: > >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> >> I think one of the major reason for creating PAI was to provide >> malicious call trace for anonymous calls. I don't think it was for >> dealing with spoofing the From header. If that was the goal, we could >> have solved it just by having device that ends up inserting the PAI >> just reject any request that has spoofed From headers. > > I agree with you, but it is used for detecting suspicious From > headers even > for non-anonymous calls. Obviously if the proxy inserting the PAI > _knows_ a >> From is spoofed, it could/should reject it. But if the proxy does >> _not_ > know whether the From is spoofed or not, it just doesn't insert the > PAI. > For example, ingress proxy receives a request from another domain - > if it > trusts the domain it passes the PAI (or inserts one). If it does > not trust > the domain, it removes PAI, but doesn't want to reject the request > (else it > wouldn't accept requests from such untrusted domains to begin with). I see your point, I can see how a proxy that is deciding not to remove a PAI might not know a From was spoofed. I don't see how a proxy that was going to *insert* a PAI would know what to put in the PAI and not be able to know if a PAI was spoofed. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 02 13:19:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx5Zx-0003WN-5O; Sun, 02 Jul 2006 13:17:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx5Zv-0003WF-HB for sip@ietf.org; Sun, 02 Jul 2006 13:17:51 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx5Zu-0003zX-W6 for sip@ietf.org; Sun, 02 Jul 2006 13:17:51 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 02 Jul 2006 10:17:51 -0700 X-IronPort-AV: i="4.06,199,1149490800"; d="scan'208"; a="302611582:sNHT34758452" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k62HHoYQ015570; Sun, 2 Jul 2006 10:17:50 -0700 Received: from [192.168.1.2] (sjc-vpn6-311.cisco.com [10.21.121.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k62HHncL021073; Sun, 2 Jul 2006 10:17:49 -0700 (PDT) In-Reply-To: <017c01c69c90$73269590$a7c8000a@acmepacket.com> References: <017c01c69c90$73269590$a7c8000a@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <48807FA4-2A3A-4EA6-99F5-96DDEFD6611E@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Sun, 2 Jul 2006 10:17:47 -0700 To: Hadriel Kaplan X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=6915; t=1151860670; x=1152724670; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20rosenberg-sip-identity-coexistence; X=v=3Dcisco.com=3B=20h=3DXAcxMa/dOWmfDGIHnzGgkVPXgSQ=3D; b=hSW2yjHhTmZOHqjSpz+IF+xB4fi1Uv8QIdVsgO/imP4zwWacoMArhRxinSQ5Mpvf4QzCQhJv tkcV72U4zLH7LOevabrhrfNrq9uNS9IDjRjzP29Yv2AEsqiVICcj4/rT; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 30, 2006, at 2:59 PM, Hadriel Kaplan wrote: > More inline... > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> >> case 2) ingress B2B on terminating domain - this is fairly easy too. >> This B2BUA resigns the incoming request. To do this it uses a cert >> that has a wildcard for all domain - the UAS need to be configured to >> have this cert in it root trust list. What the UAS is doing here is >> delegating that it trust any name that the >> B2BUA trusts. This is the sort of trust delegation one wants to be >> able to make. > > I don't know how practical that is to do on the UASs. It seems to > me like > most UASs simply trust whatever their proxy tells them, and that > should be > ok if we can guarantee what their proxy tells them is true. (a big IF) For UA that don't do Identity, I think what I proposed works with no changes to them. For UAs that do do Identity, they need to have a list or root certs they trust. It seems like when you are determining what the UA trusts you are setting up this list. Again, in this case I don't see what does not work about my proposal. > > If a b2bua before that proxy but in the same trust domain verified the > identity, and can somehow tell the proxy it verified the identity, > and even > tell the UAS it did as well, why do more? That's what the PAI > does. It may > not be what it was supposed to do, but it's what it seems to now. > So in the case of an anonymous call where the real caller identity is in the PAI for malicious call trace reasons, what are you proposing to do. Does the proxy strip the PAI before sending it to the UAS? How would the proxy know? Do you deliver the PAI to the UA - this would violate privacy laws in Europe. I don't see how this would work. > >> case 3) a B2BUA in a transit provider between the originating and >> terminating domain. There are two very different cases here - one is >> where the transit provider is an intermediate in providing PSTN >> termination services and using E.164 addresses. For example some >> company, contracts its PSTN termination from say MCI who for numbers >> in Australia perhaps uses Telstra. The company wants to see the phone >> number asserted by MCI, not Telstra - it is MCI they trust and can >> make an authorization decision based on. They have no idea who >> Telstra is so whatever telstra wants to claim is useless for the >> company. The point is, whatever things Telstra might assert to MCI, >> the company wants MCI to make an assertion that the company can use >> for it authorization decision. In these cases the transit B2BUA needs >> to resign things. > > And that's the rub. The real use/value of Identity, IMHO, is for the > transit case - period. Within a domain or between just 2, and > there are > other ways to trust, except for the really paranoid. But the > longer the > trust chain of transits is, the greater the probability the chain > is broken. > > > When I looked at the original identity draft I thought ok - the > b2bua/proxy > egress can be the signer and the ingress b2bua/proxy can be the > verifier. > Of course then I immediately thought if the 2 domains are connected > by just > those 2 elements, why bother doing the signing/verifying for a > single hop > that is going to be TLS/IPSEC anyway?? Use the PAI you already have. > > But for transit cases: it requires the transit domain(s) to either > (1) not > muck with contact, call-id, and bodies, or (2) support identity, > and to > somehow re-sign with something that the verifier in the next domain > (s) will > accept, which goes back to hop-by-hop trust kinda. But changing > (1) or (2) > is out of the local (and final) domain's control to change - they > need the > transit domain(s) to change, and that's a much bigger hurdle. > > Ok, I am done't think I am manging to explaim myself. Say A has a contract with B and B has a crontract with C. Now a call arrives at C, it seem that C wants a assertion to be made by B. Anything A says to C is clsoe to useless because C has no clue who A even is. I guese I feel like we need to sort out the requirements for what we want in a transit case and then we might be able to figure out a solution. >> As a last note, I do think there are workable solutions for the B2BUA >> case. Having UA accept message with a bad Identity header but that >> have a PAI seriously breaks Identify. One of the key things that >> Identity provides is a close to end to end integrity for the bodies. > > Yes, it signed the body, and contact, but I consider that its fatal > flaw. > It should have stuck with the From (and Date and whatever else it > thinks is > needed for a reasonable nonce). The body I know is a hard one to > not sign > (it's so tempting!). But sign the contact? What does that have to > do with > identity? > > >> This breaks this and we have no other good way to provide this. What >> I am suggesting above provides a way to keep this integrity property >> so that no device can tamper with the integrity other than devices >> that the UAS or UAC explicitly trusts to tamper with the integrity. I >> think this is a fairly important property and achievable. > > What about just splitting it into 2 Identity headers/signatures? > One for > the From and nonce-ish stuff, the other for the body and same nonce- > ish > stuff. If a middle-man wants to modify the body, he verifies and > re-signs > that second signature, or if the middle-man is unaware of identity > then the > next one can decide what to do with a bad signature for a body but > good > signature for From. > The From itself has no intrinsic value - what you are trying to sign is that some body came from the person in the From header. If the From header and it's signature can be cut and paste from one message to another, Identity would fail to solve any security problems. > So when the final UAS gets it (or its domain verifier) she says > "hmmm... the >> From was definitely signed by the URI domain company.com, but this >> body is > signed by provider.com who I trust... ok, I can trust that", vs. "I > see > company.com signed the From but the body was broken... this is > suspicious". > This way a b2bua can change the body but doesn't have to have a > certificate > matching the From-uri domain to do so, and the UAS can decide if > it's kosher > for the b2bua-domain to change the body, while also verifying the > From is of > the right domain. I haven't thought it through, but it sounds ok. You are proposing almost exactly the same thing I am. The way you are thinking of handling the body, just use that handling for both. > > -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 02 13:24:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx5eJ-0003u3-BU; Sun, 02 Jul 2006 13:22:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx5dx-0003ta-Q2 for sip@ietf.org; Sun, 02 Jul 2006 13:22:01 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx5dv-000452-V1 for sip@ietf.org; Sun, 02 Jul 2006 13:22:01 -0400 Received: (qmail 22028 invoked by uid 0); 2 Jul 2006 17:21:52 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 Jul 2006 17:21:52 -0000 Message-ID: <002d01c69dfc$0558c160$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" References: <00e201c69bcb$555b9710$31713b51@BEMBUSTER> Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt Date: Sun, 2 Jul 2006 19:21:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen, see inline Best regards, Jeroen ----- Original Message ----- From: "Cullen Jennings" To: "Jeroen van Bemmel" Cc: Sent: Sunday, July 02, 2006 3:02 AM Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt > > On Jun 29, 2006, at 3:28 PM, Jeroen van Bemmel wrote: > >> We've had some VERY long and extensive discussions on this (starting >> with http://www1.ietf.org/mail-archive/web/sip/current/ msg13677.html) >> but the draft is still not addressing some of the issues that were >> raised >> >> 1) The UAC needs a positive indication that the selected proxy can >> indeed handle STUN packets without choking on them. It is not sufficient >> if the URI it is configured with says 'keepalive=stun', that's a wish >> but no guarantee. >> >> > > Why is this a wish not a guarantee? Because the configuration may be wrong, ie the entity that provisioned the URI thinks the element supports outbound, but in fact it does not. There can be various reasons for this, like invalid manual provisioning, some edge proxy is replaced with one that does not support outbound and someone forgets to update DNS, etc I expect you will see a lot of what I'd call "opportunistic outbound": implementations that add 'keepalive=stun' to the URI for registration, in the hope that it is supported. There is nothing in the current spec to prevent this, but I believe it should be discouraged (that is, the sending of STUN packets multiplexed on SIP ports to hosts for which support is unknown). > I'm under the impression that devices that follow the RFCs should not > have problems with this. I understand the argument that we might want > DHCP or DNS to be a way to discover this configuration information but I > think either of theses systems, not to mention the config-framework, can > be used to get an URI. Keep in mind the thing that drove us to this > approach - sig- comp. We need sig-comp to work too so however we deal with > the approach for configuration of the URI so it has the sig-comp tag will > also work for this. These options were discussed several times - at one > point I was proposing a DNS scheme but I got the input that it could and > should be separated. > I suppose a similar argument applies to sigcomp: it should have been prevented that implementations try it towards hosts that are not known to support it. A difference may be that sigcomp is also used in the first request, while STUN can be postponed A second reason for providing such a 'keepalive confirmation' is that it also allows cases where the registrar / edge proxy is able to determine that keep-alives are in fact not needed (eg because it has authorative knowledge that there is no NAT or firewall in between). Not including 'keepalive=stun' would avoid unnecessary traffic. (note that perhaps a different mechanism would be more appropriate, eg "keepalive=not-needed" instead, to distinguish between not supported and not needed) >> >> 2) Section 5.3: the Edge Proxy MUST Record-Route dialog forming INVITE >> requests that it forwards over the flow towards the UA (reverse >> direction is not strictly necessary, but probably common too). If it >> does not do this, an ACK for 2xx cannot arrive. For incoming SUBSCRIBE >> it might work without (the NOTIFY could create a direct flow towards the >> target or some other proxy, using the local socket as a Contact), but >> then there would be an issue with keeping that flow alive (the STUN >> question). Probably safer to say that (in addition to MUST for INVITE) >> "the Edge Proxy SHOULD Record-Route all dialog-forming requests it >> forwards to the UA" > > This could be one way to solve the problem - others are possible too. I > don't think this is in scope for outbound. I don't think outbound does > anything that makes it so this solution (or some of the other proposed > ones) can't be used. A long time ago, outbound got stuck in a huge rat > hole of trying to define how every system should form it's high > reliability and high availability solutions. That was too big a task to > take on so I am happy to leave it out of scope as long as people can > build good system. > I agree that the way in which high reliability/availability is done should be left to implementations. However, I don't see how ACK for 2xx could arrive without Record-Route (the contents of the R-R URI, and wheteher it is used for flow mapping is an implementation issue. However, I think its use should be mandated). >> >> 3) The Proxy-Require mechanism we have discussed could be useful to UACs >> that want to ensure that a selected edge proxy supports outbound, >> aborting if not. >> > > I'll let Rohan reply to this but I don't think I see what problem it > solves. > It ensures early abortion of the registration process if outbound is not supported. As it is currently defined, a UAC has no way of determining whether an edge-proxy supports outbound (the flag in the provisioned URI makes it very likely, but not guaranteed) A second usage of a Proxy-Require mechanism is perhaps out of scope for outbound, but related to keep-alive (which, as others have pointed out, should perhaps be separated). Consider an UAC behind NAT that sends an INVITE. Note that it could manage perfectly well without outbound support (it could simply not REGISTER), but it would need to keep the flow towards its peer open. If it is somehow able to determine that the peer does not support STUN, and it cannot use TCP keepalive, what should it do? One way could be to ask a proxy that supports keepalives to stay in the signaling path. It need not be the same proxy used for registration (but it might well be). For this scenario, the UAC would need a way to ask the proxy to provide keep-alive services. "Proxy-Require: keep-alive" would be one way; semantics would be that the proxy MUST Record-Route such a request (as discussed in a parallel thread, another reason is that the ACK might contain the same Proxy-Require) >> 4) (minor remark) Perhaps some words could be added that the UAC SHOULD >> perform keepalives when configured to do so, even if it detects that >> there is no NAT. There could be a transparent firewall device that needs >> to be kept open. >> > > I agree this is the behavior we want - I thought it already more or less > said that. It does not suggest detecting if their is a NAT there at > all - if the URI has the tag, you do keep alive. > and if there is no such tag, it MUST NOT do keep alive (or at least not STUN, TCP keepalives would be harmless) ? > >> Regards, >> >> Jeroen > > I'm sorry my time is limited on this right now but I'm reading a ton of > documents and posting comments so forgive me as I suffer from a response > implosion problem. > > Cullen > >> >> >> >> >> >> >> ----- Original Message ----- From: >> To: >> Cc: >> Sent: Wednesday, June 28, 2006 12:50 AM >> Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt >> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Session Initiation Protocol Working >>> Group of the IETF. >>> >>> Title : Managing Client Initiated Connections in the >>> Session Initiation Protocol (SIP) >>> Author(s) : C. Jennings, R. Mahy >>> Filename : draft-ietf-sip-outbound-04.txt >>> Pages : 34 >>> Date : 2006-6-27 >>> >>> The Session Initiation Protocol (SIP) allows proxy servers to >>> initiate TCP connections and send asynchronous UDP datagrams to User >>> Agents in order to deliver requests. However, many practical >>> considerations, such as the existence of firewalls and Network >>> Address Translators (NATs), prevent servers from connecting to User >>> Agents in this way. This specification defines behaviors for User >>> Agents, registrars and proxy servers that allow requests to be >>> delivered on existing connections established by the User Agent. It >>> also defines keep alive behaviors needed to keep NAT bindings open >>> and specifies the usage of multiple connections. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-04.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the body of >>> the message. >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- announce >>> to change your subscription settings. >>> >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username >>> "anonymous" and a password of your e-mail address. After logging in, >>> type "cd internet-drafts" and then >>> "get draft-ietf-sip-outbound-04.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-ietf-sip-outbound-04.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> >> >> ---------------------------------------------------------------------- >> ---------- >> >> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 02 13:46:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx607-0006Qm-Rf; Sun, 02 Jul 2006 13:44:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx606-0006Qh-LA for sip@ietf.org; Sun, 02 Jul 2006 13:44:54 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx605-0005c7-CT for sip@ietf.org; Sun, 02 Jul 2006 13:44:54 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 02 Jul 2006 10:44:53 -0700 X-IronPort-AV: i="4.06,199,1149490800"; d="scan'208"; a="1834527809:sNHT32318944" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k62HiqHK020120; Sun, 2 Jul 2006 10:44:52 -0700 Received: from [192.168.1.2] (sjc-vpn6-311.cisco.com [10.21.121.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k62HiqIs009558; Sun, 2 Jul 2006 10:44:52 -0700 (PDT) In-Reply-To: <002d01c69dfc$0558c160$31713b51@BEMBUSTER> References: <00e201c69bcb$555b9710$31713b51@BEMBUSTER> <002d01c69dfc$0558c160$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <60A10346-11BD-4DE9-B53E-A11C05B1BD5B@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt Date: Sun, 2 Jul 2006 10:44:50 -0700 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1091; t=1151862292; x=1152726292; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-outbound-04.txt=20; X=v=3Dcisco.com=3B=20h=3DKfG5sG+qcQx1b+Z4qbatP1E7ris=3D; b=NL6nFvOIXItRtKOyeiZR0SZaLKVuLpiOfSLXVmNGBZOWg9PMV+7Q8XRTsJigB2esJh/3NVSv /QvqeKWfiwq+eV1CviNzG6SWe0UvX91adOnHKWBJtBQoP+ySYO8zVZBm; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 2, 2006, at 10:21 AM, Jeroen van Bemmel wrote: > >>> 4) (minor remark) Perhaps some words could be added that the UAC >>> SHOULD perform keepalives when configured to do so, even if it >>> detects that there is no NAT. There could be a transparent >>> firewall device that needs to be kept open. >>> >> >> I agree this is the behavior we want - I thought it already more >> or less said that. It does not suggest detecting if their is a >> NAT there at all - if the URI has the tag, you do keep alive. >> > > and if there is no such tag, it MUST NOT do keep alive (or at least > not STUN, TCP keepalives would be harmless) ? I'm sympathetic to what you are saying as I had originally proposed that it be allowed to do this - I pointed out the a SIP server would reject the message. Lots of people felt strongly that we should not send STUN messages to SIP servers that did not support it. The issue came up in some WG meeting - there was strong consensus that we should not send keep alive to things that did not support them. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 02 14:01:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx6Ef-0003IB-JB; Sun, 02 Jul 2006 13:59:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx6Ee-0003I3-QV for sip@ietf.org; Sun, 02 Jul 2006 13:59:56 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx6Ed-00074H-Hj for sip@ietf.org; Sun, 02 Jul 2006 13:59:56 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 02 Jul 2006 10:59:55 -0700 X-IronPort-AV: i="4.06,199,1149490800"; d="scan'208"; a="1834530080:sNHT30827892" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k62HxtFf003521; Sun, 2 Jul 2006 10:59:55 -0700 Received: from [192.168.1.2] (sjc-vpn6-311.cisco.com [10.21.121.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k62HxscL028399; Sun, 2 Jul 2006 10:59:54 -0700 (PDT) In-Reply-To: <002d01c69dfc$0558c160$31713b51@BEMBUSTER> References: <00e201c69bcb$555b9710$31713b51@BEMBUSTER> <002d01c69dfc$0558c160$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4BE2D252-ABC0-4FC0-BC3B-E5C17F153C6D@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt Date: Sun, 2 Jul 2006 10:59:53 -0700 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1163; t=1151863195; x=1152727195; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-outbound-04.txt=20; X=v=3Dcisco.com=3B=20h=3DKfG5sG+qcQx1b+Z4qbatP1E7ris=3D; b=ZYuTQlXds2nzuyQbc0p3TrvTRuZXvJfJzvAEqucwl+xkx+Ct2NWwzIjyMjAa0XuM8qFU7MxS XrxyTETnSMPzhbcuKgBdC4Vw8FdRj7VukE8OWR2MMxWzugGDLb9cY8IN; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 2, 2006, at 10:21 AM, Jeroen van Bemmel wrote: >>> 1) The UAC needs a positive indication that the selected proxy >>> can indeed handle STUN packets without choking on them. It is >>> not sufficient if the URI it is configured with says >>> 'keepalive=stun', that's a wish but no guarantee. >>> >>> >> >> Why is this a wish not a guarantee? > > Because the configuration may be wrong, ie the entity that > provisioned the URI thinks the element supports outbound, but in > fact it does not. There can be various reasons for this, like > invalid manual provisioning, some edge proxy is replaced with one > that does not support outbound and someone forgets to update DNS, etc Well totally ignoring anything to do with outbound - I don't really see how this is different from when someone configure the proxy as foo.com when it is supposed to be bar.com I do think it is important to get sip so that a user might configure an AOR name and password and everything else just happens but that is the point of the config framework. I agree configuration is a nightmare today and we need to make it easier. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 02 14:43:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx6sz-0005Pr-8u; Sun, 02 Jul 2006 14:41:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx6sx-0005Pm-Qe for sip@ietf.org; Sun, 02 Jul 2006 14:41:35 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx6sw-0000fM-EF for sip@ietf.org; Sun, 02 Jul 2006 14:41:35 -0400 Received: (qmail 8819 invoked by uid 0); 2 Jul 2006 18:41:28 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 Jul 2006 18:41:28 -0000 Message-ID: <005001c69e07$2417b150$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" References: <00e201c69bcb$555b9710$31713b51@BEMBUSTER> <002d01c69dfc$0558c160$31713b51@BEMBUSTER> <4BE2D252-ABC0-4FC0-BC3B-E5C17F153C6D@cisco.com> Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt Date: Sun, 2 Jul 2006 20:41:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> Because the configuration may be wrong, ie the entity that provisioned >> the URI thinks the element supports outbound, but in fact it does not. >> There can be various reasons for this, like invalid manual provisioning, >> some edge proxy is replaced with one that does not support outbound and >> someone forgets to update DNS, etc > > Well totally ignoring anything to do with outbound - I don't really see > how this is different from when someone configure the proxy as foo.com > when it is supposed to be bar.com > Conceptually not so different, but there would be a good chance that foo.com would either accept nothing or SIP on common SIP ports. The problem is that STUN is sent to the same port. Were it a different port, then the risk would be much lower. The combination of non-SIP (even binary) and same port makes it troublesome. > I do think it is important to get sip so that a user might configure an > AOR name and password and everything else just happens but that is the > point of the config framework. I agree configuration is a nightmare today > and we need to make it easier. Easier and more foolproof, and more easy to debug / trace when/where things go wrong. For all of this, explicit confirmation of outbound support helps. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 02 15:57:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx82M-000280-9V; Sun, 02 Jul 2006 15:55:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx82L-00027v-53 for sip@ietf.org; Sun, 02 Jul 2006 15:55:21 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx82J-0007EV-Ro for sip@ietf.org; Sun, 02 Jul 2006 15:55:21 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 02 Jul 2006 12:55:20 -0700 X-IronPort-AV: i="4.06,199,1149490800"; d="scan'208"; a="1834541171:sNHT31746672" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k62JtJwR030365; Sun, 2 Jul 2006 12:55:19 -0700 Received: from [192.168.1.2] (sjc-vpn6-311.cisco.com [10.21.121.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k62JtIcL015187; Sun, 2 Jul 2006 12:55:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <720BC7A4-8BFF-412E-A6BC-FAC41FA1289B@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Jonathan Rosenberg , IETF SIP List From: Cullen Jennings Date: Sun, 2 Jul 2006 12:55:17 -0700 X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1967; t=1151870119; x=1152734119; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-ietf-sip-gruu-09; X=v=3Dcisco.com=3B=20h=3Dd0V9YjgTijSHBaYt59YMUkB3XLw=3D; b=TJDkNV8rnUXbJ+9ImQEIXfx8hLA5sPREbZzTx5M5DVVgoLY2VnixL9rwknT0j9MZJmg/W3pA MgXwzayZhXOJ7tzRpfBSxnF9SpN1B+EG2Z+yoXxiXcVbkQgf9o0mDUwN; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Sip] draft-ietf-sip-gruu-09 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This looks good - a few comments - all very trivial Does this update 3261? If so, nice if header on first page had that Section 3 - Long lived definition. I'm really not sure what it means to say that a GRUU has a long life than any of the registrations or that it is viable for every. I'm not sure it changes behavior of anything. Is the important property that if the same AOR/Instance registers two different times it gets the same AOR? Anyways, I can live with the text exactly as is but I was not getting why it was important. Figure 1: On the diagonal arrow between GRUU and contact, I think the end near contact should have "0..1" and the end near the GRUU should have "0..n" - right now this is swapped. Section 6, page 12, 4th para or so ... you are talking about mid- dialog requests. Might be nice to mention how a transaction stateful proxy knows if something is a middialog request or not. Section 6, last para before section 7. I'm not sure I get how anything behaves differently from an unbound GRUU that exists vs the GRUU does not exist. Again, i don't have some huge problem with current text but when I read it, it makes me wonder if there is some difference which I should understand. Section 7.1.1.1 - There has been some problems with the way 3261 allowed a user to install forwarding rules using a REGISTER request. Part of the problem is that it allows an amplification attack on someone else that did not provide any consent. It makes me wonder if now that we have the consent framework moving forward, do we really want to continue down this path. I realize this is pretty orthogonal problem to GRUU. Section 8.1.1 - 2nd para. You have "However, that AOR will be rewritten ..." - I found this hard to follow. Is it the request URI? I'm not sure how to fix but you might want to have a read of the end of that para and see if it is all clear to you. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 02 16:12:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx8Gl-0005Tw-DI; Sun, 02 Jul 2006 16:10:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx8Gj-0005TJ-LS for sip@ietf.org; Sun, 02 Jul 2006 16:10:13 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx8Gi-0007WD-8r for sip@ietf.org; Sun, 02 Jul 2006 16:10:13 -0400 Received: (qmail 28667 invoked by uid 0); 2 Jul 2006 20:10:10 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 Jul 2006 20:10:10 -0000 Message-ID: <006701c69e13$85a750e0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" References: <00e201c69bcb$555b9710$31713b51@BEMBUSTER> Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt Date: Sun, 2 Jul 2006 22:10:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Something more about Proxy-Require for outbound: >> >> 3) The Proxy-Require mechanism we have discussed could be useful to UACs >> that want to ensure that a selected edge proxy supports outbound, >> aborting if not. >> > > I'll let Rohan reply to this but I don't think I see what problem it > solves. > There's another, more fundamental reason for this. The draft defines an option-tag which can occur in Supported, Require, Proxy-Require, and Unsupported headers. For each of these cases the semantics and expected behavior should be defined, either in this draft or implicitly (eg based on RFC3261) Without stating otherwise, the default behavior for Proxy-Require would be: return 420 Bad Extension if not understood, else process as defined for that feature. In particular, for the current draft a proxy would not remove the Proxy-Require header from the request it forwards. So if an UAC adds Proxy-Require, it means that every proxy on the path must support it. This is not required nor desired, hence we'd better state explicitly that a proxy needs to remove any Proxy-Require: outbound when forwarding Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 02 18:48:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxAiQ-00054F-TR; Sun, 02 Jul 2006 18:46:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxAiP-00054A-Ex for sip@ietf.org; Sun, 02 Jul 2006 18:46:57 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxAiO-0000z2-0C for sip@ietf.org; Sun, 02 Jul 2006 18:46:57 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 02 Jul 2006 15:46:55 -0700 X-IronPort-AV: i="4.06,199,1149490800"; d="scan'208"; a="1834556075:sNHT33895028" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k62Mkt8c022995; Sun, 2 Jul 2006 15:46:55 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k62MkscL007003; Sun, 2 Jul 2006 15:46:55 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 2 Jul 2006 18:46:54 -0400 Received: from [10.86.240.9] ([10.86.240.9]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 2 Jul 2006 18:46:53 -0400 Message-ID: <44A84CDD.4050205@cisco.com> Date: Sun, 02 Jul 2006 18:46:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Samir Srivastava Subject: Re: Comments on draft-srivastava-sip-e2e-ciphersuites-00 || was RE: [Sip] Comments on draft-audet-sip-sips-guidelines References: <62B9B0847CC47543B6B3B5E26BD268E60CFD9F1D@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60CFD9F1D@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2006 22:46:53.0944 (UTC) FILETIME=[6A367780:01C69E29] DKIM-Signature: a=rsa-sha1; q=dns; l=4108; t=1151880415; x=1152744415; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20Comments=20on=20draft-srivastava-sip-e2e-ciphersuites-00=20=7C=7 C=20was=20RE=3A=0A=20[Sip]=09Comments=20on=20draft-audet-sip-sips-guideline s; X=v=3Dcisco.com=3B=20h=3DUkRDo/9vbnTltv2sqHtKQZntkE4=3D; b=QAOtExnygJrB56G6OZcleW+N1X3SSEkoJxSXqSk7J7iwvJMSSHGmQiXc6r566AzCRqLg3WqA KbOcigiF2lZKLXduqL+NOS1P70dX/etN6Mal0Xszvh7n34xjxI/MzASM; Authentication-Results: sj-dkim-7.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir Srivastava wrote: > Hi Mike, > > My answers below. IMHO, it's an important piece of work. Now we > have much cleaner solution with Proxy-Require instead of > mess of SIPS etc. > > I remember in wacky thread Paul Kyzivat mentioning that if SIPS etc so > bad, why not we define a new clean > solution. I request his comments on this approach. Hoping that Dave Oran > who raised the question and Paul listening. I don't consider myself competent as a security guy. Seems like there are limits on what you can do with Via header checking. Mike covered some of that, but I guess you still have to trust all the proxies on the path. But presumably that is assumed. Having the UAC enumerate the acceptable ciphersuites seems problematic to me. (But I am way out of my depth here.) It could be that some part of the path has proxies that don't support anything listed, but support something newer and stronger that isn't listed. I wonder if it would be better to somehow rank ciphersuites by their strength, and have the UAC simply specify the minimum strength it will accept. Paul > Thx > Samir > > ________________________________ > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, June 28, 2006 8:05 AM > To: sip@ietf.org > Subject: [Sip] Comments on draft-audet-sip-sips-guidelines > > > > Samir, > > Read through the draft and had a few nits and comments. > > Nits: > > Sec 3, 2) "need to use" -> MUST use? > > page 4, top: "renegotiate" > > Will need UAC, Proxy, UAS sections in future draft. > > Comments: > > Option tag: e2e-ciphersuite: Include description of semantic for > Supported header as well. When text is expanded these could be separate > sub-sections. > > Suggestion: q-value should order the suites both by strength of > algorithm/key size (first) and then by preference (second). Reason is to > see degree of downgrade. > > SS>> Will fix in the next version. > > Via header should describe action that a proxy node MUST verify that the > Via header added by the previous hop is valid, i.e. that it did in fact > use the cipher named in the Via for the incoming link. May want to send > a report directly back to the UAC Contact notifying of the compromise. > > SS>> Will fix in the next version. > > Not sure error code sent back would help. > > Not sure how this would work with IPSEC. The applications may not have > as much control of the host or communication with it (cross-layer > indicators). I could see the IPSEC cipher listed as a substitute. But, > then the application needs to have a means to know if it is equivalent, > unless it names those up front in the new header. For fairly well known > systems (e.g. follows the ANSI Generic Security standard), this might be > a managable list. > > SS>> It's still an OPEN ISSUE. I need to consult IPSEC experts, on how > difficult it is for application to get the info/control ? > > Does IANA already have a registry of the exact string names used for > each ciphersuite? > > SS>> Will have more details on this, in the next version. > > Last half of second paragraph above Sec 4 should be in Sec 5 security > considerations. Should also point out that this may not prevent a proxy > from dropping out Security-Level header. Thought, should the cipher also > be included in the Record-Route header? The UAC should approve the route > set for continuing the call? > > SS>> Good Catch. Will have discussions on this in the next version. > > The draft is a good start. Thanks for taking the ball and running with > it. > > Mike > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 06:01:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxLDe-0005qf-HO; Mon, 03 Jul 2006 05:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxLDc-0005qV-PW for sip@ietf.org; Mon, 03 Jul 2006 05:59:52 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxLDa-0003Ki-N8 for sip@ietf.org; Mon, 03 Jul 2006 05:59:52 -0400 Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by jaguar.hughesbpo.net (8.13.6/8.13.6) with ESMTP id k639xlem010240; Mon, 3 Jul 2006 15:29:48 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k63A0XR01627; Mon, 3 Jul 2006 15:30:34 +0530 (IST) Importance: Normal X-Priority: 3 (Normal) Subject: Re: [Sip] SIP Transport Selection Question MIME-Version: 1.0 From: Rayees Khan To: Joe X-MIMETrack: MIME-CD by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 07/03/2006 02:09:03 PM, MIME-CD complete at 07/03/2006 02:09:03 PM, Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 03/07/2006 03:29:32 PM Date: Mon, 3 Jul 2006 14:09:03 +0530 Message-ID: X-Spam-Score: 3.2 (+++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1507471525==" Errors-To: sip-bounces@ietf.org --===============1507471525== Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi Joe,

My understanding is that since response has to follow the transport= published in via header, the UAS does not have choice in choosing tran= sport for response.


regards
Rayees



-----Joe <joe.uelk@gmail.com> wrote: -----

To: sip@ietf.org
From: Joe <joe.uelk@gmail.com>
Date: 07/01/2006 01:22AM
Subject: [Sip] SIP Transport Selection Question

Under the Clients section 3261 states:

"If a request is within 200 bytes of the path MTU, or if it is= larger than 1300 bytes and the path MTU is unknown, the request MUST b= e sent using an RFC 2914 congestion controlled transport protocol, such= as TCP."

Is this for "requests" (INVITE, etc.) only? What if an IN= VITE were sent as UDP but a response (200 OK) were to come back with ex= tra headers which breached the MTU? Must the node sending the OK switch= the transport to TCP? Is this optional?

Regards,
Joe
_______________________________________________
Sip mailing list =A0https://www1.ietf.org/mailman/listinfo/sip=
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current = sip
Use sipping@ietf.org for new developments on the application o= f sip
*****FSS-Private *****" DISCLAIMER: This message is proprietar= y to Flextronics Software Systems Limited (FSS) and is intended solely = for the use of the individual to whom it is addressed. It may contain &= nbsp;privileged or confidential information and should not be circulate= d or used for any purpose other than for what it is intended. If you ha= ve received this message in error, please notify the originator immedia= tely. If you are not the intended recipient, you are notified that you = are strictly prohibited from using, copying, altering, or= disclosing the contents of this message. FSS accepts no responsibility= for loss or damage arising from the use of the information transmitted= by this email including damage from virus."
"DISCLAIMER: This message is proprietary to Flextronics Software <= br> Systems Limited (FSS) and is intended solely for the use of the
individual to whom it is addressed. It may contain privileged or
confidential information and should not be circulated or used for
any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately.
If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing
= the contents of this message. FSS accepts no responsibility for
= loss or damage arising from the use of the information transmitted
= by this email including damage from virus."= --===============1507471525== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1507471525==-- From sip-bounces@ietf.org Mon Jul 03 06:39:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxLoM-0003Vj-21; Mon, 03 Jul 2006 06:37:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxLoK-0003Vd-EV for sip@ietf.org; Mon, 03 Jul 2006 06:37:48 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxLoI-0005ey-FF for sip@ietf.org; Mon, 03 Jul 2006 06:37:48 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 6B9FE2060E for ; Mon, 3 Jul 2006 16:05:13 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 54F1E20608 for ; Mon, 3 Jul 2006 16:05:13 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 16:07:43 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Update to fork-loop-fix submitted Date: Mon, 3 Jul 2006 16:09:35 +0530 Message-ID: <532B18E13CF9E64380EF5FDDE265E0711228AC@blr-m2-msg.wipro.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Update to fork-loop-fix submitted Thread-Index: AcaYZu7KA5ZvmRaxRgCAvo9fsAVo8QGJPgCA From: To: , X-OriginalArrivalTime: 03 Jul 2006 10:37:43.0412 (UTC) FILETIME=[B746D340:01C69E8C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Robert, I had suggested one more alternative (http://www1.ietf.org/mail-archive/web/sip/current/msg14359.html ) Quoted from my previous mail: I was thinking how to reduce the impact of overhead for calculating the digest. If it is suggested as follows, I think it will reduce the overhead on normal scenarios: Proxy checks to see if its address is there in the via already.=20 If it is not there, it proceeds normally without calculating the digest and inserting Via to the outgoing request without the digest. If it is there, then it is possible that the request is looping. So, this time around, it calculates a digests and inserts and sends it along. If it is looping, the request will definitely come in again, which can be rejected. This way the impact of calculating the digest is required (reduced to a smaller percent of the sessions) only when the proxy is suspicious the request might be looping. Of course this results in the scenarios mentioned in the id to be successful in completing the first loop, but the second loop will be detected and arrested. I think this can be applicable to general loop detection, and not just fork loop fixes. Regards, Ravi. -- =20 Ravishankar. G. Shiroor Wipro Technologies, Bangalore. =20 ravishankar.shiroor@wipro.com -- =20 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Sunday, June 25, 2006 8:22 PM > To: IETF SIP List > Subject: [Sip] Update to fork-loop-fix submitted >=20 > Until it appears in the repository, see: > http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-02.txt >=20 > This was a moderately heavy touch - based on list feedback,=20 > I've moved and updated the sections covering the=20 > loopdetection algorithm in from 3261. In the process of=20 > writing the clarifying text, I discovered several places that=20 > need clarification. They are listed as Open Issues in the=20 > draft. Basically there are fields that I can't recall or=20 > reconstruct how they would be useful in the part of the hash=20 > used for loop-detection or spiral differentiation. If anyone=20 > can remember why they need to be included, send a note to the=20 > list and we'll capture that in the draft. >=20 > Please review the updated loop-detection text very carefully. >=20 > Here's the changelog from the draft: >=20 > Integrated several editorial fixes suggested by=20 > Jonathan Rosenberg >=20 > Noted that the reduction of the attack to a single registration > against a single URI as documented in previous versions, is, in > fact, going to be effective against implementations=20 > conforming to > the standards before this repair. >=20 > Re-incorporated motivation from the original=20 > maxforwards-problem > draft into the security considerations section based=20 > on feedback > from Cullen Jennings >=20 > Introduced replacement text for the loop detection algorithm > description in RFC 3261, fixing the bug 648 (the=20 > topmost Via value > must not be included in the second part) and clarifying the > algorithm. Removed several other fields suggested by 3261 and > placed open issues around their presence. >=20 > Added a Notes to Implementors section capturing the=20 > "common way" > text and pointing to the interoperability issues that have been > observed with loop detection at previous SIPits >=20 >=20 > Thanks, >=20 > RjS >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 11:06:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPyb-0002fi-9D; Mon, 03 Jul 2006 11:04:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPyZ-0002fd-BX for sip@ietf.org; Mon, 03 Jul 2006 11:04:39 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxPyW-0004b7-Vp for sip@ietf.org; Mon, 03 Jul 2006 11:04:39 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2006 11:04:37 -0400 X-IronPort-AV: i="4.06,201,1149480000"; d="scan'208"; a="91564961:sNHT30801064" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k63F4ano026444; Mon, 3 Jul 2006 11:04:36 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Jul 2006 11:04:36 -0400 Received: from [192.168.1.102] ([10.86.242.137]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Jul 2006 11:04:36 -0400 Message-ID: <44A93203.2090800@cisco.com> Date: Mon, 03 Jul 2006 11:04:35 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Proposals for review process to conclude WGLCs References: <93946F5D-56E9-466E-B444-CE19BFFF2E49@softarmor.com> In-Reply-To: <93946F5D-56E9-466E-B444-CE19BFFF2E49@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2006 15:04:36.0156 (UTC) FILETIME=[FF9DA7C0:01C69EB1] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I really like the first idea - of using a conference call. I think it imposes a specific deadline that puts pressure on folks to get the reviews done in a timely way. Otherwise, you get embarassed by missing a call that you committed to be on. Its the same logic behind the IETF draft deadline. A few more tweaks to what you propose - I'd suggest that reviewers have to show up to the call with specific comments on the document, which they can work through and raise. Also, though the output of the review can be go/no-go, lets remember everything needs to come through the mailer ultimately. Thanks, Jonathan R. Dean Willis wrote: > > One of the questions we've struggled with is how to get sufficient > review on a document under WGLC to make sure it's really done. > > > SIPPING is following a new procedure with designated reviewers, doing > review by email, and sending stuff back to the. Apparently this suffers > from the expected issues, with designated reviewers sometimes not quite > meeting their review commitments. > > Cisco made me take a peer-review refresher class the other day, so this > started me thinking about some alternatives. > > In the model taught in this class, each peer review includes 1) a > "moderator" or "reader" who frames the questions and keeps things on > track, 2) a "recorder" who records conclusions and issues raised during > the review, 3) the author(s), who neither presents no interprets the > work, but does respond to specific questions about it, and 4) the > reviewers, who hopefully have expertise and have committed time to the > review. > > > I'd like to propose a couple of alternative models to what SPPING has > been doing and seeing if either resonates with our group. > > > 1) Real-time review sessions via conference call: When we get ready to > do a final review, the chairs assemble a review team. Presumably, this > review team is assembled by polling the list for volunteers, and by > pushing extra hard for stakeholders and other people with specific > expertise. The moderator builds up a checklist and set of basic > questions to consider, and distributes it to the review team. At a tiem > agreed to by enough of the participants, we have a conference call, not > to exceed two hours, and work through the checklist in a moderated > fashion. At the conclusion of that two hours, we either reach a > positive decision, a negative decision (with list of issues and > actions), or decide we need more review. > > > 2) Moderated email-review, using the entire list as the "review team". > In this model, the chairs pick a moderator and recorder for the review. > The moderator sets up a checklist and sends it to the list, along with > an announcement of the review. The moderator then goes through the > checklist item-by-item on list, polling for comments. The recorder > records any issues or conclusions. Each item might take two or three > days for primary comments, but could be revisited during the review > process if needed. The author could answer specific questions about the > draft, but not paraphrase or interpret. At the conclusion of the > review, the moderator and reviewer would report to the chairs, who > would decide whether we have issues, a conclusion, or need further review. > > > What do y'all think? > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 12:08:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQwI-00008Y-CG; Mon, 03 Jul 2006 12:06:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQwH-00008T-6s for sip@ietf.org; Mon, 03 Jul 2006 12:06:21 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxQwF-00088q-Tl for sip@ietf.org; Mon, 03 Jul 2006 12:06:21 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k63G6Fqt025308; Mon, 3 Jul 2006 11:06:15 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k63G6D415070; Mon, 3 Jul 2006 11:06:15 -0500 (CDT) Message-ID: <44A94075.3030505@lucent.com> Date: Mon, 03 Jul 2006 11:06:13 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Proposals for review process to conclude WGLCs References: <93946F5D-56E9-466E-B444-CE19BFFF2E49@softarmor.com> In-Reply-To: <93946F5D-56E9-466E-B444-CE19BFFF2E49@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > In the model taught in this class, each peer review includes 1) a > "moderator" or "reader" who frames the questions and keeps things on > track, 2) a "recorder" who records conclusions and issues raised during > the review, 3) the author(s), who neither presents no interprets the > work, but does respond to specific questions about it, and 4) the > reviewers, who hopefully have expertise and have committed time to the > review. Dean: This is probably the CMMI peer review (or a derivation thereof). I have been part of such reviews for software processes; they tend to work well assuming the reviewers indeed know what is going on with the code. I have also observed that often times, the reviews get bogged down on how many spaces of indentation are permissible. Hence the need for reviewers that are astute. In the context of your proposals: > 1) Real-time review sessions via conference call: [...] > 2) Moderated email-review, using the entire list as the "review team". [...] > What do y'all think? (1) may be more productive, for the reasons that Jonathan mentioned as well. Also, I am mapping this to something else that happens in the IETF -- the NomCom meeting, which is literally, a *peer's* review instead of a peer review. At these teleconference meetings, it is expected that the voting members read the questionnaires/bios in order to vote on the candidates. Given that the voting members are: (a) interested in the process, which is why they volunteered (b) prepared (by reading the bio and questionnaire) (c) on a real-time review session via conference call things tend to go smoothly in so far as the review of a candidate is concerned (whether or not everyone agrees that this is the right candidate is another matter altogether). Being on the phone and preparing to verbalize your thoughts appears to allow introspection of what is it that you are reviewing. Substitute (a), (b), and (c) above for reviewing WGLC documents, and I think you'll have a good working model to conclude WGLCs. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 12:28:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxRGD-0002Db-LE; Mon, 03 Jul 2006 12:26:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxRGC-0002DW-IO for sip@ietf.org; Mon, 03 Jul 2006 12:26:56 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxRGB-0001dA-94 for sip@ietf.org; Mon, 03 Jul 2006 12:26:56 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k63GQsqv008884 for ; Mon, 3 Jul 2006 11:26:55 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k63GQs423949; Mon, 3 Jul 2006 11:26:54 -0500 (CDT) Message-ID: <44A9454E.7080109@lucent.com> Date: Mon, 03 Jul 2006 11:26:54 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sip] -01 version of domain-certs (Domain Certificates in SIP) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks: Dean has been kind enough to add domain-certs-01 to the reading list of connect-reuse. The sole open issue in connect-reuse revolves around virtual SIP servers and certs, and there are precious few guidelines we have around these except for SIP Identity (section 13.4). Domain-certs contains text to foster discussion on this and a couple of other issues, server farms for instance, which has not seen any discussion. In April we had discussions on the identities stored in domain certificates. The summary of these discussions is included in Section 4 of domain-certs-01. Please eyeball the draft if you have some cycles and can comment on it. It is available at http://www.ietf.org/internet-drafts/draft-gurbani-sip-domain-certs-01.txt Thank you. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 13:05:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxRph-0007xO-4z; Mon, 03 Jul 2006 13:03:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxRpf-0007wH-8B for sip@ietf.org; Mon, 03 Jul 2006 13:03:35 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxRpd-0003bR-Tx for sip@ietf.org; Mon, 03 Jul 2006 13:03:35 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k63H3WNc001968 for ; Mon, 3 Jul 2006 12:03:32 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 3 Jul 2006 18:03:31 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0134D2616@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Mon, 3 Jul 2006 18:03:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] Presentation slides for SIP WG sessions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean has posted the agenda at http://www.softarmor.com/sipwg/meets/ietf66/agenda.html (and which will also be posted on the official IETF site as well) https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 which indicates various presenters on topics. Could we ask (nay demand) that presenters send their slides to Dean and myself at least 30 minutes before the WG sessions are due to start. We would like time to get these posted before the session starts so that remote participants have the opportunity to access them while the presentation is in progress. (If you fail to produce them, then we may make you present without the slides, so that all participants - both in the room and remote - have the opportunity of enjoying the same experience!) Obviously the earlier you deliver them the better for the chairs and all participants, and we can take them immediately if you so wish. Remember that presentations are about identifying the issues to the WG to resolve, and not about what you have done to the draft - you should already have presented the history of how you got to the current draft to the SIP list when you submitted it, and ideally it should also be included in a tear off section in the document - and the WG is expected to have read the document. And remember to leave time for the WG to discuss these issues - do not have so many slides that we stand no change of the WG presenting their opinion on issues. External participants may want to bookmark http://videolab.uoregon.edu/events/ietf/ and the presentations will be available at the same locations as the agenda. as the place where they can access the streaming audio of the various sessions. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 13:11:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxRvx-0000uZ-9K; Mon, 03 Jul 2006 13:10:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxRvv-0000sR-7i for sip@ietf.org; Mon, 03 Jul 2006 13:10:03 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxRvt-0003me-VY for sip@ietf.org; Mon, 03 Jul 2006 13:10:03 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1U004QD7HDQK@usaga01-in.huawei.com> for sip@ietf.org; Mon, 03 Jul 2006 10:05:37 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1U006Q77HCE7@usaga01-in.huawei.com> for sip@ietf.org; Mon, 03 Jul 2006 10:05:37 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [59.92.172.69]) by szxmc01-in.huawei.com (mshttpd); Mon, 03 Jul 2006 22:08:49 +0500 Date: Mon, 03 Jul 2006 22:08:49 +0500 From: prakashar 70241 To: sip@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] SIP Diagnostic - New Requirement X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Currently the SIP diagnostic draft, sip-hop-limit-diagnostics talks about returning additional diagnostic information in the 483. I am wondering whether there would be a need to extend this draft to make it generic so that caller can request for providing such additional diagnostic information even in 200 OK. The usecase that I have in mind is to provide some kind of tool to the service provider who wants to use this diagnostic information to check the path/domain the call has traversed and take measures to update/optimize the routing policies. If the above requirement is acceptable, then the security aspect of such a functionality will also have be addressed (may be through authorization mechanism defined in 3261). Regards, Prakash HTIPL FIN PDT System Engineering Group Huawei Technologies India Pvt. Ltd Bangalore, India ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 14:29:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxT99-00019t-D8; Mon, 03 Jul 2006 14:27:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxT98-00019n-KI for sip@ietf.org; Mon, 03 Jul 2006 14:27:46 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxT98-000633-9E for sip@ietf.org; Mon, 03 Jul 2006 14:27:46 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k63IRev4025614; Mon, 3 Jul 2006 13:27:40 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 3 Jul 2006 19:27:40 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0134D2622@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Mon, 3 Jul 2006 19:27:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] Comments on draft-ietf-sip-outbound-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Herewith my comments on the above document. Technical --------- 1) Section 2.1. The word "connection" gets used at various points in the document, including the introduction. I'd appreciate a definition. 2) I thought that we agreed at the last WG meeting that for TCP, keepalives were perfectly appropriate if they worked. I guess this is primarily a UAC issue rather than a proxy issue. TCP keepalives seem underdocumented, and in some places it seems that STUN is the only mechanism. Should there not be additional information on TCP keepalives at the end of section 3.1. The note in 3.4 seems entirely too negative, implying that the use is deprecated altogether. Section 4.4.1 is also implying that the UAC must only support STUN keepalives - where is the TCP equivalent section. Section 7 applies to all implementations, but ignores the support of TCP keepalives. 3) Section 3.2: The registrar challenges this registration to authenticate Bob. When the registrar adds an entry for this contact under the AOR for Bob, the registrar also keeps track of the connection over which it received this registration. I am not sure of the relevance of the first sentence. Yes it may happen here, but the way it is written implies that outbound only works if it occurs. 4) Section 3.4 (last paragraph) indicates: Regardless if they are in the same administrative domain, this specification requires that Registrars and Edge proxies support the Path header mechanism in RFC 3327 [RFC3327]. I found the requirement for UAC sort of in subclause 4.2. I found no requirement for the edge proxy to support the Path header extension in section 5. I did find a clear statement for the registrar in section 6.1. 5) Section 4.1: The UA SHOULD include a "sip.instance" media feature tag as a UA characteristic [RFC3840] in requests and responses. As described in [RFC3840], this media feature tag will be encoded in the Contact header field as the "+sip.instance" Contact header field parameter. The value of this parameter MUST be a URN [RFC2141]. One case where a UA may not want to include the URN in the sip.instance media feature tag is when it is making an anonymous request or some other privacy concern requires that the UA not reveal its identity. As currently written this seems to be a "MUST" followed by an instance where the "MUST" doesn't apply, and this is not allowed in RFC 2119. However it appears that this was not the intention, and that some rewording is required. 6) Section 4.2: The UAC MUST indicate that it supports the Path header [RFC3327] mechanism, by including the 'path' option-tag in a Supported header field value in its REGISTER requests. Other than optionally examining the Path vector in the response, this is all that is required of the UAC to support Path. Either the UAC supports the Path header extension, or not. I am not sure that adding the second sentence helps. 7) Section 4.2.1: I did not understand this subclause at all. Can you explain what you are trying to communicate? 8) Section 4.4.2: When a flow to a particular URI in the outbound-proxy-set fails, the UA needs to form a new flow to replace the old flow and replace any registrations that were previously sent over this flow. Each new registration MUST have the same reg-id as the registration it replaces. This is done in much the same way as forming a brand new flow as described in Section 4.2; however, if there is a failure in forming this flow, the UA needs to wait a certain amount of time before retrying to form a flow to this particular next hop. is almost a dupulication of the requirement in 4.2: These ordinary registration requests MUST also add a distinct reg-id parameter to the Contact header field. Each one of these registrations will form a new flow from the UA to the proxy. The reg-id sequence does not have to be sequential but MUST be exactly the same reg-id sequence each time the device power cycles or reboots so that the reg-id values will collide with the previously used reg-id values. This is so the proxy can realize that the older registrations are probably not useful. Can we make clearer that one relates to choosing a new reg-id on an initial registration, and the other relates to reusing the previous reg-id on a reboot and that these are therefore two distinct cases. 9) Section 4.4.2. Should the default times vary for TCP? 4.4 specifies different times between keepalives for TCP and UDP. 10) Section 6.2: Under what circumstances does the SHOULD not apply? And if the SHOULD is not followed, what does the registrar do instead? 11) Not sure that reference RFC 3968 and reference RFC 3969 qualify as normative references. They are only explanation to the IANA on how the text is added to the registry. 12) GRUU currently defined as an informative reference. Given that it defines the instance id which is needed for this protocol, I would have thought it needed to be normative. NITS ---- 13) Section 3.3. This text starts out by using the term "administrative domain" and then starts shortening it to just "the domain". Given that "domain" is such an overused word I suggest we use "administrative domain" in full throughout, or find a completely new term. 14) Section 3.4, 2nd paragraph has a "SHOULD". This is a general introduction, and I am surprised that RFC 2119 terminology appears at all. Suggest requirement is moved to a later clause (unless it is already there). 15) I counted three different ways of representing notes throughout the text. I like the style of indentation, with a clear first word saying note, which you have used as one of these options. Can we align the remainder of the instances where the word "note" appears with this. 16) Section 4.2 should probably do with some substructuring with inclusion of some header level 3 titles. The contents of 4.2 and 4.2.1 seem unrelated. 17) Section 4.2, 3rd paragraph: These ordinary registration requests MUST also add a distinct reg-id parameter to the Contact header field. Each one of these registrations will form a new flow from the UA to the proxy. The reg-id sequence does not have to be sequential but MUST be exactly the same reg-id sequence each time the device power cycles or reboots so that the reg-id values will collide with the previously used reg-id values. This is so the proxy can realize that the older registrations are probably not useful. Not sure "collide" is the right word. Perhaps "match the previously..." 18) Text seems to alternate between using "UAC" and "UA" and "User Agent". Where the UA is a UAC, can we use the correct term? 19) Where response codes are identified can we include them in full RFC 3261 format in all cases, e.g. correct the following: For example, if a proxy forwarded a request to 4 locations, and received 503, 407, 501, and 404 responses, it may choose to forward the 407 (Proxy Authentication Required) response. 20) Appendix A is followed by a Section 15. regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 15:14:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxTqC-0001l0-Oz; Mon, 03 Jul 2006 15:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxTqB-0001kv-Ol for sip@ietf.org; Mon, 03 Jul 2006 15:12:15 -0400 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxTqA-0008LD-Hq for sip@ietf.org; Mon, 03 Jul 2006 15:12:15 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k63JCCBR009128; Mon, 3 Jul 2006 14:12:13 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3G53PNRQ>; Mon, 3 Jul 2006 20:12:12 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0134D2624@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Mon, 3 Jul 2006 20:12:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: erkki.koivusalo@nokia.com Subject: [Sip] Comments on draft-koivusalo-sip-outbound-discovery-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Technical: ---------- 1) I need to understand whether this updates RFC 3263 or just extends it. Part of this is what appears on the cover page and in the RFC index as and when it is finally approved, but the other part also relates to compatibility, see later comment. 2) I think you have already acknowledged this, but the document requires revision to align with the terminology in the latest version (-04) of draft-ietf-sip-outbound. 3) In section 5, as far as I understand, the NAPTR request is identical for a UA that supports RFC 3263 and for one that supports this extension. Therefore the difference is in the response. Therefore the paragraph of UA requirements: As per RFC 2915 [4], the client discards any NAPTR records whose services fields are not applicable. A client resolving a SIPS URI MUST discard any services that do not contain "SIPS-O" as the protocol in the service field. A client resolving a SIP URI MUST retain records with "SIP-O" and the transport protocols the client supports and SHOULD retain records with "SIPS-O", if the client supports TLS. must work with a NAPTR response that has no knowledge of outbound. Is the above paragraph compatible with this? Additionally note that the words "if the client supports TLS" are superfluous. As RFC 3261 requires support of TLS, we are not documenting capabilities where TLS is not supported. regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 15:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxUHh-0004C8-JO; Mon, 03 Jul 2006 15:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxUHg-0004C3-8T for sip@ietf.org; Mon, 03 Jul 2006 15:40:40 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxUHZ-0001Kh-0V for sip@ietf.org; Mon, 03 Jul 2006 15:40:40 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 3B3B96C022; Mon, 3 Jul 2006 14:39:40 -0400 (EDT) Subject: Re: [Sip] draft-ietf-sip-hop-limit-diagnostics-03 From: Scott Lawrence To: Cullen Jennings In-Reply-To: References: <1150495197.10237.51.camel@sukothai.pingtel.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Mon, 03 Jul 2006 15:39:40 -0400 Message-Id: <1151955580.2892.102.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mon, 2006-06-26 at 09:00 -0700, Cullen Jennings wrote: > On Jun 16, 2006, at 2:59 PM, Scott Lawrence wrote: > > > > > There are, I think, two issues remaining for discussion: > > I disagree - I don't think the draft of the discussion has addressed > the issue I brought up. I'm going to guess here - do you mean the issue of how large the response should be? There is text in the draft on _how_ to reduce the size of the response. 3261 does not provide guidance clear guidance on response size limits. It _does_ say that all implementations MUST be able to handle messages up to the maximum UDP packet size, which can probably handle even 70 hop messages. If you think that SIP needs better definition of _when_ to limit response sizes and _what_ size they should be limited to, then I think that's an interesting discussion, but it's a bigger question than this error response and a problem that already exists whether this draft is accepted or not. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 16:39:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxVAQ-00072Q-FU; Mon, 03 Jul 2006 16:37:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxVAP-00072I-1t for sip@ietf.org; Mon, 03 Jul 2006 16:37:13 -0400 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxVAN-0005wr-SH for sip@ietf.org; Mon, 03 Jul 2006 16:37:13 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k63Kb66L017171; Mon, 3 Jul 2006 15:37:06 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3G53P3HL>; Mon, 3 Jul 2006 21:37:06 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0134D262D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Mon, 3 Jul 2006 21:37:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Rohan Mahy , "Vijay K. Gurbani" , brett@broadsoft.com Subject: [Sip] Comments on draft-ietf-sip-connect-reuse-05 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have the following comments on the draft: Technical --------- 1) I am interested in the question of whether this draft updates RFC 3261 or not, and would appreciate some list discussion on that issue. What, if any, RFC 3261 requirements does it change? NITS ---- 2) The IANA considerations may need some additional information. You may want to look at the outbound draft to see if there is information there you could use as a template. 3) You may want to update Rohan's affiliation on the cover page (I assume he has it right on outbound). regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 17:16:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxVks-0003QY-JU; Mon, 03 Jul 2006 17:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxVkr-0003QT-58 for sip@ietf.org; Mon, 03 Jul 2006 17:14:53 -0400 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxVko-00050s-RX for sip@ietf.org; Mon, 03 Jul 2006 17:14:53 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k63LEabu018038; Mon, 3 Jul 2006 16:14:37 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3G53PPAY>; Mon, 3 Jul 2006 22:14:36 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0134D2632@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Rayees Khan , Joe Subject: RE: [Sip] SIP Transport Selection Question Date: Mon, 3 Jul 2006 22:14:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There is an implicit assumption in the MTU size that may or may not prevent fragmentation. The request is specified to be MTU minus 200 bytes such that it is unlikely that the addition of headers and parameters by proxies along the path will still keep it in the MTU size, and a further assumption exists that responses will be no larger than requests. Neither of these assumptions is true in all circumstances. However a response to a request sent over UDP will be returned over UDP, and the response will in most cases get through even if the MTU size is exceeded. The problem is that the response is not delivered reliably and there may be unnecessary retransmissions of the response in order for it to be delivered. As over the years the size of SIP messages have exploded, there have been calls for the UDP option to be removed entirely. regards Keith -----Original Message----- From: Rayees Khan [mailto:rayees.khan@flextronicssoftware.com] Sent: 03 July 2006 09:39 To: Joe Cc: sip@ietf.org Subject: Re: [Sip] SIP Transport Selection Question Hi Joe, My understanding is that since response has to follow the transport published in via header, the UAS does not have choice in choosing transport for response. regards Rayees -----Joe wrote: ----- To: sip@ietf.org From: Joe Date: 07/01/2006 01:22AM Subject: [Sip] SIP Transport Selection Question Under the Clients section 3261 states: "If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 congestion controlled transport protocol, such as TCP." Is this for "requests" (INVITE, etc.) only? What if an INVITE were sent as UDP but a response (200 OK) were to come back with extra headers which breached the MTU? Must the node sending the OK switch the transport to TCP? Is this optional? Regards, Joe _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip *****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 17:51:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxWI9-0005V8-2b; Mon, 03 Jul 2006 17:49:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxWI7-0005V3-D4 for sip@ietf.org; Mon, 03 Jul 2006 17:49:15 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxWI6-00014m-2v for sip@ietf.org; Mon, 03 Jul 2006 17:49:15 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k63LnAP02065; Mon, 3 Jul 2006 17:49:10 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Transport Selection Question Date: Mon, 3 Jul 2006 16:49:09 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D057387@zrc2hxm2.corp.nortel.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0134D2632@en0033exch001u.uk.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Transport Selection Question Thread-Index: Acae5c6sMzkc708FS1ySfFUCJ1cQOQAAt+2A From: "Samir Srivastava" To: "Drage, Keith \(Keith\)" , "Rayees Khan" , "Joe" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As over the years the size of SIP messages have exploded, there have been calls for the UDP option to be removed entirely. SS>> Refer followwing thread from MMUSIC, for how big SDP can be with ICE etc extensions (~10 K) http://www1.ietf.org/mail-archive/web/mmusic/current/msg04204.html Should we take action sooner ?=20 Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 18:53:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxXGk-0002LH-GR; Mon, 03 Jul 2006 18:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxXGi-0002L7-NR for sip@ietf.org; Mon, 03 Jul 2006 18:51:52 -0400 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxXGi-0004fs-76 for sip@ietf.org; Mon, 03 Jul 2006 18:51:52 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k63MpliA000906; Mon, 3 Jul 2006 17:51:47 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3G53PP8X>; Mon, 3 Jul 2006 23:51:47 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0134D263D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Mon, 3 Jul 2006 23:51:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 1.1 (+) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: jmpolk@cisco.com Subject: [Sip] Comments on draft-ietf-sip-location-conveyance-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have the following comments on the above draft: Structural ---------- 1) Abstract: From reading the document, it is clear that presence systems are not covered at all in this document for various reasons. Therefore PUBLISH, SUBSCRIBE and NOTIFY are essentially out of scope. It seems to me that this should be made much more explicit in the abstract. 2) The SIP extension guidelines (RFC 4485) need to be applied to this document, which requires some substantial restructuring. The absence of application of these rules mean that the requirements of the document are extremely unclear. For example RFC 4485 states (section 4.5): Developers of protocols often get caught up in syntax issues, without spending enough time on semantics. The semantics of a protocol are far more important. SIP extensions MUST clearly define the semantics of the extensions. Specifically, the extension MUST specify the behaviors expected of a UAC, UAS, and proxy in processing the extension. This is often best described by having separate sections for each of these three elements. Each section SHOULD step through the processing rules in temporal order of the most common messaging scenario. Absence of this application means that in places in this document it is impossible to determine whether a requirement and its required support occurs as the sender of the location information, or the receiver of the location information. 3) Section 1 (and possibly section 2) should be redrafted taking into account RFC 4485 section 4.7: Too often, extension documents dive into detailed syntax and semantics without giving a general overview of operation. This makes understanding of the extension harder. It is RECOMMENDED that extensions have a protocol overview section that discusses the basic operation of the extension. Basic operation usually consists of the message flow, in temporal order, for the most common case covered by the extension. The most important processing rules for the elements in the call flow SHOULD be mentioned. Usage of the RFC 2119 [1] terminology in the overview section is NOT RECOMMENDED, and the specification should explicitly state that the overview is tutorial in nature only. This section SHOULD expand all acronyms, even those common in SIP systems, and SHOULD be understandable to readers who are not SIP experts. [27] provides additional guidance on writing good overview sections. I found this text much too wordy, and considered that it should be possibly to convey the necessary information to the reader in about half the length. 4) Section 3 need to have all the RFC 2119 language removed (see history-info and outbound as examples). I remain open as to whether it appears at the start of the document, as here and in history-info, or at the end, as in outbound, but given the length, we may want to consider moving it to the end. 5) Section 6 should probably follow immediately on from the procedures in the bulk of section 4, and probably be split as in comment 2) above. 6) Section 7 should be integrated into the main procedures text. Technical --------- 7) Section 1, of the three examples given in this introduction, item 2) is out of scope. I had to read an awful lot of text to discover that fact. 8) Section 2, 1st paragraph. Probably not appropriate to use the term "trust model". That term is defined in RFC 3324 and RFC 3325, and I am not convinced the usage here is one and the same. 9) Section 2, 3rd para. No routing of the request based on the location contents is required in this case, therefore no SIP Proxies between these two UAs need to view the location information contained in the SIP message(s). The UAC should know certain types of messages will be routed based on the UA's location when creating a message. Did not understand what this paragraph is meant to be telling me - can you explain it. 10) Section 3.1 UAC-4: This is not a generic requirement as it is already identified that certain methods are outside the scope of this document. 11) Section 3.1 UAC-9, UAC-10: I assume this is specified this way so that misconfiguration releases the location rather than hides it. I believe this contravenes the regulatory requirements of some countries. I believe in Japan privacy requirements are more important that the transmission of the information for emergency calls. If someone from Japan was writing these requirements they would therefore indicate exactly the opposite. 12) Section 3.2 UAS-6 and section 3.3 Proxy-4. Firstly this is halfway into implementation. Secondly if it is required to address location errors in requests, why is the same consideration not given to location errors in responses. 13) Section 3.3 Proxy-1: This merely repeats RFC 3261, rather than developing a new requirement. 14) Section 3.3 Proxy-3: This seems to be rewriting the requirements to correspond to the solution. I understand the problem is that the solution cannot distinguish between multiple locations, nor understand the reliability, and therefore a receiver may get confused. Firstly this does not seem to me to be a SIP issue, and secondly in general the ability to transport multiple locations could be regarded as useful - they just need some form of assertion as to who provided which location. 15) Section 4 and elsewhere. I don't find location in responses well described at all. It seems to be an afterthought, rather than something that is decided based on a full set of requirements. I have already made a comment with regard to requirements on error handling. Should we support location in response, or force the UAS to generate a request of its own in order to send a location? 16) Section 4. Should the instances of "URI" here be "URN". 17) Section 4 specifies: Because a person's location is generally considered to be sensitive in nature, certain security measures need to be taken into account when transmitting such information. Section 26 of [RFC3261] defines the security functionality SIPS for transporting SIP messages with either TLS or IPSec, and S/MIME for encrypting message bodies from SIP intermediaries that would otherwise have access to reading the clear-text bodies. SIP endpoints SHOULD implement S/MIME to encrypt the PIDF-LO message body (part) end-to-end. The SIPS-URI from [RFC3261] MUST be implemented for message protection (message integrity and confidentiality) and SHOULD be used when S/MIME is not used. The entities sending and receiving location MUST obey the privacy and security rules in the PIDF-LO, regarding retransmission and retention, to be compliant with this specification. Self-signed certificates SHOULD NOT be used for protecting PIDF-LO, as the sender does not have a secure identity of the recipient. However RFC 4119 is already normatively referenced which contains the following text: For the purposes of this document, only the securing of a PIDF document as a whole, rather than element-by-element security, is considered. None of the requirements [10] suggest that only part of the information in a location object might need to be protected while other parts are unprotected; virtually any such configuration would introduce potentials for privacy leakage. Consequently, the use of MIME-level security is appropriate. S/MIME [5] allows security properties (including confidentiality, integrity, and authentication properties) to be applied to the contents of a MIME body. Therefore, all PIDF implementations that support the XML Schema extensions for location information described in this document MUST support S/MIME; in particular, they MUST support the CMS [6] EnvelopedData and SignedData content types, which are used for encryption and digital signatures, respectively. It is believed that this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3, and 14.4. Additionally, all compliant applications MUST implement the AES encryption algorithm for S/MIME, as specified in [8] (and per REQ 15.1). Of course, implementations MUST also support the baseline encryption and digital signature algorithms described in the S/MIME specification. S/MIME generally entails the use of X.509 [9] certificates. In order to encrypt a request for a particular destination end-to-end (i.e., to a Location Recipient), the Location Generator must possess credentials (typically an X.509 certificate) that have been issued to the Location Recipient. Implementations of this specification SHOULD support X.509 certificates for S/MIME, and MUST support password- based CMS encryption (see [6]). Any symmetric keying systems SHOULD derive high-entropy content encoding keys (CEKs). When X.509 certificates are used to sign PIDF Location Objects, the subjectAltName of the certificate SHOULD use the "pres" URI scheme. Which set of text takes precedence? 18) Section 4: More than one location representation or format MAY be included in the same message body part, but all MUST point at the same position on the earth (altitude not withstanding), as this would confuse the recipient by pointing at more than one position within the same message body part. There MAY be a case in which part or parts of one location format and part or parts of another format exist in the same message body part. These complementary pieces of information MUST point at the same position on the earth, yet are incomplete within their own format. For example, there maybe be a latitude and longitude in coordinate format and a civic altitude value to complete a 3-dimensional position of a thing (i.e. which floor of a building the UA is on in a building at a particular lat/long coordinates pair). Not sure what "altitude not withstanding" means, particular as this is a RFC 2119 MUST sentence. Additionally, the paragraph repeats the essence of the "same position on the earth" in two separate MUST statements. 19) Section 4: There MAY be more than one PIDF-LO in the same SIP message, but each in separate message body parts. Each location body part MAY point at different positions on the earth (altitude not withstanding). If the message length exceeds the maximum message length of a single packet (1300 bytes), TCP MUST to be used for proper message fragmentation and reassembly. Why is the final sentence stronger than RFC 3261. I assume your thinking is emergency calls, but that is only one of the uses of this document. And surely if emergency calls is the problem, then the requirement has to be made as an update to RFC 3261 for all emergency calls, not just those that happen to carry location. 20) Section 4: Several push-based SIP Request Methods are capable (and applicable) of carrying location, including: INVITE, REGISTER, UPDATE, and MESSAGE, While the authors do not yet see a reason to have location conveyed in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a reason to prevent carrying a PIDF-LO within these Method Requests as long as the SIP message meets the requirements stated within this document. Discussing Location in the PUBLISH Request Method will be for another document. The draft seems to go to a great deal of effort to ensure the information is carried end to end, but then suggests that the information might be entrusted to non end-to-end messages. I would suggest that the header and body are declared out of scope for ACK and CANCEL. 21) Section 4: A 200 OK to a SIP Request MAY carry the UAS's PIDF-LO back to the UAC that provided its location in the original request, but this is not something that can be required due to the timing of the request to 200 OK messages, with potential local/user policy requiring the called user to get involved in determining if the caller is someone they wish to give their location to (and at what precision). I don't understand what this is trying to convey. Please explain? 22) Section 4.1: It is envisioned that HTTP, through the http_URL in [RFC216], and HTTPS [RFC2818] MAY be used to dereference a location-by-reference PIDF-LO. Do we place any requirement to support HTTP at any location receiver, so that location by reference when received actually works? 23) Is it not sufficient to say that RFC 2119 applies, and therefore the security considerations of RFC 2119 applies. NITS ---- 24) Section 3.1 UAC-8: As by-reference doesn't carry the PIDF-LO within SIP, but within HTTP, the text is wrong. 25) Can we consistently use "request" or "response" rather than "message" following RFC 3261 terminology? 26) Section 4: Several push-based SIP Request Methods are capable (and applicable) of carrying location, including: INVITE, REGISTER, UPDATE, and MESSAGE, While the authors do not yet see a reason to have location conveyed in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a reason to prevent carrying a PIDF-LO within these Method Requests as long as the SIP message meets the requirements stated within this document. Discussing Location in the PUBLISH Request Method will be for another document. This document is under WG control, the contents have nothing to do with the authors vision!! 27) Section 4.1: 1st para: delete "and IANA registers" as superfluous and change "is to be used" to "can be used" 28) Suggest using lower case throughout, including initial letter, for the name of the option-tag. 29) Section 4.1, table of headers needs a table number. As it follows the conventions of RFC 3261 (as indicated by reference), it should have an empty space under the "where" column. However see other technical comments about appearance in responses. 30) Section 4.2, delete the words "a new 4XX level error is created here", as this is totally obvious from the rest of the words. 31) Section 9. Delete "4xx error" before "response code" regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 20:11:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYUK-0004hv-PZ; Mon, 03 Jul 2006 20:10:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYUJ-0004fi-Ki for sip@ietf.org; Mon, 03 Jul 2006 20:09:59 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxYUI-0005ry-7T for sip@ietf.org; Mon, 03 Jul 2006 20:09:59 -0400 Received: from [131.161.248.87] (open-131-161-248-87.cliq.com [131.161.248.87]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k6409nF08300; Mon, 3 Jul 2006 17:09:49 -0700 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F027D0E28@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F027D0E28@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <21886403f5020c456b8e17d7c3e60a50@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Mon, 3 Jul 2006 17:09:54 -0700 To: X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Erkki, The only time a UAC sends a STUN request as directed by outbound -04 is when the URI in the outbound-proxy-set includes the keepalive=stun parameter. This is 100% backwards safe. We don't need any text to prevent existing implementations from getting a bunch of STUN requests. That DHCP does not provide URI is a limitation of the SIP DHCP configuration mechanism, not outbound. The same problem exists for the "comp" parameter for example. If you want to write a draft on how to "shift-up" to using keepalives or using compression from some SIP or external stimulus, you can still do this. No text in outbound prevents that from happening. thanks, -rohan On Jun 29, 2006, at 23:10, wrote: > > Hi Rohan, > >>> Also, the issue is that what may be configured (no matter how you >>> configure it) may not be a URI. It may simply be an IP address/FQDN, >>> which is then used to build a SIP-URI. I think we shall >>> allow that, and make it more clear in the spec. [/CHH] >> >> the outbound spec defines a piece of configurable data (the >> 'outbound-proxy-set'), which is a list of URIs. This list of URIs may >> never have a one-to-one correspondence to a user or administrator >> manually configurable field. That piece of configurable data may be >> derived from several fields, manually configurable, discovered via >> DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP >> download, or via a random character generator seeded by the phase of >> the moon. >> >> The outbound-proxy-set was defined as a list of URIs because the UA >> acts on each item in the list, because each URI is expected to be >> places in a Route header, and because each URI is expected to >> typically have a keepalive URI parameter in it. > > Like mentioned in other recent emails the problem is that if the UA > derives the proxy URI(s) from DHCP SIP server option or e.g. the AOR > of the user, in those cases the derived URI will NOT contain the > keepalive URI parameter in it. DHCP just returns IP addresses or > domain names instead of URIs with parameters. > > Thus in those cases it would be critical for the UA to be able > to ensure in REGISTER - 200 OK sequence that the contacted proxy > supports Outbound and can handle STUN requests sent to its SIP > port (not to cause any damage to an uncompliant proxy). I fully > agree with this proposal from Jeroen: > > -- > The text should then say "the UAC MUST wait for a 200 OK to REGISTER > before > it starts sending STUN packets. If the last Path header of the 200 OK > does > not contain keepalive=stun, the UAC MUST NOT use STUN towards this URI. > If > there are no Path headers and no "Supported: outbound", the UAC also > MUST > NOT use STUN towards the registrar.". It could still use TCP keepalive > if it > supports that > -- > > Please excuse me if I am just repeating myself and what e.g. Jeroen > has said but I believe the importance of this issue justifies some > redundancy :-) > > Regards, > > Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 21:31:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxZjS-0000D6-GA; Mon, 03 Jul 2006 21:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxZjR-0000CR-6D for sip@ietf.org; Mon, 03 Jul 2006 21:29:41 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxZVD-0002NJ-R3 for sip@ietf.org; Mon, 03 Jul 2006 21:15:01 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20060704011458m1100au5cpe>; Tue, 4 Jul 2006 01:14:58 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k641Ev0A026919 for ; Mon, 3 Jul 2006 21:14:57 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k641Ev4h026915; Mon, 3 Jul 2006 21:14:57 -0400 Date: Mon, 3 Jul 2006 21:14:57 -0400 Message-Id: <200607040114.k641Ev4h026915@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1151955580.2892.102.camel@sukothai.pingtel.com> (slawrence@pingtel.com) X-Spam-Score: 0.2 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [Sip] draft-ietf-sip-hop-limit-diagnostics-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm thinking it would be a Good Thing to define a Content-Disposition value for the message/sipfrag to unambiguously tag its purpose. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 23:20:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxbQX-0002uo-RO; Mon, 03 Jul 2006 23:18:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxbQW-0002uj-SY for sip@ietf.org; Mon, 03 Jul 2006 23:18:16 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxbQT-0006TG-Nz for sip@ietf.org; Mon, 03 Jul 2006 23:18:16 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 03 Jul 2006 20:18:13 -0700 X-IronPort-AV: i="4.06,202,1149490800"; d="scan'208"; a="302852367:sNHT40127206" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k643ICPg012892; Mon, 3 Jul 2006 20:18:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k643ICIs026566; Mon, 3 Jul 2006 20:18:12 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Jul 2006 20:18:12 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.97.19]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Jul 2006 20:18:11 -0700 Message-Id: <4.3.2.7.2.20060703184731.03349500@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Jul 2006 22:17:42 -0500 To: "Drage, Keith (Keith)" , sip@ietf.org From: "James M. Polk" In-Reply-To: <475FF955A05DD411980D00508B6D5FB0134D263D@en0033exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 04 Jul 2006 03:18:11.0353 (UTC) FILETIME=[7AB7B890:01C69F18] DKIM-Signature: a=rsa-sha1; q=dns; l=26115; t=1151983092; x=1152847092; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20Comments=20on=20draft-ietf-sip-location-conveyance-03; X=v=3Dcisco.com=3B=20h=3DUGJEUjaQ4VUlUwCmsc887nqltw8=3D; b=380yrUi1W9DfC7rTv+QoAwrFQge9nq+hli0HaP5PzxByAVG09xShw/qKR3pBxrfNdTIm6e8m 7zFGM3cWMyawKV80o5H84KbUtI9S7VjaZZIa1JgdYy0uzeuPOSr1MPQG; Authentication-Results: sj-dkim-5.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 8a7d7b1ff9fdb39b8762b25bc5367e56 Cc: Subject: [Sip] Re: Comments on draft-ietf-sip-location-conveyance-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 11:51 PM 7/3/2006 +0100, Drage, Keith (Keith) wrote: Keith in-line >I have the following comments on the above draft: > >Structural >---------- > >1) Abstract: From reading the document, it is clear that presence >systems are not covered at all in this document for various reasons. >Therefore PUBLISH, SUBSCRIBE and NOTIFY are essentially out of scope. It >seems to me that this should be made much more explicit in the abstract. The first line of the abstact states: "This document defines how the Session Initiation Protocol (SIP) conveys, or pushes, geographic location information from one SIP entity to another SIP entity." Since SUB/NOT is not a "push" form of transaction, I believe this satisfies what you are looking for. I admit I do not call out each of the 14 Methods that this extension does affect, but I rarely see this done in any SIP document, so I didn't know it was necessary here. For example RFC 4538 doesn't say in the abstract it is only used in INVITE, SUB and NOT, and not all the others. Section 4 clearly states that this extension can be used in SUB and NOT, but this is out of scope for this document because they are pull based transactions. Section 4 also states that PUB is out of scope. >2) The SIP extension guidelines (RFC 4485) need to be applied to this >document, which requires some substantial restructuring. I believe this will only result in section 4 and 5 being modified, and not any other section (structurally - unless the reqs are moved to an appendix) >The absence of application of these rules mean that the requirements of >the document are extremely unclear. For example RFC 4485 states (section 4.5): > > Developers of protocols often get caught up in syntax issues, without > spending enough time on semantics. The semantics of a protocol are > far more important. SIP extensions MUST clearly define the semantics > of the extensions. Specifically, the extension MUST specify the > behaviors expected of a UAC, UAS, and proxy in processing the > extension. This is often best described by having separate sections > for each of these three elements. Each section SHOULD step through > the processing rules in temporal order of the most common messaging > scenario. > >Absence of this application means that in places in this document it is >impossible to determine whether a requirement and its required support >occurs as the sender of the location information, or the receiver of the >location information. This document is written almost exclusively as a UAC pov extension, since it, by definition, is what is "conveying" location. Thus, little about this document is about a UAS, save a line that discusses that element can response with location. A little bit more of this doc discusses what a proxy does with this extension, with most of the original material from past version removed, to be put into ECRIT documents. I will make element operation wrt this extension much more explicit in the next rev. >3) Section 1 (and possibly section 2) should be redrafted taking into >account RFC 4485 section 4.7: > > Too often, extension documents dive into detailed syntax and > semantics without giving a general overview of operation. This makes > understanding of the extension harder. It is RECOMMENDED that > extensions have a protocol overview section that discusses the basic > operation of the extension. Basic operation usually consists of the > message flow, in temporal order, for the most common case covered by > the extension. This document, per a conversation between you, me and Dean, in Dallas, is to include the requirements for this extension in the front of the document, and not deleted or put in an appendix. This is due to this document origin as a SIPPING Requirements document. This means I have to get to the requirements section, which is section 3. This means I cannot get into the classic "Basic Operation" until the section after that - Section 4. Section 4 states it is a Basic Operation section at the top of the third paragraph, followed by the two basic message flows (Figure 1 and 2). Perhaps I should have called the section "Basic Operation of SIP Location Conveyance" instead of "Location Conveyance Using SIP". I will fix this in the next rev. But section 4 is what you are looking for per RFC 4485 section 4.7. >The most important processing rules for the elements > in the call flow SHOULD be mentioned. they are >Usage of the RFC 2119 [1] > terminology in the overview section is NOT RECOMMENDED, and the > specification should explicitly state that the overview is tutorial > in nature only. I do need to work on this. This will be addressed in the next rev. There is a good segway in section 4 right now, I just didn't divide that point into a new section - but I will now. >This section SHOULD expand all acronyms, even those > common in SIP systems, and SHOULD be understandable to readers who > are not SIP experts. I believe it does >[27] provides additional guidance on writing > good overview sections. > >I found this text much too wordy, and considered that it should be >possibly to convey the necessary information to the reader in about half >the length. "this text" meaning exactly what text? Section 1, Section 2 or both? I think section 1 is discussing scenarios that offer unique ideas about location conveyance, and what is going into which section. Section 2 has more words than it probably should. >4) Section 3 need to have all the RFC 2119 language removed (see >history-info and outbound as examples). Section 3 is only requirements, and you said in Dallas they stay where they are because this ID stated as a Reqs only doc in SIPPING, so I'm confused as to which you want. >I remain open as to whether it appears at the start of the document, as >here and in history-info, or at the end, as in outbound, but given the >length, we may want to consider moving it to the end. Again, this is where you said to keep them (in Dallas), so I did. Are you changing your mind? If so, given that you hadn't told me prior to after the document deadline, I'm not surprised I didn't do it another way. That said, I can move the reqs to an appendix, and mention this is where they are in section 1. >5) Section 6 should probably follow immediately on from the >procedures in the bulk of section 4, and probably be split as in comment >2) above. Based on what you said above, I agree that section 4 and 5 will be modified. >6) Section 7 should be integrated into the main procedures text. hmm... I think calling out how this SIP extension complies with RFC 3693 in its own section is appropriate (readers can see this glaring at them in the TOC), but it doesn't make sense until the extension is explained, which would be hard to undertand before section 5. >Technical >--------- > >7) Section 1, of the three examples given in this introduction, item >2) is out of scope. I had to read an awful lot of text to discover that fact. I disagree. Think of the REGISTER request, in which a Registrar responds with different information based on where the UAC is. I have a couple of IDs in another WG that take this usage and run with it: http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-server-uri-00.txt http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency-dialstring-00.txt http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-during-registration-00.txt >8) Section 2, 1st paragraph. Probably not appropriate to use the term >"trust model". That term is defined in RFC 3324 and RFC 3325, and I am not >convinced the usage here is one and the same. Should I use "e2e trust" vs. non-e2e trust"? 3325 talks about the UAS trusting the Proxy to assert the PAI is accurate about the UAC. Here, this is from the UAC's pov, and making a decision based on where it believes the information will be used (only at the destination UAS, or by a proxy to use for message routing based on where the UAC is). This seems like a model; either e2e or used by an intermediary to get the message to the right endpoint. Any suggestions? >9) Section 2, 3rd para. > > No routing of the request based on the location contents is required > in this case, therefore no SIP Proxies between these two UAs need to > view the location information contained in the SIP message(s). The > UAC should know certain types of messages will be routed based on > the UA's location when creating a message. > >Did not understand what this paragraph is meant to be telling me - can you >explain it. yes In the previous paragraphs it was concluded by the UAC no help was needed in the network, from a location conveyance pov, to find the destination UAS, therefore merely sending location in the message body was enough. The forth paragraph continues this train of thought stating RFC 3261 does not allow message bodies to be modified or deleted, and if a UAC wants location to be conveyed confidentially, it needs to employ an encryption mechanism (S/MIME). Paragraphs 2, 3 and 4 could be a single, larger paragraph - but I broke it up. Perhaps that was a mistake. >10) Section 3.1 UAC-4: This is not a generic requirement as it is >already identified that certain methods are outside the scope of this document. This allows Location to be included in other SIP Requests (than those listed above this requirement). Without this requirement, table 2 and 3 would be pretty empty (with only INVITE dialog related requests with an 'o', and everything else having a '-', meaning not allowed, and the doc states that 'some other Request MAY include location, but the authors do not see a reason for this at this time'. >11) Section 3.1 UAC-9, UAC-10: I assume this is specified this way so >that misconfiguration releases the location rather than hides it. that's what UAC-9 is for, also if the first INVITE hid location, but a subsequent message (after recieving a 424) doesn't want to hide it to make sure this isn't the reason the message didn't get through. UAC-10 allows for a user to "not" include location during an emergency call. We already know of places that have this law on the books. >I believe this contravenes the regulatory requirements of some countries. Yes, and in those jurisdictions, that's an configuration issue, not a protocol issue. My mobile phone needs to be able to roam between a jurisdiction that has such a law, and one that doesn't. >I believe in Japan privacy requirements are more important that the >transmission of the information for emergency calls. If someone from Japan >was writing these requirements they would therefore indicate exactly the >opposite. Again, this is an configuration issue. There are places where the user has no choice in the matter, other places the user has a choice. >12) Section 3.2 UAS-6 and section 3.3 Proxy-4. Firstly this is halfway >into implementation. Secondly if it is required to address location errors >in requests, why is the same consideration not given to location errors in >responses. Are you asking if there is an error in a SIP response? How do you address that anytime? Basically, I'm not understanding your question/comment 12. Can you rephrase? >13) Section 3.3 Proxy-1: This merely repeats RFC 3261, rather than >developing a new requirement. Fair - it does. I guess this was to remind readers of this. It should be removed. >14) Section 3.3 Proxy-3: This seems to be rewriting the requirements >to correspond to the solution. I disagree. We have a problem in that there is no indicator of who generated a PIDF-LO (by-value or by-reference). This is very real. This requirement is stating that if there already is location in a message, not to add to the confusion factor if you can help it. >I understand the problem is that the solution cannot distinguish between >multiple locations, nor understand the reliability, and therefore a >receiver may get confused. Firstly this does not seem to me to be a SIP >issue, and secondly in general the ability to transport multiple locations >could be regarded as useful - they just need some form of assertion as to >who provided which location. but there is no form of assertion now... so what do we do, ignore the problem as it is today? >15) Section 4 and elsewhere. I don't find location in responses well >described at all. I state that " Bob MAY choose to include his location in a response back to Alice." Otherwise, I don't get into this other than it must obey the PIDF-LO format and privacy mechanisms of a request. >It seems to be an afterthought, rather than something that is decided >based on a full set of requirements. I have already made a comment with >regard to requirements on error handling. Should we support location in >response, or force the UAS to generate a request of its own in order to >send a location? fair question - I'm guess I'm ok with saying Location Conveyance is only in requests, but I didn't see the harm in Location being in a 200 OK to a request that had location in it. Guidance/opinions welcome >16) Section 4. Should the instances of "URI" here be "URN". I take URNs to be services (like urn:services:sos), and URIs to be records on a remote node to be accessed. Based on that, I think locations are URIs, of which, a URL is a subset. >17) Section 4 specifies: > > Because a person's location is generally considered to be sensitive > in nature, certain security measures need to be taken into account > when transmitting such information. Section 26 of [RFC3261] defines > the security functionality SIPS for transporting SIP messages with > either TLS or IPSec, and S/MIME for encrypting message bodies from > SIP intermediaries that would otherwise have access to reading the > clear-text bodies. SIP endpoints SHOULD implement S/MIME to encrypt > the PIDF-LO message body (part) end-to-end. The SIPS-URI from > [RFC3261] MUST be implemented for message protection (message > integrity and confidentiality) and SHOULD be used when S/MIME is not > used. > > The entities sending and receiving location MUST obey the privacy > and security rules in the PIDF-LO, regarding retransmission and > retention, to be compliant with this specification. > > Self-signed certificates SHOULD NOT be used for protecting PIDF-LO, > as the sender does not have a secure identity of the recipient. > >However RFC 4119 is already normatively referenced which contains the >following text: > > For the purposes of this document, only the securing of a PIDF > document as a whole, rather than element-by-element security, is > considered. None of the requirements [10] suggest that only part of > the information in a location object might need to be protected while > other parts are unprotected; virtually any such configuration would > introduce potentials for privacy leakage. Consequently, the use of > MIME-level security is appropriate. > > S/MIME [5] allows security properties (including confidentiality, > integrity, and authentication properties) to be applied to the > contents of a MIME body. Therefore, all PIDF implementations that > support the XML Schema extensions for location information described > in this document MUST support S/MIME; in particular, they MUST > support the CMS [6] EnvelopedData and SignedData content types, which > are used for encryption and digital signatures, respectively. It is > believed that this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3, > and 14.4. > > Additionally, all compliant applications MUST implement the AES > encryption algorithm for S/MIME, as specified in [8] (and per REQ > 15.1). Of course, implementations MUST also support the baseline > encryption and digital signature algorithms described in the S/MIME > specification. > > S/MIME generally entails the use of X.509 [9] certificates. In order > to encrypt a request for a particular destination end-to-end (i.e., > to a Location Recipient), the Location Generator must possess > credentials (typically an X.509 certificate) that have been issued to > the Location Recipient. Implementations of this specification SHOULD > support X.509 certificates for S/MIME, and MUST support password- > based CMS encryption (see [6]). Any symmetric keying systems SHOULD > derive high-entropy content encoding keys (CEKs). When X.509 > certificates are used to sign PIDF Location Objects, the > subjectAltName of the certificate SHOULD use the "pres" URI scheme. > >Which set of text takes precedence? I don't see the conflict. Can you point any such conflict out? Is it the SHOULD vs. MUST implement S/MIME? If so, I'll change this ID back to MUST implement. >18) Section 4: > > More than one location representation or format MAY be included in > the same message body part, but all MUST point at the same position > on the earth (altitude not withstanding), as this would confuse the > recipient by pointing at more than one position within the same > message body part. There MAY be a case in which part or parts of > one location format and part or parts of another format exist in the > same message body part. These complementary pieces of information > MUST point at the same position on the earth, yet are incomplete > within their own format. For example, there maybe be a latitude and > longitude in coordinate format and a civic altitude value to > complete a 3-dimensional position of a thing (i.e. which floor of a > building the UA is on in a building at a particular lat/long > coordinates pair). > >Not sure what "altitude not withstanding" means, particular as this is a >RFC 2119 MUST sentence. It means with or without, it makes no difference. There are 4000 datums. Some in 2D, and others in 3D. WGS84 has both. There is a movement in Geopriv to have coordinate format location only provide 2D and a civic format provide altitude within the same element of the PIDF-LO. This statement is regarding during times where civic is not supported, or a altitude is not available, consider the 2D location to be enough information to present location by. >Additionally, the paragraph repeats the essence of the "same position on >the earth" in two separate MUST statements. I'll work on that, I was attempting to cover a separate angle of the same meaning. >19) Section 4: > > There MAY be more than one PIDF-LO in the same SIP message, but each > in separate message body parts. Each location body part MAY point at > different positions on the earth (altitude not withstanding). If > the message length exceeds the maximum message length of a single > packet (1300 bytes), TCP MUST to be used for proper message > fragmentation and reassembly. > >Why is the final sentence stronger than RFC 3261. I assume your thinking >is emergency calls, but that is only one of the uses of this document. And >surely if emergency calls is the problem, then the requirement has to be >made as an update to RFC 3261 for all emergency calls, not just those that >happen to carry location. hmmm... so this is a problem. I hadn't made that distinction wrt 3261 language. If I change this to a SHOULD, will that be acceptable? >20) Section 4: > > Several push-based SIP Request Methods are capable (and applicable) > of carrying location, including: > > INVITE, > REGISTER, > UPDATE, and > MESSAGE, > > While the authors do not yet see a reason to have location conveyed > in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a > reason to prevent carrying a PIDF-LO within these Method Requests as > long as the SIP message meets the requirements stated within this > document. Discussing Location in the PUBLISH Request Method will be > for another document. > >The draft seems to go to a great deal of effort to ensure the information >is carried end to end, but then suggests that the information might be >entrusted to non end-to-end messages. Maybe I'm missing where a message other than 100 Trying is not end2end. Certainly all requests are intended to be e2e. >I would suggest that the header and body are declared out of scope for ACK >and CANCEL. I can modify the above to state 'we do not see the point/reason of including location in either ACK or CANCEL'. >21) Section 4: > > A 200 OK to a SIP Request MAY carry the UAS's PIDF-LO back to the > UAC that provided its location in the original request, but this is > not something that can be required due to the timing of the request > to 200 OK messages, with potential local/user policy requiring the > called user to get involved in determining if the caller is someone > they wish to give their location to (and at what precision). > >I don't understand what this is trying to convey. Please explain? A 200 OK can carry Location back to the UAC; however, this cannot be an expected operation due to the user of the UAS possibly needing to get included in whether or not to include their location to the user of the UAC. This delay may be based on who the UAC user is. This could greatly delay call set-up, and delay sending of any response message to the UAC. Or, the UAS user may have a policy to let certain offerers know the UAS's location if they match certain rules within the request (i.e. are on a buddy list). I'm finding this answer to be awkward, but I feel something needs to be said here that a UAS may or may not response with location, based on some rule match in the request. suggestions are welcome. >22) Section 4.1: > > It is envisioned that HTTP, through the http_URL in [RFC216], and > HTTPS [RFC2818] MAY be used to dereference a location-by-reference > PIDF-LO. > >Do we place any requirement to support HTTP at any location receiver, so >that location by reference when received actually works? JDR got on me about lacking a means to dereference a location-by-reference. Since I don't believe we need another lame usage for SIP INFO, I thought we'd suggest that HTTP would be a good fetching protocol for a PIDF-LO not locally stored. What should I do here, change the BNF locationURI = absoluteURI / cidURI to locationURI = http_url / https_url / absoluteURI / cidURI or add a requirement in section 3 that receivers of a location by reference URI be able to use HTTP/HTTPS to dereference the PIDF-LO? >23) Is it not sufficient to say that RFC 2119 applies, and therefore >the security considerations of RFC 2119 applies. I do not understand this comment. Can you be more verbose? >NITS >---- > >24) Section 3.1 UAC-8: As by-reference doesn't carry the PIDF-LO >within SIP, but within HTTP, the text is wrong. I think within a by-value message body, it is within SIP. If I understand your point above (about 2 inches), you think this requirement needs to change where it states location by-reference within HTTP/HTTPS, correct? >25) Can we consistently use "request" or "response" rather than >"message" following RFC 3261 terminology? fair point. I will change all transactions to requests and responses. >26) Section 4: > > Several push-based SIP Request Methods are capable (and applicable) > of carrying location, including: > > INVITE, > REGISTER, > UPDATE, and > MESSAGE, > > While the authors do not yet see a reason to have location conveyed > in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a > reason to prevent carrying a PIDF-LO within these Method Requests as > long as the SIP message meets the requirements stated within this > document. Discussing Location in the PUBLISH Request Method will be > for another document. > >This document is under WG control, the contents have nothing to do with >the authors vision!! OK, and this usage of pov is quite prevelent in documents. Nonetheless, I will change it to omit author's visions. >27) Section 4.1: 1st para: delete "and IANA registers" this comes from an old correction made by an AD (who said to always say this if a doc registers anything), but I will remove it >as superfluous and change "is to be used" to "can be used" ack >28) Suggest using lower case throughout, including initial letter, for >the name of the option-tag. For the option-tag, I thought I had - but I will make sure of this. Location wrt the header needs to be upper case though (correct still?). >29) Section 4.1, table of headers needs a table number. ack >As it follows the conventions of RFC 3261 (as indicated by reference), it >should have an empty space under the "where" column. my mistake >However see other technical comments about appearance in responses. > >30) Section 4.2, delete the words "a new 4XX level error is created >here", as this is totally obvious from the rest of the words. ack >31) Section 9. Delete "4xx error" before "response code" ack >regards > >Keith > >Keith Drage >drage@lucent.com >tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 03 23:41:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxbkp-0000Lt-Vj; Mon, 03 Jul 2006 23:39:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxbkp-0000Lo-Az for sip@ietf.org; Mon, 03 Jul 2006 23:39:15 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxbkn-0007pi-Qi for sip@ietf.org; Mon, 03 Jul 2006 23:39:15 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 50E24222426 for ; Mon, 3 Jul 2006 20:47:22 -0700 (PDT) To: sip@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Mon, 03 Jul 2006 20:39:12 -0700 From: Eric Rescorla Message-Id: <20060704034722.50E24222426@laser.networkresonance.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [Sip] Review of draft-ietf-sip-connected-identity-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org BACKGROUND SIP allows "retargeting" in which the endpoints (on either end) of a call can change. So, for instance, Alice might be calling Bob but actually get forwarded to Charlie. This draft describes a mechanism for the new endpoint to notify their peer that their identity is not the same as the peer expected. BASIC MESSAGE FLOW The basic message flow without this draft looks something like this: Alice Proxy Carol ----- ----- ----- INVITE (To=Bob) -> INVITE (To=Bob) -> <- OK (To=Bob) <- OK (To=Bob) ACK (To=Bob) -> ACK (To=Bob) -> This draft adds a new set of messages for Carol to tell Alice about the retargeting. Like this: Alice Proxy Carol ----- ----- ----- INVITE (To=Bob) -> INVITE (To=Bob) -> <- OK (To=Bob) <- OK (To=Bob) ACK (To=Bob) -> ACK (To=Bob) -> <- UPDATE (From=Carol) <- UPDATE (From=Carol) ACK (From=Carol) -> ACK (From=Carol) -> SECURITY ISSUES This draft relies on the ordinary SIP authentication mechanisms (primarily Identity, I would imagine) in order to validate the update message. Unfortunately, this just tells the other side that they're now talking to someone new securely. They have no way of determining whether the retargeting was authorized or not. This is explicitly acknowledged in the Security Considerations section. Clearly something along these lines is needed. Perhaps it could go in a different draft, but this does seem like the obvious one. EDITORIAL 1. I found this document fairly hard to read until I figured out what was going on, perhaps due to my lack of familiarity with SIP. ISTM that a diagram like the one above would be appropriate here--some diagram definitely seems advisable. 2. It would be helpful to have unique and distinctive terms for the UA that isn't being retargeted (Alice above) and the one that is (Bob/Carol). I found myself trying to figure that out. These terms should be called out explicitly early on. S 3. You should explicitly state that To doesn't change during retargeting. That is an unobvious behavior of SIP. I think some diagrams of these scenarios would help. The following paragraph is a good example of what I mean above about distinctive terms: However, call re-arrangements are not always carried out using a new INVITE request. Sometimes a B2BUA performs call re-arrangements using third party call control (3PCC) techniques. With such techniques the UA involved in the original call and still involved in the re-arranged call receives only a re-INVITE or UPDATE request in the context of the original dialog between that UA and the B2BUA. This forces the UA to re-negotiate the session with the new remote party, but introduces a need to convey the identity of the new remote party to the UA. Because there is no new INVITE request (outside the context of the existing dialog), techniques applicable to new calls do not apply. "the UA involved in the original call and still involved in the re-arranged call" is too long to process as one chunk. S 4. It should be made clear that this is background material that will be used later. It's not an alternative to the current approach, which I kind of got the impression from "Existing". It would probably halp to name these mechanisms in some easy to remember way. I'm sure they already have names.... S 6.2. Just for clarity, you don't need to send an UPDATE/re-INVITEif you don't support id-change. So, the peers already need to be able to deal with a non-UPDATE-sending situation, right? So, I'm not sure I understandw hy you need to send the UPDATE/re-INVITE if nothing has changed... 7.2. There is a very bad break in this table. The headers need to be on the same page as the columns. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 04 02:56:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxeo8-0002OP-R3; Tue, 04 Jul 2006 02:54:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxekt-0001lK-Cy for sip@ietf.org; Tue, 04 Jul 2006 02:51:31 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxeZ6-00089I-4t for sip@ietf.org; Tue, 04 Jul 2006 02:39:24 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k646dIvM026684; Tue, 4 Jul 2006 09:39:18 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 09:39:18 +0300 Received: from [172.21.35.95] ([172.21.35.95]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 Jul 2006 09:39:17 +0300 Message-ID: <44AA0D15.6080208@nokia.com> Date: Tue, 04 Jul 2006 09:39:17 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] Comments on draft-koivusalo-sip-outbound-discovery-02 References: <475FF955A05DD411980D00508B6D5FB0134D2624@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0134D2624@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jul 2006 06:39:17.0874 (UTC) FILETIME=[92ECB520:01C69F34] X-Spam-Score: 1.1 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: sip@ietf.org, erkki.koivusalo@nokia.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Keith, Erkki: To answer your first question, I believe this draft updates RFC 3263. And with respect your third question, I agree that the draft does not consider the case when Outbound is not deployed, so the text has to be updated to reflect the case. I have also a couple of other non-nit comments. 1) I think the draft has to be a bit more strict on where this draft ends and when Outbound begins. At the moment I found this line quite fuzzy. Assuming this draft is about discovery, but not execution of the outbound procedures, I believe requirement REQ-OUTB-DISC-6 has not much to do with discovery, but with outbound. The same applies to several paragraphs in Section 5, when the draft describes actions taken upon a reception of a 200 response for a REGISTER request. 2) The first paragraph in Section 2.4.4 suggests that a non-standardized autodiscovery mechanism will require the UA to insert a "Proxy-Require: outbound". Care must be taken to avoid that this becomes the de-facto behavior. It must noted that such Proxy-Require will require each of the proxies en route to the registrar to support outbound, which might not be the desired behavior. I would suggest to add some more text describing this case and highlighting the problem. 3) IANA: something is not clear to me. Is this draft creating a new registry (as it suggest Sections 4 and 7), named "Registry for the NAPTR Resource Record Services Fiedl", or is it updating the existing registry at http://www.iana.org/assignments/sip-table I thought it would be the latter, but the fact that the existing registry refers to SRV records rather than NAPTR makes me doubt. Can someone clarify? BR, Miguel Drage, Keith (Keith) wrote: > Technical: > ---------- > > 1) I need to understand whether this updates RFC 3263 or just extends it. Part of this is what appears on the cover page and in the RFC index as and when it is finally approved, but the other part also relates to compatibility, see later comment. > > 2) I think you have already acknowledged this, but the document requires revision to align with the terminology in the latest version (-04) of draft-ietf-sip-outbound. > > 3) In section 5, as far as I understand, the NAPTR request is identical for a UA that supports RFC 3263 and for one that supports this extension. Therefore the difference is in the response. Therefore the paragraph of UA requirements: > > As per RFC 2915 [4], the client discards any NAPTR records whose > services fields are not applicable. A client resolving a SIPS URI > MUST discard any services that do not contain "SIPS-O" as the > protocol in the service field. A client resolving a SIP URI MUST > retain records with "SIP-O" and the transport protocols the client > supports and SHOULD retain records with "SIPS-O", if the client > supports TLS. > > must work with a NAPTR response that has no knowledge of outbound. Is the above paragraph compatible with this? > > Additionally note that the words "if the client supports TLS" are superfluous. As RFC 3261 requires support of TLS, we are not documenting capabilities where TLS is not supported. > > regards > > Keith > > Keith Drage > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 04 06:52:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxiUE-0000Ow-GT; Tue, 04 Jul 2006 06:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxiUB-0000Oo-Vm for sip@ietf.org; Tue, 04 Jul 2006 06:50:31 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxiUA-0004Gk-5c for sip@ietf.org; Tue, 04 Jul 2006 06:50:31 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k64AoKKO005512; Tue, 4 Jul 2006 13:50:21 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 13:50:20 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 13:50:19 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Tue, 4 Jul 2006 13:50:19 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> In-Reply-To: <21886403f5020c456b8e17d7c3e60a50@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on Outbound? Thread-Index: Acae/jsZE0nv3f5GTdiVBIfeMzXOiAAUFn+g From: To: X-OriginalArrivalTime: 04 Jul 2006 10:50:19.0839 (UTC) FILETIME=[A48E2CF0:01C69F57] X-Spam-Score: 0.2 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: fluffy@cisco.com, sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, Sorry to be persistent with this issue, but what you say seems to conflict with what was discussed in March. > The only time a UAC sends a STUN request as directed by=20 > outbound -04 is when the URI in the outbound-proxy-set=20 > includes the keepalive=3Dstun parameter. That DHCP does not=20 > provide URI is a limitation of the SIP DHCP configuration=20 > mechanism, not outbound. If you want to write a draft on=20 > how to "shift-up" to using keepalives from some SIP or=20 > external stimulus, you can still do this. What you say seems to suggest that you agree there is a problem when using DHCP SIP server option (as it is currently defined) for finding out if the discovered proxy supports outbound and STUN keepalives, but the solution is not in scope of Outbound draft itself.=20 However I came to a different understanding based on the emails seen in the list earlier. For instance this email from Dean Willis (SIP WG chair) seems to suggest that the problem should be in scope of the outbound draft: http://www1.ietf.org/mail-archive/web/sip/current/msg13667.html "Ok, I think we've boiled this down to a new requirement: for the "outbound" technique to work, we MUST have a means of=20 discovering whether a proxy supports the extensions of outbound. While we could do that by doing a REGISTER exchange that includes=20 an appropriate option-tag in Require:, it would be more efficient=20 if the proxy discovery mechanism informed us of this detail. So,=20 we posit that the Outbound draft SHOULD select and discuss such a=20 mechanism." And in yet another email http://www1.ietf.org/mail-archive/web/sip/current/msg13692.html Dean tells this: "There are two ways we can establish compatibility with an extensions: 1) By foreknowledge 2) By experimentation -- try it and see if it works. Both have limitations: In the case of #1, we might have incorrect knowledge. So we'll probably end up testing anyhow . . . In the case of #2, the experiment might cause a meltdown. So the "probe for discovery" must be made completely safe. Also, we can eventually end up with so many wierd hooks and idiosyncratic implementations that we end up doing a BUNCH of probing before we do any real communicating. And it's possible for the conditions to deteriorate so much that probes for two different possible conditions are mutually exclusive -- if one condition applies, the probe for another will cause a meltdown. So what happens if we start STUN-probing a proxy on its SIP port and it doesn't support STUN? My guess is, it's random.=20 ... One approach to "forward compatibility" design is to make sure that we can use both foreknowledge and experimentation -- the "trust but verify" model. ... While it's easy to decide whether a configured registrar URI has a keepalive parameter, what happens to proxies we select based on something besides direct configuration? Specifically, 1) Can the DHCP option for default proxy present the keepalive parameter?" ---- During these three months after seeing those comments in the list I have been expecting the outbound draft to provide answer to the question how UA could (within SIP signalling exchange) safely to check whether or not a proxy supports STUN keepalive. Two mechanims have been suggested how the UA could do this in a simple way: 1. The UA to check that the Path header in 200 OK returned for REGISTER would contain keepalive=3Dstun parameter for the proxy URI 2. The UA to add Proxy-Reequire: stun-keepalive parameter into the REGISTER request and the proxy to remove this tag from the request before forwarding it towards the registrar For me, any of those mechanisms would sound feasible and for safety reasons I would hope the draft to deny the UA for sending STUN keepalives to the proxy which did not pass such a test. > the same problem exists for the "comp" parameter for example.=20 Yes but please bear in mind that for comp=3Dsigcomp URI parameter RFC 3486 Compressing SIP gives several solutions how the UA would be able to check if the proxy supports SigComp while outbound does not define any other than relying on configuration.=20 A cite from RFC 3486: 4.1 Obtaining a SIP or SIPS URI with comp=3Dsigcomp For requests within a dialog, a next-hop URI with the comp=3Dsigcomp parameter is obtained from a Record-Route header field when the dialog is established. A client sending a request outside a dialog can also obtain SIP URIs with comp=3Dsigcomp in a Contact header = field in a 3xx or 485 response to the request. However, clients establishing a session will not typically be willing to wait until the dialog is established in order to begin compressing messages. One of the biggest gains that SigComp can bring to SIP is the ability to compress the initial INVITE of a dialog, when the user is waiting for the session to be established. Therefore, clients need a means to obtain a comp=3Dsigcomp URI from their outbound proxy before the user decides to establish a session. One solution to this problem is manual configuration. However, sometimes it is necessary to have clients configured in an automatic fashion. Unfortunately, current mechanisms for SIP client configuration (e.g., using DHCP [6]) do not allow to provide the client with URI parameters. In this case, the client SHOULD send an uncompressed OPTIONS request to its outbound proxy. The outbound proxy can provide an alternative SIP URI with the comp=3Dsigcomp parameter in a Contact header field in a 200 OK response to the OPTIONS. The client can use this URI for subsequent requests that are sent through the same outbound proxy using compression. RFC 3261 [1] does not define how a proxy should respond to an OPTIONS request addressed to itself. It only describes how servers respond to OPTIONS addressed to a particular user. Section 11.2 of RFC 3261 says: Contact header fields MAY be present in a 200 (OK) response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user. We extend this behavior to proxy servers responding to OPTIONS addressed to them. They MAY list a set of alternative URIs to contact the proxy. What has been called for is that outbound draft would also=20 specify one solution how the UA could check the STUN keepalive support of a proxy. In my opinion good proposals seem to exist how to do it in a reasonable way. Regards, Erkki >-----Original Message----- >From: ext Rohan Mahy [mailto:rohan@ekabal.com]=20 >Sent: 04.July.2006 03:10 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: dean.willis@softarmor.com; fluffy@cisco.com; Rohan Mahy;=20 >sip@ietf.org; jbemmel@zonnet.nl >Subject: Re: [Sip] Ready for WGLC on Outbound? > >Hi Erkki, > >The only time a UAC sends a STUN request as directed by=20 >outbound -04 is=20 >when the URI in the outbound-proxy-set includes the keepalive=3Dstun=20 >parameter. This is 100% backwards safe. We don't need any text to=20 >prevent existing implementations from getting a bunch of STUN requests. > >That DHCP does not provide URI is a limitation of the SIP DHCP=20 >configuration mechanism, not outbound. The same problem=20 >exists for the=20 >"comp" parameter for example. If you want to write a draft on how to=20 >"shift-up" to using keepalives or using compression from some SIP or=20 >external stimulus, you can still do this. No text in outbound=20 >prevents=20 >that from happening. > >thanks, >-rohan > > >On Jun 29, 2006, at 23:10, wrote: >> >> Hi Rohan, >> >>>> Also, the issue is that what may be configured (no matter how you >>>> configure it) may not be a URI. It may simply be an IP=20 >address/FQDN, >>>> which is then used to build a SIP-URI. I think we shall >>>> allow that, and make it more clear in the spec. [/CHH] >>> >>> the outbound spec defines a piece of configurable data (the >>> 'outbound-proxy-set'), which is a list of URIs. This list=20 >of URIs may >>> never have a one-to-one correspondence to a user or administrator >>> manually configurable field. That piece of configurable data may be >>> derived from several fields, manually configurable, discovered via >>> DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP >>> download, or via a random character generator seeded by the phase of >>> the moon. >>> >>> The outbound-proxy-set was defined as a list of URIs because the UA >>> acts on each item in the list, because each URI is expected to be >>> places in a Route header, and because each URI is expected to >>> typically have a keepalive URI parameter in it. >> >> Like mentioned in other recent emails the problem is that if the UA >> derives the proxy URI(s) from DHCP SIP server option or e.g. the AOR >> of the user, in those cases the derived URI will NOT contain the >> keepalive URI parameter in it. DHCP just returns IP addresses or >> domain names instead of URIs with parameters. >> >> Thus in those cases it would be critical for the UA to be able >> to ensure in REGISTER - 200 OK sequence that the contacted proxy >> supports Outbound and can handle STUN requests sent to its SIP >> port (not to cause any damage to an uncompliant proxy). I fully >> agree with this proposal from Jeroen: >> >> -- >> The text should then say "the UAC MUST wait for a 200 OK to REGISTER >> before >> it starts sending STUN packets. If the last Path header of the 200 OK >> does >> not contain keepalive=3Dstun, the UAC MUST NOT use STUN=20 >towards this URI. >> If >> there are no Path headers and no "Supported: outbound", the UAC also >> MUST >> NOT use STUN towards the registrar.". It could still use TCP=20 >keepalive >> if it >> supports that >> -- >> >> Please excuse me if I am just repeating myself and what e.g. Jeroen >> has said but I believe the importance of this issue justifies some >> redundancy :-) >> >> Regards, >> >> Erkki > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 04 12:01:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxnJD-0008Rv-DA; Tue, 04 Jul 2006 11:59:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxnJC-0008Rq-9A for sip@ietf.org; Tue, 04 Jul 2006 11:59:30 -0400 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxnJB-0007dY-0L for sip@ietf.org; Tue, 04 Jul 2006 11:59:30 -0400 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 65D3F1CC22 for ; Tue, 4 Jul 2006 08:58:45 -0700 (PDT) To: sip@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Tue, 04 Jul 2006 08:58:45 -0700 From: EKR Message-Id: <20060704155845.65D3F1CC22@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Because TLS is used in SIP in hop-by-hop mode, the cipher suite that you negotiate with your first hop proxy is no guarantee of what will be negotiated with future proxies. Consider the classic trapezoid: Atlanta ---------------------- Biloxi / \ / \ / \ alice@atlanta bob@biloxi Alice can negotiate AES-256 with Atlanta but then have Atlanta negotiate RC4-40 with Biloxi. This draft suggests a series of extensions to SIP to carry the initial client's preferences and that proxies further down the chain are expected to enforce. It seems to me that there is a simpler mechanism: any proxy X can only offer the intersection of the cipher suites that was offered to it and the ciphersuites that it is willing to support. This has the result that no downstream proxy can negotiate a cipher suite that Alice wasn't willing to negotiate with Atlanta. There are two obvious disadvantages with respect to the proposed draft: 1. Alice doesn't get any signal of what was eventually negotiated. I would solve this problem by extending Via (I'm actually surprised this isn't done). MTAs typically put it in Received lines, FWIW... 2. It's less expressive. In particular, the downstream cipher suites always narrow and never grow. So, if there were a third proxy in between Atlanta and Biloxi that only spoke DES, then Biloxi and Bob would only get DES even if they both spoke AES. Based on my experience with what real implementations support and the MUST for AES, I'm not much concerned about this. It's generally impossible to pickle the full client policy and have it sent to a proxy. It's mostly a matter of where you draw the line, and drawing it where the protocol already draws it seems natural. The big advantage of the approach I propose is that it doesn't require any new mechanisms and can be incrementally deployed in an interoperable way. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 04 12:23:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxnf1-0002lW-M5; Tue, 04 Jul 2006 12:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxney-0002ir-S8 for sip@ietf.org; Tue, 04 Jul 2006 12:22:00 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxnex-0001IX-JF for sip@ietf.org; Tue, 04 Jul 2006 12:22:00 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 91ECD1E8C1F; Tue, 4 Jul 2006 09:21:58 -0700 (PDT) To: sip@ietf.org Subject: Re: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 References: <20060704155845.65D3F1CC22@delta.rtfm.com> From: Eric Rescorla Date: Tue, 04 Jul 2006 09:21:58 -0700 In-Reply-To: <20060704155845.65D3F1CC22@delta.rtfm.com> (ekr@networkresonance.com's message of "Tue, 04 Jul 2006 08:58:45 -0700") Message-ID: <86veqd5oih.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Oh, one more note. This draft claims: An obvious inference of this statement is that SIP allows use of different cipher suites at each hop along the path. At the worst, SIP doesn't forbid the use of TLS_NULL_WITH_NULL_NULL ciphersuite for the SIPS URI scheme also. This is explicitly forbidden by TLS. TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS connection during the first handshake on that channel, but must not be negotiated, as it provides no more protection than an unsecured connection. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 04 12:33:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxnoO-0002wV-Ot; Tue, 04 Jul 2006 12:31:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxnoN-0002wQ-Lh for sip@ietf.org; Tue, 04 Jul 2006 12:31:43 -0400 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxnoM-0001sk-Ay for sip@ietf.org; Tue, 04 Jul 2006 12:31:43 -0400 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id ADAC41CC22 for ; Tue, 4 Jul 2006 09:30:58 -0700 (PDT) To: sip@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Tue, 04 Jul 2006 09:30:58 -0700 From: EKR Message-Id: <20060704163058.ADAC41CC22@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Sip] Comments on draft-gurbani-sip-domain-certs-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It seems to me that this document addresses two issues: 1. What name(s) should appear in certificates. 2. Where they should appear and how they should be encoded. I'd like to separate these two, on the theory that (1) is difficult and (2) is bit-mangling. Let's take a step back and examine first principles: The basic assumption behind RFC 2818 (and most other uses of TLS) is that you start with some URI X that you want to dereference. Through some series of (untrusted) manipulations you end up with a connection to some endpoint which presents you a certificate C. You then need to determine whether X matches C. In order for this process to work properly, X needs to either contain C or there needs to be some trusted transformation between C and X. In the Web context, what this means is that if you have a server farm with A.example.com, B.example.com, C.example.com, etc. then they all have certificates containing "www.example.com". This can either be done via key-sharing or can be done by issuing them separate certificates that all contain the same domain name ("www.example.com"). ISTM that the same situation needs to apply with SIP. If you're dereferencing then the certificate presented to you needs to either be for a known (and trusted!) proxy or contain "atlanta.com". Anything else requires trusting the DNS resolution process, which isn't generally considered acceptable. So, this leaves us with the question of whether there should be multiple names. As I understand S 10, the claimed disadvantages of a single name are: 1. It does not correspond to common TLS usage, which is to use a certificate identifying the host. If proxy.biloxi.com is allowed to require that the subject of the certificate contains a DNS entry corresponding to the IP address of proxy1.atlanta.com, then this in turn requires every authoritative proxy for atlanta.com to be registered with the DNS entry atlanta.com. Hence it is impossible for a domain to use different SIP proxies as incoming and outgoing proxies. 2. It makes forensics in the case of compromise more complex. If a malicious principal is discovered making use of a certificate for a private key issued to proxy1.atlanta.com, there is little to identify which of atlanta.com's SIP proxies has been compromised. If the certificate contains proxy1.atlanta.com's name as well as atlanta.com's name, then the forensics are simpler. I'm not sure what "common TLS usage" is being referred to. As I noted above, in my experience HTTPS behaves exactly this way (putting the generic domain name and not host name in the certificate). I agree that it does make forensics more difficult, but this problem can be solved iwth a separate certificate (with a separate serial #) for each host, even if they contain the same name. There's no need for a second name here. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 04 14:45:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxprl-0006Bv-Ss; Tue, 04 Jul 2006 14:43:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxprl-0006Bq-1N for sip@ietf.org; Tue, 04 Jul 2006 14:43:21 -0400 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxprj-0005lw-Op for sip@ietf.org; Tue, 04 Jul 2006 14:43:21 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k64IhIS5026170; Tue, 4 Jul 2006 13:43:18 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3G53QJV7>; Tue, 4 Jul 2006 19:43:17 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0134D2788@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Drage, Keith (Keith)'" , "'sip@ietf.org'" Subject: RE: [Sip] Comments on draft-koivusalo-sip-outbound-discovery-02 Date: Tue, 4 Jul 2006 19:43:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 1.1 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: "'erkki.koivusalo@nokia.com'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org With regard to > Additionally note that the words "if the client supports TLS" > are superfluous. As RFC 3261 requires support of TLS, we are > not documenting capabilities where TLS is not supported. > It has been pointed out that UAC support is only SHOULD strength in RFC 3261 therefore the extra words are appropriate. regards Keith > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 03 July 2006 20:12 > To: sip@ietf.org > Cc: erkki.koivusalo@nokia.com > Subject: [Sip] Comments on draft-koivusalo-sip-outbound-discovery-02 > > > Technical: > ---------- > > 1) I need to understand whether this updates RFC 3263 or just > extends it. Part of this is what appears on the cover page > and in the RFC index as and when it is finally approved, but > the other part also relates to compatibility, see later comment. > > 2) I think you have already acknowledged this, but the > document requires revision to align with the terminology in > the latest version (-04) of draft-ietf-sip-outbound. > > 3) In section 5, as far as I understand, the NAPTR request is > identical for a UA that supports RFC 3263 and for one that > supports this extension. Therefore the difference is in the > response. Therefore the paragraph of UA requirements: > > As per RFC 2915 [4], the client discards any NAPTR records whose > services fields are not applicable. A client resolving a SIPS URI > MUST discard any services that do not contain "SIPS-O" as the > protocol in the service field. A client resolving a SIP URI MUST > retain records with "SIP-O" and the transport protocols the client > supports and SHOULD retain records with "SIPS-O", if the client > supports TLS. > > must work with a NAPTR response that has no knowledge of > outbound. Is the above paragraph compatible with this? > > Additionally note that the words "if the client supports TLS" > are superfluous. As RFC 3261 requires support of TLS, we are > not documenting capabilities where TLS is not supported. > > regards > > Keith > > Keith Drage > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 04 16:39:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxre6-0000J9-UI; Tue, 04 Jul 2006 16:37:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxre5-0000J4-56 for sip@ietf.org; Tue, 04 Jul 2006 16:37:21 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxre4-0008HP-CZ for sip@ietf.org; Tue, 04 Jul 2006 16:37:21 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 04 Jul 2006 13:37:20 -0700 X-IronPort-AV: i="4.06,205,1149490800"; d="scan'208"; a="1835063320:sNHT36414712" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k64KbJq3003511; Tue, 4 Jul 2006 13:37:19 -0700 Received: from [192.168.1.2] (sjc-vpn4-557.cisco.com [10.21.82.45]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k64KbIIs003033; Tue, 4 Jul 2006 13:37:18 -0700 (PDT) In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Tue, 4 Jul 2006 13:37:16 -0700 To: "" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=12957; t=1152045439; x=1152909439; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Ready=20for=20WGLC=20on=20Outbound?; X=v=3Dcisco.com=3B=20h=3D1VcSVj375TL2bhrMjADUoyQBi6Y=3D; b=iuYbD6DyylklDMnHoPPibHfMECZO4f11abU9fAl67d1UixYHPir+td1s/E4hKYKBpi7EOriL OS5LGbGn9fG88CDoj9/sjMdhh6LYhWmtFQ8JbuDDrvvPsXEWdxgyT5PK; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Cc: sip@ietf.org, rohan@ekabal.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think people have stopped posting on this because they can't say anything that they have not already said. Don't take that as they agree. We got very strong feed back on one point - don't send STUN messages to a proxy unless you know it supports them. People felt strongly about that - I don't know why - but there was lots of people that agreed with that. I imagine people have sent me around 10 options on how to get the stun supported information and the set of outbound proxy URIs - certainly DNS and DHCP are some of them. We can write some drafts on various ways to do it. Right now my concern is making sure that no matter which of these many ways the WG decided to move forward with, outbound will work. So far every one of the possibilities I have heard would be possible with the current outbound. Given that, I'm not sure what we need to change in outbound. I'm not even sure what you are proposing that we change in outbound - I think what you are proposing is we need to hold up outbound until we choose which one of the 10 we will use and furthermore you feel very strongly on which one of the 10 we should use. I'm not keen on this - I think we have shown they are separable problems. The WG decided on this separation of problems awhile back - I think it was in Vancouver - and many people supported it. I think it was a good idea - we have shown we can move outbound forward before we have determined all the ways that this configuration information is delivered to the UA. I would be very hesitant to reverse this decision now. I don't think Dean's posts were sent as decries of the requirements from the chair but purely as his opinion in trying to help bring the discussion to consensus. But I do think the draft meets the requirements and ideas he was outlining - I think the current draft does meet the requirements he outlines. It does have a way for the "discovering whether a proxy supports the extensions of outbound" and on the topic of "there are two ways we can establish compatibility with an extensions", the WG rejected option 2 and we have gone with 1. Cullen (with my outbound author hat on) On Jul 4, 2006, at 3:50 AM, wrote: > > Hi Rohan, > > Sorry to be persistent with this issue, but what you say > seems to conflict with what was discussed in March. > >> The only time a UAC sends a STUN request as directed by >> outbound -04 is when the URI in the outbound-proxy-set >> includes the keepalive=stun parameter. That DHCP does not >> provide URI is a limitation of the SIP DHCP configuration >> mechanism, not outbound. If you want to write a draft on >> how to "shift-up" to using keepalives from some SIP or >> external stimulus, you can still do this. > > What you say seems to suggest that you agree there is a problem > when using DHCP SIP server option (as it is currently defined) > for finding out if the discovered proxy supports outbound and > STUN keepalives, but the solution is not in scope of Outbound > draft itself. > > However I came to a different understanding based on the emails > seen in the list earlier. For instance this email from Dean > Willis (SIP WG chair) seems to suggest that the problem should > be in scope of the outbound draft: > http://www1.ietf.org/mail-archive/web/sip/current/msg13667.html > > "Ok, I think we've boiled this down to a new requirement: > > for the "outbound" technique to work, we MUST have a means of > discovering whether a proxy supports the extensions of outbound. > > While we could do that by doing a REGISTER exchange that includes > an appropriate option-tag in Require:, it would be more efficient > if the proxy discovery mechanism informed us of this detail. So, > we posit that the Outbound draft SHOULD select and discuss such a > mechanism." > > And in yet another email > http://www1.ietf.org/mail-archive/web/sip/current/msg13692.html > Dean tells this: > > "There are two ways we can establish compatibility with an extensions: > > 1) By foreknowledge > 2) By experimentation -- try it and see if it works. > > Both have limitations: > > In the case of #1, we might have incorrect knowledge. So we'll > probably > end up testing anyhow . . . > > In the case of #2, the experiment might cause a meltdown. So the > "probe > for discovery" must be made completely safe. Also, we can > eventually end > up with so many wierd hooks and idiosyncratic implementations that we > end up doing a BUNCH of probing before we do any real > communicating. And > it's possible for the conditions to deteriorate so much that probes > for > two different possible conditions are mutually exclusive -- if one > condition applies, the probe for another will cause a meltdown. > > So what happens if we start STUN-probing a proxy on its SIP port > and it > doesn't support STUN? My guess is, it's random. > > ... > > One approach to "forward compatibility" design is to make sure that we > can use both foreknowledge and experimentation -- the "trust but > verify" > model. > > ... > > While it's easy to decide whether a configured registrar URI has a > keepalive parameter, what happens to proxies we select based on > something besides direct configuration? > > Specifically, > > 1) Can the DHCP option for default proxy present the keepalive > parameter?" > ---- > > During these three months after seeing those comments in the list > I have been expecting the outbound draft to provide answer to > the question how UA could (within SIP signalling exchange) > safely to check whether or not a proxy supports STUN keepalive. > Two mechanims have been suggested how the UA could do this in > a simple way: > > 1. The UA to check that the Path header in 200 OK returned for > REGISTER would contain keepalive=stun parameter for the proxy URI > > 2. The UA to add Proxy-Reequire: stun-keepalive parameter into > the REGISTER request and the proxy to remove this tag from > the request before forwarding it towards the registrar > > For me, any of those mechanisms would sound feasible and for > safety reasons I would hope the draft to deny the UA for sending > STUN keepalives to the proxy which did not pass such a test. > >> the same problem exists for the "comp" parameter for example. > > Yes but please bear in mind that for comp=sigcomp URI parameter > RFC 3486 Compressing SIP gives several solutions how the UA > would be able to check if the proxy supports SigComp while > outbound does not define any other than relying on configuration. > A cite from RFC 3486: > > 4.1 Obtaining a SIP or SIPS URI with comp=sigcomp > > For requests within a dialog, a next-hop URI with the comp=sigcomp > parameter is obtained from a Record-Route header field when the > dialog is established. A client sending a request outside a dialog > can also obtain SIP URIs with comp=sigcomp in a Contact header > field > in a 3xx or 485 response to the request. > > However, clients establishing a session will not typically be > willing > to wait until the dialog is established in order to begin > compressing > messages. One of the biggest gains that SigComp can bring to > SIP is > the ability to compress the initial INVITE of a dialog, when the > user > is waiting for the session to be established. Therefore, clients > need a means to obtain a comp=sigcomp URI from their outbound proxy > before the user decides to establish a session. > > One solution to this problem is manual configuration. However, > sometimes it is necessary to have clients configured in an > automatic > fashion. Unfortunately, current mechanisms for SIP client > configuration (e.g., using DHCP [6]) do not allow to provide the > client with URI parameters. In this case, the client SHOULD > send an > uncompressed OPTIONS request to its outbound proxy. The outbound > proxy can provide an alternative SIP URI with the comp=sigcomp > parameter in a Contact header field in a 200 OK response to the > OPTIONS. The client can use this URI for subsequent requests that > are sent through the same outbound proxy using compression. > > RFC 3261 [1] does not define how a proxy should respond to an > OPTIONS > request addressed to itself. It only describes how servers respond > to OPTIONS addressed to a particular user. Section 11.2 of RFC > 3261 > says: > > Contact header fields MAY be present in a 200 (OK) response and > have the same semantics as in a 3xx response. That is, they may > list a set of alternative names and methods of reaching the > user. > > We extend this behavior to proxy servers responding to OPTIONS > addressed to them. They MAY list a set of alternative URIs to > contact the proxy. > > What has been called for is that outbound draft would also > specify one solution how the UA could check the STUN keepalive > support of a proxy. In my opinion good proposals seem > to exist how to do it in a reasonable way. > > Regards, > > Erkki > >> -----Original Message----- >> From: ext Rohan Mahy [mailto:rohan@ekabal.com] >> Sent: 04.July.2006 03:10 >> To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >> Cc: dean.willis@softarmor.com; fluffy@cisco.com; Rohan Mahy; >> sip@ietf.org; jbemmel@zonnet.nl >> Subject: Re: [Sip] Ready for WGLC on Outbound? >> >> Hi Erkki, >> >> The only time a UAC sends a STUN request as directed by >> outbound -04 is >> when the URI in the outbound-proxy-set includes the keepalive=stun >> parameter. This is 100% backwards safe. We don't need any text to >> prevent existing implementations from getting a bunch of STUN >> requests. >> >> That DHCP does not provide URI is a limitation of the SIP DHCP >> configuration mechanism, not outbound. The same problem >> exists for the >> "comp" parameter for example. If you want to write a draft on how to >> "shift-up" to using keepalives or using compression from some SIP or >> external stimulus, you can still do this. No text in outbound >> prevents >> that from happening. >> >> thanks, >> -rohan >> >> >> On Jun 29, 2006, at 23:10, wrote: >>> >>> Hi Rohan, >>> >>>>> Also, the issue is that what may be configured (no matter how you >>>>> configure it) may not be a URI. It may simply be an IP >> address/FQDN, >>>>> which is then used to build a SIP-URI. I think we shall >>>>> allow that, and make it more clear in the spec. [/CHH] >>>> >>>> the outbound spec defines a piece of configurable data (the >>>> 'outbound-proxy-set'), which is a list of URIs. This list >> of URIs may >>>> never have a one-to-one correspondence to a user or administrator >>>> manually configurable field. That piece of configurable data >>>> may be >>>> derived from several fields, manually configurable, discovered via >>>> DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP >>>> download, or via a random character generator seeded by the >>>> phase of >>>> the moon. >>>> >>>> The outbound-proxy-set was defined as a list of URIs because the UA >>>> acts on each item in the list, because each URI is expected to be >>>> places in a Route header, and because each URI is expected to >>>> typically have a keepalive URI parameter in it. >>> >>> Like mentioned in other recent emails the problem is that if the UA >>> derives the proxy URI(s) from DHCP SIP server option or e.g. the AOR >>> of the user, in those cases the derived URI will NOT contain the >>> keepalive URI parameter in it. DHCP just returns IP addresses or >>> domain names instead of URIs with parameters. >>> >>> Thus in those cases it would be critical for the UA to be able >>> to ensure in REGISTER - 200 OK sequence that the contacted proxy >>> supports Outbound and can handle STUN requests sent to its SIP >>> port (not to cause any damage to an uncompliant proxy). I fully >>> agree with this proposal from Jeroen: >>> >>> -- >>> The text should then say "the UAC MUST wait for a 200 OK to REGISTER >>> before >>> it starts sending STUN packets. If the last Path header of the >>> 200 OK >>> does >>> not contain keepalive=stun, the UAC MUST NOT use STUN >> towards this URI. >>> If >>> there are no Path headers and no "Supported: outbound", the UAC also >>> MUST >>> NOT use STUN towards the registrar.". It could still use TCP >> keepalive >>> if it >>> supports that >>> -- >>> >>> Please excuse me if I am just repeating myself and what e.g. Jeroen >>> has said but I believe the importance of this issue justifies some >>> redundancy :-) >>> >>> Regards, >>> >>> Erkki >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 04 17:36:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxsXn-0006Vm-VD; Tue, 04 Jul 2006 17:34:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxsXm-0006So-Sp for sip@ietf.org; Tue, 04 Jul 2006 17:34:54 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxsXm-0004aP-0i for sip@ietf.org; Tue, 04 Jul 2006 17:34:54 -0400 Received: (qmail 8504 invoked by uid 0); 4 Jul 2006 21:34:46 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 Jul 2006 21:34:46 -0000 Message-ID: <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" , References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Tue, 4 Jul 2006 23:34:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Cc: sip@ietf.org, rohan@ekabal.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen, The point is that these are really 2 separate issues: 1. Discovering the set of outbound proxy URIs (with keepalive=stun parameters in them) 2. Confirming that a given proxy in the set actually supports outbound (ie validating the keepalive=stun information) Of these 2 options, (1) is indeed a separable problem. (2) - to me - is not, for me outbound is not acceptable without something to address (2). It really should say "the UAC MUST NOT use STUN until { mechanism for (2) says its supported }" There have been several options mentioned to do this, a simple way is to have the edge proxy insert a flag. Question is: why not? Regards, Jeroen ----- Original Message ----- From: "Cullen Jennings" To: Cc: ; ; ; Sent: Tuesday, July 04, 2006 10:37 PM Subject: Re: [Sip] Ready for WGLC on Outbound? > > I think people have stopped posting on this because they can't say > anything that they have not already said. Don't take that as they agree. > > We got very strong feed back on one point - don't send STUN messages to a > proxy unless you know it supports them. People felt strongly about that - > I don't know why - but there was lots of people that agreed with that. > > I imagine people have sent me around 10 options on how to get the stun > supported information and the set of outbound proxy URIs - certainly DNS > and DHCP are some of them. We can write some drafts on various ways to do > it. Right now my concern is making sure that no matter which of these > many ways the WG decided to move forward with, outbound will work. So far > every one of the possibilities I have heard would be possible with the > current outbound. Given that, I'm not sure what we need to change in > outbound. I'm not even sure what you are proposing that we change in > outbound - I think what you are proposing is we need to hold up outbound > until we choose which one of the 10 we will use and furthermore you feel > very strongly on which one of the 10 we should use. I'm not keen on > this - I think we have shown they are separable problems. The WG decided > on this separation of problems awhile back - I think it was in > Vancouver - and many people supported it. I think it was a good idea - > we have shown we can move outbound forward before we have determined all > the ways that this configuration information is delivered to the UA. I > would be very hesitant to reverse this decision now. > > I don't think Dean's posts were sent as decries of the requirements from > the chair but purely as his opinion in trying to help bring the > discussion to consensus. But I do think the draft meets the requirements > and ideas he was outlining - I think the current draft does meet the > requirements he outlines. It does have a way for the "discovering whether > a proxy supports the extensions of outbound" and on the topic of "there > are two ways we can establish compatibility with an extensions", the WG > rejected option 2 and we have gone with 1. > > Cullen (with my outbound author hat on) > > > On Jul 4, 2006, at 3:50 AM, > wrote: > >> >> Hi Rohan, >> >> Sorry to be persistent with this issue, but what you say >> seems to conflict with what was discussed in March. >> >>> The only time a UAC sends a STUN request as directed by >>> outbound -04 is when the URI in the outbound-proxy-set >>> includes the keepalive=stun parameter. That DHCP does not >>> provide URI is a limitation of the SIP DHCP configuration >>> mechanism, not outbound. If you want to write a draft on >>> how to "shift-up" to using keepalives from some SIP or >>> external stimulus, you can still do this. >> >> What you say seems to suggest that you agree there is a problem >> when using DHCP SIP server option (as it is currently defined) >> for finding out if the discovered proxy supports outbound and >> STUN keepalives, but the solution is not in scope of Outbound >> draft itself. >> >> However I came to a different understanding based on the emails >> seen in the list earlier. For instance this email from Dean >> Willis (SIP WG chair) seems to suggest that the problem should >> be in scope of the outbound draft: >> http://www1.ietf.org/mail-archive/web/sip/current/msg13667.html >> >> "Ok, I think we've boiled this down to a new requirement: >> >> for the "outbound" technique to work, we MUST have a means of >> discovering whether a proxy supports the extensions of outbound. >> >> While we could do that by doing a REGISTER exchange that includes >> an appropriate option-tag in Require:, it would be more efficient >> if the proxy discovery mechanism informed us of this detail. So, >> we posit that the Outbound draft SHOULD select and discuss such a >> mechanism." >> >> And in yet another email >> http://www1.ietf.org/mail-archive/web/sip/current/msg13692.html >> Dean tells this: >> >> "There are two ways we can establish compatibility with an extensions: >> >> 1) By foreknowledge >> 2) By experimentation -- try it and see if it works. >> >> Both have limitations: >> >> In the case of #1, we might have incorrect knowledge. So we'll probably >> end up testing anyhow . . . >> >> In the case of #2, the experiment might cause a meltdown. So the "probe >> for discovery" must be made completely safe. Also, we can eventually end >> up with so many wierd hooks and idiosyncratic implementations that we >> end up doing a BUNCH of probing before we do any real communicating. And >> it's possible for the conditions to deteriorate so much that probes for >> two different possible conditions are mutually exclusive -- if one >> condition applies, the probe for another will cause a meltdown. >> >> So what happens if we start STUN-probing a proxy on its SIP port and it >> doesn't support STUN? My guess is, it's random. >> >> ... >> >> One approach to "forward compatibility" design is to make sure that we >> can use both foreknowledge and experimentation -- the "trust but verify" >> model. >> >> ... >> >> While it's easy to decide whether a configured registrar URI has a >> keepalive parameter, what happens to proxies we select based on >> something besides direct configuration? >> >> Specifically, >> >> 1) Can the DHCP option for default proxy present the keepalive >> parameter?" >> ---- >> >> During these three months after seeing those comments in the list >> I have been expecting the outbound draft to provide answer to >> the question how UA could (within SIP signalling exchange) >> safely to check whether or not a proxy supports STUN keepalive. >> Two mechanims have been suggested how the UA could do this in >> a simple way: >> >> 1. The UA to check that the Path header in 200 OK returned for >> REGISTER would contain keepalive=stun parameter for the proxy URI >> >> 2. The UA to add Proxy-Reequire: stun-keepalive parameter into >> the REGISTER request and the proxy to remove this tag from >> the request before forwarding it towards the registrar >> >> For me, any of those mechanisms would sound feasible and for >> safety reasons I would hope the draft to deny the UA for sending >> STUN keepalives to the proxy which did not pass such a test. >> >>> the same problem exists for the "comp" parameter for example. >> >> Yes but please bear in mind that for comp=sigcomp URI parameter >> RFC 3486 Compressing SIP gives several solutions how the UA >> would be able to check if the proxy supports SigComp while >> outbound does not define any other than relying on configuration. >> A cite from RFC 3486: >> >> 4.1 Obtaining a SIP or SIPS URI with comp=sigcomp >> >> For requests within a dialog, a next-hop URI with the comp=sigcomp >> parameter is obtained from a Record-Route header field when the >> dialog is established. A client sending a request outside a dialog >> can also obtain SIP URIs with comp=sigcomp in a Contact header field >> in a 3xx or 485 response to the request. >> >> However, clients establishing a session will not typically be willing >> to wait until the dialog is established in order to begin compressing >> messages. One of the biggest gains that SigComp can bring to SIP is >> the ability to compress the initial INVITE of a dialog, when the user >> is waiting for the session to be established. Therefore, clients >> need a means to obtain a comp=sigcomp URI from their outbound proxy >> before the user decides to establish a session. >> >> One solution to this problem is manual configuration. However, >> sometimes it is necessary to have clients configured in an automatic >> fashion. Unfortunately, current mechanisms for SIP client >> configuration (e.g., using DHCP [6]) do not allow to provide the >> client with URI parameters. In this case, the client SHOULD send an >> uncompressed OPTIONS request to its outbound proxy. The outbound >> proxy can provide an alternative SIP URI with the comp=sigcomp >> parameter in a Contact header field in a 200 OK response to the >> OPTIONS. The client can use this URI for subsequent requests that >> are sent through the same outbound proxy using compression. >> >> RFC 3261 [1] does not define how a proxy should respond to an OPTIONS >> request addressed to itself. It only describes how servers respond >> to OPTIONS addressed to a particular user. Section 11.2 of RFC 3261 >> says: >> >> Contact header fields MAY be present in a 200 (OK) response and >> have the same semantics as in a 3xx response. That is, they may >> list a set of alternative names and methods of reaching the user. >> >> We extend this behavior to proxy servers responding to OPTIONS >> addressed to them. They MAY list a set of alternative URIs to >> contact the proxy. >> >> What has been called for is that outbound draft would also >> specify one solution how the UA could check the STUN keepalive >> support of a proxy. In my opinion good proposals seem >> to exist how to do it in a reasonable way. >> >> Regards, >> >> Erkki >> >>> -----Original Message----- >>> From: ext Rohan Mahy [mailto:rohan@ekabal.com] >>> Sent: 04.July.2006 03:10 >>> To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >>> Cc: dean.willis@softarmor.com; fluffy@cisco.com; Rohan Mahy; >>> sip@ietf.org; jbemmel@zonnet.nl >>> Subject: Re: [Sip] Ready for WGLC on Outbound? >>> >>> Hi Erkki, >>> >>> The only time a UAC sends a STUN request as directed by >>> outbound -04 is >>> when the URI in the outbound-proxy-set includes the keepalive=stun >>> parameter. This is 100% backwards safe. We don't need any text to >>> prevent existing implementations from getting a bunch of STUN requests. >>> >>> That DHCP does not provide URI is a limitation of the SIP DHCP >>> configuration mechanism, not outbound. The same problem >>> exists for the >>> "comp" parameter for example. If you want to write a draft on how to >>> "shift-up" to using keepalives or using compression from some SIP or >>> external stimulus, you can still do this. No text in outbound >>> prevents >>> that from happening. >>> >>> thanks, >>> -rohan >>> >>> >>> On Jun 29, 2006, at 23:10, wrote: >>>> >>>> Hi Rohan, >>>> >>>>>> Also, the issue is that what may be configured (no matter how you >>>>>> configure it) may not be a URI. It may simply be an IP >>> address/FQDN, >>>>>> which is then used to build a SIP-URI. I think we shall >>>>>> allow that, and make it more clear in the spec. [/CHH] >>>>> >>>>> the outbound spec defines a piece of configurable data (the >>>>> 'outbound-proxy-set'), which is a list of URIs. This list >>> of URIs may >>>>> never have a one-to-one correspondence to a user or administrator >>>>> manually configurable field. That piece of configurable data may be >>>>> derived from several fields, manually configurable, discovered via >>>>> DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP >>>>> download, or via a random character generator seeded by the phase of >>>>> the moon. >>>>> >>>>> The outbound-proxy-set was defined as a list of URIs because the UA >>>>> acts on each item in the list, because each URI is expected to be >>>>> places in a Route header, and because each URI is expected to >>>>> typically have a keepalive URI parameter in it. >>>> >>>> Like mentioned in other recent emails the problem is that if the UA >>>> derives the proxy URI(s) from DHCP SIP server option or e.g. the AOR >>>> of the user, in those cases the derived URI will NOT contain the >>>> keepalive URI parameter in it. DHCP just returns IP addresses or >>>> domain names instead of URIs with parameters. >>>> >>>> Thus in those cases it would be critical for the UA to be able >>>> to ensure in REGISTER - 200 OK sequence that the contacted proxy >>>> supports Outbound and can handle STUN requests sent to its SIP >>>> port (not to cause any damage to an uncompliant proxy). I fully >>>> agree with this proposal from Jeroen: >>>> >>>> -- >>>> The text should then say "the UAC MUST wait for a 200 OK to REGISTER >>>> before >>>> it starts sending STUN packets. If the last Path header of the 200 OK >>>> does >>>> not contain keepalive=stun, the UAC MUST NOT use STUN >>> towards this URI. >>>> If >>>> there are no Path headers and no "Supported: outbound", the UAC also >>>> MUST >>>> NOT use STUN towards the registrar.". It could still use TCP >>> keepalive >>>> if it >>>> supports that >>>> -- >>>> >>>> Please excuse me if I am just repeating myself and what e.g. Jeroen >>>> has said but I believe the importance of this issue justifies some >>>> redundancy :-) >>>> >>>> Regards, >>>> >>>> Erkki >>> >>> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 04 18:32:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxtQ5-0005SC-Ok; Tue, 04 Jul 2006 18:31:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxtQ4-0005S7-0Y for sip@ietf.org; Tue, 04 Jul 2006 18:31:00 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxtQ1-0001Y3-L4 for sip@ietf.org; Tue, 04 Jul 2006 18:30:59 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k64MUsH01820; Tue, 4 Jul 2006 18:30:54 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Date: Tue, 4 Jul 2006 17:30:50 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D0574CB@zrc2hxm2.corp.nortel.com> In-Reply-To: <20060704155845.65D3F1CC22@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Thread-Index: Acafgu/vTuSyBgw9TcW1IOf0lO0V5AAIvy+A From: "Samir Srivastava" To: "EKR" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, Thx for your review and detailed comments. Pl find my replies in line below. Thx Samir Because TLS is used in SIP in hop-by-hop mode, the cipher suite that you negotiate with your first hop proxy is no guarantee of what will be negotiated with future proxies. Consider the classic trapezoid: Atlanta ---------------------- Biloxi / \ / \ / \=20 alice@atlanta bob@biloxi Alice can negotiate AES-256 with Atlanta but then have Atlanta negotiate RC4-40 with Biloxi. This draft suggests a series of extensions to SIP to carry the initial client's preferences and that proxies further down the chain are expected to enforce. It seems to me that there is a simpler mechanism: any proxy X can only offer the intersection of the cipher suites that was offered to it and the ciphersuites that it is willing to support. This has the result that no downstream proxy can negotiate a cipher suite that Alice wasn't willing to negotiate with Atlanta.=20 SS>> Here it is assumed that cipher-suite X which is between alice@atlanta and Proxy for atlanta is supported between proxies for biloxi and atlanta. This may not be true. Suppose Proxy for atlanta is upgraded with the latest TLS version, extension, and cipher suites. But proxy for biloxi is not upgraded. In this case we cannot make a secure call. But with the proposal, we can make a call though it will be less secure. The level of security (qValue) is indicated back in the response. There are two obvious disadvantages with respect to the proposed draft: 1. Alice doesn't get any signal of what was eventually negotiated. I would solve this problem by extending Via (I'm actually surprised this isn't done). MTAs typically put it in Received lines, FWIW... SS>> Proposal extends the via to include all TLS security information. Here we agree. 2. It's less expressive. In particular, the downstream cipher suites always narrow and never grow. So, if there were a third proxy in between Atlanta and Biloxi that only spoke DES, then Biloxi and Bob would only get DES even if they both spoke AES. Based on my experience with what real implementations support and the MUST for AES, I'm not much concerned about this. It's generally impossible to pickle the full client policy and have it sent to a proxy. It's mostly a matter of where you draw the line, and drawing it where the protocol already draws it seems natural. SS>> Here if proxy for atlanta has good control over it's network, and it is using less secure cipher-suite (or no-security) in that hop, then as per your proposal it is going to use same less secure cipher-suite all along the path even in open internet where it is crossing provider's boundary, even if edge proxies are supporting the most secure cipher-suites etc. Here it should be noted that upgrading edge proxies is easy, as compared to upgrading every UA within provider's domain with the latest cipher-suite, protocol etc. In your example, If proxies are crossing the provider's boundaries over the open internet, then I would like to have AES in that hop. This cannot be done in your proposal, even if it is supported.=20 The big advantage of the approach I propose is that it doesn't require any new mechanisms and can be incrementally deployed in an interoperable way. SS>> My problem is that current mechanism are not future proof. Suppose down the line current cipher-suites, protocols etc are broken, and we have new cipher-suites etc . Then we will have different cipher-suites in the network, we cannot assume that every SIP entity in the network is upgraded quickly. Proposal caters that with clear indication of security.=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 04 18:37:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxtUR-0005x8-17; Tue, 04 Jul 2006 18:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxtUP-0005wy-Oh for sip@ietf.org; Tue, 04 Jul 2006 18:35:29 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxtUO-0001km-Fa for sip@ietf.org; Tue, 04 Jul 2006 18:35:29 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k64MZPR04157; Tue, 4 Jul 2006 18:35:26 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Date: Tue, 4 Jul 2006 17:35:25 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D0574CD@zrc2hxm2.corp.nortel.com> In-Reply-To: <86veqd5oih.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Thread-Index: AcafhgnfLr8b+Ct8QGOAdGp9CLLoFAAM/Vwg From: "Samir Srivastava" To: "EKR" , X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, Thx for pointing this out. My mistake. Will be fixed in the next version. Thx Samir=20 -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Tuesday, July 04, 2006 9:22 AM To: sip@ietf.org Subject: Re: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Oh, one more note. This draft claims: An obvious inference of this statement is that SIP allows use of different cipher suites at each hop along the path. At the worst, SIP doesn't forbid the use of TLS_NULL_WITH_NULL_NULL ciphersuite for the SIPS URI scheme also. This is explicitly forbidden by TLS. TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS connection during the first handshake on that channel, but must not be negotiated, as it provides no more protection than an unsecured connection. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 04 18:53:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxtk4-0005cA-4W; Tue, 04 Jul 2006 18:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxtk2-0005c5-Er for sip@ietf.org; Tue, 04 Jul 2006 18:51:38 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxtk0-0003qR-UH for sip@ietf.org; Tue, 04 Jul 2006 18:51:38 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id F20711E8C1F; Tue, 4 Jul 2006 15:51:35 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 References: <62B9B0847CC47543B6B3B5E26BD268E60D0574CB@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Tue, 04 Jul 2006 15:51:35 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60D0574CB@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Tue, 4 Jul 2006 17:30:50 -0500") Message-ID: <861wt12dc8.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > SS>> Here it is assumed that cipher-suite X which is between > alice@atlanta and Proxy for atlanta is supported between proxies for > biloxi and atlanta. This may not be true. Suppose Proxy for atlanta is > upgraded with the latest TLS version, extension, and cipher suites. But > proxy for biloxi is not upgraded. In this case we cannot make a secure > call. No, this is incorrect. I didn't say the *selected* cipher suite, I said the intersection of the offered and acceptable. Consider the following case for what various agents support: Alice Atlanta Biloxi ----- ------- ------ AES-SHA AES-SHA 3DES-SHA AES-SHA256 AES-SHA256 AES-SHA In this case, Alice and Atlanta will (most likely) negotiate AES-SHA256. Atlanta will offer AES-SHA and AES-SHA256. Biloxi will select AES-SHA. The only way in which the second hop could fail would be if Atlanta didn't speak AES-SHA, but remember that AES-SHA is a MUST implement. > 2. It's less expressive. In particular, the downstream cipher suites > always narrow and never grow. So, if there were a third proxy in > between Atlanta and Biloxi that only spoke DES, then Biloxi and Bob > would only get DES even if they both spoke AES. Based on my > experience > with what real implementations support and the MUST for AES, I'm not > much concerned about this. It's generally impossible to pickle > the full client policy and have it sent to a proxy. It's mostly > a matter of where you draw the line, and drawing it where the > protocol already draws it seems natural. > > SS>> Here if proxy for atlanta has good control over it's network, and > it is using less secure cipher-suite (or no-security) in that hop, then > as per your proposal it is going to use same less secure cipher-suite > all along the path even in open internet where it is crossing provider's > boundary, even if edge proxies are supporting the most secure > cipher-suites etc. I don't see your point here. You seem to be suggesting that we should deliberately be fostering a mechanism that allows providers to use weak mechanisms inside their internal networks. That doesn't seem like a particularly worthy goal, so I don't see why that merits the amount of extra protocol complexity you want to introduce. > Here it should be noted that upgrading edge proxies > is easy, as compared to upgrading every UA within provider's domain > with the latest cipher-suite, protocol etc. In your example, If proxies > are crossing the provider's boundaries over the open internet, then I > would like to have AES in that hop. This cannot be done in your > proposal, even if it is supported. It would seem easier to simply relax the narrowing constraint I indicated in cases where both ends are under the control of the same operator. This seems a lot simpler than lugging a bunch of policy information around inside your internal network. > The big advantage of the approach I propose is that it doesn't require > any new mechanisms and can be incrementally deployed in an interoperable > way. > > SS>> My problem is that current mechanism are not future proof. Suppose > down the line current cipher-suites, protocols etc are broken, and we > have new cipher-suites etc . Then we will have different cipher-suites > in the network, we cannot assume that every SIP entity in the network is > upgraded quickly. Proposal caters that with clear indication of > security. Can you name an instance in which this has actually happened? But suppose it's true? You just relax the constraint that you need to offer only incoming cipher suites, upgrade your edge proxies, and the problem goes away. The reason not to do that ordinarily is that we don't have an unambigous ordering of cipher suite strengths so we'd like to let the original UA have an opinion but if you *know* that the UA's offered algorithm is broken, I think it's safe to override it. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 04 20:41:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxvQO-0000ff-QO; Tue, 04 Jul 2006 20:39:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxvQN-0000fa-28 for sip@ietf.org; Tue, 04 Jul 2006 20:39:27 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxvQL-0001zZ-O5 for sip@ietf.org; Tue, 04 Jul 2006 20:39:27 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k650dNQ20445 for ; Tue, 4 Jul 2006 20:39:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C69FCB.75A92F0B" Date: Tue, 4 Jul 2006 19:39:20 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0B23FEB3@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-audet-sip-sips-guidelines-02.txt Thread-Index: AcaaIz5/khYAgAW9TfW7ALjWiplN7gFqCEAw From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Sip] FW: I-D ACTION:draft-audet-sip-sips-guidelines-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C69FCB.75A92F0B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another update, including more feedback from the list. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, June 27, 2006 12:50 > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-audet-sip-sips-guidelines-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Guidelines for the use of the SIPS=20 > URI Scheme in the Session Initiation Protocol (SIP) > Author(s) : F. Audet > Filename : draft-audet-sip-sips-guidelines-02.txt > Pages : 24 > Date : 2006-6-27 > =09 > This document provides clarifications and guidelines concerning the > use of SIPS URI Scheme in the Session Initiation Protocol (SIP). >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-audet-sip-sips-guide lines-02.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-audet-sip-sips-guidelines-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-audet-sip-sips-guidelines-02.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C69FCB.75A92F0B Content-Type: application/octet-stream; name="ATT378431.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT378431.TXT Content-Disposition: attachment; filename="ATT378431.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi02LTI3MTE0MTI3LkktREBpZXRmLm9yZz4NCg0KRU5D T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWF1ZGV0LXNpcC1zaXBzLWd1 aWRlbGluZXMtMDIudHh0DQo= ------_=_NextPart_001_01C69FCB.75A92F0B Content-Type: application/octet-stream; name="draft-audet-sip-sips-guidelines-02.URL" Content-Transfer-Encoding: base64 Content-Description: draft-audet-sip-sips-guidelines-02.URL Content-Disposition: attachment; filename="draft-audet-sip-sips-guidelines-02.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1hdWRldC1zaXAtc2lwcy1ndWlkZWxpbmVzLTAyLnR4dA0K ------_=_NextPart_001_01C69FCB.75A92F0B Content-Type: text/plain; name="ATT378432.txt" Content-Transfer-Encoding: base64 Content-Description: ATT378432.txt Content-Disposition: attachment; filename="ATT378432.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C69FCB.75A92F0B Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C69FCB.75A92F0B-- From sip-bounces@ietf.org Tue Jul 04 21:44:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxwPz-0005OT-N5; Tue, 04 Jul 2006 21:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxwPy-0005OI-8X for sip@ietf.org; Tue, 04 Jul 2006 21:43:06 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxwPv-0000CO-Rn for sip@ietf.org; Tue, 04 Jul 2006 21:43:06 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k651h0315973; Tue, 4 Jul 2006 21:43:00 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Date: Tue, 4 Jul 2006 20:42:57 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D0574EA@zrc2hxm2.corp.nortel.com> In-Reply-To: <861wt12dc8.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Thread-Index: AcafvGvqz/UNA+zlTGurtluYLOzeigADnzPA From: "Samir Srivastava" To: "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, Refer the http://www.cryptosystem.net/aes/ . Some points from there are quoted below w.r.t algebraic attacks on it... "Should AES be used ? Most people will answer yes, for now, due to the lack of a better standard. AES remains still millions of times better than many snake oil ciphers you can buy here or there. Moreover, even if AES will be broken in the coming years by a fast algebraic attack, it will probably still remain more secure than DES, and can still safely be used for applications that do not require long term security.=20 However, though AES seems overdesigned with respect to differential or linear cryptanalysis, from the point of view of algebraic attacks, it is an extremely bad cipher. It is rather difficult to imagine a worse cipher, among ciphers that resist to other known attacks... (worse with respect to algebraic attacks). Therefore, even if it turns out that the XSL is NOT faster than the exhaustive search of a 128-bit key, NIST should sooner or later revoke AES. One should not take chances with these things. Another open call for a cryptographic standard will probably be done in the coming years (no need to hurry). " I am not expert on the algebraic attacks, but I sensed the need for openess in SIP from this prespective, as breaking of older crypto algorithm forced to create the new algorithms (AES). IMHO one cannot deny this trend in future. I will appreciate your views on this. More replies inline below. Thx Samir "Samir Srivastava" writes: > SS>> Here it is assumed that cipher-suite X which is between > alice@atlanta and Proxy for atlanta is supported between proxies for=20 > biloxi and atlanta. This may not be true. Suppose Proxy for atlanta is > upgraded with the latest TLS version, extension, and cipher suites.=20 > But proxy for biloxi is not upgraded. In this case we cannot make a=20 > secure call. No, this is incorrect. I didn't say the *selected* cipher suite, I said the intersection of the offered and acceptable. Consider the following case for what various agents support: Alice Atlanta Biloxi ----- ------- ------ AES-SHA AES-SHA 3DES-SHA AES-SHA256 AES-SHA256 AES-SHA In this case, Alice and Atlanta will (most likely) negotiate AES-SHA256. Atlanta will offer AES-SHA and AES-SHA256. Biloxi will select AES-SHA. The only way in which the second hop could fail would be if Atlanta didn't speak AES-SHA, but remember that AES-SHA is a MUST implement. SS>> Fine. It will work in the current state of affairs. Breaking of AES-SHA in future, will need another cipher-suite. Then we fix TLS with that (newer version etc). But SIP doesn't have any knowledge of how much secure hop it is.=20 It is an open issue, how the UAC or proxy preferences of cipher-suites etc will be overidden. My first goal is to have an agreement on the need of this in SIP. UAC needs to have the knowledge with what level of security, it is able to reach UAS. IMHO, Level of Security cannot be compared with other features of underlying protocols. Without being having a guranteed level of security, I cannot share senstive info. There is no such indication in SIP. This level of security can be upgraded (At UAC and UAS) when SRTP key negotiation etc is done and media is guranteed to secure also. > 2. It's less expressive. In particular, the downstream cipher suites > always narrow and never grow. So, if there were a third proxy in > between Atlanta and Biloxi that only spoke DES, then Biloxi and Bob > would only get DES even if they both spoke AES. Based on my > experience=20 > with what real implementations support and the MUST for AES, I'm not > much concerned about this. It's generally impossible to pickle > the full client policy and have it sent to a proxy. It's mostly > a matter of where you draw the line, and drawing it where the > protocol already draws it seems natural. > > SS>> Here if proxy for atlanta has good control over it's network, and > it is using less secure cipher-suite (or no-security) in that hop, then > as per your proposal it is going to use same less secure cipher-suite > all along the path even in open internet where it is crossing provider's > boundary, even if edge proxies are supporting the most secure > cipher-suites etc. I don't see your point here. You seem to be suggesting that we should deliberately be fostering a mechanism that allows providers to use weak mechanisms inside their internal networks. That doesn't seem like a particularly worthy goal, so I don't see why that merits=20 the amount of extra protocol complexity you want to introduce. SS>> This is being inherited from SIPS. Where it doesn't even have TLS in the last hop. I don't like this mechanism, if I am interested in complete ironclad e2e AES (as per the current state of encryption) . But closed walled garden supporters like it, and I don't want to start debate on this. > Here it should be noted that upgrading edge proxies > is easy, as compared to upgrading every UA within provider's domain > with the latest cipher-suite, protocol etc. In your example, If proxies > are crossing the provider's boundaries over the open internet, then I > would like to have AES in that hop. This cannot be done in your > proposal, even if it is supported.=20 It would seem easier to simply relax the narrowing constraint I indicated in cases where both ends are under the control of the same operator. This seems a lot simpler than lugging a bunch of policy information around inside your internal network. SS>> Being at UAC, I don't know in advance how I will be able to reach the UAS. Take the case of retargeting from the another domain's proxy to the UAC domain proxy. The proposal is cleaner w.r.t. all these aspects.=20 > The big advantage of the approach I propose is that it doesn't require > any new mechanisms and can be incrementally deployed in an interoperable > way. > > SS>> My problem is that current mechanism are not future proof. Suppose > down the line current cipher-suites, protocols etc are broken, and we > have new cipher-suites etc . Then we will have different cipher-suites > in the network, we cannot assume that every SIP entity in the network is > upgraded quickly. Proposal caters that with clear indication of > security.=20 Can you name an instance in which this has actually happened? But suppose it's true? You just relax the constraint that you need to offer only incoming cipher suites, upgrade your edge proxies, and the problem goes away. The reason not to do that ordinarily is that we don't have an unambigous ordering of cipher suite strengths so we'd like to let the original UA have an opinion but if you *know* that the UA's offered algorithm is broken, I think it's safe to override it. SS>> Refer the earlier text in the reply. Ordering of strength of cipher-suites etc and overriding is not considered currently. If we are in the agreement that we need a security-level kind of header in SIP, then we can hash it out. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 04 23:31:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxy4j-000228-BV; Tue, 04 Jul 2006 23:29:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxy4h-000221-Hr for sip@ietf.org; Tue, 04 Jul 2006 23:29:15 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxy4g-0004gt-5L for sip@ietf.org; Tue, 04 Jul 2006 23:29:15 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 2327F1E8C1F; Tue, 4 Jul 2006 20:29:13 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 References: <62B9B0847CC47543B6B3B5E26BD268E60D0574EA@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Tue, 04 Jul 2006 20:29:13 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60D0574EA@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Tue, 4 Jul 2006 20:42:57 -0500") Message-ID: <86wtaszq46.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > In this case, Alice and Atlanta will (most likely) negotiate AES-SHA256. > Atlanta will offer AES-SHA and AES-SHA256. Biloxi will select AES-SHA. > The only way in which the second hop could fail would be if Atlanta > didn't speak AES-SHA, but remember that AES-SHA is a MUST implement. > > SS>> Fine. It will work in the current state of affairs. Breaking of > AES-SHA in future, will need another cipher-suite. Then we fix TLS with > that (newer version etc). But SIP doesn't have any knowledge of how much > secure hop it is. Again, that's not true with the scheme I described. Only cipher suites that the first-hop client is willing to negotiate will be negotiated on any hop. Consider the simple case where there is currently only one algorithm X. When a new algorithm Y is introduced (whatever the status of X), if the original UAC only supports X, then there are two possibilities: 1. Every proxy along the path supports X as well as Y. 2. Some proxy along the path only supports Y. Given the algorithm I described, in case 1 you get X (which by definition is OK with the UAC). In case 2, the connection fails somewhere along the line. In neither case can you get a cipher suite that X does not consider acceptable. > SS>> Being at UAC, I don't know in advance how I will be able to reach > the UAS. Take the case of retargeting from the another domain's proxy to > the UAC domain proxy. The proposal is cleaner w.r.t. all these aspects. I don't understand the point you're making here. I'm not talking about the UAC, but about the various proxies inside a single trust domain. > Can you name an instance in which this has actually happened? > > But suppose it's true? You just relax the constraint that you need to > offer only incoming cipher suites, upgrade your edge proxies, > and the problem goes away. The reason not to do that ordinarily > is that we don't have an unambigous ordering of cipher suite > strengths so we'd like to let the original UA have an opinion > but if you *know* that the UA's offered algorithm is broken, > I think it's safe to override it. > > SS>> Refer the earlier text in the reply. Ordering of strength of > cipher-suites etc and overriding is not considered currently. I don't understand this point at all. What I'm saying is that the only reason why you need to consult the UAC's cipher suite preferences at all is that we don't have a single agreed upon ordering of algorithm strengths. If we did, then it would be a simple matter of saying "on outgoing you can negotiate any algorithm as strong or stronger as the one on incoming." However, in the case where the proxy *knows* that the incoming algorithm is broken, then it's safe to negotiate a stronger algorithm even if the client did not offer it. > If we are > in the agreement that we need a security-level kind of header in SIP, > then we can hash it out. I don't agree that we need such a header. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 00:14:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxykU-0006TD-8s; Wed, 05 Jul 2006 00:12:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxykT-0006T4-CB for sip@ietf.org; Wed, 05 Jul 2006 00:12:25 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxykO-0001ng-4K for sip@ietf.org; Wed, 05 Jul 2006 00:12:25 -0400 Received: from [192.168.1.101] (c-67-164-146-154.hsd1.tx.comcast.net [67.164.146.154]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k654AVav035549 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 4 Jul 2006 23:10:40 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Tue, 4 Jul 2006 23:10:28 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 Cc: sip@ietf.org, rohan@ekabal.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've been a bystander, but will jump in here. Comment below: On Jul 4, 2006, at 3:37 PM, Cullen Jennings wrote: > > I think people have stopped posting on this because they can't say > anything that they have not already said. Don't take that as they > agree. > > We got very strong feed back on one point - don't send STUN > messages to a proxy unless you know it supports them. People felt > strongly about that - I don't know why - but there was lots of > people that agreed with that. > > I imagine people have sent me around 10 options on how to get the > stun supported information and the set of outbound proxy URIs - > certainly DNS and DHCP are some of them. We can write some drafts > on various ways to do it. Right now my concern is making sure that > no matter which of these many ways the WG decided to move forward > with, outbound will work. So far every one of the possibilities I > have heard would be possible with the current outbound. Given that, > I'm not sure what we need to change in outbound. I'm not even sure > what you are proposing that we change in outbound - I think what > you are proposing is we need to hold up outbound until we choose > which one of the 10 we will use and furthermore you feel very > strongly on which one of the 10 we should use. I'm not keen on this > - I think we have shown they are separable problems. The WG decided > on this separation of problems awhile back - I think it was in > Vancouver - and many people supported it. I think it was a good > idea - we have shown we can move outbound forward before we have > determined all the ways that this configuration information is > delivered to the UA. I would be very hesitant to reverse this > decision now. I strongly agree with Cullen. We do not need to block the outbound mechanism draft on figuring out the discovery stuff. The separation was a good idea. If for no other reason, it lets us get work done. > > I don't think Dean's posts were sent as decries of the requirements > from the chair but purely as his opinion in trying to help bring > the discussion to consensus. But I do think the draft meets the > requirements and ideas he was outlining - I think the current draft > does meet the requirements he outlines. It does have a way for the > "discovering whether a proxy supports the extensions of outbound" > and on the topic of "there are two ways we can establish > compatibility with an extensions", the WG rejected option 2 and we > have gone with 1. > > Cullen (with my outbound author hat on) > > > On Jul 4, 2006, at 3:50 AM, > wrote: > >> >> Hi Rohan, >> >> Sorry to be persistent with this issue, but what you say >> seems to conflict with what was discussed in March. >> >>> The only time a UAC sends a STUN request as directed by >>> outbound -04 is when the URI in the outbound-proxy-set >>> includes the keepalive=stun parameter. That DHCP does not >>> provide URI is a limitation of the SIP DHCP configuration >>> mechanism, not outbound. If you want to write a draft on >>> how to "shift-up" to using keepalives from some SIP or >>> external stimulus, you can still do this. >> >> What you say seems to suggest that you agree there is a problem >> when using DHCP SIP server option (as it is currently defined) >> for finding out if the discovered proxy supports outbound and >> STUN keepalives, but the solution is not in scope of Outbound >> draft itself. >> >> However I came to a different understanding based on the emails >> seen in the list earlier. For instance this email from Dean >> Willis (SIP WG chair) seems to suggest that the problem should >> be in scope of the outbound draft: >> http://www1.ietf.org/mail-archive/web/sip/current/msg13667.html >> >> "Ok, I think we've boiled this down to a new requirement: >> >> for the "outbound" technique to work, we MUST have a means of >> discovering whether a proxy supports the extensions of outbound. >> >> While we could do that by doing a REGISTER exchange that includes >> an appropriate option-tag in Require:, it would be more efficient >> if the proxy discovery mechanism informed us of this detail. So, >> we posit that the Outbound draft SHOULD select and discuss such a >> mechanism." >> >> And in yet another email >> http://www1.ietf.org/mail-archive/web/sip/current/msg13692.html >> Dean tells this: >> >> "There are two ways we can establish compatibility with an >> extensions: >> >> 1) By foreknowledge >> 2) By experimentation -- try it and see if it works. >> >> Both have limitations: >> >> In the case of #1, we might have incorrect knowledge. So we'll >> probably >> end up testing anyhow . . . >> >> In the case of #2, the experiment might cause a meltdown. So the >> "probe >> for discovery" must be made completely safe. Also, we can >> eventually end >> up with so many wierd hooks and idiosyncratic implementations that we >> end up doing a BUNCH of probing before we do any real >> communicating. And >> it's possible for the conditions to deteriorate so much that >> probes for >> two different possible conditions are mutually exclusive -- if one >> condition applies, the probe for another will cause a meltdown. >> >> So what happens if we start STUN-probing a proxy on its SIP port >> and it >> doesn't support STUN? My guess is, it's random. >> >> ... >> >> One approach to "forward compatibility" design is to make sure >> that we >> can use both foreknowledge and experimentation -- the "trust but >> verify" >> model. >> >> ... >> >> While it's easy to decide whether a configured registrar URI has a >> keepalive parameter, what happens to proxies we select based on >> something besides direct configuration? >> >> Specifically, >> >> 1) Can the DHCP option for default proxy present the keepalive >> parameter?" >> ---- >> >> During these three months after seeing those comments in the list >> I have been expecting the outbound draft to provide answer to >> the question how UA could (within SIP signalling exchange) >> safely to check whether or not a proxy supports STUN keepalive. >> Two mechanims have been suggested how the UA could do this in >> a simple way: >> >> 1. The UA to check that the Path header in 200 OK returned for >> REGISTER would contain keepalive=stun parameter for the proxy URI >> >> 2. The UA to add Proxy-Reequire: stun-keepalive parameter into >> the REGISTER request and the proxy to remove this tag from >> the request before forwarding it towards the registrar >> >> For me, any of those mechanisms would sound feasible and for >> safety reasons I would hope the draft to deny the UA for sending >> STUN keepalives to the proxy which did not pass such a test. >> >>> the same problem exists for the "comp" parameter for example. >> >> Yes but please bear in mind that for comp=sigcomp URI parameter >> RFC 3486 Compressing SIP gives several solutions how the UA >> would be able to check if the proxy supports SigComp while >> outbound does not define any other than relying on configuration. >> A cite from RFC 3486: >> >> 4.1 Obtaining a SIP or SIPS URI with comp=sigcomp >> >> For requests within a dialog, a next-hop URI with the comp=sigcomp >> parameter is obtained from a Record-Route header field when the >> dialog is established. A client sending a request outside a >> dialog >> can also obtain SIP URIs with comp=sigcomp in a Contact header >> field >> in a 3xx or 485 response to the request. >> >> However, clients establishing a session will not typically be >> willing >> to wait until the dialog is established in order to begin >> compressing >> messages. One of the biggest gains that SigComp can bring to >> SIP is >> the ability to compress the initial INVITE of a dialog, when >> the user >> is waiting for the session to be established. Therefore, clients >> need a means to obtain a comp=sigcomp URI from their outbound >> proxy >> before the user decides to establish a session. >> >> One solution to this problem is manual configuration. However, >> sometimes it is necessary to have clients configured in an >> automatic >> fashion. Unfortunately, current mechanisms for SIP client >> configuration (e.g., using DHCP [6]) do not allow to provide the >> client with URI parameters. In this case, the client SHOULD >> send an >> uncompressed OPTIONS request to its outbound proxy. The outbound >> proxy can provide an alternative SIP URI with the comp=sigcomp >> parameter in a Contact header field in a 200 OK response to the >> OPTIONS. The client can use this URI for subsequent requests that >> are sent through the same outbound proxy using compression. >> >> RFC 3261 [1] does not define how a proxy should respond to an >> OPTIONS >> request addressed to itself. It only describes how servers >> respond >> to OPTIONS addressed to a particular user. Section 11.2 of RFC >> 3261 >> says: >> >> Contact header fields MAY be present in a 200 (OK) response and >> have the same semantics as in a 3xx response. That is, they >> may >> list a set of alternative names and methods of reaching the >> user. >> >> We extend this behavior to proxy servers responding to OPTIONS >> addressed to them. They MAY list a set of alternative URIs to >> contact the proxy. >> >> What has been called for is that outbound draft would also >> specify one solution how the UA could check the STUN keepalive >> support of a proxy. In my opinion good proposals seem >> to exist how to do it in a reasonable way. >> >> Regards, >> >> Erkki >> >>> -----Original Message----- >>> From: ext Rohan Mahy [mailto:rohan@ekabal.com] >>> Sent: 04.July.2006 03:10 >>> To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >>> Cc: dean.willis@softarmor.com; fluffy@cisco.com; Rohan Mahy; >>> sip@ietf.org; jbemmel@zonnet.nl >>> Subject: Re: [Sip] Ready for WGLC on Outbound? >>> >>> Hi Erkki, >>> >>> The only time a UAC sends a STUN request as directed by >>> outbound -04 is >>> when the URI in the outbound-proxy-set includes the keepalive=stun >>> parameter. This is 100% backwards safe. We don't need any text to >>> prevent existing implementations from getting a bunch of STUN >>> requests. >>> >>> That DHCP does not provide URI is a limitation of the SIP DHCP >>> configuration mechanism, not outbound. The same problem >>> exists for the >>> "comp" parameter for example. If you want to write a draft on >>> how to >>> "shift-up" to using keepalives or using compression from some SIP or >>> external stimulus, you can still do this. No text in outbound >>> prevents >>> that from happening. >>> >>> thanks, >>> -rohan >>> >>> >>> On Jun 29, 2006, at 23:10, wrote: >>>> >>>> Hi Rohan, >>>> >>>>>> Also, the issue is that what may be configured (no matter how you >>>>>> configure it) may not be a URI. It may simply be an IP >>> address/FQDN, >>>>>> which is then used to build a SIP-URI. I think we shall >>>>>> allow that, and make it more clear in the spec. [/CHH] >>>>> >>>>> the outbound spec defines a piece of configurable data (the >>>>> 'outbound-proxy-set'), which is a list of URIs. This list >>> of URIs may >>>>> never have a one-to-one correspondence to a user or administrator >>>>> manually configurable field. That piece of configurable data >>>>> may be >>>>> derived from several fields, manually configurable, discovered via >>>>> DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP >>>>> download, or via a random character generator seeded by the >>>>> phase of >>>>> the moon. >>>>> >>>>> The outbound-proxy-set was defined as a list of URIs because >>>>> the UA >>>>> acts on each item in the list, because each URI is expected to be >>>>> places in a Route header, and because each URI is expected to >>>>> typically have a keepalive URI parameter in it. >>>> >>>> Like mentioned in other recent emails the problem is that if the UA >>>> derives the proxy URI(s) from DHCP SIP server option or e.g. the >>>> AOR >>>> of the user, in those cases the derived URI will NOT contain the >>>> keepalive URI parameter in it. DHCP just returns IP addresses or >>>> domain names instead of URIs with parameters. >>>> >>>> Thus in those cases it would be critical for the UA to be able >>>> to ensure in REGISTER - 200 OK sequence that the contacted proxy >>>> supports Outbound and can handle STUN requests sent to its SIP >>>> port (not to cause any damage to an uncompliant proxy). I fully >>>> agree with this proposal from Jeroen: >>>> >>>> -- >>>> The text should then say "the UAC MUST wait for a 200 OK to >>>> REGISTER >>>> before >>>> it starts sending STUN packets. If the last Path header of the >>>> 200 OK >>>> does >>>> not contain keepalive=stun, the UAC MUST NOT use STUN >>> towards this URI. >>>> If >>>> there are no Path headers and no "Supported: outbound", the UAC >>>> also >>>> MUST >>>> NOT use STUN towards the registrar.". It could still use TCP >>> keepalive >>>> if it >>>> supports that >>>> -- >>>> >>>> Please excuse me if I am just repeating myself and what e.g. Jeroen >>>> has said but I believe the importance of this issue justifies some >>>> redundancy :-) >>>> >>>> Regards, >>>> >>>> Erkki >>> >>> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 01:52:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy0Hr-0000gI-MO; Wed, 05 Jul 2006 01:50:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy0Hp-0000gD-V6 for sip@ietf.org; Wed, 05 Jul 2006 01:50:58 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy0Hn-0004dD-N5 for sip@ietf.org; Wed, 05 Jul 2006 01:50:57 -0400 Received: (qmail 1417 invoked by uid 0); 5 Jul 2006 05:50:53 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Jul 2006 05:50:53 -0000 Message-ID: <002401c69ff6$f8c09660$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Wed, 5 Jul 2006 07:50:49 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Sip] Relationship between GRUU and callee capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1405987573==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1405987573== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C6A007.BB752670" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C6A007.BB752670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In http://www.jdrosen.net/papers/draft-ietf-sip-gruu-09.txt section 6 = figure 1, a GRUU is shown to be associated with 0..n Contacts. Does this = include callee capabilities that were indicated in the registration of = that contact? In other words, should the GRUU proxy be able to = reconstruct those capabilities, e.g. for caller preference processing = purposes? Thanks, Jeroen ------=_NextPart_000_0021_01C6A007.BB752670 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In http://= www.jdrosen.net/papers/draft-ietf-sip-gruu-09.txt section=20 6 figure 1, a GRUU is shown to be associated with 0..n Contacts. Does = this=20 include callee capabilities that were indicated in the registration of = that=20 contact? In other words, should the GRUU proxy be able to reconstruct = those=20 capabilities, e.g. for caller preference processing = purposes?
 
Thanks,
 
Jeroen
------=_NextPart_000_0021_01C6A007.BB752670-- --===============1405987573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1405987573==-- From sip-bounces@ietf.org Wed Jul 05 03:13:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy1XN-0001cu-Oq; Wed, 05 Jul 2006 03:11:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy1XL-0001cW-BR for sip@ietf.org; Wed, 05 Jul 2006 03:11:03 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy1LD-0000uH-Dn for sip@ietf.org; Wed, 05 Jul 2006 02:58:32 -0400 Received: (qmail 3310 invoked by uid 0); 5 Jul 2006 06:58:29 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Jul 2006 06:58:29 -0000 Message-ID: <002901c6a000$6a3b8e90$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Francois Audet" , "IETF SIP List" References: <1ECE0EB50388174790F9694F77522CCF0B23FEB3@zrc2hxm0.corp.nortel.com> Subject: Re: [Sip] FW: I-D ACTION:draft-audet-sip-sips-guidelines-02.txt Date: Wed, 5 Jul 2006 08:58:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois, Perhaps I've mentioned this before, but the registration of multiple Contacts (one per transport) to indicate which transports are supported is not workable: usage of different q-values does not stop a proxy from doing parallel forking. And there are other considerations, for example callee capabilities would have to be repeated for each contact, making the request bulky In any case, it seems that transport support/selection is a different issue than sip-sips, and should be left out of scope. For the three cases that you mention: o AOR is to be reachable only with secure transport Contact: ;schemes="sips", RFC3263 section 4.1 says that TCP SHOULD be chosen as transport, and "sips" implies TLS. Since "sip" is not included, a downgrade is not allowed o AOR is to be reachable preferably with secure transport Contact: ;schemes="sips,sip" o AOR is to be reachable only without secure transport Contact: ;schemes="sip" The definition of "implicit preferences" (RFC3841 section 7.2.2) might have to be extended to include scheme considerations for contact selection to work properly. Also, it should be defined that when explicit capabilities are provided, a proxy must not rewrite to a scheme that is not indicated. Some nits: - the URIs used in REGISTER throughout the draft should be "{sip/sips}:example.com", without 'transport' parameter and without "registrar." - Contacts in REGISTER responses MUST reflect all Contact header parameters (including 'q') - "If a UAS does not support SIPS, it MUST reject a request over TLS with response code 416" (section 6): Though not strictly necessary, since SIPS implies TLS one reason for "not support SIPS" here could be that TLS is not supported. In such a case, it will be impossible for the UAS to respond to an incoming request over TLS. Perhaps the domain proxy would be the element responding with 416 here? Regards, Jeroen ----- Original Message ----- From: "Francois Audet" To: "IETF SIP List" Sent: Wednesday, July 05, 2006 2:39 AM Subject: [Sip] FW: I-D ACTION:draft-audet-sip-sips-guidelines-02.txt Another update, including more feedback from the list. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, June 27, 2006 12:50 > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-audet-sip-sips-guidelines-02.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Guidelines for the use of the SIPS > URI Scheme in the Session Initiation Protocol (SIP) > Author(s) : F. Audet > Filename : draft-audet-sip-sips-guidelines-02.txt > Pages : 24 > Date : 2006-6-27 > > This document provides clarifications and guidelines concerning the > use of SIPS URI Scheme in the Session Initiation Protocol (SIP). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-audet-sip-sips-guide lines-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-audet-sip-sips-guidelines-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-audet-sip-sips-guidelines-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------------------- > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 04:06:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy2N3-0001rS-21; Wed, 05 Jul 2006 04:04:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy2N0-0001pH-RC for sip@ietf.org; Wed, 05 Jul 2006 04:04:26 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy2La-0007Q7-JC for sip@ietf.org; Wed, 05 Jul 2006 04:02:58 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6582si09209; Wed, 5 Jul 2006 04:02:55 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Date: Wed, 5 Jul 2006 03:02:51 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D057514@zrc2hxm2.corp.nortel.com> In-Reply-To: <86wtaszq46.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Thread-Index: Acaf4zPCvnYZD63aSEGSNuOWiZqScwAG3nwg From: "Samir Srivastava" To: "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > In this case, Alice and Atlanta will (most likely) negotiate AES-SHA256. > Atlanta will offer AES-SHA and AES-SHA256. Biloxi will select AES-SHA. > The only way in which the second hop could fail would be if Atlanta=20 > didn't speak AES-SHA, but remember that AES-SHA is a MUST implement. > > SS>> Fine. It will work in the current state of affairs. Breaking of > AES-SHA in future, will need another cipher-suite. Then we fix TLS=20 > with that (newer version etc). But SIP doesn't have any knowledge of=20 > how much secure hop it is. Again, that's not true with the scheme I described. Only cipher suites that the first-hop client is willing to negotiate will be negotiated on any hop. Consider the simple case where there is currently only one algorithm X. When a new algorithm Y is introduced (whatever the status of X), if the original UAC only supports X, then there are two possibilities: 1. Every proxy along the path supports X as well as Y. 2. Some proxy along the path only supports Y. =20 Given the algorithm I described, in case 1 you get X (which by definition is OK with the UAC). In case 2, the connection fails somewhere along the line. In neither case can you get a cipher suite that X does not consider acceptable. SS>> Why you want to fail the call setup in 2. In my proposal, When we have overriding defined, call will be setup, with the clear indication, that it is less/more secure ( 0 being no secure, 1 being Max i.e. for Algo Y in this case and their will be some value for X say 0.8 ). Making more no of retries will not be acceptable by the users and not desired by the providers. Your proposal will require more no of resubmission of INVITEs with changing algorithms etc when there are large no of algorithms. Moreover, What about the case when UAC and Proxy at the first hop is upgraded to Y and other hops for particular session are having still X. In your scheme, secure call setup will fail and more no of retries etc will be needed. In my proposal, call will be set, with the indication that it is=20 less secure with a single INVITE transaction. =20 > SS>> Being at UAC, I don't know in advance how I will be able to reach > the UAS. Take the case of retargeting from the another domain's proxy=20 > to the UAC domain proxy. The proposal is cleaner w.r.t. all these aspects. I don't understand the point you're making here. I'm not talking about the UAC, but about the various proxies inside a single trust domain. SS>> My point is, UAC and it's home proxy doesn't know at prior, what domains it will be visiting. The proxies visted may or may not be in a single trust domain. When INVITE is issued, they may be in the single trust domain, and retargeting makes it to go different trust domain. Retargetor entity (Proxy) needs to know where it is going. The earlier proxies in path will not have any idea. In the single trust domain, the original call might be using algorithm X, but going out in a different domain might need different algorithm Y. There will be cases when X is more/less stronger than Y. So again we are back to similar issues of upgrade/downgrade of SIP and SIPS. My proposal provides clear guideline what proxy should do. Your proposal will reject the calls based on relative stengths of X and Y and what UAC has. And require UAC to reInitiate the calls when it is failed. > Can you name an instance in which this has actually happened? > > But suppose it's true? You just relax the constraint that you need to=20 > offer only incoming cipher suites, upgrade your edge proxies, and the=20 > problem goes away. The reason not to do that ordinarily is that we=20 > don't have an unambigous ordering of cipher suite strengths so we'd=20 > like to let the original UA have an opinion but if you *know* that the > UA's offered algorithm is broken, I think it's safe to override it. > > SS>> Refer the earlier text in the reply. Ordering of strength of > cipher-suites etc and overriding is not considered currently. I don't understand this point at all. What I'm saying is that the only reason why you need to consult the UAC's cipher suite preferences at all is that we don't have a single agreed upon ordering of algorithm strengths. If we did, then it would be a simple matter of saying "on outgoing you can negotiate any algorithm as strong or stronger as the one on incoming." However, in the case where the proxy *knows* that the incoming algorithm is broken, then it's safe to negotiate a stronger algorithm even if the client did not offer it. SS>> Refer the previous comments. In your proposal calls are failed. And they need to retried with less security. All together new transactions etc. are needed. In my proposal call is setup with the available level of security in the network, if it is acceptable to UAC with a single INVITE. Then user can accept/reject the calls. In your proposal *more trust* is given to a single Proxy and UAC doesn't know what is being done in the path. If a single evil proxy downgrades, it cannot be indicated back to UAC, as you don't agree on the new header which carries the information for least strong algorithm being used in path when RESPONSE is sent back to UAC. My proposal can catch single bad proxy if it lies. My proposal doesn't cover the case when two adjacent proxies lie in collaboration.=20 > If we are > in the agreement that we need a security-level kind of header in SIP,=20 > then we can hash it out. I don't agree that we need such a header. SS>> I don't agree with you here. Refer my concerns in above replies. Let me divide this into two 1) Header for REQUEST where ciphersuites etc are listed. 2) Header for RESPONSE where least strong used algorithm in the path is indicated back=20 to UAC by UAS by inspecting via trails. Let me know your opinions for 1 and 2. Then we can focus on the discussion for that case. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 04:12:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy2SZ-0002u7-Vs; Wed, 05 Jul 2006 04:10:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy2N2-0001pH-IB for sip@ietf.org; Wed, 05 Jul 2006 04:04:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy1cT-0002yl-Ll for sip@ietf.org; Wed, 05 Jul 2006 03:16:21 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy1Rj-0002qN-8o for sip@ietf.org; Wed, 05 Jul 2006 03:05:19 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 0739E13F8B0; Wed, 5 Jul 2006 10:05:02 +0300 (EEST) Received: from rautu (polymer65.gprs.dnafinland.fi [62.78.110.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 9676113F8AE; Wed, 5 Jul 2006 10:04:55 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 024B1F03C1; Wed, 5 Jul 2006 10:05:04 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17579.25760.584180.394914@rautu.tutpro.com> Date: Wed, 5 Jul 2006 10:05:04 +0300 From: Juha Heinanen To: "Jeroen van Bemmel" Subject: Re: [Sip] Ready for WGLC on Outbound? In-Reply-To: <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: -2.6 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Cullen Jennings , sip@ietf.org, dean.willis@softarmor.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel writes: > 2. Confirming that a given proxy in the set actually supports outbound (ie > validating the keepalive=stun information) i don't understand this one. if a proxy is listed as an outbound proxy (for example in the result returned from DNS), why can't we require that it supports stun keepalives? -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 05:49:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy3zG-0004cb-Gm; Wed, 05 Jul 2006 05:48:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy3zE-0004aQ-UW for sip@ietf.org; Wed, 05 Jul 2006 05:48:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy2tL-0002YN-74 for sip@ietf.org; Wed, 05 Jul 2006 04:37:51 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy2jj-0004WZ-Ad for sip@ietf.org; Wed, 05 Jul 2006 04:27:57 -0400 Received: (qmail 1275 invoked by uid 0); 5 Jul 2006 08:23:20 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Jul 2006 08:23:20 -0000 Message-ID: <005c01c6a00c$47763a20$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Juha Heinanen" References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com><553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com><003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Wed, 5 Jul 2006 10:23:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: -2.3 (--) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Cullen Jennings , sip@ietf.org, dean.willis@softarmor.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha, Do you mean A) you dont understand what I am trying to say B) you dont see / agree that this is needed Let me try to rephrase: Currently deployed proxies generally do not support STUN, especially not on the same ports that they use for SIP. Sending a STUN packet to such a proxy could very well be harmless, but it could also cause it to crash. Adhering to the principle "be strict in what you send", it is the UAC's responsibility to make reasonably sure that a proxy it is about to STUN can take it. "keepalive=stun" in the URI it received through configuration is likely a good indicator, depending on which provisioning mechanism is used. But *independent* of the provisioning mechanism, a confirmation from the proxy itself is better. Sure, we can state "any proxy listed as outbound proxy MUST support STUN". We might even say "all proxies SHOULD support STUN". But no matter what requirements we come up with, they won't be met by currently deployed proxies. Summarizing: 1 - there is an implicit requirement "MUST NOT break current deployments". For outbound, this includes "proxies that do not support STUN MUST NOT receive STUN packets" (could consider to include something like this as a 9th requirement in section 12 of http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-04.txt) 2 - since we cannot influence all receivers, this translates into a requirement on the sender of STUN packets (the UAC): MUST NOT send STUN unless supported by target proxy 3 - to meet this requirement, we currently have "MUST check provisioned URI has keepalive=stun". It should say explicitly "if not, then MUST NOT send STUN to that URI" 4 - I am argueing: "MUST check provisioned keepalive=stun" is not sufficient, because the configuration may be incorrect (for various reasons, also depending on what you use for provisioning). As an additional check, we need "MUST check confirmation from proxy" We cannot depend only on the configuration mechanism (which is still TBD, and in principle open ended) Regards, Jeroen ----- Original Message ----- From: "Juha Heinanen" To: "Jeroen van Bemmel" Cc: "Cullen Jennings" ; ; ; ; Sent: Wednesday, July 05, 2006 9:05 AM Subject: Re: [Sip] Ready for WGLC on Outbound? > Jeroen van Bemmel writes: > > > 2. Confirming that a given proxy in the set actually supports outbound > > (ie > > validating the keepalive=stun information) > > i don't understand this one. if a proxy is listed as an outbound proxy > (for example in the result returned from DNS), why can't we require that > it > supports stun keepalives? > > -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 05:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy42m-0002jT-Lo; Wed, 05 Jul 2006 05:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy42l-0002jM-8q for sip@ietf.org; Wed, 05 Jul 2006 05:51:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy3B3-0005Oa-VM for sip@ietf.org; Wed, 05 Jul 2006 04:56:09 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy31V-0004rN-IF for sip@ietf.org; Wed, 05 Jul 2006 04:46:19 -0400 Received: by tutpro.com (Postfix, from userid 65534) id AF61713F8A2; Wed, 5 Jul 2006 11:46:12 +0300 (EEST) Received: from rautu (polymer65.gprs.dnafinland.fi [62.78.110.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id E327213F739; Wed, 5 Jul 2006 11:45:54 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 87AE3F03C1; Wed, 5 Jul 2006 11:46:07 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17579.31823.351859.567955@rautu.tutpro.com> Date: Wed, 5 Jul 2006 11:46:07 +0300 From: Juha Heinanen To: "Jeroen van Bemmel" Subject: Re: [Sip] Ready for WGLC on Outbound? In-Reply-To: <005c01c6a00c$47763a20$31713b51@BEMBUSTER> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> <005c01c6a00c$47763a20$31713b51@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: -2.6 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Cullen Jennings , sip@ietf.org, dean.willis@softarmor.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel writes: > Currently deployed proxies generally do not support STUN, especially not on > the same ports that they use for SIP. Sending a STUN packet to such a proxy > could very well be harmless, but it could also cause it to crash. sure, but those proxies are not outbound proxys and should not be listed as such. problem solved. > Sure, we can state "any proxy listed as outbound proxy MUST support STUN". > We might even say "all proxies SHOULD support STUN". But no matter what > requirements we come up with, they won't be met by currently deployed > proxies. if your currently deployed proxy is not outbound proxy as specified in the i-d, you don't list it as such. it is a regular proxy and can do whatever is specified in rfc3261. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 06:34:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy4gA-0005TJ-Me; Wed, 05 Jul 2006 06:32:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy4g9-0005Ru-Mw for sip@ietf.org; Wed, 05 Jul 2006 06:32:21 -0400 Received: from smtpout05-04.prod.mesa1.secureserver.net ([64.202.165.221]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fy4g8-0005OZ-Ag for sip@ietf.org; Wed, 05 Jul 2006 06:32:21 -0400 Received: (qmail 21293 invoked from network); 5 Jul 2006 10:32:19 -0000 Received: from unknown (69.173.130.247) by smtpout05-04.prod.mesa1.secureserver.net (64.202.165.221) with ESMTP; 05 Jul 2006 10:32:19 -0000 From: "Rajnish Jain" To: "'EKR'" , Subject: RE: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Date: Wed, 5 Jul 2006 06:32:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <20060704155845.65D3F1CC22@delta.rtfm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcafgxWv3pk94I9OQryAA9UGfvOc9gAliRSQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Message-Id: > It seems to me that there is a simpler mechanism: any proxy X > can only offer the intersection of the cipher suites that was > offered to it and the ciphersuites that it is willing to > support. There seems to be a fundamental disconnect in the comment above. The comment above is basically describing a hop-by-hop mechanism. However, the draft is fundamentally about solving the e2e problem. The keyword here is e2e. How will the proxy know that its narrowing down the UAC's preferred ciphersuites will not be detrimental to the setting up of the call somewhere downstream in the e2e path? > This has the result that no downstream proxy can > negotiate a cipher suite that Alice wasn't willing to > negotiate with Atlanta. But this has also has the undesirable result that no downstream proxy can negotiate a cipher suite that was agreeable to Alice. > 1. Alice doesn't get any signal of what was eventually negotiated. > I would solve this problem by extending Via (I'm actually surprised > this isn't done). MTAs typically put it in Received lines, FWIW... How will extending 'Via' help Alice, the UAC, learn about the negotiated ciphersuite? The draft does talk about extending 'Via' but that is to inform Bob, the UAS. The draft also mentions that the Security-Level header containing the lowest 'q' value is sent back to Alice. > 2. It's less expressive. In particular, the downstream cipher suites > always narrow and never grow. So, if there were a third proxy in > between Atlanta and Biloxi that only spoke DES, then Biloxi and Bob > would only get DES even if they both spoke AES. This comment doesn't seem to reflect the scheme described in the draft. Instead, this seems like a comment reflecting the hop-by-hop mechanism suggested in your own email. Rajnish _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 06:47:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy4tM-0006re-IH; Wed, 05 Jul 2006 06:46:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy4tL-0006rU-Sa for sip@ietf.org; Wed, 05 Jul 2006 06:45:59 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy4tK-0008HE-Cy for sip@ietf.org; Wed, 05 Jul 2006 06:45:59 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k65AjnY1008734; Wed, 5 Jul 2006 13:45:50 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 13:44:49 +0300 Received: from [172.21.34.184] ([172.21.34.184]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 5 Jul 2006 13:44:49 +0300 Message-ID: <44AB9820.4050200@nokia.com> Date: Wed, 05 Jul 2006 13:44:48 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: sip@ietf.org, Cullen Jennings , Rohan Mahy Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2006 10:44:49.0492 (UTC) FILETIME=[0A10F940:01C6A020] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Sip] A coment to draft-ietf-sip-outbound-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Reading Section 4.2 of Outbound-04, there is a sentence that came to my attention. For each outbound proxy URI in the set, the UA MUST send a REGISTER in the normal way using this URI as the default outbound proxy. I think it is not appropriate to use a MUST strength in this case. I suspect that the spirit of the draft is to offer high availability by making the UA to establish one flow per URI, which is a good spirit. However, one has to evaluate the cost of establishing one flow per URI, which might be quite high in terms of battery consumption, for example (due to STUN refreshes). I also believe the MUST is misused here because it is not an absolute requirement for the specification. In other words, the SIP outbound procedures work OK even if the UA establishes just one flow (even when it is provisioned with several outbound URIs). Nothing is broken. So, we should be looking at adding a paragraph that describes the benefit of establishing one flow per outbound URI, but letting up to the UA's policy to decide on the absolute number of established flows. I would suggest to replace the above mentioned sentence with something around these lines: For each outbound proxy URI in the set, the UA MAY send a REGISTER in the normal way using this URI as the default outbound proxy. Sending one REGISTER per outbound proxy URI decreases the likelihood of interrupted service due to dropped connections at the cost of maintaining a living flow which each outbound proxy server. Comments? /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 07:23:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5Pi-0006I2-3G; Wed, 05 Jul 2006 07:19:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5Pg-0006Hx-H3 for sip@ietf.org; Wed, 05 Jul 2006 07:19:24 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy5Pf-0002gA-67 for sip@ietf.org; Wed, 05 Jul 2006 07:19:24 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 9B34813F916; Wed, 5 Jul 2006 14:19:16 +0300 (EEST) Received: from rautu (polymer65.gprs.dnafinland.fi [62.78.110.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 1BC5A13F914; Wed, 5 Jul 2006 14:19:10 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id E376CF03C1; Wed, 5 Jul 2006 14:19:22 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17579.41018.861426.943160@rautu.tutpro.com> Date: Wed, 5 Jul 2006 14:19:22 +0300 From: Juha Heinanen To: Miguel Garcia Subject: [Sip] A coment to draft-ietf-sip-outbound-04 In-Reply-To: <44AB9820.4050200@nokia.com> References: <44AB9820.4050200@nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Miguel Garcia writes: > I also believe the MUST is misused here because it is not an absolute > requirement for the specification. In other words, the SIP outbound > procedures work OK even if the UA establishes just one flow (even when > it is provisioned with several outbound URIs). Nothing is broken. reliability may get broken. wasn't this issue discussed already earlier? i remember that a conclusion was reached something along the lines that the default is to establish at least two flows unless instructed otherwise by the domain? -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 07:32:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5av-00076R-28; Wed, 05 Jul 2006 07:31:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5at-00076L-V3 for sip@ietf.org; Wed, 05 Jul 2006 07:30:59 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy5as-00033v-Fw for sip@ietf.org; Wed, 05 Jul 2006 07:30:59 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k65BUojh028170; Wed, 5 Jul 2006 14:30:50 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 14:29:50 +0300 Received: from [172.21.34.184] ([172.21.34.184]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 5 Jul 2006 14:29:50 +0300 Message-ID: <44ABA2AE.3010001@nokia.com> Date: Wed, 05 Jul 2006 14:29:50 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 References: <44AB9820.4050200@nokia.com> <17579.41018.861426.943160@rautu.tutpro.com> In-Reply-To: <17579.41018.861426.943160@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2006 11:29:50.0374 (UTC) FILETIME=[53EADC60:01C6A026] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Miguel Garcia writes: > > > I also believe the MUST is misused here because it is not an absolute > > requirement for the specification. In other words, the SIP outbound > > procedures work OK even if the UA establishes just one flow (even when > > it is provisioned with several outbound URIs). Nothing is broken. > > reliability may get broken. wasn't this issue discussed already > earlier? i remember that a conclusion was reached something along the > lines that the default is to establish at least two flows unless > instructed otherwise by the domain? > That is what I remember as well, but I don't recall any conclusion of "unless instructed otherwise by the domain". In otherwise, there is still some "magic" for the domain instructions. But coming back to my point... I don't understand why there is a MUST here, because the protocol is not broken if the MUST is not followed. /Miguel > -- juha -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 08:02:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy63S-0004RZ-Ro; Wed, 05 Jul 2006 08:00:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy63Q-0004Q4-Mw for sip@ietf.org; Wed, 05 Jul 2006 08:00:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy50F-00013q-Go for sip@ietf.org; Wed, 05 Jul 2006 06:53:07 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy4rz-0006vC-NR for sip@ietf.org; Wed, 05 Jul 2006 06:44:38 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k65AiPpr017745; Wed, 5 Jul 2006 13:44:25 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 13:44:25 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 13:44:24 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Wed, 5 Jul 2006 13:44:24 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0280DC28@esebe103.NOE.Nokia.com> In-Reply-To: <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on Outbound? Thread-Index: AcafsbiDxw94qgSTSiW1+cAzFoC/YwAYf3yQ From: To: , , X-OriginalArrivalTime: 05 Jul 2006 10:44:24.0517 (UTC) FILETIME=[FB2E1750:01C6A01F] X-Spam-Score: -2.5 (--) X-Scan-Signature: 210770d71723b650f9c8e3db4e95b596 Cc: sip@ietf.org, drage@lucent.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi Cullen, Rohan and Dean, >I think people have stopped posting on this because they can't say =20 >anything that they have not already said. Don't take that as=20 >they agree. This is the last email which I intend to post on this subject (and hopefully I can keep that intention). The reason to keep on posting is that I am unable to attend the IETF meeting in Montreal, so I can only raise issues by email prior to the meeting and ask those issues to be discussed as open questions in the WG meeting. If this happens and the WG is able to reach a consensus in the meeting as recorded to the minutes, that will be time for me to eventually=20 shut up and outbound draft to move on for the WGLC. >you are proposing that we change in outbound - I think what you are =20 >proposing is we need to hold up outbound until we choose which one of =20 >the 10 we will use and furthermore you feel very strongly on which =20 >one of the 10 we should use. Please do not understand me incorrectly. My intention is not to block or delay the approval of outbound draft, I also feel that it is important to get it approved as soon as possible, to be able to cope with the NAT/FW traversal problems better than now. Further on I do not try to push the outbound draft to contain a solution for outbound discovery, but a safe probe that a UA could do in order to check that sending STUN packets will do no harm for the proxy. I always believed that this was a requirement for Outbound-04, based on the comments I saw on the list=20 prior to and right after the Dallas meeting (revolving around the=20 issue whether to use STUN or SIP PING as the keepalive mechanism).=20 Finding that Outbound-04 did not provide a mechanism, I tried to=20 raise the issue as soon as I could, to get it closed asap, believing that it would be sufficient that the authors to select the mechanism amongst the options available and add 1-2 related paragraphs to=20 Outbound-05 before the WGLC. I still hope it could be done like that and just try to be helpful to avoid one pitfall with the draft. >The WG decided on this separation =20 >of problems awhile back - I think it was in Vancouver - and many =20 >people supported it. I think it was a good idea - we have shown we =20 >can move outbound forward before we have determined all the ways that =20 >this configuration information is delivered to the UA. I would be =20 >very hesitant to reverse this decision now. Even if I have been working on SIP for some years, I only joined the WG (including sip@ietf.org follow-up) in the beginning of this year, so I have not been aware of what was discussed and decided earlier. So thanks for being updated. However I would tend to agree with how Jeroen put it in his email (it is the issue 2 which I also tried to highlight): >The point is that these are really 2 separate issues: >1. Discovering the set of outbound proxy URIs (with keepalive=3Dstun=20 >parameters in them) >2. Confirming that a given proxy in the set actually supports=20 >outbound (ie validating the keepalive=3Dstun information) > >Of these 2 options, (1) is indeed a separable problem.=20 >(2) - to me - is not, for me outbound is not acceptable=20 >without something to address (2). The specific concerns that I have (and would like the WG to=20 consider in the meeting) are closely related to what you told: >We got very strong feed back on one point - don't send=20 >STUN messages to a proxy unless you know it supports them.=20 1. This is what Outbound-04 says on the subject: User Agents that form flows MUST check if the configured URI they are connecting to has a 'keepalive' URI parameter (defined in Section 10) with the value of 'stun'. If the parameter is present, the UA needs to periodically perform keepalive checks by sending a STUN [I-D.ietf- behave-rfc3489bis] Binding Requests over the flow. Does the WG consider checking the configured URI as a safe enough check for the UA to ensure that the SIP proxy support STUN ? In my opinion it is not. As an example a vendor X could implement a compliant but bad UA which provides an option for the user to=20 configure the settings via an User Interface e.g. like this: "Is the phone behind a NAT: Yes/No". When the user selects "Yes" the UA would add the keepalive=3Dstun flag to the proxy URI even if the user does not have a clue if the proxy actually supports outbound or not. There is nothing in outbound draft to prevent such unsafe implementations to appear. 2. draft-koivusalo-sip-outbound-discovery identified a security threat like this: DNS NAPTR records are used to allow a client to discover that the server supports SIP Outbound. An attacker could potentially modify these records, resulting the client to send STUN request to a proxy that does not support STUN requests in its SIP port. This kind of attack could cause the proxy to behave in an unpredictable way and might cause it to crash. This kind of attack is prevented by a mechansim introduced within draft-ietf-sip-outbound [8]. When sending REGISTER request, the UA has to add an option tag to it, requiring the proxy to reject the request if it does not support SIP Outbound. [[Author's note: the mechanism to be used within REGISTER request is still to be decided. After the decision is made the text above must be rewritten.]] Without such a mechanism in outbound draft there is nothing to do to migitate the identified threat. 3. There is a separate draft being written about how the UA could automatically discover if a proxy supports outbound or not. Someone could claim that using that draft would make up the "safe check". However I do not think it would be wise the outbound draft itself to rely on any such additional draft to be ever approved or used. Outbound draft should be sufficiently self-contained so that applying it would not requrire the UA or proxy vendor to=20 implement some related draft (which might be available much later if ever) to do some mandatory things. I hope I was able formulate those concerns clearly enough so that the WG members can draw their opinions on those and make a=20 judgement whether or not this needs to be addressed in the=20 outbound draft before WGLC. It is in your hands now ;-) Regards, Erkki >-----Original Message----- >From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 >Sent: 05.July.2006 00:35 >To: Cullen Jennings; Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: rohan@ekabal.com; dean.willis@softarmor.com; sip@ietf.org >Subject: Re: [Sip] Ready for WGLC on Outbound? > >Cullen, > >The point is that these are really 2 separate issues: >1. Discovering the set of outbound proxy URIs (with keepalive=3Dstun=20 >parameters in them) >2. Confirming that a given proxy in the set actually supports=20 >outbound (ie=20 >validating the keepalive=3Dstun information) > >Of these 2 options, (1) is indeed a separable problem. (2) -=20 >to me - is not,=20 >for me outbound is not acceptable without something to address (2). It=20 >really should say "the UAC MUST NOT use STUN until { mechanism=20 >for (2) says=20 >its supported }" > >There have been several options mentioned to do this, a simple=20 >way is to=20 >have the edge proxy insert a flag. Question is: why not? > >Regards, > >Jeroen > >----- Original Message -----=20 >From: "Cullen Jennings" >To: >Cc: ; ; ;=20 > >Sent: Tuesday, July 04, 2006 10:37 PM >Subject: Re: [Sip] Ready for WGLC on Outbound? > > >> >> I think people have stopped posting on this because they can't say=20 >> anything that they have not already said. Don't take that as=20 >they agree. >> >> We got very strong feed back on one point - don't send STUN=20 >messages to a=20 >> proxy unless you know it supports them. People felt strongly=20 > about that -=20 >> I don't know why - but there was lots of people that agreed=20 >with that. >> >> I imagine people have sent me around 10 options on how to=20 >get the stun=20 >> supported information and the set of outbound proxy URIs - =20 >certainly DNS=20 >> and DHCP are some of them. We can write some drafts on =20 >various ways to do=20 >> it. Right now my concern is making sure that no matter=20 >which of these=20 >> many ways the WG decided to move forward with, outbound=20 >will work. So far=20 >> every one of the possibilities I have heard would be=20 >possible with the=20 >> current outbound. Given that, I'm not sure what we need to=20 >change in=20 >> outbound. I'm not even sure what you are proposing that we=20 >change in=20 >> outbound - I think what you are proposing is we need to=20 >hold up outbound=20 >> until we choose which one of the 10 we will use and=20 >furthermore you feel=20 >> very strongly on which one of the 10 we should use. I'm not keen on=20 >> this - I think we have shown they are separable problems.=20 >The WG decided=20 >> on this separation of problems awhile back - I think it was in=20 >> Vancouver - and many people supported it. I think it was a=20 >good idea -=20 >> we have shown we can move outbound forward before we have=20 >determined all=20 >> the ways that this configuration information is delivered=20 >to the UA. I=20 >> would be very hesitant to reverse this decision now. >> >> I don't think Dean's posts were sent as decries of the=20 >requirements from=20 >> the chair but purely as his opinion in trying to help bring the=20 >> discussion to consensus. But I do think the draft meets the =20 >requirements=20 >> and ideas he was outlining - I think the current draft does=20 >meet the=20 >> requirements he outlines. It does have a way for the =20 >"discovering whether=20 >> a proxy supports the extensions of outbound" and on the=20 >topic of "there=20 >> are two ways we can establish compatibility with an=20 >extensions", the WG=20 >> rejected option 2 and we have gone with 1. >> >> Cullen (with my outbound author hat on) >> >> >> On Jul 4, 2006, at 3:50 AM, =20 >> wrote: >> >>> >>> Hi Rohan, >>> >>> Sorry to be persistent with this issue, but what you say >>> seems to conflict with what was discussed in March. >>> >>>> The only time a UAC sends a STUN request as directed by >>>> outbound -04 is when the URI in the outbound-proxy-set >>>> includes the keepalive=3Dstun parameter. That DHCP does not >>>> provide URI is a limitation of the SIP DHCP configuration >>>> mechanism, not outbound. If you want to write a draft on >>>> how to "shift-up" to using keepalives from some SIP or >>>> external stimulus, you can still do this. >>> >>> What you say seems to suggest that you agree there is a problem >>> when using DHCP SIP server option (as it is currently defined) >>> for finding out if the discovered proxy supports outbound and >>> STUN keepalives, but the solution is not in scope of Outbound >>> draft itself. >>> >>> However I came to a different understanding based on the emails >>> seen in the list earlier. For instance this email from Dean >>> Willis (SIP WG chair) seems to suggest that the problem should >>> be in scope of the outbound draft: >>> http://www1.ietf.org/mail-archive/web/sip/current/msg13667.html >>> >>> "Ok, I think we've boiled this down to a new requirement: >>> >>> for the "outbound" technique to work, we MUST have a means of >>> discovering whether a proxy supports the extensions of outbound. >>> >>> While we could do that by doing a REGISTER exchange that includes >>> an appropriate option-tag in Require:, it would be more efficient >>> if the proxy discovery mechanism informed us of this detail. So, >>> we posit that the Outbound draft SHOULD select and discuss such a >>> mechanism." >>> >>> And in yet another email >>> http://www1.ietf.org/mail-archive/web/sip/current/msg13692.html >>> Dean tells this: >>> >>> "There are two ways we can establish compatibility with an=20 >extensions: >>> >>> 1) By foreknowledge >>> 2) By experimentation -- try it and see if it works. >>> >>> Both have limitations: >>> >>> In the case of #1, we might have incorrect knowledge. So=20 >we'll probably >>> end up testing anyhow . . . >>> >>> In the case of #2, the experiment might cause a meltdown.=20 >So the "probe >>> for discovery" must be made completely safe. Also, we can =20 >eventually end >>> up with so many wierd hooks and idiosyncratic=20 >implementations that we >>> end up doing a BUNCH of probing before we do any real =20 >communicating. And >>> it's possible for the conditions to deteriorate so much=20 >that probes for >>> two different possible conditions are mutually exclusive -- if one >>> condition applies, the probe for another will cause a meltdown. >>> >>> So what happens if we start STUN-probing a proxy on its SIP=20 >port and it >>> doesn't support STUN? My guess is, it's random. >>> >>> ... >>> >>> One approach to "forward compatibility" design is to make=20 >sure that we >>> can use both foreknowledge and experimentation -- the=20 >"trust but verify" >>> model. >>> >>> ... >>> >>> While it's easy to decide whether a configured registrar URI has a >>> keepalive parameter, what happens to proxies we select based on >>> something besides direct configuration? >>> >>> Specifically, >>> >>> 1) Can the DHCP option for default proxy present the keepalive >>> parameter?" >>> ---- >>> >>> During these three months after seeing those comments in the list >>> I have been expecting the outbound draft to provide answer to >>> the question how UA could (within SIP signalling exchange) >>> safely to check whether or not a proxy supports STUN keepalive. >>> Two mechanims have been suggested how the UA could do this in >>> a simple way: >>> >>> 1. The UA to check that the Path header in 200 OK returned for >>> REGISTER would contain keepalive=3Dstun parameter for the proxy = URI >>> >>> 2. The UA to add Proxy-Reequire: stun-keepalive parameter into >>> the REGISTER request and the proxy to remove this tag from >>> the request before forwarding it towards the registrar >>> >>> For me, any of those mechanisms would sound feasible and for >>> safety reasons I would hope the draft to deny the UA for sending >>> STUN keepalives to the proxy which did not pass such a test. >>> >>>> the same problem exists for the "comp" parameter for example. >>> >>> Yes but please bear in mind that for comp=3Dsigcomp URI parameter >>> RFC 3486 Compressing SIP gives several solutions how the UA >>> would be able to check if the proxy supports SigComp while >>> outbound does not define any other than relying on configuration. >>> A cite from RFC 3486: >>> >>> 4.1 Obtaining a SIP or SIPS URI with comp=3Dsigcomp >>> >>> For requests within a dialog, a next-hop URI with the=20 >comp=3Dsigcomp >>> parameter is obtained from a Record-Route header field when the >>> dialog is established. A client sending a request=20 >outside a dialog >>> can also obtain SIP URIs with comp=3Dsigcomp in a Contact=20 >header field >>> in a 3xx or 485 response to the request. >>> >>> However, clients establishing a session will not=20 >typically be willing >>> to wait until the dialog is established in order to=20 >begin compressing >>> messages. One of the biggest gains that SigComp can=20 >bring to SIP is >>> the ability to compress the initial INVITE of a dialog,=20 >when the user >>> is waiting for the session to be established. Therefore, clients >>> need a means to obtain a comp=3Dsigcomp URI from their=20 >outbound proxy >>> before the user decides to establish a session. >>> >>> One solution to this problem is manual configuration. However, >>> sometimes it is necessary to have clients configured in=20 >an automatic >>> fashion. Unfortunately, current mechanisms for SIP client >>> configuration (e.g., using DHCP [6]) do not allow to provide the >>> client with URI parameters. In this case, the client=20 >SHOULD send an >>> uncompressed OPTIONS request to its outbound proxy. The outbound >>> proxy can provide an alternative SIP URI with the comp=3Dsigcomp >>> parameter in a Contact header field in a 200 OK response to the >>> OPTIONS. The client can use this URI for subsequent=20 >requests that >>> are sent through the same outbound proxy using compression. >>> >>> RFC 3261 [1] does not define how a proxy should respond=20 >to an OPTIONS >>> request addressed to itself. It only describes how=20 >servers respond >>> to OPTIONS addressed to a particular user. Section 11.2=20 >of RFC 3261 >>> says: >>> >>> Contact header fields MAY be present in a 200 (OK)=20 >response and >>> have the same semantics as in a 3xx response. That=20 >is, they may >>> list a set of alternative names and methods of=20 >reaching the user. >>> >>> We extend this behavior to proxy servers responding to OPTIONS >>> addressed to them. They MAY list a set of alternative URIs to >>> contact the proxy. >>> >>> What has been called for is that outbound draft would also >>> specify one solution how the UA could check the STUN keepalive >>> support of a proxy. In my opinion good proposals seem >>> to exist how to do it in a reasonable way. >>> >>> Regards, >>> >>> Erkki >>> >>>> -----Original Message----- >>>> From: ext Rohan Mahy [mailto:rohan@ekabal.com] >>>> Sent: 04.July.2006 03:10 >>>> To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >>>> Cc: dean.willis@softarmor.com; fluffy@cisco.com; Rohan Mahy; >>>> sip@ietf.org; jbemmel@zonnet.nl >>>> Subject: Re: [Sip] Ready for WGLC on Outbound? >>>> >>>> Hi Erkki, >>>> >>>> The only time a UAC sends a STUN request as directed by >>>> outbound -04 is >>>> when the URI in the outbound-proxy-set includes the = keepalive=3Dstun >>>> parameter. This is 100% backwards safe. We don't need any text to >>>> prevent existing implementations from getting a bunch of=20 >STUN requests. >>>> >>>> That DHCP does not provide URI is a limitation of the SIP DHCP >>>> configuration mechanism, not outbound. The same problem >>>> exists for the >>>> "comp" parameter for example. If you want to write a=20 >draft on how to >>>> "shift-up" to using keepalives or using compression from=20 >some SIP or >>>> external stimulus, you can still do this. No text in outbound >>>> prevents >>>> that from happening. >>>> >>>> thanks, >>>> -rohan >>>> >>>> >>>> On Jun 29, 2006, at 23:10, wrote: >>>>> >>>>> Hi Rohan, >>>>> >>>>>>> Also, the issue is that what may be configured (no=20 >matter how you >>>>>>> configure it) may not be a URI. It may simply be an IP >>>> address/FQDN, >>>>>>> which is then used to build a SIP-URI. I think we shall >>>>>>> allow that, and make it more clear in the spec. [/CHH] >>>>>> >>>>>> the outbound spec defines a piece of configurable data (the >>>>>> 'outbound-proxy-set'), which is a list of URIs. This list >>>> of URIs may >>>>>> never have a one-to-one correspondence to a user or administrator >>>>>> manually configurable field. That piece of configurable=20 >data may be >>>>>> derived from several fields, manually configurable,=20 >discovered via >>>>>> DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP >>>>>> download, or via a random character generator seeded by=20 >the phase of >>>>>> the moon. >>>>>> >>>>>> The outbound-proxy-set was defined as a list of URIs=20 >because the UA >>>>>> acts on each item in the list, because each URI is expected to be >>>>>> places in a Route header, and because each URI is expected to >>>>>> typically have a keepalive URI parameter in it. >>>>> >>>>> Like mentioned in other recent emails the problem is that=20 >if the UA >>>>> derives the proxy URI(s) from DHCP SIP server option or=20 >e.g. the AOR >>>>> of the user, in those cases the derived URI will NOT contain the >>>>> keepalive URI parameter in it. DHCP just returns IP addresses or >>>>> domain names instead of URIs with parameters. >>>>> >>>>> Thus in those cases it would be critical for the UA to be able >>>>> to ensure in REGISTER - 200 OK sequence that the contacted proxy >>>>> supports Outbound and can handle STUN requests sent to its SIP >>>>> port (not to cause any damage to an uncompliant proxy). I fully >>>>> agree with this proposal from Jeroen: >>>>> >>>>> -- >>>>> The text should then say "the UAC MUST wait for a 200 OK=20 >to REGISTER >>>>> before >>>>> it starts sending STUN packets. If the last Path header=20 >of the 200 OK >>>>> does >>>>> not contain keepalive=3Dstun, the UAC MUST NOT use STUN >>>> towards this URI. >>>>> If >>>>> there are no Path headers and no "Supported: outbound",=20 >the UAC also >>>>> MUST >>>>> NOT use STUN towards the registrar.". It could still use TCP >>>> keepalive >>>>> if it >>>>> supports that >>>>> -- >>>>> >>>>> Please excuse me if I am just repeating myself and what=20 >e.g. Jeroen >>>>> has said but I believe the importance of this issue justifies some >>>>> redundancy :-) >>>>> >>>>> Regards, >>>>> >>>>> Erkki >>>> >>>>=20 > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 08:14:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy6FO-0005Tp-H5; Wed, 05 Jul 2006 08:12:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy6FM-0005TT-E7 for sip@ietf.org; Wed, 05 Jul 2006 08:12:48 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy6FL-0007Lh-Uu for sip@ietf.org; Wed, 05 Jul 2006 08:12:48 -0400 Received: (qmail 26587 invoked by uid 0); 5 Jul 2006 12:12:41 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Jul 2006 12:12:41 -0000 Message-ID: <012001c6a02c$51b41780$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Miguel Garcia" , "Juha Heinanen" References: <44AB9820.4050200@nokia.com><17579.41018.861426.943160@rautu.tutpro.com> <44ABA2AE.3010001@nokia.com> Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Wed, 5 Jul 2006 14:12:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with Miguel here Outbound can be used for (at least) two things: 1) firewall/NAT traversal (especially for inbound requests) 2) high(er) reliability for registrations, by using multiple These are separate use cases, it should be possible to do (1), (2) or both together (for example: I might be in a situation where there is no NAT, but I'd still like to use 2 registrations with different reg-ids). A MUST which forces an implementation to always do (2) makes it impossible to do only (1). The abstract only talks about (1). The introduction talks mainly about (1), but mentions (2) in relation to flow failure (basically (2) is needed to overcome the window of max. 29 (UDP) or 120 (TCP) seconds it may take to detect a failed flow) The benefit of (2) is highly dependent on the deployment environment and on the type of failures that occur. A UAC may set up 2 flows, but if both go through the same NAT device and this NAT device reboots, there may only be a benefit (in terms of period for which the UAC is not reachable) if the keep-alives for both flows are not too synchronized. It does help to maintain reachability in case one of the registrars (or edge proxies) reboots and looses its state What I miss in the draft is discussion on the above aspects (i.e. synchronization of flow keep-alive timers, types of failures). A minimum of 2 flows should IMO be RECOMMENDED (with explanation that this protects against single registrar / edge proxy failure, and reduces non-reachability to at most 15 (UDP) resp. 60 (TCP) seconds in case of NAT reboots, using the recommended timer values and provided the keep-alive timers are synchronized on half periods ) Note that for deployments where registrar failure is rare, one might decide to use only a single flow with half the keep-alive period. So if we go with the 'domain suggests number of flows", we should also include "domain suggests keep-alive timer periods" Regards, Jeroen ----- Original Message ----- From: "Miguel Garcia" To: "Juha Heinanen" Cc: ; "Cullen Jennings" ; "Rohan Mahy" Sent: Wednesday, July 05, 2006 1:29 PM Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 > Juha Heinanen wrote: >> Miguel Garcia writes: >> >> > I also believe the MUST is misused here because it is not an absolute >> > requirement for the specification. In other words, the SIP outbound > >> procedures work OK even if the UA establishes just one flow (even when > >> it is provisioned with several outbound URIs). Nothing is broken. >> >> reliability may get broken. wasn't this issue discussed already >> earlier? i remember that a conclusion was reached something along the >> lines that the default is to establish at least two flows unless >> instructed otherwise by the domain? >> > > That is what I remember as well, but I don't recall any conclusion of > "unless instructed otherwise by the domain". In otherwise, there is still > some "magic" for the domain instructions. > > But coming back to my point... I don't understand why there is a MUST > here, because the protocol is not broken if the MUST is not followed. > > /Miguel > >> -- juha > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 09:38:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7Yz-0002Mc-Dk; Wed, 05 Jul 2006 09:37:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7Yx-0002MX-V6 for sip@ietf.org; Wed, 05 Jul 2006 09:37:07 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy7Yv-0008Da-AU for sip@ietf.org; Wed, 05 Jul 2006 09:37:07 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 27A461E8C1F; Wed, 5 Jul 2006 06:37:00 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 References: <62B9B0847CC47543B6B3B5E26BD268E60D057514@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Wed, 05 Jul 2006 06:37:00 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60D057514@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Wed, 5 Jul 2006 03:02:51 -0500") Message-ID: <86lkr8xjer.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Editorial note: Samir, can I ask you to use standard ">" quoting markers? I'm finding this exchange very hard to read with the quote markers you'r;e using. "Samir Srivastava" writes: > "Samir Srivastava" writes: >> In this case, Alice and Atlanta will (most likely) negotiate > AES-SHA256. >> Atlanta will offer AES-SHA and AES-SHA256. Biloxi will select AES-SHA. >> The only way in which the second hop could fail would be if Atlanta >> didn't speak AES-SHA, but remember that AES-SHA is a MUST implement. >> >> SS>> Fine. It will work in the current state of affairs. Breaking of >> AES-SHA in future, will need another cipher-suite. Then we fix TLS >> with that (newer version etc). But SIP doesn't have any knowledge of >> how much secure hop it is. > > Again, that's not true with the scheme I described. Only cipher suites > that the first-hop client is willing to negotiate will be negotiated on > any hop. Consider the simple case where there is currently only one > algorithm X. When a new algorithm Y is introduced (whatever the status > of X), if the original UAC only supports X, then there are two > possibilities: > > 1. Every proxy along the path supports X as well as Y. > 2. Some proxy along the path only supports Y. > > Given the algorithm I described, in case 1 you get X (which by > definition is OK with the UAC). In case 2, the connection fails > somewhere along the line. In neither case can you get a cipher suite > that X does not consider acceptable. > > SS>> Why you want to fail the call setup in 2. I don't want it to, particularly. But I'm pointing out the scheme I described fails safe. You may not have "any knowledge of how secure it is" but you never end up sending data over a channel you wouldn't be willing to. > In my proposal, When we > have overriding defined, call will be setup, with the clear indication, > that it is less/more secure ( 0 being no secure, 1 being Max i.e. for > Algo Y in this case and their will be some value for X say 0.8 ). Making > more no of retries will not be acceptable by the users and not desired > by the providers. Your proposal will require more no of resubmission of > INVITEs with changing algorithms etc when there are large no of > algorithms. No, I don't believe it will. Please show the flow diagrams that you think demonstrate this. > Moreover, What about the case when UAC and Proxy at the first hop is > upgraded to Y and other hops for particular session are having still X. > In your scheme, secure call setup will fail and more no of retries etc > will be needed. In my proposal, call will be set, with the indication > that it is > less secure with a single INVITE transaction. No, that's not correct either, as I showed in an earlier diagram, of exactly this case, repeated here. Alice Atlanta Biloxi ----- ------- ------ AES-SHA AES-SHA 3DES-SHA AES-SHA256 AES-SHA256 AES-SHA In this case, Alice and Atlanta will (most likely) negotiate AES-SHA256. Atlanta will offer AES-SHA and AES-SHA256. Biloxi will select AES-SHA. Now, it's certainly true that if Alice configures her client to be AES-SHA256 only then she won't be able to get a call through, but that's a feature because it's a deliberate advertisement that she's unwilling to do other algorithms. >> SS>> Being at UAC, I don't know in advance how I will be able to reach >> the UAS. Take the case of retargeting from the another domain's proxy >> to the UAC domain proxy. The proposal is cleaner w.r.t. all these > aspects. > > I don't understand the point you're making here. I'm not talking about > the UAC, but about the various proxies inside a single trust domain. > > SS>> My point is, UAC and it's home proxy doesn't know at prior, what > domains it will be visiting. The proxies visted may or may not be in a > single trust domain. When INVITE is issued, they may be in the single > trust domain, and retargeting makes it to go different trust domain. > Retargetor entity (Proxy) needs to know where it is going. The earlier > proxies in path will not have any idea. In the single trust domain, the > original call might be using algorithm X, but going out in a different > domain might need different algorithm Y. There will be cases when X is > more/less stronger than Y. > So again we are back to similar issues of upgrade/downgrade of SIP and > SIPS. My proposal provides clear guideline what proxy should do. Your > proposal will reject the calls based on relative stengths of X and Y and > what UAC has. And require UAC to reInitiate the calls when it is failed. Let's put this issue aside until we're clear on how the system I described works in the simple case above. > I don't agree that we need such a header. > > SS>> I don't agree with you here. Refer my concerns in above replies. > Let me divide this into two > 1) Header for REQUEST where ciphersuites etc are listed. This is totally unnecessary. > 2) Header for RESPONSE where least strong used algorithm in the path > is indicated back > to UAC by UAS by inspecting via trails. The whole concept of "least strong" is a mistake. What should be reported back is the entire list of proxies the message went through and the relevant crypto algorithms. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 09:41:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7bu-0002il-4h; Wed, 05 Jul 2006 09:40:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7bs-0002ib-W4 for sip@ietf.org; Wed, 05 Jul 2006 09:40:08 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy7br-00009Z-KU for sip@ietf.org; Wed, 05 Jul 2006 09:40:08 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 293031E8C1F; Wed, 5 Jul 2006 06:40:07 -0700 (PDT) To: "Rajnish Jain" Subject: Re: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 References: <20060705104029.7303A222425@laser.networkresonance.com> From: Eric Rescorla Date: Wed, 05 Jul 2006 06:40:07 -0700 In-Reply-To: <20060705104029.7303A222425@laser.networkresonance.com> (Rajnish Jain's message of "Wed, 5 Jul 2006 06:32:17 -0400") Message-ID: <861wt0xj9k.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Rajnish Jain" writes: >> It seems to me that there is a simpler mechanism: any proxy X >> can only offer the intersection of the cipher suites that was >> offered to it and the ciphersuites that it is willing to >> support. > > There seems to be a fundamental disconnect in the comment above. The comment > above is basically describing a hop-by-hop mechanism. However, the draft is > fundamentally about solving the e2e problem. The keyword here is e2e. This draft *isn't* end-to-end. End-to-end would be like in RFC 2818 where there's a single TLS channel between UAC and UAS. What this is is hop-by-hop with policy instructions. > How > will the proxy know that its narrowing down the UAC's preferred ciphersuites > will not be detrimental to the setting up of the call somewhere downstream > in the e2e path? It might be, but a lot of experience with real TLS deployments and the fact that there is a mandatory-to-implement ciphersuite suggests that this will not be a problem in practice. >> This has the result that no downstream proxy can >> negotiate a cipher suite that Alice wasn't willing to >> negotiate with Atlanta. > > But this has also has the undesirable result that no downstream proxy can > negotiate a cipher suite that was agreeable to Alice. Huh? No, that's incorrect. >> 1. Alice doesn't get any signal of what was eventually negotiated. >> I would solve this problem by extending Via (I'm actually surprised >> this isn't done). MTAs typically put it in Received lines, FWIW... > > How will extending 'Via' help Alice, the UAC, learn about the negotiated > ciphersuite? The draft does talk about extending 'Via' but that is to inform > Bob, the UAS. The draft also mentions that the Security-Level header > containing the lowest 'q' value is sent back to Alice. Yes, you'll need some reverse channel that carries the same data as the Via. >> 2. It's less expressive. In particular, the downstream cipher suites >> always narrow and never grow. So, if there were a third proxy in >> between Atlanta and Biloxi that only spoke DES, then Biloxi and Bob >> would only get DES even if they both spoke AES. > > This comment doesn't seem to reflect the scheme described in the draft. > Instead, this seems like a comment reflecting the hop-by-hop mechanism > suggested in your own email. Yes, that's why I listed it as a disadvantage of the scheme described in my e-mail message. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 09:49:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7iw-0003MZ-EF; Wed, 05 Jul 2006 09:47:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7iv-0003MU-Gn for sip@ietf.org; Wed, 05 Jul 2006 09:47:25 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy7iu-0002Am-82 for sip@ietf.org; Wed, 05 Jul 2006 09:47:25 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k65DlK2Z008818 for ; Wed, 5 Jul 2006 08:47:20 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ9SRAQ>; Wed, 5 Jul 2006 14:47:12 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369D30E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Wed, 5 Jul 2006 14:47:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Attempt to resend as the previous version seems to have disappeared into the ether. regards Keith > -----Original Message----- > From: Drage, Keith (Keith) > Sent: 05 July 2006 11:25 > To: Cullen Jennings > Cc: sip@ietf.org; rohan@ekabal.com; dean.willis@softarmor.com > Subject: RE: [Sip] Ready for WGLC on Outbound? > > > (As chair) > > Right now both Dean and myself believe outbound is blocked. > > We asked the question a month or so ago about whether > outbound could proceed without a discovery mechanism (either > included or normatively referenced), and there was a > significant number of people who apparently said no (we do > have difficulties on this list who respond to a direct > question from the chairs by going away and discussing > something completely different). > > It appears that for these people, outbound could proceed if > we have a normative reference to a discovery mechanism, but > in that case, is that one mechanism or several, and do all or > any of these require mandatory support. > > Conversely we have a set of people who appear to be saying > "use any mechanism you like" and therefore no normative > reference is needed. > > Now obviously, we would like to get this resolved one way or > the other. We will quite probably be conducting hums on this > issue in the SIP WG session in Montreal, having failed to > achieve concensus on the list - unless in the next two or > three days we see a breaking of this impasse. > > And remember, if outbound is blocked, then GRUU is dependent > on outbound, so at the end of the day that will also be > blocked, even if we progress it to the RFC editor's queue. > > We are formulating the questions we need to ask the WG on > this issue, so any guidance from those involved would be > useful. It would be nice to get the problem stated as clearly > as possible so that the WG is able to give an intelligent answer. > > regards > > Keith > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 10:28:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8KU-0006er-SM; Wed, 05 Jul 2006 10:26:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8KS-0006em-1k for sip@ietf.org; Wed, 05 Jul 2006 10:26:12 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8KP-0005Xw-Or for sip@ietf.org; Wed, 05 Jul 2006 10:26:12 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2006 07:26:10 -0700 X-IronPort-AV: i="4.06,209,1149490800"; d="scan'208"; a="303167595:sNHT138207222" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k65EQ8i0023917; Wed, 5 Jul 2006 07:26:08 -0700 Received: from [192.168.1.2] (sjc-vpn1-690.cisco.com [10.21.98.178]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k65EQ8Is020467; Wed, 5 Jul 2006 07:26:08 -0700 (PDT) In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F027D0DEB@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F027D0DEB@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96653400-8B1F-4806-81B1-6CA11CCD4B67@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER Date: Wed, 5 Jul 2006 07:26:05 -0700 To: "" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=821; t=1152109568; x=1152973568; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound-04=20and=20=22max-flow=22=20in=20200=20OK=20for =20REGISTER; X=v=3Dcisco.com=3B=20h=3DGytn9YvFPv06DM17ydzMbztPJeo=3D; b=q3wejXU5pSewS3Y1HBrhIAkkxrqek0HtnWdrLPusgai29nWW46CIgLnWV9Qa1nFj6A6rTB5t fdnOIVO9yHp9UkCkmNeOfwUan7Ch2Ax0WBhqiQdJMslBRMjhMLD/yljQ; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org, rohan@ekabal.com, christer.holmberg@ericsson.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 29, 2006, at 10:55 PM, wrote: > >> I can think of a number of ways to make this work where >> the intended semantics are entirely embedded in DNS. > > If you have any ideas like that, could you please pass them > to me since I am working on a related I-D where no such ideas > have been introduced. I would be happy to receive those to be > able to check if they work with the rest of the DNS scheme > currently proposed. If yes, I could take them into my draft. Well long and short of it is, if you are embedding the config information in DNS, just put it in DNS - look at how much information a ENUM or SRV record provides. I'm not sure if it is a good idea to do this or not but I'm just pointing out ways you might consider. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 10:32:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8ON-0007As-Tv; Wed, 05 Jul 2006 10:30:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8OM-0007Ai-F0 for sip@ietf.org; Wed, 05 Jul 2006 10:30:14 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8OM-0005gQ-3N for sip@ietf.org; Wed, 05 Jul 2006 10:30:14 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k65EUCJd017154 for ; Wed, 5 Jul 2006 09:30:13 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ9SSWD>; Wed, 5 Jul 2006 15:29:43 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369D329@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@ietf.org'" Subject: RE: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG? Date: Wed, 5 Jul 2006 15:29:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (as chair) Well I believe we got a grand total of TWO responses on this question. That means we are going to have to institute a more formal review, probably on the lines of the review process Dean outlined in a previous mail. We will be discussing the logistics for this process offline in Montreal, but we will be looking for critical reviewers to formally assess this from various sectors of the IETF community. If you consider yourself or someone else a person who should be a critical reviewer let us (the WG chairs) know. Also if have knowledge of a sector that should be addressing the review (e.g. SIPIT, security, CableLabs...) then please let us know. regards Keith > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 27 June 2006 15:03 > To: 'sip@ietf.org' > Cc: 'sip-chairs@ietf.org' > Subject: RE: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG? > > > (As WG chair) > > I'm afraid I am going to have to ask you to be much more > proactive on this question, as the IESG need something a > little more positive from the WG. So... > > i) If you have thoroughly reviewed this, and as a result > believe it is ready, and I know there are at least some of > you out there who have torn GRUU to pieces, throughly > digested it and put it back together again, then send Dean > and myself an email to that effect at sip-chairs@ietf.org. > > ii) If you are intending to review this but want more time > before responding, then also please say. > > Remember this document is still in the WGLC state. We trying > to get it into the next state of IESG review. That means WG > consensus that it is ready. > > Please try to respond by my original deadline of 30th June > (although we may give a couple of extra days grace here). > > regards > > Keith > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: 23 June 2006 11:57 > > To: 'sip@ietf.org' > > Cc: 'sip-chairs@ietf.org' > > Subject: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG? > > > > > > (As WG chair) > > > > The SIP WG chairs and the author all think this document is > > ready for sending to the IESG. > > > > We have had WGLC announced 5th July 2004 to complete 17th > July 2004. > > We had a further last round of WG review requested 26th > > October 2005 to complete 6th November 2005. > > We have had significant discussion on the lists since then of > > this draft, and discussion in SIP WG sessions, and all > > comments have been resolved. > > > > If you believe this document IS NOT ready to send to IESG, > > can you please indicate this to the list and the WG chairs by > > 12:00 midday UK time (7:00 am US Eastern Time) on 30th June > > 2006, giving technical justification for your objection. > > > > Please limit this thread to answering the question above. If > > you have other discussion relating to GRUU generally, then > > please use a different thread. > > > > regards > > > > Keith > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: 22 June 2006 20:50 > > To: i-d-announce@ietf.org > > Cc: sip@ietf.org > > Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-09.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Session Initiation Protocol > > Working Group of the IETF. > > > > Title : Obtaining and Using Globally Routable > > User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) > > Author(s) : J. Rosenberg > > Filename : draft-ietf-sip-gruu-09.txt > > Pages : 38 > > Date : 2006-6-22 > > > > Several applications of the Session Initiation Protocol > (SIP) require > > a user agent (UA) to construct and distribute a URI that can be used > > by anyone on the Internet to route a call to that specific UA > > instance. A URI that routes to a specific UA instance is called a > > Globally Routable UA URI (GRUU). This document describes an > > extension to SIP for obtaining a GRUU from a server and for > > communicating a GRUU to a peer within a dialog. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-09.txt > > > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-gruu-09.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-gruu-09.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 10:50:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8gb-00044X-I2; Wed, 05 Jul 2006 10:49:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8gZ-00040Z-LP for sip@ietf.org; Wed, 05 Jul 2006 10:49:03 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8gY-0000UJ-B0 for sip@ietf.org; Wed, 05 Jul 2006 10:49:03 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2006 07:49:01 -0700 X-IronPort-AV: i="4.06,209,1149490800"; d="scan'208"; a="303184435:sNHT72810124" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k65En1EM021739; Wed, 5 Jul 2006 07:49:01 -0700 Received: from [192.168.1.2] (sjc-vpn1-690.cisco.com [10.21.98.178]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k65En0cL029257; Wed, 5 Jul 2006 07:49:01 -0700 (PDT) In-Reply-To: <44AB9820.4050200@nokia.com> References: <44AB9820.4050200@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Wed, 5 Jul 2006 07:48:59 -0700 To: Miguel Garcia X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=3164; t=1152110941; x=1152974941; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20A=20coment=20to=20draft-ietf-sip-outbound-04; X=v=3Dcisco.com=3B=20h=3DQn9l+a0ouTkEr2/BhAU/VBQiADE=3D; b=YE7GWgjqfPKmtauxDaF+aIUhBwWLqwGu0siX5AsYjZZ4wPCpUsuC9i4emoL55kiWEzvZtRpj XPCXyQBbg3TWJL0FZI3pXOSVLrywtsRUZK+LMCoNoJxEXsoSa3YtSr3V; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: sip@ietf.org, Rohan Mahy Subject: [Sip] Re: A coment to draft-ietf-sip-outbound-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My impression of what the WG wanted was that the service provider could provide between 1 and the max number the UA supported of URIs. The UA must implement support for at least 2 and should support 4. So let's say that the domain use two and this domains has to have two do to reliability. If the UA has "local policy" and only decided to use one - things don't work. I think this is more or less the same as if you are doing a single registration and the registry tells you your registration expires after 1 hour but the UA decided to refresh after two hours to reduce network load, well things are broken. Now you say that the UA might decide by local policy if it wanted to do say 1 or 2 flows - but where will this local policy come from? The end user is not going too provide it. I suspect the domain will provide it. I'm fine with some times the domain tells the UA to use 1 uri and other times two. I can imagine the domain changing this configuration as the UA moves from different types of access networks. I expect you are right in that this MUST is too strong here but I think there is an argument for SHOULD. The problem is that if the domain assume the UA is doing two flows and the UA does one, things are broken. On Jul 5, 2006, at 3:44 AM, Miguel Garcia wrote: > Reading Section 4.2 of Outbound-04, there is a sentence that came > to my attention. > > For each outbound proxy URI in the set, the UA MUST send a > REGISTER in the normal way using this URI as the default outbound > proxy. > > I think it is not appropriate to use a MUST strength in this case. > I suspect that the spirit of the draft is to offer high > availability by making the UA to establish one flow per URI, which > is a good spirit. However, one has to evaluate the cost of > establishing one flow per URI, which might be quite high in terms > of battery consumption, for example (due to STUN refreshes). > > I also believe the MUST is misused here because it is not an > absolute requirement for the specification. In other words, the SIP > outbound procedures work OK even if the UA establishes just one > flow (even when it is provisioned with several outbound URIs). > Nothing is broken. > > So, we should be looking at adding a paragraph that describes the > benefit of establishing one flow per outbound URI, but letting up > to the UA's policy to decide on the absolute number of established > flows. > > I would suggest to replace the above mentioned sentence with > something around these lines: > > For each outbound proxy URI in the set, the UA MAY send a > REGISTER in the normal way using this URI as the default outbound > proxy. Sending one REGISTER per outbound proxy URI decreases the > likelihood of interrupted service due to dropped connections at the > cost of maintaining a living flow which each outbound proxy server. > > Comments? > > /Miguel > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 10:56:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8mR-0001WJ-G2; Wed, 05 Jul 2006 10:55:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8mQ-0001WE-A1 for sip@ietf.org; Wed, 05 Jul 2006 10:55:06 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8mM-0001fx-S4 for sip@ietf.org; Wed, 05 Jul 2006 10:55:05 -0400 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k65Erj7A092754 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 5 Jul 2006 09:53:46 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.2) To: IETF SIP List Message-Id: References: <446DCEAB.3080606@alcatel.fr> From: Robert Sparks Date: Wed, 5 Jul 2006 09:53:44 -0500 X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9724479da43a8325ad975c1a9b841870 Subject: [Sip] loop detection measurements (was Fwd: [Sipping] comments on loop detection anddraft-campen-sipping-stack-loop-detect-00) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1930963806==" Errors-To: sip-bounces@ietf.org --===============1930963806== Content-Type: multipart/alternative; boundary=Apple-Mail-2--142151341 --Apple-Mail-2--142151341 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Copying forward an older thread from SIPPING in case those =20 participating in the fork-loop-fix conversation here hadn't seen it. RjS Begin forwarded message: > From: Thomas Froment > Date: May 19, 2006 8:56:59 AM CDT > To: Jeroen van Bemmel > Cc: sipping@ietf.org > Subject: Re: [Sipping] comments on loop detection anddraft-campen-=20 > sipping-stack-loop-detect-00 > > Jeroen van Bemmel wrote: > >> Thomas, >> >> Very interesting to have some numbers here >> >> 260/305 ~ 15% less calls/sec with loop detection. That would be ~ =20 >> 15% CPU, iff it is at 100% for the whole test - is it? (you say =20 >> 13%, so perhaps you already compensated for this - I just want to =20 >> understand how you came to this conclusion) > > You are right, when doing a test, CPU is not busy at 100%, it is =20 > approximately between 85 and 90%. > It is to notice we perform this kind of tests on our implementation =20= > for a long time (based on sipstone, http://www.sipstone.org/), > and I am really confident in injector system and in the results and =20= > in general... > >> >> RFC3261 is wrong in many aspects of loop detection. > > Is it documented somewhere? did you find a bug describing these =20 > problems? > >> Could you run the same test, but this time only including the =20 >> request URI and the topmost Route header (if any) in the hash? > > The current version *already* includes the usage of request URI and =20= > the topmost Route header (only!) ... I did not even try to > test the previous algorithm.... > >> ----- Original Message ----- From: "Thomas Froment" =20 >> >> To: >> Sent: Friday, May 19, 2006 12:43 PM >> Subject: [Sipping] comments on loop detection anddraft-campen-=20 >> sipping-stack-loop-detect-00 >> >> >> Taking into account draft-ietf-sip-fork-loop-fix-01.txt which =20 >> recommends >> the support of RFC3261 loop detection algorithm (instead >> of the Max-Forwards mechanism), I would like to make some comments: >> >> 1/ The loop detection mechanism described in RFC 3261 seems =20 >> confusing in >> some points: >> >> - Section 16.6, =A78 (when sending the request, adding the loop =20 >> detection >> hash on branch parameter) says: >> >> " Loop detection is performed by verifying that, when a request =20 >> returns to a proxy, >> those fields having an impact on the processing of the request =20 >> have not changed. >> The value placed in this part of the branch parameter SHOULD =20 >> reflect all of >> those fields (including any Route, Proxy-Require and Proxy-=20 >> Authorization header fields). >> This is to ensure that if the >> request is routed back to the proxy and one of those fields >> changes, it is treated as a spiral and not a loop (see Section >> 16.3). (...)" >> >> First of all the "*fields having an impact on the processing of =20 >> the request have not changed*" is confusing >> for some people, because you really need to have a deep knowledge =20 >> of SIP protocol to be sure on this point. (And >> what about SIP extensions like Service Route?) >> >> Then "any Route" is, in my opinion confusing, is it really any =20 >> Route or only top most Route? >> I imagine this is only the top most route, and it would match the =20 >> statement " >> fields having an impact on the processing of the request", am I =20 >> wrong? >> >> Third, the last paragraph is even more confusing: >> "A common way to create this value is to compute a >> cryptographic hash of the To tag, =46rom tag, Call-ID header >> field, the Request-URI of the request received (before >> translation), the topmost Via header, and the sequence number >> from the CSeq header field, in addition to any Proxy-Require" >> >> - Here, no Route header is mentionned anymore (neither Proxy-=20 >> Authorization), should be clarified... >> - the "topmost Via header": this assertion is FALSE, if you take =20 >> the "branch parameter" of Via Header, to compute your hash, >> you will never detect any loop, since the generated branch will =20 >> always be different ! >> >> I first tried to find a bug in database, and only found one =20 >> problem related to loop detection: >> http://bugs.sipit.net/show_bug.cgi?id=3D648 >> "branch hash calculacation needs explicit comment for loop-=20 >> detecting proxies" >> Which is not pointing out the problem... >> >> Correct wording of the second paragraph may look like: >> "A common way to create this value is to compute a >> cryptographic hash of the To tag, =46rom tag, Call-ID header >> field, the Request-URI of the request received (before >> translation), the topmost Via header *without branch parameter*, =20 >> the sequence number >> from the CSeq header field, in addition to *the top most Route* =20 >> and any Proxy-Require or Proxy-Authorization header(s)*" >> >> >> 2/ Looking at "draft-campen-sipping-stack-loop-detect-00", we also =20= >> decided to bench the *existing* RFC 3261 algorithm >> to be able to evaluate if an optimization is needed. >> It is to mentionned, this bench was performed on a really =20 >> optimized SIP stack and the loop detection, as well, >> has been really carefully coded in order to minimize processing =20 >> and memory usage >> (just to anticipate objections like "is your algorithm really well =20= >> coded?): as an illustration, loop detection is not performed if >> a request is recognized as being a retransmission, and an =20 >> optimized MD5 implementation is used as hash algorithm... >> >> Doing a simple proxying scenario, >> using in injector the following "CALL ATTEMPT PER SECOND" (CAPS) =20 >> scenario: >> >> injector >> INVITE --------------> Proxy (under test) ---------------> server =20 >> (UAS test) >> >> 100 TRYING <---------- Proxy (under test) >> 180 RINGING <---------- Proxy (under test) <-------------- server >> 200 OK <---------- Proxy (under test) <-------------- server >> >> ACK ------------------> Proxy (under test) -------------> server >> BYE ------------------> Proxy (under test) -------------> server >> >> on a basic configuration, >> WITHOUT loop detection, result is ~ 305 CAPS >> WITH loop detection, result is ~ 260 CAPS >> It means, ~13% of CPU is used for this fonction for a basic =20 >> proxying scenario... >> >> We will try to provide the figures if we decide to implement draft-=20= >> campen-sipping-stack-loop-detect-00 >> algorithm but, at first, it seems valuable to think of clarifying =20 >> and/or optimizing current RFC 3261 algorithm... >> >> Thomas >> >> >> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP --Apple-Mail-2--142151341 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Copying forward an older thread = from SIPPING in case those participating in the fork-loop-fix = conversation here hadn't seen it.

RjS


Begin forwarded message:

From: = Thomas Froment <Thomas.Froment@alcatel.fr>= ;
Date: May 19, 2006 8:56:59 AM = CDT
To: Jeroen van Bemmel <jbemmel@zonnet.nl>
Cc: sipping@ietf.org
Subject: = Re: [Sipping] comments on loop detection = anddraft-campen-sipping-stack-loop-detect-00

Jeroen = van Bemmel wrote:

=
Thomas,

Very = interesting to have some numbers here

260/305 ~ 15% = less calls/sec with loop detection. That would be ~ 15% CPU, iff it is = at 100% for the whole test - is it? (you say 13%, so perhaps you already = compensated for this - I just want to understand how you came to this = conclusion)

You are right, when doing a = test, CPU is not busy at 100%, it is approximately between 85 and = 90%.
It is to notice we perform this = kind of tests on our implementation for a long time (based on sipstone, = http://www.sipstone.org/),
and I am really confident in injector system and in = the results and in general...


RFC3261 is = wrong in many aspects of loop detection.

Is it = documented somewhere? did you find a bug describing these = problems?

=
Could you run the same = test, but this time only including the request URI and the topmost Route = header (if any) in the hash?

The current = version *already* includes the usage of request URI and the topmost = Route header (only!) ... I did not even try to
test the previous algorithm....

----- Original Message ----- = From: "Thomas Froment" <Thomas.Froment@alcatel.fr>= ;
Sent: Friday, May 19, 2006 12:43 PM
Subject: [Sipping] comments on loop detection = anddraft-campen-sipping-stack-loop-detect-00


Taking into = account draft-ietf-sip-fork-loop-fix-01.txt which recommends
the support of RFC3261 loop detection algorithm = (instead
of the Max-Forwards mechanism), = I would like to make some comments:

1/ The loop detection mechanism = described in RFC 3261 seems confusing in
some = points:

- Section 16.6, =A78 (when sending the request, = adding the loop detection
hash on = branch parameter) says:

" Loop detection is performed by = verifying that, when a request returns to a proxy,
those fields having an impact on the processing of = the request have not changed.
The value = placed in this part of the branch parameter SHOULD reflect all = of
those fields (including any Route, = Proxy-Require and Proxy-Authorization header fields).
This is to ensure that if the
request is routed back to the proxy and one of those = fields
changes, it is treated as a = spiral and not a loop (see Section
16.3). = (...)"

First of all the "*fields having an impact on the = processing of the request have not changed*" is confusing
for some people, because you really need to have a = deep knowledge of SIP protocol to be sure on this point. (And
what about SIP extensions like Service = Route?)

Then "any Route" is, in my opinion confusing, is it = really any Route or only top most Route?
I = imagine this is only the top most route, and it would match the = statement "
fields having an impact on the = processing of the request", am I wrong?

Third, the = last paragraph is even more confusing:
"A = common way to create this value is to compute a
cryptographic hash of the To tag, =46rom tag, = Call-ID header
field, the Request-URI of the = request received (before
translation), = the topmost Via header, and the sequence number
from the CSeq header field, in addition to any = Proxy-Require"

- Here, no Route header is mentionned anymore = (neither Proxy-Authorization), should be clarified...
- the "topmost Via header":=A0 this assertion is FALSE, if = you take the "branch parameter" of Via Header, to compute your = hash,
you will never detect any loop, = since the generated branch will always be different !

I first = tried to find a bug in database, and only found one problem related to = loop detection:
"branch hash = calculacation needs explicit comment for loop-detecting = proxies"
Which is not pointing out the = problem...

Correct wording of the second paragraph may look = like:
"A common way to create this = value is to compute a
cryptographic hash of the = To tag, =46rom tag, Call-ID header
field, the = Request-URI of the request received (before
from the CSeq header field, in = addition to *the top most Route* and any Proxy-Require or = Proxy-Authorization header(s)*"


2/ Looking at = "draft-campen-sipping-stack-loop-detect-00", we also decided to bench = the *existing* RFC 3261 algorithm
to be able to = evaluate if an optimization is needed.
It is to = mentionned, this bench was performed on a really optimized SIP stack and = the loop detection, as well,
has been = really carefully coded in order to minimize processing and memory = usage
(just to anticipate objections = like "is your algorithm really well coded?): as an illustration, loop = detection is not performed if
a request is = recognized as being a retransmission, and an optimized MD5 = implementation is used as hash algorithm...

Doing a = simple proxying scenario,
using in = injector the following "CALL ATTEMPT PER SECOND" (CAPS) = scenario:

injector
INVITE = --------------> Proxy (under test) ---------------> server (UAS = test)

100 TRYING=A0 = <---------- Proxy (under test)
180 = RINGING <---------- Proxy (under test) <-------------- = server
200 OK=A0 =A0 =A0 <---------- Proxy = (under test) <-------------- server

ACK = ------------------> Proxy (under test) ------------->=A0 server
BYE ------------------> Proxy (under test) = ------------->=A0 = server

on a basic configuration,
WITHOUT loop detection, result is ~ 305 = CAPS
WITH loop detection, result is ~ = 260 CAPS
It means, ~13% of CPU is used = for this fonction for a basic proxying scenario...

We will = try to provide the figures if we decide to implement = draft-campen-sipping-stack-loop-detect-00






This list is = for NEW development of the application of SIP
Use sip-implementors@cs.colum= bia.edu for questions on current sip
Use sip@ietf.org for new developments of = core SIP=A0
=



This list is = for NEW development of the application of SIP
Use sip-implementors@cs.colum= bia.edu for questions on current sip
Use sip@ietf.org for new developments of = core SIP

= --Apple-Mail-2--142151341-- --===============1930963806== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1930963806==-- From sip-bounces@ietf.org Wed Jul 05 11:25:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9EB-0002fd-Nq; Wed, 05 Jul 2006 11:23:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9EA-0002fV-3W for sip@ietf.org; Wed, 05 Jul 2006 11:23:46 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy9E8-0003dm-G8 for sip@ietf.org; Wed, 05 Jul 2006 11:23:46 -0400 Received: (qmail 5608 invoked by uid 0); 5 Jul 2006 15:23:37 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Jul 2006 15:23:37 -0000 Message-ID: <016801c6a046$fdc50420$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" , "Miguel Garcia" References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Wed, 5 Jul 2006 17:23:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen, see inline, Regards, jeroen > > My impression of what the WG wanted was that the service provider could > provide between 1 and the max number the UA supported of URIs. The UA > must implement support for at least 2 and should support 4. > yes, agree. And "the service provider SHOULD provide at least 2" I suppose > So let's say that the domain use two and this domains has to have two do > to reliability. If the UA has "local policy" and only decided to use > one - things don't work. This depends on the definition of "work". The resillience against certain types of failures is less, but things will work provided no such failures occur. > I think this is more or less the same as if you are doing a single > registration and the registry tells you your registration expires after 1 > hour but the UA decided to refresh after two hours to reduce network > load, well things are broken. > This is a clear case because *it is the UAs responsibility to stay registered*. In this scenario, we would say that specifically the UA is broken (RFC3261 section 10.2.4 : "Each UA is responsible for refreshing the bindings that it has previously established.") Things are not so clear cut for outbound. The question is: who is responsible for achieving a certain level of reliability? who decides what is sufficient? > Now you say that the UA might decide by local policy if it wanted to do > say 1 or 2 flows - but where will this local policy come from? The end > user is not going too provide it. I suspect the domain will provide it. > I'm fine with some times the domain tells the UA to use 1 uri and other > times two. I can imagine the domain changing this configuration as the UA > moves from different types of access networks. > This type of policy could very well be implemented in the UA, in fact it may be in a better position to estimate the reliability of the access network(s) it is connected to (eg by monitoring channel conditions). Therefore, a model in which the UA decides how many flows it uses is defendable too. The decision on the number of flows depends on the desired level of reliability, which in turn depends on the failure characteristics of a number of things including the access network, any NAT devices, any edge proxies, and the home proxy. What if we adopt a modus operandi in which the UA decides what level of reliability it desires and (thus) how many flows it needs, and the domain provides information to support this decision (eg MTBF figures for the registrar, or derived information such as a *suggestion* for the number of flows) > I expect you are right in that this MUST is too strong here but I think > there is an argument for SHOULD. The problem is that if the domain assume > the UA is doing two flows and the UA does one, things are broken. > Not from the point of view of the UA, it is getting exactly the level of reliability that it would expect from one flow. What reason would the domain have to assume anything about the number of flows the UA is using? > > > On Jul 5, 2006, at 3:44 AM, Miguel Garcia wrote: > >> Reading Section 4.2 of Outbound-04, there is a sentence that came to my >> attention. >> >> For each outbound proxy URI in the set, the UA MUST send a >> REGISTER in the normal way using this URI as the default outbound >> proxy. >> >> I think it is not appropriate to use a MUST strength in this case. I >> suspect that the spirit of the draft is to offer high availability by >> making the UA to establish one flow per URI, which is a good spirit. >> However, one has to evaluate the cost of establishing one flow per URI, >> which might be quite high in terms of battery consumption, for example >> (due to STUN refreshes). >> >> I also believe the MUST is misused here because it is not an absolute >> requirement for the specification. In other words, the SIP outbound >> procedures work OK even if the UA establishes just one flow (even when >> it is provisioned with several outbound URIs). Nothing is broken. >> >> So, we should be looking at adding a paragraph that describes the >> benefit of establishing one flow per outbound URI, but letting up to the >> UA's policy to decide on the absolute number of established flows. >> >> I would suggest to replace the above mentioned sentence with something >> around these lines: >> >> For each outbound proxy URI in the set, the UA MAY send a >> REGISTER in the normal way using this URI as the default outbound >> proxy. Sending one REGISTER per outbound proxy URI decreases the >> likelihood of interrupted service due to dropped connections at the >> cost of maintaining a living flow which each outbound proxy server. >> >> Comments? >> >> /Miguel >> >> -- >> Miguel A. Garcia tel:+358-50-4804586 >> sip:miguel.an.garcia@openlaboratory.net >> Nokia Research Center Helsinki, Finland > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 11:32:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9KY-0003KU-Ol; Wed, 05 Jul 2006 11:30:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9KX-0003KO-Im for sip@ietf.org; Wed, 05 Jul 2006 11:30:21 -0400 Received: from mx0.aculab.com ([213.249.233.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy9KW-0003uY-36 for sip@ietf.org; Wed, 05 Jul 2006 11:30:21 -0400 Received: from localhost (localhost [127.0.0.1]) by mx0.aculab.com (Postfix) with ESMTP id 194BD8738C for ; Wed, 5 Jul 2006 16:30:18 +0100 (BST) Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17203-01 for ; Wed, 5 Jul 2006 16:30:02 +0100 (BST) Received: from saturn2.Aculab.com (saturn [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id 7FDA487520 for ; Wed, 5 Jul 2006 16:22:44 +0100 (BST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 x-mimeole: Produced By Microsoft Exchange V6.5 Date: Wed, 5 Jul 2006 16:22:43 +0100 Message-ID: <00D42150952F70458C66072322F7FE250B0A47@saturn2.Aculab.com> In-Reply-To: <20060704155845.65D3F1CC22@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Thread-Index: AcafgvAK6XwxecckR4yqfMFalFr3hwAwnxZQ From: "Matthew Gardiner" To: "EKR" X-Aculab-Com-Scanned: by amavisd-new-20030616-p10 (Debian) at aculab.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, >In particular, the downstream cipher suites always narrow and never = grow. I don't see that this is the case with Samir's scheme. Consider the case = below where A wants to talk to D, via B and C: B ---------------------- C / \ / \ / \=20 A D A, C and D all support cipher suites x,y and z. B only supports x. Just = because the hops AB and BC must negotiate cipher suite x, it does not = prevent hop CD negotiating anything from the range x,y,z. That was my (brief) understanding of Samir's proposal. I can't see where = the narrowing occurs, though obviously the range of suites will not = grow. Matthew Gardiner Software Enginneer Aculab -----Original Message----- From: EKR [mailto:ekr@networkresonance.com] Sent: 04 July 2006 16:59 To: sip@ietf.org Subject: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Because TLS is used in SIP in hop-by-hop mode, the cipher suite that you negotiate with your first hop proxy is no guarantee of what will be negotiated with future proxies. Consider the classic trapezoid: Atlanta ---------------------- Biloxi / \ / \ / \=20 alice@atlanta bob@biloxi Alice can negotiate AES-256 with Atlanta but then have Atlanta negotiate RC4-40 with Biloxi. This draft suggests a series of extensions to SIP to carry the initial client's preferences and that proxies further down the chain are expected to enforce. It seems to me that there is a simpler mechanism: any proxy X can only offer the intersection of the cipher suites that was offered to it and the ciphersuites that it is willing to support. This has the result that no downstream proxy can negotiate a cipher suite that Alice wasn't willing to negotiate with Atlanta.=20 There are two obvious disadvantages with respect to the proposed draft: 1. Alice doesn't get any signal of what was eventually negotiated. I would solve this problem by extending Via (I'm actually surprised this isn't done). MTAs typically put it in Received lines, FWIW... 2. It's less expressive. In particular, the downstream cipher suites always narrow and never grow. So, if there were a third proxy in between Atlanta and Biloxi that only spoke DES, then Biloxi and Bob would only get DES even if they both spoke AES. Based on my = experience with what real implementations support and the MUST for AES, I'm not much concerned about this. It's generally impossible to pickle the full client policy and have it sent to a proxy. It's mostly a matter of where you draw the line, and drawing it where the protocol already draws it seems natural. The big advantage of the approach I propose is that it doesn't require any new mechanisms and can be incrementally deployed in an interoperable way. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 11:34:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9N6-0003rt-2Z; Wed, 05 Jul 2006 11:33:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9N5-0003rS-0N for sip@ietf.org; Wed, 05 Jul 2006 11:32:59 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy9N3-00040u-Fw for sip@ietf.org; Wed, 05 Jul 2006 11:32:58 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 8E5EC1E8C1F; Wed, 5 Jul 2006 08:32:55 -0700 (PDT) To: "Matthew Gardiner" Subject: Re: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 References: <00D42150952F70458C66072322F7FE250B0A47@saturn2.Aculab.com> From: Eric Rescorla Date: Wed, 05 Jul 2006 08:32:55 -0700 In-Reply-To: <00D42150952F70458C66072322F7FE250B0A47@saturn2.Aculab.com> (Matthew Gardiner's message of "Wed, 5 Jul 2006 16:22:43 +0100") Message-ID: <867j2soymw.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Matthew Gardiner" writes: > Hi Eric, > >>In particular, the downstream cipher suites always narrow and never grow. > > I don't see that this is the case with Samir's scheme. Consider the case below where A wants to talk to D, via B and C: > > B ---------------------- C > / \ > / \ > / \ > A D > > A, C and D all support cipher suites x,y and z. B only supports x. Just because the hops AB and BC must negotiate cipher suite x, it does not prevent hop CD negotiating anything from the range x,y,z. > > That was my (brief) understanding of Samir's proposal. I can't see where the narrowing occurs, though obviously the range of suites will not grow. No, that's a disadvantage of the scheme I proposed. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 11:47:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9ZA-0005sN-96; Wed, 05 Jul 2006 11:45:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9Z8-0005qX-Pu for sip@ietf.org; Wed, 05 Jul 2006 11:45:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8xu-0002nj-0s for sip@ietf.org; Wed, 05 Jul 2006 11:06:58 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy8jW-0002Vx-6C for sip@ietf.org; Wed, 05 Jul 2006 10:52:08 -0400 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k65Eocs6092645 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Jul 2006 09:50:41 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <532B18E13CF9E64380EF5FDDE265E0711228AC@blr-m2-msg.wipro.com> References: <532B18E13CF9E64380EF5FDDE265E0711228AC@blr-m2-msg.wipro.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <198E95FB-598E-4CD3-98D3-054B5D37CFFB@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Update to fork-loop-fix submitted Date: Wed, 5 Jul 2006 09:50:33 -0500 To: "" X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: -2.6 (--) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I understand the suggestion. You are trading off letting the request through a loop one extra cycle for some lower amount of processing the first time the request went through the proxy. If you believe that spirals are relatively rare things, this change would result in proxies very rarely having to build the loop/spiral differentiation hash. But as Jonathan points out, it's not clear that the hash computation is expensive enough to warrant this extra logic and the extra network traffic it would allow. I expect that the hash calculation expense is small compared to the parse/search/compare operations for "Proxy checks to see if its address is there in the via already". RjS On Jul 3, 2006, at 5:39 AM, wrote: > > Hi Robert, > > I had suggested one more alternative > > (http://www1.ietf.org/mail-archive/web/sip/current/msg14359.html ) > > Quoted from my previous mail: > > > I was thinking how to reduce the impact of overhead for calculating > the > digest. > > If it is suggested as follows, I think it will reduce the overhead on > normal scenarios: > > Proxy checks to see if its address is there in the via already. > If it is not there, it proceeds normally without calculating the > digest > and inserting Via to the outgoing request without the digest. > If it is there, then it is possible that the request is looping. So, > this time around, it calculates a digests and inserts and sends it > along. > If it is looping, the request will definitely come in again, which can > be rejected. > This way the impact of calculating the digest is required (reduced > to a > smaller percent of the sessions) only when the proxy is suspicious the > request might be looping. > Of course this results in the scenarios mentioned in the id to be > successful in completing the first loop, but the second loop will be > detected and arrested. I think this can be applicable to general loop > detection, and not just fork loop fixes. > > > Regards, > Ravi. > > -- > > Ravishankar. G. Shiroor > Wipro Technologies, Bangalore. > > ravishankar.shiroor@wipro.com > -- > > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: Sunday, June 25, 2006 8:22 PM >> To: IETF SIP List >> Subject: [Sip] Update to fork-loop-fix submitted >> >> Until it appears in the repository, see: >> http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-02.txt >> >> This was a moderately heavy touch - based on list feedback, >> I've moved and updated the sections covering the >> loopdetection algorithm in from 3261. In the process of >> writing the clarifying text, I discovered several places that >> need clarification. They are listed as Open Issues in the >> draft. Basically there are fields that I can't recall or >> reconstruct how they would be useful in the part of the hash >> used for loop-detection or spiral differentiation. If anyone >> can remember why they need to be included, send a note to the >> list and we'll capture that in the draft. >> >> Please review the updated loop-detection text very carefully. >> >> Here's the changelog from the draft: >> >> Integrated several editorial fixes suggested by >> Jonathan Rosenberg >> >> Noted that the reduction of the attack to a single >> registration >> against a single URI as documented in previous versions, >> is, in >> fact, going to be effective against implementations >> conforming to >> the standards before this repair. >> >> Re-incorporated motivation from the original >> maxforwards-problem >> draft into the security considerations section based >> on feedback >> from Cullen Jennings >> >> Introduced replacement text for the loop detection algorithm >> description in RFC 3261, fixing the bug 648 (the >> topmost Via value >> must not be included in the second part) and clarifying the >> algorithm. Removed several other fields suggested by 3261 and >> placed open issues around their presence. >> >> Added a Notes to Implementors section capturing the >> "common way" >> text and pointing to the interoperability issues that have >> been >> observed with loop detection at previous SIPits >> >> >> Thanks, >> >> RjS >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of > the addressee(s) and may contain proprietary, confidential or > privileged information. If you are not the intended recipient, you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately and destroy all copies of this > message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The > recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any > damage caused by any virus transmitted by this email. > > www.wipro.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 12:35:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAJT-00082H-2B; Wed, 05 Jul 2006 12:33:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAJR-000827-9s for sip@ietf.org; Wed, 05 Jul 2006 12:33:17 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyAJQ-00005L-1Y for sip@ietf.org; Wed, 05 Jul 2006 12:33:17 -0400 Received: from hkaplan [10.0.200.167] by acmepacket.com with ESMTP (SMTPD-9.03) id A9C60690; Wed, 05 Jul 2006 12:33:10 -0400 From: "Hadriel Kaplan" To: "'Cullen Jennings'" Subject: RE: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Wed, 5 Jul 2006 12:33:11 -0400 Message-ID: <02ef01c6a050$b49e9f40$a7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <91641765-1056-4D33-9828-8090A246483C@cisco.com> Thread-Index: Acad+VCFUD2yCgaFSQiZTYroEucgGQCVSHVQ X-Spam-Score: 1.2 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Sunday, July 02, 2006 1:02 PM > > On Jun 30, 2006, at 12:57 PM, Hadriel Kaplan wrote: > > > I agree with you, but it is used for detecting suspicious From > > headers even > > for non-anonymous calls. Obviously if the proxy inserting the PAI > > _knows_ a > >> From is spoofed, it could/should reject it. But if the proxy does > >> _not_ > > know whether the From is spoofed or not, it just doesn't insert the > > PAI. > > For example, ingress proxy receives a request from another domain - > > if it > > trusts the domain it passes the PAI (or inserts one). If it does > > not trust > > the domain, it removes PAI, but doesn't want to reject the request > > (else it > > wouldn't accept requests from such untrusted domains to begin with). > > I see your point, I can see how a proxy that is deciding not to > remove a PAI might not know a From was spoofed. I don't see how a > proxy that was going to *insert* a PAI would know what to put in the > PAI and not be able to know if a PAI was spoofed. I'm not sure I follow - maybe you meant the word "From" instead of "PAI" in the "if a PAI was spoofed" bit? I meant in the context of implicitly trusted connections. For example: an operator receiving a request from a directly-attached business customer proxy, where the operator's ingress proxy may insert a PAI of bob@company.com based on the From, even though company.com's egress proxy did not insert the PAI itself. Obviously for an anonymous request the ingress proxy would not know enough to put that URI in, and it's certainly the case that it can't be 100% sure that the request really came from bob to begin with (e.g., the company proxy could be hijacked, etc.). But that could be the case with Identity in use as well. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 13:54:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyBYf-00016q-PN; Wed, 05 Jul 2006 13:53:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyBYe-00016l-QA for sip@ietf.org; Wed, 05 Jul 2006 13:53:04 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyBYd-0006uS-Ex for sip@ietf.org; Wed, 05 Jul 2006 13:53:04 -0400 Received: from [131.161.248.87] (open-131-161-248-87.cliq.com [131.161.248.87]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k65HqfF19229; Wed, 5 Jul 2006 10:52:42 -0700 In-Reply-To: <005c01c6a00c$47763a20$31713b51@BEMBUSTER> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com><553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com><003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> <005c01c6a00c$47763a20$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Wed, 5 Jul 2006 10:52:44 -0700 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, Juha Heinanen , dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen, I'd like to address this one point. My recollection from Dallas is that we had a very strong consensus that the existence of keepalive=stun was sufficient to send STUN messages. Based on this, I think we need to make it a requirement of the configuration mechanism that you can depend on its result to have accurate keepalive information. thanks, -rohan On Jul 5, 2006, at 1:23, Jeroen van Bemmel wrote: > 4 - I am argueing: "MUST check provisioned keepalive=stun" is not > sufficient, because the configuration may be incorrect (for various > reasons, also depending on what you use for provisioning). As an > additional check, we need "MUST check confirmation from proxy" > > We cannot depend only on the configuration mechanism (which is still > TBD, and in principle open ended) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 14:12:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyBpn-0003un-M6; Wed, 05 Jul 2006 14:10:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyBpl-0003ui-Kn for sip@ietf.org; Wed, 05 Jul 2006 14:10:45 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyBpl-0007yo-Ag for sip@ietf.org; Wed, 05 Jul 2006 14:10:45 -0400 Received: from hkaplan [10.0.200.167] by acmepacket.com with ESMTP (SMTPD-9.03) id A0A30450; Wed, 05 Jul 2006 14:10:43 -0400 From: "Hadriel Kaplan" To: "'Cullen Jennings'" Subject: RE: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Wed, 5 Jul 2006 14:10:44 -0400 Message-ID: <02f601c6a05e$55668570$a7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <48807FA4-2A3A-4EA6-99F5-96DDEFD6611E@cisco.com> Thread-Index: Acad+3HnvYr0J/q9QuukxR7J6JyCywCVUSAQ X-Spam-Score: 1.2 (+) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Sunday, July 02, 2006 1:18 PM > > On Jun 30, 2006, at 2:59 PM, Hadriel Kaplan wrote: > > > If a b2bua before that proxy but in the same trust domain verified the > > identity, and can somehow tell the proxy it verified the identity, > > and even > > tell the UAS it did as well, why do more? That's what the PAI > > does. It may > > not be what it was supposed to do, but it's what it seems to now. > > So in the case of an anonymous call where the real caller identity is > in the PAI for malicious call trace reasons, what are you proposing > to do. Does the proxy strip the PAI before sending it to the UAS? > How would the proxy know? Do you deliver the PAI to the UA - this > would violate privacy laws in Europe. I don't see how this would work. I don't see how that's germane to the Identity issue? Is there Identity support for anonymous requests? (I thought not) The UAS clearly cannot distinguish a trusted identity for such a request, since there is no anonymous identity. If you mean how does the proxy know to do so for only anonymous requests while not the others? You tell me - you wrote the spec. :) Operators seem to do every permutation possible. Some just have a rule where all PAI's for all requests get stripped at the edge proxy right before the UAS, others do it only if priv-value=id, some for any priv-value, some don't strip it at all. Is your point if the trust domain is not the same, and if the edge proxy strips them all, then the UAS won't know it's a verified identity? > > But for transit cases: it requires the transit domain(s) to either > > (1) not > > muck with contact, call-id, and bodies, or (2) support identity, > > and to > > somehow re-sign with something that the verifier in the next domain > > (s) will > > accept, which goes back to hop-by-hop trust kinda. But changing > > (1) or (2) > > is out of the local (and final) domain's control to change - they > > need the > > transit domain(s) to change, and that's a much bigger hurdle. > > Ok, I am done't think I am manging to explaim myself. Say A has a > contract with B and B has a crontract with C. Now a call arrives at > C, it seem that C wants a assertion to be made by B. Anything A says > to C is clsoe to useless because C has no clue who A even is. I guese > I feel like we need to sort out the requirements for what we want in > a transit case and then we might be able to figure out a solution. Yup, we need to sort out the reqs. In my mind your A-B-C scenario above doesn't need or benefit from Identity, much (or it just moves the same problem one step away). > > What about just splitting it into 2 Identity headers/signatures? > > One for > > the From and nonce-ish stuff, the other for the body and same nonce- > > ish > > stuff. If a middle-man wants to modify the body, he verifies and > > re-signs > > that second signature, or if the middle-man is unaware of identity > > then the > > next one can decide what to do with a bad signature for a body but > > good > > signature for From. > > The From itself has no intrinsic value - what you are trying to sign > is that some body came from the person in the From header. If the > From header and it's signature can be cut and paste from one message > to another, Identity would fail to solve any security problems. It has value - at least for the publicly stated benefits of Identity being useful for SPIT prevention. It can't be cut/paste anymore easily than the body also being signed. Its hash still includes the To-uri, call-id, date, and CSeq bits. If you can cut/paste that info for re-use, you can do it even if the body is also signed. (although at least with a signed body it would make it hard to fully establish a pasted call with media, or whatever) > > This way a b2bua can change the body but doesn't have to have a > > certificate > > matching the From-uri domain to do so, and the UAS can decide if > > it's kosher > > for the b2bua-domain to change the body, while also verifying the > > From is of > > the right domain. I haven't thought it through, but it sounds ok. > > You are proposing almost exactly the same thing I am. The way you are > thinking of handling the body, just use that handling for both. Except your's requires the middlemen to support Identity-coexistence or else everything breaks - if they don't then the UAS won't know if anything in the received request is correct, or if only the body got modified - even if only the body got modified. (of course for some the body is the whole enchilada) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 14:24:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyC1P-0004vT-1m; Wed, 05 Jul 2006 14:22:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyC1N-0004vO-GZ for sip@ietf.org; Wed, 05 Jul 2006 14:22:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyC1N-0008Ta-1e for sip@ietf.org; Wed, 05 Jul 2006 14:22:45 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2006 14:22:45 -0400 X-IronPort-AV: i="4.06,210,1149480000"; d="scan'208"; a="91717712:sNHT34774976" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k65IMiYL025445; Wed, 5 Jul 2006 14:22:44 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jul 2006 14:22:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Wed, 5 Jul 2006 14:22:43 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301A5AF56@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Thread-Index: AcagRxBmiWbzAI+VRr2qgDvsIOMy/QAF8XTQ From: "Michael Hammer \(mhammer\)" To: "Jeroen van Bemmel" , "Cullen Jennings \(fluffy\)" , "Miguel Garcia" X-OriginalArrivalTime: 05 Jul 2006 18:22:44.0197 (UTC) FILETIME=[02444150:01C6A060] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen, If there are two flows available and one fails, then there is less urgency to doing the registration refresh. In other words less of a need to do an avalanche restart. I would hope that the UA would appreciate that there is more to reliability than just the one connection it cares about. Because the UA does not have the visibility that the proxy does, it might allow this type of decision to be deferred to the network. Network operators may need to provide such guidance to maintain the network's stability or deny the UA access altogether. It would be good if the implementations of UA and Proxy would support the possibility of such a negotiation. Mike =20 > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: Wednesday, July 05, 2006 11:24 AM > To: Cullen Jennings (fluffy); Miguel Garcia > Cc: sip@ietf.org; Rohan Mahy > Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 >=20 > Cullen, >=20 > see inline, >=20 > Regards, >=20 > jeroen >=20 >=20 > > > > My impression of what the WG wanted was that the service provider =20 > > could provide between 1 and the max number the UA supported=20 > of URIs. =20 > > The UA must implement support for at least 2 and should support 4. > > >=20 > yes, agree. And "the service provider SHOULD provide at least=20 > 2" I suppose >=20 > > So let's say that the domain use two and this domains has=20 > to have two =20 > > do to reliability. If the UA has "local policy" and only=20 > decided to =20 > > use one - things don't work. >=20 > This depends on the definition of "work". The resillience=20 > against certain types of failures is less, but things will=20 > work provided no such failures occur. >=20 > > I think this is more or less the same as if you are doing a single=20 > > registration and the registry tells you your registration expires=20 > > after 1 hour but the UA decided to refresh after two hours=20 > to reduce=20 > > network load, well things are broken. > > >=20 > This is a clear case because *it is the UAs responsibility to=20 > stay registered*. In this scenario, we would say that=20 > specifically the UA is broken (RFC3261 section 10.2.4 : "Each=20 > UA is responsible for refreshing the bindings that it has=20 > previously established.") >=20 > Things are not so clear cut for outbound. The question is:=20 > who is responsible for achieving a certain level of=20 > reliability? who decides what is sufficient? >=20 > > Now you say that the UA might decide by local policy if it=20 > wanted to =20 > > do say 1 or 2 flows - but where will this local policy come=20 > from? The =20 > > end user is not going too provide it. I suspect the domain=20 > will provide it. > > I'm fine with some times the domain tells the UA to use 1 uri and=20 > > other times two. I can imagine the domain changing this =20 > configuration=20 > > as the UA moves from different types of access networks. > > >=20 > This type of policy could very well be implemented in the UA,=20 > in fact it may=20 > be in a better position to estimate the reliability of the=20 > access network(s)=20 > it is connected to (eg by monitoring channel conditions).=20 > Therefore, a model=20 > in which the UA decides how many flows it uses is defendable too. >=20 > The decision on the number of flows depends on the desired level of=20 > reliability, which in turn depends on the failure=20 > characteristics of a=20 > number of things including the access network, any NAT=20 > devices, any edge=20 > proxies, and the home proxy. >=20 > What if we adopt a modus operandi in which the UA decides=20 > what level of=20 > reliability it desires and (thus) how many flows it needs,=20 > and the domain=20 > provides information to support this decision (eg MTBF=20 > figures for the=20 > registrar, or derived information such as a *suggestion* for=20 > the number of=20 > flows) >=20 > > I expect you are right in that this MUST is too strong here=20 > but I think=20 > > there is an argument for SHOULD. The problem is that if the=20 > domain assume=20 > > the UA is doing two flows and the UA does one, things are broken. > > >=20 > Not from the point of view of the UA, it is getting exactly=20 > the level of=20 > reliability that it would expect from one flow. What reason=20 > would the domain=20 > have to assume anything about the number of flows the UA is using? >=20 > > > > > > On Jul 5, 2006, at 3:44 AM, Miguel Garcia wrote: > > > >> Reading Section 4.2 of Outbound-04, there is a sentence=20 > that came to my=20 > >> attention. > >> > >> For each outbound proxy URI in the set, the UA MUST send a > >> REGISTER in the normal way using this URI as the=20 > default outbound > >> proxy. > >> > >> I think it is not appropriate to use a MUST strength in=20 > this case. I=20 > >> suspect that the spirit of the draft is to offer high =20 > availability by=20 > >> making the UA to establish one flow per URI, which is a=20 > good spirit.=20 > >> However, one has to evaluate the cost of establishing one=20 > flow per URI,=20 > >> which might be quite high in terms of battery=20 > consumption, for example=20 > >> (due to STUN refreshes). > >> > >> I also believe the MUST is misused here because it is not=20 > an absolute=20 > >> requirement for the specification. In other words, the SIP=20 > outbound=20 > >> procedures work OK even if the UA establishes just one =20 > flow (even when=20 > >> it is provisioned with several outbound URIs). Nothing is broken. > >> > >> So, we should be looking at adding a paragraph that describes the=20 > >> benefit of establishing one flow per outbound URI, but=20 > letting up to the=20 > >> UA's policy to decide on the absolute number of established flows. > >> > >> I would suggest to replace the above mentioned sentence=20 > with something=20 > >> around these lines: > >> > >> For each outbound proxy URI in the set, the UA MAY send a > >> REGISTER in the normal way using this URI as the=20 > default outbound > >> proxy. Sending one REGISTER per outbound proxy URI decreases the > >> likelihood of interrupted service due to dropped=20 > connections at the > >> cost of maintaining a living flow which each outbound=20 > proxy server. > >> > >> Comments? > >> > >> /Miguel > >> > >> --=20 > >> Miguel A. Garcia tel:+358-50-4804586 > >> sip:miguel.an.garcia@openlaboratory.net > >> Nokia Research Center Helsinki, Finland > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 14:31:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyC8Y-0005dO-B5; Wed, 05 Jul 2006 14:30:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyC8W-0005dJ-Jo for sip@ietf.org; Wed, 05 Jul 2006 14:30:08 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyC8V-0000Hq-CE for sip@ietf.org; Wed, 05 Jul 2006 14:30:08 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k64MFsXM011467; Tue, 4 Jul 2006 17:15:55 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3JB91PQ0>; Tue, 4 Jul 2006 23:15:53 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0134D278D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Subject: RE: [Sip] Comments on draft-ietf-sip-outbound-04 Date: Tue, 4 Jul 2006 23:15:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Of the comments that I made, comment 12) does not apply. I misremembered the relationship between these two documents - it changed before IETF #65. It also means if you want GRUU, you've got to get outbound finished. regards Keith > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 03 July 2006 19:28 > To: sip@ietf.org > Cc: Cullen Jennings; Rohan Mahy > Subject: [Sip] Comments on draft-ietf-sip-outbound-04 > > > Herewith my comments on the above document. > > 12) GRUU currently defined as an informative reference. > Given that it defines the instance id which is needed for > this protocol, I would have thought it needed to be normative. > > > regards > > Keith > > > Keith Drage > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 14:46:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyCML-0006IE-DD; Wed, 05 Jul 2006 14:44:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyCMK-0006I6-Pk for sip@ietf.org; Wed, 05 Jul 2006 14:44:24 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyCMJ-0001eC-Br for sip@ietf.org; Wed, 05 Jul 2006 14:44:24 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k65IiCpE031019; Wed, 5 Jul 2006 21:44:15 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 21:43:46 +0300 Received: from [10.162.17.63] ([10.162.17.63]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 5 Jul 2006 21:43:46 +0300 Message-ID: <44AC0861.1020604@nokia.com> Date: Wed, 05 Jul 2006 21:43:45 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Cullen Jennings References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> In-Reply-To: <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2006 18:43:46.0724 (UTC) FILETIME=[F2CA9640:01C6A062] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org, Rohan Mahy Subject: [Sip] Re: A coment to draft-ietf-sip-outbound-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > > > I expect you are right in that this MUST is too strong here but I think > there is an argument for SHOULD. The problem is that if the domain > assume the UA is doing two flows and the UA does one, things are broken. > I would like to understand which part of the outbound mechanism is broken if the domain assumes the UE will do two flows, but the UA does one flow. Yes, it isn't reliable, but the mechanism works nicely... or not? Then... why can't a domain indicate just one outbound URI? At the moment the draft has an artificial lower limit for all the domains to provide two URIs and impose a reliability that might not be required/needed. I still think that it makes sense to enable the possibility of the network to provide a minimum of URI, although it is not the recommended behavior. With respect the MUST strength... I can accept a SHOULD as well. BR, Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 14:50:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyCQM-000752-Lm; Wed, 05 Jul 2006 14:48:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyCQK-00074w-Qe for sip@ietf.org; Wed, 05 Jul 2006 14:48:32 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyCQJ-0002fk-5V for sip@ietf.org; Wed, 05 Jul 2006 14:48:32 -0400 Received: from BPenfield [10.0.200.6] by acmepacket.com with ESMTP (SMTPD-9.03) id A9690618; Wed, 05 Jul 2006 14:48:09 -0400 Message-ID: <006501c6a063$90620ff0$800101df@acmepacket.com> From: "Bob Penfield" To: "Rohan Mahy" , "Jeroen van Bemmel" References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com><553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com><003e01c69fb1$ad32e760$31713b51@BEMBUSTER><17579.25760.584180.394914@rautu.tutpro.com><005c01c6a00c$47763a20$31713b51@BEMBUSTER> Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Wed, 5 Jul 2006 14:48:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, Juha Heinanen , dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline ----- Original Message ----- From: "Rohan Mahy" To: "Jeroen van Bemmel" Cc: "Cullen Jennings" ; "Rohan Mahy" ; ; "Juha Heinanen" ; Sent: Wednesday, July 05, 2006 1:52 PM Subject: Re: [Sip] Ready for WGLC on Outbound? > Jeroen, > > I'd like to address this one point. My recollection from Dallas is that > we had a very strong consensus that the existence of keepalive=stun was > sufficient to send STUN messages. > > Based on this, I think we need to make it a requirement of the > configuration mechanism that you can depend on its result to have > accurate keepalive information. Does that mean that a UA should not send STUN if the keepalive=stun is not present? If so, will outbound be useful prior to the completion of the various configuration mechanisms? And is it acceptable for a mis-configured UA to cause the proxy or the registrar to crash or mis-behave? A mechanism such as the proposed Proxy-Require/Require method similar to sec-agree allows the UA to determine that the proxy and registrar support STUN before it sends and potentially harmful messages. cheers, (-:bob > > thanks, > -rohan > > On Jul 5, 2006, at 1:23, Jeroen van Bemmel wrote: >> 4 - I am argueing: "MUST check provisioned keepalive=stun" is not >> sufficient, because the configuration may be incorrect (for various >> reasons, also depending on what you use for provisioning). As an >> additional check, we need "MUST check confirmation from proxy" >> >> We cannot depend only on the configuration mechanism (which is still TBD, >> and in principle open ended) > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 15:00:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyCaJ-0002lK-AK; Wed, 05 Jul 2006 14:58:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyCaH-0002eN-Bz for sip@ietf.org; Wed, 05 Jul 2006 14:58:49 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyCaG-0005Gm-0Y for sip@ietf.org; Wed, 05 Jul 2006 14:58:49 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 6FA9013F920; Wed, 5 Jul 2006 21:58:41 +0300 (EEST) Received: from rautu (eukaryote169.gprs.dnafinland.fi [62.78.106.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 13E7113F91D; Wed, 5 Jul 2006 21:58:21 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id B0DA0F03C1; Wed, 5 Jul 2006 21:58:33 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17580.3033.661988.839303@rautu.tutpro.com> Date: Wed, 5 Jul 2006 21:58:33 +0300 From: Juha Heinanen To: Miguel Garcia Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 In-Reply-To: <44ABA2AE.3010001@nokia.com> References: <44AB9820.4050200@nokia.com> <17579.41018.861426.943160@rautu.tutpro.com> <44ABA2AE.3010001@nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Miguel Garcia writes: > That is what I remember as well, but I don't recall any conclusion of > "unless instructed otherwise by the domain". In otherwise, there is > still some "magic" for the domain instructions. if i remember correctly, someone proposed that register reply somehow tells how many flow the domain needs. anyway, it was alway decision of the network, not the UA. > But coming back to my point... I don't understand why there is a MUST > here, because the protocol is not broken if the MUST is not followed. i have told at least eight times now on this mailing list that the only real added value that outbound brings is reliability due to more than one flow. outbound is NOT needed for nat traversal. if you say MAY in the spec, UA vendors don't even support setting up more than one flow and can claim compatibility. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 15:07:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyCgb-0007Yk-3j; Wed, 05 Jul 2006 15:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyCgZ-0007Yc-Fp for sip@ietf.org; Wed, 05 Jul 2006 15:05:19 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyCgY-0006Zc-4n for sip@ietf.org; Wed, 05 Jul 2006 15:05:19 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 7DEE213F920; Wed, 5 Jul 2006 22:05:14 +0300 (EEST) Received: from rautu (eukaryote169.gprs.dnafinland.fi [62.78.106.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 09E4413F91D; Wed, 5 Jul 2006 22:05:04 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 24221F03C1; Wed, 5 Jul 2006 22:05:17 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17580.3437.78338.813405@rautu.tutpro.com> Date: Wed, 5 Jul 2006 22:05:17 +0300 From: Juha Heinanen To: "Jeroen van Bemmel" Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 In-Reply-To: <012001c6a02c$51b41780$31713b51@BEMBUSTER> References: <44AB9820.4050200@nokia.com> <17579.41018.861426.943160@rautu.tutpro.com> <44ABA2AE.3010001@nokia.com> <012001c6a02c$51b41780$31713b51@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Miguel Garcia , sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel writes: > I'd still like to use 2 registrations with different reg-ids). A MUST which > forces an implementation to always do (2) makes it impossible to do only > (1). see old postings. every implementation must be able to establish at least two flows (default), but this default may be overridden by configuration. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 15:29:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyD2f-0001Jc-Ax; Wed, 05 Jul 2006 15:28:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyD2e-0001J6-Kq for sip@ietf.org; Wed, 05 Jul 2006 15:28:08 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyD2d-0002kr-AM for sip@ietf.org; Wed, 05 Jul 2006 15:28:08 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 05 Jul 2006 12:28:05 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,210,1149490800"; d="scan'208"; a="31187488:sNHT26591272" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k65JS4nu017131; Wed, 5 Jul 2006 15:28:04 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jul 2006 15:28:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Date: Wed, 5 Jul 2006 15:27:32 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301A5AFA8@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Thread-Index: AcagOIzsFpB0qHlYTdOlFQkN53QpFQALl8Uw From: "Michael Hammer \(mhammer\)" To: "EKR" , "Rajnish Jain" X-OriginalArrivalTime: 05 Jul 2006 19:28:04.0814 (UTC) FILETIME=[2322EEE0:01C6A069] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric, The Record-Route header should contain the path of those proxies that intend to stay in the signaling path, whereas the Via only provides the path back for the responses. Should this make a difference? Could A to B agree on one suite, while B to C agree on another, but A to C not have a means for mid-call? I think so long as there is one default suite, this would not be a problem. There may be some corner cases here where the ciphersuite used on a hop associated with a node in the path is not the one that will exist mid-call due to Via/Record-Route differences. Mike > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 > Sent: Wednesday, July 05, 2006 9:40 AM > To: Rajnish Jain > Cc: sip@ietf.org > Subject: Re: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 >=20 > "Rajnish Jain" writes: >=20 > >> It seems to me that there is a simpler mechanism: any proxy X can=20 > >> only offer the intersection of the cipher suites that was=20 > offered to=20 > >> it and the ciphersuites that it is willing to support. > > > > There seems to be a fundamental disconnect in the comment=20 > above. The=20 > > comment above is basically describing a hop-by-hop=20 > mechanism. However,=20 > > the draft is fundamentally about solving the e2e problem.=20 > The keyword here is e2e. >=20 > This draft *isn't* end-to-end. End-to-end would be like in=20 > RFC 2818 where there's a single TLS channel between UAC and=20 > UAS. What this is is hop-by-hop with policy instructions. >=20 > > How > > will the proxy know that its narrowing down the UAC's preferred=20 > > ciphersuites will not be detrimental to the setting up of the call=20 > > somewhere downstream in the e2e path? >=20 > It might be, but a lot of experience with real TLS=20 > deployments and the fact that there is a=20 > mandatory-to-implement ciphersuite suggests that this will=20 > not be a problem in practice. >=20 >=20 > >> This has the result that no downstream proxy can negotiate=20 > a cipher=20 > >> suite that Alice wasn't willing to negotiate with Atlanta. > > > > But this has also has the undesirable result that no=20 > downstream proxy=20 > > can negotiate a cipher suite that was agreeable to Alice. >=20 > Huh? No, that's incorrect. >=20 >=20 > >> 1. Alice doesn't get any signal of what was eventually negotiated. > >> I would solve this problem by extending Via (I'm=20 > actually surprised > >> this isn't done). MTAs typically put it in Received=20 > lines, FWIW... > > > > How will extending 'Via' help Alice, the UAC, learn about the=20 > > negotiated ciphersuite? The draft does talk about extending=20 > 'Via' but=20 > > that is to inform Bob, the UAS. The draft also mentions that the=20 > > Security-Level header containing the lowest 'q' value is=20 > sent back to Alice. >=20 > Yes, you'll need some reverse channel that carries the same=20 > data as the Via. >=20 > >> 2. It's less expressive. In particular, the downstream=20 > cipher suites > >> always narrow and never grow. So, if there were a third proxy in > >> between Atlanta and Biloxi that only spoke DES, then=20 > Biloxi and Bob > >> would only get DES even if they both spoke AES.=20 > > > > This comment doesn't seem to reflect the scheme described=20 > in the draft. > > Instead, this seems like a comment reflecting the=20 > hop-by-hop mechanism=20 > > suggested in your own email. >=20 > Yes, that's why I listed it as a disadvantage of the scheme=20 > described in my e-mail message. >=20 > -Ekr >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 15:47:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDJO-0007O6-VM; Wed, 05 Jul 2006 15:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDJN-0007Nc-By for sip@ietf.org; Wed, 05 Jul 2006 15:45:25 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyDJL-0005Lj-TW for sip@ietf.org; Wed, 05 Jul 2006 15:45:25 -0400 Received: (qmail 29948 invoked by uid 0); 5 Jul 2006 19:45:21 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Jul 2006 19:45:21 -0000 Message-ID: <01f901c6a06b$8b3bba50$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Juha Heinanen" , "Miguel Garcia" References: <44AB9820.4050200@nokia.com><17579.41018.861426.943160@rautu.tutpro.com><44ABA2AE.3010001@nokia.com> <17580.3033.661988.839303@rautu.tutpro.com> Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Wed, 5 Jul 2006 21:45:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha, > it was alway decision of the network, not the UA OK, current section 4.2 says "For each outbound proxy URI in the set, the UA MUST send a REGISTER". So that implies that the network could control the number of flows, by controlling the number of URIs provided through configuration (though this would possibly not work well for manual configuration) I think this warrants some more discussion. The network may have reasons to limit the *maximum* number of flows (ie resource allocation), but it could enforce such a constraint in other ways too. For example, it could refuse registrations beyond the first N But is it really necessary for the network to impose a minimum? For flows beyond the maximum the network "suffers" (just like the registrar determines the expiration time). But by imposing a minimum number of flows, the UA potentially "suffers" (spending scarce resources such as battery power). And anyway, when the UA sets up less flows the consequences are for its user. 4.2 "UA MUST support sets with at least two outbound proxy URIs" should be sufficient to ensure vendor compliance. But to me, the UA should have some freedom to choose less than all URIs in the outbound proxy set (and you seem to agree: "default may be overridden by configuration", unless you consider that this configuration again comes from the network) > if i remember correctly, someone proposed that register reply somehow > tells how many flow the domain needs I'm having trouble with "needs" here. Perhaps "allows" ? Regards, Jeroen ----- Original Message ----- From: "Juha Heinanen" To: "Miguel Garcia" Cc: ; "Cullen Jennings" ; "Rohan Mahy" Sent: Wednesday, July 05, 2006 8:58 PM Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 > Miguel Garcia writes: > > > That is what I remember as well, but I don't recall any conclusion of > > "unless instructed otherwise by the domain". In otherwise, there is > > still some "magic" for the domain instructions. > > if i remember correctly, someone proposed that register reply somehow > tells how many flow the domain needs. anyway, it was alway decision of > the network, not the UA. > > > But coming back to my point... I don't understand why there is a MUST > > here, because the protocol is not broken if the MUST is not followed. > > i have told at least eight times now on this mailing list that the only > real added value that outbound brings is reliability due to more than > one flow. outbound is NOT needed for nat traversal. if you say MAY in > the spec, UA vendors don't even support setting up more than one flow > and can claim compatibility. > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 15:50:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDM7-0007jl-CS; Wed, 05 Jul 2006 15:48:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDM5-0007jg-GJ for sip@ietf.org; Wed, 05 Jul 2006 15:48:13 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyDM4-0006FK-RR for sip@ietf.org; Wed, 05 Jul 2006 15:48:13 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k65AOojA025703; Wed, 5 Jul 2006 05:24:51 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3JB91ZVL>; Wed, 5 Jul 2006 11:24:50 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369D29B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Cullen Jennings Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Wed, 5 Jul 2006 11:24:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Cc: sip@ietf.org, rohan@ekabal.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As chair) Right now both Dean and myself believe outbound is blocked. We asked the question a month or so ago about whether outbound could proceed without a discovery mechanism (either included or normatively referenced), and there was a significant number of people who apparently said no (we do have difficulties on this list who respond to a direct question from the chairs by going away and discussing something completely different). It appears that for these people, outbound could proceed if we have a normative reference to a discovery mechanism, but in that case, is that one mechanism or several, and do all or any of these require mandatory support. Conversely we have a set of people who appear to be saying "use any mechanism you like" and therefore no normative reference is needed. Now obviously, we would like to get this resolved one way or the other. We will quite probably be conducting hums on this issue in the SIP WG session in Montreal, having failed to achieve concensus on the list - unless in the next two or three days we see a breaking of this impasse. And remember, if outbound is blocked, then GRUU is dependent on outbound, so at the end of the day that will also be blocked, even if we progress it to the RFC editor's queue. We are formulating the questions we need to ask the WG on this issue, so any guidance from those involved would be useful. It would be nice to get the problem stated as clearly as possible so that the WG is able to give an intelligent answer. regards Keith > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: 05 July 2006 05:10 > To: Cullen Jennings > Cc: sip@ietf.org; rohan@ekabal.com; dean.willis@softarmor.com > Subject: Re: [Sip] Ready for WGLC on Outbound? > > > I've been a bystander, but will jump in here. Comment below: > > On Jul 4, 2006, at 3:37 PM, Cullen Jennings wrote: > > > > > I think people have stopped posting on this because they can't say > > anything that they have not already said. Don't take that as they > > agree. > > > > We got very strong feed back on one point - don't send STUN > > messages to a proxy unless you know it supports them. People felt > > strongly about that - I don't know why - but there was lots of > > people that agreed with that. > > > > I imagine people have sent me around 10 options on how to get the > > stun supported information and the set of outbound proxy URIs - > > certainly DNS and DHCP are some of them. We can write some drafts > > on various ways to do it. Right now my concern is making sure that > > no matter which of these many ways the WG decided to move forward > > with, outbound will work. So far every one of the possibilities I > > have heard would be possible with the current outbound. > Given that, > > I'm not sure what we need to change in outbound. I'm not even sure > > what you are proposing that we change in outbound - I think what > > you are proposing is we need to hold up outbound until we choose > > which one of the 10 we will use and furthermore you feel very > > strongly on which one of the 10 we should use. I'm not keen > on this > > - I think we have shown they are separable problems. The WG > decided > > on this separation of problems awhile back - I think it was in > > Vancouver - and many people supported it. I think it was a good > > idea - we have shown we can move outbound forward before we have > > determined all the ways that this configuration information is > > delivered to the UA. I would be very hesitant to reverse this > > decision now. > > I strongly agree with Cullen. We do not need to block the outbound > mechanism draft on figuring out the discovery stuff. The separation > was a good idea. If for no other reason, it lets us get work done. > > > > > > > > I don't think Dean's posts were sent as decries of the > requirements > > from the chair but purely as his opinion in trying to help bring > > the discussion to consensus. But I do think the draft meets the > > requirements and ideas he was outlining - I think the > current draft > > does meet the requirements he outlines. It does have a way for the > > "discovering whether a proxy supports the extensions of outbound" > > and on the topic of "there are two ways we can establish > > compatibility with an extensions", the WG rejected option 2 and we > > have gone with 1. > > > > Cullen (with my outbound author hat on) > > > > > > On Jul 4, 2006, at 3:50 AM, > > wrote: > > > >> > >> Hi Rohan, > >> > >> Sorry to be persistent with this issue, but what you say > >> seems to conflict with what was discussed in March. > >> > >>> The only time a UAC sends a STUN request as directed by > >>> outbound -04 is when the URI in the outbound-proxy-set > >>> includes the keepalive=stun parameter. That DHCP does not > >>> provide URI is a limitation of the SIP DHCP configuration > >>> mechanism, not outbound. If you want to write a draft on > >>> how to "shift-up" to using keepalives from some SIP or > >>> external stimulus, you can still do this. > >> > >> What you say seems to suggest that you agree there is a problem > >> when using DHCP SIP server option (as it is currently defined) > >> for finding out if the discovered proxy supports outbound and > >> STUN keepalives, but the solution is not in scope of Outbound > >> draft itself. > >> > >> However I came to a different understanding based on the emails > >> seen in the list earlier. For instance this email from Dean > >> Willis (SIP WG chair) seems to suggest that the problem should > >> be in scope of the outbound draft: > >> http://www1.ietf.org/mail-archive/web/sip/current/msg13667.html > >> > >> "Ok, I think we've boiled this down to a new requirement: > >> > >> for the "outbound" technique to work, we MUST have a means of > >> discovering whether a proxy supports the extensions of outbound. > >> > >> While we could do that by doing a REGISTER exchange that includes > >> an appropriate option-tag in Require:, it would be more efficient > >> if the proxy discovery mechanism informed us of this detail. So, > >> we posit that the Outbound draft SHOULD select and discuss such a > >> mechanism." > >> > >> And in yet another email > >> http://www1.ietf.org/mail-archive/web/sip/current/msg13692.html > >> Dean tells this: > >> > >> "There are two ways we can establish compatibility with an > >> extensions: > >> > >> 1) By foreknowledge > >> 2) By experimentation -- try it and see if it works. > >> > >> Both have limitations: > >> > >> In the case of #1, we might have incorrect knowledge. So we'll > >> probably > >> end up testing anyhow . . . > >> > >> In the case of #2, the experiment might cause a meltdown. So the > >> "probe > >> for discovery" must be made completely safe. Also, we can > >> eventually end > >> up with so many wierd hooks and idiosyncratic > implementations that we > >> end up doing a BUNCH of probing before we do any real > >> communicating. And > >> it's possible for the conditions to deteriorate so much that > >> probes for > >> two different possible conditions are mutually exclusive -- if one > >> condition applies, the probe for another will cause a meltdown. > >> > >> So what happens if we start STUN-probing a proxy on its SIP port > >> and it > >> doesn't support STUN? My guess is, it's random. > >> > >> ... > >> > >> One approach to "forward compatibility" design is to make sure > >> that we > >> can use both foreknowledge and experimentation -- the "trust but > >> verify" > >> model. > >> > >> ... > >> > >> While it's easy to decide whether a configured registrar URI has a > >> keepalive parameter, what happens to proxies we select based on > >> something besides direct configuration? > >> > >> Specifically, > >> > >> 1) Can the DHCP option for default proxy present the keepalive > >> parameter?" > >> ---- > >> > >> During these three months after seeing those comments in the list > >> I have been expecting the outbound draft to provide answer to > >> the question how UA could (within SIP signalling exchange) > >> safely to check whether or not a proxy supports STUN keepalive. > >> Two mechanims have been suggested how the UA could do this in > >> a simple way: > >> > >> 1. The UA to check that the Path header in 200 OK returned for > >> REGISTER would contain keepalive=stun parameter for the > proxy URI > >> > >> 2. The UA to add Proxy-Reequire: stun-keepalive parameter into > >> the REGISTER request and the proxy to remove this tag from > >> the request before forwarding it towards the registrar > >> > >> For me, any of those mechanisms would sound feasible and for > >> safety reasons I would hope the draft to deny the UA for sending > >> STUN keepalives to the proxy which did not pass such a test. > >> > >>> the same problem exists for the "comp" parameter for example. > >> > >> Yes but please bear in mind that for comp=sigcomp URI parameter > >> RFC 3486 Compressing SIP gives several solutions how the UA > >> would be able to check if the proxy supports SigComp while > >> outbound does not define any other than relying on configuration. > >> A cite from RFC 3486: > >> > >> 4.1 Obtaining a SIP or SIPS URI with comp=sigcomp > >> > >> For requests within a dialog, a next-hop URI with the > comp=sigcomp > >> parameter is obtained from a Record-Route header field when the > >> dialog is established. A client sending a request outside a > >> dialog > >> can also obtain SIP URIs with comp=sigcomp in a Contact header > >> field > >> in a 3xx or 485 response to the request. > >> > >> However, clients establishing a session will not typically be > >> willing > >> to wait until the dialog is established in order to begin > >> compressing > >> messages. One of the biggest gains that SigComp can bring to > >> SIP is > >> the ability to compress the initial INVITE of a dialog, when > >> the user > >> is waiting for the session to be established. > Therefore, clients > >> need a means to obtain a comp=sigcomp URI from their outbound > >> proxy > >> before the user decides to establish a session. > >> > >> One solution to this problem is manual configuration. However, > >> sometimes it is necessary to have clients configured in an > >> automatic > >> fashion. Unfortunately, current mechanisms for SIP client > >> configuration (e.g., using DHCP [6]) do not allow to provide the > >> client with URI parameters. In this case, the client SHOULD > >> send an > >> uncompressed OPTIONS request to its outbound proxy. > The outbound > >> proxy can provide an alternative SIP URI with the comp=sigcomp > >> parameter in a Contact header field in a 200 OK response to the > >> OPTIONS. The client can use this URI for subsequent > requests that > >> are sent through the same outbound proxy using compression. > >> > >> RFC 3261 [1] does not define how a proxy should respond to an > >> OPTIONS > >> request addressed to itself. It only describes how servers > >> respond > >> to OPTIONS addressed to a particular user. Section > 11.2 of RFC > >> 3261 > >> says: > >> > >> Contact header fields MAY be present in a 200 (OK) > response and > >> have the same semantics as in a 3xx response. That > is, they > >> may > >> list a set of alternative names and methods of reaching the > >> user. > >> > >> We extend this behavior to proxy servers responding to OPTIONS > >> addressed to them. They MAY list a set of alternative URIs to > >> contact the proxy. > >> > >> What has been called for is that outbound draft would also > >> specify one solution how the UA could check the STUN keepalive > >> support of a proxy. In my opinion good proposals seem > >> to exist how to do it in a reasonable way. > >> > >> Regards, > >> > >> Erkki > >> > >>> -----Original Message----- > >>> From: ext Rohan Mahy [mailto:rohan@ekabal.com] > >>> Sent: 04.July.2006 03:10 > >>> To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) > >>> Cc: dean.willis@softarmor.com; fluffy@cisco.com; Rohan Mahy; > >>> sip@ietf.org; jbemmel@zonnet.nl > >>> Subject: Re: [Sip] Ready for WGLC on Outbound? > >>> > >>> Hi Erkki, > >>> > >>> The only time a UAC sends a STUN request as directed by > >>> outbound -04 is > >>> when the URI in the outbound-proxy-set includes the keepalive=stun > >>> parameter. This is 100% backwards safe. We don't need > any text to > >>> prevent existing implementations from getting a bunch of STUN > >>> requests. > >>> > >>> That DHCP does not provide URI is a limitation of the SIP DHCP > >>> configuration mechanism, not outbound. The same problem > >>> exists for the > >>> "comp" parameter for example. If you want to write a draft on > >>> how to > >>> "shift-up" to using keepalives or using compression from > some SIP or > >>> external stimulus, you can still do this. No text in outbound > >>> prevents > >>> that from happening. > >>> > >>> thanks, > >>> -rohan > >>> > >>> > >>> On Jun 29, 2006, at 23:10, wrote: > >>>> > >>>> Hi Rohan, > >>>> > >>>>>> Also, the issue is that what may be configured (no > matter how you > >>>>>> configure it) may not be a URI. It may simply be an IP > >>> address/FQDN, > >>>>>> which is then used to build a SIP-URI. I think we shall > >>>>>> allow that, and make it more clear in the spec. [/CHH] > >>>>> > >>>>> the outbound spec defines a piece of configurable data (the > >>>>> 'outbound-proxy-set'), which is a list of URIs. This list > >>> of URIs may > >>>>> never have a one-to-one correspondence to a user or > administrator > >>>>> manually configurable field. That piece of configurable data > >>>>> may be > >>>>> derived from several fields, manually configurable, > discovered via > >>>>> DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP > >>>>> download, or via a random character generator seeded by the > >>>>> phase of > >>>>> the moon. > >>>>> > >>>>> The outbound-proxy-set was defined as a list of URIs because > >>>>> the UA > >>>>> acts on each item in the list, because each URI is > expected to be > >>>>> places in a Route header, and because each URI is expected to > >>>>> typically have a keepalive URI parameter in it. > >>>> > >>>> Like mentioned in other recent emails the problem is > that if the UA > >>>> derives the proxy URI(s) from DHCP SIP server option or > e.g. the > >>>> AOR > >>>> of the user, in those cases the derived URI will NOT contain the > >>>> keepalive URI parameter in it. DHCP just returns IP addresses or > >>>> domain names instead of URIs with parameters. > >>>> > >>>> Thus in those cases it would be critical for the UA to be able > >>>> to ensure in REGISTER - 200 OK sequence that the contacted proxy > >>>> supports Outbound and can handle STUN requests sent to its SIP > >>>> port (not to cause any damage to an uncompliant proxy). I fully > >>>> agree with this proposal from Jeroen: > >>>> > >>>> -- > >>>> The text should then say "the UAC MUST wait for a 200 OK to > >>>> REGISTER > >>>> before > >>>> it starts sending STUN packets. If the last Path header of the > >>>> 200 OK > >>>> does > >>>> not contain keepalive=stun, the UAC MUST NOT use STUN > >>> towards this URI. > >>>> If > >>>> there are no Path headers and no "Supported: outbound", the UAC > >>>> also > >>>> MUST > >>>> NOT use STUN towards the registrar.". It could still use TCP > >>> keepalive > >>>> if it > >>>> supports that > >>>> -- > >>>> > >>>> Please excuse me if I am just repeating myself and what > e.g. Jeroen > >>>> has said but I believe the importance of this issue > justifies some > >>>> redundancy :-) > >>>> > >>>> Regards, > >>>> > >>>> Erkki > >>> > >>> > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 16:03:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDYq-0001tJ-5b; Wed, 05 Jul 2006 16:01:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDYo-0001t2-AQ for sip@ietf.org; Wed, 05 Jul 2006 16:01:22 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyDYl-0008BH-VD for sip@ietf.org; Wed, 05 Jul 2006 16:01:22 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k65K1JgL005132; Wed, 5 Jul 2006 15:01:19 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k65K1Ju13247; Wed, 5 Jul 2006 15:01:19 -0500 (CDT) Message-ID: <44AC1A8E.4000707@lucent.com> Date: Wed, 05 Jul 2006 15:01:18 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ekr@networkresonance.com Subject: Re: [Sip] Comments on draft-gurbani-sip-domain-certs-01 References: <20060704163058.ADAC41CC22@delta.rtfm.com> In-Reply-To: <20060704163058.ADAC41CC22@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org EKR wrote: > It seems to me that this document addresses two issues: > > 1. What name(s) should appear in certificates. > 2. Where they should appear and how they should be encoded. Eric: Thanks much for your analysis. More inline. > ISTM that the same situation needs to apply with SIP. If you're > dereferencing then the certificate presented > to you needs to either be for a known (and trusted!) proxy or > contain "atlanta.com". Anything else requires trusting the DNS > resolution process, which isn't generally considered acceptable. Yes, the discussion on issue (1) on the mailing list converged on the same outcome you mention above; i.e., it suffices that when contacting "sips:alice@atlanta.com", the certificate presented contains "atlanta.com." However, it is the specific places where SIP differs from HTTP in its routing of subsequent requests that is of concern. For example: consider a dialog that has been established across a set of proxies that Record-Routed. The UAC is now ready to send a new request: UPDATE sips:uac@host1.atlanta.com SIP/2.0 Route: ... The request will go to "sips:proxy.atlanta.com", the Route URI. What typically appears in a Route URI is the fqdn of a certain proxy, as opposed to a URI that we can run rfc3263- resolution on to derive a candidate host. In other words, when sending a request to "sips:alice@atlanta.com", it suffices to see "atlanta.com" in the certificate. But what about the case where the UAC is sending a request to "sips:proxy.atlanta.com"? Is it sufficient that when the server presents a certificate that contains "atlanta.com", this certificate is good for "sips:proxy.atlanta.com" and "sips:proxy3.atlanta.com" and for subordinate names like "sips:east.proxy.atlanta.com"? It very well might be the case that this is sufficient (SIP Identity alludes to the name subordination problem in Section 13.4). However, if so, then we should state it as such so that implementations can built the required logic into their code. So, what are the guidelines to implementors here for comparison? As an implementor, should I just do a substring comparison of the contents of a certificate ("atlanta.com") against the Route URI ("proxy.atlanta.com")? Today, I am not sure how implementors are dealing with such cases. Any thoughts on this from you or the WG at large will be much appreciated. > So, this leaves us with the question of whether there should be > multiple names. As I understand S 10, the claimed disadvantages of a > single name are: [...] > I'm not sure what "common TLS usage" is being referred to. As I noted > above, in my experience HTTPS behaves exactly this way (putting the > generic domain name and not host name in the certificate). So what, then, does it mean to do "mutual authentication" in SIP? RFC3261 states that mutual authentication should occur across inter-domain requests (Section 26.3.2.2). It's relatively easy to authenticate the server, but how should the client be authenticated? Consider: INVITE sips:alice@atlanta.com SIP/2.0 Via: SIP/2.0/TLS proxy.biloxi.com;branch=... To: From: ;tag=98jukss-1 ... The client authenticates the server using the established norm of checking for "atlanta.com" in the certificate. But the server has only one piece of authoritative information about the client: the sent-by value in the topmost Via, which contains the specific host that sent the request. This could be any host in the biloxi.com domain, including a host in a subordinate domain. Thus, this case now degenerates to the same scenario we were discussing above. RFC3261 exhorts the server to match the certificate presented from the client to the domainname in the From header. This will not work if retargetting is used (please see Appendix A and B in the draft for more information on retargetting). Now, it could well be that a combination of deprecating retargetting outside your domain and SIP Identity is the preferred means to do mutual authentication in SIP. And if so, then we ought to deprecate the portions of rfc3261 that talks about mutual authentication. I realize that you will be busy with the impending IETF, but if you have some time for thoughts on virtual server certificates (section 8) and server farms (section 7), I'd much appreciate them as well. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 16:22:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDrM-0001Xd-Vq; Wed, 05 Jul 2006 16:20:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDrL-0001XA-Rw for sip@ietf.org; Wed, 05 Jul 2006 16:20:31 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyDp8-0001G9-VO for sip@ietf.org; Wed, 05 Jul 2006 16:18:17 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 92A7813F920; Wed, 5 Jul 2006 23:18:08 +0300 (EEST) Received: from rautu (eukaryote169.gprs.dnafinland.fi [62.78.106.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 50E2813F91C; Wed, 5 Jul 2006 23:18:02 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id B9817F03C1; Wed, 5 Jul 2006 23:18:10 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17580.7810.687558.525897@rautu.tutpro.com> Date: Wed, 5 Jul 2006 23:18:10 +0300 From: Juha Heinanen To: "Jeroen van Bemmel" Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 In-Reply-To: <01f901c6a06b$8b3bba50$31713b51@BEMBUSTER> References: <44AB9820.4050200@nokia.com> <17579.41018.861426.943160@rautu.tutpro.com> <44ABA2AE.3010001@nokia.com> <17580.3033.661988.839303@rautu.tutpro.com> <01f901c6a06b$8b3bba50$31713b51@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Miguel Garcia , sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel writes: > But is it really necessary for the network to impose a minimum? in case network's reliability solution is based on more than one simultaneous flow, then network must impose a minimum. > For flows beyond the maximum the network "suffers" (just like the registrar > determines the expiration time). But by imposing a minimum number of flows, > the UA potentially "suffers" (spending scarce resources such as battery > power). And anyway, when the UA sets up less flows the consequences are for > its user. in the above situation, assuming that network has two proxies, if UA decides to establish only one flow instead of two, then the likely hood is 50% that incoming call to the UA cannot be establishes. it thus makes no sense for the UA to violate network policy on number of flows. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 16:22:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDra-0001hJ-5g; Wed, 05 Jul 2006 16:20:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDrX-0001dr-6N for sip@ietf.org; Wed, 05 Jul 2006 16:20:43 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyDlG-0001BC-Vq for sip@ietf.org; Wed, 05 Jul 2006 16:14:16 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k65KEECq014126 for ; Wed, 5 Jul 2006 15:14:14 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k65KEDu23131; Wed, 5 Jul 2006 15:14:13 -0500 (CDT) Message-ID: <44AC1D95.2060602@lucent.com> Date: Wed, 05 Jul 2006 15:14:13 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-05 References: <475FF955A05DD411980D00508B6D5FB0134D262D@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0134D262D@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Drage, Keith (Keith) wrote: > I have the following comments on the draft: > > Technical --------- > > 1) I am interested in the question of whether this draft updates RFC > 3261 or not, and would appreciate some list discussion on that issue. > What, if any, RFC 3261 requirements does it change? I beleive the draft updates rfc3261's normative language in Section 18 on connection oriented transports, especially the text before Section 18.1. > NITS ---- > > 2) The IANA considerations may need some additional information. You > may want to look at the outbound draft to see if there is information > there you could use as a template. Sure. Thanks. > 3) You may want to update Rohan's affiliation on the cover page (I > assume he has it right on outbound). Sure. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 16:27:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDw9-0005Fz-5S; Wed, 05 Jul 2006 16:25:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDw7-0005Fu-Ho for sip@ietf.org; Wed, 05 Jul 2006 16:25:27 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyDw6-0001fC-1J for sip@ietf.org; Wed, 05 Jul 2006 16:25:27 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 6032F13F977; Wed, 5 Jul 2006 23:25:22 +0300 (EEST) Received: from rautu (eukaryote169.gprs.dnafinland.fi [62.78.106.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 7746D13F91E; Wed, 5 Jul 2006 23:25:11 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 68BD1F03C1; Wed, 5 Jul 2006 23:25:23 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17580.8243.365454.466162@rautu.tutpro.com> Date: Wed, 5 Jul 2006 23:25:23 +0300 From: Juha Heinanen To: "Drage, Keith (Keith)" Subject: RE: [Sip] Ready for WGLC on Outbound? In-Reply-To: <475FF955A05DD411980D00508B6D5FB01369D29B@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB01369D29B@en0033exch001u.uk.lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Cullen Jennings , sip@ietf.org, dean.willis@softarmor.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Drage, Keith (Keith) writes: > We asked the question a month or so ago about whether outbound could > proceed without a discovery mechanism (either included or normatively > referenced), and there was a significant number of people who > apparently said no (we do have difficulties on this list who respond > to a direct question from the chairs by going away and discussing > something completely different). yes, i was one of those who said that outbound MUST reference DNS based discovery in the same way as RFC3261 does. > It appears that for these people, outbound could proceed if we have a > normative reference to a discovery mechanism, but in that case, is > that one mechanism or several, and do all or any of these require > mandatory support. there must be one that every UA MUST implement. otherwise there is no interoperability and outbound turn out to be useless in real world. > Conversely we have a set of people who appear to be saying "use any > mechanism you like" and therefore no normative reference is needed. this would be a disaster to proxy operator. > And remember, if outbound is blocked, then GRUU is dependent on > outbound, so at the end of the day that will also be blocked, even if > we progress it to the RFC editor's queue. i don't mind the delay if the result is a deployable package. it makes no sense to ietf to release outbound rfc without discovery reference and pretend that it has accomplished something. there is already now FAR TOO MANY sip related rfcs that very few or nobody have implemented. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 21:57:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyJ63-0003iP-PZ; Wed, 05 Jul 2006 21:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyJ62-0003iH-K7 for sip@ietf.org; Wed, 05 Jul 2006 21:56:02 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyJ61-0001rm-Dv for sip@ietf.org; Wed, 05 Jul 2006 21:56:02 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2006070601555501300k109ve>; Thu, 6 Jul 2006 01:56:01 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k661ttjJ018154; Wed, 5 Jul 2006 21:55:55 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k661ttcT018150; Wed, 5 Jul 2006 21:55:55 -0400 Date: Wed, 5 Jul 2006 21:55:55 -0400 Message-Id: <200607060155.k661ttcT018150@dragon.ariadne.com> To: drage@lucent.com, sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <475FF955A05DD411980D00508B6D5FB01369D329@en0033exch001u.uk.lucent.com> (drage@lucent.com) Subject: Re: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG? References: <475FF955A05DD411980D00508B6D5FB01369D329@en0033exch001u.uk.lucent.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I fear this is an issue that was disposed of before and I don't realize it: I think the I-D needs to make clearer that when sending a request with a GRUU that the request must be sent via an outbound proxy for the GRUU's domain. This is needed to make the machinery work, but isn't stated explicitly as a UA requirement, it's implied in a section of the I-D that appears to be a proxy requirement. There's also the question of how the UA discovers the correct outbound proxy address. Strictly speaking, without a standardized mechanism, different vendors could have incompatible implementations. I admit that this isn't much worse than the UA configuration problem as it now stands. Perhaps a good dodge is to allow (absent other configuration) the UA to use the proxy for GRUU's domain as an outgoing proxy for requests using that GRUU as a Contact? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 05 23:09:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyKDG-0002qh-94; Wed, 05 Jul 2006 23:07:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyKDF-0002qc-DD for sip@ietf.org; Wed, 05 Jul 2006 23:07:33 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyKDA-0006XA-Pr for sip@ietf.org; Wed, 05 Jul 2006 23:07:33 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 05 Jul 2006 20:07:28 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k6637SJB021352 for ; Wed, 5 Jul 2006 20:07:28 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6637DCW018375 for ; Wed, 5 Jul 2006 20:07:27 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jul 2006 23:07:26 -0400 Received: from [192.168.1.102] ([10.86.243.96]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jul 2006 23:07:26 -0400 Message-ID: <44AC7E6E.1060406@cisco.com> Date: Wed, 05 Jul 2006 23:07:26 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2006 03:07:26.0814 (UTC) FILETIME=[4F5E5FE0:01C6A0A9] DKIM-Signature: a=rsa-sha1; q=dns; l=2034; t=1152155248; x=1153019248; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:comments=20on=20draft-worley-sip-many-refers-00; X=v=3Dcisco.com=3B=20h=3D/yPCriWQYgWjxdtOJ4aEyTrxpqQ=3D; b=gQh+t3IAr3KTuT0dOz9p5OWPg05AZUK7FwGu2GtdoS176vHTG2qAsKqlVc0t5635T6geuRxb saVxL80Evco8A8aSrrZOl1gztBiYehzVF1Wp7qNtceabb2tfLp/4I3jC; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Sip] comments on draft-worley-sip-many-refers-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale, Thanks for taking a stab at this. The 'hidden semantic' behind REFER is a looming potential problem that I don't think we've fully captured. Your draft takes a good step towards uncovering it, but I don't think it quite gets there. In particular, the Summary section of the draft is where you actually show the differences between the various usages. None of the 'Actions' in the table demonstrate the UA having to do something that is usage-specific and not directly inferred from the request itself. That, to me, is the sign of trouble - that a UA has to manipulate some kind of other state, or take some kind of other action, as a side effect of REFER, and that other action or state change depends on the usage. Thus, at the moment, your draft doesn't seem to point out that there are any problems with the REFER mechanism. One possible place this side-effect issue might show up is in the UI of a phone device. Without a doubt, its a better experience for a user to get asked, "Joe wants to transfer you to Bob, proceed?" than "You have received a REFER with Refer-To of sip:bob@example.com, proceed?", and this would seem to require the device to know that the reason for the REFER is a transfer. You might want to look at these kinds of UI issues across the different usages. You call out a transfer #1 use case in which the transferee has to send a BYE after the transfer. However, this is not the case AFAIK. In none of the transfer flows does the transferee need to send a BYE; its the entity doing the transfer (which obviously knows its transferring) that needs to do a BYE after the REFER for the INVITE succeeds. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 00:45:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyLiA-0004Ga-2I; Thu, 06 Jul 2006 00:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyLi7-00049I-Uy for sip@ietf.org; Thu, 06 Jul 2006 00:43:31 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyLi4-0002Ok-El for sip@ietf.org; Thu, 06 Jul 2006 00:43:31 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 98084205EA for ; Thu, 6 Jul 2006 10:10:50 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 7C1F1205DB for ; Thu, 6 Jul 2006 10:10:50 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:13:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Update to fork-loop-fix submitted Date: Thu, 6 Jul 2006 10:13:27 +0530 Message-ID: <532B18E13CF9E64380EF5FDDE265E071166B24@blr-m2-msg.wipro.com> In-Reply-To: <198E95FB-598E-4CD3-98D3-054B5D37CFFB@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Update to fork-loop-fix submitted Thread-Index: AcagQpurKV4cNYeeTJaB2W/wV/kl6gAcJLYg From: To: X-OriginalArrivalTime: 06 Jul 2006 04:43:24.0400 (UTC) FILETIME=[B7284700:01C6A0B6] X-Spam-Score: 0.2 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It is always better to reduce the computation in the path of normal success case and introduce it in the path of a rarer scenario. I think it will be a fair assumption to make that Spirals will be rarer than the non-spiraling scenarios. In terms of increasing logic, the increase in logic would be very small if it all any. It would be a trade-off that should be left to the implementer to take if he considers that hash computation is expensive on his platform. If this id recommends the computation of hash at the MUST strength in the first pass of the SIP request, an implementer would not have that freedom to make that trade-off..=20 Regards, Ravi. -- =20 Ravishankar. G. Shiroor Wipro Technologies, Bangalore. =20 ravishankar.shiroor@wipro.com -- =20 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Wednesday, July 05, 2006 8:21 PM > To: RaviShankar Shiroor (WT01 - Product Engineering Solutions) > Cc: sip@ietf.org > Subject: Re: [Sip] Update to fork-loop-fix submitted >=20 > I understand the suggestion. You are trading off letting the=20 > request through a loop one extra cycle for some lower amount=20 > of processing the first time the request went through the=20 > proxy. If you believe that spirals are relatively rare=20 > things, this change would result in proxies very rarely=20 > having to build the loop/spiral differentiation hash. >=20 > But as Jonathan points out, it's not clear that the hash=20 > computation is expensive enough to warrant this extra logic=20 > and the extra network traffic it would allow. I expect that=20 > the hash calculation expense is small compared to the=20 > parse/search/compare operations for "Proxy checks to see if=20 > its address is there in the via already". >=20 > RjS >=20 > On Jul 3, 2006, at 5:39 AM, =20 > wrote: >=20 > > > > Hi Robert, > > > > I had suggested one more alternative > > > > (http://www1.ietf.org/mail-archive/web/sip/current/msg14359.html ) > > > > Quoted from my previous mail: > > > > > > I was thinking how to reduce the impact of overhead for=20 > calculating =20 > > the > > digest. > > > > If it is suggested as follows, I think it will reduce the=20 > overhead on > > normal scenarios: > > > > Proxy checks to see if its address is there in the via already. > > If it is not there, it proceeds normally without calculating the =20 > > digest > > and inserting Via to the outgoing request without the digest. > > If it is there, then it is possible that the request is looping. So, > > this time around, it calculates a digests and inserts and sends it > > along. > > If it is looping, the request will definitely come in=20 > again, which can > > be rejected. > > This way the impact of calculating the digest is required (reduced =20 > > to a > > smaller percent of the sessions) only when the proxy is=20 > suspicious the > > request might be looping. > > Of course this results in the scenarios mentioned in the id to be > > successful in completing the first loop, but the second loop will be > > detected and arrested. I think this can be applicable to=20 > general loop > > detection, and not just fork loop fixes. > > > > > > Regards, > > Ravi. > > > > -- > > > > Ravishankar. G. Shiroor > > Wipro Technologies, Bangalore. > > > > ravishankar.shiroor@wipro.com > > -- > > > > > >> -----Original Message----- > >> From: Robert Sparks [mailto:rjsparks@nostrum.com] > >> Sent: Sunday, June 25, 2006 8:22 PM > >> To: IETF SIP List > >> Subject: [Sip] Update to fork-loop-fix submitted > >> > >> Until it appears in the repository, see: > >>=20 > http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-02.txt > >> > >> This was a moderately heavy touch - based on list feedback, > >> I've moved and updated the sections covering the > >> loopdetection algorithm in from 3261. In the process of > >> writing the clarifying text, I discovered several places that > >> need clarification. They are listed as Open Issues in the > >> draft. Basically there are fields that I can't recall or > >> reconstruct how they would be useful in the part of the hash > >> used for loop-detection or spiral differentiation. If anyone > >> can remember why they need to be included, send a note to the > >> list and we'll capture that in the draft. > >> > >> Please review the updated loop-detection text very carefully. > >> > >> Here's the changelog from the draft: > >> > >> Integrated several editorial fixes suggested by > >> Jonathan Rosenberg > >> > >> Noted that the reduction of the attack to a single =20 > >> registration > >> against a single URI as documented in previous versions, =20 > >> is, in > >> fact, going to be effective against implementations > >> conforming to > >> the standards before this repair. > >> > >> Re-incorporated motivation from the original > >> maxforwards-problem > >> draft into the security considerations section based > >> on feedback > >> from Cullen Jennings > >> > >> Introduced replacement text for the loop detection algorithm > >> description in RFC 3261, fixing the bug 648 (the > >> topmost Via value > >> must not be included in the second part) and clarifying the > >> algorithm. Removed several other fields suggested=20 > by 3261 and > >> placed open issues around their presence. > >> > >> Added a Notes to Implementors section capturing the > >> "common way" > >> text and pointing to the interoperability issues that have =20 > >> been > >> observed with loop detection at previous SIPits > >> > >> > >> Thanks, > >> > >> RjS > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use > >> sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > > > > The information contained in this electronic message and any =20 > > attachments to this message are intended for the exclusive use of =20 > > the addressee(s) and may contain proprietary, confidential or =20 > > privileged information. If you are not the intended recipient, you =20 > > should not disseminate, distribute or copy this e-mail. Please =20 > > notify the sender immediately and destroy all copies of this =20 > > message and any attachments. > > > > WARNING: Computer viruses can be transmitted via email. The =20 > > recipient should check this email and any attachments for the =20 > > presence of viruses. The company accepts no liability for any =20 > > damage caused by any virus transmitted by this email. > > > > www.wipro.com >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 00:59:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyLwI-0002y3-ON; Thu, 06 Jul 2006 00:58:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyLwH-0002xy-NP for sip@ietf.org; Thu, 06 Jul 2006 00:58:09 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyLwG-0003QJ-AU for sip@ietf.org; Thu, 06 Jul 2006 00:58:09 -0400 Received: (qmail 14378 invoked by uid 0); 6 Jul 2006 04:58:01 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 6 Jul 2006 04:58:01 -0000 Message-ID: <002001c6a0b8$c2848850$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Juha Heinanen" References: <44AB9820.4050200@nokia.com><17579.41018.861426.943160@rautu.tutpro.com><44ABA2AE.3010001@nokia.com><17580.3033.661988.839303@rautu.tutpro.com><01f901c6a06b$8b3bba50$31713b51@BEMBUSTER> <17580.7810.687558.525897@rautu.tutpro.com> Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Thu, 6 Jul 2006 06:58:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Miguel Garcia , sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha, > > For flows beyond the maximum the network "suffers" (just like the > > registrar > > determines the expiration time). But by imposing a minimum number of > > flows, > > the UA potentially "suffers" (spending scarce resources such as battery > > power). And anyway, when the UA sets up less flows the consequences are > > for > > its user. > > in the above situation, assuming that network has two proxies, if UA > decides to establish only one flow instead of two, then the likely hood > is 50% that incoming call to the UA cannot be establishes. it thus > makes no sense for the UA to violate network policy on number of flows. > This hints at a very different setup than I had in my mind. I always assumed that any flows beyond the first would be redundant, to be used when the first ("primary") flow would fail. Your text here suggests something more resembling a load balancing situation, with very different call completion probabilities Indeed, in the case above the UA would need to know that it MUST use two flows (or miss 50% of its calls). An alternative setup would have the proxies (say P1 and P2) exchange requests when there is no direct connection to the UA. If P1 and P2 are setup as a DNS proxyfarm, the routing logic that each would follow could be something like "if (UA flow) then forward to UA; else if (not from other proxy) forward to other proxy; else send 480" This looks like an issue to be discussed in the draft (ie what assumptions are made regarding how those N flows are used) Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 01:15:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyMBN-0003bu-Mz; Thu, 06 Jul 2006 01:13:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyMBM-0003bO-3J for sip@ietf.org; Thu, 06 Jul 2006 01:13:44 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyMAy-0003mY-1o for sip@ietf.org; Thu, 06 Jul 2006 01:13:21 -0400 Received: from [172.17.2.251] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k665C2G6049388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jul 2006 00:12:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44AC9B93.4000103@nostrum.com> Date: Thu, 06 Jul 2006 00:11:47 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: SIP WG Subject: [Sip] Outbound Comment: binding key X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From section 6.1: When a reg-id header parameter is present in a Contact header field value in a REGISTER request, the corresponding binding is between an AOR and the combination of instance-id and reg-id. I don't think this is quite correct. This statement appears to be asserting that {instance-id,reg-id} is a unique key to a binding associated with an AOR. This would, in turn, imply that any successful registration attempt with an {instance-id,reg-id} that matches an existing binding would overwrite the existing record. I don't think that is what's intended, since section 6.2 contains the following text: o If two bindings have the same instance-id and reg-id, the proxy SHOULD prefer the contact that was most recently updated. If the binding is only to {instance-id,reg-id}, then that text is nonsensical: you can't have two identical bindings to the same AOR. I suspect that the text in 6.1 should actually read something more like: When a reg-id header parameter is present in a Contact header field value in a REGISTER request, the corresponding binding is between an AOR and the combination of instance-id, reg-id, and network flow. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 01:19:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyMFI-0004Cv-KI; Thu, 06 Jul 2006 01:17:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyMFH-0004Cq-Uu for sip@ietf.org; Thu, 06 Jul 2006 01:17:47 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyMFG-0004MI-N4 for sip@ietf.org; Thu, 06 Jul 2006 01:17:47 -0400 Received: from [172.17.2.251] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k665GTn9049711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jul 2006 00:16:29 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44AC9C9F.1000701@nostrum.com> Date: Thu, 06 Jul 2006 00:16:15 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Cullen Jennings , SIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Sip] Outbound Comment: q-value X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The current document doesn't mention q-value handling, which is probably worth some treatment. In internal discussions, we came up with realistic scenarios whereby a client may reasonably end up maintaining two connections with very different characteristics (UDP versus TLS would be an extreme example), and be willing to use both of them, but *strongly* prefer one over the other. To handle this situation, it might make sense to put stuff in 6.2 that basically says that, for contacts with matching instance-ids, the proxy MUST NOT try a contact until all contacts at a higher q-value have been tried first. (I could go along with a weaker strength, but I really do think a prescriptive approach is the only thing that allows the clients to handle the situation I describe above in a manner that is predictable to the users). /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 01:53:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyMlB-00012k-Cm; Thu, 06 Jul 2006 01:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyMl9-00012c-Em for sip@ietf.org; Thu, 06 Jul 2006 01:50:43 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyMl5-0006S5-SD for sip@ietf.org; Thu, 06 Jul 2006 01:50:43 -0400 Received: from [172.17.2.251] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k665nMP4051659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jul 2006 00:49:23 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44ACA454.3030800@nostrum.com> Date: Thu, 06 Jul 2006 00:49:08 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Cullen Jennings , SIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: [Sip] Outbound Comment: negotiation and edge proxies X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This one, I might just be confused about, but I combed the draft and can't figure out how it is supposed to work. Section 5 of the outbound document places a number of requirements on edge proxies that must be implemented for outbound to work. However, negotiation of the outbound mechanism is between the client and the registrar. An edge-proxy that doesn't understand outbound will blithely shuttle messages back and forth between the client while they signal support for the outbound mechanism. During registration, all a non-outbound edge-proxy will see and care about is "Supported: path," which makes it fat and happy. It won't care about the funky bits on the end of the Contact. It won't care about the "Supported: outbound" header field in the REGISTER response. And it won't do anything suspicious that might give the client or the registrar some idea that things are about to go quite wrong. The client and registrar have done the secret handshake, and are absolutely certain that outbound handling is alive and well. I think this can be fixed with a little more behavior around what edge-proxies that support this draft are required to do. Specifically: since section 5.1 already has some pretty strong normative language that requires edge-proxies to insert Path header fields with certain properties, it's a rather small leap to dictate that the form of the URIs in these Path header fields must include something that the registrar can use to verify outbound support. For example: When an Edge Proxy receives a registration request with a reg-id header parameter in the Contact header field, it MUST form a flow identifier token that is unique to this network flow. The Edge Proxy MUST insert this token into a URI referring to this proxy and place this URI into a Path header field as described in RFC 3327 [RFC3327]. The token MAY be placed in the userpart of the URI. The URI MUST include an ";outbound" parameter. With that in place, the registrar can now look at an inbound REGISTER request and (in addition to checking the Contact header field) look through the Path header fields to ensure that all of them contain URIs with ";outbound" parameters. If they don't, it can take evasive action (perhaps not returning the "Supported: outbound" header field in the response?) that prevents things from going wrong. /a ---- P.S. There is one corner case that this doesn't seem to cover: the situation in which the client has a locally provisioned default outbound proxy. This locally provisioned default outbound proxy won't use Path at all, but it will remain in the signaling for all requests from the client. I'm not certain how often this will become a problem, and working around it would require something similar to the Path indication I describe above, but on Via header fields. That feels like a really ugly hack, and I'm not sure it's worth the inelegance to handle cases that will be rare, if they exist at all. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 02:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyNHu-00014F-6l; Thu, 06 Jul 2006 02:24:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyNHt-00014A-AB for sip@ietf.org; Thu, 06 Jul 2006 02:24:33 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyNHr-0000Px-VX for sip@ietf.org; Thu, 06 Jul 2006 02:24:33 -0400 Received: by tutpro.com (Postfix, from userid 65534) id ACADB13F98A; Thu, 6 Jul 2006 09:24:27 +0300 (EEST) Received: from rautu (allozyme210.gprs.dnafinland.fi [62.78.104.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 6734013F988; Thu, 6 Jul 2006 09:24:20 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 17BEAF03C1; Thu, 6 Jul 2006 09:24:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17580.44184.955957.188427@rautu.tutpro.com> Date: Thu, 6 Jul 2006 09:24:24 +0300 From: Juha Heinanen To: "Jeroen van Bemmel" Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 In-Reply-To: <002001c6a0b8$c2848850$31713b51@BEMBUSTER> References: <44AB9820.4050200@nokia.com> <17579.41018.861426.943160@rautu.tutpro.com> <44ABA2AE.3010001@nokia.com> <17580.3033.661988.839303@rautu.tutpro.com> <01f901c6a06b$8b3bba50$31713b51@BEMBUSTER> <17580.7810.687558.525897@rautu.tutpro.com> <002001c6a0b8$c2848850$31713b51@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Miguel Garcia , sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel writes: > An alternative setup would have the > proxies (say P1 and P2) exchange requests when there is no direct > connection to the UA. no thank you. i don't want to consume resources of both proxies for the request and, more importantly, i don't want to loose reliability. conclusion: in some proxy configurations UA MUST set up more than one flow or miss service. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 02:29:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyNKy-0001QO-6y; Thu, 06 Jul 2006 02:27:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyNKw-0001QH-AN for sip@ietf.org; Thu, 06 Jul 2006 02:27:42 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyNKu-0000Uy-Vb for sip@ietf.org; Thu, 06 Jul 2006 02:27:42 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 6A36F13F98A; Thu, 6 Jul 2006 09:27:37 +0300 (EEST) Received: from rautu (allozyme210.gprs.dnafinland.fi [62.78.104.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 2C19C13F988; Thu, 6 Jul 2006 09:27:31 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 7B501F03C1; Thu, 6 Jul 2006 09:27:43 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17580.44383.443990.716678@rautu.tutpro.com> Date: Thu, 6 Jul 2006 09:27:43 +0300 From: Juha Heinanen To: Adam Roach Subject: [Sip] Outbound Comment: q-value In-Reply-To: <44AC9C9F.1000701@nostrum.com> References: <44AC9C9F.1000701@nostrum.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Cullen Jennings , SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Adam Roach writes: > To handle this situation, it might make sense to put stuff in 6.2 > that basically says that, for contacts with matching instance-ids, > the proxy MUST NOT try a contact until all contacts at a higher > q-value have been tried first. (I could go along with a weaker > strength, but I really do think a prescriptive approach is the only > thing that allows the clients to handle the situation I describe > above in a manner that is predictable to the users). i you suggesting that proxies consult each other about the q-value UA used when registering with each proxy before forwarding a request to the UA? if so, your suggesting makes no sense. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 02:41:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyNWT-00023B-P8; Thu, 06 Jul 2006 02:39:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyNWS-000236-VF for sip@ietf.org; Thu, 06 Jul 2006 02:39:36 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyNWS-0002Df-EK for sip@ietf.org; Thu, 06 Jul 2006 02:39:36 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k666dPCl032460; Thu, 6 Jul 2006 09:39:29 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 09:39:29 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 09:39:29 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Thu, 6 Jul 2006 09:39:27 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0280DEDF@esebe103.NOE.Nokia.com> In-Reply-To: <002001c6a0b8$c2848850$31713b51@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A coment to draft-ietf-sip-outbound-04 Thread-Index: AcaguOPKTeALa0k7ReSKaPMUzdbBKwAC3+Wg From: To: , X-OriginalArrivalTime: 06 Jul 2006 06:39:29.0156 (UTC) FILETIME=[EE79B440:01C6A0C6] X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Miguel.An.Garcia@nokia.com, sip@ietf.org, fluffy@cisco.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi Jeroen, >This hints at a very different setup than I had in my mind. I=20 >always assumed that any flows beyond the first would be=20 >redundant, to be used when the first ("primary") flow would fail. The concept you had in your mind seems to be a possible implementation but by no means mandated by -04 version. In that version the network=20 treats all the flows towards an UA in an equal way. It appears already in the definitions: outbound-proxy-set A set of SIP URIs (Uniform Resource Identifiers) that represents each of the outbound proxies (often Edge Proxies) with which the UA will attempt to maintain a direct flow. The first URI in the set is often refereed to as the primary outbound proxy and the second as the secondary outbound proxy. There is no difference between any of the URIs in this set, nor does the primary/secondary terminology imply that one is preferred over the other. The normative text leaves it open how the location service will select a specific contact and related flow for an incoming request. In my understanding the implementation may either always select one specific flow as long as it works but it may also balance the load and select a different contact for different requests. In case the location service is distributed and colocated with different outbound proxies, it might prefer using always the local flow towards the UA, as long as it works. This is why I had to send this proposal for sip-outbound-discovery draft: http://www1.ietf.org/mail-archive/web/sip/current/msg14985.html However I have not received any comments to that and will highlight it as an open issue in the WG meeting. Regards, Erkki >-----Original Message----- >From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 >Sent: 06.July.2006 07:58 >To: Juha Heinanen >Cc: Garcia Miguel.An (Nokia-NRC/Helsinki); sip@ietf.org;=20 >Cullen Jennings; Rohan Mahy >Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 > >Juha, > >> > For flows beyond the maximum the network "suffers" (just like the=20 >> > registrar >> > determines the expiration time). But by imposing a minimum=20 >number of=20 >> > flows, >> > the UA potentially "suffers" (spending scarce resources=20 >such as battery >> > power). And anyway, when the UA sets up less flows the=20 >consequences are=20 >> > for >> > its user. >> >> in the above situation, assuming that network has two proxies, if UA >> decides to establish only one flow instead of two, then the=20 >likely hood >> is 50% that incoming call to the UA cannot be establishes. it thus >> makes no sense for the UA to violate network policy on=20 >number of flows. >> > >This hints at a very different setup than I had in my mind. I=20 >always assumed=20 >that any flows beyond the first would be redundant, to be used=20 >when the=20 >first ("primary") flow would fail. Your text here suggests=20 >something more=20 >resembling a load balancing situation, with very different=20 >call completion=20 >probabilities > >Indeed, in the case above the UA would need to know that it=20 >MUST use two=20 >flows (or miss 50% of its calls). An alternative setup would have the=20 >proxies (say P1 and P2) exchange requests when there is no=20 >direct connection=20 >to the UA. If P1 and P2 are setup as a DNS proxyfarm, the=20 >routing logic that=20 >each would follow could be something like "if (UA flow) then=20 >forward to UA;=20 >else if (not from other proxy) forward to other proxy; else send 480" > >This looks like an issue to be discussed in the draft (ie what=20 >assumptions=20 >are made regarding how those N flows are used) > >Regards, > >Jeroen > > > > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 03:02:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyNqM-00022d-Nt; Thu, 06 Jul 2006 03:00:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyNqL-00022Y-7e for sip@ietf.org; Thu, 06 Jul 2006 03:00:09 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyNqJ-0004Pm-Og for sip@ietf.org; Thu, 06 Jul 2006 03:00:09 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k666xrQD013545; Thu, 6 Jul 2006 09:59:53 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 09:59:53 +0300 Received: from [172.21.34.132] ([172.21.34.132]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 6 Jul 2006 09:59:52 +0300 Message-ID: <44ACB4EB.4060305@nokia.com> Date: Thu, 06 Jul 2006 09:59:55 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 References: <44AB9820.4050200@nokia.com> <17579.41018.861426.943160@rautu.tutpro.com> <44ABA2AE.3010001@nokia.com> <17580.3033.661988.839303@rautu.tutpro.com> <01f901c6a06b$8b3bba50$31713b51@BEMBUSTER> <17580.7810.687558.525897@rautu.tutpro.com> <002001c6a0b8$c2848850$31713b51@BEMBUSTER> <17580.44184.955957.188427@rautu.tutpro.com> In-Reply-To: <17580.44184.955957.188427@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2006 06:59:52.0704 (UTC) FILETIME=[C7C45000:01C6A0C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha: While I understand that you want to impose reliability to your users, by requesting them to establish 2 or more flows, you also need to understand that this might not be always the case, because the cost of such reliability might be that my battery is drained in half of the time, due to the STUN refreshes. So, what I am advocating is for a way to decoupling reliability from NAT traversal. There must be a way for the network to indicate more than one outbound URI, used for backup purposes, but still instruct or let the UA to establish a single flow. The current text in the draft seems to prevent this use case. /Miguel Juha Heinanen wrote: > Jeroen van Bemmel writes: > > > An alternative setup would have the > > proxies (say P1 and P2) exchange requests when there is no direct > > connection to the UA. > > no thank you. i don't want to consume resources of both proxies for the > request and, more importantly, i don't want to loose reliability. > > conclusion: in some proxy configurations UA MUST set up more than one > flow or miss service. > > -- juha -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 03:19:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyO7i-0005BC-Jq; Thu, 06 Jul 2006 03:18:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyO7f-000589-BG for sip@ietf.org; Thu, 06 Jul 2006 03:18:03 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyO0S-0005Ks-3j for sip@ietf.org; Thu, 06 Jul 2006 03:10:37 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k667ARNC000372; Thu, 6 Jul 2006 10:10:28 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:10:25 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:10:25 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: Validating if the proxy supports outbound or not Date: Thu, 6 Jul 2006 10:10:24 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0280DF24@esebe103.NOE.Nokia.com> In-Reply-To: <44ACA454.3030800@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Validating if the proxy supports outbound or not Thread-Index: AcagwHzle1JwOppmTxCANtPGJSrQ9wACN0TQ From: To: , X-OriginalArrivalTime: 06 Jul 2006 07:10:25.0476 (UTC) FILETIME=[40EDA840:01C6A0CB] X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: BPenfield@acmepacket.com, adam@nostrum.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, The comments sent on the list during last few days seem to indicate reasonably large concern that it is not sufficient for the UA to check that the configured proxy URI contains keepalive=3Dstun parameter, in order for the UA to make sure that the proxy actually supports outbound. Thus I will=20 expect that the next version of outbound draft will address this issue. Note that the authors of the draft have promised to raise this as an open issue in the WG meeting, so please be prepared to contribute that discussion. The comments I am referring to are this (mine included): Bob Penfield: >Does that mean that a UA should not send STUN if the=20 >keepalive=3Dstun is not present? > >If so, will outbound be useful prior to the completion of the various=20 >configuration mechanisms? And is it acceptable for a=20 >mis-configured UA to cause the proxy or the registrar to crash or mis-behave? > >A mechanism such as the proposed Proxy-Require/Require method=20 >similar to sec-agree allows the UA to determine that the proxy and=20 >registrar support STUN before it sends and potentially harmful messages. Adam Roach: >I think this can be fixed with a little more behavior around what=20 >edge-proxies that support this draft are required to do. Specifically:=20 >since section 5.1 already has some pretty strong normative=20 >language that=20 >requires edge-proxies to insert Path header fields with certain=20 >properties, it's a rather small leap to dictate that the form of the=20 >URIs in these Path header fields must include something that the=20 >registrar can use to verify outbound support. > >With that in place, the registrar can now look at an inbound REGISTER=20 >reFrom sip-bounces@ietf.org Thu Jul 06 03:19:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyO7i-0005BC-Jq; Thu, 06 Jul 2006 03:18:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyO7f-000589-BG for sip@ietf.org; Thu, 06 Jul 2006 03:18:03 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyO0S-0005Ks-3j for sip@ietf.org; Thu, 06 Jul 2006 03:10:37 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k667ARNC000372; Thu, 6 Jul 2006 10:10:28 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:10:25 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:10:25 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: Validating if the proxy supports outbound or not Date: Thu, 6 Jul 2006 10:10:24 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0280DF24@esebe103.NOE.Nokia.com> In-Reply-To: <44ACA454.3030800@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Validating if the proxy supports outbound or not Thread-Index: AcagwHzle1JwOppmTxCANtPGJSrQ9wACN0TQ From: To: , X-OriginalArrivalTime: 06 Jul 2006 07:10:25.0476 (UTC) FILETIME=[40EDA840:01C6A0CB] X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: BPenfield@acmepacket.com, adam@nostrum.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, The comments sent on the list during last few days seem to indicate reasonably large concern that it is not sufficient for the UA to check that the configured proxy URI contains keepalive=3Dstun parameter, in order for the UA to make sure that the proxy actually supports outbound. Thus I will=20 expect that the next version of outbound draft will address this issue. Note that the authors of the draft have promised to raise this as an open issue in the WG meeting, so please be prepared to contribute that discussion. The comments I am referring to are this (mine included): Bob Penfield: >Does that mean that a UA should not send STUN if the=20 >keepalive=3Dstun is not present? > >If so, will outbound be useful prior to the completion of the various=20 >configuration mechanisms? And is it acceptable for a=20 >mis-configured UA to cause the proxy or the registrar to crash or mis-behave? > >A mechanism such as the proposed Proxy-Require/Require method=20 >similar to sec-agree allows the UA to determine that the proxy and=20 >registrar support STUN before it sends and potentially harmful messages. Adam Roach: >I think this can be fixed with a little more behavior around what=20 >edge-proxies that support this draft are required to do. Specifically:=20 >since section 5.1 already has some pretty strong normative=20 >language that=20 >requires edge-proxies to insert Path header fields with certain=20 >properties, it's a rather small leap to dictate that the form of the=20 >URIs in these Path header fields must include something that the=20 >registrar can use to verify outbound support. > >With that in place, the registrar can now look at an inbound REGISTER=20 >request and (in addition to checking the Contact header field) look=20 >through the Path header fields to ensure that all of them contain URIs=20 >with ";outbound" parameters. If they don't, it can take evasive action=20 >(perhaps not returning the "Supported: outbound" header field in the=20 >response?) that prevents things from going wrong. =20 Erkki Koivusalo: >The specific concerns that I have (and would like the WG to=20 >consider in the meeting) are closely related to what you told: > >>We got very strong feed back on one point - don't send=20 >>STUN messages to a proxy unless you know it supports them.=20 > >Does the WG consider checking the configured URI as a safe enough >check for the UA to ensure that the SIP proxy support STUN ? > >In my opinion it is not. As an example a vendor X could implement >a compliant but bad UA which provides an option for the user to=20 >configure the settings via an User Interface e.g. like this: >"Is the phone behind a NAT: Yes/No". When the user selects >"Yes" the UA would add the keepalive=3Dstun flag to the proxy URI >even if the user does not have a clue if the proxy actually >supports outbound or not. There is nothing in outbound draft >to prevent such unsafe implementations to appear. Jeroen van Bemmel: >The point is that these are really 2 separate issues: >1. Discovering the set of outbound proxy URIs (with keepalive=3Dstun=20 >parameters in them) >2. Confirming that a given proxy in the set actually supports=20 >outbound (ie validating the keepalive=3Dstun information) > >Of these 2 options, (1) is indeed a separable problem.=20 >(2) - to me - is not, for me outbound is not acceptable=20 >without something to address (2). Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 03:19:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyO7k-0005CC-C9; Thu, 06 Jul 2006 03:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyO7f-000589-Sl for sip@ietf.org; Thu, 06 Jul 2006 03:18:03 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyNz8-00054m-3h for sip@ietf.org; Thu, 06 Jul 2006 03:09:15 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 346A713F98B; Thu, 6 Jul 2006 10:09:10 +0300 (EEST) Received: from rautu (allozyme210.gprs.dnafinland.fi [62.78.104.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 99A8613F988; Thu, 6 Jul 2006 10:08:53 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 3041DF03C1; Thu, 6 Jul 2006 10:09:06 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17580.46866.136148.590440@rautu.tutpro.com> Date: Thu, 6 Jul 2006 10:09:06 +0300 From: Juha Heinanen To: Miguel Garcia Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 In-Reply-To: <44ACB4EB.4060305@nokia.com> References: <44AB9820.4050200@nokia.com> <17579.41018.861426.943160@rautu.tutpro.com> <44ABA2AE.3010001@nokia.com> <17580.3033.661988.839303@rautu.tutpro.com> <01f901c6a06b$8b3bba50$31713b51@BEMBUSTER> <17580.7810.687558.525897@rautu.tutpro.com> <002001c6a0b8$c2848850$31713b51@BEMBUSTER> <17580.44184.955957.188427@rautu.tutpro.com> <44ACB4EB.4060305@nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org, Cullen Jenniquest and (in addition to checking the Contact header field) look=20 >through the Path header fields to ensure that all of them contain URIs=20 >with ";outbound" parameters. If they don't, it can take evasive action=20 >(perhaps not returning the "Supported: outbound" header field in the=20 >response?) that prevents things from going wrong. =20 Erkki Koivusalo: >The specific concerns that I have (and would like the WG to=20 >consider in the meeting) are closely related to what you told: > >>We got very strong feed back on one point - don't send=20 >>STUN messages to a proxy unless you know it supports them.=20 > >Does the WG consider checking the configured URI as a safe enough >check for the UA to ensure that the SIP proxy support STUN ? > >In my opinion it is not. As an example a vendor X could implement >a compliant but bad UA which provides an option for the user to=20 >configure the settings via an User Interface e.g. like this: >"Is the phone behind a NAT: Yes/No". When the user selects >"Yes" the UA would add the keepalive=3Dstun flag to the proxy URI >even if the user does not have a clue if the proxy actually >supports outbound or not. There is nothing in outbound draft >to prevent such unsafe implementations to appear. Jeroen van Bemmel: >The point is that these are really 2 separate issues: >1. Discovering the set of outbound proxy URIs (with keepalive=3Dstun=20 >parameters in them) >2. Confirming that a given proxy in the set actually supports=20 >outbound (ie validating the keepalive=3Dstun information) > >Of these 2 options, (1) is indeed a separable problem.=20 >(2) - to me - is not, for me outbound is not acceptable=20 >without something to address (2). Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 03:19:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyO7k-0005CC-C9; Thu, 06 Jul 2006 03:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyO7f-000589-Sl for sip@ietf.org; Thu, 06 Jul 2006 03:18:03 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyNz8-00054m-3h for sip@ietf.org; Thu, 06 Jul 2006 03:09:15 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 346A713F98B; Thu, 6 Jul 2006 10:09:10 +0300 (EEST) Received: from rautu (allozyme210.gprs.dnafinland.fi [62.78.104.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 99A8613F988; Thu, 6 Jul 2006 10:08:53 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 3041DF03C1; Thu, 6 Jul 2006 10:09:06 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17580.46866.136148.590440@rautu.tutpro.com> Date: Thu, 6 Jul 2006 10:09:06 +0300 From: Juha Heinanen To: Miguel Garcia Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 In-Reply-To: <44ACB4EB.4060305@nokia.com> References: <44AB9820.4050200@nokia.com> <17579.41018.861426.943160@rautu.tutpro.com> <44ABA2AE.3010001@nokia.com> <17580.3033.661988.839303@rautu.tutpro.com> <01f901c6a06b$8b3bba50$31713b51@BEMBUSTER> <17580.7810.687558.525897@rautu.tutpro.com> <002001c6a0b8$c2848850$31713b51@BEMBUSTER> <17580.44184.955957.188427@rautu.tutpro.com> <44ACB4EB.4060305@nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Miguel Garcia writes: > So, what I am advocating is for a way to decoupling reliability from NAT > traversal. There must be a way for the network to indicate more than one > outbound URI, used for backup purposes, but still instruct or let the UA > to establish a single flow. The current text in the draft seems to > prevent this use case. then suggest some specific mechanism to achieve that you want. for example, like someone proposed, introduce some parameter to register 200 OK that tells than one flow is enough. you cannot simply say that "a UA may establish only one flow if it doesn't feel like setting up more". -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ngs , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Miguel Garcia writes: > So, what I am advocating is for a way to decoupling reliability from NAT > traversal. There must be a way for the network to indicate more than one > outbound URI, used for backup purposes, but still instruct or let the UA > to establish a single flow. The current text in the draft seems to > prevent this use case. then suggest some specific mechanism to achieve that you want. for example, like someone proposed, introduce some parameter to register 200 OK that tells than one flow is enough. you cannot simply say that "a UA may establish only one flow if it doesn't feel like setting up more". -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 03:23:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyOBM-0006Ky-Ol; Thu, 06 Jul 2006 03:21:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyOBL-0006Kt-76 for sip@ietf.org; Thu, 06 Jul 2006 03:21:51 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyOBJ-0006AK-Ob for sip@ietf.org; Thu, 06 Jul 2006 03:21:51 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k667LaLh031466; Thu, 6 Jul 2006 10:21:41 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:21:39 +0300 Received: from [172.21.34.132] ([172.21.34.132]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 6 Jul 2006 10:21:39 +0300 Message-ID: <44ACBA03.6030207@nokia.com> Date: Thu, 06 Jul 2006 10:21:39 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 References: <44AB9820.4050200@nokia.com> <17579.41018.861426.943160@rautu.tutpro.com> <44ABA2AE.3010001@nokia.com> <17580.3033.661988.839303@rautu.tutpro.com> <01f901c6a06b$8b3bba50$31713b51@BEMBUSTER> <17580.7810.687558.525897@rautu.tutpro.com> <002001c6a0b8$c2848850$31713b51@BEMBUSTER> <17580.44184.955957.188427@rautu.tutpro.com> <44ACB4EB.4060305@nokia.com> <17580.46866.136148.590440@rautu.tutpro.com> In-Reply-To: <17580.46866.136148.590440@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2006 07:21:39.0292 (UTC) FILETIME=[D28DD1C0:01C6A0CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Miguel Garcia writes: > > > So, what I am advocating is for a way to decoupling reliability from NAT > > traversal. There must be a way for the network to indicate more than one > > outbound URI, used for backup purposes, but still instruct or let the UA > > to establish a single flow. The current text in the draft seems to > > prevent this use case. > > then suggest some specific mechanism to achieve that you want. for > example, like someone proposed, introduce some parameter to register 200 > OK that tells than one flow is enough. you cannot simply say that "a UA > may establish only one flow if it doesn't feel like setting up more". That solution would work for me, but I think it was discussed in the past and, I dont' know really why, it was somehow rejected. The other alternative solution it comes to my mind is to play with the Priority of the SRV record. So we could say that the UA establishes a flow to each server defined with the lower Priority. Servers defined with higher priority will be used in cases of failure. Within the same priority, the UA establishes one flow per server listed there. So, if the network requests several flows, it configures several SRV records with the lower priority (say, 0). If the network requests one flow, it configures one SRV record with the lower priority. This will cover all the use cases we have been discussing. /Miguel > > -- juha -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 03:42:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyOTj-0006Bs-V7; Thu, 06 Jul 2006 03:40:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyOTi-0006Bn-JL for sip@ietf.org; Thu, 06 Jul 2006 03:40:50 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyOTi-000890-2d for sip@ietf.org; Thu, 06 Jul 2006 03:40:50 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k667egLa012854; Thu, 6 Jul 2006 10:40:43 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:40:42 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:40:42 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Thu, 6 Jul 2006 10:40:41 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0280DF6A@esebe103.NOE.Nokia.com> In-Reply-To: <44ACBA03.6030207@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A coment to draft-ietf-sip-outbound-04 Thread-Index: AcagzRcchRW2YLLnSXO00qoOoIdUHgAASscA From: To: , X-OriginalArrivalTime: 06 Jul 2006 07:40:42.0505 (UTC) FILETIME=[7BF64790:01C6A0CF] X-Spam-Score: 0.2 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip@ietf.org, fluffy@cisco.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >That solution would work for me, but I think it was discussed in the=20 >past and, I dont' know really why, it was somehow rejected. Rohan rejected the proposal like this: >As a scope issue, the chairs (previous and current) and the ADs (at >time still Allison and Jon) directed the editors to make outbound=20 >separate from gruu, initial proxy discovery/configuration, and=20 >specification of record-routing behavior for high reliability and=20 >per-call state cookies. We then had WG consensus on this approach. I=20 >think that was a wise choice, and I fear that adding new=20 >parameters now will only unwind that consensus. So nothing specific against the proposed mechanism, just a general concern of loading outbound draft with too many different mechanisms. Rohan also suggested using DNS for the purpose, however without mentioning yet any specific way how to use it: >I can think of a number of ways to make this work where the intended=20 >semantics are entirely embedded in DNS. Alternatively you can=20 >discover=20 >*candidate* outbound-proxy-URIs via DNS and use a max-flows value=20 >configured/discovered elsewhere to decide how to derive/self-configure=20 >the actually outbound-proxy-set. What comes to your suggestion on using DNS... >The other alternative solution it comes to my mind is to play with the=20 >Priority of the SRV record. So we could say that the UA establishes a=20 >flow to each server defined with the lower Priority. Servers defined=20 >with higher priority will be used in cases of failure. ... it seems that there is a drawback. If SRV records would be used like that, then a service provider could not any more use the SRV RRs with same level of priority for balancing the load for the UA population, wishing each UA to maintain lower number of flows than the number of servers in that priority level. E.g. balancing the load to 4 servers would require every UA to maintain 4 flows, which would be impractical and cause extra load (for keepalives and registration refreshes) for all those proxies. Regards, Erkki >-----Original Message----- >From: ext Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 >Sent: 06.July.2006 10:22 >To: Juha Heinanen >Cc: sip@ietf.org; Cullen Jennings; Rohan Mahy >Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 > >Juha Heinanen wrote: >> Miguel Garcia writes: >>=20 >> > So, what I am advocating is for a way to decoupling=20 >reliability from NAT=20 >> > traversal. There must be a way for the network to=20 >indicate more than one=20 >> > outbound URI, used for backup purposes, but still=20 >instruct or let the UA=20 >> > to establish a single flow. The current text in the draft=20 >seems to=20 >> > prevent this use case. >>=20 >> then suggest some specific mechanism to achieve that you want. for >> example, like someone proposed, introduce some parameter to=20 >register 200 >> OK that tells than one flow is enough. you cannot simply=20 >say that "a UA >> may establish only one flow if it doesn't feel like setting up more". > >That solution would work for me, but I think it was discussed in the=20 >past and, I dont' know really why, it was somehow rejected. > >The other alternative solution it comes to my mind is to play with the=20 >Priority of the SRV record. So we could say that the UA establishes a=20 >flow to each server defined with the lower Priority. Servers defined=20 >with higher priority will be used in cases of failure. > >Within the same priority, the UA establishes one flow per=20 >server listed=20 >there. So, if the network requests several flows, it=20 >configures several=20 >SRV records with the lower priority (say, 0). If the network requests=20 >one flow, it configures one SRV record with the lower priority. This=20 >will cover all the use cases we have been discussing. > >/Miguel > >>=20 >> -- juha > >--=20 >Miguel A. Garcia tel:+358-50-4804586 >sip:miguel.an.garcia@openlaboratory.net >Nokia Research Center Helsinki, Finland > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 03:47:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyOYV-0001kR-He; Thu, 06 Jul 2006 03:45:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyOYT-0001kJ-2f for sip@ietf.org; Thu, 06 Jul 2006 03:45:45 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyOYR-0000wF-Jo for sip@ietf.org; Thu, 06 Jul 2006 03:45:45 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k667jai6014216; Thu, 6 Jul 2006 10:45:36 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:45:36 +0300 Received: from [172.21.34.132] ([172.21.34.132]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 6 Jul 2006 10:45:35 +0300 Message-ID: <44ACBF9F.2050303@nokia.com> Date: Thu, 06 Jul 2006 10:45:35 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Koivusalo Erkki (Nokia-TP-MSW/Helsinki)" Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 References: <8B1D53AEF7B03449A6D3771B3B7F850F0280DF6A@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0280DF6A@esebe103.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2006 07:45:35.0382 (UTC) FILETIME=[2A87C360:01C6A0D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org, Cullen Jennings , Juha Heinanen , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Koivusalo Erkki (Nokia-TP-MSW/Helsinki) wrote: > What comes to your suggestion on using DNS... > >> The other alternative solution it comes to my mind is to play with the >> Priority of the SRV record. So we could say that the UA establishes a >> flow to each server defined with the lower Priority. Servers defined >> with higher priority will be used in cases of failure. > > ... it seems that there is a drawback. If SRV records would > be used like that, then a service provider could not any more > use the SRV RRs with same level of priority for balancing the > load for the UA population, wishing each UA to maintain lower > number of flows than the number of servers in that priority level. > E.g. balancing the load to 4 servers would require every UA to > maintain 4 flows, which would be impractical and cause extra > load (for keepalives and registration refreshes) for all those > proxies. > So why would you publish 4 servers with the same Priority in SRV, but don't want 4 flows, but still want load balancing among what? Strange... /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 04:24:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyP7n-0004F3-JQ; Thu, 06 Jul 2006 04:22:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyP7l-0004EP-F1 for sip@ietf.org; Thu, 06 Jul 2006 04:22:13 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyP7k-0007GU-8C for sip@ietf.org; Thu, 06 Jul 2006 04:22:13 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 98E174F007E; Thu, 6 Jul 2006 10:22:11 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:22:10 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:22:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Thu, 6 Jul 2006 10:19:20 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594117D41@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on Outbound? Thread-Index: Acafqbn3N+j+gKaDShWPiCuVfZv5sQBKyehd References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , X-OriginalArrivalTime: 06 Jul 2006 08:22:10.0823 (UTC) FILETIME=[471D7970:01C6A0D5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Cc: sip@ietf.org, rohan@ekabal.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, =20 This again brings up the question: should the whole usage of STUN for = keep-alive be described in a separate draft? The outbound spec would = then just refer to that. =20 Especially IF we can agree on the fact that the STUN keep-alive is a = stand-alone feature (not necessarily always used together with = outbound), I don't see why the STUN keep-alive mechanism is described in = one draft, and then in another draft we describe how to detect whether a = proxy supports it or not. Why not put everything in one draft, then? =20 Regards, =20 Christer =20 =20 ________________________________ From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Tue 04/07/2006 22:37 To: Cc: sip@ietf.org; rohan@ekabal.com; dean.willis@softarmor.com Subject: Re: [Sip] Ready for WGLC on Outbound? I think people have stopped posting on this because they can't say=20 anything that they have not already said. Don't take that as they agree. We got very strong feed back on one point - don't send STUN messages=20 to a proxy unless you know it supports them. People felt strongly=20 about that - I don't know why - but there was lots of people that=20 agreed with that. I imagine people have sent me around 10 options on how to get the=20 stun supported information and the set of outbound proxy URIs -=20 certainly DNS and DHCP are some of them. We can write some drafts on=20 various ways to do it. Right now my concern is making sure that no=20 matter which of these many ways the WG decided to move forward with,=20 outbound will work. So far every one of the possibilities I have=20 heard would be possible with the current outbound. Given that, I'm=20 not sure what we need to change in outbound. I'm not even sure what=20 you are proposing that we change in outbound - I think what you are=20 proposing is we need to hold up outbound until we choose which one of=20 the 10 we will use and furthermore you feel very strongly on which=20 one of the 10 we should use. I'm not keen on this - I think we have=20 shown they are separable problems. The WG decided on this separation=20 of problems awhile back - I think it was in Vancouver - and many=20 people supported it. I think it was a good idea - we have shown we=20 can move outbound forward before we have determined all the ways that=20 this configuration information is delivered to the UA. I would be=20 very hesitant to reverse this decision now. I don't think Dean's posts were sent as decries of the requirements=20 from the chair but purely as his opinion in trying to help bring the=20 discussion to consensus. But I do think the draft meets the=20 requirements and ideas he was outlining - I think the current draft=20 does meet the requirements he outlines. It does have a way for the=20 "discovering whether a proxy supports the extensions of outbound" and=20 on the topic of "there are two ways we can establish compatibility=20 with an extensions", the WG rejected option 2 and we have gone with 1. Cullen (with my outbound author hat on) On Jul 4, 2006, at 3:50 AM, =20 wrote: > > Hi Rohan, > > Sorry to be persistent with this issue, but what you say > seems to conflict with what was discussed in March. > >> The only time a UAC sends a STUN request as directed by >> outbound -04 is when the URI in the outbound-proxy-set >> includes the keepalive=3Dstun parameter. That DHCP does not >> provide URI is a limitation of the SIP DHCP configuration >> mechanism, not outbound. If you want to write a draft on >> how to "shift-up" to using keepalives from some SIP or >> external stimulus, you can still do this. > > What you say seems to suggest that you agree there is a problem > when using DHCP SIP server option (as it is currently defined) > for finding out if the discovered proxy supports outbound and > STUN keepalives, but the solution is not in scope of Outbound > draft itself. > > However I came to a different understanding based on the emails > seen in the list earlier. For instance this email from Dean > Willis (SIP WG chair) seems to suggest that the problem should > be in scope of the outbound draft: > http://www1.ietf.org/mail-archive/web/sip/current/msg13667.html > > "Ok, I think we've boiled this down to a new requirement: > > for the "outbound" technique to work, we MUST have a means of > discovering whether a proxy supports the extensions of outbound. > > While we could do that by doing a REGISTER exchange that includes > an appropriate option-tag in Require:, it would be more efficient > if the proxy discovery mechanism informed us of this detail. So, > we posit that the Outbound draft SHOULD select and discuss such a > mechanism." > > And in yet another email > http://www1.ietf.org/mail-archive/web/sip/current/msg13692.html > Dean tells this: > > "There are two ways we can establish compatibility with an extensions: > > 1) By foreknowledge > 2) By experimentation -- try it and see if it works. > > Both have limitations: > > In the case of #1, we might have incorrect knowledge. So we'll=20 > probably > end up testing anyhow . . . > > In the case of #2, the experiment might cause a meltdown. So the=20 > "probe > for discovery" must be made completely safe. Also, we can=20 > eventually end > up with so many wierd hooks and idiosyncratic implementations that we > end up doing a BUNCH of probing before we do any real=20 > communicating. And > it's possible for the conditions to deteriorate so much that probes=20 > for > two different possible conditions are mutually exclusive -- if one > condition applies, the probe for another will cause a meltdown. > > So what happens if we start STUN-probing a proxy on its SIP port=20 > and it > doesn't support STUN? My guess is, it's random. > > ... > > One approach to "forward compatibility" design is to make sure that we > can use both foreknowledge and experimentation -- the "trust but=20 > verify" > model. > > ... > > While it's easy to decide whether a configured registrar URI has a > keepalive parameter, what happens to proxies we select based on > something besides direct configuration? > > Specifically, > > 1) Can the DHCP option for default proxy present the keepalive > parameter?" > ---- > > During these three months after seeing those comments in the list > I have been expecting the outbound draft to provide answer to > the question how UA could (within SIP signalling exchange) > safely to check whether or not a proxy supports STUN keepalive. > Two mechanims have been suggested how the UA could do this in > a simple way: > > 1. The UA to check that the Path header in 200 OK returned for > REGISTER would contain keepalive=3Dstun parameter for the proxy URI > > 2. The UA to add Proxy-Reequire: stun-keepalive parameter into > the REGISTER request and the proxy to remove this tag from > the request before forwarding it towards the registrar > > For me, any of those mechanisms would sound feasible and for > safety reasons I would hope the draft to deny the UA for sending > STUN keepalives to the proxy which did not pass such a test. > >> the same problem exists for the "comp" parameter for example. > > Yes but please bear in mind that for comp=3Dsigcomp URI parameter > RFC 3486 Compressing SIP gives several solutions how the UA > would be able to check if the proxy supports SigComp while > outbound does not define any other than relying on configuration. > A cite from RFC 3486: > > 4.1 Obtaining a SIP or SIPS URI with comp=3Dsigcomp > > For requests within a dialog, a next-hop URI with the = comp=3Dsigcomp > parameter is obtained from a Record-Route header field when the > dialog is established. A client sending a request outside a dialog > can also obtain SIP URIs with comp=3Dsigcomp in a Contact header=20 > field > in a 3xx or 485 response to the request. > > However, clients establishing a session will not typically be=20 > willing > to wait until the dialog is established in order to begin=20 > compressing > messages. One of the biggest gains that SigComp can bring to=20 > SIP is > the ability to compress the initial INVITE of a dialog, when the=20 > user > is waiting for the session to be established. Therefore, clients > need a means to obtain a comp=3Dsigcomp URI from their outbound = proxy > before the user decides to establish a session. > > One solution to this problem is manual configuration. However, > sometimes it is necessary to have clients configured in an=20 > automatic > fashion. Unfortunately, current mechanisms for SIP client > configuration (e.g., using DHCP [6]) do not allow to provide the > client with URI parameters. In this case, the client SHOULD=20 > send an > uncompressed OPTIONS request to its outbound proxy. The outbound > proxy can provide an alternative SIP URI with the comp=3Dsigcomp > parameter in a Contact header field in a 200 OK response to the > OPTIONS. The client can use this URI for subsequent requests that > are sent through the same outbound proxy using compression. > > RFC 3261 [1] does not define how a proxy should respond to an=20 > OPTIONS > request addressed to itself. It only describes how servers respond > to OPTIONS addressed to a particular user. Section 11.2 of RFC=20 > 3261 > says: > > Contact header fields MAY be present in a 200 (OK) response and > have the same semantics as in a 3xx response. That is, they may > list a set of alternative names and methods of reaching the=20 > user. > > We extend this behavior to proxy servers responding to OPTIONS > addressed to them. They MAY list a set of alternative URIs to > contact the proxy. > > What has been called for is that outbound draft would also > specify one solution how the UA could check the STUN keepalive > support of a proxy. In my opinion good proposals seem > to exist how to do it in a reasonable way. > > Regards, > > Erkki > >> -----Original Message----- >> From: ext Rohan Mahy [mailto:rohan@ekabal.com] >> Sent: 04.July.2006 03:10 >> To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >> Cc: dean.willis@softarmor.com; fluffy@cisco.com; Rohan Mahy; >> sip@ietf.org; jbemmel@zonnet.nl >> Subject: Re: [Sip] Ready for WGLC on Outbound? >> >> Hi Erkki, >> >> The only time a UAC sends a STUN request as directed by >> outbound -04 is >> when the URI in the outbound-proxy-set includes the keepalive=3Dstun >> parameter. This is 100% backwards safe. We don't need any text to >> prevent existing implementations from getting a bunch of STUN=20 >> requests. >> >> That DHCP does not provide URI is a limitation of the SIP DHCP >> configuration mechanism, not outbound. The same problem >> exists for the >> "comp" parameter for example. If you want to write a draft on how to >> "shift-up" to using keepalives or using compression from some SIP or >> external stimulus, you can still do this. No text in outbound >> prevents >> that from happening. >> >> thanks, >> -rohan >> >> >> On Jun 29, 2006, at 23:10, wrote: >>> >>> Hi Rohan, >>> >>>>> Also, the issue is that what may be configured (no matter how you >>>>> configure it) may not be a URI. It may simply be an IP >> address/FQDN, >>>>> which is then used to build a SIP-URI. I think we shall >>>>> allow that, and make it more clear in the spec. [/CHH] >>>> >>>> the outbound spec defines a piece of configurable data (the >>>> 'outbound-proxy-set'), which is a list of URIs. This list >> of URIs may >>>> never have a one-to-one correspondence to a user or administrator >>>> manually configurable field. That piece of configurable data=20 >>>> may be >>>> derived from several fields, manually configurable, discovered via >>>> DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP >>>> download, or via a random character generator seeded by the=20 >>>> phase of >>>> the moon. >>>> >>>> The outbound-proxy-set was defined as a list of URIs because the UA >>>> acts on each item in the list, because each URI is expected to be >>>> places in a Route header, and because each URI is expected to >>>> typically have a keepalive URI parameter in it. >>> >>> Like mentioned in other recent emails the problem is that if the UA >>> derives the proxy URI(s) from DHCP SIP server option or e.g. the AOR >>> of the user, in those cases the derived URI will NOT contain the >>> keepalive URI parameter in it. DHCP just returns IP addresses or >>> domain names instead of URIs with parameters. >>> >>> Thus in those cases it would be critical for the UA to be able >>> to ensure in REGISTER - 200 OK sequence that the contacted proxy >>> supports Outbound and can handle STUN requests sent to its SIP >>> port (not to cause any damage to an uncompliant proxy). I fully >>> agree with this proposal from Jeroen: >>> >>> -- >>> The text should then say "the UAC MUST wait for a 200 OK to REGISTER >>> before >>> it starts sending STUN packets. If the last Path header of the=20 >>> 200 OK >>> does >>> not contain keepalive=3Dstun, the UAC MUST NOT use STUN >> towards this URI. >>> If >>> there are no Path headers and no "Supported: outbound", the UAC also >>> MUST >>> NOT use STUN towards the registrar.". It could still use TCP >> keepalive >>> if it >>> supports that >>> -- >>> >>> Please excuse me if I am just repeating myself and what e.g. Jeroen >>> has said but I believe the importance of this issue justifies some >>> redundancy :-) >>> >>> Regards, >>> >>> Erkki >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 04:44:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyPRK-0008Hz-04; Thu, 06 Jul 2006 04:42:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyPRH-0008Hp-SM for sip@ietf.org; Thu, 06 Jul 2006 04:42:23 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyPRG-00020R-3A for sip@ietf.org; Thu, 06 Jul 2006 04:42:23 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 486244F0259; Thu, 6 Jul 2006 10:42:21 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:42:20 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:42:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Thu, 6 Jul 2006 10:40:20 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594117D42@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A coment to draft-ietf-sip-outbound-04 Thread-Index: AcagIDsSY/BUfKkERpamvGnYla0VUwAt5War References: <44AB9820.4050200@nokia.com> From: "Christer Holmberg \(JO/LMF\)" To: "Miguel Garcia" , , "Cullen Jennings" , "Rohan Mahy" X-OriginalArrivalTime: 06 Jul 2006 08:42:20.0555 (UTC) FILETIME=[182BEDB0:01C6A0D8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi Miguel, =20 I agree with your text proposal. It is pretty much the same which was = proposed weeks ago, when the issue was brought up (eventhough the = wording may have been a little different). =20 Regards, =20 Christer =20 ________________________________ From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] Sent: Wed 05/07/2006 12:44 To: sip@ietf.org; Cullen Jennings; Rohan Mahy Subject: [Sip] A coment to draft-ietf-sip-outbound-04 Reading Section 4.2 of Outbound-04, there is a sentence that came to my attention. For each outbound proxy URI in the set, the UA MUST send a REGISTER in the normal way using this URI as the default outbound proxy. I think it is not appropriate to use a MUST strength in this case. I suspect that the spirit of the draft is to offer high availability by making the UA to establish one flow per URI, which is a good spirit. However, one has to evaluate the cost of establishing one flow per URI, which might be quite high in terms of battery consumption, for example (due to STUN refreshes). I also believe the MUST is misused here because it is not an absolute requirement for the specification. In other words, the SIP outbound procedures work OK even if the UA establishes just one flow (even when it is provisioned with several outbound URIs). Nothing is broken. So, we should be looking at adding a paragraph that describes the benefit of establishing one flow per outbound URI, but letting up to the UA's policy to decide on the absolute number of established flows. I would suggest to replace the above mentioned sentence with something around these lines: For each outbound proxy URI in the set, the UA MAY send a REGISTER in the normal way using this URI as the default outbound proxy. Sending one REGISTER per outbound proxy URI decreases the likelihood of interrupted service due to dropped connections at the cost of maintaining a living flow which each outbound proxy server. Comments? /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 05:23:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyQ3C-0008GI-Lq; Thu, 06 Jul 2006 05:21:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyQ3B-0008GD-QR for sip@ietf.org; Thu, 06 Jul 2006 05:21:33 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyQ3B-0007hJ-8l for sip@ietf.org; Thu, 06 Jul 2006 05:21:33 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k669LMQf010094; Thu, 6 Jul 2006 12:21:23 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 12:21:19 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 12:21:19 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A coment to draft-ietf-sip-outbound-04 and max-flows indication Date: Thu, 6 Jul 2006 12:21:17 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0280E036@esebe103.NOE.Nokia.com> In-Reply-To: <44ACBF9F.2050303@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A coment to draft-ietf-sip-outbound-04 and max-flows indication Thread-Index: Acag0C7ZClrfP7lUQA2DUwX0nDsBGAAAGPKQ From: To: X-OriginalArrivalTime: 06 Jul 2006 09:21:19.0101 (UTC) FILETIME=[8A0DBAD0:01C6A0DD] X-Spam-Score: 0.2 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: sip@ietf.org, fluffy@cisco.com, jh@tutpro.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Miguel, >So why would you publish 4 servers with the same Priority in SRV, but=20 >don't want 4 flows, but still want load balancing among what? =20 What I meant is that a service provider might provide e.g. 4 proxies for load balancing (over the whole UA population)=20 while deciding that 2 flows per UA would be sufficient for=20 reliability. Note that DNS SRV allows the UAs to select=20 different servers for their flows, like this: UA1 would connect to P1 and P2 UA2 would connect to P1 and P3 UA3 would connect to P3 and P4 If the service provider aims to have different SRV weights for each of those proxies to get bigger amount of load to servers with more capacity and less amount of load for the rest of the servers, it would no more be possible with the solution you outlined. Each of the UAs would create a flow to each server and assuming that each of the flows will be treated equally, each of the proxies would get equal amount=20 of the total load. --- An example with 3 proxies to clarify what I mean: With legacy TCP SIP the DNS SRV is used so that each=20 UA would create a connection to single proxy only. So assume we have 100 UAs so that each of those will generate and recieve equal amount of traffic over 3 proxies. P1 has SRV weight 5 and 50 UAs will connect to it P2 has SRV weight 3 and 30 UAs will connect to it P3 has SRV weight 2 and 20 UAs will connect to it In this TCP SIP example P1 will get 50%, P2 30% and P2 20% of the load within the domain. With your suggestion with outbound the situation=20 would be changed so that each of the 100 UA would create connections to each of the three proxies. If those connections are handled in an equal way the traffic will be distributed equally to each of the proxies, so each will get 33% of the load. However if the service provider would decide that for reliability one connection is sufficient the result would be the same as without outbound i.e. P1: 50% P2: 30% P3:20% If the service provider decides that two flows per UA is needed for reliability and flows are treated equally the calculation is no that trivial but should result pretty similar load balancing figures: 50 UAs would select P1 for the primary flow 30 of them would select P2 for the secondary flow 20 of them would select P3 for the secondary flow 30 UAs would select P2 for the primary flow 21 of them would select P1 for the secondary flow 9 of them would select P3 for the secondary flow 20 UAs would select P3 for the primary flow 12 of them would select P1 for the secondary flow 8 of them would select P2 for the secondary flow So the result would be altogether this: P1 would have 83 flows i.e. 41 % of the load P2 would have 68 flows i.e. 34 % of the load P3 would have 49 flows i.e. 25 % of the load This is why I suggest that your proposal would make a considerable difference for the load balancing that service provider can make. It would mean equal load for each of the servers while SRV RRs usually enable the provider to share the load unequally to different proxies based on their capacities. Regards, Erkki >-----Original Message----- >From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 >Sent: 06.July.2006 10:46 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: Juha Heinanen; sip@ietf.org; Cullen Jennings; Rohan Mahy >Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 > >Koivusalo Erkki (Nokia-TP-MSW/Helsinki) wrote: > >> What comes to your suggestion on using DNS... >>=20 >>> The other alternative solution it comes to my mind is to=20 >play with the=20 >>> Priority of the SRV record. So we could say that the UA=20 >establishes a=20 >>> flow to each server defined with the lower Priority.=20 >Servers defined=20 >>> with higher priority will be used in cases of failure. >>=20 >> ... it seems that there is a drawback. If SRV records would >> be used like that, then a service provider could not any more >> use the SRV RRs with same level of priority for balancing the >> load for the UA population, wishing each UA to maintain lower >> number of flows than the number of servers in that priority level. >> E.g. balancing the load to 4 servers would require every UA to >> maintain 4 flows, which would be impractical and cause extra >> load (for keepalives and registration refreshes) for all those >> proxies. >>=20 > >So why would you publish 4 servers with the same Priority in SRV, but=20 >don't want 4 flows, but still want load balancing among what?=20 >Strange... > >/Miguel > >--=20 >Miguel A. Garcia tel:+358-50-4804586 >sip:miguel.an.garcia@openlaboratory.net >Nokia Research Center Helsinki, Finland > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 06:05:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyQhd-000586-5q; Thu, 06 Jul 2006 06:03:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyQhb-00054H-C0 for sip@ietf.org; Thu, 06 Jul 2006 06:03:19 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyQhY-0002bP-Jh for sip@ietf.org; Thu, 06 Jul 2006 06:03:19 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k66A3EEv015048; Thu, 6 Jul 2006 13:03:15 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 13:03:09 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 13:03:09 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on draft-koivusalo-sip-outbound-discovery-02 Date: Thu, 6 Jul 2006 13:03:08 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0280E06D@esebe103.NOE.Nokia.com> In-Reply-To: <44AA0D15.6080208@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-koivusalo-sip-outbound-discovery-02 Thread-Index: AcafNJpFbas5zoqlSyWwh3TbWbHo/wAvqYRQ From: To: , X-OriginalArrivalTime: 06 Jul 2006 10:03:09.0552 (UTC) FILETIME=[62662700:01C6A0E3] X-Spam-Score: 1.3 (+) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >> 1) I need to understand whether this updates RFC 3263 or=20 >just extends it. Part of this is what appears on the cover=20 >page and in the RFC index as and when it is finally approved,=20 >but the other part also relates to compatibility, see later comment. >To answer your first question, I believe this draft updates RFC 3263. Yesterday we discussed this question with Miguel and our conclusion was that we are not sure if it extends or updates. Depends on what these words actually mean. Can someone help by providing definitions or examples of those ? My opinion is that my draft only extends RFC 3263, so the wording in the draft would have to be revised accordingly. Reasoning behind my opinion is this: - My draft at least does not make RFC 3263 obsolete. RFC 3263 would still be used when the UA tries to connect "legacy" SIP proxies without outbound support. - The procedures in my draft suggest a different way for the UA to handle the DNS NAPTR and SRV responses like RFC 3263 does. However the UA uses these different procedures only when it specifically tries to find and contact 1-N proxies supporting outbound, instead of resolving SIP URIs for any other purpose. - My draft is not independent of RFC 3263, it just highlights how the processing differs from what is described in 3263=20 but does not repeat those procedures of the RFC that still=20 apply. >> 2) I think you have already acknowledged this, but the=20 >document requires revision to align with the terminology in=20 >the latest version (-04) of draft-ietf-sip-outbound. I already tried to align the terminology, so please be more specific on what kind of alignment is needed. If=20 you simply mean usage of word "backup" in certain context, that will be removed if the corresponding use case and requirement REQ-PROXY-FARM-03 will be dropped (like I suggested in another thread). On the other hand it might still be that my draft would continue promoting the way of the domain have a pool of idle backup servers. However it would probably require the outbound draft itself to be updated like Adam suggested today: --- >In internal discussions, we came up with realistic scenarios=20 >whereby a client may reasonably end up maintaining two=20 >connections with very different characteristics (UDP versus=20 >TLS would be an extreme example), and be willing to use both=20 >of them, but *strongly* prefer one over the other. > >To handle this situation, it might make sense to put stuff in=20 >6.2 that basically says that, for contacts with matching=20 >instance-ids, the proxy MUST NOT try a contact until all=20 >contacts at a higher q-value have been tried first. --- >> 3) In section 5, as far as I understand, the NAPTR request=20 >is identical for a UA that supports RFC 3263 and for one that=20 >supports this extension. Therefore the difference is in the=20 >response.=20 Correct. What the draft currently says is this: The procedures here are invoked when a UA needs to send a REGISTER request via a proxy supporting SIP Outbound and set up a persistent flow towards that proxy. The starting point is that the UA has a SIP or SIPS (secure SIP) URI of the proxy without port, transport or maddr parameters as the next hop. According to RFC 3263 [2] the UA "SHOULD perform a NAPTR query for the domain in the URI." This specification assumes the UA would proceed to perform the NAPTR query and related SRV queries as specified in RFC 3263, but with the exceptions defined below. I would like to revise it slightly as follows: specification assumes the UA would proceed to perform the NAPTR query and related SRV queries as specified in RFC 3263, but processing the DNS NAPTR responses using the extensions as defined below. >> Therefore the paragraph of UA requirements: >>=20 >> As per RFC 2915 [4], the client discards any NAPTR records whose >> services fields are not applicable. A client resolving a SIPS URI >> MUST discard any services that do not contain "SIPS-O" as the >> protocol in the service field. A client resolving a SIP URI MUST >> retain records with "SIP-O" and the transport protocols the client >> supports and SHOULD retain records with "SIPS-O", if the client >> supports TLS. >>=20 >> must work with a NAPTR response that has no knowledge of=20 >outbound. Is the above paragraph compatible with this?=20 >And with respect your third question, I agree that the draft does not=20 >consider the case when Outbound is not deployed, so the text has to be=20 >updated to reflect the case. Right now in the draft there is later a paragraph descriging a=20 fallback to use RFC 3263 procedures if the SIP-O records are=20 not defined for the domain: When performing NAPTR queries as specified in this document, if the UA is not able to resolve the URI of the proxy successfully to any IP address or if connecting to each of the resolved addresses fails, then the UA MAY try resolving the URI using the procedures defined in RFC 3263 [2]. When doing this fallback UA MUST NOT assume the resolved target host to support SIP Outbound. What I have to do is to integrate this paragraph describing the fallback behaviour with the paragraph you highlighted. I hope that would make the story consistent and easily understandable. Also changing the MAY=20 to SHOULD or MUST is probably needed ? >I have also a couple of other non-nit comments. > >1) I think the draft has to be a bit more strict on where this draft=20 >ends and when Outbound begins. At the moment I found this line quite=20 >fuzzy. Assuming this draft is about discovery, but not=20 >execution of the outbound procedures, I believe requirement=20 >REQ-OUTB-DISC-6 has not much to do with discovery, but with outbound.=20 I and Miguel did not reach an agreement about this, so Miguel started a thread on a mailing list for the number of flows the UA is expected to create. The resolution for my draft depends on what happens to outbound draft. In my opinion it would still be in the scope of the autodiscovery draft to define how many flows the UA should set up if it discovers N proxies in the domain to support outbound (and thus be able to derive outbound-proxy-set=20 consisting of N proxies). N flows might not always be the optimal answer. >The same applies to several=20 >paragraphs in Section 5, when the draft describes actions=20 >taken upon a reception of a 200 response for a REGISTER request. I admit that some of the stuff from my draft would apparently belong in the scope of the outbound draft and could eventually be removed from the autodiscovery draft. More specifically all normative text about how the UA uses the flows (and perhaps assigns the q values for the related Contacts) could belong to this category. What I am not sure is whether those pieces of text (autodiscovery of flows and the usage of those flows)=20 could be separated to two different drafts so that the story=20 would still be understandable and the reader to be able to map these pieces together. This needs further study and also cooperation with authors of outbound. >2) The first paragraph in Section 2.4.4 suggests that a=20 >non-standardized autodiscovery mechanism will require the=20 >UA to insert a "Proxy-Require: outbound". Care must be=20 > taken to avoid that this becomes the de-facto=20 >behavior. It must noted that such Proxy-Require will require=20 >each of the proxies en route to the registrar to support=20 >outbound, which might not be the desired behavior. I would=20 >suggest to add some more text describing this case and=20 >highlighting the problem. I agree with Miguel that this problem must be added to make sure that such a solution would not be used. However the exact formulation depends on if outbound draft will be revised for Proxy-Require usage or not. This is currently under discussion. >3) IANA: something is not clear to me. Is this draft creating a new=20 >registry (as it suggest Sections 4 and 7), named "Registry for=20 >the NAPTR=20 >Resource Record Services Fiedl", or is it updating the=20 >existing registry=20 >at http://www.iana.org/assignments/sip-table > >I thought it would be the latter, but the fact that the existing=20 >registry refers to SRV records rather than NAPTR makes me doubt. Can=20 >someone clarify? We agreed that my draft would update the existing registry. Unfortunately the current register seems to incorrectly refer to SRV RRs even if it is for NAPTR RRs. Miguel tries to get the IANA registry fixed. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 06:09:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyQlt-0003G1-AZ; Thu, 06 Jul 2006 06:07:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyQls-0003Fi-0z for sip@ietf.org; Thu, 06 Jul 2006 06:07:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyPgP-0004dq-5v for sip@ietf.org; Thu, 06 Jul 2006 04:58:01 -0400 Received: from smtp1.wanadoo.co.uk ([193.252.22.158] helo=smtp1.freeserve.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyPZe-0000Qj-VO for sip@ietf.org; Thu, 06 Jul 2006 04:51:05 -0400 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3006.me.freeserve.com (SMTP Server) with ESMTP id 9B34D1C00088; Thu, 6 Jul 2006 10:50:57 +0200 (CEST) Received: from RW (user-1587.wfd77b.dsl.pol.co.uk [84.64.94.51]) by mwinf3006.me.freeserve.com (SMTP Server) with SMTP id 0FE4D1C00085; Thu, 6 Jul 2006 10:50:57 +0200 (CEST) X-ME-UUID: 20060706085057652.0FE4D1C00085@mwinf3006.me.freeserve.com Message-ID: <003901c6a0d9$4be9f8d0$ae00a8c0@RW> From: "Pete Cordell" To: , References: <532B18E13CF9E64380EF5FDDE265E071166B24@blr-m2-msg.wipro.com> Subject: Re: [Sip] Update to fork-loop-fix submitted Date: Thu, 6 Jul 2006 09:50:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: -2.6 (--) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Has it been discussed whether the hash function needs to be of cryptographic strength? For example, hash functions used by hash tables are much simpler to compute, but typically have reasonable collision avoidance. For example, one book I have [1] suggests a iteration step of a hash function of: hash = hash * MULTIPLIER + data[n]; where MULTIPLIER is 31 or 37. (This does assume that multiply is a single cycle operation - or nearly - which I believe it is for most modern processors.) If you were paranoid you could compute two hashes with the different MULTIPLIERs and concatenate the result! Pete. [1] Kernigan & Pike, "The Practice of Programming", 1999 -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= ----- Original Message ----- From: To: Cc: Sent: Thursday, July 06, 2006 5:43 AM Subject: RE: [Sip] Update to fork-loop-fix submitted It is always better to reduce the computation in the path of normal success case and introduce it in the path of a rarer scenario. I think it will be a fair assumption to make that Spirals will be rarer than the non-spiraling scenarios. In terms of increasing logic, the increase in logic would be very small if it all any. It would be a trade-off that should be left to the implementer to take if he considers that hash computation is expensive on his platform. If this id recommends the computation of hash at the MUST strength in the first pass of the SIP request, an implementer would not have that freedom to make that trade-off.. Regards, Ravi. -- Ravishankar. G. Shiroor Wipro Technologies, Bangalore. ravishankar.shiroor@wipro.com -- > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Wednesday, July 05, 2006 8:21 PM > To: RaviShankar Shiroor (WT01 - Product Engineering Solutions) > Cc: sip@ietf.org > Subject: Re: [Sip] Update to fork-loop-fix submitted > > I understand the suggestion. You are trading off letting the > request through a loop one extra cycle for some lower amount > of processing the first time the request went through the > proxy. If you believe that spirals are relatively rare > things, this change would result in proxies very rarely > having to build the loop/spiral differentiation hash. > > But as Jonathan points out, it's not clear that the hash > computation is expensive enough to warrant this extra logic > and the extra network traffic it would allow. I expect that > the hash calculation expense is small compared to the > parse/search/compare operations for "Proxy checks to see if > its address is there in the via already". > > RjS > > On Jul 3, 2006, at 5:39 AM, > wrote: > > > > > Hi Robert, > > > > I had suggested one more alternative > > > > (http://www1.ietf.org/mail-archive/web/sip/current/msg14359.html ) > > > > Quoted from my previous mail: > > > > > > I was thinking how to reduce the impact of overhead for > calculating > > the > > digest. > > > > If it is suggested as follows, I think it will reduce the > overhead on > > normal scenarios: > > > > Proxy checks to see if its address is there in the via already. > > If it is not there, it proceeds normally without calculating the > > digest > > and inserting Via to the outgoing request without the digest. > > If it is there, then it is possible that the request is looping. So, > > this time around, it calculates a digests and inserts and sends it > > along. > > If it is looping, the request will definitely come in > again, which can > > be rejected. > > This way the impact of calculating the digest is required (reduced > > to a > > smaller percent of the sessions) only when the proxy is > suspicious the > > request might be looping. > > Of course this results in the scenarios mentioned in the id to be > > successful in completing the first loop, but the second loop will be > > detected and arrested. I think this can be applicable to > general loop > > detection, and not just fork loop fixes. > > > > > > Regards, > > Ravi. > > > > -- > > > > Ravishankar. G. Shiroor > > Wipro Technologies, Bangalore. > > > > ravishankar.shiroor@wipro.com > > -- > > > > > >> -----Original Message----- > >> From: Robert Sparks [mailto:rjsparks@nostrum.com] > >> Sent: Sunday, June 25, 2006 8:22 PM > >> To: IETF SIP List > >> Subject: [Sip] Update to fork-loop-fix submitted > >> > >> Until it appears in the repository, see: > >> > http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-02.txt > >> > >> This was a moderately heavy touch - based on list feedback, > >> I've moved and updated the sections covering the > >> loopdetection algorithm in from 3261. In the process of > >> writing the clarifying text, I discovered several places that > >> need clarification. They are listed as Open Issues in the > >> draft. Basically there are fields that I can't recall or > >> reconstruct how they would be useful in the part of the hash > >> used for loop-detection or spiral differentiation. If anyone > >> can remember why they need to be included, send a note to the > >> list and we'll capture that in the draft. > >> > >> Please review the updated loop-detection text very carefully. > >> > >> Here's the changelog from the draft: > >> > >> Integrated several editorial fixes suggested by > >> Jonathan Rosenberg > >> > >> Noted that the reduction of the attack to a single > >> registration > >> against a single URI as documented in previous versions, > >> is, in > >> fact, going to be effective against implementations > >> conforming to > >> the standards before this repair. > >> > >> Re-incorporated motivation from the original > >> maxforwards-problem > >> draft into the security considerations section based > >> on feedback > >> from Cullen Jennings > >> > >> Introduced replacement text for the loop detection algorithm > >> description in RFC 3261, fixing the bug 648 (the > >> topmost Via value > >> must not be included in the second part) and clarifying the > >> algorithm. Removed several other fields suggested > by 3261 and > >> placed open issues around their presence. > >> > >> Added a Notes to Implementors section capturing the > >> "common way" > >> text and pointing to the interoperability issues that have > >> been > >> observed with loop detection at previous SIPits > >> > >> > >> Thanks, > >> > >> RjS > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use > >> sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > > > > The information contained in this electronic message and any > > attachments to this message are intended for the exclusive use of > > the addressee(s) and may contain proprietary, confidential or > > privileged information. If you are not the intended recipient, you > > should not disseminate, distribute or copy this e-mail. Please > > notify the sender immediately and destroy all copies of this > > message and any attachments. > > > > WARNING: Computer viruses can be transmitted via email. The > > recipient should check this email and any attachments for the > > presence of viruses. The company accepts no liability for any > > damage caused by any virus transmitted by this email. > > > > www.wipro.com > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 06:38:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyRDq-0007ld-80; Thu, 06 Jul 2006 06:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyRDo-0007lV-V3 for sip@ietf.org; Thu, 06 Jul 2006 06:36:36 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyRDn-0008QA-Op for sip@ietf.org; Thu, 06 Jul 2006 06:36:36 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k66AaY4Z018106 for ; Thu, 6 Jul 2006 05:36:34 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ9T26C>; Thu, 6 Jul 2006 11:36:34 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369D426@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Thu, 6 Jul 2006 11:36:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] A thought on progressing outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) Having looked at some of the comments on outbound being addressed to the list in the last few days, it occurs to me that at least of you have fundamental requirements that impact the solution and these requirements themselves need to be discussed. Hidden in the current draft you will find section 12 labelled "requirements". This is a somewhat thin section at the moment (not necessarily a bad thing). Can you all please review this section, and identify whether these requirements encompass all the requirements that you wish to have met in outbound, and then try to motivate what you think is missing. And as always "send text". regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 06:38:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyRDl-0007kl-Hp; Thu, 06 Jul 2006 06:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyRDk-0007kZ-0q for sip@ietf.org; Thu, 06 Jul 2006 06:36:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyPgQ-0004dq-Qb for sip@ietf.org; Thu, 06 Jul 2006 04:58:02 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyPYD-0000PM-LX for sip@ietf.org; Thu, 06 Jul 2006 04:49:36 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 788304F006D; Thu, 6 Jul 2006 10:49:28 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:49:27 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 From sip-bounces@ietf.org Thu Jul 06 06:38:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyRDq-0007ld-80; Thu, 06 Jul 2006 06:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyRDo-0007lV-V3 for sip@ietf.org; Thu, 06 Jul 2006 06:36:36 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyRDn-0008QA-Op for sip@ietf.org; Thu, 06 Jul 2006 06:36:36 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k66AaY4Z018106 for ; Thu, 6 Jul 2006 05:36:34 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ9T26C>; Thu, 6 Jul 2006 11:36:34 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369D426@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Thu, 6 Jul 2006 11:36:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] A thought on progressing outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) Having looked at some of the comments on outbound being addressed to the list in the last few days, it occurs to me that at least of you have fundamental requirements that impact the solution and these requirements themselves need to be discussed. Hidden in the current draft you will find section 12 labelled "requirements". This is a somewhat thin section at the moment (not necessarily a bad thing). Can you all please review this section, and identify whether these requirements encompass all the requirements that you wish to have met in outbound, and then try to motivate what you think is missing. And as always "send text". regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 06:38:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyRDl-0007kl-Hp; Thu, 06 Jul 2006 06:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyRDk-0007kZ-0q for sip@ietf.org; Thu, 06 Jul 2006 06:36:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyPgQ-0004dq-Qb for sip@ietf.org; Thu, 06 Jul 2006 04:58:02 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyPYD-0000PM-LX for sip@ietf.org; Thu, 06 Jul 2006 04:49:36 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 788304F006D; Thu, 6 Jul 2006 10:49:28 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:49:27 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:49:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: Validating if the proxy supports outbound or not Date: Thu, 6 Jul 2006 10:47:38 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594117D44@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Validating if the proxy supports outbound or not Thread-Index: AcagwHzle1JwOppmTxCANtPGJSrQ9wACN0TQAAPe/wI= References: <8B1D53AEF7B03449A6D3771B3B7F850F0280DF24@esebe103.NOE.Nokia.com> From: "Christer Holmberg \(JO/LMF\)" To: , , X-OriginalArrivalTime: 06 Jul 2006 08:49:27.0593 (UTC) FILETIME=[16B4C190:01C6A0D9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: BPenfield@acmepacket.com, adam@nostrum.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, =20 We talk about "keepalive=3Dstun", and we talk about edge proxies = supporting outbound. =20 I think we need to separate the issues. =20 1. Whether the edge proxy supports STUN for keep-alive, and whether it = needs to be able to "indicate" that. =20 2. Whether the edge proxy supports outbound (in which case it also = supports STUN for keep-alive), and whether it needs to be able to = "indicate" that. =20 Regards, =20 Christer ________________________________ From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] Sent: Thu 06/07/2006 09:10 To: sip@ietf.org; rohan@ekabal.com Cc: BPenfield@acmepacket.com; adam@nostrum.com Subject: RE: [Sip] Outbound: Validating if the proxy supports outbound = or not Hi, The comments sent on the list during last few days seem to indicate reasonably large concern that it is not sufficient for the UA to check that the configured proxy URI contains keepalive=3Dstun parameter, in order for the UA to make sure that the proxy actually supports outbound. Thus I will expect that the next version of outbound draft will address this issue. Note that the authors of the draft have promised to raise this as an open issue in the WG meeting, so please be prepared to contribute that discussion. The comments I am referring to are this (mine included): Bob Penfield: >Does that mean that a UA should not send STUN if the >keepalive=3Dstun is not present? > >If so, will outbound be useful prior to the completion of the various >configuration mechanisms? And is it acceptable for a >mis-configured UA to cause the proxy or the registrar to crash or mis-behave? > >A mechanism such as the proposed Proxy-Require/Require method >similar to sec-agree allows the UA to determine that the proxy and >registrar support STUN before it sends and potentially harmful messages. Adam Roach: >I think this can be fixed with a little more behavior around what >edge-proxies that support this draft are required to do. Specifically: >since section 5.1 already has some pretty strong normative >language that >requires edge-proxies to insert Path header fields with certain >properties, it's a rather small leap to dictate that the form of the >URIs in these Path header fields must include something that the >registrar can use to verify outbound support. > >With that in place, the registrar can now look at an inbound REGISTER >request and (in addition to checking the Contact header field) look >through the Path header fields to ensure that all of them contain URIs >with ";outbound" parameters. If they don't, it canJul 2006 10:49:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: Validating if the proxy supports outbound or not Date: Thu, 6 Jul 2006 10:47:38 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594117D44@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Validating if the proxy supports outbound or not Thread-Index: AcagwHzle1JwOppmTxCANtPGJSrQ9wACN0TQAAPe/wI= References: <8B1D53AEF7B03449A6D3771B3B7F850F0280DF24@esebe103.NOE.Nokia.com> From: "Christer Holmberg \(JO/LMF\)" To: , , X-OriginalArrivalTime: 06 Jul 2006 08:49:27.0593 (UTC) FILETIME=[16B4C190:01C6A0D9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: BPenfield@acmepacket.com, adam@nostrum.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, =20 We talk about "keepalive=3Dstun", and we talk about edge proxies = supporting outbound. =20 I think we need to separate the issues. =20 1. Whether the edge proxy supports STUN for keep-alive, and whether it = needs to be able to "indicate" that. =20 2. Whether the edge proxy supports outbound (in which case it also = supports STUN for keep-alive), and whether it needs to be able to = "indicate" that. =20 Regards, =20 Christer ________________________________ From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] Sent: Thu 06/07/2006 09:10 To: sip@ietf.org; rohan@ekabal.com Cc: BPenfield@acmepacket.com; adam@nostrum.com Subject: RE: [Sip] Outbound: Validating if the proxy supports outbound = or not Hi, The comments sent on the list during last few days seem to indicate reasonably large concern that it is not sufficient for the UA to check that the configured proxy URI contains keepalive=3Dstun parameter, in order for the UA to make sure that the proxy actually supports outbound. Thus I will expect that the next version of outbound draft will address this issue. Note that the authors of the draft have promised to raise this as an open issue in the WG meeting, so please be prepared to contribute that discussion. The comments I am referring to are this (mine included): Bob Penfield: >Does that mean that a UA should not send STUN if the >keepalive=3Dstun is not present? > >If so, will outbound be useful prior to the completion of the various >configuration mechanisms? And is it acceptable for a >mis-configured UA to cause the proxy or the registrar to crash or mis-behave? > >A mechanism such as the proposed Proxy-Require/Require method >similar to sec-agree allows the UA to determine that the proxy and >registrar support STUN before it sends and potentially harmful messages. Adam Roach: >I think this can be fixed with a little more behavior around what >edge-proxies that support this draft are required to do. Specifically: >since section 5.1 already has some pretty strong normative >language that >requires edge-proxies to insert Path header fields with certain >properties, it's a rather small leap to dictate that the form of the >URIs in these Path header fields must include something that the >registrar can use to verify outbound support. > >With that in place, the registrar can now look at an inbound REGISTER >request and (in addition to checking the Contact header field) look >through the Path header fields to ensure that all of them contain URIs >with ";outbound" parameters. If they don't, it can take evasive action >(perhaps not returning the "Supported: outbound" header field in the >response?) that prevents things from going wrong. Erkki Koivusalo: >The specific concerns that I have (and would like the WG to >consider in the meeting) are closely related to what you told: > >>We got very strong feed back on one point - don't send >>STUN messages to a proxy unless you know it supports them. > >Does the WG consider checking the configured URI as a safe enough >check for the UA to ensure that the SIP proxy support STUN ? > >In my opinion it is not. As an example a vendor X could implement >a compliant but bad UA which provides an option for the user to >configure the settings via an User Interface e.g. like this: >"Is the phone behind a NAT: Yes/No". When the user selects >"Yes" the UA would add the keepalive=3Dstun flag to the proxy URI >even if the user does not have a clue if the proxy actually >supports outbound or not. There is nothing in outbound draft >to prevent such unsafe implementations to appear. Jeroen van Bemmel: >The point is that these are really 2 separate issues: >1. Discovering the set of outbound proxy URIs (with keepalive=3Dstun >parameters in them) >2. Confirming that a given proxy in the set actually supports >outbound (ie validating the keepalive=3Dstun information) > >Of these 2 options, (1) is indeed a separable problem. >(2) - to me - is not, for me outbound is not acceptable >without something to address (2). Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip take evasive action >(perhaps not returning the "Supported: outbound" header field in the >response?) that prevents things from going wrong. Erkki Koivusalo: >The specific concerns that I have (and would like the WG to >consider in the meeting) are closely related to what you told: > >>We got very strong feed back on one point - don't send >>STUN messages to a proxy unless you know it supports them. > >Does the WG consider checking the configured URI as a safe enough >check for the UA to ensure that the SIP proxy support STUN ? > >In my opinion it is not. As an example a vendor X could implement >a compliant but bad UA which provides an option for the user to >configure the settings via an User Interface e.g. like this: >"Is the phone behind a NAT: Yes/No". When the user selects >"Yes" the UA would add the keepalive=3Dstun flag to the proxy URI >even if the user does not have a clue if the proxy actually >supports outbound or not. There is nothing in outbound draft >to prevent such unsafe implementations to appear. Jeroen van Bemmel: >The point is that these are really 2 separate issues: >1. Discovering the set of outbound proxy URIs (with keepalive=3Dstun >parameters in them) >2. Confirming that a given proxy in the set actually supports >outbound (ie validating the keepalive=3Dstun information) > >Of these 2 options, (1) is indeed a separable problem. >(2) - to me - is not, for me outbound is not acceptable >without something to address (2). Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 07:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySH9-0000pR-Ma; Thu, 06 Jul 2006 07:44:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySH8-0000pM-EP for sip@ietf.org; Thu, 06 Jul 2006 07:44:06 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FySH6-0007Sl-Uf for sip@ietf.org; Thu, 06 Jul 2006 07:44:06 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k66Bhxpu025961; Thu, 6 Jul 2006 14:44:02 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 14:44:02 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 14:44:01 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound Comment: q-value Date: Thu, 6 Jul 2006 14:44:01 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0280E132@esebe103.NOE.Nokia.com> In-Reply-To: <17580.44383.443990.716678@rautu.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Comment: q-value Thread-Index: AcagxbnophCaIb4ISC+66GHTeW0g1wAKW6zg From: To: , X-OriginalArrivalTime: 06 Jul 2006 11:44:01.0868 (UTC) FILETIME=[79DC48C0:01C6A0F1] X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, The q-value scheme Adam suggested would make sense if it would be used together with the idle backup server scheme outlined in draft-koivusalo-sip-outbound-discovery-02: If the domain has SRV records for proxies supporting outbound with different SRV 'priority' values, then when sending REGISTER requests the UA would assign the q-values like this: - For the primary flow created towards a proxy with lowest SRV priority value the UA assigns the biggest=20 q-value (to indicate this is the active flow) - For the secondary flow created towards a proxy with a higher SRV priority value (an idle backup proxy) the UA would assign a lower q-value (to indicate that this is a backup flow) Since the DNS SRV records are in control of the service provider, this scheme would not cause any problems for the environments like Juha has. He just need to assign the very same 'priority' value for all his SRV records to make sure that UA uses same q-value towards all the proxies. In environments where the location service (registrar) is on a single server which sees all the flows and the related contact bindings this usage of q-value could be used in a=20 straightforward way. =20 But whether it is in this phase still possible to get such ideas for q-value usage to be adopted to outbound draft ... well it is something extra and I am far from sure if any consensus could be reached about that quickly enough in order not to delay the draft yet another four months ... Regards, Erkki >-----Original Message----- >From: ext Juha Heinanen [mailto:jh@tutpro.com]=20 >Sent: 06.July.2006 09:28 >To: Adam Roach >Cc: Cullen Jennings; SIP WG >Subject: [Sip] Outbound Comment: q-value > >Adam Roach writes: > > > To handle this situation, it might make sense to put stuff in 6.2 > > that basically says that, for contacts with matching instance-ids, > > the proxy MUST NOT try a contact until all contacts at a higher > > q-value have been tried first. (I could go along with a weaker > > strength, but I really do think a prescriptive approach is the only > > thing that allows the clients to handle the situation I describe > > above in a manner that is predictable to the users). > >i you suggesting that proxies consult each other about the q-value UA >used when registering with each proxy before forwarding a=20 >request to the >UA? if so, your suggesting makes no sense. > >-- juha > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 08:49:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTH2-00055r-LA; Thu, 06 Jul 2006 08:48:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTH0-00055G-Q1 for sip@ietf.org; Thu, 06 Jul 2006 08:48:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FySnF-0002MS-7j for sip@ietf.org; Thu, 06 Jul 2006 08:17:17 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FySKR-0003KO-Ka for sip@ietf.org; Thu, 06 Jul 2006 07:47:33 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k66BlTwi014194; Thu, 6 Jul 2006 14:47:29 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 14:47:29 +0300 Received: from [172.21.34.132] ([172.21.34.132]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 6 Jul 2006 14:47:29 +0300 Message-ID: <44ACF851.4080508@nokia.com> Date: Thu, 06 Jul 2006 14:47:29 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] A thought on progressing outbound References: <475FF955A05DD411980D00508B6D5FB01369D426@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB01369D426@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2006 11:47:29.0442 (UTC) FILETIME=[F5959020:01C6A0F1] X-Spam-Score: -2.4 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't have any problem with the current list of requirements in Section 12. The problem is that text in the draft seems to go beyond these requirements and impose a certain mandatory redundancy scheme, to which I strongly disagree as a "mandatory" feature. /Miguel Drage, Keith (Keith) wrote: > (As WG chair) > > Having looked at some of the comments on outbound being addressed to the list in the last few days, it occurs to me that at least of you have fundamental requirements that impact the solution and these requirements themselves need to be discussed. > > Hidden in the current draft you will find section 12 labelled "requirements". This is a somewhat thin section at the moment (not necessarily a bad thing). > > Can you all please review this section, and identify whether these requirements encompass all the requirements that you wish to have met in outbound, and then try to motivate what you think is missing. > > And as always "send text". > > regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 12:18:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWWl-00077M-Vu; Thu, 06 Jul 2006 12:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWWl-00077H-6a for sip@ietf.org; Thu, 06 Jul 2006 12:16:31 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyWWj-0002rC-EA for sip@ietf.org; Thu, 06 Jul 2006 12:16:31 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D3E6B8E0013; Thu, 6 Jul 2006 18:14:45 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 18:14:45 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 18:14:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Thu, 6 Jul 2006 18:11:13 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5940294EB44@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on Outbound? Thread-Index: AcagGRSZANhSZYNlS/yfO2KOUFIG5wA/bi55 References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com><553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com><003e01c69fb1$ad32e760$31713b51@BEMBUSTER><17579.25760.584180.394914@rautu.tutpro.com><005c01c6a00c$47763a20$31713b51@BEMBUSTER> <17579.31823.351859.567955@rautu.tutpro.com> From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" , "Jeroen van Bemmel" X-OriginalArrivalTime: 06 Jul 2006 16:14:44.0860 (UTC) FILETIME=[4B702BC0:01C6A117] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Cullen Jennings , sip@ietf.org, rohan@ekabal.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Does a proxy supporting STUN keep-alive have to be an "outbound proxy" = (assuming you mean an edge proxy), as defind in the outbound spec? =20 Or, what do you mean by "outbound proxy"? As defined in 3261? =20 Regards, =20 Christer =20 ________________________________ From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Wed 05/07/2006 10:46 To: Jeroen van Bemmel Cc: Cullen Jennings; sip@ietf.org; dean.willis@softarmor.com; = rohan@ekabal.com Subject: Re: [Sip] Ready for WGLC on Outbound? Jeroen van Bemmel writes: > Currently deployed proxies generally do not support STUN, especially = not on > the same ports that they use for SIP. Sending a STUN packet to such a = proxy > could very well be harmless, but it could also cause it to crash. sure, but those proxies are not outbound proxys and should not be listed as such. problem solved. > Sure, we can state "any proxy listed as outbound proxy MUST support = STUN". > We might even say "all proxies SHOULD support STUN". But no matter = what > requirements we come up with, they won't be met by currently deployed > proxies. if your currently deployed proxy is not outbound proxy as specified in the i-d, you don't list it as such. it is a regular proxy and can do whatever is specified in rfc3261. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 12:27:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWfb-0007j5-Uz; Thu, 06 Jul 2006 12:25:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWfa-0007j0-R6 for sip@ietf.org; Thu, 06 Jul 2006 12:25:38 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyWfZ-000374-Gl for sip@ietf.org; Thu, 06 Jul 2006 12:25:38 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k66GPata025710; Thu, 6 Jul 2006 11:25:36 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ9TWZX>; Thu, 6 Jul 2006 17:25:35 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369D4C7@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Miguel Garcia Subject: RE: [Sip] A thought on progressing outbound Date: Thu, 6 Jul 2006 17:25:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Firstly I was not necessarily targetting your comments in particular, but lets try and address your issue in terms of some simple tests: 1) what is currently in the draft fulfils the current requirements 2) what is currently in the draft does not appear to be technically wrong 3) we apparently do not need to decide between two alternative technical solutions to a requirement therefore you have a use case that is different from that of the editors, and ideally we need to reflect the difference between those two use cases either: - by clearly stating a need for flexibility to allow those two use cases in the requirements - or detailing the use cases that need to be supported. (assuming that these use cases are considered to be valid) The first of these is probably correct in this case. regards Keith > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: 06 July 2006 12:47 > To: Drage, Keith (Keith) > Cc: sip@ietf.org > Subject: Re: [Sip] A thought on progressing outbound > > > I don't have any problem with the current list of requirements in > Section 12. The problem is that text in the draft seems to go beyond > these requirements and impose a certain mandatory redundancy > scheme, to > which I strongly disagree as a "mandatory" feature. > > /Miguel > > Drage, Keith (Keith) wrote: > > (As WG chair) > > > > Having looked at some of the comments on outbound being > addressed to the list in the last few days, it occurs to me > that at least of you have fundamental requirements that > impact the solution and these requirements themselves need to > be discussed. > > > > Hidden in the current draft you will find section 12 > labelled "requirements". This is a somewhat thin section at > the moment (not necessarily a bad thing). > > > > Can you all please review this section, and identify > whether these requirements encompass all the requirements > that you wish to have met in outbound, and then try to > motivate what you think is missing. > > > > And as always "send text". > > > > regards > > > > Keith > > > > Keith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 12:42:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWu8-0005to-37; Thu, 06 Jul 2006 12:40:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWu7-0005tj-1F for sip@ietf.org; Thu, 06 Jul 2006 12:40:39 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyWu5-0004Bf-Gs for sip@ietf.org; Thu, 06 Jul 2006 12:40:39 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C08F68F4; Thu, 6 Jul 2006 18:40:36 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 18:40:36 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 18:40:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] A thought on progressing outbound Date: Thu, 6 Jul 2006 18:40:35 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5940294EB49@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A thought on progressing outbound Thread-Index: AcahGNaixX7k3QP5SuG/IduOm6XjewAAQ1T+ References: <475FF955A05DD411980D00508B6D5FB01369D4C7@en0033exch001u.uk.lucent.com> From: "Christer Holmberg \(JO/LMF\)" To: "Drage, Keith \(Keith\)" , "Miguel Garcia" X-OriginalArrivalTime: 06 Jul 2006 16:40:36.0241 (UTC) FILETIME=[E8222010:01C6A11A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, =20 In order to progress the work, and avoid discussions later, I think we = also need to make clear which requirements are related to the STUN = keep-alive mechanism, but not the rest of outbound, and which = requirements have nothing to do with the STUN keep-alive mechanism. =20 Regards, =20 Christer ________________________________ From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Thu 06/07/2006 18:25 To: Miguel Garcia Cc: sip@ietf.org Subject: RE: [Sip] A thought on progressing outbound Firstly I was not necessarily targetting your comments in particular, = but lets try and address your issue in terms of some simple tests: 1) what is currently in the draft fulfils the current requirements 2) what is currently in the draft does not appear to be technically = wrong 3) we apparently do not need to decide between two alternative = technical solutions to a requirement therefore you have a use case that is different from that of the = editors, and ideally we need to reflect the difference between those two = use cases either: - by clearly stating a need for flexibility to allow those two use = cases in the requirements - or detailing the use cases that need to be supported. (assuming that these use cases are considered to be valid) The first of these is probably correct in this case. regards Keith > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: 06 July 2006 12:47 > To: Drage, Keith (Keith) > Cc: sip@ietf.org > Subject: Re: [Sip] A thought on progressing outbound > > > I don't have any problem with the current list of requirements in > Section 12. The problem is that text in the draft seems to go beyond > these requirements and impose a certain mandatory redundancy > scheme, to > which I strongly disagree as a "mandatory" feature. > > /Miguel > > Drage, Keith (Keith) wrote: > > (As WG chair) > > > > Having looked at some of the comments on outbound being > addressed to the list in the last few days, it occurs to me > that at least of you have fundamental requirements that > impact the solution and these requirements themselves need to > be discussed. > > > > Hidden in the current draft you will find section 12 > labelled "requirements". This is a somewhat thin section at > the moment (not necessarily a bad thing). > > > > Can you all please review this section, and identify > whether these requirements encompass all the requirements > that you wish to have met in outbound, and then try to > motivate what you think is missing. > > > > And as always "send text". > > > > regards > > > > Keith > > > > Keith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 13:11:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXMG-0002Ni-8L; Thu, 06 Jul 2006 13:09:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXME-0002Nd-O4 for sip@ietf.org; Thu, 06 Jul 2006 13:09:42 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXMD-0005f3-By for sip@ietf.org; Thu, 06 Jul 2006 13:09:42 -0400 Received: (qmail 28701 invoked by uid 0); 6 Jul 2006 17:09:38 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 6 Jul 2006 17:09:38 -0000 Message-ID: <005701c6a11e$f3b69d80$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com><553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com><003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> <005c01c6a00c$47763a20$31713b51@BEMBUSTER> Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Thu, 6 Jul 2006 19:09:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, Juha Heinanen , dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan, > Jeroen, > > I'd like to address this one point. My recollection from Dallas is that > we had a very strong consensus that the existence of keepalive=stun was > sufficient to send STUN messages. > > Based on this, I think we need to make it a requirement of the > configuration mechanism that you can depend on its result to have > accurate keepalive information. > No, you cannot shift it off like that. Outbound is introducing binary STUN messages that could potentially harm existing systems, so outbound is responsible for providing reasonable safeguards. If it were an "ordinary" new SIP feature, then standard RFC3261 safeguards would provide sufficient protection. But STUN is different The problem with a requirement like you propose here is twofold: 1) it is too soft, in the sense that you cannot test for it 2) Some configuration mechanisms (like manual configuration) simply cannot meet this requirement Again, what is the reason that we should not include a mechanism for this? Do you feel it would make the draft too complex? Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 13:51:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXyW-0001Gk-JW; Thu, 06 Jul 2006 13:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXyV-0001GP-3B for sip@ietf.org; Thu, 06 Jul 2006 13:49:15 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXyT-0008Sd-Qk for sip@ietf.org; Thu, 06 Jul 2006 13:49:15 -0400 Received: from [172.17.2.251] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k66Hlu8Y000560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Jul 2006 12:47:57 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44AD4CBD.9030903@nostrum.com> Date: Thu, 06 Jul 2006 12:47:41 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: SIP WG Subject: Re: [Sip] Outbound Comment: q-value References: <44AC9C9F.1000701@nostrum.com> <17580.44383.443990.716678@rautu.tutpro.com> In-Reply-To: <17580.44383.443990.716678@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Adam Roach writes: > > > To handle this situation, it might make sense to put stuff in 6.2 > > that basically says that, for contacts with matching instance-ids, > > the proxy MUST NOT try a contact until all contacts at a higher > > q-value have been tried first. (I could go along with a weaker > > strength, but I really do think a prescriptive approach is the only > > thing that allows the clients to handle the situation I describe > > above in a manner that is predictable to the users). > > i you suggesting that proxies consult each other about the q-value UA > used when registering with each proxy before forwarding a request to the > UA? if so, your suggesting makes no sense. > > -- juha > I have no idea what you're saying here. Let's try getting some common context. Open the outbound document. Go to section 6.2. You'll notice that it talks about the rules that proxy/registrars use to populate the target set. This is the section to which my comment applies. In particular, there are two new rules placed on proxy/registrars that implement outbound, specified in a bullet list. I'm suggesting a third bullet that reads something like: * If multiple bindings have the same instance-id, the proxy MUST NOT use a binding until all bindings of greater q-value have been tried. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 13:51:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXz8-00021T-2N; Thu, 06 Jul 2006 13:49:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXz6-00021O-FS for sip@ietf.org; Thu, 06 Jul 2006 13:49:52 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXz4-00007n-Tq for sip@ietf.org; Thu, 06 Jul 2006 13:49:52 -0400 Received: from [172.17.2.252] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k66HmYCg000589 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 6 Jul 2006 12:48:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <532B18E13CF9E64380EF5FDDE265E071166B24@blr-m2-msg.wipro.com> References: <532B18E13CF9E64380EF5FDDE265E071166B24@blr-m2-msg.wipro.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <997D9DBB-F126-40EC-B86F-1E3BB8CF91F3@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Update to fork-loop-fix submitted Date: Thu, 6 Jul 2006 12:48:34 -0500 To: "" X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 5, 2006, at 11:43 PM, wrote: > > It is always better to reduce the computation in the path of normal > success case and introduce it in the path of a rarer scenario. I think > it will be a fair assumption to make that Spirals will be rarer > than the > non-spiraling scenarios. But in this case, you are reducing computation (perhaps trivially) at the cost of increased network traffic. > > In terms of increasing logic, the increase in logic would be very > small > if it all any. > It would be a trade-off that should be left to the implementer to take > if he considers that hash computation is expensive on his platform. If > this id recommends the computation of hash at the MUST strength in the > first pass of the SIP request, an implementer would not have that > freedom to make that trade-off.. > > Regards, > Ravi. > > -- > > Ravishankar. G. Shiroor > Wipro Technologies, Bangalore. > > ravishankar.shiroor@wipro.com > -- > > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: Wednesday, July 05, 2006 8:21 PM >> To: RaviShankar Shiroor (WT01 - Product Engineering Solutions) >> Cc: sip@ietf.org >> Subject: Re: [Sip] Update to fork-loop-fix submitted >> >> I understand the suggestion. You are trading off letting the >> request through a loop one extra cycle for some lower amount >> of processing the first time the request went through the >> proxy. If you believe that spirals are relatively rare >> things, this change would result in proxies very rarely >> having to build the loop/spiral differentiation hash. >> >> But as Jonathan points out, it's not clear that the hash >> computation is expensive enough to warrant this extra logic >> and the extra network traffic it would allow. I expect that >> the hash calculation expense is small compared to the >> parse/search/compare operations for "Proxy checks to see if >> its address is there in the via already". >> >> RjS >> >> On Jul 3, 2006, at 5:39 AM, >> wrote: >> >>> >>> Hi Robert, >>> >>> I had suggested one more alternative >>> >>> (http://www1.ietf.org/mail-archive/web/sip/current/msg14359.html ) >>> >>> Quoted from my previous mail: >>> >>> >>> I was thinking how to reduce the impact of overhead for >> calculating >>> the >>> digest. >>> >>> If it is suggested as follows, I think it will reduce the >> overhead on >>> normal scenarios: >>> >>> Proxy checks to see if its address is there in the via already. >>> If it is not there, it proceeds normally without calculating the >>> digest >>> and inserting Via to the outgoing request without the digest. >>> If it is there, then it is possible that the request is looping. So, >>> this time around, it calculates a digests and inserts and sends it >>> along. >>> If it is looping, the request will definitely come in >> again, which can >>> be rejected. >>> This way the impact of calculating the digest is required (reduced >>> to a >>> smaller percent of the sessions) only when the proxy is >> suspicious the >>> request might be looping. >>> Of course this results in the scenarios mentioned in the id to be >>> successful in completing the first loop, but the second loop will be >>> detected and arrested. I think this can be applicable to >> general loop >>> detection, and not just fork loop fixes. >>> >>> >>> Regards, >>> Ravi. >>> >>> -- >>> >>> Ravishankar. G. Shiroor >>> Wipro Technologies, Bangalore. >>> >>> ravishankar.shiroor@wipro.com >>> -- >>> >>> >>>> -----Original Message----- >>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>>> Sent: Sunday, June 25, 2006 8:22 PM >>>> To: IETF SIP List >>>> Subject: [Sip] Update to fork-loop-fix submitted >>>> >>>> Until it appears in the repository, see: >>>> >> http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-02.txt >>>> >>>> This was a moderately heavy touch - based on list feedback, >>>> I've moved and updated the sections covering the >>>> loopdetection algorithm in from 3261. In the process of >>>> writing the clarifying text, I discovered several places that >>>> need clarification. They are listed as Open Issues in the >>>> draft. Basically there are fields that I can't recall or >>>> reconstruct how they would be useful in the part of the hash >>>> used for loop-detection or spiral differentiation. If anyone >>>> can remember why they need to be included, send a note to the >>>> list and we'll capture that in the draft. >>>> >>>> Please review the updated loop-detection text very carefully. >>>> >>>> Here's the changelog from the draft: >>>> >>>> Integrated several editorial fixes suggested by >>>> Jonathan Rosenberg >>>> >>>> Noted that the reduction of the attack to a single >>>> registration >>>> against a single URI as documented in previous versions, >>>> is, in >>>> fact, going to be effective against implementations >>>> conforming to >>>> the standards before this repair. >>>> >>>> Re-incorporated motivation from the original >>>> maxforwards-problem >>>> draft into the security considerations section based >>>> on feedback >>>> from Cullen Jennings >>>> >>>> Introduced replacement text for the loop detection algorithm >>>> description in RFC 3261, fixing the bug 648 (the >>>> topmost Via value >>>> must not be included in the second part) and clarifying the >>>> algorithm. Removed several other fields suggested >> by 3261 and >>>> placed open issues around their presence. >>>> >>>> Added a Notes to Implementors section capturing the >>>> "common way" >>>> text and pointing to the interoperability issues that have >>>> been >>>> observed with loop detection at previous SIPits >>>> >>>> >>>> Thanks, >>>> >>>> RjS >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >>> >>> >>> The information contained in this electronic message and any >>> attachments to this message are intended for the exclusive use of >>> the addressee(s) and may contain proprietary, confidential or >>> privileged information. If you are not the intended recipient, you >>> should not disseminate, distribute or copy this e-mail. Please >>> notify the sender immediately and destroy all copies of this >>> message and any attachments. >>> >>> WARNING: Computer viruses can be transmitted via email. The >>> recipient should check this email and any attachments for the >>> presence of viruses. The company accepts no liability for any >>> damage caused by any virus transmitted by this email. >>> >>> www.wipro.com >> >> > > > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of > the addressee(s) and may contain proprietary, confidential or > privileged information. If you are not the intended recipient, you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately and destroy all copies of this > message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The > recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any > damage caused by any virus transmitted by this email. > > www.wipro.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 14:00:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyY86-0004XY-KP; Thu, 06 Jul 2006 13:59:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyY85-0004XT-6x for sip@ietf.org; Thu, 06 Jul 2006 13:59:09 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyY83-0000WB-VD for sip@ietf.org; Thu, 06 Jul 2006 13:59:09 -0400 Received: from hkaplan [10.0.200.167] by acmepacket.com with ESMTP (SMTPD-9.03) id AF4B0248; Thu, 06 Jul 2006 13:58:35 -0400 From: "Hadriel Kaplan" To: "'Juha Heinanen'" Subject: RE: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Thu, 6 Jul 2006 13:58:34 -0400 Message-ID: <039e01c6a125$ce062950$a7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <17580.7810.687558.525897@rautu.tutpro.com> Thread-Index: AcagcHst2v4PvA41QZagV1eCm7U40QAsmxHQ X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Wednesday, July 05, 2006 4:18 PM > To: Jeroen van Bemmel > Cc: Miguel Garcia; sip@ietf.org; Cullen Jennings; Rohan Mahy > Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 > > Jeroen van Bemmel writes: > > > For flows beyond the maximum the network "suffers" (just like the > registrar > > determines the expiration time). But by imposing a minimum number of > flows, > > the UA potentially "suffers" (spending scarce resources such as battery > > power). And anyway, when the UA sets up less flows the consequences are > for > > its user. > > in the above situation, assuming that network has two proxies, if UA > decides to establish only one flow instead of two, then the likely hood > is 50% that incoming call to the UA cannot be establishes. it thus > makes no sense for the UA to violate network policy on number of flows. That doesn't make any sense to me. If a UA only establishes 1 flow, then the registrar only has one registered contact/flow, which points through 1 edge proxy if there is one, and 100% of the incoming calls to the UA will go over that 1 flow path. Obviously if the flow fails, there will be some amount of service-outage to the UA until it detects the loss and connects through an alternate path, but hopefully that's not happening 50% of the time. :) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 14:08:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYFY-0005Fr-6i; Thu, 06 Jul 2006 14:06:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYFW-0005Fm-Gc for sip@ietf.org; Thu, 06 Jul 2006 14:06:50 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyYFV-0000nr-4Q for sip@ietf.org; Thu, 06 Jul 2006 14:06:50 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2006 14:06:49 -0400 X-IronPort-AV: i="4.06,214,1149480000"; d="scan'208"; a="91886112:sNHT31903180" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k66I6mXE029900; Thu, 6 Jul 2006 14:06:48 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k66I6lQw028684; Thu, 6 Jul 2006 14:06:47 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 14:06:47 -0400 Received: from [161.44.55.222] ([161.44.55.222]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 14:06:47 -0400 Message-ID: <44AD5137.4050601@cisco.com> Date: Thu, 06 Jul 2006 14:06:47 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Ready for WGLC on Outbound? References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> In-Reply-To: <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2006 18:06:47.0311 (UTC) FILETIME=[F254C9F0:01C6A126] DKIM-Signature: a=rsa-sha1; q=dns; l=2611; t=1152209208; x=1153073208; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Ready=20for=20WGLC=20on=20Outbound? |To:Jeroen=20van=20Bemmel=20; X=v=3Dcisco.com=3B=20h=3D+vIhPlqdG6kJmZ9oKSrzl3HpLHY=3D; b=JZOFclRRN1JKJIpALkM6qe7YQ1L4lerfdltEa5ChRU5zNBOTTfhqKJtFsu/zllYwokk0sFkn Un2DiWHxwe/cdQZ72auPNqUzABRY7fN75HWZQSmlxMsrmsD1bukbqBvq; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Cullen Jennings , sip@ietf.org, dean.willis@softarmor.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Jeroen van Bemmel wrote: > Cullen, > > The point is that these are really 2 separate issues: > 1. Discovering the set of outbound proxy URIs (with keepalive=stun > parameters in them) > 2. Confirming that a given proxy in the set actually supports outbound > (ie validating the keepalive=stun information) > > Of these 2 options, (1) is indeed a separable problem. (2) - to me - is > not, for me outbound is not acceptable without something to address (2). > It really should say "the UAC MUST NOT use STUN until { mechanism for > (2) says its supported }" I personally think that the presence of the keepalive=stun attribute in the URI is sufficient of a "confirmation". The examples you and others have presented for why this is needed are (1) misconfiguration (someone gives a URI to the client which is incorrect in that it contains this flag when it shouldn't), (2) malicious users, (3) constructed URIs. On (2), let me point out that an attacker that can modify DNS or modify SIP messages (or whatever is used for the discovery function) can launch far more effective attacks than just adding keepalive=stun in the hopes that it causes a low-quality proxy to crash. On (1), misconfugration could potentially produce all kinds of things that would cause a client to send things to the server that might make it crash, including non-SIP URI, URI with invalid header parameters, etc. I don't see keepalive=stun as special. On (3), this is definitely a possibility. However I think the best way to mitigate is to say 'don't do that'. SIP-outbound can have some words which warn implementations that they MUST NOT insert this parameter into URI that they construct from a domain name. Finally, let me say that if you have a proxy that crashes on receipt of binary messages on its sip port, you are in for real trouble. I think a far better solution is for proxy vendors to fix their proxies, rather than for us to bend over backwards to design new mechanisms that help protect such fragile servers from ever seeing these messages. No matter what we put in our specs, attackers can still send binary messages that will result in the same result you are trying to prevent. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 14:30:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYaT-0007QO-Aq; Thu, 06 Jul 2006 14:28:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYaS-0007QJ-25 for sip@ietf.org; Thu, 06 Jul 2006 14:28:28 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyYaM-0002I8-Fx for sip@ietf.org; Thu, 06 Jul 2006 14:28:28 -0400 Received: from [72.1.129.110] (dsl001-129-110.dfw1.dsl.speakeasy.net [72.1.129.110]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k66IPvj4085115 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 6 Jul 2006 13:26:59 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <005701c6a11e$f3b69d80$31713b51@BEMBUSTER> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com><553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com><003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> <005c01c6a00c$47763a20$31713b51@BEMBUSTER> <005701c6a11e$f3b69d80$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85C045EB-B410-44D2-A028-51C234431067@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Thu, 6 Jul 2006 13:26:56 -0500 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, Juha Heinanen , dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 6, 2006, at 12:09 PM, Jeroen van Bemmel wrote: > Rohan, > >> Jeroen, >> >> I'd like to address this one point. My recollection from Dallas >> is that we had a very strong consensus that the existence of >> keepalive=stun was sufficient to send STUN messages. >> >> Based on this, I think we need to make it a requirement of the >> configuration mechanism that you can depend on its result to have >> accurate keepalive information. >> > > No, you cannot shift it off like that. Outbound is introducing > binary STUN messages that could potentially harm existing systems, > so outbound is responsible for providing reasonable safeguards. If > it were an "ordinary" new SIP feature, then standard RFC3261 > safeguards would provide sufficient protection. But STUN is different I've been watching this train of reasoning for a while now, and am not sure I buy it. Do we really expect SIP devices to melt down if they get stun and don't expect it? If so, they are big targets for DoS attacks. > > The problem with a requirement like you propose here is twofold: > 1) it is too soft, in the sense that you cannot test for it > 2) Some configuration mechanisms (like manual configuration) simply > cannot meet this requirement > > Again, what is the reason that we should not include a mechanism > for this? Do you feel it would make the draft too complex? > > Regards, > > Jeroen > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 14:32:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYcH-00087k-9k; Thu, 06 Jul 2006 14:30:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYcF-00087f-8i for sip@ietf.org; Thu, 06 Jul 2006 14:30:19 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyYcC-0002Oa-VB for sip@ietf.org; Thu, 06 Jul 2006 14:30:19 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2006 14:30:17 -0400 X-IronPort-AV: i="4.06,214,1149480000"; d="scan'208"; a="91889183:sNHT31684200" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k66IUGH2023608; Thu, 6 Jul 2006 14:30:16 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k66IUGoB008552; Thu, 6 Jul 2006 14:30:16 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 14:30:16 -0400 Received: from [161.44.55.222] ([161.44.55.222]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 14:30:16 -0400 Message-ID: <44AD56B7.9020905@cisco.com> Date: Thu, 06 Jul 2006 14:30:15 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> In-Reply-To: <44AC0861.1020604@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2006 18:30:16.0219 (UTC) FILETIME=[3A1B16B0:01C6A12A] DKIM-Signature: a=rsa-sha1; q=dns; l=1599; t=1152210616; x=1153074616; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Re=3A=20A=20coment=20to=20draft-ietf-sip-outbound-04 |To:Miguel=20Garcia=20; X=v=3Dcisco.com=3B=20h=3Dmw3ZzSPBxV65n7c09ANJSezKJZE=3D; b=js9MUokcEhM89TtVN23UXVwpHw+pIDmvYSqHmyU7fDrYuTpE8c99mNVbttbK2wG7xm1Lfqh/ yfhucwD0N9yMojuxX+iVKf1jr3UzZBQgOYbBkCmtfVkKLK2n3aQ9NFce; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Cullen Jennings , sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Miguel Garcia wrote: > Cullen Jennings wrote: > >> >> >> I expect you are right in that this MUST is too strong here but I >> think there is an argument for SHOULD. The problem is that if the >> domain assume the UA is doing two flows and the UA does one, things >> are broken. >> > > I would like to understand which part of the outbound mechanism is > broken if the domain assumes the UE will do two flows, but the UA does > one flow. Yes, it isn't reliable, but the mechanism works nicely... or not? > > Then... why can't a domain indicate just one outbound URI? At the moment > the draft has an artificial lower limit for all the domains to provide > two URIs and impose a reliability that might not be required/needed. Thats not my read. The draft says that a client has to support at least 2 outbound URI, and that it MUST send a REGISTER for each. However, that doesn't mean a domain *has* to provide two; it can also provide one. A domain would only provide one if it knows that it doesn't need two for purposes of reliability, or if it doesn't require reliability of service. As such, I support the current text which says that a client MUST send a REGISTER to each outbound URI. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 15:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZCg-0000rM-AS; Thu, 06 Jul 2006 15:07:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZCe-0000rF-SY for sip@ietf.org; Thu, 06 Jul 2006 15:07:56 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZCd-0005Ar-Fs for sip@ietf.org; Thu, 06 Jul 2006 15:07:56 -0400 Received: from hkaplan [10.0.200.167] by acmepacket.com with ESMTP (SMTPD-9.03) id AF820184; Thu, 06 Jul 2006 15:07:46 -0400 From: "Hadriel Kaplan" To: "'Adam Roach'" , "'Cullen Jennings'" Subject: RE: [Sip] Outbound Comment: binding key Date: Thu, 6 Jul 2006 15:07:48 -0400 Message-ID: <03a001c6a12f$7850bd90$a7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44AC9B93.4000103@nostrum.com> Thread-Index: AcaguvmvR6KoNz9BSEiZ8cGMwlV/ogAcglWQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: 'SIP WG' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My interpretation was the opposite - if a Register comes in with the same {instance-id,reg-id} then it should indeed replace/overwrite the previous binding of the same tuple. I know there are several sections in the draft which imply otherwise, but I don't understand why. There is no real value I can see to keeping a binding for an old flow of the same reg-id, since by definition the UA would only "re-use" a reg-id if the old flow failed (or even if it didn't think it had failed, but something rebooted and changed the flow). I can see no realistic way in which an old flow of the same {instance-id,reg-id} would succeed in reaching the UA. Am I missing something? -hadriel p.s. it's theoretically possible, if a sip-udp UA rebooted and resolved a new proxy address and sent a register to it with the same reg-id, that it may still be possible to reach the UA through the old "flow" for a time. But is that a realistic case worth caring about? > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, July 06, 2006 1:12 AM > To: Cullen Jennings > Cc: SIP WG > Subject: [Sip] Outbound Comment: binding key > > From section 6.1: > > When a reg-id header parameter is present in a Contact header field > value in a REGISTER request, the corresponding binding is between an > AOR and the combination of instance-id and reg-id. > > I don't think this is quite correct. This statement appears to be > asserting that {instance-id,reg-id} is a unique key to a binding > associated with an AOR. This would, in turn, imply that any successful > registration attempt with an {instance-id,reg-id} that matches an > existing binding would overwrite the existing record. > > I don't think that is what's intended, since section 6.2 contains the > following text: > > o If two bindings have the same instance-id and reg-id, the proxy > SHOULD prefer the contact that was most recently updated. > > If the binding is only to {instance-id,reg-id}, then that text is > nonsensical: you can't have two identical bindings to the same AOR. > > I suspect that the text in 6.1 should actually read something more like: > > When a reg-id header parameter is present in a Contact header field > value in a REGISTER request, the corresponding binding is between an > AOR and the combination of instance-id, reg-id, and network flow. > > /a > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 15:20:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZNI-00056Y-Cp; Thu, 06 Jul 2006 15:18:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZNG-00056Q-Qc for sip@ietf.org; Thu, 06 Jul 2006 15:18:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZNE-0006wp-JD for sip@ietf.org; Thu, 06 Jul 2006 15:18:54 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2006 12:18:52 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,214,1149490800"; d="scan'208"; a="31358374:sNHT24479048" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k66JIq0d013079; Thu, 6 Jul 2006 15:18:52 -0400 Received: from [161.44.55.183] (dhcp-161-44-55-183.cisco.com [161.44.55.183]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k66JIpoB024337; Thu, 6 Jul 2006 15:18:51 -0400 (EDT) Message-ID: <44AD621A.301@cisco.com> Date: Thu, 06 Jul 2006 15:18:50 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Ready for WGLC on Outbound? References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <44AD5137.4050601@cisco.com> In-Reply-To: <44AD5137.4050601@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1073; t=1152213532; x=1153077532; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:Anders=20Kristensen=20 |Subject:Re=3A=20[Sip]=20Ready=20for=20WGLC=20on=20Outbound? |To:Jonathan=20Rosenberg=20; X=v=3Dcisco.com=3B=20h=3D2zWb2Jtlp6+f/U4r3ThsJggUbeg=3D; b=NZx1OlNED4X5EMuwrV818CMvqOs4epzUWH5fm6G1a+ycLfxewj/69zLhdjdaOTTBFvKYvNM/ djKzqe7CYKlHMqaka2EUtqe8sB0pbkdgLnGB8CMsO7kLClnhUOp6rVNt; Authentication-Results: rtp-dkim-1.cisco.com; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Cullen Jennings , sip@ietf.org, dean.willis@softarmor.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > Finally, let me say that if you have a proxy that crashes on receipt of > binary messages on its sip port, you are in for real trouble. I think a > far better solution is for proxy vendors to fix their proxies, rather > than for us to bend over backwards to design new mechanisms that help > protect such fragile servers from ever seeing these messages. No matter > what we put in our specs, attackers can still send binary messages that > will result in the same result you are trying to prevent. I would agree with this in the case of UDP or in other cases where the transport does the framing. It seems that for stream based transports unrecognized binary data could mess up framing. Proxies could try to recover but I don't know if it's reasonable to expect proxies to keep connections open for an extended period of time when all they see is a some garbage every 30 seconds or so. It's not necessarily that the proxy crashes but that it gives up on a particular connection at some point. Thanks, Anders _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 15:48:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZoF-0007Cr-OF; Thu, 06 Jul 2006 15:46:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZoE-0007Cm-AM for sip@ietf.org; Thu, 06 Jul 2006 15:46:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZoB-0001a8-Ik for sip@ietf.org; Thu, 06 Jul 2006 15:46:46 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6802F8E0004; Thu, 6 Jul 2006 10:05:29 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:05:28 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:05:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER Date: Thu, 6 Jul 2006 10:02:35 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594117D3E@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER Thread-Index: AcagPvc6cpDkmRtJTC6XhHkPVqrySAAk5MlN References: <8B1D53AEF7B03449A6D3771B3B7F850F027D0DEB@esebe103.NOE.Nokia.com> <96653400-8B1F-4806-81B1-6CA11CCD4B67@cisco.com> From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , X-OriginalArrivalTime: 06 Jul 2006 08:05:27.0829 (UTC) FILETIME=[F148BC50:01C6A0D2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip@ietf.org, rohan@ekabal.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, =20 Even if we would be able to provide this information in DNS, I still = think it would be useful to be able to provide it in the REGISTER = response. =20 The number of flows the network wants the user(s) to register may be = much more "dynamic" than the DNS update. =20 In theory the number of flows could even be different for different = users. =20 Regards, =20 Christer =20 =20 ________________________________ From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Wed 05/07/2006 16:26 To: Cc: rohan@ekabal.com; dean.willis@softarmor.com; Christer Holmberg = (JO/LMF); sip@ietf.org Subject: Re: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER On Jun 29, 2006, at 10:55 PM, =20 wrote: > >> I can think of a number of ways to make this work where >> the intended semantics are entirely embedded in DNS. > > If you have any ideas like that, could you please pass them > to me since I am working on a related I-D where no such ideas > have been introduced. I would be happy to receive those to be > able to check if they work with the rest of the DNS scheme > currently proposed. If yes, I could take them into my draft. Well long and short of it is, if you are embedding the config=20 information in DNS, just put it in DNS - look at how much information=20 a ENUM or SRV record provides. I'm not sure if it is a good idea to=20 do this or not but I'm just pointing out ways you might consider. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 16:40:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyac4-0002n6-1K; Thu, 06 Jul 2006 16:38:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyac2-0002mE-5p for sip@ietf.org; Thu, 06 Jul 2006 16:38:14 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyac0-0008Ba-PG for sip@ietf.org; Thu, 06 Jul 2006 16:38:14 -0400 Received: (qmail 18413 invoked by uid 0); 6 Jul 2006 20:38:10 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 6 Jul 2006 20:38:10 -0000 Message-ID: <009b01c6a13c$15b2b1e0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Anders Kristensen" , "Jonathan Rosenberg" References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <44AD5137.4050601@cisco.com> <44AD621A.301@cisco.com> Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Thu, 6 Jul 2006 22:38:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Cullen Jennings , sip@ietf.org, rohan@ekabal.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Jonathan Rosenberg wrote: >> Finally, let me say that if you have a proxy that crashes on receipt of >> binary messages on its sip port, you are in for real trouble. I think a >> far better solution is for proxy vendors to fix their proxies, rather >> than for us to bend over backwards to design new mechanisms that help >> protect such fragile servers from ever seeing these messages. No matter >> what we put in our specs, attackers can still send binary messages that >> will result in the same result you are trying to prevent. > > I would agree with this in the case of UDP or in other cases where the > transport does the framing. It seems that for stream based transports > unrecognized binary data could mess up framing. Proxies could try to > recover but I don't know if it's reasonable to expect proxies to keep > connections open for an extended period of time when all they see is a > some garbage every 30 seconds or so. It's not necessarily that the proxy > crashes but that it gives up on a particular connection at some point. > > Thanks, > Anders Yes, exactly! And for TLS a proxy might interpret it as an encryption failure, and trigger some anomaly detection system, and then blacklist the client. All of this can be prevented through a simple measure: have the proxy insert some flag. As mechanisms go, this to me hardly feels like bending over backwards. None of this will help against malicious attackers, but it will work for UAs that are simply unaware. And it will also make debugging easier Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 17:14:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyb9n-0006Eo-TF; Thu, 06 Jul 2006 17:13:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyb9m-0006Ee-Ep for sip@ietf.org; Thu, 06 Jul 2006 17:13:06 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyb9l-0002sc-20 for sip@ietf.org; Thu, 06 Jul 2006 17:13:06 -0400 Received: (qmail 13561 invoked by uid 0); 6 Jul 2006 21:12:58 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 6 Jul 2006 21:12:58 -0000 Message-ID: <00d801c6a140$f4e7f920$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <44AD5137.4050601@cisco.com> <44AD621A.301@cisco.com> <009b01c6a13c$15b2b1e0$31713b51@BEMBUSTER> <44AD791A.5070704@cisco.com> Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Thu, 6 Jul 2006 23:12:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Cullen Jennings , sip@ietf.org, rohan@ekabal.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [ snap ] > Jonathan wrote > > I'm not objecting to the concept of this check. I just think its not > necessary, something that might be optional at best. As such, if folks > decide they want something, it can go in another draft. I dont think we > need to burden sip-outbound with this. > The trouble is, once outbound is "out" any mechanism defined in a separate draft won't work as good. Because then there will be clients that simply ignore the flag. We either MUST now, or MAY never fix it. For the benefit of those amongst us with live systems, I am including a simple Java test program below so you can test the effect of a STUN binding request on your unsuspecting proxy (currently UDP only, trivial to adapt) Regards, Jeroen import java.net.DatagramPacket; import java.net.DatagramSocket; import java.net.InetAddress; import java.net.InetSocketAddress; import java.net.SocketException; import java.net.UnknownHostException; /** * Tests what happens when a client sends a STUN Binding request over UDP * @author Jeroen */ public final class STUNClient { /** * @param args * @throws UnknownHostException * @throws SocketException */ public static void main(String[] args) throws Exception { byte [] bindingRequest = new byte[ 20 ]; bindingRequest[0] = 0x00; bindingRequest[1] = 0x01; // type: 0x0001 bindingRequest[2] = 0x00; bindingRequest[3] = 0x00; // length: 0 (excl header) // 4..19: random 128-bit transaction id, lets take 0 DatagramPacket p = new DatagramPacket( bindingRequest, bindingRequest.length, new InetSocketAddress(InetAddress.getLocalHost(),5060) ); DatagramSocket s = new DatagramSocket(); s.send( p ); s.receive( p ); System.out.println( p.getSocketAddress() ); } } _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 17:14:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyb9v-0006GF-N9; Thu, 06 Jul 2006 17:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyb9v-0006G6-70 for sip@ietf.org; Thu, 06 Jul 2006 17:13:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyYc5-0002Ne-SE for sip@ietf.org; Thu, 06 Jul 2006 14:30:09 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyYKz-0001kU-LL for sip@ietf.org; Thu, 06 Jul 2006 14:12:32 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 453B1CE0021; Thu, 6 Jul 2006 10:47:08 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:47:06 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 10:47:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound Comment: negotiation and edge proxies Date: Thu, 6 Jul 2006 10:45:16 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594117D43@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Comment: negotiation and edge proxies Thread-Index: AcagwDRaYep068oRSri31m/qqojt4AAGEzIp References: <44ACA454.3030800@nostrum.com> From: "Christer Holmberg \(JO/LMF\)" To: "Adam Roach" , "Cullen Jennings" , "SIP WG" X-OriginalArrivalTime: 06 Jul 2006 08:47:06.0954 (UTC) FILETIME=[C2E0F2A0:01C6A0D8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi Adam, =20 >However, negotiation of the outbound mechanism is between the client = and the registrar.=20 =20 Negotiation of the STUN for keep-alive mechanism is between the client = and the edge proxy. =20 And, again, I hope we can agree on the fact that the STUN for keep-alive = is a stand-alone function, so the "outbound" option tag may not be = present at all. =20 Regards, =20 Christer =20 =20 ________________________________ From: Adam Roach [mailto:adam@nostrum.com] Sent: Thu 06/07/2006 07:49 To: Cullen Jennings; SIP WG Subject: [Sip] Outbound Comment: negotiation and edge proxies This one, I might just be confused about, but I combed the draft and can't figure out how it is supposed to work. Section 5 of the outbound document places a number of requirements on edge proxies that must be implemented for outbound to work. However, negotiation of the outbound mechanism is between the client and the registrar. An edge-proxy that doesn't understand outbound will blithely shuttle messages back and forth between the client while they signal support for the outbound mechanism. During registration, all a non-outbound edge-proxy will see and care about is "Supported: path," which makes it fat and happy. It won't care about the funky bits on the end of the Contact. It won't care about the "Supported: outbound" header field in the REGISTER response. And it won't do anything suspicious that might give the client or the registrar some idea that things are about to go quite wrong. The client and registrar have done the secret handshake, and are absolutely certain that outbound handling is alive and well. I think this can be fixed with a little more behavior around what edge-proxies that support this draft are required to do. Specifically: since section 5.1 already has some pretty strong normative language that requires edge-proxies to insert Path header fields with certain properties, it's a rather small leap to dictate that the form of the URIs in these Path header fields must include something that the registrar can use to verify outbound support. For example: When an Edge Proxy receives a registration request with a reg-id header parameter in the Contact header field, it MUST form a flow identifier token that is unique to this network flow. The Edge Proxy MUST insert this token into a URI referring to this proxy and place this URI into a Path header field as described in RFC 3327 [RFC3327]. The token MAY be placed in the userpart of the URI. The URI MUST include an ";outbound" parameter. With that in place, the registrar can now look at an inbound REGISTER request and (in addition to checking the Contact header field) look through the Path header fields to ensure that all of them contain URIs with ";outbound" parameters. If they don't, it can take evasive action (perhaps not returning the "Supported: outbound" header field in the response?) that prevents things from going wrong. /a ---- P.S. There is one corner case that this doesn't seem to cover: the situation in which the client has a locally provisioned default outbound proxy. This locally provisioned default outbound proxy won't use Path at all, but it will remain in the signaling for all requests from the client. I'm not certain how often this will become a problem, and working around it would require something similar to the Path indication I describe above, but on Via header fields. That feels like a really ugly hack, and I'm not sure it's worth the inelegance to handle cases that will be rare, if they exist at all. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 17:39:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybXS-0005IY-6M; Thu, 06 Jul 2006 17:37:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybXQ-0005IT-Qq for sip@ietf.org; Thu, 06 Jul 2006 17:37:32 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FybXP-0005Kd-Ek for sip@ietf.org; Thu, 06 Jul 2006 17:37:32 -0400 Received: from hkaplan [10.0.200.167] by acmepacket.com with ESMTP (SMTPD-9.03) id A29002B4; Thu, 06 Jul 2006 17:37:20 -0400 From: "Hadriel Kaplan" To: "'Jonathan Rosenberg'" Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Thu, 6 Jul 2006 17:37:12 -0400 Message-ID: <03ed01c6a144$5d3e9b70$a7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44AD5137.4050601@cisco.com> Thread-Index: AcahJv9CfxXIXQ3YSVKFEMFG9cY2ZAACQAvg X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think we all agree every device _should_ handle a STUN message on the same port just fine, and I assume vendors active in the IETF or going to SIPit would do just that. (whatever "handle fine" means to them) However the difference between a malicious attacker or benevolent tester doing it, and this draft, is this will be an IETF RFC from the sip WG specifying the "attack" as part of a legit SIP mechanism. (and it's not RFC 4475 :) Whereas this WG has added a Required header or some other check mechanism for virtually any other extension I can think of where the proxy/registrar is really required to support something, this one does not have such a mechanism. Why? And it's not the same as just a new option-tag or header - this is a backwards-compatibility breaker. There is no defined action for a 3261-compliant device to take when receiving such a binary message, is there? It cannot "reject" it with a sip response, cannot make the UA stop sending it, nor can the UA detect the proxy doesn't support it even if the UA wanted to check. The UA will detect a keepalive loss, and try "re-connecting" by re-registering and getting another keepalive loss, indefinitely (although at least with back-off timers). Meanwhile the operator of this 3261-compliant proxy just got a headache courtesy of the IETF. For each user who mistakenly checks some little check-box which says whatever the vendor thought it should say for a keepalive=stun semantics the operator must take action to correct - if they're lucky. If they're unlucky, and their proxy silently discards the stun, they'll wonder why some UAs can make/receive calls for ~30 seconds, then disappear, then come back, ad infinitum. And this is a bad kind of failure to detect/fix, because a reboot makes it "work" for a short time. -hadriel p.s. a STUN request should really be added to the next sipping-torture-rfc4475bis. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Thursday, July 06, 2006 2:07 PM > To: Jeroen van Bemmel > Cc: Cullen Jennings; sip@ietf.org; dean.willis@softarmor.com; > rohan@ekabal.com > Subject: Re: [Sip] Ready for WGLC on Outbound? > > inline. > > Jeroen van Bemmel wrote: > > > Cullen, > > > > The point is that these are really 2 separate issues: > > 1. Discovering the set of outbound proxy URIs (with keepalive=stun > > parameters in them) > > 2. Confirming that a given proxy in the set actually supports outbound > > (ie validating the keepalive=stun information) > > > > Of these 2 options, (1) is indeed a separable problem. (2) - to me - is > > not, for me outbound is not acceptable without something to address (2). > > It really should say "the UAC MUST NOT use STUN until { mechanism for > > (2) says its supported }" > > I personally think that the presence of the keepalive=stun attribute in > the URI is sufficient of a "confirmation". The examples you and others > have presented for why this is needed are (1) misconfiguration (someone > gives a URI to the client which is incorrect in that it contains this > flag when it shouldn't), (2) malicious users, (3) constructed URIs. On > (2), let me point out that an attacker that can modify DNS or modify SIP > messages (or whatever is used for the discovery function) can launch far > more effective attacks than just adding keepalive=stun in the hopes that > it causes a low-quality proxy to crash. > > On (1), misconfugration could potentially produce all kinds of things > that would cause a client to send things to the server that might make > it crash, including non-SIP URI, URI with invalid header parameters, > etc. I don't see keepalive=stun as special. > > On (3), this is definitely a possibility. However I think the best way > to mitigate is to say 'don't do that'. SIP-outbound can have some words > which warn implementations that they MUST NOT insert this parameter into > URI that they construct from a domain name. > > Finally, let me say that if you have a proxy that crashes on receipt of > binary messages on its sip port, you are in for real trouble. I think a > far better solution is for proxy vendors to fix their proxies, rather > than for us to bend over backwards to design new mechanisms that help > protect such fragile servers from ever seeing these messages. No matter > what we put in our specs, attackers can still send binary messages that > will result in the same result you are trying to prevent. > > Thanks, > Jonathan R. > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 17:39:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybXy-0005ph-88; Thu, 06 Jul 2006 17:38:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybXx-0005pU-9c for sip@ietf.org; Thu, 06 Jul 2006 17:38:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyaOL-0007We-DS for sip@ietf.org; Thu, 06 Jul 2006 16:24:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyaBW-0003aN-Ah for sip@ietf.org; Thu, 06 Jul 2006 16:10:54 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2006 13:10:50 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,214,1149490800"; d="scan'208"; a="31367401:sNHT24450416" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k66KAn24004547 for ; Thu, 6 Jul 2006 16:10:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k66KAnoB011487 for ; Thu, 6 Jul 2006 16:10:49 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 16:10:49 -0400 Received: from [161.44.55.141] ([161.44.55.141]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 16:10:49 -0400 Message-ID: <44AD6E48.2030302@cisco.com> Date: Thu, 06 Jul 2006 16:10:48 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2006 20:10:49.0141 (UTC) FILETIME=[4601EE50:01C6A138] DKIM-Signature: a=rsa-sha1; q=dns; l=4972; t=1152216649; x=1153080649; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:an=20alternative=20approach=20for=20outbound=20proxy=20discovery |To:IETF=20SIP=20List=20; X=v=3Dcisco.com=3B=20h=3DQl/yY21E2ERtmfhbqz8uT0fegOI=3D; b=Xs/SbK3QKIRDdhkqt6wynSQ5aW52RRBjPxTzMfPU2ZIXm84OiLdK4QryKNXnpt8EZSF96cUf MJXpCchK73thNzQGouLCNFDCIedltwwX31AoDirM3vnrUIHTEfdSdT/e; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [Sip] an alternative approach for outbound proxy discovery X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I want to suggest a possible alternative approach for outbound proxy discovery than the one in draft-koivusalo-sip-outbound-discovery. So, before I get to it, two caveats: 1. I am NOT proposing that this be added to sip-outbound, and I'm not suggesting that a normative reference to this or another mechanism should be in outbound. I believe that any discovery mecanism should be orthogonal, and what I am about to propose below is orthogonal as well. 2. I have not been able to follow all of the nearly countless messages on sip-outbound, so I'm not sure if what I'm about to propose has been proposed. So, please point me to relevant threads if it has been The idea is to not use DNS, but rather use SIP mechanisms for the discovery. I much prefer a non-DNS solution for several reasons which I'll enumerate below. The basic mechanism combines two things: 1. usage of the 305/service-route as I have proposed in http://www.ietf.org/internet-drafts/draft-rosenberg-sip-route-construct-01.txt 2. usage of a new header field in REGISTER responses which specifies additional URI to try REGISTERing to So, here is the idea. UA starts with its AOR (sip:user@example.com) for example, or with a domain name learned from DHCP. In either case, it applies RFC3263 and gets the URI for a proxy. This is going to be the home proxy, and there is no keepalive=stun and thus no STUN keepalives here yet. UA sends a REGISTER request. The proxy receives this, and knows that it doesn't accept REGISTER directly like this; it needs to be sent via an edge proxy. There are many ways the proxy can know it got the REGISTER directly and not through an EP. For example, requests from EP come to a different port, or better yet, via TLS mutual auth from edge proxy. So, home proxy redirects the request with a 305. The URI in the contact header field is an edge proxy, and has the keepalive=stun parameter in it. Now, this URI can be a specific IP address, or more interestingly, a hostname that resolves to any number of proxies. This basically becomes the first proxy in the outbound proxy set. If its a hostname, client performs regular old RFC3263 and picks one. Client sends a request there, now with the topmost Route set equal to this URI (this is what I have proposed for 305 handling in route-construct). This arrives at the edge proxy, which inserts itself into Path, which is subsequently reflected into Service-Route, which the proxy can modify on its way towards the client (again this is what I have proposed in route-construct). This Service-Route points to that edge proxy. Now, the UA has a single proxy (so far) in that outbound proxy set. However, that 200 OK to the REGISTER, in addition to having a Service-Route, would also have another header field, called Additional-Proxies or something like that. This header field would contain one or more URI pointing to proxies that the client should register additional flows through. For each of those, the client performs a registration (each of those URI would be the topmost route header field in a REGISTER message, each for a different reg-id). Now, it a multiplicity of flows and outbound proxies all set up. The primary benefit of this mechanism over a DNS one is its dynamic nature. The edge proxy which receives the original REGISTER request and response is the one that inserts the Additional-Proxies header field. Thus, it can purposefully choose a specific proxy acting as its backup, or choose a proxy in a different geographic region, or whatever. These choices can differ from user to user. The original REGISTER requests can be load balanced across all of the proxies in a cluster as a consequence of DNS, but the second flow is selected explicitly by the first proxy. This also lends itself extremely well to mid-dialog failover solutions, since the backup proxy is selected by the primary. Thus, it can choose one to which it is replicating state. It also allows for a variety of algorithms in selecting a record-route value. With this mechanism, it is clear how the provider chooses the number of flows that a UA makes - its an additional one for each value of the Additional-Proxies header field. It also allows us to keep the existing meaning of DNS queries, which are meant to choose a single server and not learn a set of servers that all must be contacted. There is a cost of a single extra round trip for the very first REGISTER to be redirected. However, I do not view this as particularly onerous. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 17:44:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybcB-0001hw-DG; Thu, 06 Jul 2006 17:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fybc9-0001hr-Cq for sip@ietf.org; Thu, 06 Jul 2006 17:42:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FybFj-0003QQ-Sf for sip@ietf.org; Thu, 06 Jul 2006 17:19:15 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyauG-0004X2-Fr for sip@ietf.org; Thu, 06 Jul 2006 16:57:06 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2006 13:57:04 -0700 X-IronPort-AV: i="4.06,214,1149490800"; d="scan'208"; a="303601729:sNHT37548712" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k66Kv3h3001514; Thu, 6 Jul 2006 13:57:03 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k66Kuwvm000686; Thu, 6 Jul 2006 13:57:03 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 16:57:00 -0400 Received: from [161.44.55.141] ([161.44.55.141]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 16:56:58 -0400 Message-ID: <44AD791A.5070704@cisco.com> Date: Thu, 06 Jul 2006 16:56:58 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Ready for WGLC on Outbound? References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <44AD5137.4050601@cisco.com> <44AD621A.301@cisco.com> <009b01c6a13c$15b2b1e0$31713b51@BEMBUSTER> In-Reply-To: <009b01c6a13c$15b2b1e0$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2006 20:56:58.0719 (UTC) FILETIME=[B8CDFEF0:01C6A13E] DKIM-Signature: a=rsa-sha1; q=dns; l=2726; t=1152219423; x=1153083423; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Ready=20for=20WGLC=20on=20Outbound?; X=v=3Dcisco.com=3B=20h=3D+vIhPlqdG6kJmZ9oKSrzl3HpLHY=3D; b=KJN2J5O1bC2wVK/akdHVW0XPcwdMr7LdFC8HXCKTSey26+/baBwGwCrCKbMH8fFm3vK+rZwi BD/JTfJhZoMYzjAMqv4pmJr7IdjQwmjKKymOlSSk3pK35dR/1oSG5WCn; Authentication-Results: sj-dkim-7.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Cullen Jennings , sip@ietf.org, rohan@ekabal.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: >> Jonathan Rosenberg wrote: >> >>> Finally, let me say that if you have a proxy that crashes on receipt >>> of binary messages on its sip port, you are in for real trouble. I >>> think a far better solution is for proxy vendors to fix their >>> proxies, rather than for us to bend over backwards to design new >>> mechanisms that help protect such fragile servers from ever seeing >>> these messages. No matter what we put in our specs, attackers can >>> still send binary messages that will result in the same result you >>> are trying to prevent. >> >> >> I would agree with this in the case of UDP or in other cases where the >> transport does the framing. It seems that for stream based transports >> unrecognized binary data could mess up framing. Proxies could try to >> recover but I don't know if it's reasonable to expect proxies to keep >> connections open for an extended period of time when all they see is a >> some garbage every 30 seconds or so. It's not necessarily that the >> proxy crashes but that it gives up on a particular connection at some >> point. >> >> Thanks, >> Anders > > > Yes, exactly! And for TLS a proxy might interpret it as an encryption > failure, and trigger some anomaly detection system, There wouldn't be a TLS decryption failure - this is all transparent data as far as TLS is concerned. Anders is correct that you might lose framing on the TCP connection, in whcih case the client gets no service. No other clients are affected. However, keep in mind that the use case here is a misconfiguration. Any number of misconfigurations, such as an invalid IP address, for example, will cause the client to not receive service. I'm not objecting to the concept of this check. I just think its not necessary, something that might be optional at best. As such, if folks decide they want something, it can go in another draft. I dont think we need to burden sip-outbound with this. Indeed, I'll note that, in the outbound proxy discovery mechanism I just proposed, the flag comes for free with the mechanism since the outbound proxies are confirmed via service-routes, which can contain the stun=keepalive flag. This would argue strongly that any kind of check, if needed, goes with the discovery mechanism and not sip outbound itself. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 18:25:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FycFf-0002XF-4t; Thu, 06 Jul 2006 18:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FycFd-0002XA-Lh for sip@ietf.org; Thu, 06 Jul 2006 18:23:13 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FycFd-0002l7-Ao for sip@ietf.org; Thu, 06 Jul 2006 18:23:13 -0400 Received: from [172.17.2.251] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k66MLrOs019976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Jul 2006 17:21:55 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44AD8CF2.2030401@nostrum.com> Date: Thu, 06 Jul 2006 17:21:38 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "'SIP WG'" Subject: Re: [Sip] Outbound Comment: binding key References: <03a001c6a12f$7850bd90$a7c8000a@acmepacket.com> In-Reply-To: <03a001c6a12f$7850bd90$a7c8000a@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel: I agree with your assessment, and would be _much_ happier if we simply removed all the text that implied that the proxy has to maintain multiple bindings with the same instance-id and reg-id. I think, at the very least, the draft needs some motivating text around why the proxy/registrar is expected to keep tabs of stale registration state. /a Hadriel Kaplan wrote: > My interpretation was the opposite - if a Register comes in with the same > {instance-id,reg-id} then it should indeed replace/overwrite the previous > binding of the same tuple. I know there are several sections in the draft > which imply otherwise, but I don't understand why. There is no real value > I can see to keeping a binding for an old flow of the same reg-id, since by > definition the UA would only "re-use" a reg-id if the old flow failed (or > even if it didn't think it had failed, but something rebooted and changed > the flow). > > I can see no realistic way in which an old flow of the same > {instance-id,reg-id} would succeed in reaching the UA. Am I missing > something? > > -hadriel > p.s. it's theoretically possible, if a sip-udp UA rebooted and resolved a > new proxy address and sent a register to it with the same reg-id, that it > may still be possible to reach the UA through the old "flow" for a time. > But is that a realistic case worth caring about? > > > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Thursday, July 06, 2006 1:12 AM >> To: Cullen Jennings >> Cc: SIP WG >> Subject: [Sip] Outbound Comment: binding key >> >> From section 6.1: >> >> When a reg-id header parameter is present in a Contact header field >> value in a REGISTER request, the corresponding binding is between an >> AOR and the combination of instance-id and reg-id. >> >> I don't think this is quite correct. This statement appears to be >> asserting that {instance-id,reg-id} is a unique key to a binding >> associated with an AOR. This would, in turn, imply that any successful >> registration attempt with an {instance-id,reg-id} that matches an >> existing binding would overwrite the existing record. >> >> I don't think that is what's intended, since section 6.2 contains the >> following text: >> >> o If two bindings have the same instance-id and reg-id, the proxy >> SHOULD prefer the contact that was most recently updated. >> >> If the binding is only to {instance-id,reg-id}, then that text is >> nonsensical: you can't have two identical bindings to the same AOR. >> >> I suspect that the text in 6.1 should actually read something more like: >> >> When a reg-id header parameter is present in a Contact header field >> value in a REGISTER request, the corresponding binding is between an >> AOR and the combination of instance-id, reg-id, and network flow. >> >> /a >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 18:30:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FycKu-0006Ww-QE; Thu, 06 Jul 2006 18:28:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FycKt-0006TF-UP for sip@ietf.org; Thu, 06 Jul 2006 18:28:39 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FycKs-0003ce-5U for sip@ietf.org; Thu, 06 Jul 2006 18:28:39 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2006 15:28:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,214,1149490800"; d="scan'208"; a="31387245:sNHT144115904" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k66MSUCp028176 for ; Thu, 6 Jul 2006 18:28:30 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k66MSUoB021727 for ; Thu, 6 Jul 2006 18:28:30 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 18:28:30 -0400 Received: from [161.44.55.141] ([161.44.55.141]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 18:28:30 -0400 Message-ID: <44AD8E8D.7090601@cisco.com> Date: Thu, 06 Jul 2006 18:28:29 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2006 22:28:30.0196 (UTC) FILETIME=[81FAE340:01C6A14B] DKIM-Signature: a=rsa-sha1; q=dns; l=19704; t=1152224910; x=1153088910; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:comments=20on=20sip-outbound-04 |To:IETF=20SIP=20List=20; X=v=3Dcisco.com=3B=20h=3DTXgCjHKqIMOgBIbervI/9W8tCvI=3D; b=hKSlt31iRIW2hMZuCC7hSfOjtt/gLX6eEcTF0OfE3juWThc4Bk6WnBZ0cdw+QsV3Lzp9EwCy gXOK25I4ZqLpT/daSXmIw/tos/+HYHGVZAbrXmIqV+Op6XolmcMTyu/r; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Subject: [Sip] comments on sip-outbound-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > such detection takes time and leaves a window of opportunity for > missed incoming requests, this mechanism allows the UA to use > multiple flows to the proxy or registrar. This mechanism also uses a multiple flows to multiple proxies or registrars > Edge Proxy: An Edge Proxy is any proxy that is located topologically > between the registering User Agent and the registrar. nit: topological in what sense? Certainly not in the IP sense. Its only in the SIP sense. SHould be clarified. > outbound-proxy-set A set of SIP URIs (Uniform Resource Identifiers) Missing colon after outbound-proxy-set. > is power cycled. Each UA can register multiple times over different > connections for the same SIP Address of Record (AOR) to achieve high over different flows for the same... > The registrar can use the reg-id label to > recognize that a UA is registering after a reboot or a network > failure. reg-id is not just needed for reboots; its needed to differentiate different registrations to the same instance for purposes of high availability > When a proxy goes to route a message to a UA for which it has a > > > > Jennings & Mahy Expires December 27, 2006 [Page 5] > > Internet-Draft Client Initiated Connections in SIP June 2006 > > > binding, it can use any one of the flows on which a successful > registration has been completed. this paragraph really applies to a home proxy. I think you should clarify that, and then summarize edge proxy procedures too. > The registrar saves the instance-id > ("urn:uuid:00000000-0000-0000-0000-000A95A0E128") and reg-id ("1") > along with the rest of the Contact header field. If the instance-id > and reg-id are the same as a previous registration for the same AOR, > the proxy uses the most recently created registration first. it uses it first when processing incoming requests. The rest of the paragraph is talking about processing register requests, and this summary sounds like its implying that you would delete the previous registration. > When the proxy goes to forward a request to a given target, > it looks and finds the flows over which it received the registration. this uses flows as plural, but the use case is talking about a single flow being registered at a time. So, I think you mean that the proxy looks and finds the flow over which it has received the most recent registration from that instance. > If the proxy has multiple flows that all go to > this UA, it can choose any one of registration bindings for this AOR > that has the same instance-id as the selected UA. sure - but in this example section you've been talking about a single flow. > hosts that can perform the outbound proxy/registrar function for the > domain. Reliability is achieved by having the UA form two TCP > connections to the domain. two flows > The UA is configured with multiple outbound proxy registration URIs. > These URIs are configured into the UA through whatever the normal > mechanism is to configure the proxy or registrar address in the UA. I think we are looking at several options which aren't the 'normal mechanism' for configuration. Indeed I think it shouldn't be the normal configuration mechanism at all. Can we just say that the UA is configured with multiple URI and the means is outside the scope of this specification. > The domain also needs to ensure that a request for the UA sent to > > > > Jennings & Mahy Expires December 27, 2006 [Page 8] > > Internet-Draft Client Initiated Connections in SIP June 2006 > > > host1 or host2 is then sent across the appropriate flow to the UA. > The domain might choose to use the Path header approach (as described > in the next section) to store this internal routing information on > host1 or host2. I don't understand the Path reference here. Path is useful if there is a physically distinct EP, which there isn't. For this particular use case (co-located outbound proxy/registrar and dual flows), I think that the proxy, when doing the registration lookup, will find two registrations. It needs to select the one corresponding to the flow that it knows about. Somewhere in the normative text also we need to say this. > When a single server fails, all the UAs that have a flow through it > will detect a flow failure and try to reconnect. No, they won't try to reconnect, at least not immediately. You point out later that this is done gradually to avoid avalance restart, but this sentence in particular contradicts that. I would suggest: When a single server fails, the UAs that have a flow through it will eventually detect failure of that flow. The clients themselves will need to reconnect in order to re-establish the flow. If clients attempted to reconnect immediately, this would cause a flood of connection attempts at around the same time, a situation known as avalanche restart. To avoid this condition, if a UA has multiple flows, and one of the servers fails..... > restart. If a UA has multiple flows, and one of the servers fails, > the UA delays the specified time before trying to form a new > connection to replace the flow to the server that failed. By new flow > When used in this fashion to achieve high reliability, the operator > will need to configure DNS such that the various URIs in the outbound > proxy set do not resolve to the same host. this statement is fine but doesn't belong in an overview of operation section i think. > Some SIP deployments use edge proxies such that the UA sends the > REGISTER to an Edge Proxy that then forwards the REGISTER to the > Registrar. The Edge Proxy includes a Path header [RFC3327] so that > when the registrar later forwards a request to this UA, the request > is routed through the Edge Proxy. There could be a NAT or firewall > between the UA and the Edge Proxy. you don't show the NAT in any of the other two use cases and certainly they can be there too. THis makes it sound kind of like you need an EP in cases where there is a NAT, which is not the case. > These systems can use effectively the same mechanism as described in > the previous sections but need to use the Path header. When the Edge this is kind of weasely text. I'd suggest: In this topology, the same mechanism as described in the previous section is used, with the addition of the Path header. > registrar succeeds, it allows the Edge Proxy to indirectly check the > user's authentication information via the registrar. The identifier > SHOULD be placed in the user portion of a loose route in the Path > header. If the registration succeeds, the Edge Proxy needs to map normative statements do not belong in overview sections. see rfc4485. > For connection-less transports, a flow definition could change > because a NAT device in the network path reboots and the resulting > public IP address or port mapping for the UA changes. To detect > this, requests are sent over the same flow that is being used for the > SIP traffic. stun requests are sent over the same flow > cycles of the device. The Instance ID MUST NOT change as the device > moves from one network to another. suggest also saying that the instance ID MUST NOT vary across different network interfaces that the device has. There has been some confusion about whether a multi-homed device would have different instance IDs on each network interface. > The UA SHOULD include a "sip.instance" media feature tag as a UA > characteristic [RFC3840] in requests and responses. in the very next section, you say that inclusion of sip.instance media feature tag in a registration is a MUST. So, these are not consistent. Also, you never actually say that this value is the UA instance URN you've been talking about in the previous paragraphs. > The value of this parameter MUST be a URN [RFC2141]. One case where > a UA may not want to include the URN in the sip.instance media > feature tag is when it is making an anonymous request or some other > privacy concern requires that the UA not reveal its identity. ..may not want to include its instance identifier URN in the sip.instance.... > UAs obtain at configuration time one or more SIP URIs representing > the default outbound-proxy-set. This specification assumes the set > is determined via any of a number of configuration mechanisms and > future specifications may define additional mechanisms such as using > DNS to discover this set. How the UA is configured is outside the > scope of this specification. I think the term 'configuration' is a bit loaded here, and others I think have commented on this too. I'd suggest, instead: UAs obtain, through some means outside the scope of this specification, one or more SIP URIs representing the default outbound-proxy-set. > URIs. For each outbound proxy URI in the set, the UA MUST send a > REGISTER in the normal way using this URI as the default outbound > proxy. the word 'normal' concerns me here. What does this mean? Per rfc3261 procedures? Thats not really right, since we are updating those procedures here. Suggest: For each outbound proxy URI in the set, the UA MUST send a REGISTER using the procedures defined here (which augment those defined in RFC3261) using this URI as the default outbound proxy. > These ordinary registration requests MUST also add a distinct reg-id > parameter to the Contact header field. remove 'ordinary' You also need to define 'distinct'. What you mean is that the value must be distinct across all other flows to be concurrently registered by the same instance. > The > reg-id sequence does not have to be sequential but MUST be exactly > the same reg-id sequence each time the device power cycles or reboots > so that the reg-id values will collide with the previously used > reg-id values. This is so the proxy can realize that the older > registrations are probably not useful. This text is very confusing, especially the first sentence which says that a sequence of something doesn't have to be sequential. I'd suggest: Furthermore, if the UA will be using N simultaneous flows, the N values of the reg-id that are used MUST be reused in subsequent refreshes or brand new registrations made at a later time. As a consequence, the reg-id forms a sort of sequence number, giving a persistent identifer to each of the N concurrent registrations that the UA will make. Indeed, one perfectly valid choice for the reg-id is to use a monotonically increasing sequence number from 1 to N, however this is not required. > The UAC MAY examine successful registrations for the presence of an > 'outbound' option-tag in a Supported header field value. Presence of > this option-tag indicates that the registrar is compliant with this > specification. this is meaningless unless you specify something that the client does differently based on the presence of this header field. Also, this section doesn't talk about how a UA determines whether or not the registrar supports the contact header field extensions and new mechanisms defined here. It needs to do that. > The UA performs normal DNS resolution on the next hop URI (as > described in RFC 3263 [RFC3263]) to find a protocol, IP address, and > port. For non-TLS protocols, if the UA has an existing flow to this > IP address, and port with the correct protocol, then the UA MUST use > the existing connection. For TLS protocols, there must also be a > match between the host production in the next hop and one of the URIs > contained in the subjectAltName in the peer certificate. If the UA > cannot use one of the existing flows, then it SHOULD form a new flow > by sending a datagram or opening a new connection to the next hop, as > appropriate for the transport protocol. I'm pretty sure that this text would fundamentally require UA changes for any mid-dialog failover solution to work. I'm still noodling over whether there is a better matching algorithm that is more likely to work with future mid-dialog failover mechanisms. > The time between keepalive requests when using UDP-based transports > > > > Jennings & Mahy Expires December 27, 2006 [Page 14] > > Internet-Draft Client Initiated Connections in SIP June 2006 > > > SHOULD be a random number between 24 and 29 seconds while for TCP- > based transports it SHOULD be a random number between 95 and 120 > seconds. These times MAY be configurable. you need to clarify that you redraw the random number each time you send a keepalive, not just once on startup. ALso, the bit thats configurable are the ranges (24-29, 95-120). Also should specify that the random number is uniformly distributed. > If the parameter is present, the UA needs > to periodically perform keepalive checks by sending a STUN [I-D.ietf- > behave-rfc3489bis] Binding Requests over the flow. you should point to the binding keepalive usage specifically in 3489bis. > These three times MAY be configurable in the UA. The three times > are: > o max-time with a default of 1800 seconds > o base-time-all-fail with a default of 30 seconds > o base-time-not-failed with a default of 90 seconds the formula doesn't include the variables 'base-time-all-fail' or 'base-time-not-failed'. It just has 'base-time'. Suggest: o base time with a default of 90 seconds if there are other non-failed flows, and 30 seconds if all other flows have failed > When an Edge Proxy receives a registration request with a reg-id > header parameter in the Contact header field, it MUST form a flow > identifier token that is unique to this network flow. The Edge Proxy > MUST insert this token into a URI referring to this proxy and place > this URI into a Path header field as described in RFC 3327 [RFC3327]. > The token MAY be placed in the userpart of the URI. It also needs to remember the flow and associated it with this token. > Algorithm 1: The proxy base64 decodes the user part of the Route > header. For a TCP-based transport, if a connection specified by > the file descriptor is present and the creation time of the file > descriptor matches the creation time encoded in the Route header, > the proxy forwards the request over that connection. For a UDP- > based transport, the proxy forwards the request from the encoded > file descriptor to the source IP address and port. you need to specify the conditions under which a 410 is sent. You do that for algorithm 2 but not here. > For a binding > with an instance-id, the registrar still stores the Contact header > field value URI with the binding, but does not consider the Contact > URI for comparison purposes. I think you mean: For a binding to an instance-ID and reg-ID, the registrar still stores.... Also, you may want to clarify handling when there is an instance-ID but no reg-id, and reg-id but no instance ID. You also need to point out here quite explicitly that it is very likely that there can be registrations for the same AOR that have difference instance ID and reg-IDs, but the same contact URI. This happens when the client is behind NAT and includes a private IP address in the contact URI, such as sip:10.0.1.1:5060. > In addition to the normal information stored in the binding record, > some additional information MUST be stored for any registration that > > > > Jennings & Mahy Expires December 27, 2006 [Page 18] > > Internet-Draft Client Initiated Connections in SIP June 2006 > > > contains a reg-id header parameter in the Contact header field value. > The registrar MUST store enough information to uniquely identify the > network flow over which the request arrived. For common operating > systems with TCP, this would typically just be the file descriptor. > For common operating systems with UDP this would typically be the > file descriptor for the local socket that received the request, the > local interface, and the IP address and port number of the remote > side that sent the request. this is only for registrars co-located with edge proxies. Need to clarify that. > o The proxy MUST NOT populate the target set with more than one > contact with the same AOR and instance-id at a time. If a request > for a particular AOR and instance-id fails with a 410 response, > the proxy SHOULD replace the failed branch with another target (if > one is available) with the same AOR and instance-id, but a > different reg-id. > o If two bindings have the same instance-id and reg-id, the proxy > SHOULD prefer the contact that was most recently updated. here is where you need to add words that in the co-located EP/home proxy case, the reg-id corresponding to the flow held by that EP is used. Also I think generally more guidance is needed on selection of registrations when there are multiple reg-id. For example, if you are using geo-redundancy, the home proxy would use the reg-id received from teh EP in its own region. > Additionally, when the > proxy forwards a request to a binding that contains a reg-id, the > proxy MUST send the request over the same network flow that was saved > with the binding. only applies to the EP -should be clear on that. > 7.1. STUN Processing > > This document defines a new STUN usage for connectivity checks. no no. Firstly its not 'connectivity check', as thats something different entirely. This is binding keepalive usage. I think we should define the usage in rfc3489bis, and merely specify here that this usage is applied to sip. The only thing that needs to be in here is the keepalive=stun bit. Everything else in this section is already in rfc3489bis. > The simple case is when there are no edge proxies. In this case, the > only time an entry can be added to the routing for a given AOR is > when the registration succeeds. SIP already protects against > attackers being able to successfully register, and this scheme relies > on that security. attackers can be authenticated too. The scheme in here does not assume that attackers are unauthenticated. > This section registers a new media feature tag, per the procedures > defined in RFC 2506 [RFC2506]. The tag is placed into the sip tree, > which is defined in RFC 3840 [RFC3840]. > > Media feature tag name: sip.instance > > ASN.1 Identifier: New assignment by IANA. If memory serves me correctly, in the end with rfc3840 I had to pick the ASN.1 identifiers. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 18:43:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FycXE-0001sd-Ft; Thu, 06 Jul 2006 18:41:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FycXD-0001sY-AP for sip@ietf.org; Thu, 06 Jul 2006 18:41:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FycXC-0005KM-1s for sip@ietf.org; Thu, 06 Jul 2006 18:41:23 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2006 18:41:22 -0400 X-IronPort-AV: i="4.06,214,1149480000"; d="scan'208"; a="91926948:sNHT30693232" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k66MfL4I014838 for ; Thu, 6 Jul 2006 18:41:21 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k66MfLQw016948 for ; Thu, 6 Jul 2006 18:41:21 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 18:41:21 -0400 Received: from [161.44.55.141] ([161.44.55.141]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 18:41:21 -0400 Message-ID: <44AD9190.60606@cisco.com> Date: Thu, 06 Jul 2006 18:41:20 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2006 22:41:21.0446 (UTC) FILETIME=[4DAE4C60:01C6A14D] DKIM-Signature: a=rsa-sha1; q=dns; l=1448; t=1152225681; x=1153089681; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:comments=20on=20draft-johns-sip-outbound-middialog-draft-00 |To:IETF=20SIP=20List=20; X=v=3Dcisco.com=3B=20h=3D0Ipsp7YBRK3gW7RjC23+jwcxvDs=3D; b=DezDSzQfbr/cYZhbCYvsg4WNmjdSJzGWRZiXFSryKwdL1VWCziIBCcommGhq2dVfrxSGCiTj hbsiBaSiCbuLCRfm1CMzoxO/abRwVAWW8fgK0sk3VgaWHBFS3U/fuUKh; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] comments on draft-johns-sip-outbound-middialog-draft-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Kevin, Thanks for taking a crack at this. The mid-dialog case is a nasty hard problem and one we really do need to solve. I'm not sure the mechanism you propose has the necessary security properties, however. The attack I'm worried about is where an attacker, who is a valid but malicious user in the system, registers to the network and includes an instance ID and reg-id matching that of another user, the target. In this case, the edge proxy creates the same flow ID, and probably replaces the binding between that flow ID and the flow on which the register was received. Thus, an attacker will hijack incoming calls targeted for the target. Another big part of the problem is how the edge proxies construct a URI whose domain part happens to resolve to the actual two proxies which happen to be the ones that the client registered through. With current sip-outbound neither edge proxy knows what the other edge proxy is, so how could you construct such a URI? (note I've just posted an alternative solution for outbound discovery which will make this possible). Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 19:10:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fycxn-0004ip-D2; Thu, 06 Jul 2006 19:08:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fycxm-0004ik-Es for sip@ietf.org; Thu, 06 Jul 2006 19:08:50 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fycxk-0007dm-Qc for sip@ietf.org; Thu, 06 Jul 2006 19:08:50 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3B89F8C4; Fri, 7 Jul 2006 01:08:48 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 01:08:47 +0200 Received: from [136.225.183.83] ([136.225.183.83]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 01:08:44 +0200 From: "Christer Holmberg" To: "Jonathan Rosenberg" , "IETF SIP List" Subject: Re: [Sip] an alternative approach for outbound proxy discovery Date: Fri, 7 Jul 2006 02:08:56 +0300 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 06 Jul 2006 23:08:47.0191 (UTC) FILETIME=[229F0E70:01C6A151] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, There are a couple of issues/deployment restrictions with your = proposal. 1. The home proxy has, as you indicate, to know that an edge proxy is = needed. If the edge proxy is used only for STUN keepalive that may be = difficult, because the home proxy would need to know when keepalive is = needed in the first place. Or, of course it could force all registrations = to go via the edge proxy. 2. The home proxy and the edge proxy may be in different administrative = domains, so the home proxy may not know the address of the edge proxy = (maybe not even in which domain it's located). 3. The request may traverse a numbet of proxies in any case, so the home = proxy would have to know whether one of those is the edge proxy or = not. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 19:10:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fycy0-0004jh-5y; Thu, 06 Jul 2006 19:09:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fycxy-0004jc-8K for sip@ietf.org; Thu, 06 Jul 2006 19:09:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fycxw-0007hQ-OU for sip@ietf.org; Thu, 06 Jul 2006 19:09:02 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0BAAD8C3; Fri, 7 Jul 2006 01:09:00 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 01:08:59 +0200 Received: from [136.225.183.83] ([136.225.183.83]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 01:08:56 +0200 From: "Christer Holmberg" To: "Ben Campbell" , "Jeroen van Bemmel" Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Fri, 7 Jul 2006 02:09:03 +0300 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 06 Jul 2006 23:08:58.0847 (UTC) FILETIME=[29919EF0:01C6A151] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, Juha Heinanen , dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I agree with Bell. A server shouldn't crash if someone sends "non-SIP" = stuff to it. In that case people will be in trouble - with or without = outbound and STUN. The main reasons I want to know whether the proxy supports STUN are: 1. I don't want to send STUN request for nothing. It's not about whether = the receiver will crash or not - it's just bad and unoptimized behavior. = And, as Jeroen mentioned, the proxy could blacklist a client sending = "unknown stuff". 2. A client may choose another edge proxy, if the current does not support = STUN. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 19:37:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FydNj-0002uY-U4; Thu, 06 Jul 2006 19:35:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FydNi-0002uQ-Q6 for sip@ietf.org; Thu, 06 Jul 2006 19:35:38 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FydNh-0002Fh-Hl for sip@ietf.org; Thu, 06 Jul 2006 19:35:38 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Jul 2006 16:35:37 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k66NZaG9010019; Thu, 6 Jul 2006 16:35:36 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k66NZaCU005769; Thu, 6 Jul 2006 16:35:36 -0700 (PDT) Received: from [192.168.100.107] (sjc-vpn1-422.cisco.com [10.21.97.166]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k66NU0f9019852; Thu, 6 Jul 2006 16:30:00 -0700 In-Reply-To: <44AC1A8E.4000707@lucent.com> References: <20060704163058.ADAC41CC22@delta.rtfm.com> <44AC1A8E.4000707@lucent.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5E859922-14C9-44D1-9C0B-74E8AEBF58E6@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] Comments on draft-gurbani-sip-domain-certs-01 Date: Thu, 6 Jul 2006 19:35:22 -0400 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-2.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=770; t=1152228937; x=1153092937; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-gurbani-sip-domain-certs-01; X=v=3Dcisco.com=3B=20h=3DFhqf2Mh4zuQGdFZfDcMfwTF5hwA=3D; b=BWSAKyMNZ3Lw2h3UjbvKTG7NQuhr6c//zSmdLYufGTZZJVh52XaX+erfYmFfYQ8bD0zi4i1+ 8ZunR5YXn1Rk6X8QvtrQdyfzHDCNVQOktISrLftWOA8yZRdhApVEdBzc; X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 5, 2006, at 4:01 PM, Vijay K. Gurbani wrote: Quick question: > on the same outcome you mention above; i.e., it suffices > that when contacting "sips:alice@atlanta.com", the certificate > presented contains "atlanta.com." > Do you mean "the name in the certificate contains the string" or "ends with the string" or something else. In other words, does a certificate for badboy.atlanta.com.chaoscomputerclub.org match a sip uri of sip:alice@atlanta.com. One would think not... Or do you mean "the name in the certificate is precisely the string 'atlanta.com'", in which case does the certificate match sip uri's registered in a subdomain, e.g. alice@downtown.atlanta.com. The "contains" terminology ought to be a bit tighter, no? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 21:08:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyenX-0001sv-Uc; Thu, 06 Jul 2006 21:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyenW-0001sq-9c for sip@ietf.org; Thu, 06 Jul 2006 21:06:22 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyenU-0003Vh-Vu for sip@ietf.org; Thu, 06 Jul 2006 21:06:22 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k6710jN28650; Thu, 6 Jul 2006 21:00:45 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Issue Header For Request Date: Thu, 6 Jul 2006 20:06:15 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D1BEAF9@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Issue Header For Request Thread-Index: AcagOCqK/OT91NNhTRmqn/OBcC+2zAAjfPlgACbO/0A= From: "Samir Srivastava" To: "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, Thx for the your comments and insights. Pl find my replies below << Removed Unrelated stuff> No, that's not correct either, as I showed in an earlier diagram, of exactly this case, repeated here. Alice Atlanta Biloxi ----- ------- ------ AES-SHA AES-SHA 3DES-SHA AES-SHA256 AES-SHA256 AES-SHA In this case, Alice and Atlanta will (most likely) negotiate AES-SHA256. Atlanta will offer AES-SHA and AES-SHA256. Biloxi will select AES-SHA.=20 Now, it's certainly true that if Alice configures her client to be AES-SHA256 only then she won't be able to get a call through, but that's a feature because it's a deliberate advertisement that she's unwilling to do other algorithms.=20 1) Here you think, after the upgrade Alice still advertises the older cipher-suites. Where I think, it will use the latest cipher-suites in the TLS. And say there are some cipher-suites from the last versions, and some more from the second last version etc in a header. It can enumerate any number of cipher-suite with the preference. Any proxy down the line can use from the preferential order. In your algorithm, Take the case of 40 bit cipher-suites being advertised by Alice, and it is being selected due to commonality in the hop way ahead of UAC. Though there is another more secure cipher-suite available and honoured by the UAC, but that is not carried forward. Let us take the following generic case UAC P1 P2 P3 P4 UAS ---- ---- ---- ---- ---- ---- Ciphers A,B,C,D,E B,C C,D D,B B,E B,E =20 UAC advertises all possible cipher-suites. Here hop P1 to P2 will be established as C is the common cipher-suite between supported and offered. Now as the advertised cipher-suites are not carried forward, Call will fail between Hop P2 and P3, as D is not the cipher-suite used on the earlier hop and P2 has no knowledge that UAC is willing to honour D. P2 will reject the call.=20 2) You seem to focus on the mandatory cipher-suite being a common denominator always to setup the call. I found following for Mandatory cipher-suites=20 RFC 2246 in Mandatory Cipher Suite section says=20 "In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. " RFC 4346 in Mandatory Cipher Suites says=20 "In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA." =20 RFC 3261 mentions that TLS_RSA_WITH_AES_128_CBC_SHA MUST be supported, but others can be supported too. It asks for supporting 3DES also. =20 Going forward, we might say AES256 MUST be supported, and others can be too. Your expertise will be helpful for commenting on chances of change of MUST for SIP.=20 Now let us take a generic case with moving mandatories UAC P1 P2 P3 UAS --- -- ----- ----- ----- ciphers A1,A2 A1 A1,A2 A1,A2 Assume A1 is older mandatory cipher, and A2 is new mandatory cipher.=20 Your scheme doesn't allow the usage of A2 on the further hops (P3-UAS) down the line, though being supported and acknowdged by UAC, as somewhere in between older cipher is used.=20 Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 21:24:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyf3W-0003pl-6m; Thu, 06 Jul 2006 21:22:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyf3U-0003pg-OQ for sip@ietf.org; Thu, 06 Jul 2006 21:22:52 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyf3T-0005UA-Gh for sip@ietf.org; Thu, 06 Jul 2006 21:22:52 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k671MmQ18231; Thu, 6 Jul 2006 21:22:48 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Issue Content in Response Date: Thu, 6 Jul 2006 20:22:46 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D1BEB08@zrc2hxm2.corp.nortel.com> In-Reply-To: <86lkr8xjer.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-srivastava-sip-e2e-ciphersuites-00 Issue Content in Response Thread-Index: AcagOCqK/OT91NNhTRmqn/OBcC+2zABKbC7Q From: "Samir Srivastava" To: "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, This is another thread, to discuss content in the response. <> The whole concept of "least strong" is a mistake. What should be reported back is the entire list of proxies the message went through and the relevant crypto algorithms. 1. From the another threads, it looks that you are in agreement for a reverse channel for indicating back the cipher etc used at each hop. 2. I am okay with sending the complete via trails with ciphers etc used, and let UAC decide how it wants to interpret it. It will be having more number of bytes. If they are in the same packet, it doesn't cost much.=20 Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 06 23:12:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FygjA-0004rZ-9r; Thu, 06 Jul 2006 23:10:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fygj8-0004ps-6t for sip@ietf.org; Thu, 06 Jul 2006 23:09:58 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fygj5-0004aN-V7 for sip@ietf.org; Thu, 06 Jul 2006 23:09:58 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20060707030954m14009fb7ne>; Fri, 7 Jul 2006 03:09:55 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k6739sxp017246 for ; Thu, 6 Jul 2006 23:09:54 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k6739r8E017242; Thu, 6 Jul 2006 23:09:53 -0400 Date: Thu, 6 Jul 2006 23:09:53 -0400 Message-Id: <200607070309.k6739r8E017242@dragon.ariadne.com> From: Dale.Worley@comcast.net To: sip@ietf.org In-reply-to: <44AC7E6E.1060406@cisco.com> (jdrosen@cisco.com) Subject: Re: [Sip] comments on draft-worley-sip-many-refers-00 References: <44AC7E6E.1060406@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Jonathan Rosenberg Thanks for taking a stab at this. The 'hidden semantic' behind REFER is a looming potential problem that I don't think we've fully captured. Your draft takes a good step towards uncovering it, but I don't think it quite gets there. Thanks! In the next revision, I'll take care of these issues. At the moment, my interest was just to list all the distinct meanings and determine if it was *possible* for a UA to determine at all times which was intended. I don't think we've made that mistake, but until it's pointed out that the mistake can be made, it's accidental that we haven't. I'm also curious if there are cases I've missed. I'd be surprised if I've found all of them. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 00:08:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyhbG-0001ZL-0o; Fri, 07 Jul 2006 00:05:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyhbE-0001Z5-0p for sip@ietf.org; Fri, 07 Jul 2006 00:05:52 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyhb8-00051U-9l for sip@ietf.org; Fri, 07 Jul 2006 00:05:51 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 08752206D2 for ; Fri, 7 Jul 2006 09:32:46 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 08B4F20683 for ; Fri, 7 Jul 2006 09:07:10 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 09:09:45 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Update to fork-loop-fix submitted Date: Fri, 7 Jul 2006 09:12:54 +0530 Message-ID: <532B18E13CF9E64380EF5FDDE265E0711A07FF@blr-m2-msg.wipro.com> In-Reply-To: <997D9DBB-F126-40EC-B86F-1E3BB8CF91F3@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Update to fork-loop-fix submitted Thread-Index: AcahJJj6pw2FSFMdQGmFx0ShbF3KXQAUlvdw From: To: , X-OriginalArrivalTime: 07 Jul 2006 03:39:45.0402 (UTC) FILETIME=[FD452DA0:01C6A176] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Comment Inline. Regards, Ravi. -- =20 Ravishankar. G. Shiroor Wipro Technologies, Bangalore. =20 ravishankar.shiroor@wipro.com -- =20 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Thursday, July 06, 2006 11:19 PM > To: RaviShankar Shiroor (WT01 - Product Engineering Solutions) > Cc: sip@ietf.org > Subject: Re: [Sip] Update to fork-loop-fix submitted >=20 >=20 > On Jul 5, 2006, at 11:43 PM, =20 > wrote: >=20 > > > > It is always better to reduce the computation in the path of normal > > success case and introduce it in the path of a rarer=20 > scenario. I think > > it will be a fair assumption to make that Spirals will be rarer =20 > > than the > > non-spiraling scenarios. >=20 > But in this case, you are reducing computation (perhaps=20 > trivially) at =20 > the > cost of increased network traffic. True, but it is not going to make it increase the traffic exponentially which is the reason why this draft is coming out. If the traffic were not to increase exponentially, max-forwards would be considered sufficient to handle it right? >=20 > > > > In terms of increasing logic, the increase in logic would be very =20 > > small > > if it all any. > > It would be a trade-off that should be left to the=20 > implementer to take > > if he considers that hash computation is expensive on his=20 > platform. If > > this id recommends the computation of hash at the MUST=20 > strength in the > > first pass of the SIP request, an implementer would not have that > > freedom to make that trade-off.. > > > > Regards, > > Ravi. > > > > -- > > > > Ravishankar. G. Shiroor > > Wipro Technologies, Bangalore. > > > > ravishankar.shiroor@wipro.com > > -- > > > > > >> -----Original Message----- > >> From: Robert Sparks [mailto:rjsparks@nostrum.com] > >> Sent: Wednesday, July 05, 2006 8:21 PM > >> To: RaviShankar Shiroor (WT01 - Product Engineering Solutions) > >> Cc: sip@ietf.org > >> Subject: Re: [Sip] Update to fork-loop-fix submitted > >> > >> I understand the suggestion. You are trading off letting the > >> request through a loop one extra cycle for some lower amount > >> of processing the first time the request went through the > >> proxy. If you believe that spirals are relatively rare > >> things, this change would result in proxies very rarely > >> having to build the loop/spiral differentiation hash. > >> > >> But as Jonathan points out, it's not clear that the hash > >> computation is expensive enough to warrant this extra logic > >> and the extra network traffic it would allow. I expect that > >> the hash calculation expense is small compared to the > >> parse/search/compare operations for "Proxy checks to see if > >> its address is there in the via already". > >> > >> RjS > >> > >> On Jul 3, 2006, at 5:39 AM, > >> wrote: > >> > >>> > >>> Hi Robert, > >>> > >>> I had suggested one more alternative > >>> > >>> (http://www1.ietf.org/mail-archive/web/sip/current/msg14359.html ) > >>> > >>> Quoted from my previous mail: > >>> > >>> > >>> I was thinking how to reduce the impact of overhead for > >> calculating > >>> the > >>> digest. > >>> > >>> If it is suggested as follows, I think it will reduce the > >> overhead on > >>> normal scenarios: > >>> > >>> Proxy checks to see if its address is there in the via already. > >>> If it is not there, it proceeds normally without calculating the > >>> digest > >>> and inserting Via to the outgoing request without the digest. > >>> If it is there, then it is possible that the request is=20 > looping. So, > >>> this time around, it calculates a digests and inserts and sends it > >>> along. > >>> If it is looping, the request will definitely come in > >> again, which can > >>> be rejected. > >>> This way the impact of calculating the digest is required (reduced > >>> to a > >>> smaller percent of the sessions) only when the proxy is > >> suspicious the > >>> request might be looping. > >>> Of course this results in the scenarios mentioned in the id to be > >>> successful in completing the first loop, but the second=20 > loop will be > >>> detected and arrested. I think this can be applicable to > >> general loop > >>> detection, and not just fork loop fixes. > >>> > >>> > >>> Regards, > >>> Ravi. > >>> > >>> -- > >>> > >>> Ravishankar. G. Shiroor > >>> Wipro Technologies, Bangalore. > >>> > >>> ravishankar.shiroor@wipro.com > >>> -- > >>> > >>> > >>>> -----Original Message----- > >>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] > >>>> Sent: Sunday, June 25, 2006 8:22 PM > >>>> To: IETF SIP List > >>>> Subject: [Sip] Update to fork-loop-fix submitted > >>>> > >>>> Until it appears in the repository, see: > >>>> > >>=20 > http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-02.txt > >>>> > >>>> This was a moderately heavy touch - based on list feedback, > >>>> I've moved and updated the sections covering the > >>>> loopdetection algorithm in from 3261. In the process of > >>>> writing the clarifying text, I discovered several places that > >>>> need clarification. They are listed as Open Issues in the > >>>> draft. Basically there are fields that I can't recall or > >>>> reconstruct how they would be useful in the part of the hash > >>>> used for loop-detection or spiral differentiation. If anyone > >>>> can remember why they need to be included, send a note to the > >>>> list and we'll capture that in the draft. > >>>> > >>>> Please review the updated loop-detection text very carefully. > >>>> > >>>> Here's the changelog from the draft: > >>>> > >>>> Integrated several editorial fixes suggested by > >>>> Jonathan Rosenberg > >>>> > >>>> Noted that the reduction of the attack to a single > >>>> registration > >>>> against a single URI as documented in previous versions, > >>>> is, in > >>>> fact, going to be effective against implementations > >>>> conforming to > >>>> the standards before this repair. > >>>> > >>>> Re-incorporated motivation from the original > >>>> maxforwards-problem > >>>> draft into the security considerations section based > >>>> on feedback > >>>> from Cullen Jennings > >>>> > >>>> Introduced replacement text for the loop=20 > detection algorithm > >>>> description in RFC 3261, fixing the bug 648 (the > >>>> topmost Via value > >>>> must not be included in the second part) and=20 > clarifying the > >>>> algorithm. Removed several other fields suggested > >> by 3261 and > >>>> placed open issues around their presence. > >>>> > >>>> Added a Notes to Implementors section capturing the > >>>> "common way" > >>>> text and pointing to the interoperability issues that have > >>>> been > >>>> observed with loop detection at previous SIPits > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> RjS > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol Use > >>>> sip-implementors@cs.columbia.edu for questions on current sip > >>>> Use sipping@ietf.org for new developments on the=20 > application of sip > >>>> > >>> > >>> > >>> The information contained in this electronic message and any > >>> attachments to this message are intended for the exclusive use of > >>> the addressee(s) and may contain proprietary, confidential or > >>> privileged information. If you are not the intended recipient, you > >>> should not disseminate, distribute or copy this e-mail. Please > >>> notify the sender immediately and destroy all copies of this > >>> message and any attachments. > >>> > >>> WARNING: Computer viruses can be transmitted via email. The > >>> recipient should check this email and any attachments for the > >>> presence of viruses. The company accepts no liability for any > >>> damage caused by any virus transmitted by this email. > >>> > >>> www.wipro.com > >> > >> > > > > > > The information contained in this electronic message and any =20 > > attachments to this message are intended for the exclusive use of =20 > > the addressee(s) and may contain proprietary, confidential or =20 > > privileged information. If you are not the intended recipient, you =20 > > should not disseminate, distribute or copy this e-mail. Please =20 > > notify the sender immediately and destroy all copies of this =20 > > message and any attachments. > > > > WARNING: Computer viruses can be transmitted via email. The =20 > > recipient should check this email and any attachments for the =20 > > presence of viruses. The company accepts no liability for any =20 > > damage caused by any virus transmitted by this email. > > > > www.wipro.com >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 00:24:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyhqw-0003U8-IL; Fri, 07 Jul 2006 00:22:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyhqu-0003Tx-Jd for sip@ietf.org; Fri, 07 Jul 2006 00:22:04 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyhqr-0000Vk-RG for sip@ietf.org; Fri, 07 Jul 2006 00:22:04 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2006 21:22:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,215,1149490800"; d="scan'208"; a="31402574:sNHT25437470" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k674M0s0005993 for ; Fri, 7 Jul 2006 00:22:00 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k674M0YP006698 for ; Fri, 7 Jul 2006 00:22:00 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 00:22:00 -0400 Received: from [192.168.1.102] ([10.82.208.176]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 00:22:00 -0400 Message-ID: <44ADE168.7050309@cisco.com> Date: Fri, 07 Jul 2006 00:22:00 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 04:22:00.0481 (UTC) FILETIME=[E44B8910:01C6A17C] DKIM-Signature: a=rsa-sha1; q=dns; l=9224; t=1152246120; x=1153110120; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:comments=20on=20draft-ietf-sip-connect-reuse-05 |To:IETF=20SIP=20List=20; X=v=3Dcisco.com=3B=20h=3DI/I60a/IJzBdlbpbWA+EaWWJkAA=3D; b=sGDd3io3Bw9D8fYBz6aBPQK7WNMXO/S4cJDzFCVp0sFreWjojZQgIqcGMibBd0Eeu9u2j2i2 8cKwTmVZZd8O50zIMwqSV+5HL+mlAvTKvB4nxUPXfCWKZZbXLp0sdI2z; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Subject: [Sip] comments on draft-ietf-sip-connect-reuse-05 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > the connection. SIP entities that can only open a connection in a > specific direction -- perhaps because of Network Address Translation > (NAT) and firewall reasons -- reuse their connections using the > mechanism described in [1]. another important reason is that, in the case of TLS, only one side will offer a certificate. In other words, connect-reuse only applies in truly symmetric models. > Opening an extra connection where an existing one is sufficient can > result in potential scaling and performance problems. Consider the > call flow shown below where Proxy A and Proxy B use the Record-Route > mechanism to stay involved in a dialog. Proxy B will establish a new > TLS connection just to send a BYE request. this presumes in general that there aren't persistent, long-lived connections already set up. > Opening an extra connection where an existing one is sufficient can > result in potential scaling and performance problems. Consider the > call flow shown below where Proxy A and Proxy B use the Record-Route > mechanism to stay involved in a dialog. Proxy B will establish a new > TLS connection just to send a BYE request. the bottom of section 3 already talked about benefits; you should combine together into one place. > This effectively doubles the load on each > entity. definitely not. It doubles the amount of work for connection establishment, but its far from obvious to me in most use cases that the overall work of the proxy is dominated by connection establishment. Today, for the vast majority of cases, there are fairly fixed relationships between proxies and this mechanism won't impact the workload at all. This only starts to show up as an issue in cases of broad interconnection across numerous domains (i.e., every enterprise connects to every other enterprise). Again though I wonder if the connection establishment is really the dominant CPU cost. > ReINVITEs or UPDATE [7] requests are expected to be handled > automatically and rapidly in order to avoid media and session state > from being out of step. If a reINVITE requires a new TLS connection, > the reINVITE could be delayed by several extra round-trip times. > Depending on the round-trip time, this combined delay could be > perceptible or even annoying to a human user. Can you give a specific use case? I don't think there are established guidelines for how long it takes to add video, for example. > The act of reusing a connection is initiated by an user agent client > (UAC, or the proxy half of the UAC) when it adds an "alias" parameter > to the added Via header (the parameter itself is defined later). > When a user agent server (UAS, or the proxy half of the UAS) receives > the request, it examines the topmost Via header. I think you mean just 'client' and 'server' which are well defiend in rfc3261, and are what you want. 'proxy half of a UAC' makes no sense. > Without any loss of > generality, it should be clear that the same technique can be used > for connection reuse between a UAC and an edge proxy, or between an > edge proxy and a UAS, or between an UAC and an UAS. Just talk about clients and servers. > The presence of the "alias" parameter indicates that P1 does support > aliasing. P2 now authenticates the connection and if the > authentication was successful, P2 creates an alias to P1 using the > advertised address in the topmost Via. Firstly, you need to define 'successful' authentication. You need to match the domain in the certificate with the via address. Also, this last sentence is very confusing, since the table is NOT populated with the advertised address, its populated with the received address, as described in the text below. Also how do you populate destination port? The overview section doesn't say. I believe it is NOT the received port (as IP address is) but rather the one advertised in the sent-by field, or 5061 (the default) if no port is listed. > To implement connection aliases for resolved addresses, a SIP node > could (for example) search an additional data structure (the alias > table) prior to opening a new connection, or could modify the data > > > > Mahy, et al. Expires August 5, 2006 [Page 7] > > Internet-Draft SIP Connection Reuse February 2006 > > > structure in which it keeps active connection state so that aliases, > active connections, and blacklisted nodes are all discovered when > looking for an active connection. you've not defined 'an additional data structure' or blacklisted nodes; I couldn't follow this paragraph. > 6. Requirements you may want to have an intro paragraph which says that these are the requirements which motivated this specification > 7. Formal Syntax > > The following syntax specification uses the augmented Backus-Naur > Form (BNF) as described in RFC 4234 [6]. This document extends the > via-params to include a new via-alias defined below. please use the =/ syntax notation that we've started using for sip specs. Its much better. > request. Whenever the RFC3263 server selection mechanism executed at > the receiver results in the choice of this IP address, port, and > transport tuple, the alias MUST be used instead. I think a SHOULD is fine here; and indeed if the connection has gone away you obviously won't be reusing the alias. > An alias is formed at the sender of the request when it executes the > RFC3263 server selection mechanism to arrive at an IP address, port, > and transport tuple to send a request to. Subsequent requests going > to the same destination address MUST use the alias instead. Hmm this MUST is stronger than in rfc3261, which actually says SHOULD. I think the existing SHOULD is fine. > Only one alias SHOULD exist for the resolved address. If more than > one alias is requested because of race conditions (or any other I don't think the SHOULD here is capitalized; you're not specifying an action to take. You need to define 'resolved address'. I don't know what that is. > Because an alias connection might be reclaimed during a transaction, > clients SHOULD NOT enforce the RFC 3261 requirement of sending CANCEL > and ACK (for non 2xx responses) to the same port. If the alias > connection no longer exists, the client SHOULD open a new connection > to the resolved address and send the CANCEL or ACK there instead. > The newly opened connection MAY be inserted into the alias table. Hmm. I think this rule only applies to aliases formed through the mechanism defined here, NOT through the ones obtained from rfc3263. > And furthermore, > it MUST reuse the connection when subsequent requests in the same or > different transactions are destined to the same resolved address. Again per above, I think this is SHOULD. Generally with all of these reuse requirements SHOULD is OK. > Whether or not to allow an aliased connection ultimately depends on > > > > Mahy, et al. Expires August 5, 2006 [Page 9] > > Internet-Draft SIP Connection Reuse February 2006 > > > the recepient of the request. I think you mean that a client gets no confirmation that its downstream peer created the alias, or indeed that it even supports this specification. > Clients must authenticate the connection before forming an alias. > Section 9.1 discusses the authentication steps in more detail. You need to integrate that processing as part of the core client and server behaviors. > A TLS server conformant to this specification MUST ask for a client > certificate; if the client possesses a certificate, it will be > presented to the server for mutual authentication. The server MUST > ensure that the canonical host name of the client is present either where does one obtain the canonical hostname? It seems to me, that in a proxy to proxy case, the receiving proxy (the server side) will need to check the record-route hostname against the client certificate. > This document adds a parameter to the SIP header field parameters > registry: reference rfc3968 > Reference: This document Should say: RFC XXXX [[NOTE TO RFC-EDITOR: please replace with the final RFC number of this specification]] > 13.1 Normative References > > [1] Jennings, C. and R. Mahy, "Managing Client Initiated Connections > in the Session Initiation Protocol (SIP)", > draft-ietf-sip-outbound-01.txt (work in progress), October 2005. I dont think this is a normative reference. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 00:37:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyi3H-0007mw-4x; Fri, 07 Jul 2006 00:34:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyi3E-0007ip-VE for sip@ietf.org; Fri, 07 Jul 2006 00:34:48 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyi3D-0000p4-K4 for sip@ietf.org; Fri, 07 Jul 2006 00:34:48 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2006 00:34:47 -0400 X-IronPort-AV: i="4.06,215,1149480000"; d="scan'208"; a="91941974:sNHT34450952" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k674Ylqs008024; Fri, 7 Jul 2006 00:34:47 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k674YkYP008353; Fri, 7 Jul 2006 00:34:46 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 00:34:46 -0400 Received: from [192.168.1.102] ([10.82.208.176]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 00:34:45 -0400 Message-ID: <44ADE465.5050403@cisco.com> Date: Fri, 07 Jul 2006 00:34:45 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nils Ohlmeier Subject: Re: [Sip] Anybody feeling a connection with "connect reuse"? References: <200606271654.12268.lists@ohlmeier.org> In-Reply-To: <200606271654.12268.lists@ohlmeier.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 04:34:46.0028 (UTC) FILETIME=[AC98BCC0:01C6A17E] DKIM-Signature: a=rsa-sha1; q=dns; l=3347; t=1152246887; x=1153110887; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Anybody=20feeling=20a=20connection=20with=20=22connect=2 0reuse=22? |To:Nils=20Ohlmeier=20; X=v=3Dcisco.com=3B=20h=3DaQq6KZPpMlC7/B/p/l34ur8jL9g=3D; b=ToywN3amnaXjAcxm/XIVrEEQjugoVFU/ZwvuHp8uanUJRcFnzPXxo66/y9kPXdCK67Q36MQm L+trp68oAxiP5uE0MnmGOuSaHf00QbImOU/QLLzg34vFV9vpobbff37L; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org, Rohan Mahy , Keith Drage , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Having just done a detailed review of the document, I will say that I am skeptical of the value of this specification at this time. Firstly, it has fairly limited deployment scenarios: 1. no NATs between the elements 2. mutual TLS auth only assuming these are true, its valuable only when there is generally a lot of churn in TLS connection setups. For example, in an environment where there is a fixed and known-ahead-of-time peering relationship between providers, connect-reuse doesn't do much for you anyway, since there are relatively few TLS connections and they are set up when the system boots, or perhaps just once. Even if the connections aren't set up at startup, but on demand, over time the value of connect-reuse is really zero if the total number of TLS connections that are needed by the proxy is below the capacity of the server. In other words, if a proxy only ever connects to 100 other proxies, then at some point the proxy gets its 200 TLS connections set up (assuming no connect-reuse) and thats it. It never tears them down since it never runs out of resources, so TLS handshaking becomes a fixed, one-time cost. That makes it uninteresting to optimize. The value, then, comes only when the set of proxies that get connected to is constantly changing, such that TLS handshaking between proxy peers is an ongoing and non-trivial percentage of the overall CPU effort. To be frank, I am not aware of a single deployment situation today that meets this constraint. Can someone point me to a real deployment scenario where connect-reuse is applicable and has a non-trivial improvement in the performance of the proxy? Thanks, Jonathan R. Nils Ohlmeier wrote: > On Friday 23 June 2006 23:08, Dean Willis wrote: > >>We've been following the connection reuse draft, currently draft-ietf- >>sip-connect-reuse-05.txt, for a long long time. >> >>We've slipped the charter delivery date several times. >> >>Are we ever going to finish this work? Do we need to finish this work? >> >>Is this something that we could just not do? >> >> >>Otherwise said: "Does the SIP working group still have a consensus to >>expend working group effort on connection reuse?" >> >>If you have an opinion, for or against, please let it be known on >>this list. > > > I think their are two options left: > > - either push it out as "TLS-connection-reuse-between-proxies" (if nobody > comes up with any issue any more) > - or drop it because the real world usage is too limited > > I have little preference for the first alternative, but wouldn't mind to go > for the second option. > > Regards > Nils > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 01:32:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyity-0004Kz-7Z; Fri, 07 Jul 2006 01:29:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyitv-0004Ku-V2 for sip@ietf.org; Fri, 07 Jul 2006 01:29:15 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyitt-0006HS-Ig for sip@ietf.org; Fri, 07 Jul 2006 01:29:15 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2006 22:29:12 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,215,1149490800"; d="scan'208"; a="31405579:sNHT26392292" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k675TCGR026307 for ; Fri, 7 Jul 2006 01:29:12 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k675TAVQ000157 for ; Fri, 7 Jul 2006 01:29:12 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 01:29:10 -0400 Received: from [192.168.1.102] ([10.82.208.176]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 01:29:10 -0400 Message-ID: <44ADF125.5010101@cisco.com> Date: Fri, 07 Jul 2006 01:29:09 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 05:29:10.0383 (UTC) FILETIME=[464DC7F0:01C6A186] DKIM-Signature: a=rsa-sha1; q=dns; l=4616; t=1152250152; x=1153114152; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:comments=20on=20draft-gurbani-sip-domain-certs-01 |To:IETF=20SIP=20List=20; X=v=3Dcisco.com=3B=20h=3DoeiGui4ENVNQrUza++LRQvRRmug=3D; b=U+EU5AG6cM+RH7dIt//LtPQEo8AS9xix/3lokb7yEKrVBMQsp/Zb3Rl6+VaOlJ+2CpjtkMqF p1/0kjQJjpH8nAvdma2c/d0bw75KwdokmzKDzZRR0P6oanjTuvffz1Qc; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [Sip] comments on draft-gurbani-sip-domain-certs-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay, A few comments on the draft. Firstly, I think the draft mixes authentication and authorization. You spend a bunch of time talking about checks that a server makes when receiving a request from a client, comparing bits of the SIP message to the TLS certificate. To me, all of those checks are authorization, not authentication. TLS mutual auth has done what its name suggests - it has already authenticated the other side. Now you are trying to figure out whether they are authorized to send you a SIP request. I think these are quite separable. For example, if my proxy has a policy about only connecting to specific other domains, then it can take the identities determined from TLS mutual auth and use those to decide whether to accept requests coming from that proxy. No need to every look at the via, record-route or whatever. More importantly though, I'm not at all sure that the Via based check you are suggesting adds any value. The value in the Via header is almost never used for anything. Its certainly not used for sending requests in the reverse direction. Its only used if the server needs to open a connection to the client to send a response - an extremely rare case. Thus, it seems futile to verify the value of a field that is never used for anything. Indeed, I'm not at all sure that this whole concept of verifying the client certificate against fields in the SIP request message makes any sense at all. Validaing the Via is almost completely pointless as I mention above. Record-route, which at first glance seems better, won't work either since the proxy might not have record-routed. From doesn't work due to retargeting and also in networks where there are multiple proxies in the terminating domain. Thinking about this some more, I think connect-reue has got the validation model wrong. Its not about validating that the client is authorized to send this request. Rather, what you want to demonstrate is that connect-reuse has security that is equivalent to the 'normal' connection-in-each-direction model. The way you do that is as follows. Consider proxies A and B. A opens a connection to B, and provides a certificate. B caches the certificate and associates it with that connection. B also adds the entries to the alias table as your draft suggests. However, it does not attempt to validate the incoming SIP request against the certificate at all. Now, when B needs to send a request in the reverse direction, it looks up the r-uri/route in DNS, gets the IP/port, and checks the alias table as you have described. If it finds a match, it checks the cached certificate for that connection. The trick is - that certificate had better look exactly like what it would have looked like if B had opened a new TLS connection towards A to send that request. In particular, the r-uri/route domain had better be a match for the SAN in the cached certificate. If its a match, the request is sent over the connection. If not, a fresh connection is opened. This validation model has the desired property; a request gets delivered in the reverse direction with connect-reuse only if it would have been delivered had connect-reuse not been used. This has the benefit of making certificate validation in SIP always look like the existing web-model of client to server connections only. This simplifies the work that domain-certs has to do. It merely needs to give guidance on how the server certificate should look like, addressing the two main things EKR mentioned: 1. what field does the identity get coded into 2. what does that identity represent - the specific host or the domain My two cents is, I think it should always just be the domain (example.com and not proxy2.example.com). Thus if you connect to proxy2.example.com, and the server provided a certificate for example.com, that would be OK. This handles the record-routing use case you mention in the draft and works for server farms and TLS offloaders. I also think its highly unlikely that a cerificate authority would hand out certs that verify that a *host* is proxy2.example.com. How would a CA verify that this is true? Hope this makes sense, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 01:48:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyj9Y-0004tX-Nk; Fri, 07 Jul 2006 01:45:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyj9X-0004tS-5I for sip@ietf.org; Fri, 07 Jul 2006 01:45:23 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyj9T-0000eT-RC for sip@ietf.org; Fri, 07 Jul 2006 01:45:23 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2006 22:45:16 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,215,1149490800"; d="scan'208"; a="31406204:sNHT23732304" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k675jG6p019736; Fri, 7 Jul 2006 01:45:16 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k675jEYP017978; Fri, 7 Jul 2006 01:45:14 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 01:45:14 -0400 Received: from [192.168.1.102] ([10.82.208.176]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 01:45:13 -0400 Message-ID: <44ADF4E9.5000305@cisco.com> Date: Fri, 07 Jul 2006 01:45:13 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence Subject: Re: [Sip] draft-ietf-sip-hop-limit-diagnostics-03 References: <1150495197.10237.51.camel@sukothai.pingtel.com> <1151955580.2892.102.camel@sukothai.pingtel.com> In-Reply-To: <1151955580.2892.102.camel@sukothai.pingtel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 05:45:13.0977 (UTC) FILETIME=[84A68E90:01C6A188] DKIM-Signature: a=rsa-sha1; q=dns; l=2587; t=1152251116; x=1153115116; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-hop-limit-diagnostics-03 |To:Scott=20Lawrence=20; X=v=3Dcisco.com=3B=20h=3D5pQ2UN5Z/znzmcDL8Dk8jJCV0fk=3D; b=F2tvbBqlQ5CXg2JwlE4gLgJrEuSwJREL/eMGKGhALqEw62dwWI7OrbUcAp6mJ48vvFMUqJYN rB8/Fgz0uO05itzFwtTvD0IIiBhMa6NC3iG2/k3q2/yfR2F5Zy3wnic/; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Cullen Jennings , SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Scott Lawrence wrote: > On Mon, 2006-06-26 at 09:00 -0700, Cullen Jennings wrote: > >>On Jun 16, 2006, at 2:59 PM, Scott Lawrence wrote: >> >> >>>There are, I think, two issues remaining for discussion: >> >>I disagree - I don't think the draft of the discussion has addressed >>the issue I brought up. > > > I'm going to guess here - do you mean the issue of how large the > response should be? > > There is text in the draft on _how_ to reduce the size of the response. > > 3261 does not provide guidance clear guidance on response size limits. > It _does_ say that all implementations MUST be able to handle messages > up to the maximum UDP packet size, which can probably handle even 70 hop > messages. If you think that SIP needs better definition of _when_ to > limit response sizes and _what_ size they should be limited to, then I > think that's an interesting discussion, but it's a bigger question than > this error response and a problem that already exists whether this draft > is accepted or not. > Well, here is the history. The transport design of SIP was based on the model that the response used the same transport as the request. We had the somewhat naive view that the response wouldn't be much larger than the request. So, we would take the MTU, subtract off a few hundred bytes to account for any possible increase in the size of the response, and that should be OK. So, the implied limit is the path MTU itself, or 1500 bytes if unknown. But this is not stated explicitly, its implicit from the design. One idea on dealing with the size problem is, instead of including the sip-frag in a response, the resposne just indicates that the hop limit was exceeded. The server which generated the response then sends a request in a totally new transaction, towards the contact of the request. That request contains the sip-frag with all of the information, and could be sent over TCP if needed. That idea doesn't work for requests which omit contact, and also means that intermediate proxies on the path of the failed request might not see the diagnostic information, since it would come over a different transaction. Anyway, just a thought. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 01:55:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyjH7-0005l6-G4; Fri, 07 Jul 2006 01:53:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyjH6-0005l1-74 for sip@ietf.org; Fri, 07 Jul 2006 01:53:12 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyjH3-0002Ia-MZ for sip@ietf.org; Fri, 07 Jul 2006 01:53:12 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k675r6eM014889; Fri, 7 Jul 2006 08:53:08 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 08:53:07 +0300 Received: from [172.21.34.132] ([172.21.34.132]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 7 Jul 2006 08:53:07 +0300 Message-ID: <44ADF6C1.2020404@nokia.com> Date: Fri, 07 Jul 2006 08:53:05 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] A thought on progressing outbound References: <475FF955A05DD411980D00508B6D5FB01369D4C7@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB01369D4C7@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 05:53:07.0290 (UTC) FILETIME=[9EC463A0:01C6A189] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, then I would say that what is missing is a mechanism that allows the domain to indicate the number of flows the UA should establish, independently of the number of provided URIs. At the moment both are tied together, one URI equals one flow. I think those should be decoupled. /Miguel Drage, Keith (Keith) wrote: > Firstly I was not necessarily targetting your comments in particular, but lets try and address your issue in terms of some simple tests: > > 1) what is currently in the draft fulfils the current requirements > 2) what is currently in the draft does not appear to be technically wrong > 3) we apparently do not need to decide between two alternative technical solutions to a requirement > > therefore you have a use case that is different from that of the editors, and ideally we need to reflect the difference between those two use cases either: > > - by clearly stating a need for flexibility to allow those two use cases in the requirements > - or detailing the use cases that need to be supported. > > (assuming that these use cases are considered to be valid) > > The first of these is probably correct in this case. > > regards > > Keith > >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >> Sent: 06 July 2006 12:47 >> To: Drage, Keith (Keith) >> Cc: sip@ietf.org >> Subject: Re: [Sip] A thought on progressing outbound >> >> >> I don't have any problem with the current list of requirements in >> Section 12. The problem is that text in the draft seems to go beyond >> these requirements and impose a certain mandatory redundancy >> scheme, to >> which I strongly disagree as a "mandatory" feature. >> >> /Miguel >> >> Drage, Keith (Keith) wrote: >>> (As WG chair) >>> >>> Having looked at some of the comments on outbound being >> addressed to the list in the last few days, it occurs to me >> that at least of you have fundamental requirements that >> impact the solution and these requirements themselves need to >> be discussed. >>> Hidden in the current draft you will find section 12 >> labelled "requirements". This is a somewhat thin section at >> the moment (not necessarily a bad thing). >>> Can you all please review this section, and identify >> whether these requirements encompass all the requirements >> that you wish to have met in outbound, and then try to >> motivate what you think is missing. >>> And as always "send text". >>> >>> regards >>> >>> Keith >>> >>> Keith Drage >>> Lucent Technologies >>> drage@lucent.com >>> tel: +44 1793 776249 >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> -- >> Miguel A. Garcia tel:+358-50-4804586 >> sip:miguel.an.garcia@openlaboratory.net >> Nokia Research Center Helsinki, Finland >> -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 01:59:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyjKT-0006Wt-LL; Fri, 07 Jul 2006 01:56:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyjKR-0006Us-Ie for sip@ietf.org; Fri, 07 Jul 2006 01:56:39 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyjKP-0002wf-Vm for sip@ietf.org; Fri, 07 Jul 2006 01:56:39 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k675uTsR001736; Fri, 7 Jul 2006 08:56:33 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 08:56:28 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 08:56:27 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound Comment: binding key Date: Fri, 7 Jul 2006 08:56:27 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0280E31D@esebe103.NOE.Nokia.com> In-Reply-To: <03a001c6a12f$7850bd90$a7c8000a@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Comment: binding key Thread-Index: AcaguvmvR6KoNz9BSEiZ8cGMwlV/ogAcglWQABb/suA= From: To: , , X-OriginalArrivalTime: 07 Jul 2006 05:56:27.0482 (UTC) FILETIME=[161743A0:01C6A18A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, In March before Dallas meeting Jeroen raised the same question: > Some comments on this draft: >=20 > Section 3.2 (and elsewhere): in addition to stating that a proxy/registrar > should prefer the most recently registered flow, I would suggest that the > registrar explicitly invalidates an existing registration when it receives a > new registration with the same instance-id / reg-id. This situation would > most likely be due to a reboot of the client. For TCP and other > connection-oriented transports it would be detected, but a registration over > UDP could survive a client crash And this is what Cullen answered: > This has been a topic of large debate and we (with many but not most people > saying exactly what you are saying). We asked about it in WG meeting and on > list and came to agreement that the text that does not allow "explicit > invalidation" was better. I'm scared to reopen this.=20 I do not have a clue what kind of arguments were there in that old debate, but I admit I have been a couple of times wondering this same issue. It would be nice if someone would bring up the thread Cullen is referrng to. If changing the draft like you and Jeroen suggested I believe the draft SHOULD be more explicit about what happens to the old flows ? Will they stay in the registrar database forever ? After one year of operation, does the registrar have e.g. 27 mappings stored for one UA which has rebooted 27 times, even if the most recent of them is used ? Regards, Erkki >-----Original Message----- >From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 >Sent: 06.July.2006 22:08 >To: 'Adam Roach'; 'Cullen Jennings' >Cc: 'SIP WG' >Subject: RE: [Sip] Outbound Comment: binding key > >My interpretation was the opposite - if a Register comes in=20 >with the same >{instance-id,reg-id} then it should indeed replace/overwrite=20 >the previous >binding of the same tuple. I know there are several sections=20 >in the draft >which imply otherwise, but I don't understand why. There is=20 >no real value >I can see to keeping a binding for an old flow of the same=20 >reg-id, since by >definition the UA would only "re-use" a reg-id if the old flow=20 >failed (or >even if it didn't think it had failed, but something rebooted=20 >and changed >the flow). =20 > >I can see no realistic way in which an old flow of the same >{instance-id,reg-id} would succeed in reaching the UA. Am I missing >something? > >-hadriel >p.s. it's theoretically possible, if a sip-udp UA rebooted and=20 >resolved a >new proxy address and sent a register to it with the same=20 >reg-id, that it >may still be possible to reach the UA through the old "flow"=20 >for a time. =20 >But is that a realistic case worth caring about? > > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Thursday, July 06, 2006 1:12 AM >> To: Cullen Jennings >> Cc: SIP WG >> Subject: [Sip] Outbound Comment: binding key >>=20 >> From section 6.1: >>=20 >> When a reg-id header parameter is present in a Contact=20 >header field >> value in a REGISTER request, the corresponding binding is=20 >between an >> AOR and the combination of instance-id and reg-id. >>=20 >> I don't think this is quite correct. This statement appears to be >> asserting that {instance-id,reg-id} is a unique key to a binding >> associated with an AOR. This would, in turn, imply that any=20 >successful >> registration attempt with an {instance-id,reg-id} that matches an >> existing binding would overwrite the existing record. >>=20 >> I don't think that is what's intended, since section 6.2 contains the >> following text: >>=20 >> o If two bindings have the same instance-id and reg-id, the proxy >> SHOULD prefer the contact that was most recently updated. >>=20 >> If the binding is only to {instance-id,reg-id}, then that text is >> nonsensical: you can't have two identical bindings to the same AOR. >>=20 >> I suspect that the text in 6.1 should actually read=20 >something more like: >>=20 >> When a reg-id header parameter is present in a Contact=20 >header field >> value in a REGISTER request, the corresponding binding is=20 >between an >> AOR and the combination of instance-id, reg-id, and network flow. >>=20 >> /a >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 02:01:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyjMb-00080F-Gl; Fri, 07 Jul 2006 01:58:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyjMZ-0007xl-K3 for sip@ietf.org; Fri, 07 Jul 2006 01:58:51 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyjMY-0003Z2-4i for sip@ietf.org; Fri, 07 Jul 2006 01:58:51 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k675wQb4015056; Fri, 7 Jul 2006 08:58:40 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 08:58:38 +0300 Received: from [172.21.34.132] ([172.21.34.132]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 7 Jul 2006 08:58:38 +0300 Message-ID: <44ADF80B.2000204@nokia.com> Date: Fri, 07 Jul 2006 08:58:35 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com> In-Reply-To: <44AD56B7.9020905@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 05:58:38.0054 (UTC) FILETIME=[63EAF860:01C6A18A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Cullen Jennings , sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline Jonathan Rosenberg wrote: > inline. > > Miguel Garcia wrote: > >> Cullen Jennings wrote: >> >>> >>> >>> I expect you are right in that this MUST is too strong here but I >>> think there is an argument for SHOULD. The problem is that if the >>> domain assume the UA is doing two flows and the UA does one, things >>> are broken. >>> >> >> I would like to understand which part of the outbound mechanism is >> broken if the domain assumes the UE will do two flows, but the UA does >> one flow. Yes, it isn't reliable, but the mechanism works nicely... or >> not? >> >> Then... why can't a domain indicate just one outbound URI? At the >> moment the draft has an artificial lower limit for all the domains to >> provide two URIs and impose a reliability that might not be >> required/needed. > > Thats not my read. > > The draft says that a client has to support at least 2 outbound URI, and > that it MUST send a REGISTER for each. However, that doesn't mean a > domain *has* to provide two; it can also provide one. A domain would > only provide one if it knows that it doesn't need two for purposes of > reliability, or if it doesn't require reliability of service. True, but then the UA does not have an alternative outbound server, in case the supplied one fails. What I don't like is the one to one relation between the number of supplied outbound URIs and the number of flows (and REGISTER). Additionally I suspect that users may still impose local policies in the UAs as for the number of established flows, independently of the number of learned URIs. So, the MUST in the spec is always subject to local policy. And a third thing is that, according to RFC 2119: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. I don't see the need for a MUST in that paragraph, because the spec is not broken even if the UA does not obey the MUST. /Miguel > As such, I support the current text which says that a client MUST send a > REGISTER to each outbound URI. > > Thanks, > Jonathan R. > > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 02:07:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyjSA-0000VQ-JB; Fri, 07 Jul 2006 02:04:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyjS8-0000VL-O4 for sip@ietf.org; Fri, 07 Jul 2006 02:04:36 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyjS6-0004GA-CV for sip@ietf.org; Fri, 07 Jul 2006 02:04:36 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2006 23:04:34 -0700 X-IronPort-AV: i="4.06,215,1149490800"; d="scan'208"; a="303727568:sNHT31356042" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k6764X8r011268 for ; Thu, 6 Jul 2006 23:04:33 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6764Xfr023571 for ; Thu, 6 Jul 2006 23:04:33 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 02:04:32 -0400 Received: from [192.168.1.102] ([10.82.208.176]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 02:04:32 -0400 Message-ID: <44ADF970.3040708@cisco.com> Date: Fri, 07 Jul 2006 02:04:32 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 06:04:32.0914 (UTC) FILETIME=[376E4F20:01C6A18B] DKIM-Signature: a=rsa-sha1; q=dns; l=2443; t=1152252273; x=1153116273; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:comments=20on=20draft-ietf-sip-hop-limit-diagnostics-03; X=v=3Dcisco.com=3B=20h=3DA1WfTSLmhUwt7FfguMfgvK1OAZw=3D; b=i8aRrP6SGhj+XSs/tqMvHDwhbSt0zYifrQynXnGziym2kEYO6SGwm9fh9gznQzCeeqF4AbRC vla+o8lgOjxJ20SZUE/8IavgA3R/iEJpWTz/fbIuQh9bu7wcGz4yaAfv; Authentication-Results: sj-dkim-6.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Sip] comments on draft-ietf-sip-hop-limit-diagnostics-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org major issues: Well, no change here in these. I think we need more discussion on them: 1. I still think this mechanism is applicable outside of max-forwards violations. The current text limits it to 483. 2. I agree with Cullen that we do need to specify a size limit for the response. Having thought about it more, I'm worried that the sipfrag body can't be more than 200 bytes! Consider a request that loops a lot. At some point, the via header itself will grow sufficiently to cause the mesage to switch from udp to tcp. That happens at the point at which the udp request exceeds 1300 bytes. For a response to that request to be also sent over UDP with no fragmentation, the response cannot be larger than the request by more than 200 bytes. Now, you might argue that proxies often strip Via's, and that a small max-forwards might never get the request to pop over to tcp. However if you are looking for a safe value, its 200 bytes. Thsi might motivate us to look at something different to return the data to the client, rather than in that response. Another option is content indirection. minor issues: > The SIP protocol imposes a limit on the number of hops a request can > transit on the way to its destination. The number of hops remaining > for the request is carried in the Max-Forwards header, and is header field > request has traversed a series of proxies, the response follows the > Vias back to the requester - in the case of a typical 483 response it > can be difficult to determine even what server the response came same comment as on -02. Difficult implies that its possible, just hard. Its NOT possible. > A Warning header with a warn-code of 399 that identifies the > system returning the error. header field > If including all Via and Route headers is still too large, the > implementation SHOULD remove the oldest Vias (those nearest the > message originator) until the size is acceptable; the only exception > to this rule is when . when....? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 02:50:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyk97-00049X-3l; Fri, 07 Jul 2006 02:49:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyk95-00049Q-FJ for sip@ietf.org; Fri, 07 Jul 2006 02:48:59 -0400 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyk94-0005sP-VD for sip@ietf.org; Fri, 07 Jul 2006 02:48:59 -0400 Received: from Inbox ([89.205.157.243]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J2000KLKW60NJA0@jes-fe1.zx.nl> for sip@ietf.org; Fri, 07 Jul 2006 08:44:38 +0100 (WEST) Date: Fri, 07 Jul 2006 08:48:49 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] Outbound Comment: binding key To: Erkki.Koivusalo@nokia.com, HKaplan@acmepacket.com, adam@nostrum.com, fluffy@cisco.com Message-id: <0J2000KLLW61NJA0@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline Regards, jeroen -----Oorspronkelijk bericht ----- Van: Erkki.Koivusalo@nokia.com Aan: HKaplan@acmepacket.com; adam@nostrum.com; fluffy@cisco.com CC: sip@ietf.org Verzonden: 7-7-06 07:56 Onderwerp: RE: [Sip] Outbound Comment: binding key Hi, In March before Dallas meeting Jeroen raised the same question: > Some comments on this draft: > > Section 3.2 (and elsewhere): in addition to stating that a proxy/registrar > should prefer the most recently registered flow, I would suggest that the > registrar explicitly invalidates an existing registration when it receives a > new registration with the same instance-id / reg-id. This situation would > most likely be due to a reboot of the client. For TCP and other > connection-oriented transports it would be detected, but a registration over > UDP could survive a client crash And this is what Cullen answered: > This has been a topic of large debate and we (with many but not most people > saying exactly what you are saying). We asked about it in WG meeting and on > list and came to agreement that the text that does not allow "explicit > invalidation" was better. I'm scared to reopen this. I do not have a clue what kind of arguments were there in that old debate, but I admit I have been a couple of times wondering this same issue. It would be nice if someone would bring up the thread Cullen is referrng to. If changing the draft like you and Jeroen suggested I believe the draft SHOULD be more explicit about what happens to the old flows ? Will they stay in the registrar database forever ? After one year of operation, does the registrar have e.g. 27 mappings stored for one UA which has rebooted 27 times, even if the most recent of them is used ? [jvb] well,it would not get quite so bad;lifetimes are still bound by the expiry interval. But I don't see any benefit in keeping the mapping around.What is wrong with explicit invalidation? Regards, Erkki >-----Original Message----- >From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >Sent: 06.July.2006 22:08 >To: 'Adam Roach'; 'Cullen Jennings' >Cc: 'SIP WG' >Subject: RE: [Sip] Outbound Comment: binding key > >My interpretation was the opposite - if a Register comes in >with the same >{instance-id,reg-id} then it should indeed replace/overwrite >the previous >binding of the same tuple. I know there are several sections >in the draft >which imply otherwise, but I don't understand why. There is >no real value >I can see to keeping a binding for an old flow of the same >reg-id, since by >definition the UA would only "re-use" a reg-id if the old flow >failed (or >even if it didn't think it had failed, but something rebooted >and changed >the flow). > >I can see no realistic way in which an old flow of the same >{instance-id,reg-id} would succeed in reaching the UA. Am I missing >something? > >-hadriel >p.s. it's theoretically possible, if a sip-udp UA rebooted and >resolved a >new proxy address and sent a register to it with the same >reg-id, that it >may still be possible to reach the UA through the old "flow" >for a time. >But is that a realistic case worth caring about? > > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Thursday, July 06, 2006 1:12 AM >> To: Cullen Jennings >> Cc: SIP WG >> Subject: [Sip] Outbound Comment: binding key >> >> From section 6.1: >> >> When a reg-id header parameter is present in a Contact >header field >> value in a REGISTER request, the corresponding binding is >between an >> AOR and the combination of instance-id and reg-id. >> >> I don't think this is quite correct. This statement appears to be >> asserting that {instance-id,reg-id} is a unique key to a binding >> associated with an AOR. This would, in turn, imply that any >successful >> registration attempt with an {instance-id,reg-id} that matches an >> existing binding would overwrite the existing record. >> >> I don't think that is what's intended, since section 6.2 contains the >> following text: >> >> o If two bindings have the same instance-id and reg-id, the proxy >> SHOULD prefer the contact that was most recently updated. >> >> If the binding is only to {instance-id,reg-id}, then that text is >> nonsensical: you can't have two identical bindings to the same AOR. >> >> I suspect that the text in 6.1 should actually read >something more like: >> >> When a reg-id header parameter is present in a Contact >header field >> value in a REGISTER request, the corresponding binding is >between an >> AOR and the combination of instance-id, reg-id, and network flow. >> >> /a >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 03:14:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FykWS-0006hi-SF; Fri, 07 Jul 2006 03:13:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FykWR-0006hd-Mu for sip@ietf.org; Fri, 07 Jul 2006 03:13:07 -0400 Received: from jes-fe2.zx.nl ([194.187.76.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FykWQ-0008OI-Dw for sip@ietf.org; Fri, 07 Jul 2006 03:13:07 -0400 Received: from Inbox ([89.205.157.243]) by jes-fe2.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J20003Q1XOZRR80@jes-fe2.zx.nl> for sip@ietf.org; Fri, 07 Jul 2006 09:17:34 +0100 (WEST) Date: Fri, 07 Jul 2006 09:13:08 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 To: Miguel Garcia , Jonathan Rosenberg Message-id: <0J20003Q2XP1RR80@jes-fe2.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Cullen Jennings , sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline > Thats not my read. > > The draft says that a client has to support at least 2 outbound URI, and > that it MUST send a REGISTER for each. However, that doesn't mean a > domain *has* to provide two; it can also provide one. A domain would > only provide one if it knows that it doesn't need two for purposes of > reliability, or if it doesn't require reliability of service. True, but then the UA does not have an alternative outbound server, in case the supplied one fails. [jvb] you could still have multiple alternatives from DNS (ie traditional DNS that is) What I don't like is the one to one relation between the number of supplied outbound URIs and the number of flows (and REGISTER). [jvb] indeed, especially since the domain may have no control over how many URIs the client discovers. Manual entry is one example. And what happens if one URI comes via manual provisioning and 2 more via DNS as per outbound-discovery? Additionally I suspect that users may still impose local policies in the UAs as for the number of established flows, independently of the number of learned URIs. So, the MUST in the spec is always subject to local policy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 03:18:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FykZW-00073q-Rb; Fri, 07 Jul 2006 03:16:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FykZV-00073l-6V for sip@ietf.org; Fri, 07 Jul 2006 03:16:17 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FykZT-0000Qa-KV for sip@ietf.org; Fri, 07 Jul 2006 03:16:17 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k676sjmU002549; Fri, 7 Jul 2006 09:54:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 09:54:36 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 09:54:36 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on sip-outbound-04 Date: Fri, 7 Jul 2006 09:54:35 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0280E38C@esebe103.NOE.Nokia.com> In-Reply-To: <44AD8E8D.7090601@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on sip-outbound-04 Thread-Index: AcahS5/Fqs8a09orTESz8FDXGiQ2rQAQfT4Q From: To: , X-OriginalArrivalTime: 07 Jul 2006 06:54:36.0333 (UTC) FILETIME=[359BADD0:01C6A192] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >> When a UA is about to send a request, it first=20 >> performs normal processing to select the next hop URI. >> The UA performs normal DNS resolution on the next=20 >> hop URI (as described in RFC 3263 [RFC3263]) to=20 >> find a protocol, IP address, and port. For non-TLS=20 >> protocols, if the UA has an existing flow to this >> IP address, and port with the correct protocol, then=20 >> the UA MUST use the existing connection. =20 > >I'm pretty sure that this text would fundamentally require=20 >UA changes for any mid-dialog failover solution to work.=20 Mid-dialog failover is not the only case for which the referred piece of text has a problem. It also contains a clear bug at least when used literally for registration refreshes. For outbound to work correctly, UA must send the registration refresh over the same flow that was created when sending the initial registration to be refreshed. Currently the draft fails to mention this as I have earlier pointed out. RFC 3263 procedures DO NOT guarantee that when UA resolves once again the URI of the next hop (of the outbound proxy), it would result the same IP address which was received when resolving the same URI previously. If it is different IP address then another flow will be used, perhaps towards a totally different proxy as used earlier. UA should cache the DNS RRs it received when it resolved the URI the first time, so the problem is not whether the DNS server returns the same values or not. The failure can=20 happen if the domain has a number of SRV records with the same transport and priority values, but different weights (for load balancing reasons). a) RFC 3263 states that to resolve a SIP URI without a transport or port parameter, the UA will have to use NAPTR, SRV and address queries to get the IP address. b) RFC 2782 defines the weight for SRV RR as follows: A server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535. This is a 16 bit unsigned integer in network byte order. Domain administrators SHOULD use Weight 0 when there isn't any server selection to do, to make the RR easier to read for humans (less noisy). In the presence of records containing weights greater than 0, records with weight 0 should have a very small chance of being selected. In the absence of a protocol whose specification calls for the use of other weighting information, a client arranges the SRV RRs of the same Priority in the order in which target hosts, specified by the SRV RRs, will be contacted. The following algorithm SHOULD be used to order the SRV RRs of the same priority: To select a target to be contacted next, arrange all SRV RRs (that have not been ordered yet) in any order, except that all those with weight 0 are placed at the beginning of the list. Compute the sum of the weights of those RRs, and with each RR associate the running sum in the selected order. Then choose a uniform random number between 0 and the sum computed (inclusive), and select the RR whose running sum value is the first in the selected order which is greater than or equal to the random number selected. The target host specified in the selected SRV RR is the next one to be contacted by the client. Remove this SRV RR from the set of the unordered SRV RRs and apply the described algorithm to the unordered SRV RRs to select the next target host. Continue the ordering process until there are no unordered SRV RRs. This process is repeated for each Priority. When processing the SRV records as per RFC 3263, the UA may select different record each time, due to the randomness involved for selecting the order of SRV records to try. Even if the UA would cache the DNS records itself, nothing requires it to cache the ultimate result of RFC 3263 processing, so the result may be different IP address each time.=20 For legacy SIP this has not been a problem. The registrar (not to mention the proxy) could not care less if the registration refresh was routed over different edge proxy each time. However for outbound this would not cause the desired behaviour. I can identify at least two issues: 1. It is not clear how the UA should handle the flow related=20 to a registration if it swaps from one proxy to another. 2. If the UA has one primary and one secondary flow, it might happen that when refreshing the primary flow, the UA would accidentally move it to the same proxy towards which the secondary flow is going to. So redundancy would be lost. P.S. I tried to raise this issue already twice but because I did not get any clear response, I now do it once again as I will be out of office for the next few weeks. I hope that this time I was able to formulate the problem statement clearly enough for you to get the point. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 03:47:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyl24-0001hY-BS; Fri, 07 Jul 2006 03:45:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyl22-0001hT-Sp for sip@ietf.org; Fri, 07 Jul 2006 03:45:46 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyl22-0004N9-8l for sip@ietf.org; Fri, 07 Jul 2006 03:45:46 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k677jdSh017553; Fri, 7 Jul 2006 10:45:42 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 10:44:45 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 10:44:45 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Fri, 7 Jul 2006 10:44:44 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0280E401@esebe103.NOE.Nokia.com> In-Reply-To: <03ed01c6a144$5d3e9b70$a7c8000a@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on Outbound? Thread-Index: AcahJv9CfxXIXQ3YSVKFEMFG9cY2ZAACQAvgABn6xtA= From: To: , X-OriginalArrivalTime: 07 Jul 2006 07:44:45.0097 (UTC) FILETIME=[36F8A190:01C6A199] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, What Hadriel says here is in my opinion a clear reason why the outbound draft (instead of any other optional or additional draft) must have the safe check for the UA to ensure whether or not the=20 contacted proxy supports outbound: =20 >And it's not the same as just a new option-tag or header - this is a >backwards-compatibility breaker. There is no defined action for a >3261-compliant device to take when receiving such a binary message, is >there? It cannot "reject" it with a sip response, cannot make=20 >the UA stop >sending it, nor can the UA detect the proxy doesn't support it=20 >even if the >UA wanted to check. The UA will detect a keepalive loss, and try >"re-connecting" by re-registering and getting another keepalive loss, >indefinitely (although at least with back-off timers). > >Meanwhile the operator of this 3261-compliant proxy just got a headache >courtesy of the IETF. For each user who mistakenly checks some little >check-box which says whatever the vendor thought it should say for a >keepalive=3Dstun semantics the operator must take action to correct - = if >they're lucky. If they're unlucky, and their proxy silently=20 >discards the >stun, they'll wonder why some UAs can make/receive calls for=20 >~30 seconds, >then disappear, then come back, ad infinitum. And this is a=20 >bad kind of >failure to detect/fix, because a reboot makes it "work" for a=20 >short time. Another reason is embedded into this statement from Jonathan: > (3) constructed URIs.=20 > > On (3), this is definitely a possibility. However I think the best way > to mitigate is to say 'don't do that'. SIP-outbound can have some words=20 > which warn implementations that they MUST NOT insert this parameter into=20 > URI that they construct from a domain name. This suggestion seems to prevent the UA to use DHCP to discover and use a local SIP proxy even if such an outbound compliant proxy would exist. This does not sound a good idea to me. Regards, Erkki >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: Thursday, July 06, 2006 2:07 PM >> To: Jeroen van Bemmel >> Cc: Cullen Jennings; sip@ietf.org; dean.willis@softarmor.com; >> rohan@ekabal.com >> Subject: Re: [Sip] Ready for WGLC on Outbound? >>=20 >> inline. >>=20 >> Jeroen van Bemmel wrote: >>=20 >> > Cullen, >> > >> > The point is that these are really 2 separate issues: >> > 1. Discovering the set of outbound proxy URIs (with = keepalive=3Dstun >> > parameters in them) >> > 2. Confirming that a given proxy in the set actually=20 >supports outbound >> > (ie validating the keepalive=3Dstun information) >> > >> > Of these 2 options, (1) is indeed a separable problem. (2)=20 >- to me - is >> > not, for me outbound is not acceptable without something=20 >to address (2). >> > It really should say "the UAC MUST NOT use STUN until {=20 >mechanism for >> > (2) says its supported }" >>=20 >> I personally think that the presence of the keepalive=3Dstun=20 >attribute in >> the URI is sufficient of a "confirmation". The examples you=20 >and others >> have presented for why this is needed are (1)=20 >misconfiguration (someone >> gives a URI to the client which is incorrect in that it contains this >> flag when it shouldn't), (2) malicious users, (3)=20 >constructed URIs. On >> (2), let me point out that an attacker that can modify DNS=20 >or modify SIP >> messages (or whatever is used for the discovery function)=20 >can launch far >> more effective attacks than just adding keepalive=3Dstun in=20 >the hopes that >> it causes a low-quality proxy to crash. >>=20 >> On (1), misconfugration could potentially produce all kinds of things >> that would cause a client to send things to the server that=20 >might make >> it crash, including non-SIP URI, URI with invalid header parameters, >> etc. I don't see keepalive=3Dstun as special. >>=20 >> On (3), this is definitely a possibility. However I think=20 >the best way >> to mitigate is to say 'don't do that'. SIP-outbound can have=20 >some words >> which warn implementations that they MUST NOT insert this=20 >parameter into >> URI that they construct from a domain name. >>=20 >> Finally, let me say that if you have a proxy that crashes on=20 >receipt of >> binary messages on its sip port, you are in for real=20 >trouble. I think a >> far better solution is for proxy vendors to fix their proxies, rather >> than for us to bend over backwards to design new mechanisms that help >> protect such fragile servers from ever seeing these=20 >messages. No matter >> what we put in our specs, attackers can still send binary=20 >messages that >> will result in the same result you are trying to prevent. >>=20 >> Thanks, >> Jonathan R. >>=20 >>=20 >>=20 >>=20 >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany,=20 >NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 03:59:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FylDN-0002QV-Jy; Fri, 07 Jul 2006 03:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FylDM-0002QP-Ay for sip@ietf.org; Fri, 07 Jul 2006 03:57:28 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FylDL-0005Y9-10 for sip@ietf.org; Fri, 07 Jul 2006 03:57:28 -0400 Received: from [192.168.2.100] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k677x81D029395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jul 2006 02:59:08 -0500 Message-ID: <44AE14E2.6040700@softarmor.com> Date: Fri, 07 Jul 2006 03:01:38 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] Ready for WGLC on Outbound? References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> In-Reply-To: <17579.25760.584180.394914@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Cullen Jennings , sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Jeroen van Bemmel writes: > > > 2. Confirming that a given proxy in the set actually supports outbound (ie > > validating the keepalive=stun information) > > i don't understand this one. if a proxy is listed as an outbound proxy > (for example in the result returned from DNS), why can't we require that it > supports stun keepalives? What do you mean "require"? Use a proxy-require option tag? Or just hope it won't melt when you send it a STUN packet, meaning that you "require the operator to get it right". The problem as I see it is we have no way of easily detecting an error if somebody mistakenly lists a non-compliant proxy as an outbound proxy in DHCP or some other discovery mechanism. I hate leaping off a trapeze without a safety net . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 04:01:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FylFh-0002nq-5f; Fri, 07 Jul 2006 03:59:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FylFf-0002ni-RQ for sip@ietf.org; Fri, 07 Jul 2006 03:59:51 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FylFe-0005dj-H3 for sip@ietf.org; Fri, 07 Jul 2006 03:59:51 -0400 Received: from [192.168.2.100] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6781WH3029429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jul 2006 03:01:33 -0500 Message-ID: <44AE1573.6010702@softarmor.com> Date: Fri, 07 Jul 2006 03:04:03 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Ready for WGLC on Outbound? References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> In-Reply-To: <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Cullen Jennings , rohan@ekabal.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Cullen, > > The point is that these are really 2 separate issues: > 1. Discovering the set of outbound proxy URIs (with keepalive=stun > parameters in them) > 2. Confirming that a given proxy in the set actually supports outbound > (ie validating the keepalive=stun information) > > Of these 2 options, (1) is indeed a separable problem. (2) - to me - is > not, for me outbound is not acceptable without something to address (2). > It really should say "the UAC MUST NOT use STUN until { mechanism for > (2) says its supported }" > > There have been several options mentioned to do this, a simple way is to > have the edge proxy insert a flag. Question is: why not? I find that I've developed a great deal of sympathy for the above position. Discovery is indeed separable from error-detection (or confirmation, detecting "absence of error"). -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 04:14:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FylS4-00061D-R9; Fri, 07 Jul 2006 04:12:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FylS3-0005yA-9o for sip@ietf.org; Fri, 07 Jul 2006 04:12:39 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FylS0-0007yz-PN for sip@ietf.org; Fri, 07 Jul 2006 04:12:39 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F16AA6E0002; Fri, 7 Jul 2006 10:12:31 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 10:12:31 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 10:12:31 +0200 Received: from [131.160.36.38] (EH3I2003TGFCPET.lmf.ericsson.se [131.160.36.38]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3858F235F; Fri, 7 Jul 2006 11:12:31 +0300 (EEST) Message-ID: <44AE176E.3000105@ericsson.com> Date: Fri, 07 Jul 2006 11:12:30 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> In-Reply-To: <44ADF80B.2000204@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 08:12:31.0335 (UTC) FILETIME=[18205F70:01C6A19D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Cullen Jennings , sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, > True, but then the UA does not have an alternative outbound server, in > case the supplied one fails. What I don't like is the one to one > relation between the number of supplied outbound URIs and the number of > flows (and REGISTER). using a SHOULD instead of a MUST would break this coupling, which would give more freedom to the UA in order to decide how many flows it wants to establish (maybe the terminal does not want high reliability). If things do not break, a SHOULD is more appropriate than a MUST. Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 05:57:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyn3q-00061H-W8; Fri, 07 Jul 2006 05:55:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyn3n-0005uY-JU for sip@ietf.org; Fri, 07 Jul 2006 05:55:43 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyn3k-0000g6-Pb for sip@ietf.org; Fri, 07 Jul 2006 05:55:43 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k679tZQx017300; Fri, 7 Jul 2006 12:55:38 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 12:55:33 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 12:55:33 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] an alternative approach for outbound proxy discovery Date: Fri, 7 Jul 2006 12:55:32 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02840581@esebe103.NOE.Nokia.com> In-Reply-To: <44AD6E48.2030302@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] an alternative approach for outbound proxy discovery Thread-Index: AcahRK9Ds15cTNQPQw+W2c5UsO8LfwAVa0IA From: To: , X-OriginalArrivalTime: 07 Jul 2006 09:55:33.0446 (UTC) FILETIME=[7CF3A660:01C6A1AB] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, >The idea is to not use DNS, but rather use SIP mechanisms for the=20 >discovery. I much prefer a non-DNS solution for several reasons which=20 >I'll enumerate below. The basic mechanism combines two things: > >1. usage of the 305/service-route as I have proposed in=20 >http://www.ietf.org/internet-drafts/draft-rosenberg-sip-route-c >onstruct-01.txt > >2. usage of a new header field in REGISTER responses which specifies=20 >additional URI to try REGISTERing to Sounds a nice idea as it has all those good properties that you mentioned, but it is not without some drawbacks and open issues. One difficulty is that such a solution would require the service=20 provider to upgrade also the home proxies when starting to=20 deploy outbound, instead of just upgrading the edge proxies=20 and registrar. There would be no hope of autodiscovery without such a network upgrade. For the DNS based solution what would be needed is just a reconfiguration of the DNS server together with the UAs which implement the procedures. No software upgrade would be needed for any server in the network. For the technical point of view I have the following questions: Most importantly, how can the UA make sure what is the situation if it does not receive 305 response or 200 OK with Additional- Proxies for the REGISTER ? - Was it so that the contacted proxy supports outbound and the network does not require the UA to contact any additional proxy, so that everything is fine when receiving 200 OK that=20 does not contain Additional-Proxies header ? In this case the UA can perfectly well start sending STUN keepalives towards the proxy. - Or was it so that the proxy supports neither outbound nor this new optional draft and therefore did not return 305=20 or Additional-Proxies header ? In this case UA could make a false assumption and continue using outbound even if that would not work. So I assume that 200 OK header would always have to contain=20 some indication whether or not the proxy supports outbound, right ? This is already being discussed in another thread but your idea would add one another reason for mandating such an indication within outbound draft. >So, here is the idea. UA starts with its AOR (sip:user@example.com)=20 >for example, or with a domain name learned from DHCP. In either case,=20 >it applies RFC3263 and gets the URI for a proxy. This is going to=20 >be the home proxy. In my understanding the main motivation for using DHCP for the SIP proxy discovery is to find a local proxy instead of the home proxy. Home proxy could always be found by resolving the AOR. I am not totally sure if your idea was relying on an assumption=20 that the UA would always try contacting the home proxy at first. Anyway that is not always the case. Mobile clients like laptop PCs and mobile phones could be attached to a network anywhere in the world, even in different continent than the one where the home proxy or edge proxies for a domain are located. In those cases the UA would probably prefer using a local proxy, if available, rather than the remote edge proxy of user's home domain. DHCP is used to find such a local proxy. The discovered local proxy may or may not support outbound: - In the case it supports the proxy has to indicate the=20 support to the UA in 200 OK as told above. - In case it does not support the proxy should redirect. However is it certain for such a proxy that the UA needs outbound support ? The UA does not send Proxy-Require header or anything like that to tell the local proxy about what it needs. Can such a local proxy rely on this kind of hints what you outlined below ? >UA sends a REGISTER request. The proxy receives this, and=20 >knows that it doesn't accept REGISTER directly like this;=20 >it needs to be sent via an edge proxy. There are many ways=20 >the proxy can know it got the REGISTER directly and not=20 >through an EP. For example, requests from EP come to a=20 >different port, or better yet, via TLS mutual auth from=20 >edge proxy. Regards, Erkki=20 >-----Original Message----- >From: ext Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 >Sent: 06.July.2006 23:11 >To: IETF SIP List >Subject: [Sip] an alternative approach for outbound proxy discovery > >I want to suggest a possible alternative approach for outbound proxy=20 >discovery than the one in draft-koivusalo-sip-outbound-discovery. So,=20 >before I get to it, two caveats: > >1. I am NOT proposing that this be added to sip-outbound, and I'm not=20 >suggesting that a normative reference to this or another mechanism=20 >should be in outbound. I believe that any discovery mecanism should be=20 >orthogonal, and what I am about to propose below is orthogonal as well. > >2. I have not been able to follow all of the nearly countless messages=20 >on sip-outbound, so I'm not sure if what I'm about to propose has been=20 >proposed. So, please point me to relevant threads if it has been > > >The idea is to not use DNS, but rather use SIP mechanisms for the=20 >discovery. I much prefer a non-DNS solution for several reasons which=20 >I'll enumerate below. The basic mechanism combines two things: > >1. usage of the 305/service-route as I have proposed in=20 >http://www.ietf.org/internet-drafts/draft-rosenberg-sip-route-c >onstruct-01.txt > >2. usage of a new header field in REGISTER responses which specifies=20 >additional URI to try REGISTERing to > >So, here is the idea. UA starts with its AOR=20 >(sip:user@example.com) for=20 >example, or with a domain name learned from DHCP. In either case, it=20 >applies RFC3263 and gets the URI for a proxy. This is going to be the=20 >home proxy, and there is no keepalive=3Dstun and thus no STUN = keepalives=20 >here yet. UA sends a REGISTER request. The proxy receives this, and=20 >knows that it doesn't accept REGISTER directly like this; it=20 >needs to be=20 >sent via an edge proxy. There are many ways the proxy can know it got=20 >the REGISTER directly and not through an EP. For example,=20 >requests from=20 >EP come to a different port, or better yet, via TLS mutual auth from=20 >edge proxy. > >So, home proxy redirects the request with a 305. The URI in=20 >the contact=20 >header field is an edge proxy, and has the keepalive=3Dstun parameter = in=20 >it. Now, this URI can be a specific IP address, or more=20 >interestingly, a=20 >hostname that resolves to any number of proxies. This=20 >basically becomes=20 >the first proxy in the outbound proxy set. If its a hostname, client=20 >performs regular old RFC3263 and picks one. Client sends a request=20 >there, now with the topmost Route set equal to this URI (this=20 >is what I=20 >have proposed for 305 handling in route-construct). > >This arrives at the edge proxy, which inserts itself into=20 >Path, which is=20 >subsequently reflected into Service-Route, which the proxy can=20 >modify on=20 >its way towards the client (again this is what I have proposed in=20 >route-construct). This Service-Route points to that edge proxy. > >Now, the UA has a single proxy (so far) in that outbound proxy set.=20 >However, that 200 OK to the REGISTER, in addition to having a=20 >Service-Route, would also have another header field, called=20 >Additional-Proxies or something like that. This header field would=20 >contain one or more URI pointing to proxies that the client should=20 >register additional flows through. For each of those, the client=20 >performs a registration (each of those URI would be the topmost route=20 >header field in a REGISTER message, each for a different reg-id). Now,=20 >it a multiplicity of flows and outbound proxies all set up. > >The primary benefit of this mechanism over a DNS one is its dynamic=20 >nature. The edge proxy which receives the original REGISTER=20 >request and=20 >response is the one that inserts the Additional-Proxies header field.=20 >Thus, it can purposefully choose a specific proxy acting as=20 >its backup,=20 >or choose a proxy in a different geographic region, or whatever. These=20 >choices can differ from user to user. The original REGISTER=20 >requests can=20 >be load balanced across all of the proxies in a cluster as a=20 >consequence=20 >of DNS, but the second flow is selected explicitly by the first proxy. > >This also lends itself extremely well to mid-dialog failover=20 >solutions,=20 >since the backup proxy is selected by the primary. Thus, it can choose=20 >one to which it is replicating state. It also allows for a variety of=20 >algorithms in selecting a record-route value. > >With this mechanism, it is clear how the provider chooses the=20 >number of=20 >flows that a UA makes - its an additional one for each value of the=20 >Additional-Proxies header field. > >It also allows us to keep the existing meaning of DNS queries,=20 >which are=20 >meant to choose a single server and not learn a set of servers=20 >that all=20 >must be contacted. > >There is a cost of a single extra round trip for the very=20 >first REGISTER=20 >to be redirected. However, I do not view this as particularly onerous. > >Thanks, >Jonathan R. > > > >--=20 >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Cisco Fellow Parsippany, NJ=20 >07054-2711 >Cisco Systems >jdrosen@cisco.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.cisco.com > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 06:51:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fynu5-0004Ef-6L; Fri, 07 Jul 2006 06:49:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fynu3-0004CN-CB for sip@ietf.org; Fri, 07 Jul 2006 06:49:43 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fynu1-0007Qi-AP for sip@ietf.org; Fri, 07 Jul 2006 06:49:43 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 36AB220611 for ; Fri, 7 Jul 2006 16:17:03 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 23E4C205DD for ; Fri, 7 Jul 2006 16:17:03 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 16:19:39 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] FW: I-D ACTION:draft-audet-sip-sips-guidelines-02.txt Date: Fri, 7 Jul 2006 16:22:44 +0530 Message-ID: <532B18E13CF9E64380EF5FDDE265E0711A0D55@blr-m2-msg.wipro.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0B23FEB3@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] FW: I-D ACTION:draft-audet-sip-sips-guidelines-02.txt Thread-Index: AcaaIz5/khYAgAW9TfW7ALjWiplN7gFqCEAwAHnkrTA= From: To: , X-OriginalArrivalTime: 07 Jul 2006 10:49:39.0036 (UTC) FILETIME=[0B7961C0:01C6A1B3] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Comment on content of Section 3: TLS MAY be used between Proxy B and UA b@B, depending on local policy. Because B is responsible for it's own security policy inside it's own domain, it could use some other security mechanism. For example, it could be using IPsec, or some lower-layer security mechanism. It is not just B that needs security, it might be A who wants the security too. A might decide not to call B if there were no SIPS. Thus it might not be ok to leave the decision to B to decide if he wants to use TLS. -- =20 Ravishankar. G. Shiroor Wipro Technologies, Bangalore. =20 ravishankar.shiroor@wipro.com -- =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Wednesday, July 05, 2006 6:09 AM > To: IETF SIP List > Subject: [Sip] FW: I-D ACTION:draft-audet-sip-sips-guidelines-02.txt >=20 > Another update, including more feedback from the list. >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, June 27, 2006 12:50 > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-audet-sip-sips-guidelines-02.txt > >=20 > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > >=20 > > Title : Guidelines for the use of the SIPS=20 > > URI Scheme in the Session Initiation Protocol (SIP) > > Author(s) : F. Audet > > Filename : draft-audet-sip-sips-guidelines-02.txt > > Pages : 24 > > Date : 2006-6-27 > > =09 > > This document provides clarifications and guidelines concerning the > > use of SIPS URI Scheme in the Session Initiation Protocol (SIP). > >=20 > > A URL for this Internet-Draft is:=20 > > http://www.ietf.org/internet-drafts/draft-audet-sip-sips-guide > lines-02.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-audet-sip-sips-guidelines-02.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-audet-sip-sips-guidelines-02.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 09:22:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyqFi-0007OJ-CB; Fri, 07 Jul 2006 09:20:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyqFg-0007OE-S0 for sip@ietf.org; Fri, 07 Jul 2006 09:20:12 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyqFf-00085I-AV for sip@ietf.org; Fri, 07 Jul 2006 09:20:12 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k67DK9xm007972; Fri, 7 Jul 2006 08:20:09 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ943KX>; Fri, 7 Jul 2006 14:20:08 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369D630@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Jonathan Rosenberg'" , "'Scott Lawrence'" Subject: RE: [Sip] draft-ietf-sip-hop-limit-diagnostics-03 Date: Fri, 7 Jul 2006 14:20:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: 'SIP WG List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We'd also get pretty much the same thing by using the "by reference" mechanism in draft-ietf-sip-location-conveyance. The server sends a URI to some location where the diagnostic information is placed. All the issues that exist have to be handled for location-conveyance with that mechanism. Out of interest, for Jonathan's proposal, on networks where we're running on the verge of hop limit expiries for all requests, don't we tend to some form of amplification situation. The server sends the 4xx response plus a new request with the diagnostic information. A certain percentage (because they took slightly longer paths) of the new requests hit the hop limit in the reverse direction and send 4xx back to the original server plus a request containing the diagnostic inforation, etc, etc. Of course, on properly configured networks... regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 07 July 2006 06:45 > To: Scott Lawrence > Cc: Cullen Jennings; SIP WG List > Subject: Re: [Sip] draft-ietf-sip-hop-limit-diagnostics-03 > > > inline. > > Scott Lawrence wrote: > > > On Mon, 2006-06-26 at 09:00 -0700, Cullen Jennings wrote: > > > >>On Jun 16, 2006, at 2:59 PM, Scott Lawrence wrote: > >> > >> > >>>There are, I think, two issues remaining for discussion: > >> > >>I disagree - I don't think the draft of the discussion has > addressed > >>the issue I brought up. > > > > > > I'm going to guess here - do you mean the issue of how large the > > response should be? > > > > There is text in the draft on _how_ to reduce the size of > the response. > > > > 3261 does not provide guidance clear guidance on response > size limits. > > It _does_ say that all implementations MUST be able to > handle messages > > up to the maximum UDP packet size, which can probably > handle even 70 hop > > messages. If you think that SIP needs better definition of > _when_ to > > limit response sizes and _what_ size they should be limited > to, then I > > think that's an interesting discussion, but it's a bigger > question than > > this error response and a problem that already exists > whether this draft > > is accepted or not. > > > > Well, here is the history. > > The transport design of SIP was based on the model that the response > used the same transport as the request. We had the somewhat > naive view > that the response wouldn't be much larger than the request. > So, we would > take the MTU, subtract off a few hundred bytes to account for any > possible increase in the size of the response, and that should be OK. > > So, the implied limit is the path MTU itself, or 1500 bytes > if unknown. > But this is not stated explicitly, its implicit from the design. > > One idea on dealing with the size problem is, instead of > including the > sip-frag in a response, the resposne just indicates that the > hop limit > was exceeded. The server which generated the response then sends a > request in a totally new transaction, towards the contact of the > request. That request contains the sip-frag with all of the > information, > and could be sent over TCP if needed. > > That idea doesn't work for requests which omit contact, and > also means > that intermediate proxies on the path of the failed request might not > see the diagnostic information, since it would come over a different > transaction. > > Anyway, just a thought. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 11:25:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysAl-0004IO-FH; Fri, 07 Jul 2006 11:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyryu-0002Ve-8k for sip@ietf.org; Fri, 07 Jul 2006 11:11:00 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyrqx-0002m1-A9 for sip@ietf.org; Fri, 07 Jul 2006 11:02:49 -0400 Received: from [131.161.248.89] (open-131-161-248-89.cliq.com [131.161.248.89]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k67F2fF15089; Fri, 7 Jul 2006 08:02:41 -0700 In-Reply-To: <44ADF80B.2000204@nokia.com> References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Fri, 7 Jul 2006 08:02:47 -0700 To: Miguel Garcia X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Miguel, On Jul 6, 2006, at 22:58, Miguel Garcia wrote: >>> Then... why can't a domain indicate just one outbound URI? At the >>> moment the draft has an artificial lower limit for all the domains >>> to provide two URIs and impose a reliability that might not be >>> required/needed. >> Thats not my read. >> The draft says that a client has to support at least 2 outbound URI, >> and that it MUST send a REGISTER for each. However, that doesn't mean >> a domain *has* to provide two; it can also provide one. A domain >> would only provide one if it knows that it doesn't need two for >> purposes of reliability, or if it doesn't require reliability of >> service. > > True, but then the UA does not have an alternative outbound server, in > case the supplied one fails. What I don't like is the one to one > relation between the number of supplied outbound URIs and the number > of flows (and REGISTER). There is a difference from a flow failing to a particular server and an outbound URI failing. If you only provide a single URI, its trivial to make the single URI have several SRV entries pointing to separate actual servers. > Additionally I suspect that users may still impose local policies in > the UAs as for the number of established flows, independently of the > number of learned URIs. So, the MUST in the spec is always subject to > local policy. The spec currently says that UAs MUST support a minimum of 2 flows. If they don't open the two flows, the mechanism is broken since the UA can lose inbound messages for several minutes. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 11:27:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysDT-0000sZ-8h; Fri, 07 Jul 2006 11:26:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysDR-0000sU-UX for sip@ietf.org; Fri, 07 Jul 2006 11:26:01 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FysDP-0005U1-HI for sip@ietf.org; Fri, 07 Jul 2006 11:26:01 -0400 Received: from [131.161.248.89] (open-131-161-248-89.cliq.com [131.161.248.89]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k67FPqF16204; Fri, 7 Jul 2006 08:25:52 -0700 In-Reply-To: <00d801c6a140$f4e7f920$31713b51@BEMBUSTER> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <44AD5137.4050601@cisco.com> <44AD621A.301@cisco.com> <009b01c6a13c$15b2b1e0$31713b51@BEMBUSTER> <44AD791A.5070704@cisco.com> <00d801c6a140$f4e7f920$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6ce5e2217cc2dc449693a634f7644930@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Fri, 7 Jul 2006 08:25:46 -0700 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen, On Jul 6, 2006, at 14:12, Jeroen van Bemmel wrote: > [ snap ] >> Jonathan wrote >> >> I'm not objecting to the concept of this check. I just think its not >> necessary, something that might be optional at best. As such, if >> folks decide they want something, it can go in another draft. I dont >> think we need to burden sip-outbound with this. > > The trouble is, once outbound is "out" any mechanism defined in a > separate draft won't work as good. Because then there will be clients > that simply ignore the flag. Why is this anymore likely for clients that implement outbound? What is the motivation for clients to ignore the flag? If they ignore the flag and send STUN requests anyway against the they trash their own proxy. That is not in the interest of the client vendor. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 11:31:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysGg-0001PW-Vw; Fri, 07 Jul 2006 11:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysGg-0001PR-0i for sip@ietf.org; Fri, 07 Jul 2006 11:29:22 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FysGe-0005b5-Jz for sip@ietf.org; Fri, 07 Jul 2006 11:29:21 -0400 Received: from [192.168.0.102] (ppp-70-249-144-63.dsl.rcsntx.swbell.net [70.249.144.63]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k67FRtWX092341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jul 2006 10:27:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44AE7D81.9080100@nostrum.com> Date: Fri, 07 Jul 2006 10:28:01 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Ready for WGLC on Outbound? References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> <44AE14E2.6040700@softarmor.com> In-Reply-To: <44AE14E2.6040700@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.144.63 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Cullen Jennings , sip@ietf.org, Juha Heinanen , rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > The problem as I see it is we have no way of easily detecting an error > if somebody mistakenly lists a non-compliant proxy as an outbound > proxy in DHCP or some other discovery mechanism. I hate leaping off a > trapeze without a safety net . . . You mean like sending SIP to an address and port just because DNS resolution leads you to believe that address and port is ready to receive SIP? But what if someone misconfigures their DNS and accidentally resolves a request for the SIP service to their SMTP port? At some point, we need to trust that system administrators have a couple of brain cells to rub together; that they can notice when they've misconfigured their systems; and that they will take corrective measures when things fail to work. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 11:54:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysdQ-0004aI-Qf; Fri, 07 Jul 2006 11:52:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FysdP-0004aD-5Z for sip@ietf.org; Fri, 07 Jul 2006 11:52:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FysKn-0005is-Pz for sip@ietf.org; Fri, 07 Jul 2006 11:33:37 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FysDq-0005hw-VW for sip@ietf.org; Fri, 07 Jul 2006 11:26:29 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k67FQIja022967; Fri, 7 Jul 2006 09:26:19 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on draft-johns-sip-outbound-middialog-draft-00 Date: Fri, 7 Jul 2006 09:26:18 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-johns-sip-outbound-middialog-draft-00 Thread-Index: AcahTVfqj8m7P9DMQlSII62IFF33kgAiyxqQ From: "Kevin Johns" To: "Jonathan Rosenberg" , "IETF SIP List" X-Approved: ondar X-Spam-Score: -1.9 (-) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, Thanks for taking the time to read the draft and provide comments. To your first point, I agree this is a problem but do not think it is limited to the approach I propose. Thinking about it some more, I think the same security risk is present in the current outbound procedures. For your use case, the edge proxy will create a new flow II however, the registrar will replace the existing registration with the new one given that the instance ID and reg-ID match an existing registration. This will essentially have the same effect of hijacking incoming calls. The only way I could think of to mitigate this is through the authentication framework. If the registrar challenges the registration requests it can verify that a user is allowed to register a given AOR. If it is allowed, then the malicious user is hijacking the registration from themselves. If they are not allowed to register against a given AOR then the registration request should fail and protect from malicious users. As for your second point, I will need to go back and read your proposal. My initial thought was that this was configured and managed via the service provider. Thanks again for the comments. Kevin -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Thursday, July 06, 2006 4:41 PM To: IETF SIP List Subject: [Sip] comments on draft-johns-sip-outbound-middialog-draft-00 Kevin, Thanks for taking a crack at this. The mid-dialog case is a nasty hard problem and one we really do need to solve. I'm not sure the mechanism you propose has the necessary security properties, however. The attack I'm worried about is where an attacker, who is a valid but malicious user in the system, registers to the network and includes an instance ID and reg-id matching that of another user, the target. In this case, the edge proxy creates the same flow ID, and probably replaces the binding between that flow ID and the flow on which the register was received. Thus, an attacker will hijack incoming calls targeted for the target. Another big part of the problem is how the edge proxies construct a URI whose domain part happens to resolve to the actual two proxies which happen to be the ones that the client registered through. With current sip-outbound neither edge proxy knows what the other edge proxy is, so how could you construct such a URI? (note I've just posted an alternative solution for outbound discovery which will make this possible). Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 12:35:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FytGp-0006BA-7H; Fri, 07 Jul 2006 12:33:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FytGn-0006B5-Fk for sip@ietf.org; Fri, 07 Jul 2006 12:33:33 -0400 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FytGl-0003WT-Qf for sip@ietf.org; Fri, 07 Jul 2006 12:33:33 -0400 Received: from Inbox ([84.241.215.71]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J21004WNN8HRP50@jes-fe1.zx.nl> for sip@ietf.org; Fri, 07 Jul 2006 18:29:20 +0100 (WEST) Date: Fri, 07 Jul 2006 18:33:34 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] Ready for WGLC on Outbound? To: Adam Roach Message-id: <0J21004WON8JRP50@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Adam, I hear what you're saying - one cannot even begin to list every possible way in which things could go wrong, let alone implement preventive measures However, this case is different. 1) there is a simple solution that can avoid much pain and 2) What you describe below is relatively easy to diagnose (mail server receiving SIP). For outbound, what you will see is UAs that re-register every 90 seconds or so. Try detecting that, and then relating that to a DNS configuration error which is not apparent from only inspecting the DNS config 3) There are multiple config mechanisms. DNS is setup by (relative) professionals, but eg manual config is much more error prone (and nothing can be assumed about future mechanisms) People used to think that 32 bits would be plenty,and look where that's gotten us. Now is the moment to say "if the topmost Route URI contains a 'keepalive=stun' parameter, an edge proxy MUST copy this parameter into the Path URI that it inserts". One simple sentence to prevent all sorts of trouble Regards, Jeroen -----Oorspronkelijk bericht ----- Van: "Adam Roach" Aan: "Dean Willis" CC: "Cullen Jennings" ; sip@ietf.org; "Juha Heinanen" ; rohan@ekabal.com Verzonden: 7-7-06 17:28 Onderwerp: Re: [Sip] Ready for WGLC on Outbound? Dean Willis wrote: > The problem as I see it is we have no way of easily detecting an error > if somebody mistakenly lists a non-compliant proxy as an outbound > proxy in DHCP or some other discovery mechanism. I hate leaping off a > trapeze without a safety net . . . You mean like sending SIP to an address and port just because DNS resolution leads you to believe that address and port is ready to receive SIP? But what if someone misconfigures their DNS and accidentally resolves a request for the SIP service to their SMTP port? At some point, we need to trust that system administrators have a couple of brain cells to rub together; that they can notice when they've misconfigured their systems; and that they will take corrective measures when things fail to work. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 12:49:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FytUH-0008Gg-MP; Fri, 07 Jul 2006 12:47:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FytUF-0008GX-N9 for sip@ietf.org; Fri, 07 Jul 2006 12:47:27 -0400 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FytUE-0006DN-Dw for sip@ietf.org; Fri, 07 Jul 2006 12:47:27 -0400 Received: from Inbox ([84.241.215.71]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J210041TNVQRP60@jes-fe1.zx.nl> for sip@ietf.org; Fri, 07 Jul 2006 18:43:15 +0100 (WEST) Date: Fri, 07 Jul 2006 18:47:29 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] Ready for WGLC on Outbound? To: Rohan Mahy Message-id: <0J210041UNVSRP60@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan, Clients ignoring the flag would not do so on purpose, but simply because they would not know about it (ie only implementing outbound and not the separate extension). By making it part of outbound it becomes atomic: either the client does both STUN and "crash prevention", or neither of these. That is the only way to make it safe Regards , Jeroen -----Oorspronkelijk bericht ----- Van: "Rohan Mahy" Aan: "Jeroen van Bemmel" CC: dean.willis@softarmor.com; "Cullen Jennings" ; "Rohan Mahy" ; "Jonathan Rosenberg" ; "Anders Kristensen" ; sip@ietf.org Verzonden: 7-7-06 17:25 Onderwerp: Re: [Sip] Ready for WGLC on Outbound? Jeroen, On Jul 6, 2006, at 14:12, Jeroen van Bemmel wrote: > [ snap ] >> Jonathan wrote >> >> I'm not objecting to the concept of this check. I just think its not >> necessary, something that might be optional at best. As such, if >> folks decide they want something, it can go in another draft. I dont >> think we need to burden sip-outbound with this. > > The trouble is, once outbound is "out" any mechanism defined in a > separate draft won't work as good. Because then there will be clients > that simply ignore the flag. Why is this anymore likely for clients that implement outbound? What is the motivation for clients to ignore the flag? If they ignore the flag and send STUN requests anyway against the they trash their own proxy. That is not in the interest of the client vendor. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 13:09:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fytnb-0005xK-A1; Fri, 07 Jul 2006 13:07:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fytna-0005xE-Bj for sip@ietf.org; Fri, 07 Jul 2006 13:07:26 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FytnY-0008SQ-U0 for sip@ietf.org; Fri, 07 Jul 2006 13:07:26 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DA0DE6E0002; Fri, 7 Jul 2006 19:06:50 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 19:06:50 +0200 Received: from [136.225.183.104] ([136.225.183.104]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 19:06:48 +0200 From: "Christer Holmberg" To: "Rohan Mahy" , "Miguel Garcia" Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Fri, 7 Jul 2006 20:06:57 +0300 Message-ID: <5lMhySMZNSts.P4yLcZSr@se-smtp.ericsson.se> X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 07 Jul 2006 17:06:50.0305 (UTC) FILETIME=[BCC2FB10:01C6A1E7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org IHi, What if the client only gets IP address(es) of the edge proxy? Is each = address treated as a URI? As I've said earlier, a SIP URI is something the client creates, but it = does not necessarily be what is configured (given as input, manually or = using some other mechanism). I've also indicated that there may be other mechanisms than "multi flow" to = provide reliability. So, in those cases multiple flows may not be needed, = but one may still want to use outbound. Note tha I am NOT arguing against saying that a client must support the = establishment of two flows. Also, if a client uses STUN keepalive, but not the rest of outbound = (instance-id etc) it would not make sense trying to send multiple = registrations, since the registrar would not be able to differentiate the = "flows". I think that needs to be clear in the spec, a part of defining the = STUN keepalive as a standalone function. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 13:49:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyuQc-00037w-Dx; Fri, 07 Jul 2006 13:47:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyuQb-00037r-1F for sip@ietf.org; Fri, 07 Jul 2006 13:47:45 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyuQZ-0002Jg-Kh for sip@ietf.org; Fri, 07 Jul 2006 13:47:45 -0400 Received: (qmail 5587 invoked by uid 0); 7 Jul 2006 17:47:36 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 7 Jul 2006 17:47:36 -0000 Message-ID: <002c01c6a1ed$6e8726f0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" , "Miguel Garcia" References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com><44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Fri, 7 Jul 2006 19:47:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan, >> Additionally I suspect that users may still impose local policies in the >> UAs as for the number of established flows, independently of the number >> of learned URIs. So, the MUST in the spec is always subject to local >> policy. > > The spec currently says that UAs MUST support a minimum of 2 flows. If > they don't open the two flows, the mechanism is broken since the UA can > lose inbound messages for several minutes. > OK, let me try to see if I understand where this "several minutes" comes from, and if we could quantify "broken" here. Assuming that the client uses the default keepalive timer values (UDP: 24..29 seconds, TCP: 95..120 seconds), I deduce that worst case a client using only one flow could loose its registration status for a period of 120 seconds (on average, this would be only 60 seconds). So your "several" equals 2 ? One could probably calculate the chance that in this window a request would come in (given message rate assumptions, etc). Multiply that with the chance at flow failure (given component MTBF figures etc), and you would have the kind of reliability one would have for one flow only. Call that reliability R My question now is: what are reasonable assumptions for these figures, and could it be that for some clients, R could be sufficient? Intuitively I say: yes, that's possible. There exist clients and users that would be happy with a scheme that is broken for (1-R) part (I know at least one - me). There is currently nothing in the requirements regarding reliability. Section 4.4 mentions the relationship between timer values and server load, and has some text on "the expected time that a user may not receive inbound communications"; but not in relation to the number of flows (nor does it mention to de-synchronize keepalive timers across multiple flows). Do we need that, perhaps with some sample quantitative analysis? Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 15:31:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyw1F-000254-T0; Fri, 07 Jul 2006 15:29:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyw1E-00024z-W0 for sip@ietf.org; Fri, 07 Jul 2006 15:29:40 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyw1D-0003ww-Ha for sip@ietf.org; Fri, 07 Jul 2006 15:29:40 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2006 12:29:37 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,218,1149490800"; d="scan'208"; a="31477139:sNHT27718752" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k67JTbnb016749 for ; Fri, 7 Jul 2006 15:29:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k67JTbVM024456 for ; Fri, 7 Jul 2006 15:29:37 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 15:29:37 -0400 Received: from [161.44.34.230] ([161.44.34.230]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 15:29:37 -0400 Message-ID: <44AEB61F.2020108@cisco.com> Date: Fri, 07 Jul 2006 15:29:35 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 19:29:37.0099 (UTC) FILETIME=[AEF801B0:01C6A1FB] DKIM-Signature: a=rsa-sha1; q=dns; l=5794; t=1152300577; x=1153164577; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:comments=20on=20draft-ietf-sip-saml-00 |To:IETF=20SIP=20List=20; X=v=3Dcisco.com=3B=20h=3D+HYqUrN72KkHPG2lEm0v0wjGDmE=3D; b=rAZLsE0gyWYFPU50x5R2ntTvuUVgv4f7hr2FPq2veBhPM7KyXyc9qyr9Wm7eArq3oEx+bPvR BEcoOJPFaIV2CGl5f/XPXyJxsIyV6v0e05MuBdUJi8W08jr7zjNFotDG; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Subject: [Sip] comments on draft-ietf-sip-saml-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Overall, this is a HUGE improvement over draft-tschofenig-sip-saml-04, which is the last version I read (I see that -05 was similar to draft-ietf-sip-saml). This looks like a viable solution overall, and I like how it dovetails with sip-identity. Major comments: * I'm a little worried that the SAML assertion itself doesn't include any content from the SIP message which clearly limits its scope of applicability to the request. You are relying on authentication via sip-identity for that, but there are attacks where this won't work. For example, consider a rogue proxy or MITM which sees a SIP request fly by. The AS was executed by an upstream proxy, so this request has an Identity and Identity-Info header field. The proxy modifies the Indentity-Info header field, which contains a URL to an older assertion generated by the AS for the same subject, say, for a previous call it just made. This is not a major threat, but there may be others like it. Is there harm in including things like call-id, contact and other parameters into the saml assertion so they are signed too? * I'm not clear on how this mechanism works with older sip-identity implementations. The main issue is whether the URI in the identity-info header field will return just a certificate, as specified in sip-identity, or whether it returns a saml assertion. An older sip-identity verifier will expect a certificate but it will get an assertion if the AS implements sip-saml. Perhaps you are assuming that the Accept headers or something are used for this? Somehow this needs to be handled. > 6.1.4.1.3. Element: > > The element SHOULD contain an > element, which itself SHOULD contain an element. The > value of the element SHOULD be the same as the addr-spec > of the SIP request's To header field. Hmm. Here is our infamous retargeting problem again. If the request is retargeted, does this mean that the assertion cannot be used by the forwarded party? This restriction doesn't exist for normal sip-identity. Minor comments: > The scope of this specification is: > > o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such > that a subject's profile attributes, and their domain's > certificate, can be conveyed to a relying party using SAML. In > doing so, satisfy the requirements outlined in [I-D.ietf-sipping- > trait-authz], and compose with [I-D.ietf-sip-identity]. perhaps I've misunderstood, but don't we also need to specify a SIP SAML binding? > SIP-specific SAML profile(s) and binding(s). This is technically > straigh-forward as both SAML and SIP are explicitly extensible. straightforward > [RFC3261]. Depending on the chosen SIP security mechanism > either digest authentication, S/MIME or Transport Layer > Security is used to provide the AS with a strong assurance > about the identity of Alice. well, TLS in this use case is not normally used to provide the AS with the identity of ALice. Perhaps you are referring to mutual authentication with tls? Or maybe you just mean digest over tls? > signature" for the message and add Identity and Identity-Info > headers to the message. The AS also at this time constructs I feel like a broken record, but its header field and not header * sections 6.1.3, 6.1.2 and 5 all seem pretty redundant, as they contain the same flow with nearly the same levels of detail. Are all three needed? > Attribute: NotOnOrAfter > > The value of the NotOnOrAfter XML attribute MUST be set to a time > instant later than the value for NotBefore. guidance on how to set this? > This section specifies the "SAML HTTP-URI-based SIP Binding", > (SHUSB). SHUSB? Geez, this acronym is awful. > Section 3.7.5.4 Error Reporting: > > All SHOULDs in this section are to be interpreted as MUSTs. > This is somewhat mysterious. Is there something SIP specific which would cause you to want to do this, or just a beef with the fact that everything there is a SHOULD and not a MUST? Also perhaps a few words about whats in that section would be helpful. Indeed its not obvious to me why we can't just use the existing SAML URI binding if we're just doing a vanilla http query to retrieve the assertion. > The value of the element MUST be the same as the Address of > Record (AoR) value used in computing the "signed-identity-digest" > which forms the value of the Identity header. See Section 9 of > [I-D.ietf-sip-identity]. I read this as being that this is the literal AoR, i.e., sip:user@domain. But, in the example later on: > 1 2 IssueInstant="2003-04-17T00:46:02Z" Version="2.0" > 3 xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> > 4 > 5 example.com > 6 > 7 > 8 9 Format= > 10 "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> > 11 Alice@example.com > 12 there is no sip:, and the format attribute has a URN which explicitly says emailAddress and not SIPURI. I think this should be a SIP URI. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 16:04:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FywX5-0000z1-Rr; Fri, 07 Jul 2006 16:02:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FywX5-0000yw-4d for sip@ietf.org; Fri, 07 Jul 2006 16:02:35 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FywX3-0008RW-P5 for sip@ietf.org; Fri, 07 Jul 2006 16:02:35 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 07 Jul 2006 12:49:51 -0700 X-IronPort-AV: i="4.06,218,1149490800"; d="scan'208"; a="303996598:sNHT3494871432" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k67JnpNO021122 for ; Fri, 7 Jul 2006 12:49:51 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k67JnX4Q007502 for ; Fri, 7 Jul 2006 12:49:51 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 15:49:44 -0400 Received: from [161.44.34.230] ([161.44.34.230]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 15:49:43 -0400 Message-ID: <44AEBAD6.1040409@cisco.com> Date: Fri, 07 Jul 2006 15:49:42 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 19:49:44.0162 (UTC) FILETIME=[7E6F3420:01C6A1FE] DKIM-Signature: a=rsa-sha1; q=dns; l=2706; t=1152301791; x=1153165791; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:concerns=20on=20draft-elwell-sip-tispan-connected-identity-01; X=v=3Dcisco.com=3B=20h=3DmrV292tkN6WMAYCtPW776dZ/ixo=3D; b=cS78GVHvlbTahKMhEHSzIJKVwWM/in7K0sI3zq43rEELwGvzUUb+zto5Rtn3mQ7EOjT9Jsbl gAUWP+GHLPcwy6pe5mX7cBw9GnT3Ja4DX4rB4sNvjlULayWgMBpxcXd0; Authentication-Results: sj-dkim-8.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Sip] concerns on draft-elwell-sip-tispan-connected-identity-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I wasn't able to find any disucssion on this draft so far in the archives; my apologies if I missed it. This draft concerns me greatly. The first thing that worries me is the general idea that 3gpp or tispan get to 'choose' which SIP header field contains what type of identity. They get to do no such thing. These header fields have defined meanings. Having either organization decide to specify their own interpretation for the type of identity that goes in there is a guarnateed receipe for huge, massive, and unending interoperability failures. On the technical front, I strongly disagree that the From and P-Asserted-Identity represent different types of identity in any way. They both have always identified the user that is the sender of the request. In cases where you had an enterprise user Joe making a SIP call, the From would contain sip:joe@enterprise.com and this would be authenticated by the proxy in the enterprise, followed by insertion of a P-Asserted-ID which says the same thing. The From, in this use case, should not be sip:enterprise.com. Next, I am puzzled by the requirement to deliver separate identities to the calling party for these two things. I understand the concept of a billing identity being separate from the identity of the caller. I do not, however, understand why the billing ID is of any interest to the called party whatsoever. It seems that this would, at best, be of interest only within the domain of the calling party. Since its also directly inferrable from the identity of the caller (presumably the database contains a linkage between the two), I also don't see why it would need to be carried in the sip message itself. Is there a use case where there is not a provisioned relationship between the user making the call and the billing entity? Certainly there is a clear direct relationship in the enterprise example in the draft. Finally, even if I buy the idea that there are two identities and that they both need to be conveyed, I strongly disagree with the notion that one of them can be conveyed with SIP-identity, while P-A-ID is OK for the other. There are certain well-known technical limitations with P-A-ID which sip-identity addresses. There is nothing about the nature of the identity which invalidates any of those issues. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 16:31:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fywxb-000493-AY; Fri, 07 Jul 2006 16:29:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FywxZ-00048x-Mr for sip@ietf.org; Fri, 07 Jul 2006 16:29:57 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FywxY-0001w1-Bz for sip@ietf.org; Fri, 07 Jul 2006 16:29:57 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2006 13:29:55 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,218,1149490800"; d="scan'208"; a="31483335:sNHT24488244" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k67KTtvD002355; Fri, 7 Jul 2006 16:29:55 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k67KTtVM008555; Fri, 7 Jul 2006 16:29:55 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 16:29:54 -0400 Received: from [10.86.240.9] ([10.86.240.9]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 16:29:54 -0400 Message-ID: <44AEC441.7030808@cisco.com> Date: Fri, 07 Jul 2006 16:29:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Anybody feeling a connection with "connect reuse"? References: <200606271654.12268.lists@ohlmeier.org> <44ADE465.5050403@cisco.com> In-Reply-To: <44ADE465.5050403@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 20:29:54.0127 (UTC) FILETIME=[1AE2ADF0:01C6A204] DKIM-Signature: a=rsa-sha1; q=dns; l=3493; t=1152304195; x=1153168195; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Anybody=20feeling=20a=20connection=20with=20=22connect=2 0reuse=22? |To:Jonathan=20Rosenberg=20; X=v=3Dcisco.com=3B=20h=3DgxoFSdELFGvpfmeqayFsXG6HCuM=3D; b=SBXuc854zr3vEwMGFdWDDk2ENZAPZMGAnIyZTg0FnbXMY++ukS5pfkXzk1F2IMm/bTRhvGxO WOgMv1sTlEqKScjKiQb4fw5/eGBc3lbKYLDEcqAZtnOidNMon0ZOWqge; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Nils Ohlmeier , sip@ietf.org, Keith Drage , Dean Willis , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry - haven't been following this and don't have a position on the merits. But one thing Jonathan didn't mention below that might be relevant: With two connections, the traffic is split across them. This potentially affects the flow control. I can see that there could be both pros and cons to this. Paul Jonathan Rosenberg wrote: > Having just done a detailed review of the document, I will say that I am > skeptical of the value of this specification at this time. > > Firstly, it has fairly limited deployment scenarios: > > 1. no NATs between the elements > 2. mutual TLS auth only > > assuming these are true, its valuable only when there is generally a lot > of churn in TLS connection setups. For example, in an environment where > there is a fixed and known-ahead-of-time peering relationship between > providers, connect-reuse doesn't do much for you anyway, since there are > relatively few TLS connections and they are set up when the system > boots, or perhaps just once. > > Even if the connections aren't set up at startup, but on demand, over > time the value of connect-reuse is really zero if the total number of > TLS connections that are needed by the proxy is below the capacity of > the server. In other words, if a proxy only ever connects to 100 other > proxies, then at some point the proxy gets its 200 TLS connections set > up (assuming no connect-reuse) and thats it. It never tears them down > since it never runs out of resources, so TLS handshaking becomes a > fixed, one-time cost. That makes it uninteresting to optimize. > > The value, then, comes only when the set of proxies that get connected > to is constantly changing, such that TLS handshaking between proxy peers > is an ongoing and non-trivial percentage of the overall CPU effort. > > To be frank, I am not aware of a single deployment situation today that > meets this constraint. Can someone point me to a real deployment > scenario where connect-reuse is applicable and has a non-trivial > improvement in the performance of the proxy? > > Thanks, > Jonathan R. > > > Nils Ohlmeier wrote: > >> On Friday 23 June 2006 23:08, Dean Willis wrote: >> >>> We've been following the connection reuse draft, currently draft-ietf- >>> sip-connect-reuse-05.txt, for a long long time. >>> >>> We've slipped the charter delivery date several times. >>> >>> Are we ever going to finish this work? Do we need to finish this work? >>> >>> Is this something that we could just not do? >>> >>> >>> Otherwise said: "Does the SIP working group still have a consensus to >>> expend working group effort on connection reuse?" >>> >>> If you have an opinion, for or against, please let it be known on >>> this list. >> >> >> I think their are two options left: >> >> - either push it out as "TLS-connection-reuse-between-proxies" (if >> nobody comes up with any issue any more) >> - or drop it because the real world usage is too limited >> >> I have little preference for the first alternative, but wouldn't mind >> to go for the second option. >> >> Regards >> Nils >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 20:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz10x-0001o5-W4; Fri, 07 Jul 2006 20:49:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz10w-0001o0-02 for sip@ietf.org; Fri, 07 Jul 2006 20:49:42 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz10v-0004pq-Cm for sip@ietf.org; Fri, 07 Jul 2006 20:49:41 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 1070F222425 for ; Fri, 7 Jul 2006 17:57:49 -0700 (PDT) To: sip@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Fri, 07 Jul 2006 17:49:40 -0700 From: Eric Rescorla Message-Id: <20060708005749.1070F222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Subject: [Sip] Review of draft-audet-sip-sips-guidelines-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This draft attempts to clarify the underspecification of SIPS in RFC 3261. This seems like a good idea in principle, but at least from the security guy perspective, I worry that this draft isn't completely baked yet. I do hasten to add that this is the security guy perspective, so there are probably SIP complexities I'm missing. That said, ISTM that there are a number of problems that need to be disentangled: 1. What a UA which is trying to contact a given URI can expect in terms of how their messages will be handled. 2. What a UA can safely publish as their AOR and how to do it. 3. What a UA which receives a message can determine about how the message was handled. This draft handles all of these issues together and I think it would be best to handle them separately. Taking a step back, I think we want the following: 1. A UA which tries to dereference a SIPS URI knows that as long as its dealing with compliant proxies its messages will be transmitted securely all the way to the peer. 2. A UA can make itself available in the following ways: - Secure only - Secure or insecure but hopefully if you're dealing with a secure peer then you both get secure. - Insecure only. So, AOR advertisement should support this. 3. A UA can determine (again assuming it's dealing with compliant proxies) whether the path from the peer was secure. Do I have these requirements right? Issue (1) needs to be dealt with by imposing rules about what the proxies do. I.e., that when presented with SIPS they use TLS in the outgoing direction. The edge case--and the one that's creating most of the heartbreak--appears to be what happens inside of trust domains. Based on the discussion in this draft, Issue (2) breaks down into two cases: (a) What you advertise when you register. (b) What you put in your own headers (i.e., the To). Case (a) seems like it's relatively straightforward using the rules described in S 5. It's case (b) that's tricky, due to the asymmetry of "SIPS means you must use TLS to your first hop proxy" and "SIPS means you may or may not use TLS between the last hop proxy and the final destination". Since that last link is about to become the first hop, this seems highly problematic. ISTM that there are two natural fixes for this: (a) Decree that SIPS means TLS all the way (this is a lot less problematic in the face of outbound than it otherwise would be.) (b) Decree that it's none of our business what happens inside people's trust boundaries and so SIPS only means secure in between them. This draft, however, takes neither approach and instead attempts to thread the needle between these. I'm not sure that this is practical--and it's certainly creating a lot of complexity. Issue (3) seems like it ought to be solved the same way that it's ntended to be solved in RFC 3207 (STARTTLS): examine the Via lines or something like them. I would ignore the URI entirely here, especially in view of the confusion noted above. DETAILED COMMENTS: S 5.1: I'm not sure why you need TLS transport to do a registration of a SIPS contact. S 6. If a UAS does not support SIPS, it MUST reject a request over TLS with response code 416. I don't understand how this can happen. Can you explain? Upon receiveing a 416 a UAC SHOULD not re- attempt the request with a SIP URI by automatically replacing the SIPS scheme with a SIP scheme. If the UAC does re-attempt the call with a SIP URI, it SHOULD inform to the user that the security level is downgraded. Shouldn't this last SHOULD be a MUST? It seems like a security condition. The presence of a SIPS Request-URI does not necessarily indicate that the request was sent end-to-end securely. The presence by the time you receive it, right? CAuse it should mean that at the sender.... 26.4.4/RFC 3261 also explains that S/MIME may also be used by the originating UAC to ensure that the original form of the To header field is carried end-to-end. While not specifically mentioned in 26.4.4/RFC 3261, this is meant to imply that [RFC3893] would be used to "tunnel" important headers (such as To and From) in an encrypted S/MIME body, replicating the information in the SIP message, and allowing the UAS to validate the content of those important headers. While this approach is certainly legal, another approach is to use the SIP Identity mechanism defined in [I-D.ietf-sip-identity]. SIP Identity creates a signed identity digest which includes, amongst other things, the AOR of the sender (from the From header) and the AOR of the original destination (from the To header). It is RECOMMENDED that a UAC use the mechanism in [I-D.ietf-sip-identity] instead of the one defined in RFC 3893. You say "encrypted" here, but you really mean signed, right? S 13. I'm not sure I find this that helpful. S 14. It seems to me that most of these rules have security implications. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 21:23:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz1Vy-0002H7-Cc; Fri, 07 Jul 2006 21:21:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz1Vw-0002H2-Jh for sip@ietf.org; Fri, 07 Jul 2006 21:21:44 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz1Vv-0006f6-9S for sip@ietf.org; Fri, 07 Jul 2006 21:21:44 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 07 Jul 2006 18:21:42 -0700 X-IronPort-AV: i="4.06,219,1149490800"; d="scan'208"; a="1836345864:sNHT30353456" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k681Lgae005951; Fri, 7 Jul 2006 18:21:42 -0700 Received: from dwingwxp (sjc-vpn4-467.cisco.com [10.21.81.211]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k681LT47019961; Fri, 7 Jul 2006 18:21:41 -0700 (PDT) From: "Dan Wing" To: "'Elwell, John'" , Subject: RE: [Sip] Issue 4 in draft-ietf-sip-connected-identity-00.txt Date: Fri, 7 Jul 2006 18:21:20 -0700 Message-ID: <000101c6a22c$de48c6d0$d351150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZuJlpV81qUmJ43SMKaK9Uqv4dvDwz5gT2Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <50B1CBA96870A34799A506B2313F266708CFA25F@ntht201e.siemenscomms.co.uk> DKIM-Signature: a=rsa-sha1; q=dns; l=1739; t=1152321702; x=1153185702; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[Sip]=20Issue=204=20in=20draft-ietf-sip-connected-identity-00.tx t; X=v=3Dcisco.com=3B=20h=3DdRMymw3Rtq/6zpz0eo/DL9lYfKk=3D; b=p9f5xRxhws3osE6+8SrOH6vloKRVNQgU9JXI2th1eYI5eN15moELtP99L75fdLY6lG6ap+BG FPunxEujslWW/4y9GGaT5O/vJBnccn3xhW5o0ag3qLq1e/v3fhXD1SFp; Authentication-Results: sj-dkim-6.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Tuesday, May 02, 2006 1:24 PM > To: sip@ietf.org > Subject: [Sip] Issue 4 in draft-ietf-sip-connected-identity-00.txt > > The fourth issue is not actually in draft-00 but was raised > subsequently. If a UA supports a change of From header field URI > mid-dialog, as indicated by the "id-change" option tag, we could > mandate that it also support the SIP UPDATE method. Then the peer > UA in a dialog would be free to use the UPDATE method to report > connected identity, rather than the less suitable re-INVITE method. > The use of UPDATE means 2 messages instead of 3 and avoids the need > for an offer-answer exchange. I heard no objections when this was > proposed a few days ago. Do we have consensus? I prefer UPDATE. I am considering the needs of some proposed SRTP keying techniques which could benefit from strong authentication of identity and of the fingerprints or certificates in SDP. For those cases it's helpful to include SDP in the UPDATE so that it gets signed with Identity, even if that SDP is exactly the same as the SDP in the answer. An example of where Identity could help is with a pure DH mode (such as draft-baugher-mmusic-sdp-dh). It can also help provide additional protection of a UA's self-signed certificate (various MIKEY modes) or certificate fingerprint (mmusic-comedia-tls, mcgrew-tls-srtp). Even without SRTP and without comedia-tls, the reasons that Identity chose to include the offerer's SDP in its signature should be applicable to the answerer's SDP. Otherwise we're saying the answerer's SDP doesn't need authentication or integrity protection. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 07 21:23:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz1W8-0002TY-6t; Fri, 07 Jul 2006 21:21:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz1W6-0002Ml-Ph for sip@ietf.org; Fri, 07 Jul 2006 21:21:54 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz1W5-0006fM-Gs for sip@ietf.org; Fri, 07 Jul 2006 21:21:54 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 07 Jul 2006 18:21:53 -0700 X-IronPort-AV: i="4.06,219,1149490800"; d="scan'208"; a="1836345914:sNHT35061090" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k681Lr39027065; Fri, 7 Jul 2006 18:21:53 -0700 Received: from dwingwxp (sjc-vpn4-467.cisco.com [10.21.81.211]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k681LT4A019961; Fri, 7 Jul 2006 18:21:52 -0700 (PDT) From: "Dan Wing" To: "'Elwell, John'" , Subject: RE: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt Date: Fri, 7 Jul 2006 18:21:21 -0700 Message-ID: <000401c6a22c$e47659a0$d351150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZuJjcqo41fibdrQq6VWk3pjEr63gz4aY1A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <50B1CBA96870A34799A506B2313F266708CFA25D@ntht201e.siemenscomms.co.uk> DKIM-Signature: a=rsa-sha1; q=dns; l=1687; t=1152321713; x=1153185713; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[Sip]=20Issue=202=20in=20draft-ietf-sip-connected-identity-00.tx t; X=v=3Dcisco.com=3B=20h=3DZSIM5S5QfLQbqL0P0FGFNeY7QSc=3D; b=iyh4f6lMY+Q8g+K7OWthc/zpgmzrf9De0r8d4ARs6n2JxLPSH7MzbabX3rDV6xWZcZMAhclu 0UVa9sQ9ekP/xVmtG4VA795u70ha79qQT117QP2e1fteofdOyX5K2Y50; Authentication-Results: sj-dkim-8.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I hadn't noticed any followups to this issue. I have a suggestion: > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Tuesday, May 02, 2006 1:21 PM > To: sip@ietf.org > Subject: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt > > The second issue concerns the fact that an UPDATE request in the > backward direction following dialog establishment can be wasted if > the peer UA (the UAC for the INVITE transaction) does not support > it. It states: > > "OPEN ISSUE: If the identity has has not changed compared with > the URI in the To header field and the UAC (for the INVITE > request) does not support verification of an Identity header, > this UPDATE or re-INVITE transaction would fulfil no useful > purpose. However, the UAS (for the INVITE transaction) does > not know this. In order to save this round trip, should we > have an additional option tag to indicate support for receipt > of the Identity header on mid- dialog requests? Then if this > option tag is not present in the INVITE request the additional > transaction could be omitted. Note that the id-change option > tag does not seem appropriate for this purpose, since a UA > could support a change of URI without supporting Identity." > > Whilst I do not wish to proliferate option tags, I do see some > benefit in such a tag. Any opinions? If an Invite arrives with both Identity and the id-change tag, it indicates the offerer understands both Identity and connected- identity, so the answerer should generate an request (UPDATE or re-INVITE). -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 01:06:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz4zn-0004BU-E6; Sat, 08 Jul 2006 01:04:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz4zm-0004BP-0K for sip@ietf.org; Sat, 08 Jul 2006 01:04:46 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz4zj-0004SE-9P for sip@ietf.org; Sat, 08 Jul 2006 01:04:45 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k6854co16147; Fri, 7 Jul 2006 23:04:38 -0600 Message-ID: <44AF3CE4.6020207@ntt-at.com> Date: Fri, 07 Jul 2006 22:04:36 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] comments on draft-ietf-sip-saml-00 References: <44AEB61F.2020108@cisco.com> In-Reply-To: <44AEB61F.2020108@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan; My comments inline. Jonathan Rosenberg wrote: > Overall, this is a HUGE improvement over draft-tschofenig-sip-saml-04, > which is the last version I read (I see that -05 was similar to > draft-ietf-sip-saml). This looks like a viable solution overall, and I > like how it dovetails with sip-identity. > > > > Major comments: > > * I'm a little worried that the SAML assertion itself doesn't include > any content from the SIP message which clearly limits its scope of > applicability to the request. You are relying on authentication via > sip-identity for that, but there are attacks where this won't work. > > For example, consider a rogue proxy or MITM which sees a SIP request > fly by. The AS was executed by an upstream proxy, so this request has > an Identity and Identity-Info header field. The proxy modifies the > Indentity-Info header field, which contains a URL to an older > assertion generated by the AS for the same subject, say, for a > previous call it just made. > > This is not a major threat, but there may be others like it. Is there > harm in including things like call-id, contact and other parameters > into the saml assertion so they are signed too? > > * I'm not clear on how this mechanism works with older sip-identity > implementations. The main issue is whether the URI in the > identity-info header field will return just a certificate, as > specified in sip-identity, or whether it returns a saml assertion. An > older sip-identity verifier will expect a certificate but it will get > an assertion if the AS implements sip-saml. Perhaps you are assuming > that the Accept headers or something are used for this? Somehow this > needs to be handled. > I asked the exact question on the SIP-SAML design team ML as well as in the last meeting. Currently as you mentioned, there is no indication on whether the URI referred by identity-info header points to a certificate or sip-identity. As far as I understood from the reply I got was that because SAML is based on federation or bi-lateral agreement, AS should know whether the target will understand the SAML. So there is no problems. Although, if call is forwarded to a domain which is not part of the federation, it may cause some issues. There are few other issues with the current SIP-SAML spec if it was to be used to convey information that would affect a routing decision on the signaling path. The issues are addressed on the draft which evaluates the profile defined in the SIP-SAML spec to convey CPC related information. http://www.ietf.org/internet-drafts/draft-schubert-sipping-saml-cpc-01.txt BTW it's not currently mentioned in the draft, but if more than one asserting party exists on the signaling path that needs to add artifacts(URI to the assertion), the current SIP-SAML might not work as sip-identity only allows one uri to be referred AFAIK. > > 6.1.4.1.3. Element: > > > > The element SHOULD contain an > > element, which itself SHOULD contain an element. The > > value of the element SHOULD be the same as the addr-spec > > of the SIP request's To header field. > > Hmm. Here is our infamous retargeting problem again. If the request is > retargeted, does this mean that the assertion cannot be used by the > forwarded party? This restriction doesn't exist for normal sip-identity. Agreed. Same can be said if the assertion is to be used by the intermediaries to alter the routing of the call. > > > Minor comments: > >> The scope of this specification is: >> >> o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such >> that a subject's profile attributes, and their domain's >> certificate, can be conveyed to a relying party using SAML. In >> doing so, satisfy the requirements outlined in [I-D.ietf-sipping- >> trait-authz], and compose with [I-D.ietf-sip-identity]. > > perhaps I've misunderstood, but don't we also need to specify a SIP > SAML binding? > >> SIP-specific SAML profile(s) and binding(s). This is technically >> straigh-forward as both SAML and SIP are explicitly extensible. > > straightforward > >> [RFC3261]. Depending on the chosen SIP security mechanism >> either digest authentication, S/MIME or Transport Layer >> Security is used to provide the AS with a strong assurance >> about the identity of Alice. > > well, TLS in this use case is not normally used to provide the AS with > the identity of ALice. Perhaps you are referring to mutual > authentication with tls? Or maybe you just mean digest over tls? > >> signature" for the message and add Identity and Identity-Info >> headers to the message. The AS also at this time constructs > > I feel like a broken record, but its header field and not header > > > * sections 6.1.3, 6.1.2 and 5 all seem pretty redundant, as they > contain the same flow with nearly the same levels of detail. Are all > three needed? > > >> Attribute: NotOnOrAfter >> >> The value of the NotOnOrAfter XML attribute MUST be set to a time >> instant later than the value for NotBefore. > > guidance on how to set this? > >> This section specifies the "SAML HTTP-URI-based SIP Binding", >> (SHUSB). > > SHUSB? Geez, this acronym is awful. > >> Section 3.7.5.4 Error Reporting: >> >> All SHOULDs in this section are to be interpreted as MUSTs. >> > > This is somewhat mysterious. Is there something SIP specific which > would cause you to want to do this, or just a beef with the fact that > everything there is a SHOULD and not a MUST? Also perhaps a few words > about whats in that section would be helpful. > > Indeed its not obvious to me why we can't just use the existing SAML > URI binding if we're just doing a vanilla http query to retrieve the > assertion. > >> The value of the element MUST be the same as the Address of >> Record (AoR) value used in computing the "signed-identity-digest" >> which forms the value of the Identity header. See Section 9 of >> [I-D.ietf-sip-identity]. > > I read this as being that this is the literal AoR, i.e., > sip:user@domain. But, in the example later on: > >> 1 > 2 IssueInstant="2003-04-17T00:46:02Z" Version="2.0" >> 3 xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> >> 4 >> 5 example.com >> 6 >> 7 >> 8 > 9 Format= >> 10 "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> >> 11 Alice@example.com >> 12 > > there is no sip:, and the format attribute has a URN which explicitly > says emailAddress and not SIPURI. I think this should be a SIP URI. I addressed this a while ago as well. Regards Shida > > Thanks, > Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 01:47:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz5d7-0002Uw-59; Sat, 08 Jul 2006 01:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz5d5-0002Ur-02 for sip@ietf.org; Sat, 08 Jul 2006 01:45:23 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz5d3-0006h5-Ji for sip@ietf.org; Sat, 08 Jul 2006 01:45:22 -0400 Received: from [131.161.248.89] (open-131-161-248-89.cliq.com [131.161.248.89]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k685jCF03247; Fri, 7 Jul 2006 22:45:12 -0700 In-Reply-To: <0J210041UNVSRP60@jes-fe1.zx.nl> References: <0J210041UNVSRP60@jes-fe1.zx.nl> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <52d49c981ff7287261758272cf8e73ca@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Fri, 7 Jul 2006 22:45:06 -0700 To: Jeroen Van Bemmel X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen, Clients which implement outbound-04 as written already have a flag: the presence of keepalive=stun in the outbound-proxy-set. The draft is pretty clear that clients send STUN messages to their outbound proxies when this parameter is present. Some *other* flag that lets a client with a derived outbound-proxy-set figure out it is also safe to send STUN to a proxy is a perfectly fine future extension which does no harm. Clients that just implement outbound-04 will never send STUN messages to the proxies with the future extension but no keepalive parameter, nor will they send STUN messages to unsuspecting proxies. thanks, -rohan On Jul 7, 2006, at 9:47, Jeroen Van Bemmel wrote: > Rohan, > > Clients ignoring the flag would not do so on purpose, but simply > because they would not know about it (ie only implementing outbound > and not the separate extension). By making it part of outbound it > becomes atomic: either the client does both STUN and "crash > prevention", or neither of these. That is the only way to make it safe > > Regards , > > Jeroen > > > -----Oorspronkelijk bericht ----- > Van: "Rohan Mahy" > Aan: "Jeroen van Bemmel" > CC: dean.willis@softarmor.com; "Cullen Jennings" ; > "Rohan Mahy" ; "Jonathan Rosenberg" > ; "Anders Kristensen" ; > sip@ietf.org > Verzonden: 7-7-06 17:25 > Onderwerp: Re: [Sip] Ready for WGLC on Outbound? > > Jeroen, > > On Jul 6, 2006, at 14:12, Jeroen van Bemmel wrote: >> [ snap ] >>> Jonathan wrote >>> >>> I'm not objecting to the concept of this check. I just think its not >>> necessary, something that might be optional at best. As such, if >>> folks decide they want something, it can go in another draft. I dont >>> think we need to burden sip-outbound with this. >> >> The trouble is, once outbound is "out" any mechanism defined in a >> separate draft won't work as good. Because then there will be clients >> that simply ignore the flag. > > Why is this anymore likely for clients that implement outbound? What > is the motivation for clients to ignore the flag? If they ignore the > flag and send STUN requests anyway against the they trash their own > proxy. That is not in the interest of the client vendor. > > thanks, > -rohan > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 02:13:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz625-0008R3-DG; Sat, 08 Jul 2006 02:11:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz623-0008Qy-Bw for sip@ietf.org; Sat, 08 Jul 2006 02:11:11 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz621-0003zp-Uk for sip@ietf.org; Sat, 08 Jul 2006 02:11:11 -0400 Received: from [131.161.248.89] (open-131-161-248-89.cliq.com [131.161.248.89]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k686B5F03637; Fri, 7 Jul 2006 23:11:05 -0700 In-Reply-To: <5lMhySMZNSts.P4yLcZSr@se-smtp.ericsson.se> References: <5lMhySMZNSts.P4yLcZSr@se-smtp.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <25779fe3c8df692656b33691abc67cf3@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Fri, 7 Jul 2006 23:11:16 -0700 To: "Christer Holmberg" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org, Miguel Garcia , Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, It is near the end of a long day today, so I am having trouble understanding why we are still having this discussion. I really do want to understand what you are trying to accomplish. I am just relating a humorous thought that popped into my punchy brain as I sit here. I have to admit that my initial reaction is that this is something like the following vignette. A coach tells a runner about the new track about to be installed with black spongy rubber. The runner asks can you please add a sprinkler system to it before it is installed? The coach asks why and the runner responds that the black track will be hot to run on in bare feet. Of course running on the track with bare feet is a perfectly acceptable, but running with shoes is certainly more common, possibly even recommended. The new track will be a great improvement for everyone and will work with and without shoes. However its unclear that the sprinkler system is really a good idea, that it will work, how long it will take to install, and how much it will cost. It could be installed later if it turns out to be needed. In the interim, folks with shoes and tough feet can use the track immediately. On Jul 7, 2006, at 10:06, Christer Holmberg wrote: > Hi, > > What if the client only gets IP address(es) of the edge proxy? Is each > address treated as a URI? the client needs to figure out how to derive a URI to place in its Route header or to use as a target for RFC 3263. how this is done is up to you, but getting an IP address alone feels like getting running shorts and no shoes. > As I've said earlier, a SIP URI is something the client creates, but > it does not necessarily be what is configured (given as input, > manually or using some other mechanism). > > I've also indicated that there may be other mechanisms than "multi > flow" to provide reliability. So, in those cases multiple flows may > not be needed, but one may still want to use outbound. I still don't see the advantage of trying to do one flow "reliability" with outbound proxies only addressed by an IP address. Why is going barefoot better than wearing sneakers? I think I would need to see a full use case (a few paragraphs and maybe a simple drawing) to get what you have in mind. > Note that I am NOT arguing against saying that a client must support > the establishment of two flows. ok, good to know. > Also, if a client uses STUN keepalive, but not the rest of outbound > (instance-id etc) it would not make sense trying to send multiple > registrations, since the registrar would not be able to differentiate > the "flows". I think that needs to be clear in the spec, a part of > defining the STUN keepalive as a standalone function. I actually understand the motivation for this one. The issue is how much of the STUN keepalive mechanism belongs in 3489bis, how much could go in outbound in a separate section (or a separate document), and how much is specific to outbound. I think all the text about what you do when you try to setup a flow and it doesn't work (retry after x seconds...) is really very specific to multiple flows. There is the binding request/response that belongs in 3489bis. What is unclear to me is what else is left. Certainly you need some part of a doc that defines the keepalive URI parameter and updates 3261 to say it ok to send STUN on the same port as SIP when you have positive knowledge (such as the keepalive parameter) that the server is ok with that. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 03:09:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz6uV-0003so-PA; Sat, 08 Jul 2006 03:07:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz6uT-0003sj-RU for sip@ietf.org; Sat, 08 Jul 2006 03:07:25 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz6uT-0008Ol-FM for sip@ietf.org; Sat, 08 Jul 2006 03:07:25 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k6877OFL016208; Sat, 8 Jul 2006 02:07:24 -0500 (CDT) Received: from [135.244.32.54] (vkg.lra2.lucent.com [135.244.32.54]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k6877ND03300; Sat, 8 Jul 2006 02:07:23 -0500 (CDT) Message-ID: <44AF59A8.1000304@lucent.com> Date: Sat, 08 Jul 2006 02:07:20 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] comments on draft-ietf-sip-connect-reuse-05 References: <44ADE168.7050309@cisco.com> In-Reply-To: <44ADE168.7050309@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan: Thanks for a detailed read. A lot of your comments were incorporated as requested; below are the remaining comments that warranted a discussion. Jonathan Rosenberg wrote: > another important reason is that, in the case of TLS, only one side > will offer a certificate. Is that always true? After all, a server can ask a client of a certificate as well. If the client is a proxy, it will have one, and it will give it to the server. In connect-reuse, if mutual authentication is to be done, the server has to authenticate the client as well. An attempt on how it does that is is teased out in domain-certs (more on that in a separate email thread). > this presumes in general that there aren't persistent, long-lived > connections already set up. Which is reasonable today, since there are no guidelines for persistent long-lived connections in rfc3261. Instead it talks about general reuse of connections without specifying anything else. Maybe some will say that how to do this is implementation defined, but I think that we ought to be able to provide some more stricter guidelines to implementors, especially as TCP and TLS become the dominant transports. Otherwise it is already a mess for TCP, where some implementations keep the connections open across transactions and dialogs, some do not, and yet others open a new connection to send a response! Let's not create the same mess for TLS. >> This effectively doubles the load on each entity. > > definitely not. > > It doubles the amount of work for connection establishment, [...] > Again though I wonder if the connection establishment is really the > dominant CPU cost. In "SSL and TLS" by EKR, Section 6.19 analyzes TLS connection establishment. Servers will build up considerable queues as the server CPU saturates by the SSL handshakes it is already performing. > Can you give a specific use case? I don't think there are established > guidelines for how long it takes to add video, for example. No, they are not. However, it is appropriate that a re-INV over an existing TLS connection will complete faster than one that requires SSL handshake. >> The presence of the "alias" parameter indicates that P1 does >> support aliasing. P2 now authenticates the connection and if the >> authentication was successful, P2 creates an alias to P1 using the >> advertised address in the topmost Via. > > Firstly, you need to define 'successful' authentication. You need to > match the domain in the certificate with the via address. Good point about defining 'successful' authentication. I have tried to do highlight the issue of a server authenticating a client in domain-certs. Via is the only obvious choice here. > Also, this last sentence is very confusing, since the table is NOT > populated with the advertised address, its populated with the > received address, as described in the text below. I will clarify. > Also how do you populate destination port? The overview section > doesn't say. I believe it is NOT the received port (as IP address is) > but rather the one advertised in the sent-by field, or 5061 (the > default) if no port is listed. Yes; I will clarify. >> structure in which it keeps active connection state so that >> aliases, active connections, and blacklisted nodes are all >> discovered when looking for an active connection. > > you've not defined 'an additional data structure' or blacklisted > nodes; I couldn't follow this paragraph. I will rephrase and clarify. >> 6. Requirements > > you may want to have an intro paragraph which says that these are the > requirements which motivated this specification Sure. >> 7. Formal Syntax [...] > please use the =/ syntax notation that we've started using for sip > specs. Its much better. Sure. >> request. Whenever the RFC3263 server selection mechanism executed >> at the receiver results in the choice of this IP address, port, and >> transport tuple, the alias MUST be used instead. > > I think a SHOULD is fine here; and indeed if the connection has gone > away you obviously won't be reusing the alias. I can clarify the corner case. But I really think that the normative strength should be MUST. The more choices, the more complexity. Think of it from an implementation point of view: if an alias exists, why not use it instead of opening up a new connection? If you open up a new connection, then do you put it in the alias table? If you do, then you have two aliases. How do you choose which one to use on subsequent requests? >> An alias is formed at the sender of the request when it executes >> the RFC3263 server selection mechanism to arrive at an IP address, >> port, and transport tuple to send a request to. Subsequent >> requests going to the same destination address MUST use the alias >> instead. > > Hmm this MUST is stronger than in rfc3261, which actually says > SHOULD. I think the existing SHOULD is fine. Yes, rfc3261 says SHOULD (actually RECOMMENDED is the word used there). But for the same reason I wrote above, it will be good to reuse the same alias. >> A TLS server conformant to this specification MUST ask for a client >> certificate; if the client possesses a certificate, it will be >> presented to the server for mutual authentication. The server MUST >> ensure that the canonical host name of the client is present >> either > > where does one obtain the canonical hostname? > > It seems to me, that in a proxy to proxy case, the receiving proxy > (the server side) will need to check the record-route hostname > against the client certificate. R-R is optional. The only header that fits the bill is Via. Thanks so much for a detailed read. Much appreciated. Ciao. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 03:09:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz6uk-00040D-Nu; Sat, 08 Jul 2006 03:07:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz6uj-0003vY-8T for sip@ietf.org; Sat, 08 Jul 2006 03:07:41 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz6uh-0008Ot-VD for sip@ietf.org; Sat, 08 Jul 2006 03:07:41 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k6877cCG016266; Sat, 8 Jul 2006 02:07:38 -0500 (CDT) Received: from [135.244.32.54] (vkg.lra2.lucent.com [135.244.32.54]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k6877cD03356; Sat, 8 Jul 2006 02:07:38 -0500 (CDT) Message-ID: <44AF59B8.5060703@lucent.com> Date: Sat, 08 Jul 2006 02:07:36 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Anybody feeling a connection with "connect reuse"? References: <200606271654.12268.lists@ohlmeier.org> <44ADE465.5050403@cisco.com> In-Reply-To: <44ADE465.5050403@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > Having just done a detailed review of the document, I will say that I am > skeptical of the value of this specification at this time. > > Firstly, it has fairly limited deployment scenarios: > > 1. no NATs between the elements > 2. mutual TLS auth only Jonathan: This is imposed by other realities. The NAT issue is discussed in outbound, and a decision has already been made not to do connect reuse of TCP connections. > assuming these are true, its valuable only when there is generally a lot > of churn in TLS connection setups. For example, in an environment where > there is a fixed and known-ahead-of-time peering relationship between > providers, connect-reuse doesn't do much for you anyway, since there are > relatively few TLS connections and they are set up when the system > boots, or perhaps just once. True, but there is nothing to stop UACs in an enterprise to do connect reuse to their default outbound proxy. > Even if the connections aren't set up at startup, but on demand, over > time the value of connect-reuse is really zero if the total number of > TLS connections that are needed by the proxy is below the capacity of > the server. In other words, if a proxy only ever connects to 100 other > proxies, then at some point the proxy gets its 200 TLS connections set > up (assuming no connect-reuse) and thats it. It never tears them down > since it never runs out of resources, so TLS handshaking becomes a > fixed, one-time cost. That makes it uninteresting to optimize. RFC3261 is rather silent on how to do persistent connections. This has let to a mess for TCP, where some implementations keep the connections open across transactions and dialogs, some do not, and yet others open a new connection to send a response! Let's not create the same mess for TLS. > The value, then, comes only when the set of proxies that get connected > to is constantly changing, such that TLS handshaking between proxy peers > is an ongoing and non-trivial percentage of the overall CPU effort. ...Or the number of UACs using a default outbound proxy is constantly changing... > To be frank, I am not aware of a single deployment situation today that > meets this constraint. Can someone point me to a real deployment > scenario where connect-reuse is applicable and has a non-trivial > improvement in the performance of the proxy? Connection reuse is underspecified in rfc3261, which takes the position that connections accepted by the transport layer will frequently not be reused. Connect-reuse solves this problem. Without it, there is *absolutely* no guidance in how to send requests in the backwards direction on the same connection if outbound is not used. Given the state of TCP connection reuse today, I think we can do better with TLS. The draft itself has seen implementations, so it appears that it has some utility. The draft can be wrapped up in a couple of weeks after Montreal. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 03:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz7Zc-0005Fg-AC; Sat, 08 Jul 2006 03:49:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz7Za-0005DK-QN for sip@ietf.org; Sat, 08 Jul 2006 03:49:54 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz7ZZ-0003vq-Ga for sip@ietf.org; Sat, 08 Jul 2006 03:49:54 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E471D78C; Sat, 8 Jul 2006 09:49:52 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 09:49:52 +0200 Received: from [136.225.183.110] ([136.225.183.110]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 09:49:49 +0200 From: "Christer Holmberg" To: "Rohan Mahy" , "Jeroen Van Bemmel" Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Sat, 8 Jul 2006 10:49:58 +0300 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Jul 2006 07:49:52.0621 (UTC) FILETIME=[18AED1D0:01C6A263] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Maybe I've missed it, but what is the purpose of sending the keepalive = parameter to the edge proxy in the first place? To me it is only used to tell the client to use STUN keepalive, but what = will the proxy do with that information? Should it reject a reuest if it = does expect STUN, but the parameter is not present? Or? Regards, Christer Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 07:30:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzAzK-0006Xn-UM; Sat, 08 Jul 2006 07:28:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzAzI-0006Xi-Rg for sip@ietf.org; Sat, 08 Jul 2006 07:28:40 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzAzH-0007qT-IP for sip@ietf.org; Sat, 08 Jul 2006 07:28:40 -0400 Received: from office-srv-04.HQ.TELIO.NO (office-srv-04.hq.telio.no [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 3AE85194497 for ; Sat, 8 Jul 2006 13:28:38 +0200 (CEST) Received: from [142.131.134.165] ([192.168.3.19]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 13:27:53 +0200 Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <78fca135c137ba19bb6a13f2b9b8cc49@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Date: Sat, 8 Jul 2006 13:28:54 +0200 To: jonathan Rosenberg X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 08 Jul 2006 11:27:54.0139 (UTC) FILETIME=[8DE00EB0:01C6A281] X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org, sip@ietf.orgList Subject: [Sip] Comments on sip-identity-coexistance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have one concern and one comment. The concern in the use of the From header value to compare to the p-asserted-identity value. In IMS, those might not be the same. The comment I have is about the behaviour of the ingress proxy. I think it would be a really good idea for the ingress proxy to re-populate the Identity header and Identity-Info header using its own certificate after verifying the Identity header value from the remote egress proxy. This helps the UAS because it will most likely have the certificate of its ingress proxy and does not have to find the certificate of the remote end. Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 09:15:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzCcm-0001AM-RJ; Sat, 08 Jul 2006 09:13:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyMBM-0003bO-Da for sip@ietf.org; Thu, 06 Jul 2006 01:13:44 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyMAE-0003l6-Th for sip@ietf.org; Thu, 06 Jul 2006 01:12:36 -0400 Received: from [172.17.2.251] ([172.17.2.251]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k665BI8J058687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jul 2006 00:11:18 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <44AC9B68.1060408@estacado.net> Date: Thu, 06 Jul 2006 00:11:04 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Sat, 08 Jul 2006 09:13:31 -0400 Cc: SIP WG Subject: [Sip] Outbound Comment: binding key X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From section 6.1: When a reg-id header parameter is present in a Contact header field value in a REGISTER request, the corresponding binding is between an AOR and the combination of instance-id and reg-id. I don't think this is quite correct. This statement appears to be asserting that {instance-id,reg-id} is a unique key to a binding associated with an AOR. This would, in turn, imply that any successful registration attempt with an {instance-id,reg-id} that matches an existing binding would overwrite the existing record. I don't think that is what's intended, since section 6.2 contains the following text: o If two bindings have the same instance-id and reg-id, the proxy SHOULD prefer the contact that was most recently updated. If the binding is only to {instance-id,reg-id}, then that text is nonsensical: you can't have two identical bindings to the same AOR. I suspect that the text in 6.1 should actually read something more like: When a reg-id header parameter is present in a Contact header field value in a REGISTER request, the corresponding binding is between an AOR and the combination of instance-id, reg-id, and network flow. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 09:15:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzCd6-0001db-3T; Sat, 08 Jul 2006 09:13:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FycGO-0002kh-Ms for sip@ietf.org; Thu, 06 Jul 2006 18:24:00 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FycGN-0002wU-Ew for sip@ietf.org; Thu, 06 Jul 2006 18:24:00 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20060706222358m14009frade>; Thu, 6 Jul 2006 22:23:58 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k66MNvxp010717 for ; Thu, 6 Jul 2006 18:23:57 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k66MNvQC010713; Thu, 6 Jul 2006 18:23:57 -0400 Date: Thu, 6 Jul 2006 18:23:57 -0400 Message-Id: <200607062223.k66MNvQC010713@dragon.ariadne.com> From: Dale Worley To: sip@ietf.org In-reply-to: <85C045EB-B410-44D2-A028-51C234431067@estacado.net> (ben@estacado.net) Subject: Re: [Sip] Ready for WGLC on Outbound? References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com><553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com><003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> <005c01c6a00c$47763a20$31713b51@BEMBUSTER> <005701c6a11e$f3b69d80$31713b51@BEMBUSTER> <85C045EB-B410-44D2-A028-51C234431067@estacado.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Sat, 08 Jul 2006 09:13:50 -0400 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Ben Campbell I've been watching this train of reasoning for a while now, and am not sure I buy it. Do we really expect SIP devices to melt down if they get stun and don't expect it? If so, they are big targets for DoS attacks. The problem (I think) is whether the device can recover framing adequately to receive the next message on the "channel" in question. Clearly, this isn't a problem with UDP or SCTP, which frame messages. But if a UA establishes a TCP connection and sends a STUN message that the recipient doesn't understand, we need to know that the recipient can recover framing fast enough to process the SIP that the UA sends afterward. Otherwise, the UA's STUN messages would be performing a DoS attack on its own SIP connection! Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 09:15:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzCcn-0001AT-Kj; Sat, 08 Jul 2006 09:13:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXpF-0001iF-IX for sip@ietf.org; Thu, 06 Jul 2006 13:39:41 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXpE-0007E5-70 for sip@ietf.org; Thu, 06 Jul 2006 13:39:41 -0400 Received: from [172.17.2.251] ([172.17.2.251]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k66HcDBY071221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jul 2006 12:38:14 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <44AD4A76.6070309@estacado.net> Date: Thu, 06 Jul 2006 12:37:58 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] Outbound Comment: q-value References: <44AC9C9F.1000701@nostrum.com> <17580.44383.443990.716678@rautu.tutpro.com> In-Reply-To: <17580.44383.443990.716678@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Sat, 08 Jul 2006 09:13:31 -0400 Cc: Cullen Jennings , SIP WG , Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Adam Roach writes: > > > To handle this situation, it might make sense to put stuff in 6.2 > > that basically says that, for contacts with matching instance-ids, > > the proxy MUST NOT try a contact until all contacts at a higher > > q-value have been tried first. (I could go along with a weaker > > strength, but I really do think a prescriptive approach is the only > > thing that allows the clients to handle the situation I describe > > above in a manner that is predictable to the users). > > i you suggesting that proxies consult each other about the q-value UA > used when registering with each proxy before forwarding a request to the > UA? if so, your suggesting makes no sense. > > -- juha > I have no idea what you're saying here. Let's try getting some common context. Open the outbound document. Go to section 6.2. You'll notice that it talks about the rules that proxy/registrars use to populate the target set. This is the section to which my comment applies. In particular, there are two new rules placed on proxy/registrars that implement outbound, specified in a bullet list. I'm suggesting a third bullet that reads something like: * If multiple bindings have the same instance-id, the proxy MUST NOT use a binding until all bindings of greater q-value have been tried. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 09:15:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzCco-0001Aa-AP; Sat, 08 Jul 2006 09:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FycAG-0002Iw-HY for sip@ietf.org; Thu, 06 Jul 2006 18:17:40 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FycAF-00029a-2d for sip@ietf.org; Thu, 06 Jul 2006 18:17:40 -0400 Received: from [172.17.2.251] ([172.17.2.251]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k66MGHkk050821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jul 2006 17:16:17 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <44AD8BA2.9040906@estacado.net> Date: Thu, 06 Jul 2006 17:16:02 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] Outbound Comment: binding key References: <03a001c6a12f$7850bd90$a7c8000a@acmepacket.com> In-Reply-To: <03a001c6a12f$7850bd90$a7c8000a@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-Mailman-Approved-At: Sat, 08 Jul 2006 09:13:31 -0400 Cc: 'Cullen Jennings' , 'SIP WG' , 'Adam Roach' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel: I agree with your assessment, and would be _much_ happier if we simply removed all the text that implied that the proxy has to maintain multiple bindings with the same instance-id and reg-id. I think, at the very least, the draft needs some motivating text around why the proxy/registrar is expected to keep tabs of stale registration state. /a Hadriel Kaplan wrote: > My interpretation was the opposite - if a Register comes in with the same > {instance-id,reg-id} then it should indeed replace/overwrite the previous > binding of the same tuple. I know there are several sections in the draft > which imply otherwise, but I don't understand why. There is no real value > I can see to keeping a binding for an old flow of the same reg-id, since by > definition the UA would only "re-use" a reg-id if the old flow failed (or > even if it didn't think it had failed, but something rebooted and changed > the flow). > > I can see no realistic way in which an old flow of the same > {instance-id,reg-id} would succeed in reaching the UA. Am I missing > something? > > -hadriel > p.s. it's theoretically possible, if a sip-udp UA rebooted and resolved a > new proxy address and sent a register to it with the same reg-id, that it > may still be possible to reach the UA through the old "flow" for a time. > But is that a realistic case worth caring about? > > > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Thursday, July 06, 2006 1:12 AM >> To: Cullen Jennings >> Cc: SIP WG >> Subject: [Sip] Outbound Comment: binding key >> >> From section 6.1: >> >> When a reg-id header parameter is present in a Contact header field >> value in a REGISTER request, the corresponding binding is between an >> AOR and the combination of instance-id and reg-id. >> >> I don't think this is quite correct. This statement appears to be >> asserting that {instance-id,reg-id} is a unique key to a binding >> associated with an AOR. This would, in turn, imply that any successful >> registration attempt with an {instance-id,reg-id} that matches an >> existing binding would overwrite the existing record. >> >> I don't think that is what's intended, since section 6.2 contains the >> following text: >> >> o If two bindings have the same instance-id and reg-id, the proxy >> SHOULD prefer the contact that was most recently updated. >> >> If the binding is only to {instance-id,reg-id}, then that text is >> nonsensical: you can't have two identical bindings to the same AOR. >> >> I suspect that the text in 6.1 should actually read something more like: >> >> When a reg-id header parameter is present in a Contact header field >> value in a REGISTER request, the corresponding binding is between an >> AOR and the combination of instance-id, reg-id, and network flow. >> >> /a >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 11:41:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzEuS-0004Zn-Ec; Sat, 08 Jul 2006 11:39:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzEuR-0004ZI-5w for sip@ietf.org; Sat, 08 Jul 2006 11:39:55 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzEuP-0005zU-Qb for sip@ietf.org; Sat, 08 Jul 2006 11:39:55 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 449511400C8; Sat, 8 Jul 2006 18:39:49 +0300 (EEST) Received: from rautu (guanine140.gprs.dnafinland.fi [62.78.120.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 3198013FFEB; Sat, 8 Jul 2006 18:39:34 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 85138F03C3; Sat, 8 Jul 2006 18:39:44 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17583.53696.438432.812866@rautu.tutpro.com> Date: Sat, 8 Jul 2006 18:39:44 +0300 From: Juha Heinanen To: Subject: RE: [Sip] Outbound: Validating if the proxy supports outbound or not In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0280DF24@esebe103.NOE.Nokia.com> References: <44ACA454.3030800@nostrum.com> <8B1D53AEF7B03449A6D3771B3B7F850F0280DF24@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org, rohan@ekabal.com, adam@nostrum.com, BPenfield@acmepacket.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Erkki.Koivusalo@nokia.com writes: > The comments sent on the list during last few days seem to > indicate reasonably large concern that it is not sufficient > for the UA to check that the configured proxy URI contains > keepalive=stun parameter, in order for the UA to make sure > that the proxy actually supports outbound. erkki, i don't understand this concern. your own outbound discovery draft allows finding out outbound and non-outbound proxies of a domain. if proxy is outbound proxy, it of course support stun keepalives. if not, it doesn't. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 11:48:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzF17-0000Kz-6U; Sat, 08 Jul 2006 11:46:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzF16-0000Ku-6r for sip@ietf.org; Sat, 08 Jul 2006 11:46:48 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzF14-0008Kd-SF for sip@ietf.org; Sat, 08 Jul 2006 11:46:48 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 3A9F71400C8; Sat, 8 Jul 2006 18:46:43 +0300 (EEST) Received: from rautu (guanine140.gprs.dnafinland.fi [62.78.120.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id ADA0713FFEB; Sat, 8 Jul 2006 18:46:36 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 785D9F03C3; Sat, 8 Jul 2006 18:46:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17583.54122.434147.549688@rautu.tutpro.com> Date: Sat, 8 Jul 2006 18:46:50 +0300 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] Ready for WGLC on Outbound? In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5940294EB44@esealmw113.eemea.ericsson.se> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> <005c01c6a00c$47763a20$31713b51@BEMBUSTER> <17579.31823.351859.567955@rautu.tutpro.com> <5EB80D22825EEE42872083AD5BFFB5940294EB44@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Cullen Jennings , sip@ietf.org, dean.willis@softarmor.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) writes: > Does a proxy supporting STUN keep-alive have to be an "outbound > proxy" (assuming you mean an edge proxy), as defind in the outbound > spec? i don't know or care. see subject line. this thread is about outbound proxies. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 12:31:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzFgb-0005tA-D1; Sat, 08 Jul 2006 12:29:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzFgZ-0005t5-PS for sip@ietf.org; Sat, 08 Jul 2006 12:29:39 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzFgY-0003CP-EV for sip@ietf.org; Sat, 08 Jul 2006 12:29:39 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 68EC413F8A5; Sat, 8 Jul 2006 19:29:32 +0300 (EEST) Received: from rautu (guanine140.gprs.dnafinland.fi [62.78.120.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 710C013F861; Sat, 8 Jul 2006 19:29:22 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 9AB24F03C1; Sat, 8 Jul 2006 19:29:34 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17583.56686.563626.603475@rautu.tutpro.com> Date: Sat, 8 Jul 2006 19:29:34 +0300 From: Juha Heinanen To: "Jeroen van Bemmel" Subject: Re: [Sip] Ready for WGLC on Outbound? In-Reply-To: <005701c6a11e$f3b69d80$31713b51@BEMBUSTER> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> <005c01c6a00c$47763a20$31713b51@BEMBUSTER> <005701c6a11e$f3b69d80$31713b51@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel writes: > No, you cannot shift it off like that. Outbound is introducing binary STUN > messages that could potentially harm existing systems, so outbound is > responsible for providing reasonable safeguards. i don't buy that. stun port can be configured on many UAs. it is thus easy to set it to 5060. proxies should be build to last any non-sip packets. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 12:48:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzFxR-00070V-Iu; Sat, 08 Jul 2006 12:47:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzFxQ-0006w7-D0 for sip@ietf.org; Sat, 08 Jul 2006 12:47:04 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzFxO-0004G4-NE for sip@ietf.org; Sat, 08 Jul 2006 12:47:04 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 800B46E0001; Sat, 8 Jul 2006 18:47:01 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 18:47:01 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 18:47:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Sat, 8 Jul 2006 18:45:31 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5940294EB56@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on Outbound? Thread-Index: Acaipb3zjJtuSD5IQOKf/9hsBDgg2gACC74s References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com><553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com><003e01c69fb1$ad32e760$31713b51@BEMBUSTER><17579.25760.584180.394914@rautu.tutpro.com><005c01c6a00c$47763a20$31713b51@BEMBUSTER><17579.31823.351859.567955@rautu.tutpro.com><5EB80D22825EEE42872083AD5BFFB5940294EB44@esealmw113.eemea.ericsson.se> <17583.54122.434147.549688@rautu.tutpro.com> From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 08 Jul 2006 16:47:01.0023 (UTC) FILETIME=[224EB2F0:01C6A2AE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Cullen Jennings , sip@ietf.org, dean.willis@softarmor.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The subjects says "Ready for WGLC on Outbound", and currently the usage = of STUN for keep-alive is defined in that draft. Where do you see the = word "proxy" in the subject line??? ________________________________ From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Sat 08/07/2006 17:46 To: Christer Holmberg (JO/LMF) Cc: Jeroen van Bemmel; Cullen Jennings; sip@ietf.org; = dean.willis@softarmor.com; rohan@ekabal.com Subject: RE: [Sip] Ready for WGLC on Outbound? Christer Holmberg (JO/LMF) writes: > Does a proxy supporting STUN keep-alive have to be an "outbound > proxy" (assuming you mean an edge proxy), as defind in the outbound > spec? i don't know or care. see subject line. this thread is about outbound proxies. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 12:52:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzG17-00083q-AM; Sat, 08 Jul 2006 12:50:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzG16-0007wS-2V for sip@ietf.org; Sat, 08 Jul 2006 12:50:52 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzG11-0004T0-GG for sip@ietf.org; Sat, 08 Jul 2006 12:50:52 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9DBA66E0001; Sat, 8 Jul 2006 18:50:46 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 18:50:46 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 18:50:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: Validating if the proxy supports outbound or not Date: Sat, 8 Jul 2006 18:49:53 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5940294EB57@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Validating if the proxy supports outbound or not Thread-Index: AcaipNR2ILE8pzJzRUCyszwqrIjmwgACbR/C References: <44ACA454.3030800@nostrum.com><8B1D53AEF7B03449A6D3771B3B7F850F0280DF24@esebe103.NOE.Nokia.com> <17583.53696.438432.812866@rautu.tutpro.com> From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" , X-OriginalArrivalTime: 08 Jul 2006 16:50:46.0014 (UTC) FILETIME=[A86999E0:01C6A2AE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, rohan@ekabal.com, adam@nostrum.com, BPenfield@acmepacket.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha, how do you define an "oubound proxy"? =20 Is a proxy that supports STUN for keep-alive, but nothing else, an = outbound proxy? ________________________________ From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Sat 08/07/2006 17:39 To: Erkki.Koivusalo@nokia.com Cc: sip@ietf.org; rohan@ekabal.com; adam@nostrum.com; = BPenfield@acmepacket.com Subject: RE: [Sip] Outbound: Validating if the proxy supports outbound = or not Erkki.Koivusalo@nokia.com writes: > The comments sent on the list during last few days seem to > indicate reasonably large concern that it is not sufficient > for the UA to check that the configured proxy URI contains > keepalive=3Dstun parameter, in order for the UA to make sure > that the proxy actually supports outbound. erkki, i don't understand this concern. your own outbound discovery draft allows finding out outbound and non-outbound proxies of a domain. if proxy is outbound proxy, it of course support stun keepalives. if not, it doesn't. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 13:11:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGJm-00006J-Qe; Sat, 08 Jul 2006 13:10:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGJl-00006E-LU for sip@ietf.org; Sat, 08 Jul 2006 13:10:09 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzGJk-0004yX-AY for sip@ietf.org; Sat, 08 Jul 2006 13:10:09 -0400 Received: by tutpro.com (Postfix, from userid 65534) id BF1DD1400C8; Sat, 8 Jul 2006 20:09:59 +0300 (EEST) Received: from rautu (guanine140.gprs.dnafinland.fi [62.78.120.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id B742D1400C5; Sat, 8 Jul 2006 20:09:43 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 83202F03C1; Sat, 8 Jul 2006 20:09:51 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17583.59103.225110.806776@rautu.tutpro.com> Date: Sat, 8 Jul 2006 20:09:51 +0300 From: Juha Heinanen To: Adam Roach Subject: Re: [Sip] Outbound Comment: q-value In-Reply-To: <44AD4A76.6070309@estacado.net> References: <44AC9C9F.1000701@nostrum.com> <17580.44383.443990.716678@rautu.tutpro.com> <44AD4A76.6070309@estacado.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Cullen Jennings , SIP WG , Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Adam Roach writes: > I'm suggesting a third bullet that reads something like: > > * If multiple bindings have the same instance-id, the proxy MUST NOT > use a binding until all bindings of greater q-value have been tried. if outbound set has two proxies and UA registers with one using q value 0.5 and with the other using q value 0.6, there would be only one binding per proxy. in that case, i hope you are not suggesting that one proxy asks the other if it has higher q value for the same instance id. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 13:13:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGL5-0002QT-1d; Sat, 08 Jul 2006 13:11:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGL4-0002QL-7h for sip@ietf.org; Sat, 08 Jul 2006 13:11:30 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzGL1-00052c-Se for sip@ietf.org; Sat, 08 Jul 2006 13:11:30 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 584181400C8; Sat, 8 Jul 2006 20:11:24 +0300 (EEST) Received: from rautu (guanine140.gprs.dnafinland.fi [62.78.120.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id A28D51400C5; Sat, 8 Jul 2006 20:11:13 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 6CFA3F03C1; Sat, 8 Jul 2006 20:11:26 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17583.59198.391812.55065@rautu.tutpro.com> Date: Sat, 8 Jul 2006 20:11:26 +0300 From: Juha Heinanen To: "Hadriel Kaplan" Subject: RE: [Sip] A coment to draft-ietf-sip-outbound-04 In-Reply-To: <039e01c6a125$ce062950$a7c8000a@acmepacket.com> References: <17580.7810.687558.525897@rautu.tutpro.com> <039e01c6a125$ce062950$a7c8000a@acmepacket.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel Kaplan writes: > > in the above situation, assuming that network has two proxies, if UA > > decides to establish only one flow instead of two, then the likely hood > > is 50% that incoming call to the UA cannot be establishes. it thus > > makes no sense for the UA to violate network policy on number of flows. > > That doesn't make any sense to me. obviously you didn't notice that in the example there was two proxies, one flow to each. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 13:14:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGMN-0003xQ-B8; Sat, 08 Jul 2006 13:12:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGMM-0003xL-Py for sip@ietf.org; Sat, 08 Jul 2006 13:12:50 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzGML-0005JX-Es for sip@ietf.org; Sat, 08 Jul 2006 13:12:50 -0400 Received: by tutpro.com (Postfix, from userid 65534) id CD5781400C8; Sat, 8 Jul 2006 20:12:45 +0300 (EEST) Received: from rautu (guanine140.gprs.dnafinland.fi [62.78.120.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 0B66B1400C5; Sat, 8 Jul 2006 20:12:35 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 47113F03C1; Sat, 8 Jul 2006 20:12:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17583.59280.231609.364622@rautu.tutpro.com> Date: Sat, 8 Jul 2006 20:12:48 +0300 From: Juha Heinanen To: Jonathan Rosenberg Subject: Re: [Sip] Ready for WGLC on Outbound? In-Reply-To: <44AD5137.4050601@cisco.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <44AD5137.4050601@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Cullen Jennings , sip@ietf.org, dean.willis@softarmor.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg writes: > Finally, let me say that if you have a proxy that crashes on receipt of > binary messages on its sip port, you are in for real trouble. fully agree. let's close this tread. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 13:24:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGWN-0000DG-N5; Sat, 08 Jul 2006 13:23:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGWM-0000DB-Nv for sip@ietf.org; Sat, 08 Jul 2006 13:23:10 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzGWL-0005XL-CS for sip@ietf.org; Sat, 08 Jul 2006 13:23:10 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 905DF1400C8; Sat, 8 Jul 2006 20:23:05 +0300 (EEST) Received: from rautu (guanine140.gprs.dnafinland.fi [62.78.120.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 4292D1400C5; Sat, 8 Jul 2006 20:22:55 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 39BE9F03C1; Sat, 8 Jul 2006 20:23:08 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17583.59900.171344.986622@rautu.tutpro.com> Date: Sat, 8 Jul 2006 20:23:08 +0300 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] Ready for WGLC on Outbound? In-Reply-To: <44AE14E2.6040700@softarmor.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> <44AE14E2.6040700@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Cullen Jennings , sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > What do you mean "require"? Use a proxy-require option tag? no, we simply say that outbound proxy MUST support stun keepalives. > Or just hope it won't melt when you send it a STUN packet, meaning that > you "require the operator to get it right". > The problem as I see it is we have no way of easily detecting an error > if somebody mistakenly lists a non-compliant proxy as an outbound proxy > in DHCP or some other discovery mechanism. I hate leaping off a trapeze > without a safety net . . . no properly implemented proxy melts no matter what you sent to it. this kind of arguments are completely bogus. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 13:35:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGgt-0006wv-SE; Sat, 08 Jul 2006 13:34:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGgs-0006we-53 for sip@ietf.org; Sat, 08 Jul 2006 13:34:02 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzGgp-00068D-DM for sip@ietf.org; Sat, 08 Jul 2006 13:34:02 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 93D651400C8; Sat, 8 Jul 2006 20:33:55 +0300 (EEST) Received: from rautu (guanine140.gprs.dnafinland.fi [62.78.120.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 08B231400C5; Sat, 8 Jul 2006 20:33:45 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 2B4E6F03C1; Sat, 8 Jul 2006 20:33:57 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17583.60549.106403.319239@rautu.tutpro.com> Date: Sat, 8 Jul 2006 20:33:57 +0300 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] Ready for WGLC on Outbound? In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5940294EB56@esealmw113.eemea.ericsson.se> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> <005c01c6a00c$47763a20$31713b51@BEMBUSTER> <17579.31823.351859.567955@rautu.tutpro.com> <5EB80D22825EEE42872083AD5BFFB5940294EB44@esealmw113.eemea.ericsson.se> <17583.54122.434147.549688@rautu.tutpro.com> <5EB80D22825EEE42872083AD5BFFB5940294EB56@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Cullen Jennings , sip@ietf.org, dean.willis@softarmor.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) writes: > The subjects says "Ready for WGLC on Outbound", and currently the > usage of STUN for keep-alive is defined in that draft. yes, but only in connection with outbound proxies. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 13:39:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGkX-0008Gs-Aj; Sat, 08 Jul 2006 13:37:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGkW-0008Gm-16 for sip@ietf.org; Sat, 08 Jul 2006 13:37:48 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzGkU-0006XH-MY for sip@ietf.org; Sat, 08 Jul 2006 13:37:48 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 1697D1400C8; Sat, 8 Jul 2006 20:37:43 +0300 (EEST) Received: from rautu (guanine140.gprs.dnafinland.fi [62.78.120.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 7F3B71400C5; Sat, 8 Jul 2006 20:37:32 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id CACD2F03C1; Sat, 8 Jul 2006 20:37:45 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17583.60777.750733.549711@rautu.tutpro.com> Date: Sat, 8 Jul 2006 20:37:45 +0300 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] Outbound: Validating if the proxy supports outbound or not In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5940294EB57@esealmw113.eemea.ericsson.se> References: <44ACA454.3030800@nostrum.com> <8B1D53AEF7B03449A6D3771B3B7F850F0280DF24@esebe103.NOE.Nokia.com> <17583.53696.438432.812866@rautu.tutpro.com> <5EB80D22825EEE42872083AD5BFFB5940294EB57@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: sip@ietf.org, rohan@ekabal.com, adam@nostrum.com, BPenfield@acmepacket.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) writes: > Is a proxy that supports STUN for keep-alive, but nothing else, an > outbound proxy? no. why you ask me? see section 5 of outbound. but i will give up this tread now. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 13:49:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGuH-0000N6-90; Sat, 08 Jul 2006 13:47:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGuF-0000N1-6Y for sip@ietf.org; Sat, 08 Jul 2006 13:47:51 -0400 Received: from [2001:5c0:8fff:fffe::4c49] (helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzGuB-00083M-PE for sip@ietf.org; Sat, 08 Jul 2006 13:47:51 -0400 Received: from [142.157.201.14] (dhcp201014.rez.mcgill.ca [142.157.201.14]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k68HlhGu003501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Jul 2006 12:47:44 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44AFEFAC.4030909@nostrum.com> Date: Sat, 08 Jul 2006 12:47:24 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: SIP WG Subject: Re: [Sip] Outbound Comment: q-value References: <44AC9C9F.1000701@nostrum.com> <17580.44383.443990.716678@rautu.tutpro.com> <44AD4A76.6070309@estacado.net> <17583.59103.225110.806776@rautu.tutpro.com> In-Reply-To: <17583.59103.225110.806776@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 142.157.201.14 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Adam Roach writes: > > > I'm suggesting a third bullet that reads something like: > > > > * If multiple bindings have the same instance-id, the proxy MUST NOT > > use a binding until all bindings of greater q-value have been tried. > > if outbound set has two proxies and UA registers with one using q value > 0.5 and with the other using q value 0.6, there would be only one > binding per proxy. in that case, i hope you are not suggesting that one > proxy asks the other if it has higher q value for the same instance id. > I'm not adding any new requirements here. The following bullet has identical implications: o If two bindings have the same instance-id and reg-id, the proxy SHOULD prefer the contact that was most recently updated. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 14:03:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzH7i-0003og-8Z; Sat, 08 Jul 2006 14:01:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzH7g-0003ob-WA for sip@ietf.org; Sat, 08 Jul 2006 14:01:44 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzH7f-0004kF-HO for sip@ietf.org; Sat, 08 Jul 2006 14:01:44 -0400 Received: (qmail 2081 invoked by uid 0); 8 Jul 2006 18:01:41 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 8 Jul 2006 18:01:41 -0000 Message-ID: <04a801c6a2b8$8d48d2c0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Juha Heinanen" , "Hadriel Kaplan" References: <17580.7810.687558.525897@rautu.tutpro.com><039e01c6a125$ce062950$a7c8000a@acmepacket.com> <17583.59198.391812.55065@rautu.tutpro.com> Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Sat, 8 Jul 2006 20:01:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha, Hadriel is not the only one who was puzzled by this, so was I. I've been trying to follow your reasoning, and I think I now know where this confusion comes from The reason outbound introduces multiple flows is stated in the introduction: "[...] Since such detection takes time and leaves a window of opportunity for missed incoming requests, this mechanism allows the UA to use multiple flows to the proxy or registrar." I read this as "multiple flows to the *same, single* proxy or registrar". When reading this, I think "ah, that makes sense, because NAT devices can be unstable and drop flows all the time, and keepalive messages could get lost". So I interpret this as protection against failing NAT devices, and *not* against failing proxies. This is why I initially did not understand why things would break if a UA sets up only 1 flow, instead of 2. This makes sense only in case of flows to *distinct* proxies, ie your 50% scheme below. What you are doing, is saying: "ah, outbound gives me multiple flows, and that is its main benefit (and not NAT traversal)". So you take something that is only a side effect of the main intention of the draft, and turn it around by assuming that flows go to different proxies. Probably inspired by section 3.3 which does this too. My conclusion is that all this reliability stuff (mainly section 3.3 and part of section 3.4) is a *separate issue*, and has nothing to do with the core of outbound. It should not be in this draft, because it is confusing and - as the text already points out - only one of many ways to provide reliability. Section 3.4 should be rewritten to consider the case of a UA, a *single* edge proxy, and a registrar. By including two edge proxies here, two different issues are introduced: 1) how does one do outbound in case of an edge proxy and 2) how does one deal with multiple edge proxies. Again, separate that please! Regards, Jeroen ----- Original Message ----- From: "Juha Heinanen" To: "Hadriel Kaplan" Cc: Sent: Saturday, July 08, 2006 7:11 PM Subject: RE: [Sip] A coment to draft-ietf-sip-outbound-04 > Hadriel Kaplan writes: > > > > in the above situation, assuming that network has two proxies, if UA > > > decides to establish only one flow instead of two, then the likely > > > hood > > > is 50% that incoming call to the UA cannot be establishes. it thus > > > makes no sense for the UA to violate network policy on number of > > > flows. > > > > That doesn't make any sense to me. > > obviously you didn't notice that in the example there was two proxies, > one flow to each. > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 14:30:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzHXj-000052-9Z; Sat, 08 Jul 2006 14:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzHXi-0008WS-BD for sip@ietf.org; Sat, 08 Jul 2006 14:28:38 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzHXh-0006GA-0j for sip@ietf.org; Sat, 08 Jul 2006 14:28:38 -0400 Received: by tutpro.com (Postfix, from userid 65534) id B24721400C8; Sat, 8 Jul 2006 21:28:32 +0300 (EEST) Received: from rautu (guanine140.gprs.dnafinland.fi [62.78.120.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id D1BB81400C5; Sat, 8 Jul 2006 21:28:21 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id B9830F03C1; Sat, 8 Jul 2006 21:28:30 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17583.63822.302979.834665@rautu.tutpro.com> Date: Sat, 8 Jul 2006 21:28:30 +0300 From: Juha Heinanen To: "Jeroen van Bemmel" Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 In-Reply-To: <04a801c6a2b8$8d48d2c0$31713b51@BEMBUSTER> References: <17580.7810.687558.525897@rautu.tutpro.com> <039e01c6a125$ce062950$a7c8000a@acmepacket.com> <17583.59198.391812.55065@rautu.tutpro.com> <04a801c6a2b8$8d48d2c0$31713b51@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org jeroen, multiple flows to the same proxy is not interesting. the only added value of outbound is multiple flows to more than one proxy. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 14:45:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzHlt-0002De-Ca; Sat, 08 Jul 2006 14:43:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzHlr-00028n-4l for sip@ietf.org; Sat, 08 Jul 2006 14:43:15 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzHlp-0008G0-P6 for sip@ietf.org; Sat, 08 Jul 2006 14:43:15 -0400 Received: (qmail 12473 invoked by uid 0); 8 Jul 2006 18:43:06 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 8 Jul 2006 18:43:06 -0000 Message-ID: <04cf01c6a2be$5958de00$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" , "Cullen Jennings" References: <17580.7810.687558.525897@rautu.tutpro.com><039e01c6a125$ce062950$a7c8000a@acmepacket.com><17583.59198.391812.55065@rautu.tutpro.com><04a801c6a2b8$8d48d2c0$31713b51@BEMBUSTER> <17583.63822.302979.834665@rautu.tutpro.com> Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Sat, 8 Jul 2006 20:43:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org, Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear outbound authors, Could you share your thoughts on the view Juha is expressing below? Regards, Jeroen ----- Original Message ----- From: "Juha Heinanen" To: "Jeroen van Bemmel" Cc: "Hadriel Kaplan" ; Sent: Saturday, July 08, 2006 8:28 PM Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 > jeroen, > > multiple flows to the same proxy is not interesting. the only added > value of outbound is multiple flows to more than one proxy. > > -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 15:17:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzIGu-0006Mu-F3; Sat, 08 Jul 2006 15:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzIGr-0006Ml-N7 for sip@ietf.org; Sat, 08 Jul 2006 15:15:18 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzIGp-00019c-Bo for sip@ietf.org; Sat, 08 Jul 2006 15:15:17 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 18D6F1400CA; Sat, 8 Jul 2006 22:15:11 +0300 (EEST) Received: from rautu (guanine140.gprs.dnafinland.fi [62.78.120.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 2E7151400C8; Sat, 8 Jul 2006 22:15:00 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 3AD12F03C1; Sat, 8 Jul 2006 22:15:11 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17584.1087.152540.596341@rautu.tutpro.com> Date: Sat, 8 Jul 2006 22:15:11 +0300 From: Juha Heinanen To: "Jeroen van Bemmel" Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 In-Reply-To: <04cf01c6a2be$5958de00$31713b51@BEMBUSTER> References: <17580.7810.687558.525897@rautu.tutpro.com> <039e01c6a125$ce062950$a7c8000a@acmepacket.com> <17583.59198.391812.55065@rautu.tutpro.com> <04a801c6a2b8$8d48d2c0$31713b51@BEMBUSTER> <17583.63822.302979.834665@rautu.tutpro.com> <04cf01c6a2be$5958de00$31713b51@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel writes: > Could you share your thoughts on the view Juha is expressing below? jeroen, are you saying that if outbound-proxy-set consists of two sip uris, it would be ok if the UA sets up two flows to one of them and no flow to the other one? if this is allowed by outbound i-d, then i have wasted my (and other people's) time on it. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 15:21:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzIKo-0006pl-6d; Sat, 08 Jul 2006 15:19:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzIKn-0006pg-Dm for sip@ietf.org; Sat, 08 Jul 2006 15:19:21 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzIKl-0001VO-Ks for sip@ietf.org; Sat, 08 Jul 2006 15:19:21 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CD72A6E0001; Sat, 8 Jul 2006 21:19:18 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 21:19:18 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 21:19:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Sat, 8 Jul 2006 21:19:17 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5940294EB58@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on Outbound? Thread-Index: AcaitLConRcvIa26QiypXwAYT2Kr8wADP7wh References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com><553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com><003e01c69fb1$ad32e760$31713b51@BEMBUSTER><17579.25760.584180.394914@rautu.tutpro.com><005c01c6a00c$47763a20$31713b51@BEMBUSTER><17579.31823.351859.567955@rautu.tutpro.com><5EB80D22825EEE42872083AD5BFFB5940294EB44@esealmw113.eemea.ericsson.se><17583.54122.434147.549688@rautu.tutpro.com><5EB80D22825EEE42872083AD5BFFB5940294EB56@esealmw113.eemea.ericsson.se> <17583.60549.106403.319239@rautu.tutpro.com> From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 08 Jul 2006 19:19:18.0243 (UTC) FILETIME=[6883D330:01C6A2C3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Cullen Jennings , sip@ietf.org, dean.willis@softarmor.com, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> The subjects says "Ready for WGLC on Outbound", and currently the >> usage of STUN for keep-alive is defined in that draft. >yes, but only in connection with outbound proxies. There is an ongoing discussion related to documenting it as a standalone = feature, and one of the options IS to document that standalone feature = in the outbound draft. =20 I fully agree on the comments saying that a proxy should be able to = receive STUN without crashing (it may enable some black-list functions = etc, though, as described by Jeroen). However, I DO think it's a bad = standard when you send stuff without knowing if the receiver supports it = or not. In SIP we do use mechanisms (error codes, headers etc) to = indicate what entities support and don't support, and I don't see why we = shouldn't be able to do that also in this case. =20 =20 Regards, =20 Christer =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 15:49:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzIm1-0000Uz-1l; Sat, 08 Jul 2006 15:47:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzIlz-0000U6-F0 for sip@ietf.org; Sat, 08 Jul 2006 15:47:27 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzIlw-0005DX-Rw for sip@ietf.org; Sat, 08 Jul 2006 15:47:27 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 142DB6E0001; Sat, 8 Jul 2006 21:47:24 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 21:47:23 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 21:47:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: STUN keep-alive: Where to document it? (was [Sip] Re: A coment to draft-ietf-sip-outbound-04) Date: Sat, 8 Jul 2006 21:47:22 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5940294EB59@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: STUN keep-alive: Where to document it? (was [Sip] Re: A coment to draft-ietf-sip-outbound-04) Thread-Index: AcaiVVcjQ8rg4yhjTyy9v0QIKEDF6AAbt19s References: <5lMhySMZNSts.P4yLcZSr@se-smtp.ericsson.se> <25779fe3c8df692656b33691abc67cf3@ekabal.com> From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" , X-OriginalArrivalTime: 08 Jul 2006 19:47:23.0500 (UTC) FILETIME=[5501A2C0:01C6A2C7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Miguel Garcia , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Moving the discussion from the "[Sip] Re: A coment to = draft-ietf-sip-outbound-04" thread: =20 Rohan wrote: =20 >> Also, if a client uses STUN keepalive, but not the rest of outbound >> (instance-id etc) it would not make sense trying to send multiple >> registrations, since the registrar would not be able to differentiate >> the "flows". I think that needs to be clear in the spec, a part of >> defining the STUN keepalive as a standalone function. >I actually understand the motivation for this one. The issue is how >much of the STUN keepalive mechanism belongs in 3489bis, how much could >go in outbound in a separate section (or a separate document), and how >much is specific to outbound. =20 My proposal would be: =20 3489bis: ----------- =20 - We pretty much leave the text as it is. 3489bis is not SIP specific, = but we could say how it can be used to detect whether the NAT has = re-booted (checking the XOR-xxx value in the STUN response). I believe = that is currently said in the outbound spec, but it's not outbound = specific. I don't have the specs in front of me, so I may be wrong... =20 =20 Outbound spec: ---------------------- =20 - The outbound spec refers to the SIP STUN keep-alive mechanism (no = matter if described in the outbound draft or a separate draft), says = that it MUST be used with outbound. - That outbound related actions taken if the client detects (from the = STUN response) that the NAT has re-booted. =20 =20 Separate document OR separate section in the outbound spec: -------------------------------------------------------------------------= ---------- =20 - Here we define whatever option-tags and URI parameters are needed for = the SIP usage of STUN keep-alive (NOTE: outbound related option-tags = etc are not defined here) - Here we define how to use it for SIP, e.g. saying that the STUN = messages are sent to the same port as the SIP requests - Here we MAY say something about "generic SIP actions" if the client = detects NAT re-boot, if there is something we don't think is outbound = specific (need to think about that). =20 =20 >I think all the text about what you do when you try to setup a flow and = it doesn't work (retry after x seconds...) is really very >specific to = multiple flows. =20 I agree. "Flow" is an outbound specific term, and has nothing to do with = STUN keep-alive as such. =20 >There is the binding request/response that belongs in 3489bis. What is = unclear to >me is what else is left. Certainly you need some part of a doc that = defines the keepalive URI parameter and updates 3261 to >say it ok to = send STUN on the same port as SIP when you have positive knowledge >(such as the keepalive parameter) that the server is ok with that. =20 Yes. That is pretty much what I suggested above. =20 And, IF some new parameter is needed for the proxy to indicate whether = it supports STUN or not (please let us have that discussion elsewhere - = not in this thread :), it should also be defined here.=20 =20 But, IF we think that the = indicate-what-a-proxy-support-and-does-not-support mechanism itself is = GENERIC, and not only related to STUN (in future there may be other = extensions where it's needed), that should of course then be described = in a dedicated document. But, let's have that discussion elsewhere also = :) =20 Regards, =20 Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 17:02:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzJvA-0005Ed-7M; Sat, 08 Jul 2006 17:01:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzJv8-0005EY-3T for sip@ietf.org; Sat, 08 Jul 2006 17:00:58 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzJv7-0004KQ-H3 for sip@ietf.org; Sat, 08 Jul 2006 17:00:58 -0400 Received: (qmail 27866 invoked by uid 0); 8 Jul 2006 21:00:49 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 8 Jul 2006 21:00:49 -0000 Message-ID: <04ee01c6a2d1$963ca820$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Christer Holmberg \(JO/LMF\)" , "Rohan Mahy" , References: <5lMhySMZNSts.P4yLcZSr@se-smtp.ericsson.se><25779fe3c8df692656b33691abc67cf3@ekabal.com> <5EB80D22825EEE42872083AD5BFFB5940294EB59@esealmw113.eemea.ericsson.se> Subject: Re: STUN keep-alive: Where to document it? (was [Sip] Re: A coment todraft-ietf-sip-outbound-04) Date: Sat, 8 Jul 2006 23:00:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.2 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Miguel Garcia , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, And don't forget UA-UA keep-alives (and thus the need for a UAC/UAS to indicate support). Once the UA registers using outbound, at one point it's going to want to make a call (or subscribe, or whatever). I'd like to avoid a situation in which some proxy must always record-route for this to work (think eg about SIPSEC) Also, I've been considering the following: what if we would reverse the client/server roles for STUN in outbound? Have the proxy initiate binding requests, and the UA answer them. Then the proxy can have more control over its load, and there is no risk that a non-outbound proxy gets STUNned. Just a thought... Regards, Jeroen ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" To: "Rohan Mahy" ; Cc: "Miguel Garcia" ; "Cullen Jennings" Sent: Saturday, July 08, 2006 9:47 PM Subject: STUN keep-alive: Where to document it? (was [Sip] Re: A coment todraft-ietf-sip-outbound-04) Moving the discussion from the "[Sip] Re: A coment to draft-ietf-sip-outbound-04" thread: Rohan wrote: >> Also, if a client uses STUN keepalive, but not the rest of outbound >> (instance-id etc) it would not make sense trying to send multiple >> registrations, since the registrar would not be able to differentiate >> the "flows". I think that needs to be clear in the spec, a part of >> defining the STUN keepalive as a standalone function. >I actually understand the motivation for this one. The issue is how >much of the STUN keepalive mechanism belongs in 3489bis, how much could >go in outbound in a separate section (or a separate document), and how >much is specific to outbound. My proposal would be: 3489bis: ----------- - We pretty much leave the text as it is. 3489bis is not SIP specific, but we could say how it can be used to detect whether the NAT has re-booted (checking the XOR-xxx value in the STUN response). I believe that is currently said in the outbound spec, but it's not outbound specific. I don't have the specs in front of me, so I may be wrong... Outbound spec: ---------------------- - The outbound spec refers to the SIP STUN keep-alive mechanism (no matter if described in the outbound draft or a separate draft), says that it MUST be used with outbound. - That outbound related actions taken if the client detects (from the STUN response) that the NAT has re-booted. Separate document OR separate section in the outbound spec: ----------------------------------------------------------------------------------- - Here we define whatever option-tags and URI parameters are needed for the SIP usage of STUN keep-alive (NOTE: outbound related option-tags etc are not defined here) - Here we define how to use it for SIP, e.g. saying that the STUN messages are sent to the same port as the SIP requests - Here we MAY say something about "generic SIP actions" if the client detects NAT re-boot, if there is something we don't think is outbound specific (need to think about that). >I think all the text about what you do when you try to setup a flow and it >doesn't work (retry after x seconds...) is really very >specific to >multiple flows. I agree. "Flow" is an outbound specific term, and has nothing to do with STUN keep-alive as such. >There is the binding request/response that belongs in 3489bis. What is >unclear to >me is what else is left. Certainly you need some part of a doc that >defines the keepalive URI parameter and updates 3261 to >say it ok to send >STUN on the same port as SIP when you have positive knowledge >(such as the keepalive parameter) that the server is ok with that. Yes. That is pretty much what I suggested above. And, IF some new parameter is needed for the proxy to indicate whether it supports STUN or not (please let us have that discussion elsewhere - not in this thread :), it should also be defined here. But, IF we think that the indicate-what-a-proxy-support-and-does-not-support mechanism itself is GENERIC, and not only related to STUN (in future there may be other extensions where it's needed), that should of course then be described in a dedicated document. But, let's have that discussion elsewhere also :) Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 18:11:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzKzh-0002jy-AS; Sat, 08 Jul 2006 18:09:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzKzf-0002jt-7c for sip@ietf.org; Sat, 08 Jul 2006 18:09:43 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzKzd-0008RX-Uy for sip@ietf.org; Sat, 08 Jul 2006 18:09:43 -0400 Received: from [162.83.109.253] (helo=JMHLap3.stevecrocker.com) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FzKzd-0005zL-HN for sip@ietf.org; Sat, 08 Jul 2006 18:09:41 -0400 Message-Id: <7.0.1.0.0.20060708174448.03338828@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 08 Jul 2006 18:09:38 -0400 To: sip@ietf.org From: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112063f3c8c75eb6fcdce2a1350d21934efc6375de8276a6ac97350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 162.83.109.253 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Sip] Outbound and multiple connections X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have been watching this ongoing discussion with some bemusement. It appears that there are two very different views of the purpose for the multiple connections specified in draft-ietf-sip-outbound-04.txt. There also seems to be some discrepancies about where the multiple connections go. With regard to purpose, the question I see is whether the reliability is for the clients benefit, or the networks. If it is for the client's benefit, then as has been suggested the client should be able to choose whether to take advantage of it or not. The multiple connections ought not be MUST strength. On the other hand, if it is a mechanism to enable the network to offer better service (particularly, better service to incoming requests) then the network would reasonably expect the multiple connections, and so the usage should be a MUST. --Personally, I think that network techniques for providing reliability are the network's job / business, and so the multiple connections are about the clients desire for reliability, and ought to be SHOULD, or even MAY strength. I believe that the above alternatives lead to confusion about the draft. Further, I think that there is related confusion about the usage of the multiple connections. I note that the wording of the draft is very fuzzy as to whether the multiple connections are to the same server, multiple "closely coupled" servers, or distinct servers. I had assumed that the connections would be to distinct servers. However, re-reading the draft I see wording like (3.1) "it [proxy] can use any one of the flows on which a successful registration has been completed." For a proxy to have several flows would imply that the client connected to the same server multiple times. is in order. Wording in section 3.2 also talks about the proxy, which is the registrar, having multiple connections to the target. I suspect that all the wording about a single registrar is to be interpreted in conjunction with the example case (3.3) of a single registrar that is actually two "closely coupled" hosts. This is a perfectly reasonable deployment. However, I think we would be much better off describing this as if it were two registrars, and indicating that coordination among the registrars is outside of the scope of this draft. And we ought not require that they be closely coupled. Whatever the actual intent of the authors of 3.1, 3.2, and 3.3, we need to decide what we want it to mean, and clarify the wording so that it says that, clearly. Yours, Joel M. Halpern PS: I believe the reference in section 4.4 to "Section 4.2 to form a new flow" is actually a reference to 4.4.2? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 18:53:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzLee-0005mk-7p; Sat, 08 Jul 2006 18:52:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzLec-0005mf-QZ for sip@ietf.org; Sat, 08 Jul 2006 18:52:02 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzLea-0007Cz-4K for sip@ietf.org; Sat, 08 Jul 2006 18:52:02 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E3C1569E; Sun, 9 Jul 2006 00:51:58 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Jul 2006 00:51:58 +0200 Received: from [136.225.183.114] ([136.225.183.114]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Jul 2006 00:51:55 +0200 From: "Christer Holmberg" To: "Jeroen van Bemmel" , "Rohan Mahy" , sip@ietf.org Subject: Re: STUN keep-alive: Where to document it? (was [Sip] Re: A coment todraft-ietf-sip-outbound-04) Date: Sun, 9 Jul 2006 01:52:05 +0300 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Jul 2006 22:51:57.0950 (UTC) FILETIME=[1DE499E0:01C6A2E1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Miguel Garcia , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I guess we would need an option tag for the UAC/UAS to indicate the = support. When it comes to the edge proxy sending the STUN requests, that is probably = the same thing as the "network initiated keepalive" mechanism I proposed = while we were still discussing whether we are going to use STUN in the = first place. I did not propose STUN at that point, but anything that = triggers a message (a response in the STUN case) to be sent back from the = client towards the edge proxy (some NATs require keepalive traffic in that = direction in order to keep the bindings open). One issue with that proposal was that the client doesn't know if e.g. a NAT = is rebooting. It would require some timer, so that the client can assume a = reboot has occured if it doesn't receive a STUN request before the timer = expires. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 19:13:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzLxq-0000Zm-Dr; Sat, 08 Jul 2006 19:11:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzLxp-0000Zg-1U for sip@ietf.org; Sat, 08 Jul 2006 19:11:53 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzLxm-0007bk-L1 for sip@ietf.org; Sat, 08 Jul 2006 19:11:53 -0400 Received: (qmail 12916 invoked by uid 0); 8 Jul 2006 23:11:49 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 8 Jul 2006 23:11:49 -0000 Message-ID: <001401c6a2e3$dfe48850$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Christer Holmberg" , "Rohan Mahy" , References: Subject: Re: STUN keep-alive: Where to document it? (was [Sip] Re: A coment todraft-ietf-sip-outbound-04) Date: Sun, 9 Jul 2006 01:11:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Miguel Garcia , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, >One issue with that proposal was that the client doesn't know if e.g. a NAT >is rebooting. It would require some timer, so that the client can assume a >reboot has >occured if it doesn't receive a STUN request before the timer >expires. Also client-initiated STUN requires such a periodic timer. Furthermore, sending a STUN request and then waiting for a response also implicitly uses a timer (typical implementation is the sending thread blocking on some event with a timeout, reception of the response setting this event) I just scanned briefly through RFC3489bis section 7.1. It appears that much more needs to be said on exactly how STUN is to be done. For example, RFC3489bis suggests a retransmission scheme with timeout after 9500ms for UDP; for TCP it says "SHOULD NOT retransmit", but what should be used for timeout? Surely not 9.5 seconds? And compared to SIP standard timings, a retransmission after 100ms (UDP) seems rather quick... Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 22:01:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzOaU-0001C9-Lj; Sat, 08 Jul 2006 21:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzOaT-0001C4-OG for sip@ietf.org; Sat, 08 Jul 2006 21:59:57 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzOaS-0005Lb-BB for sip@ietf.org; Sat, 08 Jul 2006 21:59:57 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k691xlQ11583; Sat, 8 Jul 2006 19:59:47 -0600 Message-ID: <44B06315.80104@ntt-at.com> Date: Sat, 08 Jul 2006 18:59:49 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Dan Wing Subject: Re: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt References: <000401c6a22c$e47659a0$d351150a@amer.cisco.com> In-Reply-To: <000401c6a22c$e47659a0$d351150a@amer.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: sip@ietf.org, "'Elwell, John'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I generally like the draft, and I think the work is very important. Anyhow, AFAIK there is no distinct way to request SIP-Identity to AS, so just because one receives a sip-identity/id-change tag does not necessary mean that sender of an UPDATE will be able to send the sip-identity back(Even if the UAS supports sip-identity/id-change, the domain of the UAS might not have AS in place to provide sip-identity). This is because there is no option tag to require proxy to add sip-identity, and because sip-identity is generally performed at AS, UA is generally unaware of the domian's support for sip-identity. Furthermore, because its the AS that adds sip-identity(except when UA has its own certificate which I think is unlikely), just because UA receives the sip-identity, does not necessary mean that UA sending the original INVITE(offerer that you have described in your comment) with identity-info header supports sip-identity. Last note, looking at the sentence in 6.1 which is shown below, I am not sure if mandating UA to send an UPDATE to update its identity is aligned with the semantics of Supported header field. I don't really have a strong opinion on this point, but it felt a little funny to mandate a behavior with a presence of "Supported" header. Thanks & Regards Shida Dan Wing wrote: > I hadn't noticed any followups to this issue. I have a suggestion: > > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Tuesday, May 02, 2006 1:21 PM >> To: sip@ietf.org >> Subject: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt >> >> The second issue concerns the fact that an UPDATE request in the >> backward direction following dialog establishment can be wasted if >> the peer UA (the UAC for the INVITE transaction) does not support >> it. It states: >> >> "OPEN ISSUE: If the identity has has not changed compared with >> the URI in the To header field and the UAC (for the INVITE >> request) does not support verification of an Identity header, >> this UPDATE or re-INVITE transaction would fulfil no useful >> purpose. However, the UAS (for the INVITE transaction) does >> not know this. In order to save this round trip, should we >> have an additional option tag to indicate support for receipt >> of the Identity header on mid- dialog requests? Then if this >> option tag is not present in the INVITE request the additional >> transaction could be omitted. Note that the id-change option >> tag does not seem appropriate for this purpose, since a UA >> could support a change of URI without supporting Identity." >> >> Whilst I do not wish to proliferate option tags, I do see some >> benefit in such a tag. Any opinions? >> > > If an Invite arrives with both Identity and the id-change tag, > it indicates the offerer understands both Identity and connected- > identity, so the answerer should generate an request (UPDATE or > re-INVITE). > > -d > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 08 22:11:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzOkO-00076w-85; Sat, 08 Jul 2006 22:10:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzOkM-00075M-91 for sip@ietf.org; Sat, 08 Jul 2006 22:10:10 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzOkK-0006kH-PN for sip@ietf.org; Sat, 08 Jul 2006 22:10:10 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k6924V126350; Sat, 8 Jul 2006 22:04:31 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Proposals for review process to conclude WGLCs Date: Sat, 8 Jul 2006 21:10:04 -0500 Message-ID: In-Reply-To: <93946F5D-56E9-466E-B444-CE19BFFF2E49@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Proposals for review process to conclude WGLCs Thread-Index: Acacg3265m++O3nrS9KuSlNj1fIl/ACUVBdA From: "Mary Barnes" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You can add another vote in support of option 1), as I think it increases the level of commitment for the reviewers, along with the document editor/authors. It might also prove quite useful in terms of resolving some issues in real-time, thus reducing the amount of thrashing on specific issues on the list due to misunderstandings via email. As you've already identified, a recorder would be imperative for the process.=20 I also support the idea of SIP doing something different than SIPPING and at year end we can evaluate both options and see what seems to work best. I'm beginning to think the SIPPING approach might be much better applied early in the cycle (i.e, for the first few iterations), but that the conference calls might be the most effective way to handle the WGLCs. =20 Obviously, any of the approaches requires committed and dedicated reviewers for the documents. The response in the SIPPING WG has been pretty good, but I think it would be optimal to add the requirement that a document isn't accepted as a WG document, unless you also have the reviewers committed. This might delay some things, but in my mind, if we don't have WG members committed to the work, along with the editor/authors, we don't have the resources to effectively complete the work (in a timely manner). =20 Mary -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Friday, June 30, 2006 3:26 PM To: IETF SIP List Subject: [Sip] Proposals for review process to conclude WGLCs One of the questions we've struggled with is how to get sufficient =20 review on a document under WGLC to make sure it's really done. SIPPING is following a new procedure with designated reviewers, doing =20 review by email, and sending stuff back to the. Apparently this =20 suffers from the expected issues, with designated reviewers sometimes =20 not quite meeting their review commitments. Cisco made me take a peer-review refresher class the other day, so =20 this started me thinking about some alternatives. In the model taught in this class, each peer review includes 1) a =20 "moderator" or "reader" who frames the questions and keeps things on =20 track, 2) a "recorder" who records conclusions and issues raised =20 during the review, 3) the author(s), who neither presents no =20 interprets the work, but does respond to specific questions about it, =20 and 4) the reviewers, who hopefully have expertise and have committed =20 time to the review. I'd like to propose a couple of alternative models to what SPPING has =20 been doing and seeing if either resonates with our group. 1) Real-time review sessions via conference call: When we get ready =20 to do a final review, the chairs assemble a review team. Presumably, =20 this review team is assembled by polling the list for volunteers, and =20 by pushing extra hard for stakeholders and other people with specific =20 expertise. The moderator builds up a checklist and set of basic =20 questions to consider, and distributes it to the review team. At a =20 tiem agreed to by enough of the participants, we have a conference =20 call, not to exceed two hours, and work through the checklist in a =20 moderated fashion. At the conclusion of that two hours, we either =20 reach a positive decision, a negative decision (with list of issues =20 and actions), or decide we need more review. 2) Moderated email-review, using the entire list as the "review =20 team". In this model, the chairs pick a moderator and recorder for =20 the review. The moderator sets up a checklist and sends it to the =20 list, along with an announcement of the review. The moderator then =20 goes through the checklist item-by-item on list, polling for =20 comments. The recorder records any issues or conclusions. Each item =20 might take two or three days for primary comments, but could be =20 revisited during the review process if needed. The author could =20 answer specific questions about the draft, but not paraphrase or =20 interpret. At the conclusion of the review, the moderator and =20 reviewer would report to the chairs, who would decide whether we have =20 issues, a conclusion, or need further review. What do y'all think? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 00:29:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzQtO-0005wq-KK; Sun, 09 Jul 2006 00:27:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzQtM-0005wi-HY for sip@ietf.org; Sun, 09 Jul 2006 00:27:36 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzQtH-0000PB-2U for sip@ietf.org; Sun, 09 Jul 2006 00:27:33 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 08 Jul 2006 21:27:31 -0700 X-IronPort-AV: i="4.06,220,1149490800"; d="scan'208"; a="304220173:sNHT33391112" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k694RUNS015556; Sat, 8 Jul 2006 21:27:30 -0700 Received: from dwingwxp (sjc-vpn4-33.cisco.com [10.21.80.33]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k694RNsT003978; Sat, 8 Jul 2006 21:27:26 -0700 (PDT) From: "Dan Wing" To: Subject: RE: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt Date: Sun, 9 Jul 2006 00:27:17 -0400 Keywords: direct-to-dwing Message-ID: <033e01c6a30f$fd4e4580$d351150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acai+1yOQqpa/7hFTF6dZvfrAundJQAFCbew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44B06315.80104@ntt-at.com> DKIM-Signature: a=rsa-sha1; q=dns; l=4082; t=1152419250; x=1153283250; c=relaxed/simple; s=sjdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[Sip]=20Issue=202=20in=20draft-ietf-sip-connected-identity-00.tx t; X=v=3Dcisco.com=3B=20h=3DZSIM5S5QfLQbqL0P0FGFNeY7QSc=3D; b=aFbF6hElveV6UEhGAu4itZ661Cjg40kg5Vbz2rAwriYik9l+Bs0r0Z+mlG5AEmOIxhneorXI rJ4yErU+51Kebc4yRFx3nqNNoGnuuOIkTcQ6ygPPR9mkbd/Jml9owX9+; Authentication-Results: sj-dkim-1.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sip@ietf.org, "'Elwell, John'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > I generally like the draft, and I think the work is very important. Me, too. > Anyhow, AFAIK there is no distinct way to request SIP-Identity to > AS, so just because one receives a sip-identity/id-change tag does > not necessary mean that sender of an UPDATE will be able to send > the sip-identity back(Even if the UAS supports sip-identity/id-change, > the domain of the UAS might not have AS in place to provide > sip-identity). Agreed; if we agree we need to optimize that case, we will need an additional option tag. But, still, there isn't a way for a UAS to "know" that his request will be protected with Identity. So I'm not sure of the value such an additional tag would bring over my suggestion. > This is because there is no option tag to require proxy to add > sip-identity, > and because sip-identity is generally performed at AS, UA is generally > unaware of the domian's support for sip-identity. > > Furthermore, because its the AS that adds sip-identity(except when > UA has its own certificate which I think is unlikely), just because UA > receives the sip-identity, does not necessary mean that UA sending > the original INVITE(offerer that you have described in your comment) > with identity-info header supports sip-identity. Even if the original UA itself doesn't support Identity, one of the domain's proxies added the Identity signature and it's likely that proxy may validate incoming requests containing Identity signatures. -d > Last note, looking at the sentence in 6.1 which is shown > below, I am not sure if > mandating UA to send an UPDATE to update its identity is aligned > with the semantics of Supported header field. I don't really > have a strong > opinion on this point, but it felt a little funny to mandate > a behavior with > a presence of "Supported" header. > > Thanks & Regards > Shida > > Dan Wing wrote: > > I hadn't noticed any followups to this issue. I have a suggestion: > > > > > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens.com] > >> Sent: Tuesday, May 02, 2006 1:21 PM > >> To: sip@ietf.org > >> Subject: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt > >> > >> The second issue concerns the fact that an UPDATE request in the > >> backward direction following dialog establishment can be wasted if > >> the peer UA (the UAC for the INVITE transaction) does not support > >> it. It states: > >> > >> "OPEN ISSUE: If the identity has has not changed > compared with > >> the URI in the To header field and the UAC (for the INVITE > >> request) does not support verification of an Identity header, > >> this UPDATE or re-INVITE transaction would fulfil no useful > >> purpose. However, the UAS (for the INVITE transaction) does > >> not know this. In order to save this round trip, should we > >> have an additional option tag to indicate support for receipt > >> of the Identity header on mid- dialog requests? Then if this > >> option tag is not present in the INVITE request the > additional > >> transaction could be omitted. Note that the id-change option > >> tag does not seem appropriate for this purpose, since a UA > >> could support a change of URI without supporting Identity." > >> > >> Whilst I do not wish to proliferate option tags, I do see some > >> benefit in such a tag. Any opinions? > >> > > > > If an Invite arrives with both Identity and the id-change tag, > > it indicates the offerer understands both Identity and connected- > > identity, so the answerer should generate an request (UPDATE or > > re-INVITE). > > > > -d > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 01:27:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzRnT-0004qu-5O; Sun, 09 Jul 2006 01:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzRnR-0004qo-0R for sip@ietf.org; Sun, 09 Jul 2006 01:25:33 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzRnN-0004Xh-8G for sip@ietf.org; Sun, 09 Jul 2006 01:25:32 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 08 Jul 2006 22:25:28 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k695PSmx023469; Sat, 8 Jul 2006 22:25:28 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k695PSTQ028230; Sat, 8 Jul 2006 22:25:28 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 8 Jul 2006 22:25:28 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.144.101]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 8 Jul 2006 22:25:27 -0700 Message-Id: <4.3.2.7.2.20060708211913.02830498@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 08 Jul 2006 21:37:25 -0500 To: Hannes Tschofenig From: "James M. Polk" In-Reply-To: <44A4D3F0.7080109@gmx.net> References: <4.3.2.7.2.20060629161426.035ff008@email.cisco.com> <4.3.2.7.2.20060629161426.035ff008@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 09 Jul 2006 05:25:27.0954 (UTC) FILETIME=[168D4F20:01C6A318] DKIM-Signature: a=rsa-sha1; q=dns; l=10739; t=1152422728; x=1153286728; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Geopriv]=20draft-ietf-sip-location-conveyance-03.txt=20=0A=20=2 0Comments; X=v=3Dcisco.com=3B=20h=3DOeRs85a8BNAXi2BPn7cBFju7fiA=3D; b=LOOZ8/ryD/TfAMCOp++Ll3k8JBPorcxf5TwWdJIR/feethcrR6Dym9xWa9hd8ecKIlWbgmvG XW9bAS3+pj8xESvV2CsnNHeAB7JbK3vHX3qFsdOFhuGfFiMyR5LGTeOy; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: SIP Subject: [Sip] Re: [Geopriv] draft-ietf-sip-location-conveyance-03.txt Comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 09:34 AM 6/30/2006 +0200, Hannes Tschofenig wrote: >Hi James > >thanks for your quick response and your clarifications. I'm slower this time, sorry >Please find my response below: > > >James M. Polk wrote: >>At 11:03 PM 6/29/2006 +0200, Hannes Tschofenig wrote: >> >>>Hi Brian, >>>Hi James >>> >>>I have a few questions concerning the latest SIP location conveyance >>>document. >> >>I moved this discussion to the SIP list, as that's the home of this ID. >> >>>* Usage Cases >>> >>>I think we need to consider the following scenarios: >>> >>>(a) Location transport per-value (a1) and per-reference (a2) >>> >>>(b) Location transport in the header (b1) and in the body (b2) >>> >>>(a) and (b) has to be combined to produce a reasonable combination. >>> >>>Let me go through the individual cases: >>> >>>- If SIP UA Alice wants to convey location information to SIP UA Bob >>>then it should put the PIDF-LO into the body (and apply S/MIME to it). >>>(Case a1+b2) >> >>this is covered >> >>>- If a proxy wants to add location information to a SIP message then it >>>creates the PIDF-LO and a reference to it. The reference is placed into >>>the SIP header. (Case a2+b1) >> >>this is covered >> >>>Would the proxy use M2M/M2E security? >> >>this is orthogonal > >I thought that this issue is important and would deserve a discussion in >the document. >I could only find discussions about S/MIME usage for end-to-end security. so far, a UAC shouldn't use S/MIME on a PIDF-LO message body if it knows a proxy will need to read that message body to route the message. 911/112 calling is a good example of this, that can be coded in a phone to *not* use S/MIME (or any message body encryption to hide a PIDF-LO, knowing that info will be needed in transit). Now, there has been a suggestion that every time a UAC sends location, it uses S/MIME (meaning location is always sent by-value from an endpoint). That only when the UAC receives an error to that request will it consider sending a subsequent request without S/MIME. This will cause an extra round-trip to have the UAC send the request without S/MIME for the Proxy to be able to read the necessary location information to route the request to the appropriate destination. What do you think of this language in the doc? >>>- If SIP UA Alice has to perform location-based routing (e.g., as used >>>in emergency scenarios) then it has to place something into the SIP >>>header since the proxy is not supposed to inspect the body (particularly >>>since it can be encrypted). >> >>not true >>Nothing in SIP prevents a proxy from inspecting a body. A proxy just >>cannot add or modify a body. >> >>>What is SIP UA Alice supposed todo? >> >>Alice can include location by-value or by-reference. >> >>>I think it is not realistic to assume that the SIP UA creates a >>>reference and makes it available by running a webserver on the end host. >> >>I tend to agree, therefore I believe Alice includes location by-value if >>she has it >> >>>It >> >>what is "it" in this context? >> >>>cannot add location information to the SIP header (as a base64 encoded >>>PIDF-LO) since this functionality is not provided by the draft. > >It=the SIP proxy > >The SIP proxy cannot add location information to the SIP header (as a >base64 encoded PIDF-LO) since this functionality is not provided by the draft. This is not true. see this table that's been in the doc for some time: The following table extends the values in Table 2&3 of RFC3261 [RFC3261]. Header field where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- Location Rr ar o - - o o o - Header field where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- Location Rr ar - - o o o o - adding a header value to a SIP message is standard procedure for SIP proxies. The above (unlabelled) table grants this ability explicitly to Location header usage. >>I think you're operating under the impression that proxies cannot read >>bodies, which they can. Any B2BUA or SBC can modify bodies, or add >>bodies - but we cannot assume there will be one in the message path. > >The SIP proxy cannot read the body if it is encrypted. fair If we are to have an error response sent from a proxy that wants to read the PIDF-LO message body (it first has to assume there is one in the message), we can use the existing 424 (Bad Location Information) response message, and add a RFC 3326 Reason header with a 493 (Undecipherable) indication (the 493 is defined in RFC 3261). This could explicitly state to the UAC that a proxy cannot read the assumed PIDF-LO by-value message body, and to send a new request without encrypting that message body. Is this desired, and do we want to have this text in this document, or ECRIT's phoneBCP (and maybe the Framework)? >>>This would be case a1+b1. >>> >>>- What happens if the SIP UA Alice only has a location reference and she >>>wants to send it to SIP UA Bob (where intermediaries must not process >>>the location information)? Is she able to place the reference into the >>>body of the message? I don't think you cover this option in your draft. >> >>SIP Headers can be placed in a message body already. Do you want that >>specified here too? > >Ok. That's fine. > >> >>>This would be case a2+b2. >>> >>>- What happens if you want to perform location-based routing (i.e., >>>processing of the PIDF-LO by intermediaries) and conveyance to the other >>>end point? >> >>by-value covers this I believe > >I suspect that you want to put the location header into the message to let >the proxy know where to find the PIDF-LO and that it actually has to look >for one. most likely >If you don't want intermediaries to process it then you want to apply >S/MIME and if not available (=quite likely) then you wouldn't put the >location header into the message. Right? right now, this spec states if location is conveyed in a message, that message MUST have a Location header (with a cid to the message body part, or a URI for the by-reference). >>>Do you include the information only in the header and not in the body or >>>in the header and the body? >> >>either a header or body >>The proxies can read and route based on the body, and >>Bob can dereference a header if that's all that's in the message. >> >> >>>* I think that the following text is already covered in the PIDF-LO >>>profile draft: >>> >>>" >>> More than one location representation or format MAY be included in >>> the same message body part, but all MUST point at the same position >>> on the earth (altitude not withstanding), as this would confuse the >>> recipient by pointing at more than one position within the same >>> message body part. There MAY be a case in which part or parts of >>> one location format and part or parts of another format exist in the >>> same message body part. These complementary pieces of information >>> MUST point at the same position on the earth, yet are incomplete >>> within their own format. For example, there maybe be a latitude and >>> longitude in coordinate format and a civic altitude value to >>> complete a 3-dimensional position of a thing (i.e. which floor of a >>> building the UA is on in a building at a particular lat/long >>> coordinates pair). >>>" >> >>This needs to be in the "Using Protocol's" document too IMO. I do not >>believe this is inconsistent with the PIDF-LO profile doc. > >I think the PIDF-LO profile document is more precise on these issues >and repeating it does not add value. but this doc doesn't reference the PIDF-LO profile doc, so SIP folks will not necessarily find it anywhere else. >>>* PIDF-LO in SIP Header >>> >>>You write: >>>" >>> The amount >>> of information that is necessary to appropriately transmit location >>> information in a format that is understandable is larger than a SIP >>> header could realistically include. >>>" >>> >>>What is the upper limit? >> >>I do not know, but I do not believe it is 27 CATypes as separate fields >>in a Location header. I think Henning worked out a 500 byte >> element, and while that's allowable I believe, I think >>it's hard to read. > >Why is it a problem if you assume that the SIP proxies will inspect the >body? He has to read the same XML document. for one, it makes reading the SIP message harder to parse with a massive header in the middle of it (that currently only can be a message body). >>>* Scenario Description >>> >>>In the introduction you list three scenarios (actually four). >>> >>>I assume that Scenario #1 refers to the scenario in Figure 2 of Section >>>4 where the end point performs location-based routing. Correct? >> >>agreed >> >>>Thinking about the service URN draft one could get the impression that a >>>solution scenario according to Scenario #3B could also be designed to >>>accomplish the goal of Scenario #1. >> >>yes, but I choose to call them out separately to have a reader understand >>the different scenarios > >Ok. That's fine. > >> >>>I might be good to combine the scenario description of Section 1 with >>>the text and the figures in Section 4. >> >>I was told explicitly to reduce my figures in section 4. Therefore, I >>have a basic request/response transaction (figure 1), a request/response >>transaction involving an intermediary performing routing based on the >>location contents of the request (figure 2) and then articulate how >>Location can be conveyed in a specific SIP Request type (INVITE here). >>I have been told by the WG chairs in SIP to not have more than this. >>This doesn't prevent a user-cases ID from being generated giving these >>examples. I think that would be appropriate once this ID reaches RFC status. > >I am fine with the number of message flows but Section 1 talks about >scenarios without figures and later you talk again about scenarios with >figure and there is no link between them. ok. I need to link the two somehow. >Ciao >Hannes > >> >> >>>Ciao >>>Hannes >>> >>> >>>_______________________________________________ >>>Geopriv mailing list >>>Geopriv@ietf.org >>>https://www1.ietf.org/mailman/listinfo/geopriv >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 01:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzS5V-0000K7-OM; Sun, 09 Jul 2006 01:44:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzS5T-00005N-FJ for sip@ietf.org; Sun, 09 Jul 2006 01:44:11 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzS5S-0008Nr-3n for sip@ietf.org; Sun, 09 Jul 2006 01:44:11 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k695i8vN014535; Sun, 9 Jul 2006 00:44:08 -0500 (CDT) Received: from [135.244.32.83] (vkg.lra2.lucent.com [135.244.32.83]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k695i8H22160; Sun, 9 Jul 2006 00:44:08 -0500 (CDT) Message-ID: <44B097A6.1090206@lucent.com> Date: Sun, 09 Jul 2006 00:44:06 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] comments on draft-gurbani-sip-domain-certs-01 References: <44ADF125.5010101@cisco.com> In-Reply-To: <44ADF125.5010101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > Vijay, > > A few comments on the draft. Jonathan: Thanks for reviewing the draft. More inline. > Firstly, I think the draft mixes authentication and authorization. > You spend a bunch of time talking about checks that a server makes > when receiving a request from a client, comparing bits of the SIP > message to the TLS certificate. To me, all of those checks are > authorization, not authentication. TLS mutual auth has done what its > name suggests - it has already authenticated the other side. To me, the term "mutual authentication" implies that the client authenticates the server, and the server authenticates the client. As it exists today, TLS mutual authentication in SIP does only the former, not the latter. > Now you are trying to figure out whether they are authorized to send > you a SIP request. I think these are quite separable. They may be separable, but rfc3261 conflates these. When the server asks a certificate of a client, rfc3261 expects the server to match the domain in the certificate to the "domainname" portion of the From header. I am trying to tease this out and better specify it from an implementation point of view. Due to retargetting, using the From is pointless. R-R is optional, so that only leaves the Via header. However, the identity of the client in the Via header is usually in the form of a FQDN, whereas the certificate from the client will normally only contain a domain. > For example, if my proxy has a policy about only connecting to > specific other domains, then it can take the identities determined > from TLS mutual auth and use those to decide whether to accept > requests coming from that proxy. No need to every look at the via, > record-route or whatever. But what do you do absent such a policy? A proxy put up on the Internet by a service provider cannot be expected to know all the domainsthat will send it a request. Thus, in the worst case, it will do minimal authentication on the client certificate: probably the CA check and the expiry check. If that iFrom sip-bounces@ietf.org Sun Jul 09 01:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzS5V-0000K7-OM; Sun, 09 Jul 2006 01:44:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzS5T-00005N-FJ for sip@ietf.org; Sun, 09 Jul 2006 01:44:11 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzS5S-0008Nr-3n for sip@ietf.org; Sun, 09 Jul 2006 01:44:11 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k695i8vN014535; Sun, 9 Jul 2006 00:44:08 -0500 (CDT) Received: from [135.244.32.83] (vkg.lra2.lucent.com [135.244.32.83]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k695i8H22160; Sun, 9 Jul 2006 00:44:08 -0500 (CDT) Message-ID: <44B097A6.1090206@lucent.com> Date: Sun, 09 Jul 2006 00:44:06 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] comments on draft-gurbani-sip-domain-certs-01 References: <44ADF125.5010101@cisco.com> In-Reply-To: <44ADF125.5010101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > Vijay, > > A few comments on the draft. Jonathan: Thanks for reviewing the draft. More inline. > Firstly, I think the draft mixes authentication and authorization. > You spend a bunch of time talking about checks that a server makes > when receiving a request from a client, comparing bits of the SIP > message to the TLS certificate. To me, all of those checks are > authorization, not authentication. TLS mutual auth has done what its > name suggests - it has already authenticated the other side. To me, the term "mutual authentication" implies that the client authenticates the server, and the server authenticates the client. As it exists today, TLS mutual authentication in SIP does only the former, not the latter. > Now you are trying to figure out whether they are authorized to send > you a SIP request. I think these are quite separable. They may be separable, but rfc3261 conflates these. When the server asks a certificate of a client, rfc3261 expects the server to match the domain in the certificate to the "domainname" portion of the From header. I am trying to tease this out and better specify it from an implementation point of view. Due to retargetting, using the From is pointless. R-R is optional, so that only leaves the Via header. However, the identity of the client in the Via header is usually in the form of a FQDN, whereas the certificate from the client will normally only contain a domain. > For example, if my proxy has a policy about only connecting to > specific other domains, then it can take the identities determined > from TLS mutual auth and use those to decide whether to accept > requests coming from that proxy. No need to every look at the via, > record-route or whatever. But what do you do absent such a policy? A proxy put up on the Internet by a service provider cannot be expected to know all the domainsthat will send it a request. Thus, in the worst case, it will do minimal authentication on the client certificate: probably the CA check and the expiry check. If that is the expected behavior, then we ought to proscribe it in a form that implementors can understand and code to. Today, no such text or guideline exist. > Thinking about this some more, I think connect-reue has got the > validation model wrong. [...] This validation model has the desired > property; a request gets delivered in the reverse direction with > connect-reuse only if it would have been delivered had connect-reuse > not been used. Thanks; this'll be added to connect-reuse. > This simplifies the work that domain-certs has to do. It merely > needs to give guidance on how the server certificate should look > like, addressing the two main things EKR mentioned: > > 1. what field does the identity get coded into > 2. what does that identity represent - the specific host or the > domain > > My two cents is, I think it should always just be the domain > (example.com and not proxy2.example.com). Thus if you connect to > proxy2.example.com, and the server provided a certificate for > example.com, that would be OK. This works fine for majority of the cases where the client authenticates the server, i.e., client has a R-URI of "sips:alice@example.com" and the server certificate asserts an SAN identity of "DNS:example.com". The corner case where there is a problem is the case where the client follows a R-URI of "sips:alice@downtown.example.com" and gets a certificate saying "DNS:example.com". Is downtown a subdomain? If so, is example.com authorized to present a certificate for downtown.example.com? Or is downtown a host? In which case, it would be trivial for the certificate to have an additional DNS name matching that host. The same problem occurs when a client follows a Route header (sips:proxy2.example.com) and gets a certificate saying "DNS:example.com". Is proxy2 a host in example.com? Or is it a subordinate domain of example.com? > I also think its highly unlikely that a cerificate authority would > hand out certs that verify that a *host* is proxy2.example.com. How > would a CA verify that this is true? The CA will not verify this; I would think it would be upto the holder of the example.com domain to ensure the integrity of any additional identities stored in the certificate. I am curious: my understanding is that a certificate for a virtual servers may contain multiple domain names in it (c.f. Identity, Section 13.4: "certificates have varying ways of describing their subjects, and may indeed have multiple subjects, especially in 'virtual hosting' cases where multiple domains are managed by a single application."). If so, how do CAs do validation of these individual domain names? > Hope this makes sense. Yes, a lot of good comments driving some discussion above... Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 01:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzS5W-0000Rt-UE; Sun, 09 Jul 2006 01:44:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzS5T-00005d-G0 for sip@ietf.org; Sun, 09 Jul 2006 01:44:11 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzS5Q-0008No-61 for sip@ietf.org; Sun, 09 Jul 2006 01:44:11 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k695i6pi014519; Sun, 9 Jul 2006 00:44:06 -0500 (CDT) Received: from [135.244.32.83] (vkg.lra2.lucent.com [135.244.32.83]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 ss the expected behavior, then we ought to proscribe it in a form that implementors can understand and code to. Today, no such text or guideline exist. > Thinking about this some more, I think connect-reue has got the > validation model wrong. [...] This validation model has the desired > property; a request gets delivered in the reverse direction with > connect-reuse only if it would have been delivered had connect-reuse > not been used. Thanks; this'll be added to connect-reuse. > This simplifies the work that domain-certs has to do. It merely > needs to give guidance on how the server certificate should look > like, addressing the two main things EKR mentioned: > > 1. what field does the identity get coded into > 2. what does that identity represent - the specific host or the > domain > > My two cents is, I think it should always just be the domain > (example.com and not proxy2.example.com). Thus if you connect to > proxy2.example.com, and the server provided a certificate for > example.com, that would be OK. This works fine for majority of the cases where the client authenticates the server, i.e., client has a R-URI of "sips:alice@example.com" and the server certificate asserts an SAN identity of "DNS:example.com". The corner case where there is a problem is the case where the client follows a R-URI of "sips:alice@downtown.example.com" and gets a certificate saying "DNS:example.com". Is downtown a subdomain? If so, is example.com authorized to present a certificate for downtown.example.com? Or is downtown a host? In which case, it would be trivial for the certificate to have an additional DNS name matching that host. The same problem occurs when a client follows a Route header (sips:proxy2.example.com) and gets a certificate saying "DNS:example.com". Is proxy2 a host in example.com? Or is it a subordinate domain of example.com? > I also think its highly unlikely that a cerificate authority would > hand out certs that verify that a *host* is proxy2.example.com. How > would a CA verify that this is true? The CA will not verify this; I would think it would be upto the holder of the example.com domain to ensure the integrity of any additional identities stored in the certificate. I am curious: my understanding is that a certificate for a virtual servers may contain multiple domain names in it (c.f. Identity, Section 13.4: "certificates have varying ways of describing their subjects, and may indeed have multiple subjects, especially in 'virtual hosting' cases where multiple domains are managed by a single application."). If so, how do CAs do validation of these individual domain names? > Hope this makes sense. Yes, a lot of good comments driving some discussion above... Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 01:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzS5W-0000Rt-UE; Sun, 09 Jul 2006 01:44:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzS5T-00005d-G0 for sip@ietf.org; Sun, 09 Jul 2006 01:44:11 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzS5Q-0008No-61 for sip@ietf.org; Sun, 09 Jul 2006 01:44:11 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k695i6pi014519; Sun, 9 Jul 2006 00:44:06 -0500 (CDT) Received: from [135.244.32.83] (vkg.lra2.lucent.com [135.244.32.83]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k695i5H22153; Sun, 9 Jul 2006 00:44:06 -0500 (CDT) Message-ID: <44B097A3.8040704@lucent.com> Date: Sun, 09 Jul 2006 00:44:03 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: oran@cisco.com Subject: Re: [Sip] Comments on draft-gurbani-sip-domain-certs-01 References: <20060704163058.ADAC41CC22@delta.rtfm.com> <44AC1A8E.4000707@lucent.com> <5E859922-14C9-44D1-9C0B-74E8AEBF58E6@cisco.com> In-Reply-To: <5E859922-14C9-44D1-9C0B-74E8AEBF58E6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org David R Oran wrote: > Quick question: > >> on the same outcome you mention above; i.e., it suffices >> that when contacting "sips:alice@atlanta.com", the certificate >> presented contains "atlanta.com." >> > Do you mean "the name in the certificate contains the string" or "ends > with the string" or something else. In other words, does a certificate > for badboy.atlanta.com.chaoscomputerclub.org match a sip uri of > sip:alice@atlanta.com. > > One would think not... I would hope so as well. > Or do you mean "the name in the certificate is precisely the string > 'atlanta.com'", in which case does the certificate match sip uri's > registered in a subdomain, e.g. alice@downtown.atlanta.com. Yes, exactly! You hit the nail right on the head, Dave. What should an implementor of a client expect when a R-URI contains sips:alice@downtown.atlanta.com and the certificate that is received contains "atlanta.com"? It could, of course, simply close the connection. But then again, "downtown" could have been a certain host in the atlanta.com domain versus a subordinate domain, in which case, the client may have torn the connection down prematurely. Are the guidelines that implementors must match exactly the domainname in the cerificate to the domainname in the R-URI? Anything else is considered suspect? If so, then how do we handle this case of a mid-dialog request: INVITE sips:alice@alicehost.atlanta.com SIP/2.0 Route: ... The proxy (proxy1.atlanta.com) presents a certificate that asserts "atlanta.com". What should the UAC do now? Close the connection? I think any guidance we provide around these issues is well worth it if we are to have a semblance of security in the stacks. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ol2) id k695i5H22153; Sun, 9 Jul 2006 00:44:06 -0500 (CDT) Message-ID: <44B097A3.8040704@lucent.com> Date: Sun, 09 Jul 2006 00:44:03 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: oran@cisco.com Subject: Re: [Sip] Comments on draft-gurbani-sip-domain-certs-01 References: <20060704163058.ADAC41CC22@delta.rtfm.com> <44AC1A8E.4000707@lucent.com> <5E859922-14C9-44D1-9C0B-74E8AEBF58E6@cisco.com> In-Reply-To: <5E859922-14C9-44D1-9C0B-74E8AEBF58E6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org David R Oran wrote: > Quick question: > >> on the same outcome you mention above; i.e., it suffices >> that when contacting "sips:alice@atlanta.com", the certificate >> presented contains "atlanta.com." >> > Do you mean "the name in the certificate contains the string" or "ends > with the string" or something else. In other words, does a certificate > for badboy.atlanta.com.chaoscomputerclub.org match a sip uri of > sip:alice@atlanta.com. > > One would think not... I would hope so as well. > Or do you mean "the name in the certificate is precisely the string > 'atlanta.com'", in which case does the certificate match sip uri's > registered in a subdomain, e.g. alice@downtown.atlanta.com. Yes, exactly! You hit the nail right on the head, Dave. What should an implementor of a client expect when a R-URI contains sips:alice@downtown.atlanta.com and the certificate that is received contains "atlanta.com"? It could, of course, simply close the connection. But then again, "downtown" could have been a certain host in the atlanta.com domain versus a subordinate domain, in which case, the client may have torn the connection down prematurely. Are the guidelines that implementors must match exactly the domainname in the cerificate to the domainname in the R-URI? Anything else is considered suspect? If so, then how do we handle this case of a mid-dialog request: INVITE sips:alice@alicehost.atlanta.com SIP/2.0 Route: ... The proxy (proxy1.atlanta.com) presents a certificate that asserts "atlanta.com". What should the UAC do now? Close the connection? I think any guidance we provide around these issues is well worth it if we are to have a semblance of security in the stacks. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 02:36:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzSsa-0005Hk-1E; Sun, 09 Jul 2006 02:34:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzSsY-0005CT-Jc for sip@ietf.org; Sun, 09 Jul 2006 02:34:54 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzSsW-0002Op-Ub for sip@ietf.org; Sun, 09 Jul 2006 02:34:54 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 31F588F4; Sun, 9 Jul 2006 08:34:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Jul 2006 08:34:51 +0200 Received: from [136.225.183.76] ([136.225.183.76]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Jul 2006 08:34:48 +0200 From: "Christer Holmberg" To: "Jeroen van Bemmel" , "Rohan Mahy" , sip@ietf.org Subject: Re: STUN keep-alive: Where to document it? (was [Sip] Re: A coment todraft-ietf-sip-outbound-04) Date: Sun, 9 Jul 2006 09:34:58 +0300 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 09 Jul 2006 06:34:51.0229 (UTC) FILETIME=[C80EA8D0:01C6A321] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Miguel Garcia , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeroen, Could we move this discussion to a separate thread? I would like this = thread to simply focus on the where-will-we-document-things issue. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 04:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzUqt-0005qO-Em; Sun, 09 Jul 2006 04:41:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzUqX-0005MU-3i for sip@ietf.org; Sun, 09 Jul 2006 04:40:57 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzUdS-0000vX-Fg for sip@ietf.org; Sun, 09 Jul 2006 04:27:28 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AA7A66E0001; Sun, 9 Jul 2006 10:27:25 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Jul 2006 10:27:25 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Jul 2006 10:27:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 9 Jul 2006 10:25:54 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5940294EB5E@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: STUN keep-alive: timer values Thread-Index: Acai4+VOSLXL3eL+S9ioukAIDvfMbwATWaYk References: <001401c6a2e3$dfe48850$31713b51@BEMBUSTER> From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , "Rohan Mahy" , X-OriginalArrivalTime: 09 Jul 2006 08:27:24.0757 (UTC) FILETIME=[81794050:01C6A331] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Miguel Garcia , Cullen Jennings Subject: [Sip] STUN keep-alive: timer values X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Moved from the "RE: STUN keep-alive: Where to document it? (was [Sip] = Re: A coment todraft-ietf-sip-outbound-04)" thread: =20 Jeroen wrote: =20 >I just scanned briefly through RFC3489bis section 7.1. It appears that = much >more needs to be said on exactly how STUN is to be done. For example, >RFC3489bis suggests a retransmission scheme with timeout after 9500ms = for >UDP; for TCP it says "SHOULD NOT retransmit", but what should be used = for >timeout? Surely not 9.5 seconds? And compared to SIP standard timings, = a >retransmission after 100ms (UDP) seems rather quick...=20 I agree that we probably need to document that. I found the same issue = with RTSP at one point - there were no = transaction/re-transmission/timeout timers etc defined (I haven't been = working with RTSP for a while now, so I don't know what the situation is = at the moment). The question is whether we want "SIP specific" behavior, in which case = it should be in the SIP STUN keep-alive document (or dedicated chapter = in the outbound spec), or if we want generic behavior in which case it = should be in 3489bis. (...OR, if we want outbound specific behavior, in which case it should = be in the outbound spec). Regards, =20 Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 04:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzUqq-0005hO-HH; Sun, 09 Jul 2006 04:41:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzUqX-0005MU-Ni for sip@ietf.org; Sun, 09 Jul 2006 04:40:57 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzUbx-0000tQ-GS for sip@ietf.org; Sun, 09 Jul 2006 04:25:55 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9D843619; Sun, 9 Jul 2006 10:25:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Jul 2006 10:25:52 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Jul 2006 10:25:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 9 Jul 2006 10:25:51 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5940294EB5D@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: STUN keep-alive: Client vs server generating requests Thread-Index: Acai4+VOSLXL3eL+S9ioukAIDvfMbwAS6Drg References: <001401c6a2e3$dfe48850$31713b51@BEMBUSTER> From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , "Rohan Mahy" , X-OriginalArrivalTime: 09 Jul 2006 08:25:51.0351 (UTC) FILETIME=[49CCA070:01C6A331] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Miguel Garcia , Cullen Jennings Subject: [Sip] STUN keep-alive: Client vs server generating requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Moved from the "STUN keep-alive: Where to document it? (was [Sip] Re: A = coment todraft-ietf-sip-outbound-04)" thread: Jeroen wrote: >>One issue with that proposal was that the client doesn't know if e.g. = a NAT >>is rebooting. It would require some timer, so that the client can = assume a >>reboot has >occured if it doesn't receive a STUN request before the = timer >>expires. >Also client-initiated STUN requires such a periodic timer. Furthermore, >sending a STUN request and then waiting for a response also implicitly = uses >a timer (typical implementation is the sending thread blocking on some = event >with a timeout, reception of the response setting this event) Correct. But, these timers a "local" client timers aren't they, i.e. how = often it sends STUN requests and for how long it should wait for a = reply?=20 In case the server generates the STUN request the client must know which = timers the server uses. That can of course be a standardized value, OR = it can be provided in some header, but the client needs to know about = it. Regards, Christer =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 07:27:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzXQA-0007Aw-RB; Sun, 09 Jul 2006 07:25:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzXQ9-0007Aq-7r for sip@ietf.org; Sun, 09 Jul 2006 07:25:53 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzXQ7-00005S-Ql for sip@ietf.org; Sun, 09 Jul 2006 07:25:53 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k69APgmS013313; Sun, 9 Jul 2006 13:25:43 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Jul 2006 14:25:41 +0300 Received: from [10.162.17.84] ([10.162.17.84]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 9 Jul 2006 14:25:40 +0300 Message-ID: <44B0E7B3.3060801@nokia.com> Date: Sun, 09 Jul 2006 14:25:39 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ext Rohan Mahy Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2006 11:25:40.0554 (UTC) FILETIME=[68AA5AA0:01C6A34A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Cullen Jennings , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan Mahy wrote: > > The spec currently says that UAs MUST support a minimum of 2 flows. If > they don't open the two flows, the mechanism is broken since the UA can > lose inbound messages for several minutes. I think I have a different opinion on whether the mechanism is broken or not. The mechanism is not broken, but obviously the server can loose inbound connections. This scenario, although not perfect, may be much desirable than draining battery of portable devices at a fast speed. /Miguel > > thanks, > -rohan > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 08:39:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzYXA-0002eq-Pi; Sun, 09 Jul 2006 08:37:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzYX9-0002c9-Pk for sip@ietf.org; Sun, 09 Jul 2006 08:37:11 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzYX7-0005Vg-Br for sip@ietf.org; Sun, 09 Jul 2006 08:37:11 -0400 Received: (qmail 18594 invoked by uid 0); 9 Jul 2006 12:37:02 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 Jul 2006 12:37:02 -0000 Message-ID: <003801c6a354$5f9c0a80$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Miguel Garcia" , "ext Rohan Mahy" References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com><44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <44B0E7B3.3060801@nokia.com> Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Sun, 9 Jul 2006 14:37:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Cullen Jennings , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think the system is "broken" in the sense that it does not behave as the authors of the draft had intended There are 2 questions here: 1) Is that intention expressed sufficiently clear and consistent in the draft? 2) Is the intended behavior (and associated system architecture) appropriate/desirable (in all/most cases)? The draft seems to be written under the assumption that "reliability" (not well defined yet what that means) can only be provided through multiple flows. However, "outbound" (ie enabling UAs behind NAT to register and receive incoming requests) can be done using only a single flow, albeit with a somewhat higher chance at missing incoming requests. If the system is architected as Juha was describing (2 independent proxies, UA missing 50% of its calls when only setting up 1 flow), the chance at missed requests for such a UA is much higher than double that of a single flow system. I feel that outbound should certainly not mandate such an architecture. Currently in SIP the assumption is that a single registration suffices to receive all incoming requests for a given AoR. If we break that, it means that current UAs won't be able to register with "outbound-enhanced" registrars and edge proxies. That to me is not acceptable. In other words, a requirement is missing: "Support UAs that do not implement this extension" Regards, jeroen ----- Original Message ----- From: "Miguel Garcia" To: "ext Rohan Mahy" Cc: "Cullen Jennings" ; Sent: Sunday, July 09, 2006 1:25 PM Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 > Rohan Mahy wrote: >> >> The spec currently says that UAs MUST support a minimum of 2 flows. If >> they don't open the two flows, the mechanism is broken since the UA can >> lose inbound messages for several minutes. > > I think I have a different opinion on whether the mechanism is broken or > not. The mechanism is not broken, but obviously the server can loose > inbound connections. This scenario, although not perfect, may be much > desirable than draining battery of portable devices at a fast speed. > > /Miguel > >> >> thanks, >> -rohan >> > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 08:43:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzYbu-00057H-5j; Sun, 09 Jul 2006 08:42:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzYbr-00057B-W0 for sip@ietf.org; Sun, 09 Jul 2006 08:42:03 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzYbq-00064j-K0 for sip@ietf.org; Sun, 09 Jul 2006 08:42:03 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 6E78D1401B4; Sun, 9 Jul 2006 15:41:56 +0300 (EEST) Received: from rautu (allozyme237.gprs.dnafinland.fi [62.78.104.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id A73B61401B2; Sun, 9 Jul 2006 15:41:45 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 79354F03C1; Sun, 9 Jul 2006 15:41:54 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17584.63890.360760.847258@rautu.tutpro.com> Date: Sun, 9 Jul 2006 15:41:54 +0300 From: Juha Heinanen To: Jonathan Rosenberg Subject: [Sip] an alternative approach for outbound proxy discovery In-Reply-To: <44AD6E48.2030302@cisco.com> References: <44AD6E48.2030302@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org i liked jonathan's SIP based discovery mechanism and didn't see any problems with it. > 1. I am NOT proposing that this be added to sip-outbound, and I'm not > suggesting that a normative reference to this or another mechanism > should be in outbound. however, i can't agree with the above statement, because i don't see any difference with outbound discovery and rfc3263 discovery referenced in rfc3261. it would have been impossible to set up any vendor independent sip services unless rfc3263 had existed and mandated by rfc3261. or perhaps people only want closed, vendor specific outbound implementations? -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 12:55:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzcWz-0006BM-9n; Sun, 09 Jul 2006 12:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzcWx-00066R-5u for sip@ietf.org; Sun, 09 Jul 2006 12:53:15 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzcWv-0004FZ-S4 for sip@ietf.org; Sun, 09 Jul 2006 12:53:15 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J2500901AXA2Z@siemenscomms.co.uk> for sip@ietf.org; Sun, 09 Jul 2006 17:53:34 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J25002APAXAF9@siemenscomms.co.uk>; Sun, 09 Jul 2006 17:53:34 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Sun, 09 Jul 2006 17:53:12 +0100 Content-return: allowed Date: Sun, 09 Jul 2006 17:53:09 +0100 From: "Elwell, John" Subject: RE: [Sip] Issue 4 in draft-ietf-sip-connected-identity-00.txt To: Dan Wing , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667095641C2@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan, Yes, I agree with your motivation for being able to have signed SDP in the reverse direction. This doesn't necessarily mean UPDATE has to be used - re-INVITE would do, but I prefer to use UPDATE unless there are other reasons for using re-INVITE. The question is whether we should mandate including an SDP offer in the UPDATE so that we always have the benefit of this signature. John > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: 08 July 2006 02:21 > To: Elwell, John; sip@ietf.org > Subject: RE: [Sip] Issue 4 in draft-ietf-sip-connected-identity-00.txt > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Tuesday, May 02, 2006 1:24 PM > > To: sip@ietf.org > > Subject: [Sip] Issue 4 in draft-ietf-sip-connected-identity-00.txt > > > > The fourth issue is not actually in draft-00 but was raised > > subsequently. If a UA supports a change of From header field URI > > mid-dialog, as indicated by the "id-change" option tag, we could > > mandate that it also support the SIP UPDATE method. Then the peer > > UA in a dialog would be free to use the UPDATE method to report > > connected identity, rather than the less suitable re-INVITE method. > > The use of UPDATE means 2 messages instead of 3 and avoids the need > > for an offer-answer exchange. I heard no objections when this was > > proposed a few days ago. Do we have consensus? > > I prefer UPDATE. I am considering the needs of some proposed > SRTP keying techniques which could benefit from strong authentication > of identity and of the fingerprints or certificates in SDP. For > those cases it's helpful to include SDP in the UPDATE so that it > gets signed with Identity, even if that SDP is exactly the same as > the SDP in the answer. An example of where Identity could help is > with a pure DH mode (such as draft-baugher-mmusic-sdp-dh). It can > also help provide additional protection of a UA's self-signed > certificate (various MIKEY modes) or certificate fingerprint > (mmusic-comedia-tls, mcgrew-tls-srtp). > > Even without SRTP and without comedia-tls, the reasons that > Identity chose to include the offerer's SDP in its signature > should be applicable to the answerer's SDP. Otherwise we're > saying the answerer's SDP doesn't need authentication or > integrity protection. > > -d > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 13:54:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzdSr-0000aI-4M; Sun, 09 Jul 2006 13:53:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzdSo-0000Yj-Vo for sip@ietf.org; Sun, 09 Jul 2006 13:53:02 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzdPv-0003uL-0l for sip@ietf.org; Sun, 09 Jul 2006 13:50:04 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k69HnxF32436; Sun, 9 Jul 2006 10:49:59 -0700 In-Reply-To: <002c01c6a1ed$6e8726f0$31713b51@BEMBUSTER> References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com><44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <002c01c6a1ed$6e8726f0$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Sat, 8 Jul 2006 17:16:26 -0700 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, Miguel Garcia , Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 7, 2006, at 10:47, Jeroen van Bemmel wrote: > Rohan, > >>> Additionally I suspect that users may still impose local policies in >>> the UAs as for the number of established flows, independently of the >>> number of learned URIs. So, the MUST in the spec is always subject >>> to local policy. >> >> The spec currently says that UAs MUST support a minimum of 2 flows. >> If they don't open the two flows, the mechanism is broken since the >> UA can lose inbound messages for several minutes. > > OK, let me try to see if I understand where this "several minutes" > comes from, and if we could quantify "broken" here. > > Assuming that the client uses the default keepalive timer values (UDP: > 24..29 seconds, TCP: 95..120 seconds), I deduce that worst case a > client using only one flow could loose its registration status for a > period of 120 seconds (on average, this would be only 60 seconds). So > your "several" equals 2 ? Yes, you are right. The UA could lose inbound messages for 2 minutes I went back and rechecked all the timers. I was still (wrongly) thinking about the problem based on timer values that resulted in a ~10 minute window of potential downtime. While 10 minutes was not acceptable to me, I agree that 2 minutes is in a gray area that will be fine for some and not fine for others. So we are back to a pure semantic question. Does the service get to decide how many flows the UA opens (up to an implementation supported maximum), does the UA decide how many flows to open, or is there some negotiation? I still think the current semantics are fine, because they allow a single flow to a URI that can still load-share and failover to a large number of actual servers. Of course there are others who don't like that because it relies on DNS for failover. thanks, -rohan > One could probably calculate the chance that in this window a request > would come in (given message rate assumptions, etc). Multiply that > with the chance at flow failure (given component MTBF figures etc), > and you would have the kind of reliability one would have for one flow > only. Call that reliability R > > My question now is: what are reasonable assumptions for these figures, > and could it be that for some clients, R could be sufficient? > Intuitively I say: yes, that's possible. There exist clients and users > that would be happy with a scheme that is broken for (1-R) part (I > know at least one - me). > > There is currently nothing in the requirements regarding reliability. > Section 4.4 mentions the relationship between timer values and server > load, and has some text on "the expected time that a user may not > receive inbound communications"; but not in relation to the number of > flows (nor does it mention to de-synchronize keepalive timers across > multiple flows). Do we need that, perhaps with some sample > quantitative analysis? > > Regards, > > Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 13:54:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzdSq-0000aB-Eb; Sun, 09 Jul 2006 13:53:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzdSo-0000Yj-V3 for sip@ietf.org; Sun, 09 Jul 2006 13:53:02 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzdQ3-0003uc-SG for sip@ietf.org; Sun, 09 Jul 2006 13:50:13 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k69HnuF32430; Sun, 9 Jul 2006 10:49:56 -0700 In-Reply-To: <04cf01c6a2be$5958de00$31713b51@BEMBUSTER> References: <17580.7810.687558.525897@rautu.tutpro.com><039e01c6a125$ce062950$a7c8000a@acmepacket.com><17583.59198.391812.55065@rautu.tutpro.com><04a801c6a2b8$8d48d2c0$31713b51@BEMBUSTER> <17583.63822.302979.834665@rautu.tutpro.com> <04cf01c6a2be$5958de00$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Sat, 8 Jul 2006 17:25:32 -0700 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Cullen Jennings , Rohan Mahy , Juha Heinanen , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I do not understand the motivation for wanting multiple flows to the same actual server. At some point we need to ask ourselves as a group whether we are a building a mechanism that solves a problem in every conceivable topology we can come up with , or whether it is sufficient for us to build a mechanism that solves a variety of important problems using one or two plausible topologies. thanks, -rohan On Jul 8, 2006, at 11:43, Jeroen van Bemmel wrote: > Dear outbound authors, > > Could you share your thoughts on the view Juha is expressing below? > > Regards, > > Jeroen > > ----- Original Message ----- From: "Juha Heinanen" > To: "Jeroen van Bemmel" > Cc: "Hadriel Kaplan" ; > Sent: Saturday, July 08, 2006 8:28 PM > Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 > > >> jeroen, >> multiple flows to the same proxy is not interesting. the only added >> value of outbound is multiple flows to more than one proxy. >> -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 13:54:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzdSr-0000aI-4M; Sun, 09 Jul 2006 13:53:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzdSo-0000Yj-Vo for sip@ietf.org; Sun, 09 Jul 2006 13:53:02 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzdPv-0003uL-0l for sip@ietf.org; Sun, 09 Jul 2006 13:50:04 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k69HnxF32436; Sun, 9 Jul 2006 10:49:59 -0700 In-Reply-To: <002c01c6a1ed$6e8726f0$31713b51@BEMBUSTER> References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com><44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <002c01c6a1ed$6e8726f0$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Sat, 8 Jul 2006 17:16:26 -0700 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, Miguel Garcia , Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 7, 2006, at 10:47, Jeroen van Bemmel wrote: > Rohan, > >>> Additionally I suspect that users may still impose local policies in >>> the UAs as for the number of established flows, independently of the >>> number of learned URIs. So, the MUST in the spec is always subject >>> to local policy. >> >> The spec currently says that UAs MUST support a minimum of 2 flows. >> If they don't open the two flows, the mechanism is broken since the >> UA can lose inbound messages for several minutes. > > OK, let me try to see if I understand where this "several minutes" > comes from, and if we could quantify "broken" here. > > Assuming that the client uses the default keepalive timer values (UDP: > 24..29 seconds, TCP: 95..120 seconds), I deduce that worst case a > client using only one flow could loose its registration status for a > period of 120 seconds (on average, this would be only 60 seconds). So > your "several" equals 2 ? Yes, you are right. The UA could lose inbound messages for 2 minutes I went back and rechecked all the timers. I was still (wrongly) thinking about the problem based on timer values that resulted in a ~10 minute window of potential downtime. While 10 minutes was not acceptable to me, I agree that 2 minutes is in a gray area that will be fine for some and not fine for others. So we are back to a pure semantic question. Does the service get to decide how many flows the UA opens (up to an implementation supported maximum), does the UA decide how many flows to open, or is there some negotiation? I still think the current semantics are fine, because they allow a single flow to a URI that can still load-share and failover to a large number of actual servers. Of course there are others who don't like that because it relies on DNS for failover. thanks, -rohan > One could probably calculate the chance that in this window a request > would come in (given message rate assumptions, etc). Multiply that > with the chance at flow failure (given component MTBF figures etc), > and you would have the kind of reliability one would have for one flow > only. Call that reliability R > > My question now is: what are reasonable assumptions for these figures, > and could it be that for some clients, R could be sufficient? > Intuitively I say: yes, that's possible. There exist clients and users > that would be happy with a scheme that is broken for (1-R) part (I > know at least one - me). > > There is currently nothing in the requirements regarding reliability. > Section 4.4 mentions the relationship between timer values and server > load, and has some text on "the expected time that a user may not > receive inbound communications"; but not in relation to the number of > flows (nor does it mention to de-synchronize keepalive timers across > multiple flows). Do we need that, perhaps with some sample > quantitative analysis? > > Regards, > > Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 13:54:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzdSq-0000aB-Eb; Sun, 09 Jul 2006 13:53:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzdSo-0000Yj-V3 for sip@ietf.org; Sun, 09 Jul 2006 13:53:02 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzdQ3-0003uc-SG for sip@ietf.org; Sun, 09 Jul 2006 13:50:13 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k69HnuF32430; Sun, 9 Jul 2006 10:49:56 -0700 In-Reply-To: <04cf01c6a2be$5958de00$31713b51@BEMBUSTER> References: <17580.7810.687558.525897@rautu.tutpro.com><039e01c6a125$ce062950$a7c8000a@acmepacket.com><17583.59198.391812.55065@rautu.tutpro.com><04a801c6a2b8$8d48d2c0$31713b51@BEMBUSTER> <17583.63822.302979.834665@rautu.tutpro.com> <04cf01c6a2be$5958de00$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Sat, 8 Jul 2006 17:25:32 -0700 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Cullen Jennings , Rohan Mahy , Juha Heinanen , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I do not understand the motivation for wanting multiple flows to the same actual server. At some point we need to ask ourselves as a group whether we are a building a mechanism that solves a problem in every conceivable topology we can come up with , or whether it is sufficient for us to build a mechanism that solves a variety of important problems using one or two plausible topologies. thanks, -rohan On Jul 8, 2006, at 11:43, Jeroen van Bemmel wrote: > Dear outbound authors, > > Could you share your thoughts on the view Juha is expressing below? > > Regards, > > Jeroen > > ----- Original Message ----- From: "Juha Heinanen" > To: "Jeroen van Bemmel" > Cc: "Hadriel Kaplan" ; > Sent: Saturday, July 08, 2006 8:28 PM > Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 > > >> jeroen, >> multiple flows to the same proxy is not interesting. the only added >> value of outbound is multiple flows to more than one proxy. >> -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 17:29:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzgoG-0005Ub-Vf; Sun, 09 Jul 2006 17:27:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzgoF-0005UW-Bd for sip@ietf.org; Sun, 09 Jul 2006 17:27:23 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzgoD-0002MN-0m for sip@ietf.org; Sun, 09 Jul 2006 17:27:23 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J2500601NM58K@siemenscomms.co.uk> for sip@ietf.org; Sun, 09 Jul 2006 22:27:41 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J250007HNM5UY@siemenscomms.co.uk>; Sun, 09 Jul 2006 22:27:41 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Sun, 09 Jul 2006 22:27:19 +0100 Content-return: allowed Date: Sun, 09 Jul 2006 22:27:09 +0100 From: "Elwell, John" Subject: RE: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt To: Dan Wing , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667095641CB@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan, I am not sure that would work. The problem is the UAC typically does not insert the Identity header field in a request, this is typically done by an authentication service at the outbound proxy. So the fact that the request went through an authentication service and had an Identity header field added does not mean that the response will go through a verification service. However, I am open to opinions on that. John > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: 08 July 2006 02:21 > To: Elwell, John; sip@ietf.org > Subject: RE: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt > > I hadn't noticed any followups to this issue. I have a suggestion: > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Tuesday, May 02, 2006 1:21 PM > > To: sip@ietf.org > > Subject: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt > > > > The second issue concerns the fact that an UPDATE request in the > > backward direction following dialog establishment can be wasted if > > the peer UA (the UAC for the INVITE transaction) does not support > > it. It states: > > > > "OPEN ISSUE: If the identity has has not changed compared with > > the URI in the To header field and the UAC (for the INVITE > > request) does not support verification of an Identity header, > > this UPDATE or re-INVITE transaction would fulfil no useful > > purpose. However, the UAS (for the INVITE transaction) does > > not know this. In order to save this round trip, should we > > have an additional option tag to indicate support for receipt > > of the Identity header on mid- dialog requests? Then if this > > option tag is not present in the INVITE request the additional > > transaction could be omitted. Note that the id-change option > > tag does not seem appropriate for this purpose, since a UA > > could support a change of URI without supporting Identity." > > > > Whilst I do not wish to proliferate option tags, I do see some > > benefit in such a tag. Any opinions? > > If an Invite arrives with both Identity and the id-change tag, > it indicates the offerer understands both Identity and connected- > identity, so the answerer should generate an request (UPDATE or > re-INVITE). > > -d > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 17:43:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzh2I-0006r5-TO; Sun, 09 Jul 2006 17:41:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzh2H-0006r0-MO for sip@ietf.org; Sun, 09 Jul 2006 17:41:53 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzh2G-0003w5-AD for sip@ietf.org; Sun, 09 Jul 2006 17:41:53 -0400 Received: (qmail 1252 invoked by uid 0); 9 Jul 2006 21:41:45 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 Jul 2006 21:41:45 -0000 Message-ID: <009801c6a3a0$77b14940$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" References: <17580.7810.687558.525897@rautu.tutpro.com><039e01c6a125$ce062950$a7c8000a@acmepacket.com><17583.59198.391812.55065@rautu.tutpro.com><04a801c6a2b8$8d48d2c0$31713b51@BEMBUSTER> <17583.63822.302979.834665@rautu.tutpro.com> <04cf01c6a2be$5958de00$31713b51@BEMBUSTER> Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Sun, 9 Jul 2006 23:41:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Cullen Jennings , Rohan Mahy , Juha Heinanen , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Hi, > > I do not understand the motivation for wanting multiple flows to the same > actual server. > Not multiple *connections*, but multiple flows via different edge proxies: yes (see section 3.4). Of course, the single server itself will need to be built properly to provide adequate reliability (eg storage that survives reboots for registration state, etc). Perhaps we should let edge proxies refuse a REGISTER that comes in when another flow already exists through it though. > At some point we need to ask ourselves as a group whether we are a > building a mechanism that solves a problem in every conceivable topology > we can come up with , or whether it is sufficient for us to build a > mechanism that solves a variety of important problems using one or two > plausible topologies. > The problem is: in the current outbound draft there are *several* mechanisms ( multiple flows, keepalive, outbound request handling, reliability schemes) defined that solve a variety of *separate* problems, while making assumptions that rule out certain other, equally plausible, topologies. For example, topologies involving mobile devices are important too. Such networks are quite capable of providing certain degrees of reliability themselves, but that won't do any good once the battery is drained. For these devices, "MUST setup 2 flows" can be too much. So we cannot (only) have a scheme that requires that Regards, Jeroen > thanks, > -rohan > > > On Jul 8, 2006, at 11:43, Jeroen van Bemmel wrote: >> Dear outbound authors, >> >> Could you share your thoughts on the view Juha is expressing below? >> >> Regards, >> >> Jeroen >> >> ----- Original Message ----- From: "Juha Heinanen" >> To: "Jeroen van Bemmel" >> Cc: "Hadriel Kaplan" ; >> Sent: Saturday, July 08, 2006 8:28 PM >> Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 >> >> >>> jeroen, >>> multiple flows to the same proxy is not interesting. the only added >>> value of outbound is multiple flows to more than one proxy. >>> -- juha > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 17:57:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzhFa-0006Z6-KN; Sun, 09 Jul 2006 17:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzhFY-0006X2-Vx for sip@ietf.org; Sun, 09 Jul 2006 17:55:36 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzhFX-0008I2-Kw for sip@ietf.org; Sun, 09 Jul 2006 17:55:36 -0400 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.03) id AB560444; Sun, 09 Jul 2006 17:55:34 -0400 From: "Hadriel Kaplan" To: "'Jeroen van Bemmel'" , Subject: RE: [Sip] STUN keep-alive: Client vs server generating requests Date: Sun, 9 Jul 2006 17:55:35 -0400 Message-ID: <05ea01c6a3a2$689236c0$a7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5940294EB5D@esealmw113.eemea.ericsson.se> Thread-Index: Acai4+VOSLXL3eL+S9ioukAIDvfMbwAS6DrgABtF3uA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I would strongly suggest you keep with the client-side initiating STUN requests. It's been our experience that the device behind the NAT (on the private/internal side) is always at a distinct advantage over the one on the outside of it for keepalives. If you want the reasons I can list them, but it's probably not worth the time and I think this has been said before by others on this mailing list in the past. It would be nice though if the server could give the client a stun-interval value to use. Like many solutions do with Registers and expires/min-expires today. Some regions of the world seem to have insanely short NAT cache timers, and others have very long ones, and there's a penalty to be paid for the former. -hadriel > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, July 09, 2006 4:26 AM > To: Jeroen van Bemmel; Rohan Mahy; sip@ietf.org > Cc: Miguel Garcia; Cullen Jennings > Subject: [Sip] STUN keep-alive: Client vs server generating requests > > Moved from the "STUN keep-alive: Where to document it? (was [Sip] Re: A > coment todraft-ietf-sip-outbound-04)" thread: > > Jeroen wrote: > > > >>One issue with that proposal was that the client doesn't know if e.g. a > NAT > >>is rebooting. It would require some timer, so that the client can assume > a > >>reboot has >occured if it doesn't receive a STUN request before the > timer > >>expires. > > >Also client-initiated STUN requires such a periodic timer. Furthermore, > >sending a STUN request and then waiting for a response also implicitly > uses > >a timer (typical implementation is the sending thread blocking on some > event > >with a timeout, reception of the response setting this event) > > Correct. But, these timers a "local" client timers aren't they, i.e. how > often it sends STUN requests and for how long it should wait for a reply? > > In case the server generates the STUN request the client must know which > timers the server uses. That can of course be a standardized value, OR it > can be provided in some header, but the client needs to know about it. > > Regards, > > Christer > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 18:05:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzhNA-0002q0-49; Sun, 09 Jul 2006 18:03:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzhN8-0002pv-9a for sip@ietf.org; Sun, 09 Jul 2006 18:03:26 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzhN6-0000FO-Rt for sip@ietf.org; Sun, 09 Jul 2006 18:03:26 -0400 Received: (qmail 13438 invoked by uid 0); 9 Jul 2006 22:03:23 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 Jul 2006 22:03:23 -0000 Message-ID: <00a101c6a3a3$7a0df690$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Hadriel Kaplan" , References: <05ea01c6a3a2$689236c0$a7c8000a@acmepacket.com> Subject: Re: [Sip] STUN keep-alive: Client vs server generating requests Date: Mon, 10 Jul 2006 00:03:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel, OK, I'll take your word for it. If we then interpret such a 'stun-interval=xxx' as an indication of support for STUN (and say 'no STUN unless interval is provided'), I'm happy Only trouble is: in many cases, the proxy would not know which type of NAT there is in between, let alone how long it caches... Regards, Jeroen ----- Original Message ----- From: "Hadriel Kaplan" To: "'Jeroen van Bemmel'" ; Sent: Sunday, July 09, 2006 11:55 PM Subject: RE: [Sip] STUN keep-alive: Client vs server generating requests >I would strongly suggest you keep with the client-side initiating STUN > requests. It's been our experience that the device behind the NAT (on the > private/internal side) is always at a distinct advantage over the one on > the > outside of it for keepalives. If you want the reasons I can list them, > but > it's probably not worth the time and I think this has been said before by > others on this mailing list in the past. > > It would be nice though if the server could give the client a > stun-interval > value to use. Like many solutions do with Registers and > expires/min-expires > today. Some regions of the world seem to have insanely short NAT cache > timers, and others have very long ones, and there's a penalty to be paid > for > the former. > > -hadriel > > >> -----Original Message----- >> From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] >> Sent: Sunday, July 09, 2006 4:26 AM >> To: Jeroen van Bemmel; Rohan Mahy; sip@ietf.org >> Cc: Miguel Garcia; Cullen Jennings >> Subject: [Sip] STUN keep-alive: Client vs server generating requests >> >> Moved from the "STUN keep-alive: Where to document it? (was [Sip] Re: A >> coment todraft-ietf-sip-outbound-04)" thread: >> >> Jeroen wrote: >> >> >> >>One issue with that proposal was that the client doesn't know if e.g. a >> NAT >> >>is rebooting. It would require some timer, so that the client can >> >>assume >> a >> >>reboot has >occured if it doesn't receive a STUN request before the >> timer >> >>expires. >> >> >Also client-initiated STUN requires such a periodic timer. Furthermore, >> >sending a STUN request and then waiting for a response also implicitly >> uses >> >a timer (typical implementation is the sending thread blocking on some >> event >> >with a timeout, reception of the response setting this event) >> >> Correct. But, these timers a "local" client timers aren't they, i.e. how >> often it sends STUN requests and for how long it should wait for a reply? >> >> In case the server generates the STUN request the client must know which >> timers the server uses. That can of course be a standardized value, OR it >> can be provided in some header, but the client needs to know about it. >> >> Regards, >> >> Christer >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 18:11:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzhSn-0004K9-07; Sun, 09 Jul 2006 18:09:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzhSm-0004K4-Av for sip@ietf.org; Sun, 09 Jul 2006 18:09:16 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzhSk-0000N8-VT for sip@ietf.org; Sun, 09 Jul 2006 18:09:16 -0400 Received: (qmail 14932 invoked by uid 0); 9 Jul 2006 22:09:08 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 Jul 2006 22:09:08 -0000 Message-ID: <00a801c6a3a4$4b2a1150$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Mon, 10 Jul 2006 00:09:05 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Sip] outbound: recovery in case of flow failure X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0528211146==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0528211146== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A5_01C6A3B5.0E9D8490" This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C6A3B5.0E9D8490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Suggestion for section 5.3 (Edge proxy forwarding) and 6.2 (registrar = forwarding): When a flow is found but fails upon trying, the registrar / = edge proxy could send back a '480 Temporarily Unavailable' response, = with a Retry-After equal to the maximum time a flow recovery would take = (ie about 29 seconds for UDP, 120 seconds for TCP) This could help the caller in deciding to retry after giving the callee = enough time to restore its flow Regards, Jeroen ------=_NextPart_000_00A5_01C6A3B5.0E9D8490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Suggestion for section 5.3 (Edge proxy = forwarding)=20 and 6.2 (registrar forwarding): When a flow is found but fails upon = trying, the=20 registrar / edge proxy could send back a '480 Temporarily Unavailable' = response,=20 with a Retry-After equal to the maximum time a flow recovery would take = (ie=20 about 29 seconds for UDP, 120 seconds for TCP)
 
This could help the caller in deciding = to retry=20 after giving the callee enough time to restore its flow
 
Regards,
 
Jeroen
------=_NextPart_000_00A5_01C6A3B5.0E9D8490-- --===============0528211146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0528211146==-- From sip-bounces@ietf.org Sun Jul 09 18:14:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzhWS-000565-HZ; Sun, 09 Jul 2006 18:13:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzhWR-00055z-4F for sip@ietf.org; Sun, 09 Jul 2006 18:13:03 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzhWP-0000SB-Rd for sip@ietf.org; Sun, 09 Jul 2006 18:13:03 -0400 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.03) id AF68023C; Sun, 09 Jul 2006 18:12:56 -0400 From: "Hadriel Kaplan" To: "'Juha Heinanen'" Subject: RE: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Sun, 9 Jul 2006 18:12:57 -0400 Message-ID: <05eb01c6a3a4$d59bcf40$a7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <17583.59198.391812.55065@rautu.tutpro.com> Thread-Index: AcaisYrnM4TyOuKwR3OytQ7DUTxN+AA8PBXQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm really confused now. If there are 2 proxies, with "one flow to each", then clearly the UAC created a flow to each, and registered through each. Jeroen's case is one where the operator configures 2 outbound proxies, but the UAC only USES one - i.e, it only registers and stuns through/to one. Not that it somehow registers to it but rejects requests from it. (right Jeroen?) Whether you as an operator configure all UACs with 2 proxies, or more, does not make a difference for his case - if the UAC only establishes 1 flow, then it only registers through one proxy, and only one proxy adds a path header, and the registrar only has one flow and registration contact info to use to reach the UAC, and 100% of the requests go that 1 proxy path. The other proxy(s) know nothing about the UAC, short of being able to find out from the location server that it's through the 1 proxy that the UAC actually registered through. To suggest otherwise, that somehow the secondary proxy gets 50% of the requests (and they fail) even if the UAC did not register through it, means that in a failure mode where the UAC can only reach one proxy, then it only gets 50% service. That would be a significant step BACKWARDS from today's fairly common reliability mechanisms and availability models, IMO. -hadriel > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Saturday, July 08, 2006 1:11 PM > To: Hadriel Kaplan > Cc: sip@ietf.org > Subject: RE: [Sip] A coment to draft-ietf-sip-outbound-04 > > Hadriel Kaplan writes: > > > > in the above situation, assuming that network has two proxies, if UA > > > decides to establish only one flow instead of two, then the likely > hood > > > is 50% that incoming call to the UA cannot be establishes. it thus > > > makes no sense for the UA to violate network policy on number of > flows. > > > > That doesn't make any sense to me. > > obviously you didn't notice that in the example there was two proxies, > one flow to each. > > -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 18:36:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzhrJ-00026M-6V; Sun, 09 Jul 2006 18:34:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzhrI-00026H-1H for sip@ietf.org; Sun, 09 Jul 2006 18:34:36 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzhrG-0000t2-Jc for sip@ietf.org; Sun, 09 Jul 2006 18:34:36 -0400 Received: (qmail 24949 invoked by uid 0); 9 Jul 2006 22:34:27 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 Jul 2006 22:34:27 -0000 Message-ID: <00bd01c6a3a7$d466a340$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Hadriel Kaplan" , "'Juha Heinanen'" References: <05eb01c6a3a4$d59bcf40$a7c8000a@acmepacket.com> Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Mon, 10 Jul 2006 00:34:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hadriel, > I'm really confused now. If there are 2 proxies, with "one flow to each", > then clearly the UAC created a flow to each, and registered through each. > Jeroen's case is one where the operator configures 2 outbound proxies, but > the UAC only USES one - i.e, it only registers and stuns through/to one. > Not that it somehow registers to it but rejects requests from it. (right > Jeroen?) > Right, it establishes only 1 registration (like most UACs do today) and keeps this flow alive > Whether you as an operator configure all UACs with 2 proxies, or more, > does > not make a difference for his case - if the UAC only establishes 1 flow, > then it only registers through one proxy, and only one proxy adds a path > header, and the registrar only has one flow and registration contact info > to > use to reach the UAC, and 100% of the requests go that 1 proxy path. The > other proxy(s) know nothing about the UAC, short of being able to find out > from the location server that it's through the 1 proxy that the UAC > actually > registered through. > > To suggest otherwise, that somehow the secondary proxy gets 50% of the > requests (and they fail) even if the UAC did not register through it, > means > that in a failure mode where the UAC can only reach one proxy, then it > only > gets 50% service. That would be a significant step BACKWARDS from today's > fairly common reliability mechanisms and availability models, IMO. > In my mind, how you would end up with this "50% model" is to have 2 registrar instances configured in DNS as load-balancing alternatives for the domain. With or without edge proxies, this model would indeed require the UA to setup 2 registrations/flows, or miss 50% of the requests (on average). I am no great fan of this model, but if people want to do this, the UA needs to know how many registrations it is expected to create. This is *not* equal to the number of URIs in the magically discovered outbound proxy set, because the UA cannot tell how many distinct registrar instances are reachable through this set. The number of registrations cannot be larger than the number of URIs in the set, but it could be less (i.e. value is in range 1..#URIs) Regards, Jeroen > -hadriel > > >> -----Original Message----- >> From: Juha Heinanen [mailto:jh@tutpro.com] >> Sent: Saturday, July 08, 2006 1:11 PM >> To: Hadriel Kaplan >> Cc: sip@ietf.org >> Subject: RE: [Sip] A coment to draft-ietf-sip-outbound-04 >> >> Hadriel Kaplan writes: >> >> > > in the above situation, assuming that network has two proxies, if UA >> > > decides to establish only one flow instead of two, then the likely >> hood >> > > is 50% that incoming call to the UA cannot be establishes. it thus >> > > makes no sense for the UA to violate network policy on number of >> flows. >> > >> > That doesn't make any sense to me. >> >> obviously you didn't notice that in the example there was two proxies, >> one flow to each. >> >> -- juha > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 19:52:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzj38-0006bl-Ug; Sun, 09 Jul 2006 19:50:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzj37-0006bg-Kq for sip@ietf.org; Sun, 09 Jul 2006 19:50:53 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzj36-0000Jy-B2 for sip@ietf.org; Sun, 09 Jul 2006 19:50:53 -0400 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.03) id A6520380; Sun, 09 Jul 2006 19:50:42 -0400 From: "Hadriel Kaplan" To: "'Jeroen van Bemmel'" , "'Juha Heinanen'" Subject: RE: [Sip] A coment to draft-ietf-sip-outbound-04 Date: Sun, 9 Jul 2006 19:50:44 -0400 Message-ID: <061601c6a3b2$7e79b750$a7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <00bd01c6a3a7$d466a340$31713b51@BEMBUSTER> Thread-Index: Acajp9oQ/NVR775oQjuSmMTZE6kxugABtJ9g X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeroen, inline... > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > Hi Hadriel, > > In my mind, how you would end up with this "50% model" is to have 2 > registrar instances configured in DNS as load-balancing alternatives for > the > domain. With or without edge proxies, this model would indeed require the > UA > to setup 2 registrations/flows, or miss 50% of the requests (on average). I would think any model using 2 registrars in this way has to use a shared registrar database, a database exchange/sync mechanism, or a "if not on this registrar then try the other" mechanism. There is simply no way to guarantee every UAC has reach-ability to both registrars all the time. There are just too many failure modes, some of which are long-lived. They would just be asking for trouble, imho. :) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 21:06:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzkCm-0006jF-6R; Sun, 09 Jul 2006 21:04:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzkCk-0006iZ-4r for sip@ietf.org; Sun, 09 Jul 2006 21:04:54 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzkCi-0006ZI-Sn for sip@ietf.org; Sun, 09 Jul 2006 21:04:54 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 09 Jul 2006 18:04:53 -0700 X-IronPort-AV: i="4.06,221,1149490800"; d="scan'208"; a="1836701909:sNHT29417408" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k6A14q5K007131; Sun, 9 Jul 2006 18:04:52 -0700 Received: from dwingwxp (sjc-vpn4-751.cisco.com [10.21.82.239]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6A14o46027268; Sun, 9 Jul 2006 18:04:51 -0700 (PDT) From: "Dan Wing" To: "'Elwell, John'" , Subject: RE: [Sip] Issue 4 in draft-ietf-sip-connected-identity-00.txt Date: Sun, 9 Jul 2006 21:04:45 -0400 Keywords: direct-to-dwing Message-ID: <00cb01c6a3bc$d960b290$ef52150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcajeCugiB9jTg4+TsOtbKNPluhD5gARImmA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <50B1CBA96870A34799A506B2313F2667095641C2@ntht201e.siemenscomms.co.uk> DKIM-Signature: a=rsa-sha1; q=dns; l=504; t=1152493492; x=1153357492; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[Sip]=20Issue=204=20in=20draft-ietf-sip-connected-identity-00.tx t; X=v=3Dcisco.com=3B=20h=3DdRMymw3Rtq/6zpz0eo/DL9lYfKk=3D; b=MlJ83AP84Ewobx/+JvFUFpYeKhc4amOdYrdd4h/Ay13P3pGRoKHntQx0xEoAM5Bt9FCXDPqQ 3/fNatnPz5k/mHixqAEbfrfhdSp6S+w6+tAX+3HrrPr6hGeXsKmCqtX+; Authentication-Results: sj-dkim-8.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Yes, I agree with your motivation for being able to have > signed SDP in the reverse direction. This doesn't necessarily mean > UPDATE has to be used - re-INVITE would do, but I prefer to use > UPDATE unless there are other reasons for using re-INVITE. > > The question is whether we should mandate including an SDP > offer in the UPDATE so that we always have the benefit of > this signature. Agreed. And if the SDP is exactly the same, I see a lot of value and little harm. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 21:14:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzkKF-00087f-As; Sun, 09 Jul 2006 21:12:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzkKD-00087V-6x for sip@ietf.org; Sun, 09 Jul 2006 21:12:37 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzkKB-0006lT-T7 for sip@ietf.org; Sun, 09 Jul 2006 21:12:37 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 09 Jul 2006 18:12:35 -0700 X-IronPort-AV: i="4.06,221,1149490800"; d="scan'208"; a="1836702837:sNHT30418024" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k6A1CWT9024227; Sun, 9 Jul 2006 18:12:32 -0700 Received: from dwingwxp (sjc-vpn4-751.cisco.com [10.21.82.239]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6A1CV46028368; Sun, 9 Jul 2006 18:12:31 -0700 (PDT) From: "Dan Wing" To: "'Elwell, John'" , Subject: RE: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt Date: Sun, 9 Jul 2006 21:12:26 -0400 Keywords: direct-to-dwing Message-ID: <014201c6a3bd$eb8ab3c0$ef52150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcajnndmJvPovuf2TSCyRDmHpW15NQAHtKoA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <50B1CBA96870A34799A506B2313F2667095641CB@ntht201e.siemenscomms.co.uk> DKIM-Signature: a=rsa-sha1; q=dns; l=3346; t=1152493952; x=1153357952; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[Sip]=20Issue=202=20in=20draft-ietf-sip-connected-identity-00.tx t; X=v=3Dcisco.com=3B=20h=3DZSIM5S5QfLQbqL0P0FGFNeY7QSc=3D; b=Pry00KRuUE6qqwkAdHKHj7LKUCEKB3eiaMgEiVmtaau3lj81h/bAEYdsTPrDGtfqiMCv/Dd6 2rYzD7H18sPslzrycQGeVZIfkc5p6aAx3x2CU0saz5s/d5h9TNVfH/E/; Authentication-Results: sj-dkim-7.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > I am not sure that would work. The problem is the UAC > typically does not insert the Identity header field in a > request, this is typically done by an authentication service > at the outbound proxy. So the fact that the request went > through an authentication service and had an Identity header > field added does not mean that the response will go through > a verification service. I agree there is nothing a UA can do to ensure its request gets an Identity header added. All I'm saying is that if you receive a request with an Identity headers, there is a pretty darn high likelyhood that the requestor is interested in having your response authenticated (by a backwards request using connected-identity). All you can do is send a request back to him and hope that your request will get an Identity header added by your authentication service. If it doesn't get an Identity header added, the requestor's local policy or implementation will decide what to do next: accept the call or drop it (because the connected-identity response lacks an Identity header). I argue that an additional tag wouldn't convey any additional meaning over my proposal. -d > However, I am open to opinions on that. > > John > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: 08 July 2006 02:21 > > To: Elwell, John; sip@ietf.org > > Subject: RE: [Sip] Issue 2 in > draft-ietf-sip-connected-identity-00.txt > > > > I hadn't noticed any followups to this issue. I have a suggestion: > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: Tuesday, May 02, 2006 1:21 PM > > > To: sip@ietf.org > > > Subject: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt > > > > > > The second issue concerns the fact that an UPDATE request in the > > > backward direction following dialog establishment can be wasted if > > > the peer UA (the UAC for the INVITE transaction) does not support > > > it. It states: > > > > > > "OPEN ISSUE: If the identity has has not changed > compared with > > > the URI in the To header field and the UAC (for the INVITE > > > request) does not support verification of an > Identity header, > > > this UPDATE or re-INVITE transaction would fulfil no useful > > > purpose. However, the UAS (for the INVITE transaction) does > > > not know this. In order to save this round trip, should we > > > have an additional option tag to indicate support > for receipt > > > of the Identity header on mid- dialog requests? > Then if this > > > option tag is not present in the INVITE request the > additional > > > transaction could be omitted. Note that the > id-change option > > > tag does not seem appropriate for this purpose, since a UA > > > could support a change of URI without supporting Identity." > > > > > > Whilst I do not wish to proliferate option tags, I do see some > > > benefit in such a tag. Any opinions? > > > > If an Invite arrives with both Identity and the id-change tag, > > it indicates the offerer understands both Identity and connected- > > identity, so the answerer should generate an request (UPDATE or > > re-INVITE). > > > > -d > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 21:43:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzklx-0006qM-Lt; Sun, 09 Jul 2006 21:41:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzklw-0006qE-B3 for sip@ietf.org; Sun, 09 Jul 2006 21:41:16 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzkls-0007vv-Lv for sip@ietf.org; Sun, 09 Jul 2006 21:41:16 -0400 Received: from office-srv-04.HQ.TELIO.NO (office-srv-04.hq.telio.no [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id B722619447E for ; Mon, 10 Jul 2006 03:41:09 +0200 (CEST) Received: from [10.0.1.2] ([192.168.3.11]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 03:40:24 +0200 In-Reply-To: <50B1CBA96870A34799A506B2313F266708CFA25D@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F266708CFA25D@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1482ff635db4cef9a264bf3d59c7223f@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt Date: Mon, 10 Jul 2006 03:41:26 +0200 To: "Elwell, John" X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 10 Jul 2006 01:40:24.0773 (UTC) FILETIME=[D0712750:01C6A3C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What is the point of supporting id-change without supporting Identity. If you support connected-identity, then you MUST support Identity RFC. That's it. Hisham On May 2, 2006, at 10:21 PM, Elwell, John wrote: > The second issue concerns the fact that an UPDATE request in the > backward > direction following dialog establishment can be wasted if the peer UA > (the > UAC for the INVITE transaction) does not support it. It states: > > "OPEN ISSUE: If the identity has has not changed compared with > the > URI in the To header field and the UAC (for the INVITE request) > does not support verification of an Identity header, this UPDATE > or re-INVITE transaction would fulfil no useful purpose. > However, > the UAS (for the INVITE transaction) does not know this. In > order > to save this round trip, should we have an additional option tag > to indicate support for receipt of the Identity header on mid- > dialog requests? Then if this option tag is not present in the > INVITE request the additional transaction could be omitted. Note > that the id-change option tag does not seem appropriate for this > purpose, since a UA could support a change of URI without > supporting Identity." > > Whilst I do not wish to proliferate option tags, I do see some benefit > in > such a tag. Any opinions? > > John > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 21:46:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzkph-0000yK-US; Sun, 09 Jul 2006 21:45:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzkpg-0000yA-1r for sip@ietf.org; Sun, 09 Jul 2006 21:45:08 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzkpe-0008NF-IJ for sip@ietf.org; Sun, 09 Jul 2006 21:45:08 -0400 Received: from office-srv-04.HQ.TELIO.NO (office-srv-04.hq.telio.no [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 0B8CC19447E for ; Mon, 10 Jul 2006 03:45:06 +0200 (CEST) Received: from [10.0.1.2] ([192.168.3.11]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 03:44:20 +0200 In-Reply-To: <50B1CBA96870A34799A506B2313F266708CFA25F@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F266708CFA25F@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Issue 4 in draft-ietf-sip-connected-identity-00.txt Date: Mon, 10 Jul 2006 03:45:15 +0200 To: "Elwell, John" X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 10 Jul 2006 01:44:21.0087 (UTC) FILETIME=[5D4BCEF0:01C6A3C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't think we should mandate UPDATE. INVITE does the job if an implementer chooses not to do UPDATE. Hisham On May 2, 2006, at 10:23 PM, Elwell, John wrote: > The fourth issue is not actually in draft-00 but was raised > subsequently. If > a UA supports a change of From header field URI mid-dialog, as > indicated by > the "id-change" option tag, we could mandate that it also support the > SIP > UPDATE method. Then the peer UA in a dialog would be free to use the > UPDATE > method to report connected identity, rather than the less suitable > re-INVITE > method. The use of UPDATE means 2 messages instead of 3 and avoids the > need > for an offer-answer exchange. I heard no objections when this was > proposed a > few days ago. Do we have consensus? > > John > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 21:55:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzky3-0004xI-Cj; Sun, 09 Jul 2006 21:53:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzky2-0004xC-BL for sip@ietf.org; Sun, 09 Jul 2006 21:53:46 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzky1-0001LU-TH for sip@ietf.org; Sun, 09 Jul 2006 21:53:46 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J2500001ZY6NV@siemenscomms.co.uk> for sip@ietf.org; Mon, 10 Jul 2006 02:54:06 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J2500EBZZY6OQ@siemenscomms.co.uk>; Mon, 10 Jul 2006 02:54:06 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Jul 2006 02:53:44 +0100 Content-return: allowed Date: Mon, 10 Jul 2006 02:53:38 +0100 From: "Elwell, John" Subject: RE: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt To: Dan Wing , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667095641D0@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan, That was not what I was trying to say. The UAC (for the INVITE request) has no control over whether an Identity header field is added by its domain proxy. So just because the UAS receives an INVITE request with an Identity header field, does not mean that the UAC put it there and would be interested in receiving an UPDATE request with an Identity header field. However, I don't have a strong objection to the UAS (for the INVITE) always sending back an UPDATE even if the From header URI would be unchanged from that in the To header URI of the INVITE request. Regards, John > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: 10 July 2006 02:12 > To: Elwell, John; sip@ietf.org > Subject: RE: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt > > > I am not sure that would work. The problem is the UAC > > typically does not insert the Identity header field in a > > request, this is typically done by an authentication service > > at the outbound proxy. So the fact that the request went > > through an authentication service and had an Identity header > > field added does not mean that the response will go through > > a verification service. > > I agree there is nothing a UA can do to ensure its request > gets an Identity header added. > > All I'm saying is that if you receive a request with an Identity > headers, there is a pretty darn high likelyhood that the requestor > is interested in having your response authenticated (by a backwards > request using connected-identity). All you can do is send a request > back to him and hope that your request will get an Identity header > added by your authentication service. If it doesn't get an Identity > header added, the requestor's local policy or implementation will > decide what to do next: accept the call or drop it (because the > connected-identity response lacks an Identity header). > > I argue that an additional tag wouldn't convey any additional > meaning over my proposal. > > -d > > > However, I am open to opinions on that. > > > > John > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Sent: 08 July 2006 02:21 > > > To: Elwell, John; sip@ietf.org > > > Subject: RE: [Sip] Issue 2 in > > draft-ietf-sip-connected-identity-00.txt > > > > > > I hadn't noticed any followups to this issue. I have a > suggestion: > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: Tuesday, May 02, 2006 1:21 PM > > > > To: sip@ietf.org > > > > Subject: [Sip] Issue 2 in > draft-ietf-sip-connected-identity-00.txt > > > > > > > > The second issue concerns the fact that an UPDATE request in the > > > > backward direction following dialog establishment can > be wasted if > > > > the peer UA (the UAC for the INVITE transaction) does > not support > > > > it. It states: > > > > > > > > "OPEN ISSUE: If the identity has has not changed > > compared with > > > > the URI in the To header field and the UAC (for the INVITE > > > > request) does not support verification of an > > Identity header, > > > > this UPDATE or re-INVITE transaction would fulfil > no useful > > > > purpose. However, the UAS (for the INVITE > transaction) does > > > > not know this. In order to save this round trip, > should we > > > > have an additional option tag to indicate support > > for receipt > > > > of the Identity header on mid- dialog requests? > > Then if this > > > > option tag is not present in the INVITE request the > > additional > > > > transaction could be omitted. Note that the > > id-change option > > > > tag does not seem appropriate for this purpose, since a UA > > > > could support a change of URI without supporting > Identity." > > > > > > > > Whilst I do not wish to proliferate option tags, I do see some > > > > benefit in such a tag. Any opinions? > > > > > > If an Invite arrives with both Identity and the id-change tag, > > > it indicates the offerer understands both Identity and connected- > > > identity, so the answerer should generate an request (UPDATE or > > > re-INVITE). > > > > > > -d > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 21:58:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzl0e-00086N-N3; Sun, 09 Jul 2006 21:56:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzl0d-0007xg-1T for sip@ietf.org; Sun, 09 Jul 2006 21:56:27 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzl0b-0001hH-My for sip@ietf.org; Sun, 09 Jul 2006 21:56:27 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J260010102M88@siemenscomms.co.uk> for sip@ietf.org; Mon, 10 Jul 2006 02:56:46 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J2600ECS02MOQ@siemenscomms.co.uk>; Mon, 10 Jul 2006 02:56:46 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Jul 2006 02:56:24 +0100 Content-return: allowed Date: Mon, 10 Jul 2006 02:56:22 +0100 From: "Elwell, John" Subject: RE: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt To: Hisham Khartabil Message-id: <50B1CBA96870A34799A506B2313F2667095641D1@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hisham, Well that was how I had it originally, but I was asked to consider separating it. I don't have a strong opinion. John > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: 10 July 2006 02:41 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt > > What is the point of supporting id-change without supporting > Identity. > If you support connected-identity, then you MUST support > Identity RFC. > That's it. > > Hisham > > On May 2, 2006, at 10:21 PM, Elwell, John wrote: > > > The second issue concerns the fact that an UPDATE request in the > > backward > > direction following dialog establishment can be wasted if > the peer UA > > (the > > UAC for the INVITE transaction) does not support it. It states: > > > > "OPEN ISSUE: If the identity has has not changed > compared with > > the > > URI in the To header field and the UAC (for the > INVITE request) > > does not support verification of an Identity header, > this UPDATE > > or re-INVITE transaction would fulfil no useful purpose. > > However, > > the UAS (for the INVITE transaction) does not know this. In > > order > > to save this round trip, should we have an additional > option tag > > to indicate support for receipt of the Identity header on mid- > > dialog requests? Then if this option tag is not > present in the > > INVITE request the additional transaction could be > omitted. Note > > that the id-change option tag does not seem > appropriate for this > > purpose, since a UA could support a change of URI without > > supporting Identity." > > > > Whilst I do not wish to proliferate option tags, I do see > some benefit > > in > > such a tag. Any opinions? > > > > John > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 22:27:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzlT2-00063f-KZ; Sun, 09 Jul 2006 22:25:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzlT1-00063X-7E for sip@ietf.org; Sun, 09 Jul 2006 22:25:47 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzlSz-0003uI-Nv for sip@ietf.org; Sun, 09 Jul 2006 22:25:47 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J26008011FIE0@siemenscomms.co.uk> for sip@ietf.org; Mon, 10 Jul 2006 03:26:06 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J260071U1FISG@siemenscomms.co.uk>; Mon, 10 Jul 2006 03:26:06 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Jul 2006 03:25:44 +0100 Content-return: allowed Date: Mon, 10 Jul 2006 03:25:36 +0100 From: "Elwell, John" Subject: RE: [Sip] concerns on draft-elwell-sip-tispan-connected-identity- 01 To: Jonathan Rosenberg , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F2667095641D2@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, Thanks for reading this and commenting. I will leave the TISPAN guys to reply on the TISPAN reasons for needing two identities (although this was discussed at length on an old thread) and their rationale for using PAI for one / Identity for the other. All I can say is that the document lays down a concern that some TISPAN people have about the connected-identity draft and possible ways to overcome that concern. One solution, of course, would be to do nothing - leave the connected-identity draft as it is. But in taking that course we will need to show that TISPAN requirements can be met by some other means. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 07 July 2006 20:50 > To: IETF SIP List > Subject: [Sip] concerns on > draft-elwell-sip-tispan-connected-identity-01 > > I wasn't able to find any disucssion on this draft so far in the > archives; my apologies if I missed it. > > This draft concerns me greatly. > > The first thing that worries me is the general idea that 3gpp > or tispan > get to 'choose' which SIP header field contains what type of > identity. > They get to do no such thing. These header fields have > defined meanings. > Having either organization decide to specify their own interpretation > for the type of identity that goes in there is a guarnateed > receipe for > huge, massive, and unending interoperability failures. > > On the technical front, I strongly disagree that the From and > P-Asserted-Identity represent different types of identity in any way. > They both have always identified the user that is the sender of the > request. In cases where you had an enterprise user Joe making a SIP > call, the From would contain sip:joe@enterprise.com and this would be > authenticated by the proxy in the enterprise, followed by > insertion of a > P-Asserted-ID which says the same thing. The From, in this use case, > should not be sip:enterprise.com. > > Next, I am puzzled by the requirement to deliver separate > identities to > the calling party for these two things. I understand the concept of a > billing identity being separate from the identity of the caller. I do > not, however, understand why the billing ID is of any interest to the > called party whatsoever. It seems that this would, at best, be of > interest only within the domain of the calling party. Since its also > directly inferrable from the identity of the caller (presumably the > database contains a linkage between the two), I also don't see why it > would need to be carried in the sip message itself. Is there > a use case > where there is not a provisioned relationship between the user making > the call and the billing entity? Certainly there is a clear direct > relationship in the enterprise example in the draft. > > Finally, even if I buy the idea that there are two identities > and that > they both need to be conveyed, I strongly disagree with the > notion that > one of them can be conveyed with SIP-identity, while P-A-ID is OK for > the other. There are certain well-known technical limitations with > P-A-ID which sip-identity addresses. There is nothing about > the nature > of the identity which invalidates any of those issues. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 09 23:51:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzmmZ-0000ux-9X; Sun, 09 Jul 2006 23:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzmmY-0000up-Ie for sip@ietf.org; Sun, 09 Jul 2006 23:50:02 -0400 Received: from [2001:5c0:8fff:fffe::4c3d] (helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzmmU-0002Nb-S4 for sip@ietf.org; Sun, 09 Jul 2006 23:50:02 -0400 Received: from [10.0.1.2] ([142.131.134.168]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6A3mUpw043057 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 9 Jul 2006 22:49:20 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0306223F-C113-47A0-B148-5E0E5B7E2159@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Sip] Proposals for review process to conclude WGLCs Date: Sun, 9 Jul 2006 22:48:27 -0500 To: Mary Barnes X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Time zones are going to be an issue with any real-time review process. Maybe it is an issue we can deal with, but I suspect some number people who would otherwise participate may be locked out, or at least discouraged, by the idea of doing conference calls in their normal sleep cycle. On Jul 8, 2006, at 9:10 PM, Mary Barnes wrote: > You can add another vote in support of option 1), as I think it > increases the level of commitment for the reviewers, along with the > document editor/authors. It might also prove quite useful in terms of > resolving some issues in real-time, thus reducing the amount of > thrashing on specific issues on the list due to misunderstandings via > email. As you've already identified, a recorder would be > imperative for > the process. > > I also support the idea of SIP doing something different than SIPPING > and at year end we can evaluate both options and see what seems to > work > best. I'm beginning to think the SIPPING approach might be much better > applied early in the cycle (i.e, for the first few iterations), but > that > the conference calls might be the most effective way to handle the > WGLCs. > > Obviously, any of the approaches requires committed and dedicated > reviewers for the documents. The response in the SIPPING WG has been > pretty good, but I think it would be optimal to add the requirement > that > a document isn't accepted as a WG document, unless you also have the > reviewers committed. This might delay some things, but in my > mind, if > we don't have WG members committed to the work, along with the > editor/authors, we don't have the resources to effectively complete > the > work (in a timely manner). > > Mary > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, June 30, 2006 3:26 PM > To: IETF SIP List > Subject: [Sip] Proposals for review process to conclude WGLCs > > > > One of the questions we've struggled with is how to get sufficient > review on a document under WGLC to make sure it's really done. > > > SIPPING is following a new procedure with designated reviewers, doing > review by email, and sending stuff back to the. Apparently this > suffers from the expected issues, with designated reviewers sometimes > not quite meeting their review commitments. > > Cisco made me take a peer-review refresher class the other day, so > this started me thinking about some alternatives. > > In the model taught in this class, each peer review includes 1) a > "moderator" or "reader" who frames the questions and keeps things on > track, 2) a "recorder" who records conclusions and issues raised > during the review, 3) the author(s), who neither presents no > interprets the work, but does respond to specific questions about it, > and 4) the reviewers, who hopefully have expertise and have committed > time to the review. > > > I'd like to propose a couple of alternative models to what SPPING has > been doing and seeing if either resonates with our group. > > > 1) Real-time review sessions via conference call: When we get ready > to do a final review, the chairs assemble a review team. Presumably, > this review team is assembled by polling the list for volunteers, and > by pushing extra hard for stakeholders and other people with specific > expertise. The moderator builds up a checklist and set of basic > questions to consider, and distributes it to the review team. At a > tiem agreed to by enough of the participants, we have a conference > call, not to exceed two hours, and work through the checklist in a > moderated fashion. At the conclusion of that two hours, we either > reach a positive decision, a negative decision (with list of issues > and actions), or decide we need more review. > > > 2) Moderated email-review, using the entire list as the "review > team". In this model, the chairs pick a moderator and recorder for > the review. The moderator sets up a checklist and sends it to the > list, along with an announcement of the review. The moderator then > goes through the checklist item-by-item on list, polling for > comments. The recorder records any issues or conclusions. Each item > might take two or three days for primary comments, but could be > revisited during the review process if needed. The author could > answer specific questions about the draft, but not paraphrase or > interpret. At the conclusion of the review, the moderator and > reviewer would report to the chairs, who would decide whether we have > issues, a conclusion, or need further review. > > > What do y'all think? > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 00:27:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FznL5-0005vu-Rc; Mon, 10 Jul 2006 00:25:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FznL3-0005vf-Tg for sip@ietf.org; Mon, 10 Jul 2006 00:25:41 -0400 Received: from mail.globalsuite.net ([69.46.103.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FznBh-00045s-U0 for sip@ietf.org; Mon, 10 Jul 2006 00:16:02 -0400 Received: from [198.18.87.129] (unknown [67.70.246.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 8C637BC3; Sun, 9 Jul 2006 22:15:59 -0600 (MDT) Message-ID: <44B1D47B.2060805@ntt-at.com> Date: Sun, 09 Jul 2006 21:15:55 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Dan Wing Subject: Re: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt References: <033e01c6a30f$fd4e4580$d351150a@amer.cisco.com> In-Reply-To: <033e01c6a30f$fd4e4580$d351150a@amer.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: sip@ietf.org, "'Elwell, John'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi; Dan Wing wrote: >> I generally like the draft, and I think the work is very important. >> > > Me, too. > > >> Anyhow, AFAIK there is no distinct way to request SIP-Identity to >> AS, so just because one receives a sip-identity/id-change tag does >> not necessary mean that sender of an UPDATE will be able to send >> the sip-identity back(Even if the UAS supports sip-identity/id-change, >> the domain of the UAS might not have AS in place to provide >> sip-identity). >> > > Agreed; if we agree we need to optimize that case, we will need > an additional option tag. But, still, there isn't a way for > a UAS to "know" that his request will be protected with Identity. > So I'm not sure of the value such an additional tag would bring > over my suggestion. > In past, there has been RFC which proposed the use of proxy-require for the next hop only(First hop proxy removes the relevant option-tag in the proxy-require). RFC 3329 is one of the example for this, and proposal similar to that may be considered. > >> This is because there is no option tag to require proxy to add >> sip-identity, >> and because sip-identity is generally performed at AS, UA is generally >> unaware of the domian's support for sip-identity. >> >> Furthermore, because its the AS that adds sip-identity(except when >> UA has its own certificate which I think is unlikely), just because UA >> receives the sip-identity, does not necessary mean that UA sending >> the original INVITE(offerer that you have described in your comment) >> with identity-info header supports sip-identity. >> > > Even if the original UA itself doesn't support Identity, one of the > domain's proxies added the Identity signature and it's likely that > proxy may validate incoming requests containing Identity signatures. > > Agree. Regards Shida Schubert > -d > > >> Last note, looking at the sentence in 6.1 which is shown >> below, I am not sure if >> mandating UA to send an UPDATE to update its identity is aligned >> with the semantics of Supported header field. I don't really >> have a strong >> opinion on this point, but it felt a little funny to mandate >> a behavior with >> a presence of "Supported" header. >> >> Thanks & Regards >> Shida >> >> Dan Wing wrote: >> >>> I hadn't noticed any followups to this issue. I have a suggestion: >>> >>> >>> >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>> Sent: Tuesday, May 02, 2006 1:21 PM >>>> To: sip@ietf.org >>>> Subject: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt >>>> >>>> The second issue concerns the fact that an UPDATE request in the >>>> backward direction following dialog establishment can be wasted if >>>> the peer UA (the UAC for the INVITE transaction) does not support >>>> it. It states: >>>> >>>> "OPEN ISSUE: If the identity has has not changed >>>> >> compared with >> >>>> the URI in the To header field and the UAC (for the INVITE >>>> request) does not support verification of an Identity header, >>>> this UPDATE or re-INVITE transaction would fulfil no useful >>>> purpose. However, the UAS (for the INVITE transaction) does >>>> not know this. In order to save this round trip, should we >>>> have an additional option tag to indicate support for receipt >>>> of the Identity header on mid- dialog requests? Then if this >>>> option tag is not present in the INVITE request the >>>> >> additional >> >>>> transaction could be omitted. Note that the id-change option >>>> tag does not seem appropriate for this purpose, since a UA >>>> could support a change of URI without supporting Identity." >>>> >>>> Whilst I do not wish to proliferate option tags, I do see some >>>> benefit in such a tag. Any opinions? >>>> >>>> >>> If an Invite arrives with both Identity and the id-change tag, >>> it indicates the offerer understands both Identity and connected- >>> identity, so the answerer should generate an request (UPDATE or >>> re-INVITE). >>> >>> -d >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >>> >>> >>> > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 00:44:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fznb6-0005Wl-7x; Mon, 10 Jul 2006 00:42:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fznb5-0005Wg-6v for sip@ietf.org; Mon, 10 Jul 2006 00:42:15 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fznb2-00073w-Ni for sip@ietf.org; Mon, 10 Jul 2006 00:42:15 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k6A4g1F07684; Sun, 9 Jul 2006 21:42:01 -0700 In-Reply-To: <003801c6a354$5f9c0a80$31713b51@BEMBUSTER> References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com><44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <44B0E7B3.3060801@nokia.com> <003801c6a354$5f9c0a80$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5ff412ad9f184bb5d8e5f552b09b3ad0@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Mon, 10 Jul 2006 00:42:02 -0400 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Miguel Garcia , Cullen Jennings , sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 9, 2006, at 8:37, Jeroen van Bemmel wrote: > I think the system is "broken" in the sense that it does not behave as > the authors of the draft had intended > There are 2 questions here: > 1) Is that intention expressed sufficiently clear and consistent in > the draft? > 2) Is the intended behavior (and associated system architecture) > appropriate/desirable (in all/most cases)? > > The draft seems to be written under the assumption that "reliability" > (not well defined yet what that means) can only be provided through > multiple flows. However, "outbound" (ie enabling UAs behind NAT to > register and receive incoming requests) can be done using only a > single flow, albeit with a somewhat higher chance at missing incoming > requests. the draft assumes that *if* the outbound-proxy-set contained URIs, then whoever provided the outbound-proxy-set believes that flows are needed to provide reliability. If only a single URI is provided in the outbound-proxy-set, then a single flow is sufficient. > If the system is architected as Juha was describing (2 independent > proxies, UA missing 50% of its calls when only setting up 1 flow), the > chance at missed requests for such a UA is much higher than double > that of a single flow system. I feel that outbound should certainly > not mandate such an architecture. The UA doesn't miss 50% of its calls in this case. If only one flow is registered, the registrar/home proxy will forward incoming requests only over that flow. Its just that the UA is not playing nicely with the proxies, as they would like to load balance over two flows, but they have to forward all the traffic for the UA over one flow instead. > Currently in SIP the assumption is that a single registration suffices > to receive all incoming requests for a given AoR. If we break that, it > means that current UAs won't be able to register with > "outbound-enhanced" registrars and edge proxies. That to me is not > acceptable. there is no requirement in outbound that pre-outbound registrations will not work. > In other words, a requirement is missing: "Support UAs that do not > implement this extension" What amount of "support" do you envision? thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 01:07:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FznxM-0001y2-8l; Mon, 10 Jul 2006 01:05:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FznxL-0001xx-7f for sip@ietf.org; Mon, 10 Jul 2006 01:05:15 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FznxI-0002CR-T5 for sip@ietf.org; Mon, 10 Jul 2006 01:05:15 -0400 Received: from [142.131.134.247] ([142.131.134.247]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6A56Vvh004582 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 10 Jul 2006 00:06:45 -0500 In-Reply-To: <17583.59900.171344.986622@rautu.tutpro.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> <44AE14E2.6040700@softarmor.com> <17583.59900.171344.986622@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A349A8F-A2FC-4343-8A3E-BFA27267E130@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Mon, 10 Jul 2006 00:04:13 -0500 To: Juha Heinanen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Cullen Jennings , sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 8, 2006, at 12:23 PM, Juha Heinanen wrote: > >> Or just hope it won't melt when you send it a STUN packet, meaning >> that >> you "require the operator to get it right". > >> The problem as I see it is we have no way of easily detecting an >> error >> if somebody mistakenly lists a non-compliant proxy as an outbound >> proxy >> in DHCP or some other discovery mechanism. I hate leaping off a >> trapeze >> without a safety net . . . > > no properly implemented proxy melts no matter what you sent to it. > this > kind of arguments are completely bogus. Dale has noted in a separate thread that STUN breaks TCP framing, possibly creating a self-inflicted DoS attack that the UA cannot detect to recover from. So let's say my UA comes up on a strange network and I use nmap to find nodes responding on 5060/tcp that might serve as an outbound proxy. I find one. Should I STUN it first, or ask it to process a SIP message request with a "Proxy-Require: outbound" before stunning it? The current outbound draft, although it defines such an option tag, seems to define its use only in responses to REGISTER requests issued by a registrar. It says nothing about its use by a proxy that is in- between the registrar and the UA. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 01:09:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FznzK-0003CZ-A4; Mon, 10 Jul 2006 01:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FznzJ-0003CU-PP for sip@ietf.org; Mon, 10 Jul 2006 01:07:17 -0400 Received: from mail.globalsuite.net ([69.46.103.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FznzJ-0002Gi-Ax for sip@ietf.org; Mon, 10 Jul 2006 01:07:17 -0400 Received: from [198.18.87.129] (unknown [67.70.246.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 5E6071136; Sun, 9 Jul 2006 23:07:15 -0600 (MDT) Message-ID: <44B1E07F.1030101@ntt-at.com> Date: Sun, 09 Jul 2006 22:07:11 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt References: <50B1CBA96870A34799A506B2313F2667095641D1@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F2667095641D1@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi; I think they may have separate semantics. I see "id-change" tag marely defines the ability to express ones ability to withstand the change of From. Usage of sip-identity along with id-change to provide authenticated connected identity is defining a usage of id-change. I think it's important to describe the usage somewhere. Where? I don't know.. . As discussed on this thread, id-change is used by the end-device and sip-identity as I can foresee will be likely to be deployed on the proxy. So support "id-change" also means support "sip-identity" may not work too well. Regards Shida Elwell, John wrote: > Hisham, > > Well that was how I had it originally, but I was asked to consider > separating it. I don't have a strong opinion. > > John > > >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: 10 July 2006 02:41 >> To: Elwell, John >> Cc: sip@ietf.org >> Subject: Re: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt >> >> What is the point of supporting id-change without supporting >> Identity. >> If you support connected-identity, then you MUST support >> Identity RFC. >> That's it. >> >> Hisham >> >> On May 2, 2006, at 10:21 PM, Elwell, John wrote: >> >> >>> The second issue concerns the fact that an UPDATE request in the >>> backward >>> direction following dialog establishment can be wasted if >>> >> the peer UA >> >>> (the >>> UAC for the INVITE transaction) does not support it. It states: >>> >>> "OPEN ISSUE: If the identity has has not changed >>> >> compared with >> >>> the >>> URI in the To header field and the UAC (for the >>> >> INVITE request) >> >>> does not support verification of an Identity header, >>> >> this UPDATE >> >>> or re-INVITE transaction would fulfil no useful purpose. >>> However, >>> the UAS (for the INVITE transaction) does not know this. In >>> order >>> to save this round trip, should we have an additional >>> >> option tag >> >>> to indicate support for receipt of the Identity header on mid- >>> dialog requests? Then if this option tag is not >>> >> present in the >> >>> INVITE request the additional transaction could be >>> >> omitted. Note >> >>> that the id-change option tag does not seem >>> >> appropriate for this >> >>> purpose, since a UA could support a change of URI without >>> supporting Identity." >>> >>> Whilst I do not wish to proliferate option tags, I do see >>> >> some benefit >> >>> in >>> such a tag. Any opinions? >>> >>> John >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >>> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 01:25:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzoEr-0001kp-5B; Mon, 10 Jul 2006 01:23:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzoEp-0001kk-Oc for sip@ietf.org; Mon, 10 Jul 2006 01:23:19 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzoEo-0002iB-EK for sip@ietf.org; Mon, 10 Jul 2006 01:23:19 -0400 Received: from [142.131.134.247] ([142.131.134.247]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6A5Oklb004704 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 10 Jul 2006 00:24:57 -0500 In-Reply-To: <0306223F-C113-47A0-B148-5E0E5B7E2159@estacado.net> References: <0306223F-C113-47A0-B148-5E0E5B7E2159@estacado.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06C96942-34A9-481A-86FF-F8B02CBFFC01@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Proposals for review process to conclude WGLCs Date: Mon, 10 Jul 2006 00:22:28 -0500 To: Ben Campbell X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org, Mary Barnes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 9, 2006, at 10:48 PM, Ben Campbell wrote: > Time zones are going to be an issue with any real-time review > process. Maybe it is an issue we can deal with, but I suspect some > number people who would otherwise participate may be locked out, or > at least discouraged, by the idea of doing conference calls in > their normal sleep cycle. You people sleep? No wonder we're missing milestones! Keith, we need to recalculate all the milestones to accommodate this sleep thing. Seriously, one would have to schedule an individual review to meet the schedules of the selected review team. We'd have to be careful not to mix people in very bad configurations. This can usually be sorted out for groups of 3-5 people selected from a large pool, assuming they're willing to work between 7:00 AM and midnight in their home time zones. Of course, that does leave out at least one area director I know of . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 03:27:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzq94-0001BJ-IN; Mon, 10 Jul 2006 03:25:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzq93-0001BE-Fa for sip@ietf.org; Mon, 10 Jul 2006 03:25:29 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzq90-0004if-38 for sip@ietf.org; Mon, 10 Jul 2006 03:25:29 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 609F31401BE; Mon, 10 Jul 2006 10:25:19 +0300 (EEST) Received: from rautu (eukaryote89.gprs.dnafinland.fi [62.78.106.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id B19741400B1; Mon, 10 Jul 2006 10:25:02 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id D6D97F03C1; Mon, 10 Jul 2006 10:24:59 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17586.203.649343.449065@rautu.tutpro.com> Date: Mon, 10 Jul 2006 10:24:59 +0300 From: Juha Heinanen To: "Jeroen van Bemmel" Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04 In-Reply-To: <009801c6a3a0$77b14940$31713b51@BEMBUSTER> References: <17580.7810.687558.525897@rautu.tutpro.com> <039e01c6a125$ce062950$a7c8000a@acmepacket.com> <17583.59198.391812.55065@rautu.tutpro.com> <04a801c6a2b8$8d48d2c0$31713b51@BEMBUSTER> <17583.63822.302979.834665@rautu.tutpro.com> <04cf01c6a2be$5958de00$31713b51@BEMBUSTER> <009801c6a3a0$77b14940$31713b51@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel writes: > For example, topologies involving mobile devices are important too. Such > networks are quite capable of providing certain degrees of reliability > themselves, but that won't do any good once the battery is drained. For > these devices, "MUST setup 2 flows" can be too much. So we cannot (only) > have a scheme that requires that i don't remember anybody suggesting "MUST setup 2 flows", but "MUST be capable of setting at least 2 flows". the domain will then decide how many flows need to be set up (by that particular device if we adopts jonathan's discovery proposal). -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 07:04:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FztXR-0006Uv-Mm; Mon, 10 Jul 2006 07:02:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FztXQ-0006Up-I0 for sip@ietf.org; Mon, 10 Jul 2006 07:02:52 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FztXL-0007bE-WE for sip@ietf.org; Mon, 10 Jul 2006 07:02:52 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J2600I01P8HG9@siemenscomms.co.uk> for sip@ietf.org; Mon, 10 Jul 2006 12:00:18 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J2600I3KP8H7Z@siemenscomms.co.uk>; Mon, 10 Jul 2006 12:00:17 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Jul 2006 11:59:55 +0100 Content-return: allowed Date: Mon, 10 Jul 2006 11:59:47 +0100 From: "Elwell, John" Subject: RE: [Sip] Review of draft-ietf-sip-connected-identity-00 To: Eric Rescorla , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667095C29E2@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 1.1 (+) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric, Thanks for reading this draft. See my responses below. John > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: 04 July 2006 04:39 > To: sip@ietf.org > Subject: [Sip] Review of draft-ietf-sip-connected-identity-00 > > BACKGROUND > SIP allows "retargeting" in which the endpoints (on either end) of > a call can change. So, for instance, Alice might be calling Bob > but actually get forwarded to Charlie. This draft describes a > mechanism for the new endpoint to notify their peer that their > identity is not the same as the peer expected. > > > BASIC MESSAGE FLOW > The basic message flow without this draft looks something like this: > > Alice Proxy Carol > ----- ----- ----- > INVITE (To=Bob) -> > INVITE (To=Bob) -> > <- OK (To=Bob) > <- OK (To=Bob) > ACK (To=Bob) -> > ACK (To=Bob) -> > > > This draft adds a new set of messages for Carol to tell Alice about > the retargeting. Like this: > > > Alice Proxy Carol > ----- ----- ----- > INVITE (To=Bob) -> > INVITE (To=Bob) -> > <- OK (To=Bob) > <- OK (To=Bob) > ACK (To=Bob) -> > ACK (To=Bob) -> > > <- UPDATE (From=Carol) > <- UPDATE (From=Carol) > ACK (From=Carol) -> > ACK (From=Carol) -> > > > > > SECURITY ISSUES > This draft relies on the ordinary SIP authentication mechanisms > (primarily Identity, I would imagine) in order to validate the update > message. Unfortunately, this just tells the other side that they're > now talking to someone new securely. They have no way of determining > whether the retargeting was authorized or not. This is explicitly > acknowledged in the Security Considerations section. Clearly > something along these lines is needed. Perhaps it could > go in a different draft, but this does seem like the obvious one. [JRE] There has been a lot of discussion on this point in the past, and it is proving quite hard to come up with a solution for determining whether retargeting was authorised or not. Whilst there are some people still looking into this (e.g., draft-cao-sip-response-identity-00 and draft-cao-sip-response-auth-01), the SIP group felt that it would be appropriate to proceed with the connected-identity work, since this is well understood and easily achievable. This does not prevent continued investigations into authorised retargeting, but any mechanism to achieve that will be in a separate document. > > > EDITORIAL > 1. I found this document fairly hard to read until I figured > out what was > going on, perhaps due to my lack of familiarity with SIP. ISTM that a > diagram like the one above would be appropriate here--some diagram > definitely seems advisable. [JRE] We do have this in the examples section. > > 2. It would be helpful to have unique and distinctive terms for the > UA that isn't being retargeted (Alice above) and the one that is > (Bob/Carol). I found myself trying to figure that out. These > terms should be called out explicitly early on. [JRE] I get your point - the use of the terms UAC and UAS are not helpful, since roles are reversed when the UPDATE request is sent. I will think about it further when I work on the next draft after the meeting. > > > S 3. > You should explicitly state that To doesn't change during retargeting. > That is an unobvious behavior of SIP. [JRE] OK > > I think some diagrams of these scenarios would help. > > The following paragraph is a good example of what I mean above about > distinctive terms: > > However, call re-arrangements are not always carried out > using a new > INVITE request. Sometimes a B2BUA performs call re-arrangements > using third party call control (3PCC) techniques. With such > techniques the UA involved in the original call and still > involved in > the re-arranged call receives only a re-INVITE or UPDATE request in > the context of the original dialog between that UA and the B2BUA. > This forces the UA to re-negotiate the session with the new remote > party, but introduces a need to convey the identity of the > new remote > party to the UA. Because there is no new INVITE request > (outside the > context of the existing dialog), techniques applicable to new calls > do not apply. > > "the UA involved in the original call and still involved in > the re-arranged call" is too long to process as one chunk. [JRE] I will write instead: "For example, when call transfer is carried out by a B2BUA the transferred UA With such techniques the UA involved in the original call and still involved in the re-arranged call receives only a re-INVITE or UPDATE request in the context of the original dialog between that UA and the B2BUA." > > > S 4. > It should be made clear that this is background material that > will be used later. It's not an alternative to the current > approach, which I kind of got the impression from "Existing". [JRE] OK > > It would probably halp to name these mechanisms in some easy > to remember way. I'm sure they already have names.... [JRE] OK > > S 6.2. > Just for clarity, you don't need to send an UPDATE/re-INVITEif you > don't support id-change. So, the peers already need to be able to deal > with a non-UPDATE-sending situation, right? So, I'm not sure > I understandw hy you need to send the UPDATE/re-INVITE if nothing > has changed... [JRE] In order to an Authentication Service to insert an Identity header field, to provide authentication of the fact that nothing has changed. The source XML has this explanation, but due to an error in the XML tags it got dropped by xmlToRfc. > > 7.2. > There is a very bad break in this table. The headers need to be on > the same page as the columns. [JRE] I will investigate whether xmlToRfc allows me to correct this. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 07:56:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzuLE-0000Ya-UW; Mon, 10 Jul 2006 07:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzuLD-0000YV-Tv for sip@ietf.org; Mon, 10 Jul 2006 07:54:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzuLD-0000tw-RL for sip@ietf.org; Mon, 10 Jul 2006 07:54:19 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FzuLB-0007fv-GK for sip@ietf.org; Mon, 10 Jul 2006 07:54:19 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J2600801RO1A6@siemenscomms.co.uk> for sip@ietf.org; Mon, 10 Jul 2006 12:53:32 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J2600706RLEUL@siemenscomms.co.uk>; Mon, 10 Jul 2006 12:51:14 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Jul 2006 12:50:52 +0100 Content-return: allowed Date: Mon, 10 Jul 2006 12:50:44 +0100 From: "Elwell, John" Subject: RE: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt To: shida@ntt-at.com, Dan Wing Message-id: <50B1CBA96870A34799A506B2313F2667095C2AA8@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: -2.6 (--) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Shida, I don't think it would work with edge proxies. John > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: 10 July 2006 05:16 > To: Dan Wing > Cc: Elwell, John; sip@ietf.org > Subject: Re: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt > > > Hi; > > > Dan Wing wrote: > >> I generally like the draft, and I think the work is very important. > >> > > > > Me, too. > > > > > >> Anyhow, AFAIK there is no distinct way to request SIP-Identity to > >> AS, so just because one receives a sip-identity/id-change tag does > >> not necessary mean that sender of an UPDATE will be able to send > >> the sip-identity back(Even if the UAS supports > sip-identity/id-change, > >> the domain of the UAS might not have AS in place to provide > >> sip-identity). > >> > > > > Agreed; if we agree we need to optimize that case, we will need > > an additional option tag. But, still, there isn't a way for > > a UAS to "know" that his request will be protected with Identity. > > So I'm not sure of the value such an additional tag would bring > > over my suggestion. > > > In past, there has been RFC which proposed the use of > proxy-require for > the next hop only(First hop proxy removes the relevant > option-tag in the > proxy-require). RFC 3329 is one of the example for this, and proposal > similar to that may be considered. > > > >> This is because there is no option tag to require proxy to add > >> sip-identity, > >> and because sip-identity is generally performed at AS, UA > is generally > >> unaware of the domian's support for sip-identity. > >> > >> Furthermore, because its the AS that adds sip-identity(except when > >> UA has its own certificate which I think is unlikely), > just because UA > >> receives the sip-identity, does not necessary mean that UA sending > >> the original INVITE(offerer that you have described in > your comment) > >> with identity-info header supports sip-identity. > >> > > > > Even if the original UA itself doesn't support Identity, one of the > > domain's proxies added the Identity signature and it's likely that > > proxy may validate incoming requests containing Identity signatures. > > > > > Agree. > > Regards > Shida Schubert > > > -d > > > > > >> Last note, looking at the sentence in 6.1 which is shown > >> below, I am not sure if > >> mandating UA to send an UPDATE to update its identity is aligned > >> with the semantics of Supported header field. I don't really > >> have a strong > >> opinion on this point, but it felt a little funny to mandate > >> a behavior with > >> a presence of "Supported" header. > >> > >> Thanks & Regards > >> Shida > >> > >> Dan Wing wrote: > >> > >>> I hadn't noticed any followups to this issue. I have a > suggestion: > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>>> Sent: Tuesday, May 02, 2006 1:21 PM > >>>> To: sip@ietf.org > >>>> Subject: [Sip] Issue 2 in > draft-ietf-sip-connected-identity-00.txt > >>>> > >>>> The second issue concerns the fact that an UPDATE request in the > >>>> backward direction following dialog establishment can be > wasted if > >>>> the peer UA (the UAC for the INVITE transaction) does not support > >>>> it. It states: > >>>> > >>>> "OPEN ISSUE: If the identity has has not changed > >>>> > >> compared with > >> > >>>> the URI in the To header field and the UAC (for the INVITE > >>>> request) does not support verification of an > Identity header, > >>>> this UPDATE or re-INVITE transaction would fulfil no useful > >>>> purpose. However, the UAS (for the INVITE > transaction) does > >>>> not know this. In order to save this round trip, should we > >>>> have an additional option tag to indicate support > for receipt > >>>> of the Identity header on mid- dialog requests? > Then if this > >>>> option tag is not present in the INVITE request the > >>>> > >> additional > >> > >>>> transaction could be omitted. Note that the > id-change option > >>>> tag does not seem appropriate for this purpose, since a UA > >>>> could support a change of URI without supporting Identity." > >>>> > >>>> Whilst I do not wish to proliferate option tags, I do see some > >>>> benefit in such a tag. Any opinions? > >>>> > >>>> > >>> If an Invite arrives with both Identity and the id-change tag, > >>> it indicates the offerer understands both Identity and connected- > >>> identity, so the answerer should generate an request (UPDATE or > >>> re-INVITE). > >>> > >>> -d > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the > application of sip > >>> > >>> > >>> > >>> > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 09:15:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzvZk-0002kt-Lr; Mon, 10 Jul 2006 09:13:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzvZk-0002ko-35 for sip@ietf.org; Mon, 10 Jul 2006 09:13:24 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzvZi-0003mE-Tn for sip@ietf.org; Mon, 10 Jul 2006 09:13:24 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc11) with ESMTP id <20060710131322011009cq9me>; Mon, 10 Jul 2006 13:13:22 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k6ADDMN1008443 for ; Mon, 10 Jul 2006 09:13:22 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k6ADDLdu008439; Mon, 10 Jul 2006 09:13:21 -0400 Date: Mon, 10 Jul 2006 09:13:21 -0400 Message-Id: <200607101313.k6ADDLdu008439@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <5A349A8F-A2FC-4343-8A3E-BFA27267E130@softarmor.com> (dean.willis@softarmor.com) Subject: Re: [Sip] Ready for WGLC on Outbound? References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> <17579.25760.584180.394914@rautu.tutpro.com> <44AE14E2.6040700@softarmor.com> <17583.59900.171344.986622@rautu.tutpro.com> <5A349A8F-A2FC-4343-8A3E-BFA27267E130@softarmor.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Dean Willis Dale has noted in a separate thread that STUN breaks TCP framing, possibly creating a self-inflicted DoS attack that the UA cannot detect to recover from. Actually, Anders Kristensen raised the framing problem earlier, I was just echoing him in the later context. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 09:27:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzvld-0002hf-3H; Mon, 10 Jul 2006 09:25:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzvlb-0002hV-JV for sip@ietf.org; Mon, 10 Jul 2006 09:25:39 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzvlZ-000460-5h for sip@ietf.org; Mon, 10 Jul 2006 09:25:39 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 10 Jul 2006 06:25:37 -0700 X-IronPort-AV: i="4.06,225,1149490800"; d="scan'208"; a="304435340:sNHT33557804" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k6ADPa52013470; Mon, 10 Jul 2006 06:25:36 -0700 Received: from dwingwxp (sjc-vpn-hwcore-34.cisco.com [10.21.152.34]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6ADPZ46011912; Mon, 10 Jul 2006 06:25:35 -0700 (PDT) From: "Dan Wing" To: "'Elwell, John'" , Subject: RE: [Sip] Issue 2 in draft-ietf-sip-connected-identity-00.txt Date: Mon, 10 Jul 2006 09:25:30 -0400 Keywords: direct-to-dwing Message-ID: <023b01c6a424$53ebd460$ef52150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acajw7IuvCob+YdhS+a8bm0qjEHXkgAYAgGQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <50B1CBA96870A34799A506B2313F2667095641D0@ntht201e.siemenscomms.co.uk> DKIM-Signature: a=rsa-sha1; q=dns; l=4939; t=1152537936; x=1153401936; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[Sip]=20Issue=202=20in=20draft-ietf-sip-connected-identity-00.tx t; X=v=3Dcisco.com=3B=20h=3DZSIM5S5QfLQbqL0P0FGFNeY7QSc=3D; b=YSuNm74rgtrTO70cWGncbmWJ45mnw2ItVG/fhln42VpjlNXCejcL/1Hd2SeHXpUVpY8aGKIJ IRIk0uwXPAJ5OJ2lM7z0akU6vG5c4C2TJ06cERnu7n4UpoDR9Xgv851S; Authentication-Results: sj-dkim-6.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > That was not what I was trying to say. The UAC (for the > INVITE request) has no control over whether an Identity header > field is added by its domain proxy. So just because the UAS > receives an INVITE request with an Identity header field, does > not mean that the UAC put it there and would be interested in > receiving an UPDATE request with an Identity header field. > > However, I don't have a strong objection to the UAS (for the > INVITE) always sending back an UPDATE even if the From header > URI would be unchanged from that in the To header URI of > the INVITE request. Cool. We could define another Supported tag to optimize this slightly, (so the UAC indicates it desires connected-identity from the UAS) but we're still stuck with the problem that the UAS can't ensure its response will get an Identity header. I don't see another tag being that beneficial to that slight optimization. -d > Regards, > > John > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: 10 July 2006 02:12 > > To: Elwell, John; sip@ietf.org > > Subject: RE: [Sip] Issue 2 in > draft-ietf-sip-connected-identity-00.txt > > > > > I am not sure that would work. The problem is the UAC > > > typically does not insert the Identity header field in a > > > request, this is typically done by an authentication service > > > at the outbound proxy. So the fact that the request went > > > through an authentication service and had an Identity header > > > field added does not mean that the response will go through > > > a verification service. > > > > I agree there is nothing a UA can do to ensure its request > > gets an Identity header added. > > > > All I'm saying is that if you receive a request with an Identity > > headers, there is a pretty darn high likelyhood that the requestor > > is interested in having your response authenticated (by a backwards > > request using connected-identity). All you can do is send a request > > back to him and hope that your request will get an Identity header > > added by your authentication service. If it doesn't get an Identity > > header added, the requestor's local policy or implementation will > > decide what to do next: accept the call or drop it (because the > > connected-identity response lacks an Identity header). > > > > I argue that an additional tag wouldn't convey any additional > > meaning over my proposal. > > > > -d > > > > > However, I am open to opinions on that. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Dan Wing [mailto:dwing@cisco.com] > > > > Sent: 08 July 2006 02:21 > > > > To: Elwell, John; sip@ietf.org > > > > Subject: RE: [Sip] Issue 2 in > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > I hadn't noticed any followups to this issue. I have a > > suggestion: > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > > Sent: Tuesday, May 02, 2006 1:21 PM > > > > > To: sip@ietf.org > > > > > Subject: [Sip] Issue 2 in > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > The second issue concerns the fact that an UPDATE > request in the > > > > > backward direction following dialog establishment can > > be wasted if > > > > > the peer UA (the UAC for the INVITE transaction) does > > not support > > > > > it. It states: > > > > > > > > > > "OPEN ISSUE: If the identity has has not changed > > > compared with > > > > > the URI in the To header field and the UAC (for > the INVITE > > > > > request) does not support verification of an > > > Identity header, > > > > > this UPDATE or re-INVITE transaction would fulfil > > no useful > > > > > purpose. However, the UAS (for the INVITE > > transaction) does > > > > > not know this. In order to save this round trip, > > should we > > > > > have an additional option tag to indicate support > > > for receipt > > > > > of the Identity header on mid- dialog requests? > > > Then if this > > > > > option tag is not present in the INVITE request the > > > additional > > > > > transaction could be omitted. Note that the > > > id-change option > > > > > tag does not seem appropriate for this purpose, > since a UA > > > > > could support a change of URI without supporting > > Identity." > > > > > > > > > > Whilst I do not wish to proliferate option tags, I do see some > > > > > benefit in such a tag. Any opinions? > > > > > > > > If an Invite arrives with both Identity and the id-change tag, > > > > it indicates the offerer understands both Identity and > connected- > > > > identity, so the answerer should generate an request (UPDATE or > > > > re-INVITE). > > > > > > > > -d > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 09:57:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwF4-0008H6-BK; Mon, 10 Jul 2006 09:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwF2-0008GP-QB for sip@ietf.org; Mon, 10 Jul 2006 09:56:04 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzwEr-0007Pj-IQ for sip@ietf.org; Mon, 10 Jul 2006 09:55:54 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6ADtq3T027253 for ; Mon, 10 Jul 2006 08:55:52 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ9V68S>; Mon, 10 Jul 2006 14:55:52 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369D812@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Mon, 10 Jul 2006 14:55:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] Presentations for SIP session today X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A reminder that we expect (nay demand and insist) that we have all presentations mailed (and that means received not sent) by 12:30 pm today. We are still a considerable number outstanding. And earlier is better. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 10:00:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwHq-0001aX-Oh; Mon, 10 Jul 2006 09:58:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwHp-0001aS-O1 for sip@ietf.org; Mon, 10 Jul 2006 09:58:57 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzwHo-00009M-8e for sip@ietf.org; Mon, 10 Jul 2006 09:58:57 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6ADwjff025966; Mon, 10 Jul 2006 16:58:48 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 16:58:14 +0300 Received: from [10.162.24.153] ([10.162.24.153]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 Jul 2006 16:58:14 +0300 Message-ID: <44B25CED.2060302@nokia.com> Date: Mon, 10 Jul 2006 16:58:05 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com><44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <002c01c6a1ed$6e8726f0$31713b51@BEMBUSTER> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 13:58:14.0159 (UTC) FILETIME=[E30D61F0:01C6A428] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org, Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan Mahy wrote: > > > So we are back to a pure semantic question. Does the service get to > decide how many flows the UA opens (up to an implementation supported > maximum), does the UA decide how many flows to open, or is there some > negotiation? I still think the current semantics are fine, because > they allow a single flow to a URI that can still load-share and failover > to a large number of actual servers. Of course there are others who > don't like that because it relies on DNS for failover. > > thanks, > -rohan > I thought a bit more about this. I believe the service provider has no more say than providing the list of outbound URIs. The UA has to decide on how many flows to open, and what is the cost of this decision. I can imagine a policy in my laptop that makes the number of flows dependent on whether I am plug to the main or running on battery, so that if I am running on batteries I keep only one flow. My provider will never know what is my battery status: He can only set the maximum number of flows, but not the minimum. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 10:15:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwWM-0006Zy-L0; Mon, 10 Jul 2006 10:13:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwWL-0006Zk-6s for sip@ietf.org; Mon, 10 Jul 2006 10:13:57 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzwWI-0001Fn-SX for sip@ietf.org; Mon, 10 Jul 2006 10:13:57 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6AEDpd9017013; Mon, 10 Jul 2006 09:13:52 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ9V7Z2>; Mon, 10 Jul 2006 15:13:51 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369D81C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Scott Lawrence Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt Date: Mon, 10 Jul 2006 15:13:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: sip@ietf.org, ahawrylyshen@ditechnetworks.com, RjS@nostrum.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Getting back to the Warning issue: Inline below Keith > -----Original Message----- > From: Scott Lawrence [mailto:slawrence@pingtel.com] > Sent: 08 June 2006 19:04 > To: Drage, Keith (Keith) > Cc: sip@ietf.org; ahawrylyshen@ditechnetworks.com; RjS@nostrum.com > Subject: RE: [Sip] I-D > ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt > > > On Thu, 2006-06-08 at 18:29 +0100, Drage, Keith (Keith) wrote: > > > > 2) Section 2.2 and elsewhere, I am not convinced that the > > > use of the > > > > Warning header is consistent with RFC 3261. The clear > implication of > > > > RFC 3261 is that Warning headers relate only to the session > > > > description contained in the request. > > > > > > It didn't seem worth the trouble to define a new header, > or to require > > > some multipart body just to identify the last server - I'm open to > > > suggestions. It seems a valuable part of the diagnostic > information. > > > > > Well if we continue to use the Warning header, this would be another > > update of RFC 3261 to extend the usage of Warning, at least in my > > understanding, and that would need to be defined. > > RFC 3261, section 20.43 Warning says: > > The Warning header field is used to carry > additional information > about the status of a response. > and > The currently-defined "warn-code"s are listed below, with a > recommended warn-text in English and a description > of their meaning. > These warnings describe failures induced by the > session description. > The first digit of warning codes beginning with > "3" indicates > warnings specific to SIP. Warnings 300 through > 329 are reserved for > indicating problems with keywords in the session > description, 330 > through 339 are warnings related to basic network > services requested > in the session description, 370 through 379 are > warnings related to > quantitative QoS parameters requested in the > session description, and > 390 through 399 are miscellaneous warnings that do > not fall into one > of the above categories. > > it seems to me that this already explicitly allows for usages > other than > session description errors by allowing "miscellaneous warnings that do > not fall into one of the above categories". > > Arguably, this could call for actually registering a code in the 39x > range; if the WG thinks that's better, I can add an IANA > Considerations > section to do that. > The text you are quoting is I agree vague, but implies that 390 through 399 vcould be so used. However if continue on in the text of the section you are reading: Additional "warn-code"s can be defined through IANA, as defined in Section 27.2. and you go to the IANA registration section in 27.2: This specification establishes the Warn-codes sub-registry under http://www.iana.org/assignments/sip-parameters and initiates its population with the warn-codes listed in Section 20.43. Additional warn-codes are registered by RFC publication. Rosenberg, et. al. Standards Track [Page 252] RFC 3261 SIP: Session Initiation Protocol June 2002 The descriptive text for the table of warn-codes is: Warning codes provide information supplemental to the status code in SIP response messages when the failure of the transaction results from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. The "warn-code" consists of three digits. A first digit of "3" indicates warnings specific to SIP. Until a future specification describes uses of warn-codes other than 3xx, only 3xx warn-codes may be registered. Warnings 300 through 329 are reserved for indicating problems with keywords in the session description, 330 through 339 are warnings related to basic network services requested in the session description, 370 through 379 are warnings related to quantitative QoS parameters requested in the session description, and 390 through 399 are miscellaneous warnings that do not fall into one of the above categories. I believe this text is clear in requiring IANA to register codes that apply only to SDP errors. The text is reproduced on the IANA registry page concerned. Now whether we should change this or not I will leave open to discussion, but that is what it says at the moment. > > Out of interest, what harm would occur by adding it to the Server > > header? Alternatively, could the Contact header be allowed in a 483 > > response mean this? > > The Server header is defined as providing information about > the software > of the UAS, and as such the syntax doesn't allow for a field that is > identifiably the address or host name. > > I'm concerned that including a Contact is more likely to confuse > implementations that don't expect to see them in an error response > (especially since it is often going to be coming from a proxy). > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 10:33:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwnd-0003kk-OC; Mon, 10 Jul 2006 10:31:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwnc-0003ji-75 for sip@ietf.org; Mon, 10 Jul 2006 10:31:48 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzwna-00021l-TG for sip@ietf.org; Mon, 10 Jul 2006 10:31:48 -0400 Received: from hkaplan [132.219.11.211] by acmepacket.com with ESMTP (SMTPD-9.03) id A4D10444; Mon, 10 Jul 2006 10:31:45 -0400 From: "Hadriel Kaplan" To: "'Jeroen van Bemmel'" , Subject: RE: [Sip] STUN keep-alive: Client vs server generating requests Date: Mon, 10 Jul 2006 10:31:34 -0400 Message-ID: <008101c6a42d$8e5e8300$d30bdb84@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acajo3903vz6zaekSiywPdAUuGNN4AAiKv4A In-Reply-To: <00a101c6a3a3$7a0df690$31713b51@BEMBUSTER> X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > OK, I'll take your word for it. If we then interpret such a > 'stun-interval=xxx' as an indication of support for STUN (and say 'no STUN > unless interval is provided'), I'm happy > > Only trouble is: in many cases, the proxy would not know which type of NAT > there is in between, let alone how long it caches... If it doesn't know, then it sets the value recommended in the draft. However, there are ways for the proxy to find out, and there are also operators who know what the timeout is. (e.g., if the NAT is provided by them) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 10:45:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwyq-0002ts-Cs; Mon, 10 Jul 2006 10:43:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwyo-0002s8-Ny for sip@ietf.org; Mon, 10 Jul 2006 10:43:22 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzwyn-0002Sz-5q for sip@ietf.org; Mon, 10 Jul 2006 10:43:22 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Jul 2006 10:43:20 -0400 X-IronPort-AV: i="4.06,225,1149480000"; d="scan'208"; a="92184213:sNHT32298726" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6AEhKwV028525; Mon, 10 Jul 2006 10:43:20 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6AEhJ7t008482; Mon, 10 Jul 2006 10:43:19 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 10:43:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound and multiple connections Date: Mon, 10 Jul 2006 10:43:18 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301AC005B@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and multiple connections Thread-Index: Acai21H9sq6oNo3fRUSkE1rtWHWNlQBU0BcA From: "Michael Hammer \(mhammer\)" To: "Joel M. Halpern" , X-OriginalArrivalTime: 10 Jul 2006 14:43:19.0624 (UTC) FILETIME=[2FA29480:01C6A42F] DKIM-Signature: a=rsa-sha1; q=dns; l=3893; t=1152542600; x=1153406600; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Outbound=20and=20multiple=20connections |To:=22Joel=20M.=20Halpern=22=20,=20; X=v=3Dcisco.com=3B=20h=3DjmIRquQ86jU94jAzdDs6n3Lp9aw=3D; b=VmJ2sn1dttZ28bEafTLfBeniRh3b4QYhqnHtdo07KAMoNJWYubNTuFl6jyCJuHor8vU6R/AO BIReIk8V7eF8XDsy8u2Ng2GILQ249JZ0Pp1K+aQUKCgnSMwgmJ6Ohywj; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I wonder if the author is using an IMS orientation where the client attaches to different edge proxies, but the same registrar proxy, but that all gets conflated to talking about a "proxy". =20 In any case, good writing technique would suggest scanning a draft and replacing all instances of "it" with whatever "it" is. Saving a couple characters is a bad trade-off for the confusion that often ensues. Mike > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 > Sent: Saturday, July 08, 2006 6:10 PM > To: sip@ietf.org > Subject: [Sip] Outbound and multiple connections >=20 > I have been watching this ongoing discussion with some bemusement. > It appears that there are two very different views of the=20 > purpose for the multiple connections specified in=20 > draft-ietf-sip-outbound-04.txt. There also seems to be some=20 > discrepancies about where the multiple connections go. >=20 > With regard to purpose, the question I see is whether the=20 > reliability is for the clients benefit, or the networks. If=20 > it is for the client's benefit, then as has been suggested=20 > the client should be able to choose whether to take advantage=20 > of it or not. The multiple connections ought not be MUST=20 > strength. On the other hand, if it is a mechanism to enable=20 > the network to offer better service (particularly, better=20 > service to incoming requests) then the network would=20 > reasonably expect the multiple connections, and so the usage=20 > should be a MUST. > --Personally, I think that network techniques for providing=20 > reliability are the network's job / business, and so the=20 > multiple connections are about the clients desire for=20 > reliability, and ought to be SHOULD, or even MAY strength. >=20 > I believe that the above alternatives lead to confusion about=20 > the draft. Further, I think that there is related confusion=20 > about the usage of the multiple connections. >=20 > I note that the wording of the draft is very fuzzy as to=20 > whether the multiple connections are to the same server,=20 > multiple "closely coupled" servers, or distinct servers. I=20 > had assumed that the connections would be to distinct=20 > servers. However, re-reading the draft I see wording like=20 > (3.1) "it [proxy] can use any one of the flows on which a=20 > successful registration has been completed." For a proxy to=20 > have several flows would imply that the client connected to=20 > the same server multiple times. is in order. Wording in=20 > section 3.2 also talks about the proxy, which is the=20 > registrar, having multiple connections to the target. > I suspect that all the wording about a single registrar is to=20 > be interpreted in conjunction with the example case (3.3) of=20 > a single registrar that is actually two "closely coupled"=20 > hosts. This is a perfectly reasonable deployment. > However, I think we would be much better off describing this=20 > as if it were two registrars, and indicating that=20 > coordination among the registrars is outside of the scope of=20 > this draft. And we ought not require that they be closely coupled. > Whatever the actual intent of the authors of 3.1, 3.2, and=20 > 3.3, we need to decide what we want it to mean, and clarify=20 > the wording so that it says that, clearly. >=20 > Yours, > Joel M. Halpern >=20 > PS: I believe the reference in section 4.4 to "Section 4.2 to=20 > form a new flow" is actually a reference to 4.4.2? >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 10:55:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzx8V-0004vS-Tb; Mon, 10 Jul 2006 10:53:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzx8U-0004vN-5d for sip@ietf.org; Mon, 10 Jul 2006 10:53:22 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzx8S-0002yP-QK for sip@ietf.org; Mon, 10 Jul 2006 10:53:22 -0400 Received: by tutpro.com (Postfix, from userid 65534) id A2B991401BC; Mon, 10 Jul 2006 17:53:16 +0300 (EEST) Received: from rautu (allozyme53.gprs.dnafinland.fi [62.78.104.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 7CA3D13F6E1; Mon, 10 Jul 2006 17:53:00 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 5814EF03C1; Mon, 10 Jul 2006 17:53:05 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17586.27089.302552.734252@rautu.tutpro.com> Date: Mon, 10 Jul 2006 17:53:05 +0300 From: Juha Heinanen To: Miguel Garcia Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 In-Reply-To: <44B25CED.2060302@nokia.com> References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <002c01c6a1ed$6e8726f0$31713b51@BEMBUSTER> <44B25CED.2060302@nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Miguel Garcia writes: > The UA has to decide > on how many flows to open, and what is the cost of this decision. what if the cost is missing half of incoming calls? if that is not acceptable, then you exclude configuration where outbound proxies operate standalone. and once you do that, outbound does not provide ANY benefit over what we have today (reliability nor nat traversal). in fact, outbound would provides LESS than what we have today. in current implementations where proxies do nat keepalives, an intelligent nat can be build that does not actually send ANY keepalives to your battery operated UA, but still keep nat binding open. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 11:00:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxE7-0005cg-T2; Mon, 10 Jul 2006 10:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxE6-0005cb-Cv for sip@ietf.org; Mon, 10 Jul 2006 10:59:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzxE6-0003dH-B6 for sip@ietf.org; Mon, 10 Jul 2006 10:59:10 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FzxE2-0002eT-Uo for sip@ietf.org; Mon, 10 Jul 2006 10:59:10 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6ADx5Bw026570 for ; Mon, 10 Jul 2006 16:59:05 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:59:05 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:59:05 +0300 Received: from 10.241.58.185 ([10.241.58.185]) by esebe106.NOE.Nokia.com ([172.21.143.51]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Jul 2006 14:59:05 +0000 Received: from macbuster by ESEBE106.noe.nokia.com; 10 Jul 2006 10:59:04 -0400 From: Aki Niemi To: sip@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-NRC/Helsinki Date: Mon, 10 Jul 2006 10:59:02 -0400 Message-Id: <1152543543.13403.4.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-OriginalArrivalTime: 10 Jul 2006 14:59:05.0275 (UTC) FILETIME=[634978B0:01C6A431] X-Spam-Score: -2.6 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] Outbound comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The draft still says that in case of flow failure, the UA should retry registering every 900...1800 seconds *forever*. For an end user, even the first 30 minutes of waiting will seem like forever, so the UA should abort with an error much, much sooner than that. Why say forever in the draft then? What is the relationship between outbound, SIP identity and perhaps also identity-coexistance? Will outgoing requests reuse the outbound flow, is the edge proxy also the AS, and if so how will it determine the identity of the sender of the request? The draft could say a few words (and maybe add to the example) also about outgoing requests. About the default keepalive timers: the TCP timer is awfully short. A couple of minutes keepalive interval will make the battery life of any 2G or 3G mobile phone absolutely suck. What is the reason for such an aggressive interval, if even the worst NAT generally has binding lifetimes ten times that? Overall, the draft says in the introduction that this is about SIP traversing NAT better. However, the draft isn't only about that, but tries to solve some other n-nines reliability requirement as well. These could be separate drafts, really. -- Aki Niemi Nokia Research Center _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 11:00:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxEB-0005dK-MP; Mon, 10 Jul 2006 10:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxEA-0005dF-Vx for sip@ietf.org; Mon, 10 Jul 2006 10:59:14 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzxE9-0003dL-Mt for sip@ietf.org; Mon, 10 Jul 2006 10:59:14 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Jul 2006 10:59:14 -0400 X-IronPort-AV: i="4.06,225,1149480000"; d="scan'208"; a="92187448:sNHT31442988" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6AExDrG000694; Mon, 10 Jul 2006 10:59:13 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6AEx985013714; Mon, 10 Jul 2006 10:59:13 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 10:59:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Mon, 10 Jul 2006 10:59:11 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301AC0079@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Thread-Index: AcakKQEfN5T/5ULMSGuZySN2qZY1SQACDdog From: "Michael Hammer \(mhammer\)" To: "Miguel Garcia" , "Rohan Mahy" X-OriginalArrivalTime: 10 Jul 2006 14:59:12.0624 (UTC) FILETIME=[67AAD700:01C6A431] DKIM-Signature: a=rsa-sha1; q=dns; l=2092; t=1152543553; x=1153407553; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Re=3A=20A=20coment=20to=20draft-ietf-sip-outbound-04 |To:=22Miguel=20Garcia=22=20, =0A=20=20=20=20=20= 20=20=20=22Rohan=20Mahy=22=20; X=v=3Dcisco.com=3B=20h=3DT0Nc55Nkv0j8Iblrp5myBehinAo=3D; b=l4oatf2vweMRk3Pcs3OaoCKOdazHzieI/wLgu4AglZyVMvza6ILL4DLvayZWOAaf/E7Df+c7 MP/xjAiSNH5KnXtIC4pNtnkkI1SMmefE5pz45/ic2A5wfhPhh6cU2iKE; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org, "Cullen Jennings \(fluffy\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org And what is your approach to re-registration avalanches? Oh, wait that is not a handset problem. Mike =20 > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 > Sent: Monday, July 10, 2006 9:58 AM > To: Rohan Mahy > Cc: sip@ietf.org; Cullen Jennings (fluffy) > Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 >=20 > Rohan Mahy wrote: > >=20 > > > > So we are back to a pure semantic question. Does the=20 > service get to=20 > > decide how many flows the UA opens (up to an implementation=20 > supported=20 > > maximum), does the UA decide how many flows to open, or is=20 > there some > > negotiation? I still think the current semantics are=20 > fine, because=20 > > they allow a single flow to a URI that can still load-share and=20 > > failover to a large number of actual servers. Of course there are=20 > > others who don't like that because it relies on DNS for failover. > >=20 > > thanks, > > -rohan > >=20 >=20 > I thought a bit more about this. I believe the service=20 > provider has no more say than providing the list of outbound=20 > URIs. The UA has to decide on how many flows to open, and=20 > what is the cost of this decision. I can imagine a policy in=20 > my laptop that makes the number of flows dependent on whether=20 > I am plug to the main or running on battery, so that if I am=20 > running on batteries I keep only one flow. My provider will=20 > never know what is my battery status: He can only set the=20 > maximum number of flows, but not the minimum. >=20 > /Miguel >=20 > --=20 > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 11:00:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxE7-0005cg-T2; Mon, 10 Jul 2006 10:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxE6-0005cb-Cv for sip@ietf.org; Mon, 10 Jul 2006 10:59:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzxE6-0003dH-B6 for sip@ietf.org; Mon, 10 Jul 2006 10:59:10 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FzxE2-0002eT-Uo for sip@ietf.org; Mon, 10 Jul 2006 10:59:10 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6ADx5Bw026570 for ; Mon, 10 Jul 2006 16:59:05 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:59:05 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:59:05 +0300 Received: from 10.241.58.185 ([10.241.58.185]) by esebe106.NOE.Nokia.com ([172.21.143.51]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Jul 2006 14:59:05 +0000 Received: from macbuster by ESEBE106.noe.nokia.com; 10 Jul 2006 10:59:04 -0400 From: Aki Niemi To: sip@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Nokia-NRC/Helsinki Date: Mon, 10 Jul 2006 10:59:02 -0400 Message-Id: <1152543543.13403.4.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-OriginalArrivalTime: 10 Jul 2006 14:59:05.0275 (UTC) FILETIME=[634978B0:01C6A431] X-Spam-Score: -2.6 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] Outbound comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The draft still says that in case of flow failure, the UA should retry registering every 900...1800 seconds *forever*. For an end user, even the first 30 minutes of waiting will seem like forever, so the UA should abort with an error much, much sooner than that. Why say forever in the draft then? What is the relationship between outbound, SIP identity and perhaps also identity-coexistance? Will outgoing requests reuse the outbound flow, is the edge proxy also the AS, and if so how will it determine the identity of the sender of the request? The draft could say a few words (and maybe add to the example) also about outgoing requests. About the default keepalive timers: the TCP timer is awfully short. A couple of minutes keepalive interval will make the battery life of any 2G or 3G mobile phone absolutely suck. What is the reason for such an aggressive interval, if even the worst NAT generally has binding lifetimes ten times that? Overall, the draft says in the introduction that this is about SIP traversing NAT better. However, the draft isn't only about that, but tries to solve some other n-nines reliability requirement as well. These could be separate drafts, really. -- Aki Niemi Nokia Research Center _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 11:00:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxEB-0005dK-MP; Mon, 10 Jul 2006 10:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxEA-0005dF-Vx for sip@ietf.org; Mon, 10 Jul 2006 10:59:14 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzxE9-0003dL-Mt for sip@ietf.org; Mon, 10 Jul 2006 10:59:14 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Jul 2006 10:59:14 -0400 X-IronPort-AV: i="4.06,225,1149480000"; d="scan'208"; a="92187448:sNHT31442988" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6AExDrG000694; Mon, 10 Jul 2006 10:59:13 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6AEx985013714; Mon, 10 Jul 2006 10:59:13 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 10:59:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Mon, 10 Jul 2006 10:59:11 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301AC0079@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Thread-Index: AcakKQEfN5T/5ULMSGuZySN2qZY1SQACDdog From: "Michael Hammer \(mhammer\)" To: "Miguel Garcia" , "Rohan Mahy" X-OriginalArrivalTime: 10 Jul 2006 14:59:12.0624 (UTC) FILETIME=[67AAD700:01C6A431] DKIM-Signature: a=rsa-sha1; q=dns; l=2092; t=1152543553; x=1153407553; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Re=3A=20A=20coment=20to=20draft-ietf-sip-outbound-04 |To:=22Miguel=20Garcia=22=20, =0A=20=20=20=20=20= 20=20=20=22Rohan=20Mahy=22=20; X=v=3Dcisco.com=3B=20h=3DT0Nc55Nkv0j8Iblrp5myBehinAo=3D; b=l4oatf2vweMRk3Pcs3OaoCKOdazHzieI/wLgu4AglZyVMvza6ILL4DLvayZWOAaf/E7Df+c7 MP/xjAiSNH5KnXtIC4pNtnkkI1SMmefE5pz45/ic2A5wfhPhh6cU2iKE; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org, "Cullen Jennings \(fluffy\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org And what is your approach to re-registration avalanches? Oh, wait that is not a handset problem. Mike =20 > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 > Sent: Monday, July 10, 2006 9:58 AM > To: Rohan Mahy > Cc: sip@ietf.org; Cullen Jennings (fluffy) > Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 >=20 > Rohan Mahy wrote: > >=20 > > > > So we are back to a pure semantic question. Does the=20 > service get to=20 > > decide how many flows the UA opens (up to an implementation=20 > supported=20 > > maximum), does the UA decide how many flows to open, or is=20 > there some > > negotiation? I still think the current semantics are=20 > fine, because=20 > > they allow a single flow to a URI that can still load-share and=20 > > failover to a large number of actual servers. Of course there are=20 > > others who don't like that because it relies on DNS for failover. > >=20 > > thanks, > > -rohan > >=20 >=20 > I thought a bit more about this. I believe the service=20 > provider has no more say than providing the list of outbound=20 > URIs. The UA has to decide on how many flows to open, and=20 > what is the cost of this decision. I can imagine a policy in=20 > my laptop that makes the number of flows dependent on whether=20 > I am plug to the main or running on battery, so that if I am=20 > running on batteries I keep only one flow. My provider will=20 > never know what is my battery status: He can only set the=20 > maximum number of flows, but not the minimum. >=20 > /Miguel >=20 > --=20 > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 11:05:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxIa-0006b4-Qn; Mon, 10 Jul 2006 11:03:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxIZ-0006au-08 for sip@ietf.org; Mon, 10 Jul 2006 11:03:47 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzxIX-0003lu-LR for sip@ietf.org; Mon, 10 Jul 2006 11:03:46 -0400 Received: by tutpro.com (Postfix, from userid 65534) id CCA371401BE; Mon, 10 Jul 2006 18:03:41 +0300 (EEST) Received: from rautu (allozyme53.gprs.dnafinland.fi [62.78.104.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 54DCE1401BB; Mon, 10 Jul 2006 18:03:31 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 4D64EF03C1; Mon, 10 Jul 2006 18:03:42 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17586.27726.18986.629743@rautu.tutpro.com> Date: Mon, 10 Jul 2006 18:03:42 +0300 From: Juha Heinanen To: Aki Niemi Subject: [Sip] Outbound comments In-Reply-To: <1152543543.13403.4.camel@macbuster.research.nokia.com> References: <1152543543.13403.4.camel@macbuster.research.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki Niemi writes: > About the default keepalive timers: the TCP timer is awfully short. A > couple of minutes keepalive interval will make the battery life of any > 2G or 3G mobile phone absolutely suck. What is the reason for such an > aggressive interval, if even the worst NAT generally has binding > lifetimes ten times that? aki, uset yleisessa kaytossa olevan natit sidoksen hengissa luokkaa 30 sekunttia. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 11:06:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxJy-00072q-RW; Mon, 10 Jul 2006 11:05:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxJx-00072l-Bb for sip@ietf.org; Mon, 10 Jul 2006 11:05:13 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzxJu-0003q3-W4 for sip@ietf.org; Mon, 10 Jul 2006 11:05:13 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 10 Jul 2006 08:05:11 -0700 X-IronPort-AV: i="4.06,225,1149490800"; d="scan'208"; a="304472319:sNHT33454200" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k6AF5Agt028217; Mon, 10 Jul 2006 08:05:10 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6AF4ugB001429; Mon, 10 Jul 2006 08:05:09 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 11:05:01 -0400 Received: from [132.219.13.201] ([10.86.242.26]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 11:05:01 -0400 Message-ID: <44B26C9C.7020902@cisco.com> Date: Mon, 10 Jul 2006 11:05:00 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com><44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <002c01c6a1ed$6e8726f0$31713b51@BEMBUSTER> <44B25CED.2060302@nokia.com> In-Reply-To: <44B25CED.2060302@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 15:05:01.0158 (UTC) FILETIME=[3768E860:01C6A432] DKIM-Signature: a=rsa-sha1; q=dns; l=2221; t=1152543910; x=1153407910; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Re=3A=20A=20coment=20to=20draft-ietf-sip-outbound-04; X=v=3Dcisco.com=3B=20h=3Dmw3ZzSPBxV65n7c09ANJSezKJZE=3D; b=tCOFZ7zEDG17QRBMcKQFiMjhAvc1Dp7X8+P9HLiV9B8OyvJYCEFezvkC441JR9LZnWBk8mq6 Mz4lYCZnnOzQRt5kdQVD0BlRz7Bs1YVCygGw73WPC0wCo19kXRMbOQGh; Authentication-Results: sj-dkim-7.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Miguel Garcia wrote: > Rohan Mahy wrote: > >> >> >> So we are back to a pure semantic question. Does the service get to >> decide how many flows the UA opens (up to an implementation supported >> maximum), does the UA decide how many flows to open, or is there some >> negotiation? I still think the current semantics are fine, because >> they allow a single flow to a URI that can still load-share and >> failover to a large number of actual servers. Of course there are >> others who don't like that because it relies on DNS for failover. >> >> thanks, >> -rohan >> > > I thought a bit more about this. I believe the service provider has no > more say than providing the list of outbound URIs. No. I think the semantic is clear. If the provider offers N URI, then the semantic is, "I, the provider, want you to open N flows". > The UA has to decide > on how many flows to open, and what is the cost of this decision. I can > imagine a policy in my laptop that makes the number of flows dependent > on whether I am plug to the main or running on battery, so that if I am > running on batteries I keep only one flow. My provider will never know > what is my battery status: He can only set the maximum number of flows, > but not the minimum. I'm not entirely convinced that, once you're doing one flow with sip-outbound, that the incremental cost of an additional flow has a major impact on battery life. That said, I think this is starting to split hairs. The main point, I think, is that, under almost all conditions, if a client is offered N URI it opens N flows. Only for *exceptional* conditions would it open less. I would be OK with a strongly-qualified SHOULD. I.e., the spec would say SHOULD and then explain that its only under such extreme conditions that it would open fewer. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 11:12:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxPE-0007yh-G8; Mon, 10 Jul 2006 11:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxPD-0007yc-Iv for sip@ietf.org; Mon, 10 Jul 2006 11:10:39 -0400 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzxPB-00044A-Ca for sip@ietf.org; Mon, 10 Jul 2006 11:10:39 -0400 Received: by wr-out-0506.google.com with SMTP id i4so28483wra for ; Mon, 10 Jul 2006 08:10:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mOvs+WC80DLF4i7TpNcGfDA384NUqmZJAbsH/ZrlzHlzZlDmOTuA9O9GRMMHNabDk1os31YaQdF0lGcC53iDe9MP/ABv/9lCVRtqzJUwfJlmP0W+Qsj/1mhccKp+8Lu4VHHnMC+7FFUtYDWbtgM1oB/5qosWdiZJi7YdBZVyl7g= Received: by 10.65.213.14 with SMTP id p14mr4693894qbq; Mon, 10 Jul 2006 08:10:37 -0700 (PDT) Received: by 10.64.49.5 with HTTP; Mon, 10 Jul 2006 08:10:36 -0700 (PDT) Message-ID: Date: Mon, 10 Jul 2006 11:10:36 -0400 From: "Jason Fischl" To: "Cullen Jennings" Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <002401c693c8$aab13400$31713b51@BEMBUSTER> <4497EAE7.9090700@cisco.com> <44985514.4010107@cisco.com> <002f01c694ad$3c5479a0$31713b51@BEMBUSTER> <669459C0-169D-42AF-B59A-0F81AB5C2339@cisco.com> <002501c6995b$1c3002e0$31713b51@BEMBUSTER> X-Google-Sender-Auth: 30aefc28a27354f5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IETF SIP List , Paul H Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 6/30/06, Cullen Jennings wrote: > > On Jun 26, 2006, at 1:00 PM, Jeroen van Bemmel wrote: > > > On the using a GRUU in a cert, would need to consider that any time > my GRUU changes I need to generate a new cert - if this meant a new > private/public key pair, this might be expensive. > Also consider that GRUUs will change relatively frequently for devices. Can I get a sense on the list of who thinks storing the GRUU instead of the AOR in the cert is worth additional consideration in the context of this document? I would suggest leaving this out of scope for now. Jason _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 11:13:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxQX-0008Lw-WF; Mon, 10 Jul 2006 11:12:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxQW-0008Lr-Di for sip@ietf.org; Mon, 10 Jul 2006 11:12:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzxQV-00048S-5M for sip@ietf.org; Mon, 10 Jul 2006 11:12:00 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Jul 2006 11:11:59 -0400 X-IronPort-AV: i="4.06,225,1149480000"; d="scan'208"; a="92190251:sNHT30465840" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6AFBwpj008131; Mon, 10 Jul 2006 11:11:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6AFBw7t018540; Mon, 10 Jul 2006 11:11:58 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 11:11:58 -0400 Received: from [132.219.13.201] ([10.86.242.26]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 11:11:58 -0400 Message-ID: <44B26E3A.8000408@cisco.com> Date: Mon, 10 Jul 2006 11:11:54 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erkki.Koivusalo@nokia.com Subject: Re: [Sip] Ready for WGLC on Outbound? References: <8B1D53AEF7B03449A6D3771B3B7F850F0280E401@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0280E401@esebe103.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 15:11:58.0345 (UTC) FILETIME=[30129790:01C6A433] DKIM-Signature: a=rsa-sha1; q=dns; l=1212; t=1152544319; x=1153408319; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Ready=20for=20WGLC=20on=20Outbound? |To:Erkki.Koivusalo@nokia.com; X=v=3Dcisco.com=3B=20h=3D+vIhPlqdG6kJmZ9oKSrzl3HpLHY=3D; b=f9E81pfuvhhBFtYgYgpvTCQiyZu3PjAWU9j5LjTlDCkj6iI9O9Ap6gu80/Tfhhqe/59+bmLc zPwT+9Bsee3/ukv0cSCylksZ2+IHY/fGihNXworPbg7SzJOvtZxtLc3T; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Erkki.Koivusalo@nokia.com wrote: > Another reason is embedded into this statement from Jonathan: > > >>(3) constructed URIs. >> >>On (3), this is definitely a possibility. However I think the best way > > >>to mitigate is to say 'don't do that'. SIP-outbound can have some > > words > >>which warn implementations that they MUST NOT insert this parameter > > into > >>URI that they construct from a domain name. > > > This suggestion seems to prevent the UA to use DHCP to discover > and use a local SIP proxy even if such an outbound compliant > proxy would exist. This does not sound a good idea to me. Not in my discovery proposal at least. A UA would construct the outbound proxy URI from DHCP without the flag. REGISTER is sent through it. Resulting service-route URI has the flag. Now keepalives get used. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 11:23:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxZS-0003uo-65; Mon, 10 Jul 2006 11:21:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxZQ-0003pD-Ap for sip@ietf.org; Mon, 10 Jul 2006 11:21:12 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzxZO-0004eY-WD for sip@ietf.org; Mon, 10 Jul 2006 11:21:12 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 10 Jul 2006 08:21:11 -0700 X-IronPort-AV: i="4.06,225,1149490800"; d="scan'208"; a="304478959:sNHT65399040" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k6AFLA3k019204; Mon, 10 Jul 2006 08:21:10 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6AFL948027739; Mon, 10 Jul 2006 08:21:10 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 11:21:09 -0400 Received: from [132.219.13.201] ([10.86.242.26]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 11:21:09 -0400 Message-ID: <44B27064.4070105@cisco.com> Date: Mon, 10 Jul 2006 11:21:08 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] an alternative approach for outbound proxy discovery References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 15:21:09.0658 (UTC) FILETIME=[78AE47A0:01C6A434] DKIM-Signature: a=rsa-sha1; q=dns; l=1770; t=1152544870; x=1153408870; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20an=20alternative=20approach=20for=20outbound=20proxy=20d iscovery; X=v=3Dcisco.com=3B=20h=3Dm0N0gjXk6ts9SF37Zoo9gY3Ztrw=3D; b=UftTKSUJJt1O62mWOMQx845EdWGGJelv1YYDvQ37J98LMIimO3v8D+098A8vgeyjWRa4Bi/x LKmpiNWFjsh1LLdxcG2kyKQaXF/eLMvQIOuKovQqUQef0wEN9sJlv+ml; Authentication-Results: sj-dkim-8.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for reading. Responses below. Christer Holmberg wrote: > Hi Jonathan, > > There are a couple of issues/deployment restrictions with your > proposal. > > 1. The home proxy has, as you indicate, to know that an edge proxy is > needed. If the edge proxy is used only for STUN keepalive that may be > difficult, because the home proxy would need to know when keepalive > is needed in the first place. Or, of course it could force all > registrations to go via the edge proxy. You lost me on this one. The idea is that, within a particular service provider network, the home proxy knows whether the user should be using an edge proxy from that provider. > > 2. The home proxy and the edge proxy may be in different > administrative domains, so the home proxy may not know the address of > the edge proxy (maybe not even in which domain it's located). Right. This is a good point. In this particular case, I think you would discover the edge proxy through DHCP rather from the AOR. Then, the procedure works as I described, with Service-Route providing a URI with the keepalive=stun and the Additional-Proxies header with more proxies. > > 3. The request may traverse a numbet of proxies in any case, so the > home proxy would have to know whether one of those is the edge proxy > or not. If the request arrives to the home proxy from a different proxy, it wouldn't redirect. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 11:26:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxdA-0005DD-3J; Mon, 10 Jul 2006 11:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzxd9-0005D8-Kv for sip@ietf.org; Mon, 10 Jul 2006 11:25:03 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzxd8-0004nx-8B for sip@ietf.org; Mon, 10 Jul 2006 11:25:03 -0400 Received: from hkaplan [132.219.11.211] by acmepacket.com with ESMTP (SMTPD-9.03) id A144018C; Mon, 10 Jul 2006 11:24:52 -0400 From: "Hadriel Kaplan" To: "'Michael Hammer \(mhammer\)'" , "'Miguel Garcia'" , "'Rohan Mahy'" Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Mon, 10 Jul 2006 11:24:45 -0400 Message-ID: <00bb01c6a434$f9f3ffd0$d30bdb84@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcakKQEfN5T/5ULMSGuZySN2qZY1SQACDdogAAAub2A= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301AC0079@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: sip@ietf.org, "'Cullen Jennings \(fluffy\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't put that much value in using multiple concurrent flows for avalanche avoidance. There are already ways proxies handle this, though they're mostly about smoothing out registration rates over time. And the UAs will already be doing some smoothing on their own as they detect the failure at different times (over a 2 min period?). The worst-case avalanche is probably right after a power outage, and that's not covered by multiple flows. So your proxies need to be able to handle it. -hadriel > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, July 10, 2006 10:59 AM > To: Miguel Garcia; Rohan Mahy > Cc: sip@ietf.org; Cullen Jennings (fluffy) > Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 > > And what is your approach to re-registration avalanches? > > Oh, wait that is not a handset problem. > > Mike > > > > -----Original Message----- > > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > > Sent: Monday, July 10, 2006 9:58 AM > > To: Rohan Mahy > > Cc: sip@ietf.org; Cullen Jennings (fluffy) > > Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 > > > > Rohan Mahy wrote: > > > > > > > > > So we are back to a pure semantic question. Does the > > service get to > > > decide how many flows the UA opens (up to an implementation > > supported > > > maximum), does the UA decide how many flows to open, or is > > there some > > > negotiation? I still think the current semantics are > > fine, because > > > they allow a single flow to a URI that can still load-share and > > > failover to a large number of actual servers. Of course there are > > > others who don't like that because it relies on DNS for failover. > > > > > > thanks, > > > -rohan > > > > > > > I thought a bit more about this. I believe the service > > provider has no more say than providing the list of outbound > > URIs. The UA has to decide on how many flows to open, and > > what is the cost of this decision. I can imagine a policy in > > my laptop that makes the number of flows dependent on whether > > I am plug to the main or running on battery, so that if I am > > running on batteries I keep only one flow. My provider will > > never know what is my battery status: He can only set the > > maximum number of flows, but not the minimum. > > > > /Miguel > > > > -- > > Miguel A. Garcia tel:+358-50-4804586 > > sip:miguel.an.garcia@openlaboratory.net > > Nokia Research Center Helsinki, Finland > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 11:39:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzxow-0006S8-0o; Mon, 10 Jul 2006 11:37:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzxou-0006Rj-9b for sip@ietf.org; Mon, 10 Jul 2006 11:37:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzxou-0005tB-83 for sip@ietf.org; Mon, 10 Jul 2006 11:37:12 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FzxnA-0003GI-Uv for sip@ietf.org; Mon, 10 Jul 2006 11:35:26 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 10 Jul 2006 08:35:23 -0700 X-IronPort-AV: i="4.06,225,1149490800"; d="scan'208"; a="1836921894:sNHT31168370" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k6AFZNZ1026565; Mon, 10 Jul 2006 08:35:23 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6AFZNsT004002; Mon, 10 Jul 2006 08:35:23 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn6-668.cisco.com [10.21.122.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k6AFTXea009889; Mon, 10 Jul 2006 08:29:34 -0700 Message-ID: <44B273BA.9010409@cisco.com> Date: Mon, 10 Jul 2006 08:35:22 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Fischl Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates References: <002401c693c8$aab13400$31713b51@BEMBUSTER> <4497EAE7.9090700@cisco.com> <44985514.4010107@cisco.com> <002f01c694ad$3c5479a0$31713b51@BEMBUSTER> <669459C0-169D-42AF-B59A-0F81AB5C2339@cisco.com> <002501c6995b$1c3002e0$31713b51@BEMBUSTER> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1006; t=1152545723; x=1153409723; c=relaxed/simple; s=sjdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-certs-00, =09communicating=20private=20key s=20and=0A=20self-signed=20certificates; X=v=3Dcisco.com=3B=20h=3DtOkffTLqRd6xPtl3JUjWoP2yWPY=3D; b=IBy7Q4DaPmEXh4JHLMTU9fkNTFXRwBdhcVxV+XJESr25fQs/+ZqpHVEStjACKcNss9wULoGW wEsuGCcJLpJbCU8SHmszSo7Sv+r4TxW6Hk5EXMSklrsGntNk6dcDk1IT; X-Spam-Score: -2.6 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Cullen Jennings , IETF SIP List , Paul H Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jason Fischl wrote: > On 6/30/06, Cullen Jennings wrote: > >> >> On Jun 26, 2006, at 1:00 PM, Jeroen van Bemmel wrote: >> >> >> On the using a GRUU in a cert, would need to consider that any time >> my GRUU changes I need to generate a new cert - if this meant a new >> private/public key pair, this might be expensive. > Just piggybacking on this comment. First, try doing an openssl genrsa -- it doesn't take very long to create a new key pair for all but really large keys. Second, I don't understand why one would need to create new keys for new identities. A certificate is nothing more than a name/key binding at its heart. There's nothing in the certificate that can sniff out whether the key is fresh or stale, and in the abstract there's nothing wrong with having a single key signing for a variety of different identities (*). Mike [*] context matters here, of course, but my guess is that for the average UA it matters very little. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 11:45:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzxus-0007Sb-Tx; Mon, 10 Jul 2006 11:43:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzxuq-0007SA-Oy for sip@ietf.org; Mon, 10 Jul 2006 11:43:20 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzxup-0006HQ-6z for sip@ietf.org; Mon, 10 Jul 2006 11:43:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Jul 2006 08:43:11 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,225,1149490800"; d="scan'208"; a="31656480:sNHT29075768" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6AFhBea023073; Mon, 10 Jul 2006 11:43:11 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6AFhBdU004660; Mon, 10 Jul 2006 11:43:11 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 11:43:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Mon, 10 Jul 2006 11:43:09 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301AC00E9@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Thread-Index: AcakKQEfN5T/5ULMSGuZySN2qZY1SQACDdogAAAub2AAARAe8A== From: "Michael Hammer \(mhammer\)" To: "Hadriel Kaplan" , "Miguel Garcia" , "Rohan Mahy" X-OriginalArrivalTime: 10 Jul 2006 15:43:10.0952 (UTC) FILETIME=[8C3BBE80:01C6A437] DKIM-Signature: a=rsa-sha1; q=dns; l=4619; t=1152546191; x=1153410191; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Re=3A=20A=20coment=20to=20draft-ietf-sip-outbound-04 |To:=22Hadriel=20Kaplan=22=20, =0A=20=20=20=20=20=20= 20=20=22Miguel=20Garcia=22=20, =0A=20=20=20=20=2 0=20=20=20=22Rohan=20Mahy=22=20; X=v=3Dcisco.com=3B=20h=3DT0Nc55Nkv0j8Iblrp5myBehinAo=3D; b=fBpPrZCY8dNA0TT/+v1bpmsY1uUV3qjd/tB03rEiR0xito9drJ4YqbJw0uDSaksSo51NCQml 6+UNq8I8346VnTYvPxbb/f1G0/APD8cFiODB4M16Fdg0zP5xVGO3VHEw; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: sip@ietf.org, "Cullen Jennings \(fluffy\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That 2-minute period could be smoothed out over a much longer period of time if there were multiple flows. Your power outage example assumes a specific topology relative to where power was lost. I disagree with assuming a poor network design as argument for multiple flows not handling the outage. I do agree that proxies need to handle such overloads, but that leads right back to the service being out for longer than the acceptable (?) 2 minute period. I am not adverse to wireless networks choosing to make the tradeoff of battery time to increased possibility of missing incoming calls, I just think that there needs to be agreement between the network and client as to what is acceptable and what those tradeoffs are, such that neither has negative impacts. Mike > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Monday, July 10, 2006 11:25 AM > To: Michael Hammer (mhammer); 'Miguel Garcia'; 'Rohan Mahy' > Cc: sip@ietf.org; Cullen Jennings (fluffy) > Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 >=20 > I don't put that much value in using multiple concurrent=20 > flows for avalanche avoidance. There are already ways=20 > proxies handle this, though they're mostly about smoothing=20 > out registration rates over time. And the UAs will already=20 > be doing some smoothing on their own as they detect the=20 > failure at different times (over a 2 min period?). The=20 > worst-case avalanche is probably right after a power outage,=20 > and that's not covered by multiple flows. So your proxies=20 > need to be able to handle it. >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Monday, July 10, 2006 10:59 AM > > To: Miguel Garcia; Rohan Mahy > > Cc: sip@ietf.org; Cullen Jennings (fluffy) > > Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 > >=20 > > And what is your approach to re-registration avalanches? > >=20 > > Oh, wait that is not a handset problem. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > > > Sent: Monday, July 10, 2006 9:58 AM > > > To: Rohan Mahy > > > Cc: sip@ietf.org; Cullen Jennings (fluffy) > > > Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 > > > > > > Rohan Mahy wrote: > > > > > > > > > > > > So we are back to a pure semantic question. Does the > > > service get to > > > > decide how many flows the UA opens (up to an implementation > > > supported > > > > maximum), does the UA decide how many flows to open, or is > > > there some > > > > negotiation? I still think the current semantics are > > > fine, because > > > > they allow a single flow to a URI that can still load-share and=20 > > > > failover to a large number of actual servers. Of=20 > course there are=20 > > > > others who don't like that because it relies on DNS for=20 > failover. > > > > > > > > thanks, > > > > -rohan > > > > > > > > > > I thought a bit more about this. I believe the service=20 > provider has=20 > > > no more say than providing the list of outbound URIs. The=20 > UA has to=20 > > > decide on how many flows to open, and what is the cost of this=20 > > > decision. I can imagine a policy in my laptop that makes=20 > the number=20 > > > of flows dependent on whether I am plug to the main or running on=20 > > > battery, so that if I am running on batteries I keep only=20 > one flow.=20 > > > My provider will never know what is my battery status: He=20 > can only=20 > > > set the maximum number of flows, but not the minimum. > > > > > > /Miguel > > > > > > -- > > > Miguel A. Garcia tel:+358-50-4804586 > > > sip:miguel.an.garcia@openlaboratory.net > > > Nokia Research Center Helsinki, Finland > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > > > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 12:15:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzyOA-0005UK-Sc; Mon, 10 Jul 2006 12:13:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzyO8-0005UA-T5 for sip@ietf.org; Mon, 10 Jul 2006 12:13:36 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzyO7-0001Ex-Dq for sip@ietf.org; Mon, 10 Jul 2006 12:13:36 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6AFDJeW017503; Mon, 10 Jul 2006 18:13:20 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 19:13:19 +0300 Received: from [10.162.24.153] ([10.162.24.153]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 Jul 2006 19:13:19 +0300 Message-ID: <44B27C9D.8070101@nokia.com> Date: Mon, 10 Jul 2006 19:13:17 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <002c01c6a1ed$6e8726f0$31713b51@BEMBUSTER> <44B25CED.2060302@nokia.com> <17586.27089.302552.734252@rautu.tutpro.com> In-Reply-To: <17586.27089.302552.734252@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 16:13:19.0203 (UTC) FILETIME=[C208F330:01C6A43B] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Miguel Garcia writes: > > > The UA has to decide > > on how many flows to open, and what is the cost of this decision. > > what if the cost is missing half of incoming calls? if that is not > acceptable, then you exclude configuration where outbound proxies > operate standalone. and once you do that, outbound does not provide ANY > benefit over what we have today (reliability nor nat traversal). If the user does not want to miss any calls, he can install a policy that uses several flows. The draft allows you to do it. What the draft does not allow me to do is to install a policy where I use only one flow. > > in fact, outbound would provides LESS than what we have today. in > current implementations where proxies do nat keepalives, an intelligent > nat can be build that does not actually send ANY keepalives to your > battery operated UA, but still keep nat binding open. True, in that case you probably don't need STUN or SIP outbound, so no need to discuss it either. The same applies if you can get a non-private IP address to your UA. We don't discuss the lack of need of the outbound draft in those cases. /Miguel > > -- juha -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 12:19:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzySS-0006HQ-TJ; Mon, 10 Jul 2006 12:18:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzySR-0006HB-Co for sip@ietf.org; Mon, 10 Jul 2006 12:18:03 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzySP-0001a5-VG for sip@ietf.org; Mon, 10 Jul 2006 12:18:03 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6AGHrs4009409; Mon, 10 Jul 2006 19:17:54 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 19:17:53 +0300 Received: from [10.162.24.153] ([10.162.24.153]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 Jul 2006 19:17:53 +0300 Message-ID: <44B27DAF.2040306@nokia.com> Date: Mon, 10 Jul 2006 19:17:51 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com><44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <002c01c6a1ed$6e8726f0$31713b51@BEMBUSTER> <44B25CED.2060302@nokia.com> <44B26C9C.7020902@cisco.com> In-Reply-To: <44B26C9C.7020902@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 16:17:53.0401 (UTC) FILETIME=[65783E90:01C6A43C] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > inline. > > I'm not entirely convinced that, once you're doing one flow with > sip-outbound, that the incremental cost of an additional flow has a > major impact on battery life. It does, not because of the flow itself, but because of the keepalives every 30 seconds. > That said, I think this is starting to split hairs. The main point, I > think, is that, under almost all conditions, if a client is offered N > URI it opens N flows. Only for *exceptional* conditions would it open > less. I would be OK with a strongly-qualified SHOULD. I.e., the spec > would say SHOULD and then explain that its only under such extreme > conditions that it would open fewer. I am fine with this proposal. And I wouldn't mine to add some paragraph describing the conditions under which the UA would establish the N flows. /Miguel > Thanks, > Jonathan R. -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 13:22:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzQn-0006kp-La; Mon, 10 Jul 2006 13:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzQm-0006kT-7x for sip@ietf.org; Mon, 10 Jul 2006 13:20:24 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzzQj-0005Hq-Q1 for sip@ietf.org; Mon, 10 Jul 2006 13:20:24 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 44C698D8 for ; Mon, 10 Jul 2006 19:20:21 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 19:20:20 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 19:20:19 +0200 Received: from [131.160.126.8] (rvi2-126-8.lmf.ericsson.se [131.160.126.8]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4CC9F295B for ; Mon, 10 Jul 2006 20:20:19 +0300 (EEST) Message-ID: <44B28C50.8030109@ericsson.com> Date: Mon, 10 Jul 2006 20:20:16 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 17:20:19.0974 (UTC) FILETIME=[1E99EA60:01C6A445] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] Issue related to SIP and Sigcomp X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks, per my presentation a minute ago in SIP, if you are interested in meeting at some point during the following days to work on the issue I presented, which relates to SigComp and SIP, please send me an email. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 13:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzVG-0007h0-Lw; Mon, 10 Jul 2006 13:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzVF-0007gj-Jf for sip@ietf.org; Mon, 10 Jul 2006 13:25:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzzVC-0005nY-9x for sip@ietf.org; Mon, 10 Jul 2006 13:25:01 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Jul 2006 13:24:58 -0400 X-IronPort-AV: i="4.06,225,1149480000"; d="scan'208"; a="92211503:sNHT31201776" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6AHOvcW000980; Mon, 10 Jul 2006 13:24:57 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6AHOv7t027657; Mon, 10 Jul 2006 13:24:57 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 13:24:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Mon, 10 Jul 2006 13:24:56 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301AC0171@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Thread-Index: AcakPHbc1TmZcDKbR7SjwBZ76O5WtgACRz+w From: "Michael Hammer \(mhammer\)" To: "Miguel Garcia" , "Jonathan Rosenberg \(jdrosen\)" X-OriginalArrivalTime: 10 Jul 2006 17:24:57.0527 (UTC) FILETIME=[C4092470:01C6A445] DKIM-Signature: a=rsa-sha1; q=dns; l=2008; t=1152552297; x=1153416297; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Re=3A=20A=20coment=20to=20draft-ietf-sip-outbound-04 |To:=22Miguel=20Garcia=22=20, =0A=20=20=20=20=20= 20=20=20=22Jonathan=20Rosenberg=20\(jdrosen\)=22=20; X=v=3Dcisco.com=3B=20h=3DT0Nc55Nkv0j8Iblrp5myBehinAo=3D; b=Shb+FDTXnVubpI3STzlO5KhADFkxwmLwvSh5MW+hswvysfpEHNEdBD5wjI1YoSl5qqAOAWUf kK5Kn7wGcV29gCLNR+y98GfoRnQ4PVCW1e/z++8HxvDMKRCrQhoIGjnY; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org, Rohan Mahy , "Cullen Jennings \(fluffy\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So, could one infer from your statement, that if a network uses multiple flows, but not keepalives, because it knows there are no NATs, then that would be an acceptable configuration? Mike > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 > Sent: Monday, July 10, 2006 12:18 PM > To: Jonathan Rosenberg (jdrosen) > Cc: sip@ietf.org; Rohan Mahy; Cullen Jennings (fluffy) > Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 >=20 > Jonathan Rosenberg wrote: > > inline. > >=20 > > I'm not entirely convinced that, once you're doing one flow with=20 > > sip-outbound, that the incremental cost of an additional flow has a=20 > > major impact on battery life. >=20 > It does, not because of the flow itself, but because of the=20 > keepalives every 30 seconds. >=20 >=20 > > That said, I think this is starting to split hairs. The=20 > main point, I=20 > > think, is that, under almost all conditions, if a client is=20 > offered N=20 > > URI it opens N flows. Only for *exceptional* conditions=20 > would it open=20 > > less. I would be OK with a strongly-qualified SHOULD. I.e.,=20 > the spec=20 > > would say SHOULD and then explain that its only under such extreme=20 > > conditions that it would open fewer. >=20 > I am fine with this proposal. And I wouldn't mine to add some=20 > paragraph=20 > describing the conditions under which the UA would establish=20 > the N flows. >=20 > /Miguel >=20 > > Thanks, > > Jonathan R. >=20 > --=20 > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 13:33:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzbT-0008Vx-G0; Mon, 10 Jul 2006 13:31:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzbR-0008Vs-WA for sip@ietf.org; Mon, 10 Jul 2006 13:31:25 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzzbQ-0006Gz-Ip for sip@ietf.org; Mon, 10 Jul 2006 13:31:25 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6AHVFll021639; Mon, 10 Jul 2006 20:31:17 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 20:30:39 +0300 Received: from [10.162.24.153] ([10.162.24.153]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 Jul 2006 20:30:38 +0300 Message-ID: <44B28EBA.5010504@nokia.com> Date: Mon, 10 Jul 2006 20:30:34 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "ext Michael Hammer (mhammer)" Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 References: <072C5B76F7CEAB488172C6F64B30B5E301AC0171@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301AC0171@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 17:30:38.0514 (UTC) FILETIME=[8F47A120:01C6A446] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org, Rohan Mahy , "Cullen Jennings \(fluffy\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Michael Hammer (mhammer) wrote: > So, could one infer from your statement, that if a network uses multiple > flows, but not keepalives, because it knows there are no NATs, then that > would be an acceptable configuration? > Yes, although I am not sure the benefit outbound will give you in this case, but it would be fine. /Miguel > Mike > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 14:25:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00Q5-0001VX-LH; Mon, 10 Jul 2006 14:23:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00Q4-0001VS-Jk for sip@ietf.org; Mon, 10 Jul 2006 14:23:44 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G00Q3-0004rW-B6 for sip@ietf.org; Mon, 10 Jul 2006 14:23:44 -0400 Received: from hkaplan [132.219.11.211] by acmepacket.com with ESMTP (SMTPD-9.03) id AB280164; Mon, 10 Jul 2006 14:23:36 -0400 From: "Hadriel Kaplan" To: "'Michael Hammer \(mhammer\)'" Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Mon, 10 Jul 2006 14:23:28 -0400 Message-ID: <00e601c6a44d$f2c19dd0$d30bdb84@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcakKQEfN5T/5ULMSGuZySN2qZY1SQACDdogAAAub2AAARAe8AADOU7g In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301AC00E9@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My point was just that it's not a panacea for the avalanche issue. It helps in various failure modes, doesn't in others. The power outage was just an extreme failure mode example; there are others. I know everyone's mileage varies, but 2 Minutes lets a heck of a lot of UAs register, from what I've seen of registrar reg/sec load handling. Like at least in the thousands. If more than thousands of UAs are registering anew, the odds are it was either because they've all rebooted due to regional power loss, or their primary proxy died/lost-comms. In the former case multiple flows would not help. In the latter case outbound would have all the UAs connecting to a backup for that failed primary in 90 seconds (ie, they use the secondary proxy, but then create a replacement for the failed flow). So the avalanche is still there, just for another proxy, no? -hadriel > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, July 10, 2006 11:43 AM > To: Hadriel Kaplan; Miguel Garcia; Rohan Mahy > Cc: sip@ietf.org; Cullen Jennings (fluffy) > Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 > > That 2-minute period could be smoothed out over a much longer period of > time if there were multiple flows. > > Your power outage example assumes a specific topology relative to where > power was lost. I disagree with assuming a poor network design as > argument for multiple flows not handling the outage. > > I do agree that proxies need to handle such overloads, but that leads > right back to the service being out for longer than the acceptable (?) 2 > minute period. > > I am not adverse to wireless networks choosing to make the tradeoff of > battery time to increased possibility of missing incoming calls, I just > think that there needs to be agreement between the network and client as > to what is acceptable and what those tradeoffs are, such that neither > has negative impacts. > > Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 14:43:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00hM-00082D-EB; Mon, 10 Jul 2006 14:41:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00hK-000828-W1 for sip@ietf.org; Mon, 10 Jul 2006 14:41:35 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G00hK-0007xR-Hi for sip@ietf.org; Mon, 10 Jul 2006 14:41:34 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6AIfVf07038; Mon, 10 Jul 2006 14:41:32 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-audet-sip-sips-guidelines-02 Date: Mon, 10 Jul 2006 13:41:27 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0B4E2F42@zrc2hxm0.corp.nortel.com> In-Reply-To: <20060708005749.1070F222425@laser.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-audet-sip-sips-guidelines-02 Thread-Index: AcaiKH44PVGRu9zVTi6k95LuUAYoegCJJhUw From: "Francois Audet" To: "Eric Rescorla" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org FA> -----Original Message----- FA> From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 FA> Sent: Friday, July 07, 2006 5:50 PM FA> To: sip@ietf.org FA> Subject: [Sip] Review of draft-audet-sip-sips-guidelines-02 FA>=20 FA> This draft attempts to clarify the underspecification of=20 FA> SIPS in RFC 3261. This seems like a good idea in principle,=20 FA> but at least from the security guy perspective, I worry=20 FA> that this draft isn't completely baked yet. I do hasten to=20 FA> add that this is the security guy perspective, so there are=20 FA> probably SIP complexities I'm missing. FA>=20 FA> That said, ISTM that there are a number of problems that need to be FA> disentangled: FA>=20 FA> 1. What a UA which is trying to contact a given URI=20 FA> can expect in terms of how their messages will be FA> handled. FA> 2. What a UA can safely publish as their AOR and how FA> to do it. FA> 3. What a UA which receives a message can determine FA> about how the message was handled. FA>=20 FA> This draft handles all of these issues together and I think=20 FA> it would be best to handle them separately. Taking a step=20 FA> back, I think we want the following: FA>=20 FA> 1. A UA which tries to dereference a SIPS URI knows that FA> as long as its dealing with compliant proxies its messages FA> will be transmitted securely all the way to the peer. FA>=20 FA> 2. A UA can make itself available in the following ways: FA> - Secure only FA> - Secure or insecure but hopefully if you're dealing FA> with a secure peer then you both get secure. FA> - Insecure only. FA> So, AOR advertisement should support this. FA>=20 FA> 3. A UA can determine (again assuming it's dealing with compliant FA> proxies) whether the path from the peer was secure. FA>=20 FA> Do I have these requirements right? Thanks Eric. You are putting the finger on exactly where the problem is: Sips was never really well-defined. The requirements where never explicit. We are faced with the "fait accomplit" of RFC 3261.=20 What I am seeing now is the following: - There is a group of people now that are trying to implement SIP-TLS and can't make any sense of RFC 3261, and need guidance. - There is another group of people who see flaws with the basic requirements. It's going to be tough to reconcile this... FA>=20 FA> Issue (1) needs to be dealt with by imposing rules about=20 FA> what the proxies do. I.e., that when presented with SIPS=20 FA> they use TLS in the outgoing direction. The edge case--and=20 FA> the one that's creating most of the heartbreak--appears to=20 FA> be what happens inside of trust domains.=20 FA>=20 FA> Based on the discussion in this draft, Issue (2) breaks=20 FA> down into two cases: FA>=20 FA> (a) What you advertise when you register. FA> (b) What you put in your own headers (i.e., the To). FA>=20 FA> Case (a) seems like it's relatively straightforward using=20 FA> the rules described in S 5. It's case (b) that's tricky,=20 FA> due to the asymmetry of "SIPS means you must use TLS to=20 FA> your first hop proxy" and "SIPS means you may or may not=20 FA> use TLS between the last hop proxy and the final=20 FA> destination". Since that last link is about to become the=20 FA> first hop, this seems highly problematic. FA>=20 FA> ISTM that there are two natural fixes for this: FA>=20 FA> (a) Decree that SIPS means TLS all the way (this is a lot less FA> problematic in the face of outbound than it otherwise FA> would be.) FA> (b) Decree that it's none of our business what happens inside FA> people's trust boundaries and so SIPS only means secure FA> in between them. FA>=20 FA> This draft, however, takes neither approach and instead=20 FA> attempts to thread the needle between these. I'm not sure=20 FA> that this is practical--and it's certainly creating a lot=20 FA> of complexity. Basically, I'm fetching for opinions on this. Keep in mind that this is an individual draft still. We need people to express opinions on this.=20 As it stands, this draft is basically pointing out problems with RFC 3261. FA>=20 FA> Issue (3) seems like it ought to be solved the same way=20 FA> that it's ntended to be solved in RFC 3207 (STARTTLS):=20 FA> examine the Via lines or something like them. I would=20 FA> ignore the URI entirely here, especially in view of the=20 FA> confusion noted above. FA>=20 FA>=20 FA> DETAILED COMMENTS: FA> S 5.1: FA> I'm not sure why you need TLS transport to do a=20 FA> registration of a SIPS contact. My thinking is that if the registration itself is not secure, how can the Resources that are binding themselves to a sips URI with that registration be secure? FA> S 6. FA>=20 FA> If a UAS does not support SIPS, it MUST reject a request over TLS FA> with response code 416.=20 FA>=20 FA> I don't understand how this can happen. Can you explain? Good point. It can't. FA> Upon receiveing a 416 a UAC SHOULD not re- FA> attempt the request with a SIP URI by automatically replacing the FA> SIPS scheme with a SIP scheme. If the UAC does=20 FA> re-attempt the call FA> with a SIP URI, it SHOULD inform to the user that the=20 FA> security level FA> is downgraded. FA>=20 FA> Shouldn't this last SHOULD be a MUST? It seems like a=20 FA> security condition. I think that's from RFC 3261 verbatim. FA>=20 FA> The presence of a SIPS Request-URI does not necessarily=20 FA> indicate that FA> the request was sent end-to-end securely.=20 FA>=20 FA> The presence by the time you receive it, right? CAuse it=20 FA> should mean that at the sender.... Correct. FA>=20 FA>=20 FA> 26.4.4/RFC 3261 also explains that S/MIME may also be used by the FA> originating UAC to ensure that the original form of the To header FA> field is carried end-to-end. While not specifically mentioned in FA> 26.4.4/RFC 3261, this is meant to imply that [RFC3893]=20 FA> would be used FA> to "tunnel" important headers (such as To and From) in=20 FA> an encrypted FA> S/MIME body, replicating the information in the SIP message, and FA> allowing the UAS to validate the content of those=20 FA> important headers. FA> While this approach is certainly legal, another approach=20 FA> is to use FA> the SIP Identity mechanism defined in=20 FA> [I-D.ietf-sip-identity]. SIP FA> Identity creates a signed identity digest which includes, amongst FA> other things, the AOR of the sender (from the From=20 FA> header) and the FA> AOR of the original destination (from the To header). It is FA> RECOMMENDED that a UAC use the mechanism in=20 FA> [I-D.ietf-sip-identity] FA> instead of the one defined in RFC 3893. FA>=20 FA> You say "encrypted" here, but you really mean signed, right? I believe it's all of them for S/MIME. No encryption for SIP Identity. FA>=20 FA> S 13. FA> I'm not sure I find this that helpful. It's helpful for the author.... The idea would be to remove it later. FA> S 14. FA> It seems to me that most of these rules have security implications. Yes. It should really say TBD.... FA> -Ekr FA>=20 FA>=20 FA>=20 FA>=20 FA>=20 FA>=20 FA>=20 FA>=20 FA>=20 FA>=20 FA>=20 FA>=20 FA>=20 FA> =20 FA>=20 FA>=20 FA>=20 FA>=20 FA> =20 FA>=20 FA> _______________________________________________ FA> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip FA> This list is for NEW development of the core SIP Protocol=20 FA> Use sip-implementors@cs.columbia.edu for questions on=20 FA> current sip Use sipping@ietf.org for new developments on=20 FA> the application of sip FA>=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 14:52:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00qP-0000IV-DE; Mon, 10 Jul 2006 14:50:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00qN-0000IQ-CZ for sip@ietf.org; Mon, 10 Jul 2006 14:50:55 -0400 Received: from [132.219.15.238] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G00qM-0000FC-4o for sip@ietf.org; Mon, 10 Jul 2006 14:50:55 -0400 Received: by delta.rtfm.com (Postfix, from userid 1001) id B01551CC24; Mon, 10 Jul 2006 11:49:59 -0700 (PDT) To: "Francois Audet" Subject: Re: [Sip] Review of draft-audet-sip-sips-guidelines-02 References: <1ECE0EB50388174790F9694F77522CCF0B4E2F42@zrc2hxm0.corp.nortel.com> From: EKR Date: Mon, 10 Jul 2006 11:49:59 -0700 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0B4E2F42@zrc2hxm0.corp.nortel.com> (Francois Audet's message of "Mon, 10 Jul 2006 13:41:27 -0500") Message-ID: <868xn1thuw.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Francois Audet" writes: > FA> Issue (3) seems like it ought to be solved the same way > FA> that it's ntended to be solved in RFC 3207 (STARTTLS): > FA> examine the Via lines or something like them. I would > FA> ignore the URI entirely here, especially in view of the > FA> confusion noted above. > FA> > FA> > FA> DETAILED COMMENTS: > FA> S 5.1: > FA> I'm not sure why you need TLS transport to do a > FA> registration of a SIPS contact. > > My thinking is that if the registration itself is not secure, how can > the > Resources that are binding themselves to a sips URI with that > registration be > secure? Well, what if it happened on some walled garden network? > FA> S 13. > FA> I'm not sure I find this that helpful. > > It's helpful for the author.... The idea would be to remove it later. That makes sense... -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 15:16:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01DF-0000Pu-Rl; Mon, 10 Jul 2006 15:14:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01DD-0000Jq-PB for sip@ietf.org; Mon, 10 Jul 2006 15:14:31 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G01DC-0001dY-Bp for sip@ietf.org; Mon, 10 Jul 2006 15:14:31 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6AJDbGR027166; Mon, 10 Jul 2006 22:14:19 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 22:14:16 +0300 Received: from essapo-nirac25284.europe.nokia.com ([10.162.252.84]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 Jul 2006 22:14:15 +0300 Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 From: Aki Niemi To: ext Juha Heinanen In-Reply-To: <17586.27089.302552.734252@rautu.tutpro.com> References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <002c01c6a1ed$6e8726f0$31713b51@BEMBUSTER> <44B25CED.2060302@nokia.com> <17586.27089.302552.734252@rautu.tutpro.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Mon, 10 Jul 2006 14:51:24 -0400 Message-Id: <1152557484.19220.0.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 19:14:16.0188 (UTC) FILETIME=[094D63C0:01C6A455] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Miguel Garcia , sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On ma, 2006-07-10 at 17:53 +0300, ext Juha Heinanen wrote: > in fact, outbound would provides LESS than what we have today. >From my point of view, the most important thing missing today is getting SIP over TCP to work in presence of NATs. This is what outbound provides, which IMO is more than what's available today. -- Aki Niemi Nokia Research Center _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 15:17:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01Ek-0001QT-Ac; Mon, 10 Jul 2006 15:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01Ej-0001QG-4U for sip@ietf.org; Mon, 10 Jul 2006 15:16:05 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G01Eh-0001hP-Nr for sip@ietf.org; Mon, 10 Jul 2006 15:16:05 -0400 Received: (qmail 18936 invoked by uid 0); 10 Jul 2006 19:15:56 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 10 Jul 2006 19:15:56 -0000 Message-ID: <010601c6a455$42a96150$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com><44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <44B0E7B3.3060801@nokia.com> <003801c6a354$5f9c0a80$31713b51@BEMBUSTER> <5ff412ad9f184bb5d8e5f552b09b3ad0@ekabal.com> Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Mon, 10 Jul 2006 21:15:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Miguel Garcia , Cullen Jennings , sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan, >> If the system is architected as Juha was describing (2 independent >> proxies, UA missing 50% of its calls when only setting up 1 flow), the >> chance at missed requests for such a UA is much higher than double that >> of a single flow system. I feel that outbound should certainly not >> mandate such an architecture. > > The UA doesn't miss 50% of its calls in this case. If only one flow is > registered, the registrar/home proxy will forward incoming requests only > over that flow. Its just that the UA is not playing nicely with the > proxies, as they would like to load balance over two flows, but they have > to forward all the traffic for the UA over one flow instead. > As long as things work as you describe here, it's fine with me. The 50% was based on Juha's description of the system he envisioned earlier in this thread >> Currently in SIP the assumption is that a single registration suffices to >> receive all incoming requests for a given AoR. If we break that, it means >> that current UAs won't be able to register with "outbound-enhanced" >> registrars and edge proxies. That to me is not acceptable. > > there is no requirement in outbound that pre-outbound registrations will > not work. > True, but this is not the same as a requirement that says that pre-outbound registrations MUST still work (and receive 100% of service, not 50%). I thought this was implicitly obvious, but recent discussions suggest otherwise >> In other words, a requirement is missing: "Support UAs that do not >> implement this extension" > > What amount of "support" do you envision? Just no less - statistically speaking - than a UA would get from a REGISTER today. Regards, Jeroen > > thanks, > -rohan > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 15:26:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01Mp-0002S3-Pj; Mon, 10 Jul 2006 15:24:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01Mo-0002Ry-6j for sip@ietf.org; Mon, 10 Jul 2006 15:24:26 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G01Mm-00028L-P4 for sip@ietf.org; Mon, 10 Jul 2006 15:24:26 -0400 Received: (qmail 30320 invoked by uid 0); 10 Jul 2006 19:24:17 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 10 Jul 2006 19:24:17 -0000 Message-ID: <011101c6a456$6d5fdea0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Miguel Garcia" , "ext Michael Hammer \(mhammer\)" References: <072C5B76F7CEAB488172C6F64B30B5E301AC0171@xmb-rtp-20b.amer.cisco.com> <44B28EBA.5010504@nokia.com> Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Mon, 10 Jul 2006 21:24:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org, Rohan Mahy , "Cullen Jennings \(fluffy\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Acceptable with a minor change in wording: "if a network OFFERS TO use multiple flows". I compare this with an incoming INVITE that offers both audio and video. An UA might accept the audio but refuse the video, for whatever reason. The communication experience will be different (some might say "less"), but it's the UA's decision. If there are no keepalives, then that is one compelling reason less to establish fewer flows than offered. So phrases like "the UA SHOULD establish a flow to each URI in the outbound proxy set" and "it is RECOMMENDED that..." are fine. Regards, Jeroen ----- Original Message ----- From: "Miguel Garcia" To: "ext Michael Hammer (mhammer)" Cc: ; "Rohan Mahy" ; "Cullen Jennings (fluffy)" Sent: Monday, July 10, 2006 7:30 PM Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 > Michael Hammer (mhammer) wrote: >> So, could one infer from your statement, that if a network uses multiple >> flows, but not keepalives, because it knows there are no NATs, then that >> would be an acceptable configuration? >> > > Yes, although I am not sure the benefit outbound will give you in this > case, but it would be fine. > > /Miguel > >> Mike >> > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 15:31:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01Rv-00038w-R3; Mon, 10 Jul 2006 15:29:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01Ru-00038r-S5 for sip@ietf.org; Mon, 10 Jul 2006 15:29:42 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G01Rt-0002JL-Gt for sip@ietf.org; Mon, 10 Jul 2006 15:29:42 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 529F613F979; Mon, 10 Jul 2006 22:29:37 +0300 (EEST) Received: from rautu (allozyme53.gprs.dnafinland.fi [62.78.104.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 265D113F979; Mon, 10 Jul 2006 22:29:27 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 77242F0B0B; Mon, 10 Jul 2006 22:29:37 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17586.43680.630973.131072@rautu.tutpro.com> Date: Mon, 10 Jul 2006 22:29:36 +0300 From: Juha Heinanen To: "Jeroen van Bemmel" Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 In-Reply-To: <010601c6a455$42a96150$31713b51@BEMBUSTER> References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <44B0E7B3.3060801@nokia.com> <003801c6a354$5f9c0a80$31713b51@BEMBUSTER> <5ff412ad9f184bb5d8e5f552b09b3ad0@ekabal.com> <010601c6a455$42a96150$31713b51@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Miguel Garcia , Rohan Mahy , sip@ietf.org, Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel writes: > True, but this is not the same as a requirement that says that pre-outbound > registrations MUST still work (and receive 100% of service, not 50%). I > thought this was implicitly obvious, but recent discussions suggest > otherwise. i haven't said that pre-outbound registrations would not work. what would not work is that if UA claims outbound support, but establishes only one flow when two would be the minimum for a particular domain. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 15:37:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01Xn-00047U-A8; Mon, 10 Jul 2006 15:35:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01Xm-00046w-3q for sip@ietf.org; Mon, 10 Jul 2006 15:35:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G01Xm-0002a7-2K for sip@ietf.org; Mon, 10 Jul 2006 15:35:46 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G01U9-0007YV-9S for sip@ietf.org; Mon, 10 Jul 2006 15:32:03 -0400 Received: (qmail 6886 invoked by uid 0); 10 Jul 2006 19:31:51 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 10 Jul 2006 19:31:51 -0000 Message-ID: <013001c6a457$7be7b2d0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Michael Hammer \(mhammer\)" , "Miguel Garcia" , "Jonathan Rosenberg \(jdrosen\)" References: <072C5B76F7CEAB488172C6F64B30B5E301AC0171@xmb-rtp-20b.amer.cisco.com> Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Mon, 10 Jul 2006 21:31:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: -2.4 (--) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org, Rohan Mahy , "Cullen Jennings \(fluffy\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >So, could one infer from your statement, that if a network uses multiple >flows, but not keepalives, because it knows there are no NATs, then that >would be an acceptable configuration? Besides being outside of the scope of outbound, the current text also makes it impossible to do optimizations like this (ie telling the UA not to do keepalive) because of the text in 7.1: "When a URI is created that refers to a SIP device that supports STUN as described in this section, the 'keepalive' URI parameter, as defined in Section 10 MUST be added to the URI, with a value of 'stun'." Regards, jeroen > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: Monday, July 10, 2006 12:18 PM > To: Jonathan Rosenberg (jdrosen) > Cc: sip@ietf.org; Rohan Mahy; Cullen Jennings (fluffy) > Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 > > Jonathan Rosenberg wrote: > > inline. > > > > I'm not entirely convinced that, once you're doing one flow with > > sip-outbound, that the incremental cost of an additional flow has a > > major impact on battery life. > > It does, not because of the flow itself, but because of the > keepalives every 30 seconds. > > > > That said, I think this is starting to split hairs. The > main point, I > > think, is that, under almost all conditions, if a client is > offered N > > URI it opens N flows. Only for *exceptional* conditions > would it open > > less. I would be OK with a strongly-qualified SHOULD. I.e., > the spec > > would say SHOULD and then explain that its only under such extreme > > conditions that it would open fewer. > > I am fine with this proposal. And I wouldn't mine to add some > paragraph > describing the conditions under which the UA would establish > the N flows. > > /Miguel > > > Thanks, > > Jonathan R. > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 15:41:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01bs-00050T-AP; Mon, 10 Jul 2006 15:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01br-00050O-KQ for sip@ietf.org; Mon, 10 Jul 2006 15:39:59 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G01bq-0002pV-Bd for sip@ietf.org; Mon, 10 Jul 2006 15:39:59 -0400 Received: from [132.219.4.230] (helo=JMHLap3.stevecrocker.com) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1G01bh-0006Xn-1Q; Mon, 10 Jul 2006 15:39:49 -0400 Message-Id: <7.0.1.0.0.20060710153817.0333c730@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 10 Jul 2006 15:39:47 -0400 To: Juha Heinanen ,"Jeroen van Bemmel" From: "Joel M. Halpern" Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 In-Reply-To: <17586.43680.630973.131072@rautu.tutpro.com> References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <44B0E7B3.3060801@nokia.com> <003801c6a354$5f9c0a80$31713b51@BEMBUSTER> <5ff412ad9f184bb5d8e5f552b09b3ad0@ekabal.com> <010601c6a455$42a96150$31713b51@BEMBUSTER> <17586.43680.630973.131072@rautu.tutpro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b5711207249f4a11fddf0b4ab61c4ac532d2730d9b6ea08cb58335c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 132.219.4.230 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Miguel Garcia , Rohan Mahy , sip@ietf.org, Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I do not think it is the UAs job to provide support for the operators architecture. Nor is it "outbound"s job to mandate specific redundancy mechanisms (it currently seems to do so, although I think all of that is intended as examples.) Yours, Joel At 03:29 PM 7/10/2006, Juha Heinanen wrote: >Jeroen van Bemmel writes: > > > True, but this is not the same as a requirement that says that > pre-outbound > > registrations MUST still work (and receive 100% of service, not 50%). I > > thought this was implicitly obvious, but recent discussions suggest > > otherwise. > >i haven't said that pre-outbound registrations would not work. what >would not work is that if UA claims outbound support, but establishes >only one flow when two would be the minimum for a particular domain. > >-- juha > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 15:59:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01tb-0006C5-T9; Mon, 10 Jul 2006 15:58:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G01ta-0006At-GN for sip@ietf.org; Mon, 10 Jul 2006 15:58:18 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G01tZ-0004H1-97 for sip@ietf.org; Mon, 10 Jul 2006 15:58:18 -0400 Received: from [132.219.4.230] (helo=JMHLap3.stevecrocker.com) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1G01tU-00082B-0I; Mon, 10 Jul 2006 15:58:12 -0400 Message-Id: <7.0.1.0.0.20060710155005.032fde38@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 10 Jul 2006 15:58:10 -0400 To: Juha Heinanen From: "Joel M. Halpern" Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 In-Reply-To: <20060710194750.4B521F0B16@rautu> References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <44B0E7B3.3060801@nokia.com> <003801c6a354$5f9c0a80$31713b51@BEMBUSTER> <5ff412ad9f184bb5d8e5f552b09b3ad0@ekabal.com> <010601c6a455$42a96150$31713b51@BEMBUSTER> <17586.43680.630973.131072@rautu.tutpro.com> <7.0.1.0.0.20060710153817.0333c730@stevecrocker.com> <20060710194750.4B521F0B16@rautu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b5711207249f4a11fddf0b425b18709c74ff0a31ef69bcbf31b9e0d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 132.219.4.230 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Miguel Garcia , Rohan Mahy , sip@ietf.org, Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My problem is that this couples the network requirements for resiliency with the UA's preferences and with the UA's need to get through a firewall (often not even under the networks control.) Outbound is not the place for the network to get the UA to help with redundancy. Yours, Joel At 03:47 PM 7/10/2006, Juha Heinanen wrote: >Joel M. Halpern writes: > > > Nor is it "outbound"s job to mandate specific redundancy mechanisms > > (it currently seems to do so, although I think all of that is > > intended as examples.) > >outbound can support any number of redundancy mechanisms. if a domain >chooses to require two flows from a particular UA, then it is up to >outbound UA to do so. another domain may have different policy. as >long as outbound UA is able to setup at least two flows everything is >ok. > >-- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 16:07:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G020i-0007uZ-I1; Mon, 10 Jul 2006 16:05:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G020g-0007uN-Ot for sip@ietf.org; Mon, 10 Jul 2006 16:05:38 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G020f-0004go-DE for sip@ietf.org; Mon, 10 Jul 2006 16:05:38 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 7B4DF1400A2; Mon, 10 Jul 2006 23:05:31 +0300 (EEST) Received: from rautu (allozyme53.gprs.dnafinland.fi [62.78.104.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 1EC2A13F979; Mon, 10 Jul 2006 23:05:25 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id A0294F0B1B; Mon, 10 Jul 2006 23:05:34 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17586.45838.30809.555728@rautu.tutpro.com> Date: Mon, 10 Jul 2006 23:05:34 +0300 From: Juha Heinanen To: "Joel M. Halpern" Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 In-Reply-To: <7.0.1.0.0.20060710155005.032fde38@stevecrocker.com> References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <44B0E7B3.3060801@nokia.com> <003801c6a354$5f9c0a80$31713b51@BEMBUSTER> <5ff412ad9f184bb5d8e5f552b09b3ad0@ekabal.com> <010601c6a455$42a96150$31713b51@BEMBUSTER> <17586.43680.630973.131072@rautu.tutpro.com> <7.0.1.0.0.20060710153817.0333c730@stevecrocker.com> <20060710194750.4B521F0B16@rautu> <7.0.1.0.0.20060710155005.032fde38@stevecrocker.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Miguel Garcia , Rohan Mahy , sip@ietf.org, Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Joel M. Halpern writes: > Outbound is not the place for the network to get the UA to help with > redundancy. ok, in case i was misled to believe so. it would have been years of migration to outbound anyhow and without normative reference to discovery, its deployment would have been a nightmare in open environment. so i'll rest my case and go back to write code. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 16:45:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02bX-00045r-3v; Mon, 10 Jul 2006 16:43:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02bV-00045g-9u for sip@ietf.org; Mon, 10 Jul 2006 16:43:41 -0400 Received: from [192.84.19.237] (helo=mailint.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G02bT-0006kB-M6 for sip@ietf.org; Mon, 10 Jul 2006 16:43:41 -0400 Received: from mailint.8x8.com (localhost.localdomain [127.0.0.1]) by mailint.8x8.com (8.13.1/8.13.1) with ESMTP id k6AKgR97014474; Mon, 10 Jul 2006 13:42:28 -0700 Received: from mailint.8x8.com (root@localhost) by mailint.8x8.com (8.13.1/8.13.1/Submit) with ESMTP id k6AKgA0d014451; Mon, 10 Jul 2006 13:42:19 -0700 Received: from [10.0.2.15] (godzilla.8x8.com 192.168.84.42) by mailint.8x8.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Mon, 10 Jul 2006 13:42:10 -0700 (PDT) Date: Mon, 10 Jul 2006 16:42:13 -0400 From: Marc Petit-Huguenin To: Dean Willis Message-ID: <44B2BBA5.5010004@acm.org> In-Reply-To: <5A349A8F-A2FC-4343-8A3E-BFA27267E130@softarmor.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0280D7E8@esebe103.NOE.Nokia.com> References: <553B0B8B-7808-4BAD-ABB5-6D164C4B30A0@cisco.com> References: <003e01c69fb1$ad32e760$31713b51@BEMBUSTER> References: <17579.25760.584180.394914@rautu.tutpro.com> References: <44AE14E2.6040700@softarmor.com> References: <17583.59900.171344.986622@rautu.tutpro.com> References: <5A349A8F-A2FC-4343-8A3E-BFA27267E130@softarmor.com> Subject: Re: [Sip] Ready for WGLC on Outbound? x-scalix-Hops: 1 User-Agent: Thunderbird 1.5.0.4 (X11/20060619) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Cullen Jennings , sip@ietf.org, Juha Heinanen , rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Jul 8, 2006, at 12:23 PM, Juha Heinanen wrote: > >> >>> Or just hope it won't melt when you send it a STUN packet, meaning that >>> you "require the operator to get it right". >> >>> The problem as I see it is we have no way of easily detecting an error >>> if somebody mistakenly lists a non-compliant proxy as an outbound proxy >>> in DHCP or some other discovery mechanism. I hate leaping off a trapeze >>> without a safety net . . . >> >> no properly implemented proxy melts no matter what you sent to it. this >> kind of arguments are completely bogus. > > Dale has noted in a separate thread that STUN breaks TCP framing, One solution to fix this TCP framing problem would be to add an attribute in the STUN request, just before the FINGERPRINT attribute, that contain this octet string: 0x00000D0A6C3A32340D0A0D0A This embeds the character string "\r\nl:24\r\n\r\n", which should be enough to have the SIP parser skip the entire STUN message, and return an error (same than with UDP). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 17:08:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02xU-0004pJ-Ip; Mon, 10 Jul 2006 17:06:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02xT-0004pE-Cw for sip@ietf.org; Mon, 10 Jul 2006 17:06:23 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G02xM-0007aE-W2 for sip@ietf.org; Mon, 10 Jul 2006 17:06:23 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id E8C536C02B; Mon, 10 Jul 2006 16:05:22 -0400 (EDT) Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt From: Scott Lawrence To: "Drage, Keith (Keith)" In-Reply-To: <475FF955A05DD411980D00508B6D5FB01369D81C@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB01369D81C@en0033exch001u.uk.lucent.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Mon, 10 Jul 2006 17:05:23 -0400 Message-Id: <1152565523.2919.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sip@ietf.org, ahawrylyshen@ditechnetworks.com, RjS@nostrum.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mon, 2006-07-10 at 15:13 +0100, Drage, Keith (Keith) wrote: > Getting back to the Warning issue: > and you go to the IANA registration section in 27.2: > > This specification establishes the Warn-codes sub-registry under > http://www.iana.org/assignments/sip-parameters and initiates its > population with the warn-codes listed in Section 20.43. Additional > warn-codes are registered by RFC publication. > The descriptive text for the table of warn-codes is: > Warning codes provide information supplemental to the status code in > SIP response messages when the failure of the transaction results > from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. > > The "warn-code" consists of three digits. A first digit of "3" > indicates warnings specific to SIP. Until a future specification > describes uses of warn-codes other than 3xx, only 3xx warn-codes may > be registered. > > Warnings 300 through 329 are reserved for indicating problems with > keywords in the session description, 330 through 339 are warnings > related to basic network services requested in the session > description, 370 through 379 are warnings related to quantitative QoS > parameters requested in the session description, and 390 through 399 > are miscellaneous warnings that do not fall into one of the above > categories. > > I believe this text is clear in requiring IANA to register codes that apply only to SDP errors. > > The text is reproduced on the IANA registry page concerned. > > Now whether we should change this or not I will leave open to discussion, but that is what it says at the moment. Fair enough. I've explained why I think the Server and Contact headers are not good for identifying the responding server, and I think that the value of identifying the responding server is clear. What does the group think is better: - define a new mechanism - expanding the usage of Warning -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 17:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G03e9-0000Os-UB; Mon, 10 Jul 2006 17:50:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G03Ya-0007Z1-Ux for sip@ietf.org; Mon, 10 Jul 2006 17:44:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G01Xn-0002Zh-0C for sip@ietf.org; Mon, 10 Jul 2006 15:35:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G01SK-0007W2-Fp for sip@ietf.org; Mon, 10 Jul 2006 15:30:10 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 10 Jul 2006 12:30:05 -0700 X-IronPort-AV: i="4.06,225,1149490800"; d="scan'208"; a="304577490:sNHT32745514" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k6AJU5mU010977; Mon, 10 Jul 2006 12:30:05 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6AJU4fr014552; Mon, 10 Jul 2006 12:30:05 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 15:30:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Mon, 10 Jul 2006 15:30:02 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301AC0216@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Thread-Index: AcakKQEfN5T/5ULMSGuZySN2qZY1SQACDdogAAAub2AAARAe8AADOU7gAATKC2A= From: "Michael Hammer \(mhammer\)" To: "Hadriel Kaplan" X-OriginalArrivalTime: 10 Jul 2006 19:30:04.0625 (UTC) FILETIME=[3E9D6410:01C6A457] DKIM-Signature: a=rsa-sha1; q=dns; l=3076; t=1152559805; x=1153423805; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Re=3A=20A=20coment=20to=20draft-ietf-sip-outbound-04; X=v=3Dcisco.com=3B=20h=3DT0Nc55Nkv0j8Iblrp5myBehinAo=3D; b=qed495Ae9oTuVCp5+84QnQvls1IASO7HYURyZ1Y8vl8mKTvtiaQZknZUiur2ZZEUaR/TiFNn pxQHe7cX7RiK8PHXhEb7AxE9G4aEZLaHeyhKQ4fqdizUwAOFCXNs5UE+; Authentication-Results: sj-dkim-5.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Agree, it is not a panacea, but a means of mitigation. I tend to feel things have scaled well when we start talking millions. But, I know of some systems that think in terms of tens to hundreds of thousands. Of course, you would need to detect and re-establish IP connectivity. As for the avalanche on a replacement proxy in the power-out region (versus the one outside that region), you could spread the load across a much longer time period (tens of minutes, if you like), while the backup proxy could deliver calls following the connectivity re-establishment. Mike > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Monday, July 10, 2006 2:23 PM > To: Michael Hammer (mhammer) > Cc: sip@ietf.org > Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 >=20 > My point was just that it's not a panacea for the avalanche=20 > issue. It helps in various failure modes, doesn't in others.=20 > The power outage was just an extreme failure mode example;=20 > there are others. =20 >=20 > I know everyone's mileage varies, but 2 Minutes lets a heck=20 > of a lot of UAs register, from what I've seen of registrar=20 > reg/sec load handling. Like at least in the thousands. If=20 > more than thousands of UAs are registering anew, the odds are=20 > it was either because they've all rebooted due to regional=20 > power loss, or their primary proxy died/lost-comms. In the=20 > former case multiple flows would not help. In the latter=20 > case outbound would have all the UAs connecting to a backup=20 > for that failed primary in 90 seconds (ie, they use the=20 > secondary proxy, but then create a replacement for the failed=20 > flow). So the avalanche is still there, just for another proxy, no? >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Monday, July 10, 2006 11:43 AM > > To: Hadriel Kaplan; Miguel Garcia; Rohan Mahy > > Cc: sip@ietf.org; Cullen Jennings (fluffy) > > Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 > >=20 > > That 2-minute period could be smoothed out over a much=20 > longer period=20 > > of time if there were multiple flows. > >=20 > > Your power outage example assumes a specific topology relative to=20 > > where power was lost. I disagree with assuming a poor=20 > network design=20 > > as argument for multiple flows not handling the outage. > >=20 > > I do agree that proxies need to handle such overloads, but=20 > that leads=20 > > right back to the service being out for longer than the=20 > acceptable (?)=20 > > 2 minute period. > >=20 > > I am not adverse to wireless networks choosing to make the=20 > tradeoff of=20 > > battery time to increased possibility of missing incoming calls, I=20 > > just think that there needs to be agreement between the network and=20 > > client as to what is acceptable and what those tradeoffs are, such=20 > > that neither has negative impacts. > >=20 > > Mike >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 17:54:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G03gF-0002EH-Ib; Mon, 10 Jul 2006 17:52:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G03gC-0002CM-GY for sip@ietf.org; Mon, 10 Jul 2006 17:52:36 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G03gA-0003tM-Ui for sip@ietf.org; Mon, 10 Jul 2006 17:52:36 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4756D8CC for ; Mon, 10 Jul 2006 23:52:32 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 23:52:31 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 23:52:31 +0200 Received: from [131.160.126.8] (rvi2-126-8.lmf.ericsson.se [131.160.126.8]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3D70C295B for ; Tue, 11 Jul 2006 00:52:31 +0300 (EEST) Message-ID: <44B2CC1E.1070200@ericsson.com> Date: Tue, 11 Jul 2006 00:52:30 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 21:52:31.0558 (UTC) FILETIME=[24FBDE60:01C6A46B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] [Fwd: P2P SIP Ad-hoc on Friday at 12:30 at Room 519A] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org FYI. -------- Original Message -------- Subject: P2P SIP Ad-hoc on Friday at 12:30 at Room 519A Date: Tue, 11 Jul 2006 00:50:37 +0300 From: Gonzalo Camarillo To: sipping CC: Mary Barnes Folks, the ad-hoc meeting on SIP peer-to-peer will take place on Friday, at 12:30, at Room 519A. The room is reserved until 15:00. Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 18:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G03nu-0005hj-KJ; Mon, 10 Jul 2006 18:00:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G03nt-0005he-5k for sip@ietf.org; Mon, 10 Jul 2006 18:00:33 -0400 Received: from [2001:5c0:8fff:fffe::4c49] (helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G03nr-0004Mq-3a for sip@ietf.org; Mon, 10 Jul 2006 18:00:33 -0400 Received: from [132.219.30.170] (h1eaa-net84db.lab.risq.net [132.219.30.170] (may be forged)) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6ALx3JK077623 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 10 Jul 2006 16:59:08 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <1152565523.2919.20.camel@localhost.localdomain> References: <475FF955A05DD411980D00508B6D5FB01369D81C@en0033exch001u.uk.lucent.com> <1152565523.2919.20.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2479970F-4337-4A67-9656-B6DFC0E5E033@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt Date: Mon, 10 Jul 2006 17:59:02 -0400 To: Scott Lawrence X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 132.219.30.170 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org, ahawrylyshen@ditechnetworks.com, "Drage, Keith \(Keith\)" , RjS@nostrum.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 10, 2006, at 5:05 PM, Scott Lawrence wrote: > On Mon, 2006-07-10 at 15:13 +0100, Drage, Keith (Keith) wrote: >> Getting back to the Warning issue: > > ... >> >> I believe this text is clear in requiring IANA to register codes >> that apply only to SDP errors. >> >> The text is reproduced on the IANA registry page concerned. >> >> Now whether we should change this or not I will leave open to >> discussion, but that is what it says at the moment. > > Fair enough. > > I've explained why I think the Server and Contact headers are not good > for identifying the responding server, and I think that the value of > identifying the responding server is clear. > > What does the group think is better: > > - define a new mechanism > - expanding the usage of Warning I don't feel strongly, but if we allow the scope to creep to other response conditions, then I suspect we'll be better off with a new mechanism and propose that carrying that data (and any other meta-data we might discover useful) in the body. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 19:22:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G053m-00044h-6K; Mon, 10 Jul 2006 19:21:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G053k-00044A-Be for sip@ietf.org; Mon, 10 Jul 2006 19:21:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G021W-0004mU-MA for sip@ietf.org; Mon, 10 Jul 2006 16:06:30 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G01jb-0007zR-Jq for sip@ietf.org; Mon, 10 Jul 2006 15:48:00 -0400 Received: by tutpro.com (Postfix, from userid 65534) id B9AB01400A4; Mon, 10 Jul 2006 22:47:50 +0300 (EEST) Received: from rautu (allozyme53.gprs.dnafinland.fi [62.78.104.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 0DB981400A2; Mon, 10 Jul 2006 22:47:40 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 4B521F0B16; Mon, 10 Jul 2006 22:47:50 +0300 (EEST) From: Juha Heinanen To: "Joel M. Halpern" Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 In-Reply-To: <7.0.1.0.0.20060710153817.0333c730@stevecrocker.com> References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <44B0E7B3.3060801@nokia.com> <003801c6a354$5f9c0a80$31713b51@BEMBUSTER> <5ff412ad9f184bb5d8e5f552b09b3ad0@ekabal.com> <010601c6a455$42a96150$31713b51@BEMBUSTER> <17586.43680.630973.131072@rautu.tutpro.com> <7.0.1.0.0.20060710153817.0333c730@stevecrocker.com> X-Mailer: VM 7.19 under Emacs 21.4.1 Message-Id: <20060710194750.4B521F0B16@rautu> Date: Mon, 10 Jul 2006 22:47:50 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: -2.6 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Miguel Garcia , Rohan Mahy , sip@ietf.org, Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Joel M. Halpern writes: > Nor is it "outbound"s job to mandate specific redundancy mechanisms > (it currently seems to do so, although I think all of that is > intended as examples.) outbound can support any number of redundancy mechanisms. if a domain chooses to require two flows from a particular UA, then it is up to outbound UA to do so. another domain may have different policy. as long as outbound UA is able to setup at least two flows everything is ok. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 19:27:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0588-0005ma-Lf; Mon, 10 Jul 2006 19:25:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0587-0005mV-66 for sip@ietf.org; Mon, 10 Jul 2006 19:25:31 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0584-0007dL-UU for sip@ietf.org; Mon, 10 Jul 2006 19:25:31 -0400 Received: from [132.219.4.230] (helo=JMHLap3.stevecrocker.com) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1G0581-0006LQ-3O; Mon, 10 Jul 2006 19:25:25 -0400 Message-Id: <7.0.1.0.0.20060710192359.0333cde8@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 10 Jul 2006 19:25:21 -0400 To: Juha Heinanen From: "Joel M. Halpern" Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 In-Reply-To: <20060710194750.4B521F0B16@rautu> References: <44AB9820.4050200@nokia.com> <4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com> <44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com> <44ADF80B.2000204@nokia.com> <44B0E7B3.3060801@nokia.com> <003801c6a354$5f9c0a80$31713b51@BEMBUSTER> <5ff412ad9f184bb5d8e5f552b09b3ad0@ekabal.com> <010601c6a455$42a96150$31713b51@BEMBUSTER> <17586.43680.630973.131072@rautu.tutpro.com> <7.0.1.0.0.20060710153817.0333c730@stevecrocker.com> <20060710194750.4B521F0B16@rautu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b5711207249f4a11fddf0b4312998f5a0b3d80cb174fd24821b975c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 132.219.4.230 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Miguel Garcia , Rohan Mahy , sip@ietf.org, Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org By this interpretation, a network could not offer redundant / backup connectivity (via outbound) to UAs which want to take advantage of that without also mandating that all UAs make connect to all the entities. Yours, Joel At 03:47 PM 7/10/2006, Juha Heinanen wrote: >Joel M. Halpern writes: > > > Nor is it "outbound"s job to mandate specific redundancy mechanisms > > (it currently seems to do so, although I think all of that is > > intended as examples.) > >outbound can support any number of redundancy mechanisms. if a domain >chooses to require two flows from a particular UA, then it is up to >outbound UA to do so. another domain may have different policy. as >long as outbound UA is able to setup at least two flows everything is >ok. > >-- juha > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 19:34:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G05FF-0008VU-Ca; Mon, 10 Jul 2006 19:32:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G05FD-0008T5-W7 for sip@ietf.org; Mon, 10 Jul 2006 19:32:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzwGn-0008IR-Pp for sip@ietf.org; Mon, 10 Jul 2006 09:57:53 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fzw39-00017u-Vp for sip@ietf.org; Mon, 10 Jul 2006 09:43:48 -0400 Received: from [10.0.1.2] ([142.131.134.168]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6ADhUsh011480 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 10 Jul 2006 08:43:41 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <06C96942-34A9-481A-86FF-F8B02CBFFC01@softarmor.com> References: <0306223F-C113-47A0-B148-5E0E5B7E2159@estacado.net> <06C96942-34A9-481A-86FF-F8B02CBFFC01@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7530787B-7B45-4866-9420-CBCFD3493DA8@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Sip] Proposals for review process to conclude WGLCs Date: Mon, 10 Jul 2006 09:43:29 -0400 To: Dean Willis X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.6 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org, Mary Barnes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 10, 2006, at 1:22 AM, Dean Willis wrote: > > On Jul 9, 2006, at 10:48 PM, Ben Campbell wrote: > >> Time zones are going to be an issue with any real-time review >> process. Maybe it is an issue we can deal with, but I suspect some >> number people who would otherwise participate may be locked out, >> or at least discouraged, by the idea of doing conference calls in >> their normal sleep cycle. > > You people sleep? No wonder we're missing milestones! Keith, we > need to recalculate all the milestones to accommodate this sleep > thing. > > Seriously, one would have to schedule an individual review to meet > the schedules of the selected review team. We'd have to be careful > not to mix people in very bad configurations. This can usually be > sorted out for groups of 3-5 people selected from a large pool, > assuming they're willing to work between 7:00 AM and midnight in > their home time zones. Of course, that does leave out at least one > area director I know of . . . For that group size, I agree. I had somehow assumed larger groups for no particular reasons. > > -- > Dean > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 19:38:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G05Ix-0001nD-NZ; Mon, 10 Jul 2006 19:36:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzGa2-0002aj-4u for sip@ietf.org; Sat, 08 Jul 2006 13:26:58 -0400 Received: from [2001:5c0:8fff:fffe::4c3d] (helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzGZz-0005hw-Ry for sip@ietf.org; Sat, 08 Jul 2006 13:26:58 -0400 Received: from [142.157.201.14] (dhcp201014.rez.mcgill.ca [142.157.201.14]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k68HQjZb085373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Jul 2006 12:26:50 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <44AFEAC3.3020505@estacado.net> Date: Sat, 08 Jul 2006 12:26:27 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] Outbound Comment: q-value References: <44AC9C9F.1000701@nostrum.com> <17580.44383.443990.716678@rautu.tutpro.com> <44AD4A76.6070309@estacado.net> <17583.59103.225110.806776@rautu.tutpro.com> In-Reply-To: <17583.59103.225110.806776@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Mon, 10 Jul 2006 19:36:42 -0400 Cc: Cullen Jennings , SIP WG , Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Adam Roach writes: > > > I'm suggesting a third bullet that reads something like: > > > > * If multiple bindings have the same instance-id, the proxy MUST NOT > > use a binding until all bindings of greater q-value have been tried. > > if outbound set has two proxies and UA registers with one using q value > 0.5 and with the other using q value 0.6, there would be only one > binding per proxy. in that case, i hope you are not suggesting that one > proxy asks the other if it has higher q value for the same instance id. > I'm not adding any new requirements here. The following bullet has identical implications: o If two bindings have the same instance-id and reg-id, the proxy SHOULD prefer the contact that was most recently updated. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 21:17:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G06q8-0007KO-TY; Mon, 10 Jul 2006 21:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G06q8-0007KE-5k for sip@ietf.org; Mon, 10 Jul 2006 21:15:04 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G06q6-0006wq-Ps for sip@ietf.org; Mon, 10 Jul 2006 21:15:04 -0400 Received: (qmail 29933 invoked by uid 0); 11 Jul 2006 01:15:00 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 11 Jul 2006 01:15:00 -0000 Message-ID: <000c01c6a487$6e97cc20$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Tue, 11 Jul 2006 03:15:00 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Sip] outbound slide 9 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1104507274==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1104507274== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C6A498.31FCC070" This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C6A498.31FCC070 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Suggestion for EP indicating it added a token: =20 Path: Regards, jeroen ------=_NextPart_000_0009_01C6A498.31FCC070 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Suggestion for EP indicating it added a = token:
 
Path:=20 <sip:token@ep.example.com;lr;user=3Dtoken><= /DIV>
 
Regards,
 
jeroen
------=_NextPart_000_0009_01C6A498.31FCC070-- --===============1104507274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1104507274==-- From sip-bounces@ietf.org Mon Jul 10 23:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G08k4-0002Cz-Qk; Mon, 10 Jul 2006 23:16:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G08k3-0002Cr-K3 for sip@ietf.org; Mon, 10 Jul 2006 23:16:55 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G08k2-0003Xu-BU for sip@ietf.org; Mon, 10 Jul 2006 23:16:55 -0400 Received: from [142.131.134.137] (helo=JMHLap3.stevecrocker.com) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1G08k1-0003dY-G0 for sip@ietf.org; Mon, 10 Jul 2006 23:16:54 -0400 Message-Id: <7.0.1.0.0.20060710230810.03d3d130@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 10 Jul 2006 23:16:42 -0400 To: sip@ietf.org From: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b5711207249f4a11fddf0b4d1a368809ba1157c65d56063a1f39596350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 142.131.134.137 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Sip] Outbound: Stunning who? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I was chatting with folks about this debate on when it is okay to send STUN messages. An interesting point was raised. In describing the STUN processing (section 7.1) the draft says "When a URI is created that refers to a SIP device that supports STUN as described in this section, the keepalive URI parameter, as defined in Section 10 MUST be added to the URI, with a value of 'stun'. This allows a UA to inspect the URI to decide if it should attempt to send STUN requests to this location." Presumably, the URI under discussion here is the same URI as discussed earlier, namely the sip URI of the outbound proxy. This is consistent with the discussion on the list about the use of supported: outbound indicating support for STUN. supported: outbound is put in a response by the outbound proxy (registrar.) However, the document is quite clear that a normal deployment is one with an edge proxy between the UAC and the outbound proxy. If I understand right, the outbound proxy URI points to the outbound proxy, not the edge proxy. And the supported header is put on by the outbound proxy, not the edge proxy. The only problem is that if the UAC sends STUN packets, in the presence of an edge proxy, those STUN packets will be addressed to, and (if they arrive) be consumed by the edge proxy. In other words, the entity which needs to support STUN is not the entity identified by the URI with the keepalive=stun parameter, nor is it the entity which placed the support: outbound in the header. Whatever one thinks about the safety of sending STUN based on a configured parameter, that configuration ought to relate to the server to which the STUN is being sent. As far as I can tell, the desire for and verification of STUN usage ought to be a matter between the UAC and the edge proxy, and ought not be tied up with the outbound URI or the behavior of the outbound proxy. Feel free to tell me I have missed the point, Joel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 10 23:38:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0935-0000rv-4o; Mon, 10 Jul 2006 23:36:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0933-0000qO-LF for sip@ietf.org; Mon, 10 Jul 2006 23:36:33 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0931-0004CC-9h for sip@ietf.org; Mon, 10 Jul 2006 23:36:33 -0400 Received: from [142.131.134.158] ([142.131.134.158]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6B3c70e011276 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 10 Jul 2006 22:38:20 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip@ietf.org From: Dean Willis Date: Mon, 10 Jul 2006 22:35:46 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] Wacky-thread sipsec ad-hoc X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Marcia has arranged us a smallish room - seats for about 35 people -- on Wednesday afternoon at 1520 (after SIP). On the agenda: draft-gurbani-sip-sipsec-00.txt draft-srivastava-sip-e2e-ciphersuites-00 and more on: draft-audet-sip-sips-guidelines-02 What I'd like to achieve here: a better understanding of the security properties we either want or thought we had (but don't actually have) with sips:. -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 03:30:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0CfL-0008I0-KL; Tue, 11 Jul 2006 03:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0CfK-0008Hv-P7 for sip@ietf.org; Tue, 11 Jul 2006 03:28:18 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0CfK-0001CE-A6 for sip@ietf.org; Tue, 11 Jul 2006 03:28:18 -0400 Received: (qmail 24995 invoked by uid 0); 11 Jul 2006 07:28:16 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 11 Jul 2006 07:28:16 -0000 Message-ID: <001101c6a4bb$936de410$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: , "Joel M. Halpern" References: <7.0.1.0.0.20060710230810.03d3d130@stevecrocker.com> Subject: Re: [Sip] Outbound: Stunning who? Date: Tue, 11 Jul 2006 09:28:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Joel, see inline Regards, Jeroen ----- Original Message ----- From: "Joel M. Halpern" To: Sent: Tuesday, July 11, 2006 5:16 AM Subject: [Sip] Outbound: Stunning who? >I was chatting with folks about this debate on when it is okay to send STUN >messages. > An interesting point was raised. > > In describing the STUN processing (section 7.1) the draft says "When a URI > is created that refers to a SIP device that supports STUN as described in > this section, the keepalive URI parameter, as defined in Section 10 MUST > be added to the URI, with a value of 'stun'. This allows a UA to inspect > the URI to decide if it should attempt to send STUN requests to this > location." > Presumably, the URI under discussion here is the same URI as discussed > earlier, namely the sip URI of the outbound proxy. This is consistent > with the discussion on the list about the use of supported: outbound > indicating support for STUN. supported: outbound is put in a response by > the outbound proxy (registrar.) > > However, the document is quite clear that a normal deployment is one with > an edge proxy between the UAC and the outbound proxy. If I understand > right, the outbound proxy URI points to the outbound proxy, not the edge > proxy. And the supported header is put on by the outbound proxy, not the > edge proxy. > An "outbound proxy URI" would refer to the outbound proxy, which can be either an edge proxy or a "home proxy" (ie the proxy associated with the registrar). The URI that is being talked about in section 7.1 refers to a "SIP device [...] as describe in this section", which "include a Registrar and an Edge proxy". It purposefully leaves both options open. Interestingly, early drafts of RFC3263 defined an "outbound proxy" as "a specific server, independent of the URI", but the term was removed from the final version of that RFC. Section 2.1 of the outbound draft should really include a definition of "outbound proxy", but the intention is that it can mean both depending on deployment. The supported header is inserted by the *registrar*, which is (associated with) the outbound proxy if there are no edge proxies. I think for clarity, we should also come up with a term for the "proxy associated with the registrar" (and add that to section 2.1 too) > The only problem is that if the UAC sends STUN packets, in the presence of > an edge proxy, those STUN packets will be addressed to, and (if they > arrive) be consumed by the edge proxy. In other words, the entity which > needs to support STUN is not the entity identified by the URI with the > keepalive=stun parameter, nor is it the entity which placed the support: > outbound in the header. Whatever one thinks about the safety of sending > STUN based on a configured parameter, that configuration ought to relate > to the server to which the STUN is being sent. > > As far as I can tell, the desire for and verification of STUN usage ought > to be a matter between the UAC and the edge proxy, and ought not be tied > up with the outbound URI or the behavior of the outbound proxy. > Edge proxies *are* outbound proxies, the "home proxy" is the outbound proxy when there are no edge proxies > Feel free to tell me I have missed the point, > Joel > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 07:23:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0GJ4-00066m-70; Tue, 11 Jul 2006 07:21:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0GJ2-00066g-8d for sip@ietf.org; Tue, 11 Jul 2006 07:21:32 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0GJ0-0004Ad-Tj for sip@ietf.org; Tue, 11 Jul 2006 07:21:32 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2006 04:21:31 -0700 X-IronPort-AV: i="4.06,227,1149490800"; d="scan'208"; a="328275276:sNHT32714452" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k6BBLUnf029428 for ; Tue, 11 Jul 2006 04:21:30 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6BBLUsT027698 for ; Tue, 11 Jul 2006 04:21:30 -0700 (PDT) Received: from [142.131.134.224] (sjc-vpn4-774.cisco.com [10.21.83.5]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k6BBFVY7003654 for ; Tue, 11 Jul 2006 04:15:32 -0700 In-Reply-To: <001101c6a4bb$936de410$31713b51@BEMBUSTER> References: <7.0.1.0.0.20060710230810.03d3d130@stevecrocker.com> <001101c6a4bb$936de410$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <438232A5-FDA9-4012-902D-3A15A7573D35@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] Outbound: Stunning who? Date: Tue, 11 Jul 2006 07:21:22 -0400 To: IETF SIP List X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-3.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3156; t=1152616890; x=1153480890; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[Sip]=20Outbound=3A=20Stunning=20who?; X=v=3Dcisco.com=3B=20h=3DuZAIEOUE0xAvLVaNsDdsJ7uYPqQ=3D; b=Jcc2JsVdPVK7oT00HUbFBMnPvKKm5zaQEQRp2/LGZdAPmeMhlf746nim5jyy5w/wpe7NZnkr 00OiPce7/2HpRg0f8U01kIDu/aB0LdyGDUcSGWlQQcNJhNfcLncKDnlD; X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 11, 2006, at 3:28 AM, Jeroen van Bemmel wrote: > Joel, > > see inline > [snip] >> The only problem is that if the UAC sends STUN packets, in the >> presence of an edge proxy, those STUN packets will be addressed >> to, and (if they arrive) be consumed by the edge proxy. In other >> words, the entity which needs to support STUN is not the entity >> identified by the URI with the keepalive=stun parameter, nor is it >> the entity which placed the support: outbound in the header. >> Whatever one thinks about the safety of sending STUN based on a >> configured parameter, that configuration ought to relate to the >> server to which the STUN is being sent. >> >> As far as I can tell, the desire for and verification of STUN >> usage ought to be a matter between the UAC and the edge proxy, and >> ought not be tied up with the outbound URI or the behavior of the >> outbound proxy. >> > > Edge proxies *are* outbound proxies, the "home proxy" is the > outbound proxy when there are no edge proxies > Needless to say, I find this incredibly confusing. It's clear Joel does too. I wonder how many other people are wandering around in this maze as badly as I am. I thought this whole effort was about managing transport connections from UAs to the "SIP cloud" such that the user doesn't lose service because SIP routing can't figure out how to get requests destined for the UA to the proxy that happens to have the transport connection to the UA at this moment. If I'm misinformed on this, I suspect some other folks are too. >> Feel free to tell me I have missed the point, If you missed the point, I missed the point... I'll quickly comment that when I looked over outbound again last night, I got the distinct impression that MOST of the complexity is due to trying to solve one particular use case - the UA wants to maintain transport connections to proxies in different domains and be able to receive calls whichever of the connections (and hence whichever of those doimains) happens to be working. I once worked out a pretty simple scheme (at least one I think is much simpler than outbound) for the case where all that's needed is redundant transport connectivity to the UA from proxies in the same edge proxy farm. (I described this to Dean late last night and I think he got it, so maybe there's somebody else who shared my hallucination here). Dave Oran. >> Joel >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 08:09:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0H1l-00038V-W3; Tue, 11 Jul 2006 08:07:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0H1k-00038N-6e for sip@ietf.org; Tue, 11 Jul 2006 08:07:44 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0H1i-0007va-P3 for sip@ietf.org; Tue, 11 Jul 2006 08:07:44 -0400 Received: from [142.131.134.137] (helo=JMHLap3.stevecrocker.com) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1G0H1i-00049H-1I; Tue, 11 Jul 2006 08:07:42 -0400 Message-Id: <7.0.1.0.0.20060711074824.03d8aca0@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 11 Jul 2006 08:07:36 -0400 To: "Jeroen van Bemmel" , From: "Joel M. Halpern" Subject: Re: [Sip] Outbound: Stunning who? In-Reply-To: <001101c6a4bb$936de410$31713b51@BEMBUSTER> References: <7.0.1.0.0.20060710230810.03d3d130@stevecrocker.com> <001101c6a4bb$936de410$31713b51@BEMBUSTER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120935d3b7e8aa68d05784310362ecabfb647f3766457075bf4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 142.131.134.137 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Your description below of the entities involved, and of the outbound proxy being an edge proxy or a home proxy is technically correct. An Outbound proxy may be an edge proxy. But as I read the document, there may be an edge proxy which is not an outbound proxy in between. The draft talks about the outbound set, and about the registration being targeted at the elements of the outbound set. As such, the elements of the outbound set (the outbound proxies, the URIs that are known to the UAC) are clearly the registrars. The draft explicitly introduces the notion that the edge proxy may be between the UAC and the registrar. The registrar is the entity who fills in supported: outbound. Not edge proxy. It is true that the definitions section states that the outbound proxy set are the proxies with which the UAC will attempt to maintain a direct flow. But it states that these are "often Edge Proxies". Presumably, they are sometimes not edge proxies. When they are not edge proxies, there presumably is an edge proxy between the UAC and the outbound proxy. The whole wording makes it clear that one registers with the elements of the outbound set. Yours, Joel M. Halpern PS: If Outbound is really supposed to be about finding and using the first proxy, rather than the registrar, then that proxy ought to be the one that has to support outbound. Alternatively (and more usefully), the mechanisms for supporting STUN ought to be tied to ones first proxy, rather than to ones registrar, while outbound talks about finding and talking to suitable registrars. At 03:28 AM 7/11/2006, Jeroen van Bemmel wrote: >Joel, > >see inline > >Regards, > >Jeroen > >----- Original Message ----- From: "Joel M. Halpern" >To: >Sent: Tuesday, July 11, 2006 5:16 AM >Subject: [Sip] Outbound: Stunning who? > > >>I was chatting with folks about this debate on when it is okay to >>send STUN messages. >>An interesting point was raised. >> >>In describing the STUN processing (section 7.1) the draft says >>"When a URI is created that refers to a SIP device that supports >>STUN as described in this section, the keepalive URI parameter, as >>defined in Section 10 MUST be added to the URI, with a value of >>'stun'. This allows a UA to inspect the URI to decide if it should >>attempt to send STUN requests to this location." >>Presumably, the URI under discussion here is the same URI as >>discussed earlier, namely the sip URI of the outbound proxy. This >>is consistent with the discussion on the list about the use of >>supported: outbound indicating support for STUN. supported: >>outbound is put in a response by the outbound proxy (registrar.) >> >>However, the document is quite clear that a normal deployment is >>one with an edge proxy between the UAC and the outbound proxy. If >>I understand right, the outbound proxy URI points to the outbound >>proxy, not the edge proxy. And the supported header is put on by >>the outbound proxy, not the edge proxy. > >An "outbound proxy URI" would refer to the outbound proxy, which can >be either an edge proxy or a "home proxy" (ie the proxy associated >with the registrar). The URI that is being talked about in section >7.1 refers to a "SIP device [...] as describe in this section", >which "include a Registrar and an Edge proxy". It purposefully >leaves both options open. > >Interestingly, early drafts of RFC3263 defined an "outbound proxy" >as "a specific server, independent of the URI", but the term was >removed from the final version of that RFC. > >Section 2.1 of the outbound draft should really include a definition >of "outbound proxy", but the intention is that it can mean both >depending on deployment. The supported header is inserted by the >*registrar*, which is (associated with) the outbound proxy if there >are no edge proxies. > >I think for clarity, we should also come up with a term for the >"proxy associated with the registrar" (and add that to section 2.1 too) > >>The only problem is that if the UAC sends STUN packets, in the >>presence of an edge proxy, those STUN packets will be addressed to, >>and (if they arrive) be consumed by the edge proxy. In other >>words, the entity which needs to support STUN is not the entity >>identified by the URI with the keepalive=stun parameter, nor is it >>the entity which placed the support: outbound in the >>header. Whatever one thinks about the safety of sending STUN based >>on a configured parameter, that configuration ought to relate to >>the server to which the STUN is being sent. >> >>As far as I can tell, the desire for and verification of STUN usage >>ought to be a matter between the UAC and the edge proxy, and ought >>not be tied up with the outbound URI or the behavior of the outbound proxy. > >Edge proxies *are* outbound proxies, the "home proxy" is the >outbound proxy when there are no edge proxies > >>Feel free to tell me I have missed the point, >>Joel >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 10:45:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0JSs-0002qx-Hb; Tue, 11 Jul 2006 10:43:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0JSr-0002p1-5K for sip@ietf.org; Tue, 11 Jul 2006 10:43:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0JSr-0005j4-3o for sip@ietf.org; Tue, 11 Jul 2006 10:43:53 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0JLt-0006yK-By for sip@ietf.org; Tue, 11 Jul 2006 10:36:43 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 11 Jul 2006 07:36:40 -0700 X-IronPort-AV: i="4.06,229,1149490800"; d="scan'208"; a="304852581:sNHT31514040" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k6BEaefD018677; Tue, 11 Jul 2006 07:36:40 -0700 Received: from [132.219.6.214] (sjc-vpn4-516.cisco.com [10.21.82.4]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6BEadfr025576; Tue, 11 Jul 2006 07:36:40 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Wacky-thread sipsec ad-hoc Date: Tue, 11 Jul 2006 10:36:33 -0400 To: Dean Willis X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1143; t=1152628600; x=1153492600; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Wacky-thread=20sipsec=20ad-hoc; X=v=3Dcisco.com=3B=20h=3DjWM4OBbwHt/jdmT+mCUrttvMw80=3D; b=CyMQfda4ar2mRRk7U424K+0qOgfwbuDPhKeCrCSFCAr76fZFJ/07CZ8felcLWAyuK9jeOExr vsMKNrTG+xyz+w9hBED3VKHr0tLNW116wTOxUvWX9ndivl/BbleN7zvj; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.4 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'd like to put in a request for some time at the beginning to frame two key things that might help frame the rest of the discussion.... 1) Requirements^H^H^H^H^H Thinks we want around having a "Lock Icon" on phone 2) A path out of the sips swamp that we are swimming in Cullen On Jul 10, 2006, at 11:35 PM, Dean Willis wrote: > > Marcia has arranged us a smallish room - seats for about 35 people > -- on Wednesday afternoon at 1520 (after SIP). > > On the agenda: > > draft-gurbani-sip-sipsec-00.txt > draft-srivastava-sip-e2e-ciphersuites-00 > and more on: > draft-audet-sip-sips-guidelines-02 > > What I'd like to achieve here: a better understanding of the > security properties we either want or thought we had (but don't > actually have) with sips:. > > -- > dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 11:06:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Jmv-0002CT-7M; Tue, 11 Jul 2006 11:04:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Jmt-0002CL-18 for sip@ietf.org; Tue, 11 Jul 2006 11:04:35 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Jmr-0006Xv-Jx for sip@ietf.org; Tue, 11 Jul 2006 11:04:35 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2006 08:04:31 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,229,1149490800"; d="scan'208"; a="31791824:sNHT27209156" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6BF4ViW020661 for ; Tue, 11 Jul 2006 11:04:31 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6BF4VdU000131 for ; Tue, 11 Jul 2006 11:04:31 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 11:04:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: Stunning who? Date: Tue, 11 Jul 2006 11:04:30 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301AC0465@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Stunning who? Thread-Index: Acak3DunHQkTdu8LQaCYBm+8ESfklwAHajGA From: "Michael Hammer \(mhammer\)" To: "Dave Oran \(oran\)" , "IETF SIP List" X-OriginalArrivalTime: 11 Jul 2006 15:04:31.0289 (UTC) FILETIME=[50050290:01C6A4FB] DKIM-Signature: a=rsa-sha1; q=dns; l=4503; t=1152630271; x=1153494271; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Outbound=3A=20Stunning=20who? |To:=22Dave=20Oran=20\(oran\)=22=20, =20=22IETF=20SIP=20List= 22=20; X=v=3Dcisco.com=3B=20h=3DmJ8FhcRV09qcYLvcSvG86opAfrw=3D; b=TKJuJLCiW29Fh5jqBz1cCTlt0eCc2yEE6lWTkQ8yNSg+8pJx2AHUA+4NE46MgzYsfmEkYWu3 8PlbBpNBLsBNibKLXm8FfpQtaG06ojrmo9s3e2QXzsALZKf5S+GtoRQt; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dave, I think there are 3 possible topologies: R=3Dregistrar E=3Dedge O=3Doutbound C=3Dclient +-+ +-+ +-+ |R| |R| |R| home | | +-+ +-+ | | | | | | +-+ +-+ |E| |E| |E| home | | | | +-+=20 | | | | | | | | | +-+ |O| |O| |O| visited +-+ +-+ +-+=20 | | | +-+ +-+ +-+ |C| |C| |C| +-+ +-+ +-+ 1 2 3 1=3Dmonolithic proxy 2=3Dhome network IMS 3=3Dvisited network IMS Confusion may depend on which picture people have in their head at the moment. All, feel free to correct or modify if I missed something. Mike =20 > -----Original Message----- > From: Dave Oran (oran)=20 > Sent: Tuesday, July 11, 2006 7:21 AM > To: IETF SIP List > Subject: Re: [Sip] Outbound: Stunning who? >=20 >=20 > On Jul 11, 2006, at 3:28 AM, Jeroen van Bemmel wrote: >=20 > > Joel, > > > > see inline > > > [snip] > >> The only problem is that if the UAC sends STUN packets, in the=20 > >> presence of an edge proxy, those STUN packets will be=20 > addressed to,=20 > >> and (if they arrive) be consumed by the edge proxy. In=20 > other words,=20 > >> the entity which needs to support STUN is not the entity=20 > identified=20 > >> by the URI with the keepalive=3Dstun parameter, nor is it > >> the entity which placed the support: outbound in the header. =20 > >> Whatever one thinks about the safety of sending STUN based on a=20 > >> configured parameter, that configuration ought to relate to the=20 > >> server to which the STUN is being sent. > >> > >> As far as I can tell, the desire for and verification of=20 > STUN usage=20 > >> ought to be a matter between the UAC and the edge proxy, and ought=20 > >> not be tied up with the outbound URI or the behavior of=20 > the outbound=20 > >> proxy. > >> > > > > Edge proxies *are* outbound proxies, the "home proxy" is=20 > the outbound=20 > > proxy when there are no edge proxies > > > Needless to say, I find this incredibly confusing. It's clear=20 > Joel does too. I wonder how many other people are wandering=20 > around in this maze as badly as I am. >=20 > I thought this whole effort was about managing transport=20 > connections from UAs to the "SIP cloud" such that the user=20 > doesn't lose service because SIP routing can't figure out how=20 > to get requests destined for the UA to the proxy that happens=20 > to have the transport connection to the UA at this moment. >=20 > If I'm misinformed on this, I suspect some other folks are too. >=20 > >> Feel free to tell me I have missed the point, > If you missed the point, I missed the point... >=20 > I'll quickly comment that when I looked over outbound again=20 > last night, I got the distinct impression that MOST of the=20 > complexity is due to trying to solve one particular use case=20 > - the UA wants to maintain transport connections to proxies=20 > in different domains and be able to receive calls whichever=20 > of the connections (and hence whichever of those doimains)=20 > happens to be working. >=20 > I once worked out a pretty simple scheme (at least one I=20 > think is much simpler than outbound) for the case where all=20 > that's needed is redundant transport connectivity to the UA=20 > from proxies in the same edge proxy farm. (I described this=20 > to Dean late last night and I think he got it, so maybe=20 > there's somebody else who shared my hallucination here). >=20 > Dave Oran. >=20 > >> Joel > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 12:46:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0LM0-0004wr-BZ; Tue, 11 Jul 2006 12:44:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0LLy-0004wh-Vx for sip@ietf.org; Tue, 11 Jul 2006 12:44:54 -0400 Received: from mail.shinkuro.com ([216.194.124.237] helo=execdsl.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0LLy-0005fT-HI for sip@ietf.org; Tue, 11 Jul 2006 12:44:54 -0400 Received: from [132.219.4.230] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 13392171; Tue, 11 Jul 2006 10:42:10 -0600 Message-Id: <7.0.1.0.0.20060711124106.03339838@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 11 Jul 2006 12:44:50 -0400 To: "Michael Hammer \(mhammer\)" , "IETF SIP List" From: "Joel M. Halpern" Subject: RE: [Sip] Outbound: Stunning who? In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301AC0465@xmb-rtp-20b.amer. cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E301AC0465@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That's interesting, but does not align with how I read the outbound draft. The proxies identified as the "outbound set" (which are presumably the outbound proxies) are teh targets of the registration requests from the user. Hence, I believe the outbound proxies are intended to be the registrars. And the Edge Proxy is specifically stated to be the first proxy from the user. Whatever else is going on, if different readers are getting pictures this disparate from the draft, we need to clarify the draft. Yours, Joel PS: There is actually an assumption in all of this that the first proxy is outside of ones NAT. Otherwise, the client can not STUN anyone, since the entity he has an IP address for, his first proxy, would also be inside the NAT boundary. At 11:04 AM 7/11/2006, Michael Hammer \(mhammer\) wrote: >Dave, > >I think there are 3 possible topologies: >R=registrar >E=edge >O=outbound >C=client > >+-+ +-+ +-+ >|R| |R| |R| home >| | +-+ +-+ >| | | | >| | +-+ +-+ >|E| |E| |E| home >| | | | +-+ >| | | | | >| | | | +-+ >|O| |O| |O| visited >+-+ +-+ +-+ > | | | >+-+ +-+ +-+ >|C| |C| |C| >+-+ +-+ +-+ > 1 2 3 > >1=monolithic proxy >2=home network IMS >3=visited network IMS > >Confusion may depend on which picture people have in their head at the >moment. > >All, feel free to correct or modify if I missed something. > >Mike > > > > -----Original Message----- > > From: Dave Oran (oran) > > Sent: Tuesday, July 11, 2006 7:21 AM > > To: IETF SIP List > > Subject: Re: [Sip] Outbound: Stunning who? > > > > > > On Jul 11, 2006, at 3:28 AM, Jeroen van Bemmel wrote: > > > > > Joel, > > > > > > see inline > > > > > [snip] > > >> The only problem is that if the UAC sends STUN packets, in the > > >> presence of an edge proxy, those STUN packets will be > > addressed to, > > >> and (if they arrive) be consumed by the edge proxy. In > > other words, > > >> the entity which needs to support STUN is not the entity > > identified > > >> by the URI with the keepalive=stun parameter, nor is it > > >> the entity which placed the support: outbound in the header. > > >> Whatever one thinks about the safety of sending STUN based on a > > >> configured parameter, that configuration ought to relate to the > > >> server to which the STUN is being sent. > > >> > > >> As far as I can tell, the desire for and verification of > > STUN usage > > >> ought to be a matter between the UAC and the edge proxy, and ought > > >> not be tied up with the outbound URI or the behavior of > > the outbound > > >> proxy. > > >> > > > > > > Edge proxies *are* outbound proxies, the "home proxy" is > > the outbound > > > proxy when there are no edge proxies > > > > > Needless to say, I find this incredibly confusing. It's clear > > Joel does too. I wonder how many other people are wandering > > around in this maze as badly as I am. > > > > I thought this whole effort was about managing transport > > connections from UAs to the "SIP cloud" such that the user > > doesn't lose service because SIP routing can't figure out how > > to get requests destined for the UA to the proxy that happens > > to have the transport connection to the UA at this moment. > > > > If I'm misinformed on this, I suspect some other folks are too. > > > > >> Feel free to tell me I have missed the point, > > If you missed the point, I missed the point... > > > > I'll quickly comment that when I looked over outbound again > > last night, I got the distinct impression that MOST of the > > complexity is due to trying to solve one particular use case > > - the UA wants to maintain transport connections to proxies > > in different domains and be able to receive calls whichever > > of the connections (and hence whichever of those doimains) > > happens to be working. > > > > I once worked out a pretty simple scheme (at least one I > > think is much simpler than outbound) for the case where all > > that's needed is redundant transport connectivity to the UA > > from proxies in the same edge proxy farm. (I described this > > to Dean late last night and I think he got it, so maybe > > there's somebody else who shared my hallucination here). > > > > Dave Oran. > > > > >> Joel > > >> > > >> > > >> _______________________________________________ > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol Use > > >> sip-implementors@cs.columbia.edu for questions on current sip Use > > >> sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 13:38:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0M9f-0000JJ-3T; Tue, 11 Jul 2006 13:36:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0M9d-0000JE-8O for sip@ietf.org; Tue, 11 Jul 2006 13:36:13 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0M9c-0001w3-2n for sip@ietf.org; Tue, 11 Jul 2006 13:36:13 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <20060711173611014004ju0te>; Tue, 11 Jul 2006 17:36:11 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k6BHaAN1015553 for ; Tue, 11 Jul 2006 13:36:10 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k6BHaAEA015549; Tue, 11 Jul 2006 13:36:10 -0400 Date: Tue, 11 Jul 2006 13:36:10 -0400 Message-Id: <200607111736.k6BHaAEA015549@dragon.ariadne.com> From: Dale.Worley@comcast.net To: sip@ietf.org In-reply-to: (jason@counterpath.com) Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates References: <002401c693c8$aab13400$31713b51@BEMBUSTER> <4497EAE7.9090700@cisco.com> <44985514.4010107@cisco.com> <002f01c694ad$3c5479a0$31713b51@BEMBUSTER> <669459C0-169D-42AF-B59A-0F81AB5C2339@cisco.com> <002501c6995b$1c3002e0$31713b51@BEMBUSTER> X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Jason Fischl" > On the using a GRUU in a cert, would need to consider that any time > my GRUU changes I need to generate a new cert - if this meant a new > private/public key pair, this might be expensive. Also consider that GRUUs will change relatively frequently for devices. Why would GRUUs change "relatively frequently"? They can change only as frequently as the AOR changes, or the instance-id changes. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 14:58:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NPV-0001Iw-Ac; Tue, 11 Jul 2006 14:56:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NPU-0001Ir-74 for sip@ietf.org; Tue, 11 Jul 2006 14:56:40 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0NPS-0004aE-IX for sip@ietf.org; Tue, 11 Jul 2006 14:56:40 -0400 Received: (qmail 23893 invoked by uid 0); 11 Jul 2006 18:56:36 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 11 Jul 2006 18:56:36 -0000 Message-ID: <002401c6a51b$bb9df870$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Michael Hammer \(mhammer\)" , "IETF SIP List" , "Joel M. Halpern" References: <072C5B76F7CEAB488172C6F64B30B5E301AC0465@xmb-rtp-20b.amer.cisco.com> <7.0.1.0.0.20060711124106.03339838@stevecrocker.com> Subject: Re: [Sip] Outbound: Stunning who? Date: Tue, 11 Jul 2006 20:56:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Joel, > That's interesting, but does not align with how I read the outbound draft. > The proxies identified as the "outbound set" (which are presumably the > outbound proxies) are teh targets of the registration requests from the > user. Hence, I believe the outbound proxies are intended to be the > registrars. No, the registration requests are targeted at the home domain as usual (ie request URI == domain from AoR). Any discovered URI is added as the topmost Route header, it is the first hop but not (necessarily) the final destination of the REGISTER. That being said, there seems something wrong with the text in section 4.2. When interpreted literally, it reads as if the UA would always have an outbound-proxy-set with at least 2 entries, making the example given in section 3.2 (direct registration) impossible (because there would "typically" be a Route header). I think the text should say "UAs obtain at configuration time *zero* or more SIP URIs representing the default outbound-proxy-set." to allow for this case > And the Edge Proxy is specifically stated to be the first proxy from the > user. > > Whatever else is going on, if different readers are getting pictures this > disparate from the draft, we need to clarify the draft. > > Yours, > Joel > > PS: There is actually an assumption in all of this that the first proxy is > outside of ones NAT. Otherwise, the client can not STUN anyone, since the > entity he has an IP address for, his first proxy, would also be inside the > NAT boundary. > That is the assumption / limitation that the outbound draft makes: if there is NAT, it is located between the UA and the proxy to which the discovered outbound URI resolves. Regards, jeroen > At 11:04 AM 7/11/2006, Michael Hammer \(mhammer\) wrote: >>Dave, >> >>I think there are 3 possible topologies: >>R=registrar >>E=edge >>O=outbound >>C=client >> >>+-+ +-+ +-+ >>|R| |R| |R| home >>| | +-+ +-+ >>| | | | >>| | +-+ +-+ >>|E| |E| |E| home >>| | | | +-+ >>| | | | | >>| | | | +-+ >>|O| |O| |O| visited >>+-+ +-+ +-+ >> | | | >>+-+ +-+ +-+ >>|C| |C| |C| >>+-+ +-+ +-+ >> 1 2 3 >> >>1=monolithic proxy >>2=home network IMS >>3=visited network IMS >> >>Confusion may depend on which picture people have in their head at the >>moment. >> >>All, feel free to correct or modify if I missed something. >> >>Mike >> >> >> > -----Original Message----- >> > From: Dave Oran (oran) >> > Sent: Tuesday, July 11, 2006 7:21 AM >> > To: IETF SIP List >> > Subject: Re: [Sip] Outbound: Stunning who? >> > >> > >> > On Jul 11, 2006, at 3:28 AM, Jeroen van Bemmel wrote: >> > >> > > Joel, >> > > >> > > see inline >> > > >> > [snip] >> > >> The only problem is that if the UAC sends STUN packets, in the >> > >> presence of an edge proxy, those STUN packets will be >> > addressed to, >> > >> and (if they arrive) be consumed by the edge proxy. In >> > other words, >> > >> the entity which needs to support STUN is not the entity >> > identified >> > >> by the URI with the keepalive=stun parameter, nor is it >> > >> the entity which placed the support: outbound in the header. >> > >> Whatever one thinks about the safety of sending STUN based on a >> > >> configured parameter, that configuration ought to relate to the >> > >> server to which the STUN is being sent. >> > >> >> > >> As far as I can tell, the desire for and verification of >> > STUN usage >> > >> ought to be a matter between the UAC and the edge proxy, and ought >> > >> not be tied up with the outbound URI or the behavior of >> > the outbound >> > >> proxy. >> > >> >> > > >> > > Edge proxies *are* outbound proxies, the "home proxy" is >> > the outbound >> > > proxy when there are no edge proxies >> > > >> > Needless to say, I find this incredibly confusing. It's clear >> > Joel does too. I wonder how many other people are wandering >> > around in this maze as badly as I am. >> > >> > I thought this whole effort was about managing transport >> > connections from UAs to the "SIP cloud" such that the user >> > doesn't lose service because SIP routing can't figure out how >> > to get requests destined for the UA to the proxy that happens >> > to have the transport connection to the UA at this moment. >> > >> > If I'm misinformed on this, I suspect some other folks are too. >> > >> > >> Feel free to tell me I have missed the point, >> > If you missed the point, I missed the point... >> > >> > I'll quickly comment that when I looked over outbound again >> > last night, I got the distinct impression that MOST of the >> > complexity is due to trying to solve one particular use case >> > - the UA wants to maintain transport connections to proxies >> > in different domains and be able to receive calls whichever >> > of the connections (and hence whichever of those doimains) >> > happens to be working. >> > >> > I once worked out a pretty simple scheme (at least one I >> > think is much simpler than outbound) for the case where all >> > that's needed is redundant transport connectivity to the UA >> > from proxies in the same edge proxy farm. (I described this >> > to Dean late last night and I think he got it, so maybe >> > there's somebody else who shared my hallucination here). >> > >> > Dave Oran. >> > >> > >> Joel >> > >> >> > >> >> > >> _______________________________________________ >> > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > >> This list is for NEW development of the core SIP Protocol Use >> > >> sip-implementors@cs.columbia.edu for questions on current sip Use >> > >> sipping@ietf.org for new developments on the application of sip >> > > >> > > >> > > _______________________________________________ >> > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > > This list is for NEW development of the core SIP Protocol Use >> > > sip-implementors@cs.columbia.edu for questions on current sip Use >> > > sipping@ietf.org for new developments on the application of sip >> > >> > _______________________________________________ >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol Use >> > sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> > >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 16:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OV5-0003BW-Ac; Tue, 11 Jul 2006 16:06:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OV3-0003BO-NY for sip@ietf.org; Tue, 11 Jul 2006 16:06:29 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0OV1-0005D4-70 for sip@ietf.org; Tue, 11 Jul 2006 16:06:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2006 12:23:02 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,230,1149490800"; d="scan'208"; a="31842657:sNHT28979516" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6BJN1F6022591; Tue, 11 Jul 2006 15:23:01 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6BJN1LY007326; Tue, 11 Jul 2006 12:23:01 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 15:22:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: Stunning who? Date: Tue, 11 Jul 2006 15:22:56 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301AC05B3@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Stunning who? Thread-Index: AcalCVp2MSo32LFQQaiCBxuVoDeqnQAE+p6w From: "Michael Hammer \(mhammer\)" To: "Joel M. Halpern" , "IETF SIP List" X-OriginalArrivalTime: 11 Jul 2006 19:22:57.0393 (UTC) FILETIME=[6A60B610:01C6A51F] DKIM-Signature: a=rsa-sha1; q=dns; l=7541; t=1152645781; x=1153509781; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Outbound=3A=20Stunning=20who? |To:=22Joel=20M.=20Halpern=22=20, =20=22IETF=20SIP=20L ist=22=20; X=v=3Dcisco.com=3B=20h=3DmJ8FhcRV09qcYLvcSvG86opAfrw=3D; b=zUILchvodlToThu6/1lEQ7h+OjetEUNtbtXnNqIbTACTLHEuM786eIsx5ri/WEPHz1z8dCAJ OizlGLb5sCloMo5YhCjbEIpHwXSpKx6R2cmtcSz6OhkcXzFEFbrN+AqK; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I probably switched the E's and the O's, but that is why I threw this out there, because this was the picture that came to mind from reading the email thread. Actually, the third possibility may be the one tripping up the words. Case 1 is monolithic and likely in the home network only Case 2 may allow for the O/E proxy to be either in a home or visited network. Does it matter? Case 3 may need more explanation in the draft. Is the following the correct picture? Maybe my E and O are synonymous and the O proxy should be labeled something else. R=3Dregistrar E=3Dedge O=3Doutbound C=3Dclient +-+ +-+ +-+ |R| |R| |R| home | | +-+ +-+ | | | | | | +-+ +-+ |O| |O| |O| home | | | | +-+ | | | | | | | | | +-+ |E| |E| |E| visited +-+ +-+ +-+ | | | +-+ +-+ +-+ |C| |C| |C| +-+ +-+ +-+ 1 2 3 1=3Dmonolithic proxy 2=3Dhome network IMS 3=3Dvisited network IMS If we can't draw the picture, we probably don't know what we mean. =20 If this is wrong, please draw me another picture. Mike =20 > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 > Sent: Tuesday, July 11, 2006 12:45 PM > To: Michael Hammer (mhammer); IETF SIP List > Subject: RE: [Sip] Outbound: Stunning who? >=20 > That's interesting, but does not align with how I read the=20 > outbound draft. > The proxies identified as the "outbound set" (which are=20 > presumably the outbound proxies) are teh targets of the=20 > registration requests from the user. Hence, I believe the=20 > outbound proxies are intended to be the registrars. > And the Edge Proxy is specifically stated to be the first=20 > proxy from the user. >=20 > Whatever else is going on, if different readers are getting=20 > pictures this disparate from the draft, we need to clarify the draft. >=20 > Yours, > Joel >=20 > PS: There is actually an assumption in all of this that the=20 > first proxy is outside of ones NAT. Otherwise, the client=20 > can not STUN anyone, since the entity he has an IP address=20 > for, his first proxy, would also be inside the NAT boundary. >=20 > At 11:04 AM 7/11/2006, Michael Hammer \(mhammer\) wrote: > >Dave, > > > >I think there are 3 possible topologies: > >R=3Dregistrar > >E=3Dedge > >O=3Doutbound > >C=3Dclient > > > >+-+ +-+ +-+ > >|R| |R| |R| home > >| | +-+ +-+ > >| | | | > >| | +-+ +-+ > >|E| |E| |E| home > >| | | | +-+ > >| | | | | > >| | | | +-+ > >|O| |O| |O| visited > >+-+ +-+ +-+ > > | | | > >+-+ +-+ +-+ > >|C| |C| |C| > >+-+ +-+ +-+ > > 1 2 3 > > > >1=3Dmonolithic proxy > >2=3Dhome network IMS > >3=3Dvisited network IMS > > > >Confusion may depend on which picture people have in their=20 > head at the=20 > >moment. > > > >All, feel free to correct or modify if I missed something. > > > >Mike > > > > > > > -----Original Message----- > > > From: Dave Oran (oran) > > > Sent: Tuesday, July 11, 2006 7:21 AM > > > To: IETF SIP List > > > Subject: Re: [Sip] Outbound: Stunning who? > > > > > > > > > On Jul 11, 2006, at 3:28 AM, Jeroen van Bemmel wrote: > > > > > > > Joel, > > > > > > > > see inline > > > > > > > [snip] > > > >> The only problem is that if the UAC sends STUN packets, in the=20 > > > >> presence of an edge proxy, those STUN packets will be > > > addressed to, > > > >> and (if they arrive) be consumed by the edge proxy. In > > > other words, > > > >> the entity which needs to support STUN is not the entity > > > identified > > > >> by the URI with the keepalive=3Dstun parameter, nor is it the=20 > > > >> entity which placed the support: outbound in the header. > > > >> Whatever one thinks about the safety of sending STUN=20 > based on a=20 > > > >> configured parameter, that configuration ought to=20 > relate to the=20 > > > >> server to which the STUN is being sent. > > > >> > > > >> As far as I can tell, the desire for and verification of > > > STUN usage > > > >> ought to be a matter between the UAC and the edge proxy, and=20 > > > >> ought not be tied up with the outbound URI or the behavior of > > > the outbound > > > >> proxy. > > > >> > > > > > > > > Edge proxies *are* outbound proxies, the "home proxy" is > > > the outbound > > > > proxy when there are no edge proxies > > > > > > > Needless to say, I find this incredibly confusing. It's=20 > clear Joel=20 > > > does too. I wonder how many other people are wandering around in=20 > > > this maze as badly as I am. > > > > > > I thought this whole effort was about managing transport=20 > connections=20 > > > from UAs to the "SIP cloud" such that the user doesn't=20 > lose service=20 > > > because SIP routing can't figure out how to get requests destined=20 > > > for the UA to the proxy that happens to have the transport=20 > > > connection to the UA at this moment. > > > > > > If I'm misinformed on this, I suspect some other folks are too. > > > > > > >> Feel free to tell me I have missed the point, > > > If you missed the point, I missed the point... > > > > > > I'll quickly comment that when I looked over outbound again last=20 > > > night, I got the distinct impression that MOST of the=20 > complexity is=20 > > > due to trying to solve one particular use case > > > - the UA wants to maintain transport connections to proxies in=20 > > > different domains and be able to receive calls whichever of the=20 > > > connections (and hence whichever of those doimains) happens to be=20 > > > working. > > > > > > I once worked out a pretty simple scheme (at least one I think is=20 > > > much simpler than outbound) for the case where all that's=20 > needed is=20 > > > redundant transport connectivity to the UA from proxies=20 > in the same=20 > > > edge proxy farm. (I described this to Dean late last night and I=20 > > > think he got it, so maybe there's somebody else who shared my=20 > > > hallucination here). > > > > > > Dave Oran. > > > > > > >> Joel > > > >> > > > >> > > > >> _______________________________________________ > > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >> This list is for NEW development of the core SIP Protocol Use=20 > > > >> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > >> sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use=20 > >sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 16:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0PCk-000076-NI; Tue, 11 Jul 2006 16:51:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0PCj-000071-Tg for sip@ietf.org; Tue, 11 Jul 2006 16:51:37 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0PCi-0002js-Ia for sip@ietf.org; Tue, 11 Jul 2006 16:51:37 -0400 Received: from [132.219.30.156] (h1e9c-net84db.lab.risq.net [132.219.30.156] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6BKrOV2016116 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 11 Jul 2006 15:53:25 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Tue, 11 Jul 2006 15:51:02 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Cullen Jennings , ekr@rtfm.com Subject: [Sip] Room# for Wacky-thread sipsec ad-hoc on Wednesday X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We have room: 518C, for Wednesday afternoon after SIP, eta 1520. It's a small room. -- Dean On Jul 10, 2006, at 10:35 PM, Dean Willis wrote: > > Marcia has arranged us a smallish room - seats for about 35 people > -- on Wednesday afternoon at 1520 (after SIP). > > On the agenda: > > draft-gurbani-sip-sipsec-00.txt > draft-srivastava-sip-e2e-ciphersuites-00 > and more on: > draft-audet-sip-sips-guidelines-02 > > What I'd like to achieve here: a better understanding of the > security properties we either want or thought we had (but don't > actually have) with sips:. > > -- > dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 16:57:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0PH6-0000tq-AF; Tue, 11 Jul 2006 16:56:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0PH4-0000tk-UY for sip@ietf.org; Tue, 11 Jul 2006 16:56:06 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0PH2-0002tr-Jy for sip@ietf.org; Tue, 11 Jul 2006 16:56:06 -0400 Received: from [132.219.30.156] (h1e9c-net84db.lab.risq.net [132.219.30.156] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6BKvqIQ016147 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 11 Jul 2006 15:57:53 -0500 In-Reply-To: <7.0.1.0.0.20060711124106.03339838@stevecrocker.com> References: <072C5B76F7CEAB488172C6F64B30B5E301AC0465@xmb-rtp-20b.amer.cisco.com> <7.0.1.0.0.20060711124106.03339838@stevecrocker.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09354CA3-6B95-47F0-B99F-A5361DB96BC7@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound: Stunning who? Date: Tue, 11 Jul 2006 15:55:30 -0500 To: "Joel M. Halpern" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 11, 2006, at 11:44 AM, Joel M. Halpern wrote: > That's interesting, but does not align with how I read the outbound > draft. > The proxies identified as the "outbound set" (which are presumably > the outbound proxies) are teh targets of the registration requests > from the user. Hence, I believe the outbound proxies are intended > to be the registrars. > And the Edge Proxy is specifically stated to be the first proxy > from the user. > > Whatever else is going on, if different readers are getting > pictures this disparate from the draft, we need to clarify the draft. Yep. I'm pretty sure I invented the term "outbound proxy" (in the sip context, at least) some years ago, but even so the way I read the draft we were ending up stunning helpless edge proxies that were between the UAs and the "outbound" proxies and had no way to complain about it. Worse than the Taser-happy Dallas police, I think. The root of the problem, I think, is that this draft intertwingles the proxy behavior (supporting stun) with the registrar behavior (supporting "outbound" parallel registrations). -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 17:11:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0PU7-0002Ma-SX; Tue, 11 Jul 2006 17:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0PU6-0002MV-Du for sip@ietf.org; Tue, 11 Jul 2006 17:09:34 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0PU5-0003mL-2I for sip@ietf.org; Tue, 11 Jul 2006 17:09:34 -0400 Received: (qmail 14408 invoked by uid 0); 11 Jul 2006 21:09:31 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 11 Jul 2006 21:09:31 -0000 Message-ID: <014b01c6a52e$4d035320$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Dean Willis" , "Joel M. Halpern" References: <072C5B76F7CEAB488172C6F64B30B5E301AC0465@xmb-rtp-20b.amer.cisco.com><7.0.1.0.0.20060711124106.03339838@stevecrocker.com> <09354CA3-6B95-47F0-B99F-A5361DB96BC7@softarmor.com> Subject: Re: [Sip] Outbound: Stunning who? Date: Tue, 11 Jul 2006 23:09:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > The root of the problem, I think, is that this draft intertwingles the > proxy behavior (supporting stun) with the registrar behavior (supporting > "outbound" parallel registrations). That, plus the fact that "outbound" is really about receiving inbound requests (from the UA perspective). An "outbound" proxy is traditionally something to which a UA sends its outbound requests, typically starting with REGISTER. "draft-ietf-sip-inbound-nat-traversal" ? Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 21:19:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0TLw-0007An-Bf; Tue, 11 Jul 2006 21:17:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0TLv-00079s-1v for sip@ietf.org; Tue, 11 Jul 2006 21:17:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0TLv-0003Yb-0Q for sip@ietf.org; Tue, 11 Jul 2006 21:17:23 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0TAT-0000qf-4M for sip@ietf.org; Tue, 11 Jul 2006 21:05:34 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6BNWcav000784 for ; Tue, 11 Jul 2006 18:32:59 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ9XJ50>; Wed, 12 Jul 2006 00:32:32 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369DA2D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Wed, 12 Jul 2006 00:32:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: -2.6 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Sip] SIP Session 2 revised agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Due to the overrun in the first session, this is the revised agenda for tomorrow. Apologies for the format but all the information is there. We will be looking to pull up as much time as possible, so we will be skipping resolution of non-urgent issues. Presenter's if you think something is critical that we may not have thought of, please tell us in advance. I think we have most of the presentations now, but if for some reason you have not provided your's, please send as soon as possible. Note that we also have the security issues discussion in an ad-hoc immediately following the SIP session (after the break). See Dean's separate note to this list. regards Keith 1300 Agenda bash Chairs This doc 1305 Location conveyance James Polk draft-ietf-sip-location-conveyance-03.txt 1320 SAML for SIP James Polk, Hannes Tschofenig draft-ietf-sip-saml-00.txt 1330 Certificates. Arboreal Rodents Or Fruitless Canine Vocalization? Jason Fischl draft-ietf-sip-certs-01 1345 Hop Limit Diagnostics Is my bunny sick? Scott Lawrence draft-ietf-sip-hop-limit-diagnostics-03 1400 Connected identity John Elwell draft-ietf-sip-connected-identity-00.txt draft-elwell-sip-tispan-connected-identity-01.txt 1430 Security flows Fork loop fix Feature list for advanced specification Robert Sparks draft-ietf-sip-sec-flows-01 draft-ietf-sip-fork-loop-fix-02 TBD 1445 Hitchhiker's guide Jonathan Rosenberg draft-ietf-sip-hitchhikers-guide-00 1455 SIPS: Guidelines Francois Audet draft-audet-sip-sips-guidelines-02 Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 11 23:43:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Vbh-0006AO-L1; Tue, 11 Jul 2006 23:41:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Vbf-00062m-6O for sip@ietf.org; Tue, 11 Jul 2006 23:41:47 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0VXn-0002HV-3w for sip@ietf.org; Tue, 11 Jul 2006 23:37:48 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6BLDSkY022679 for ; Tue, 11 Jul 2006 16:13:48 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ9X22Y>; Tue, 11 Jul 2006 22:13:28 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369DA22@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Tue, 11 Jul 2006 22:13:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sip] Dialog usage on new status codes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org RFC 4485 (http://www.ietf.org/rfc/rfc4485.txt) section 5 specifies: Dialog Usages: SIP allows for requests that normally create their own dialog (such as SUBSCRIBE) to be used within a dialog created by another method (such as INVITE). In such a case, there are said to be multiple usages of that dialog. Extensions SHOULD consider their interaction with dialog usages. In particular, extensions that define new error response codes SHOULD describe whether that response code causes the dialog and all usages to terminate, or just a specific usage. http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-01.txt does this by implication: A UAC the does not understand or care about the specific semantics of the 433 response will treat it as a 400 response. But this could be much much more explicit. http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-03.txt does not seem to have any information on this whatsoever. Can I ask all editor's of i-ds with new response code values to make sure this is covered. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 12 01:45:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0XVF-0002cl-IK; Wed, 12 Jul 2006 01:43:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0XVE-0002cf-EA for sip@ietf.org; Wed, 12 Jul 2006 01:43:16 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0XVB-0000Fo-28 for sip@ietf.org; Wed, 12 Jul 2006 01:43:16 -0400 Received: from hkaplan [66.103.220.156] by acmepacket.com with ESMTP (SMTPD-9.03) id ABE9029C; Wed, 12 Jul 2006 01:43:05 -0400 From: "Hadriel Kaplan" To: "'Cullen Jennings'" Subject: RE: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Wed, 12 Jul 2006 01:42:52 -0400 Message-ID: <028f01c6a576$0afbdcc0$d30bdb84@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acad+3HnvYr0J/q9QuukxR7J6JyCywHb2kYg In-Reply-To: <48807FA4-2A3A-4EA6-99F5-96DDEFD6611E@cisco.com> X-Spam-Score: 1.2 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Ok, I am done't think I am manging to explaim myself. Say A has a > contract with B and B has a crontract with C. Now a call arrives at > C, it seem that C wants a assertion to be made by B. Anything A says > to C is clsoe to useless because C has no clue who A even is. I guese > I feel like we need to sort out the requirements for what we want in > a transit case and then we might be able to figure out a solution. One of the problems with the idea of a b2bua re-signing it is how to trust the b2bua. I.e., if the domain the b2bua is in is not the same as the From's, then you have to somehow trust the different domain. I agree with you there's a common model of "I trust the domain connected to me directly". So if you have an A-B-C chain as you describe, then sure A can sign, then B can verify A and re-sign with B-cert, and C can verify B. Now imagine A-B-C-D; A and B have a b2bua, but C doesn't. A signs, then B verifies and signs with B-cert, C does nothing and D gets a From of A with a cert of B and does what? In other words, unless they all re-sign, it's limited to a small chain. But if they all re-sign, we're back to hop-by-hop trust. Well... fewer hops because it's domain-by-domain instead of proxy-by-proxy, so it is better. But is domain by domain resigning acceptable? It breaks the end-to-end model of identity, so I would think not. And making every domain re-sign would have a serious flag-day problem. (not to mention quite an impressive performance/scale issue I suspect) At the same time, in your example C does not have a contract with A, so the business model is not end-to-end - so I'm not sure why the trust would be. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 12 07:16:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0cfx-0006Vr-NW; Wed, 12 Jul 2006 07:14:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0cfw-0006Vl-Tn for sip@ietf.org; Wed, 12 Jul 2006 07:14:40 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0cfv-0002l0-Ac for sip@ietf.org; Wed, 12 Jul 2006 07:14:40 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 12 Jul 2006 13:14:26 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id <3YPAR228>; Wed, 12 Jul 2006 13:14:26 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A60F@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: john.elwell@siemens.com, jdrosen@cisco.com, sip@ietf.org Subject: AW: [Sip] concerns on draft-elwell-sip-tispan-connected-identity- 01 Date: Wed, 12 Jul 2006 13:14:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: mdolly@att.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The use of From and P-Asserted Identity for TISPAN Services is = discussed within IETF since nearly one year. Discussion at the Paris and Vancouver Meeting and within the SIPPING = and SIPPING-TISPAN mail list. The use of the From and P-Asserted header for our OIP-OIR (Originating = Identification Presentation/Restriction) is inline with the use as = defined in RFC3261. The From header is used as a not screened identity = directly send from the user where as the P-Asserted-Identity is send by = a network entity that can verify the identity of the user. In many = cases the sent identity is the same. But also in some cases the user can have more than one identity. A = public (Asserted) and a private (Not asserted) one but both are = pointing to the same user. The user could have more than one private = identity pointing to his UA or several UAs. Now in the PSTN world we have PBX using also Public and private = identities (one main line e.G. a Company with many extensions e.G. all = people working within the company) so we have the same construct as I = described for the P-Asserted-Identity and From header. The PBX is sender and receiver of the Requests and Responses so also = originator of the From header and a P-Preferred-Identity that will be = verified by a Network element of the trusted Domain. But behind an PBX = there could be many private identities of users that could be addressed = directly by the private identity and over the asserted identity = (switchboard). =20 So now for the forward direction the use of From and = P-Asserted-Identity for presenting the originating user is clear. In = backward direction we can also use the P-Asserted-Identity but a = equivalent of the Private identity is missing. So the = draft-elwell-sip-tispan-connected-identity- 01 looks fore some = possibilities to fulfil this requirements. These requirements are also documented within = draft-jesske-sipping-tispan-requirements-03.=20 Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Elwell, John [mailto:john.elwell@siemens.com]=20 > Gesendet: Montag, 10. Juli 2006 04:26 > An: Jonathan Rosenberg; IETF SIP List > Betreff: RE: [Sip] concerns on=20 > draft-elwell-sip-tispan-connected-identity- 01 >=20 >=20 > Jonathan, >=20 > Thanks for reading this and commenting. I will leave the=20 > TISPAN guys to > reply on the TISPAN reasons for needing two identities=20 > (although this was > discussed at length on an old thread) and their rationale for=20 > using PAI for > one / Identity for the other.=20 >=20 > All I can say is that the document lays down a concern that=20 > some TISPAN > people have about the connected-identity draft and possible=20 > ways to overcome > that concern. One solution, of course, would be to do nothing=20 > - leave the > connected-identity draft as it is. But in taking that course=20 > we will need to > show that TISPAN requirements can be met by some other means. >=20 > John >=20 > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > > Sent: 07 July 2006 20:50 > > To: IETF SIP List > > Subject: [Sip] concerns on=20 > > draft-elwell-sip-tispan-connected-identity-01 > >=20 > > I wasn't able to find any disucssion on this draft so far in the=20 > > archives; my apologies if I missed it. > >=20 > > This draft concerns me greatly. > >=20 > > The first thing that worries me is the general idea that 3gpp=20 > > or tispan=20 > > get to 'choose' which SIP header field contains what type of=20 > > identity.=20 > > They get to do no such thing. These header fields have=20 > > defined meanings.=20 > > Having either organization decide to specify their own=20 > interpretation=20 > > for the type of identity that goes in there is a guarnateed=20 > > receipe for=20 > > huge, massive, and unending interoperability failures. > >=20 > > On the technical front, I strongly disagree that the From and > > P-Asserted-Identity represent different types of identity=20 > in any way.=20 > > They both have always identified the user that is the sender of the = > > request. In cases where you had an enterprise user Joe making a SIP = > > call, the From would contain sip:joe@enterprise.com and=20 > this would be=20 > > authenticated by the proxy in the enterprise, followed by=20 > > insertion of a=20 > > P-Asserted-ID which says the same thing. The From, in this=20 > use case,=20 > > should not be sip:enterprise.com. > >=20 > > Next, I am puzzled by the requirement to deliver separate=20 > > identities to=20 > > the calling party for these two things. I understand the=20 > concept of a=20 > > billing identity being separate from the identity of the=20 > caller. I do=20 > > not, however, understand why the billing ID is of any=20 > interest to the=20 > > called party whatsoever. It seems that this would, at best, be of=20 > > interest only within the domain of the calling party. Since=20 > its also=20 > > directly inferrable from the identity of the caller (presumably the = > > database contains a linkage between the two), I also don't=20 > see why it=20 > > would need to be carried in the sip message itself. Is there=20 > > a use case=20 > > where there is not a provisioned relationship between the=20 > user making=20 > > the call and the billing entity? Certainly there is a clear direct=20 > > relationship in the enterprise example in the draft. > >=20 > > Finally, even if I buy the idea that there are two identities=20 > > and that=20 > > they both need to be conveyed, I strongly disagree with the=20 > > notion that=20 > > one of them can be conveyed with SIP-identity, while P-A-ID=20 > is OK for=20 > > the other. There are certain well-known technical limitations with=20 > > P-A-ID which sip-identity addresses. There is nothing about=20 > > the nature=20 > > of the identity which invalidates any of those issues. > >=20 > > Thanks, > > Jonathan R. > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ=20 > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) = 952-5050 > > http://www.jdrosen.net PHONE: (973) = 952-5000 > > http://www.cisco.com > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 12 08:08:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0dUX-0007FT-8H; Wed, 12 Jul 2006 08:06:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0dUV-00079i-Ap for sip@ietf.org; Wed, 12 Jul 2006 08:06:55 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0dUT-0008K3-Vp for sip@ietf.org; Wed, 12 Jul 2006 08:06:55 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J2A00101HJ0AF@siemenscomms.co.uk> for sip@ietf.org; Wed, 12 Jul 2006 13:04:51 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J2A0004SHGLGI@siemenscomms.co.uk>; Wed, 12 Jul 2006 13:02:45 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Jul 2006 13:02:23 +0100 Content-return: allowed Date: Wed, 12 Jul 2006 13:02:21 +0100 From: "Elwell, John" Subject: RE: [Sip] STUN keep-alive: Client vs server generating requests To: Hadriel Kaplan , 'Jeroen van Bemmel' , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670960A683@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think it would be a good idea to have this stun-interval=xxx. The proxy will have its own upper limit of frequency of STUN requests it can handle, depending on the number of registered UAs it supports. In general there is likely to be some administrative action required for choosing the right compromise between fast recovery from loss of connectivity and the number of UAs a proxy can support. It is best to do this once at the proxy and have that indicated to each registering UA. When administering this value, account has to be taken of the NATs and firewalls involved, and if the value chosen is too long for some NATs/firewalls, then it will fail. But likewise if the UA chooses the value, it could be wrong not only for NATs/firewalls but also for the proxy. John > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: 10 July 2006 15:32 > To: 'Jeroen van Bemmel'; sip@ietf.org > Subject: RE: [Sip] STUN keep-alive: Client vs server > generating requests > > > > -----Original Message----- > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > > OK, I'll take your word for it. If we then interpret such a > > 'stun-interval=xxx' as an indication of support for STUN > (and say 'no STUN > > unless interval is provided'), I'm happy > > > > Only trouble is: in many cases, the proxy would not know > which type of NAT > > there is in between, let alone how long it caches... > > If it doesn't know, then it sets the value recommended in the draft. > However, there are ways for the proxy to find out, and there are also > operators who know what the timeout is. (e.g., if the NAT is > provided by > them) > > -hadriel > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 12 08:51:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0e9N-0001ol-1y; Wed, 12 Jul 2006 08:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0e9L-0001og-MK for sip@ietf.org; Wed, 12 Jul 2006 08:49:07 -0400 Received: from nz-out-0102.google.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0e9K-0006Li-GC for sip@ietf.org; Wed, 12 Jul 2006 08:49:07 -0400 Received: by nz-out-0102.google.com with SMTP id s1so102148nze for ; Wed, 12 Jul 2006 05:49:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=dwvXADd4sCgjNfiUxH954/FRBUqArsz38VoJjdGMEIn/M+G2brVaTu2nOTQQfbem9s4v1YY0WFz8Ym8DC2KvvwM8YACKJZ+eb9YxHGz9kShs1etKnQn/vE6lj4Gjph9Q0PG0pBF6WHbCQb+UKQDFITiG+m58c2EPkYZkfFIS4Qg= Received: by 10.64.142.10 with SMTP id p10mr572224qbd; Wed, 12 Jul 2006 05:49:05 -0700 (PDT) Received: by 10.64.24.16 with HTTP; Wed, 12 Jul 2006 05:49:05 -0700 (PDT) Message-ID: Date: Wed, 12 Jul 2006 08:49:05 -0400 From: "Jason Fischl" To: "Dale.Worley@comcast.net" Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates In-Reply-To: <200607111736.k6BHaAEA015549@dragon.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <002401c693c8$aab13400$31713b51@BEMBUSTER> <4497EAE7.9090700@cisco.com> <44985514.4010107@cisco.com> <002f01c694ad$3c5479a0$31713b51@BEMBUSTER> <669459C0-169D-42AF-B59A-0F81AB5C2339@cisco.com> <002501c6995b$1c3002e0$31713b51@BEMBUSTER> <200607111736.k6BHaAEA015549@dragon.ariadne.com> X-Google-Sender-Auth: 9f3aa80a70471d8e X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 7/11/06, Dale.Worley@comcast.net wrote: > From: "Jason Fischl" > > > On the using a GRUU in a cert, would need to consider that any time > > my GRUU changes I need to generate a new cert - if this meant a new > > private/public key pair, this might be expensive. > > Also consider that GRUUs will change relatively frequently for devices. > > Why would GRUUs change "relatively frequently"? They can change only > as frequently as the AOR changes, or the instance-id changes. > Yes. I was just confused. Sorry about that and thanks for pointing it out. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 12 13:38:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0idN-00009d-Uv; Wed, 12 Jul 2006 13:36:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0idM-00009Y-3X for sip@ietf.org; Wed, 12 Jul 2006 13:36:24 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0idK-0000Qw-G2 for sip@ietf.org; Wed, 12 Jul 2006 13:36:24 -0400 Received: from [132.219.4.181] (h04b5-net84db.lab.risq.net [132.219.4.181] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6CGmSRD020358 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 12 Jul 2006 11:48:29 -0500 In-Reply-To: References: <002401c693c8$aab13400$31713b51@BEMBUSTER> <4497EAE7.9090700@cisco.com> <44985514.4010107@cisco.com> <002f01c694ad$3c5479a0$31713b51@BEMBUSTER> <669459C0-169D-42AF-B59A-0F81AB5C2339@cisco.com> <002501c6995b$1c3002e0$31713b51@BEMBUSTER> <200607111736.k6BHaAEA015549@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <427499A3-2C89-4547-A670-5C0C3B860634@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates Date: Wed, 12 Jul 2006 10:26:16 -0500 To: Jason Fischl X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 12, 2006, at 7:49 AM, Jason Fischl wrote: > On 7/11/06, Dale.Worley@comcast.net wrote: >> From: "Jason Fischl" >> >> > On the using a GRUU in a cert, would need to consider that >> any time >> > my GRUU changes I need to generate a new cert - if this meant >> a new >> > private/public key pair, this might be expensive. >> >> Also consider that GRUUs will change relatively frequently for >> devices. >> >> Why would GRUUs change "relatively frequently"? They can change only >> as frequently as the AOR changes, or the instance-id changes. >> > > Yes. I was just confused. Sorry about that and thanks for pointing > it out. > In practice, I would not be surprised if they actually change more frequently -- either with reboot of the assigning server, or perhaps on a database rebuild, major upgrade, etc. I'm not aware of anybody currently adding assigned GRUUs to their "long term provisioning database of record", which is what would be needed to maintain the GRUU as long as we might want. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 12 14:10:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0j8i-0001W1-BD; Wed, 12 Jul 2006 14:08:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0j8h-0001Vw-U5 for sip@ietf.org; Wed, 12 Jul 2006 14:08:47 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0j8g-0006Wg-Gh for sip@ietf.org; Wed, 12 Jul 2006 14:08:47 -0400 Received: from [132.219.4.181] (h04b5-net84db.lab.risq.net [132.219.4.181] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6CIAUfh020842 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 12 Jul 2006 13:10:35 -0500 In-Reply-To: <44ADF4E9.5000305@cisco.com> References: <1150495197.10237.51.camel@sukothai.pingtel.com> <1151955580.2892.102.camel@sukothai.pingtel.com> <44ADF4E9.5000305@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 12 Jul 2006 13:08:05 -0500 To: SIP WG List X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Cullen Jennings Subject: [Sip] Message in reverse direction for hop-limit diagnostics X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 7, 2006, at 12:45 AM, Jonathan Rosenberg wrote: > > > One idea on dealing with the size problem is, instead of including > the sip-frag in a response, the resposne just indicates that the > hop limit was exceeded. The server which generated the response > then sends a request in a totally new transaction, towards the > contact of the request. That request contains the sip-frag with all > of the information, and could be sent over TCP if needed. > > That idea doesn't work for requests which omit contact, and also > means that intermediate proxies on the path of the failed request > might not see the diagnostic information, since it would come over > a different transaction. > > Anyway, just a thought. JDR mentioned during today's WG discussion that he had previously suggested this idea on the list. I looked and found it hiding in a thread, and thought it was worth putting back up on the list. So here you go. Maybe this will work. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From 4p6ch8cCoe@mail.ru Wed Jul 12 14:33:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jWv-0006ys-Rc for sip-archive@lists.ietf.org; Wed, 12 Jul 2006 14:33:49 -0400 Received: from [194.187.134.53] (helo=b43.tlan.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jQR-0001At-14; Wed, 12 Jul 2006 14:27:08 -0400 Message-ID: <662161c80604elizfz4juv9npf2mhgb7pqbrow94g1n69@mxs.mail.ru> Date: Wed, 12 Jul 2006 18:27:07 -0120 From: "Theresa Lovell" To: sms@lists.ietf.org Subject: DCK MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 In other words, we didn't touch on the subject again. Kirill phoned PPS No limits, Jonathan? he thought. Well, then, the time's not distant "OK, sir. Next time I'll bring my dictionary along, sir." Then it was in to his body, left only the narrow swept daggers of his wingtips From sip-bounces@ietf.org Wed Jul 12 18:14:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0mwf-0007ht-Dq; Wed, 12 Jul 2006 18:12:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0mwe-0007hl-ID for sip@ietf.org; Wed, 12 Jul 2006 18:12:36 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0mwd-0007bc-8O for sip@ietf.org; Wed, 12 Jul 2006 18:12:36 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J2B00A019PJZ2@siemenscomms.co.uk> for sip@ietf.org; Wed, 12 Jul 2006 23:12:55 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J2B006BU9PJGK@siemenscomms.co.uk>; Wed, 12 Jul 2006 23:12:55 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Jul 2006 23:12:34 +0100 Content-return: allowed Date: Wed, 12 Jul 2006 23:12:32 +0100 From: "Elwell, John" To: sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670960AAE7@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "Jesske, R" , christer.holmberg@ericsson.com Subject: [Sip] Outcome of discussion on tispan-connected-identity draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org During today's SIP meeting there was discussion of draft-elwell-sip-tispan-connected-identity-01. This was in the context of open issue 1 in draft-ietf-sip-connected-identity-00. My view of what emerged was as follows (please correct me if necessary). There were mixed views on the TISPAN use of the P-Asserted-Identity header field to indicate the identity used for billing / authorisation purposes, as opposed to the identity suitable for return call purposes that would be in the From header field (with the possibility of authentication using Identity header field). Opinions ranged from agreeing that it is reasonable, on the one hand, to strong opposition to changing the meaning of the P-Asserted-Identity header field on the other hand. Although ETSI TISPAN requirements in this area are stated in draft-jesske-sipping-tispan-requirements-02 and had been discussed in the past, discussion with ETSI TISPAN on candidate mechanisms to satisfy these requirements had not taken place previously. Because the primary topic of the agenda slot was draft-ietf-sip-connected-identity, and because of the absence of TISPAN liaison representatives in the meeting, it was not possible to discuss the issue at length during this meeting. However, I was encouraged to work with TISPAN representatives and assist them to contribute further on the topic. Open issue 1 in draft-ietf-sip-connected-identity-00 will be closed, with no change. The document will not specify a response identity and will not specify an option tag to inform a PSTN gateway that an UPDATE request will follow the 200 response to the INVITE request. If any protocol enhancements are required to support TISPAN callee identification requirements, these will be covered in separate documents under a separate charter item. TISPAN members on this mailing list (IETF SIP) are encouraged to take note of the above. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 12 19:21:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0nzp-0008BI-0o; Wed, 12 Jul 2006 19:19:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0nzm-00085k-R4 for sip@ietf.org; Wed, 12 Jul 2006 19:19:54 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0nzl-00068R-Kh for sip@ietf.org; Wed, 12 Jul 2006 19:19:54 -0400 Received: from [132.219.26.162] (h1aa2-net84db.lab.risq.net [132.219.26.162] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6CNJq4B003601 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 12 Jul 2006 19:19:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <66662E19-867B-4B7D-AE82-D1F907EB8940@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip@ietf.org From: Henning Schulzrinne Date: Wed, 12 Jul 2006 19:19:52 -0400 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] Location header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org To follow up on the discussion in the SIP group. I think there are roughly three options for the content of Location: (1) Point to content in the body --> can't be modified and cannot be inserted by proxies (and may not be inspectable by proxies if encrypted) (2) Point to external location --> can be modified, can be added, but can induce loops if changed in mid-stream and incurs another failure mode (and possible security risks if the reference is generally accessible) (3) Point to data URL (RFC 2397) as in Location: data:application/pidf+xml;base64, Date: Wed, 12 Jul 2006 19:36:24 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Sip] Location header References: <66662E19-867B-4B7D-AE82-D1F907EB8940@cs.columbia.edu> In-Reply-To: <66662E19-867B-4B7D-AE82-D1F907EB8940@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Henning, I like your idea of using the data URL. It would work nicely for PIDF-LO and SAML assertions. Ciao Hannes Henning Schulzrinne wrote: > To follow up on the discussion in the SIP group. I think there are > roughly three options for the content of Location: > > (1) Point to content in the body --> can't be modified and cannot be > inserted by proxies (and may not be inspectable by proxies if encrypted) > > (2) Point to external location --> can be modified, can be added, but > can induce loops if changed in mid-stream and incurs another failure > mode (and possible security risks if the reference is generally > accessible) > > (3) Point to data URL (RFC 2397) as in > > Location: data:application/pidf+xml;base64, > Disadvantage: about 30% larger than as body; can't be encrypted > separately (except as XML-DSIG) > > Advantages: can be inserted/modified by proxies (similar to (2)), but > avoids difficulty of external reference > > I think these three methods all have different time-space-flexibility > trade-offs and thus I suspect they all serve a need. > > Henning > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 12 20:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0pPL-0003qi-BJ; Wed, 12 Jul 2006 20:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0pPJ-0003it-MP for sip@ietf.org; Wed, 12 Jul 2006 20:50:21 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0pPH-0003rC-FQ for sip@ietf.org; Wed, 12 Jul 2006 20:50:21 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <200607130050180120002soie>; Thu, 13 Jul 2006 00:50:18 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k6D0oIN1026399 for ; Wed, 12 Jul 2006 20:50:18 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k6D0oIiH026395; Wed, 12 Jul 2006 20:50:18 -0400 Date: Wed, 12 Jul 2006 20:50:18 -0400 Message-Id: <200607130050.k6D0oIiH026395@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <427499A3-2C89-4547-A670-5C0C3B860634@softarmor.com> (dean.willis@softarmor.com) Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates References: <002401c693c8$aab13400$31713b51@BEMBUSTER> <4497EAE7.9090700@cisco.com> <44985514.4010107@cisco.com> <002f01c694ad$3c5479a0$31713b51@BEMBUSTER> <669459C0-169D-42AF-B59A-0F81AB5C2339@cisco.com> <002501c6995b$1c3002e0$31713b51@BEMBUSTER> <200607111736.k6BHaAEA015549@dragon.ariadne.com> <427499A3-2C89-4547-A670-5C0C3B860634@softarmor.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Dean Willis In practice, I would not be surprised if they actually change more frequently -- either with reboot of the assigning server, or perhaps on a database rebuild, major upgrade, etc. I'm not aware of anybody currently adding assigned GRUUs to their "long term provisioning database of record", which is what would be needed to maintain the GRUU as long as we might want. sipX (http://www.sipfoundry.org) constructs GRUUs by hashing the AOR, instance ID, and a fixed key string. So its GRUUs really are eternal. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 11:11:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12os-00059j-Rb; Thu, 13 Jul 2006 11:09:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12om-0004sd-9A for sip@ietf.org; Thu, 13 Jul 2006 11:09:32 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12a1-0007fh-2f for sip@ietf.org; Thu, 13 Jul 2006 10:54:23 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 038056C030 for ; Thu, 13 Jul 2006 09:53:22 -0400 (EDT) From: Scott Lawrence To: SIP WG List In-Reply-To: References: <1150495197.10237.51.camel@sukothai.pingtel.com> <1151955580.2892.102.camel@sukothai.pingtel.com> <44ADF4E9.5000305@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Thu, 13 Jul 2006 10:53:24 -0400 Message-Id: <1152802404.2840.81.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Sip] Size of message/sipfrag in diagnostic responses X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org One of the open issues with draft-ietf-hop-limit-diagnostics-0x (for all x <= 3) is that the response will usually be very large. If any hop in the path is UDP, and the large response reaches that point, it may be fragmented into so many parts that it: - causes congestion problems in the reverse direction - fails reassembly (resulting in no response at all and triggering retries) Since either of these problems is arguably worse than not getting good diagnostic information, we have concluded that something different needs to be done. I've spent some time trying to sort through the various suggestions on how to cope with this, and I think that the simplest one is the best. I propose something like the following for the next revision of the draft: When sending an error response that has a message/sipfrag body, the responding server MUST examine all the Via header values in the request. If any Via header value specifies UDP, then the total size of the response body MUST NOT be greater than 200 bytes and the server MUST follow the procedures in section X to prune the returned message/sipfrag body to fit within this limit. If no request Via header value specifies UDP, then the server is free to either prune the returned message/sipfrag body as specified in section X or to return the full set of request headers. Even though this falls short of providing as much diagnostic information as I'd like, I think that this is the best chance of getting _some_ useful information back to both the originator and to the proxies along the path. It means that you have a better chance of getting better diagnostic information when you use TCP, and I think that may actually provide an incentive that's in a good direction anyway. The above text does not attempt to solve the general problem of SIP response size; it is deliberately limited to the class of diagnostic responses this draft is advocating. I think that the SIP WG should try to actually specify general rules for response sizes, but I would rather decouple that from making this diagnostic information available. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 11:17:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12uK-0006rW-9M; Thu, 13 Jul 2006 11:15:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12uJ-0006rO-9j for sip@ietf.org; Thu, 13 Jul 2006 11:15:15 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12uE-0000eg-Px for sip@ietf.org; Thu, 13 Jul 2006 11:15:15 -0400 Received: from frmail28.netfr.alcatel.fr (frmail28.netfr.alcatel.fr [155.132.251.28]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6DFF9NX016733; Thu, 13 Jul 2006 17:15:09 +0200 Received: from [127.0.0.1] ([155.132.188.32]) by frmail28.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006071317150712:8468 ; Thu, 13 Jul 2006 17:15:07 +0200 Message-ID: <44B6636A.7050906@alcatel.fr> Date: Thu, 13 Jul 2006 17:14:50 +0200 From: Thomas.Froment@alcatel.fr User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Robert Sparks References: <44B64F07.4090908@alcatel.fr> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/13/2006 17:15:07, Serialize by Router on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/13/2006 17:15:08, Serialize complete at 07/13/2006 17:15:08 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org Subject: [Sip] Re: question on draft-ietf-sip-fork-loop-fix-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Robert Sparks wrote: > I have another open issue on the current algorithm (as it is presented > in RFC 3261) which suggests that the "Via" header should be added, > without telling that, of course, the branch parameter should NOT be > used in Hash calculation (overwise it will always be different and > loop will never be detected...) > > the fork-loop-fix draft (at version -02) _REPLACES_ all of that text > in 3261. I don't think the replacement text has the problem you > point to does it? This is the part which mentions the open issues: > This second part MUST vary with any field used by the location > > service logic in determining where to retarget or forward this > request. This is necessary to distinguish looped requests from > spirals by allowing the proxy to recognize if none of the values > affecting the processing of the request have changed. Hence, The > second part MUST depend at least on the received Request-URI and any > Route header field values in the received request. Implementers need > to take care to include all fields used by the location service logic > in that particular implementation. > > This second part MUST NOT include the request method. CANCEL and > non-200 ACK requests MUST have the same branch parameter value as the > corresponding request they cancel or acknowledge. This branch > parameter value is used in correlating those requests at the server > handling them (see Sections 17.2.3 and 9.2). I am confused with this part: there is no more sent-by part of the Via header? why is not mentionned in the open issue part then? (like for Call-Id ,toTag, and fromTag which should actually be removed...) > Another quick comment on the section 4 of > draft-ietf-sip-fork-loop-fix-02.txt >>> 4. Loop Detection Check >>> >>> Proxies required to perform loop-detection by RFC-XXXX (RFC-Editor: >>> replace XXXX with the RFC number of this document) MUST perform the >>> following loop-detection test before forwarding a request. Each Via >>> header field value in the request whose sent-by value matches a >>> value >>> placed into previous requests by this proxy MUST be inspected for >>> the >>> "second part" defined in Section 4.2.1 of RFC-XXXX. This second >>> part >>> will not be present if the message was not forked when that Via >>> header field value was added. If the second field is present, the >>> proxy MUST perform the second part calculation described in >>> Section 4.2.1 of RFC-XXXX on this request and compare the result to >>> the value from the Via header field. If these values are equal, the >>> request has looped and the proxy MUST reject the request with a 482 >>> (Loop Detected) response. If the values differ, the request is >>> spiraling and processing continues to the next step. >> The question here is, how do I know that the "second part" is present? >> the common practice is to setup a branch with a "minus" separator, eg: >> branch=z9hg4bKRANDOMID-LOOPDETECTIONHASH >> however, it is also common pratice for many implementation to setup >> some additionnal information in their branch, also using the "minus" >> separator, >> e.g: >> branch=z9hG4bKRANDOMID-MYIMPLEMENTATIONSTUFF-LOOPDETECTIONHASH >> >> So, since the "presence" of minus (or any other) separator may not be >> enough, and in order to be able be sure the "loop detection part" is >> here, >> wouldn't it be useful to setup another kind of "magic cookie" for that? > > So the only thing that will look into the branch for the second part > is the thing that put that second part there. > You don't need to know how anyone else forms their branch parameter > with respect to this. > > Since you put the value in, you know how to recognize whether it's > there. I don't see importance in making everyone > do this the same way. because if somebody use -XX at the end of the branch parameter (and this is common practice), I will have to make unecessary computation on the incoming request... One possible solution to avoid this is to have some kind of magic cookie, or a pre-defined separator... If I decide to use '--' as separator, unfortunately, it may by used by somebody else in its branch format (and for something ELSE than loop detection)... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 11:38:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13FF-0003yP-Ha; Thu, 13 Jul 2006 11:36:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13Ek-00035d-F1 for sip@ietf.org; Thu, 13 Jul 2006 11:36:22 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12zf-000155-4N for sip@ietf.org; Thu, 13 Jul 2006 11:20:48 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id DE55519449D for ; Thu, 13 Jul 2006 17:20:44 +0200 (CEST) Received: from [132.219.5.208] ([132.219.5.208]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 17:19:58 +0200 In-Reply-To: <1152802404.2840.81.camel@localhost.localdomain> References: <1150495197.10237.51.camel@sukothai.pingtel.com> <1151955580.2892.102.camel@sukothai.pingtel.com> <44ADF4E9.5000305@cisco.com> <1152802404.2840.81.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3c17e6330e8571d304ba52b461a628d2@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses Date: Thu, 13 Jul 2006 17:21:04 +0200 To: Scott Lawrence X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 13 Jul 2006 15:19:58.0262 (UTC) FILETIME=[CD5D5D60:01C6A68F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Another option is to return, in the 4xx response, an http URI pointing to a place where the server has stored the request. The requester can then go and pull the SIP request. Might be an issue to interdomain cases, but not sure. Hisham On Jul 13, 2006, at 4:53 PM, Scott Lawrence wrote: > One of the open issues with draft-ietf-hop-limit-diagnostics-0x (for > all > x <= 3) is that the response will usually be very large. If any hop in > the path is UDP, and the large response reaches that point, it may be > fragmented into so many parts that it: > - causes congestion problems in the reverse direction > - fails reassembly (resulting in no response at all and > triggering retries) > Since either of these problems is arguably worse than not getting good > diagnostic information, we have concluded that something different > needs > to be done. > > I've spent some time trying to sort through the various suggestions on > how to cope with this, and I think that the simplest one is the best. > I > propose something like the following for the next revision of the > draft: > > When sending an error response that has a message/sipfrag body, > the responding server MUST examine all the Via header values in > the request. If any Via header value specifies UDP, then the > total size of the response body MUST NOT be greater than 200 > bytes and the server MUST follow the procedures in section X to > prune the returned message/sipfrag body to fit within this > limit. If no request Via header value specifies UDP, then the > server is free to either prune the returned message/sipfrag > body > as specified in section X or to return the full set of request > headers. > > Even though this falls short of providing as much diagnostic > information > as I'd like, I think that this is the best chance of getting _some_ > useful information back to both the originator and to the proxies along > the path. It means that you have a better chance of getting better > diagnostic information when you use TCP, and I think that may actually > provide an incentive that's in a good direction anyway. > > The above text does not attempt to solve the general problem of SIP > response size; it is deliberately limited to the class of diagnostic > responses this draft is advocating. I think that the SIP WG should try > to actually specify general rules for response sizes, but I would > rather > decouple that from making this diagnostic information available. > > -- > Scott Lawrence tel:+1-781-938-5306;ext=162 or > sip:slawrence@pingtel.com > sipXpbx project coordinator - SIPfoundry > http://www.sipfoundry.org/sipX > Chief Architect - Pingtel Corp. http://www.pingtel.com/ > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 13:36:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G155J-00023t-HH; Thu, 13 Jul 2006 13:34:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G155I-00020z-HH for sip@ietf.org; Thu, 13 Jul 2006 13:34:44 -0400 Received: from [2001:5c0:8fff:fffe::4c49] (helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G155F-0000Pr-Vn for sip@ietf.org; Thu, 13 Jul 2006 13:34:44 -0400 Received: from [132.219.30.170] (h1eaa-net84db.lab.risq.net [132.219.30.170] (may be forged)) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6DHYWh4061451 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 13 Jul 2006 12:34:33 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <44B6636A.7050906@alcatel.fr> References: <44B64F07.4090908@alcatel.fr> <44B6636A.7050906@alcatel.fr> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4D70D397-D747-4229-8E98-5E8D06797A68@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Thu, 13 Jul 2006 13:34:35 -0400 To: Thomas.Froment@alcatel.fr X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 132.219.30.170 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: sip@ietf.org Subject: [Sip] Re: question on draft-ietf-sip-fork-loop-fix-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 13, 2006, at 11:14 AM, Thomas.Froment@alcatel.fr wrote: > Robert Sparks wrote: >> I have another open issue on the current algorithm (as it is >> presented in RFC 3261) which suggests that the "Via" header should >> be added, without telling that, of course, the branch parameter >> should NOT be used in Hash calculation (overwise it will always be >> different and loop will never be detected...) >> the fork-loop-fix draft (at version -02) _REPLACES_ all of that >> text in 3261. I don't think the replacement text has the problem you >> point to does it? > This is the part which mentions the open issues: > >> This second part MUST vary with any field used by the location >> >> service logic in determining where to retarget or forward this >> request. This is necessary to distinguish looped requests from >> spirals by allowing the proxy to recognize if none of the values >> affecting the processing of the request have changed. Hence, The >> second part MUST depend at least on the received Request-URI >> and any >> Route header field values in the received request. >> Implementers need >> to take care to include all fields used by the location service >> logic >> in that particular implementation. >> >> This second part MUST NOT include the request method. CANCEL and >> non-200 ACK requests MUST have the same branch parameter value >> as the >> corresponding request they cancel or acknowledge. This branch >> parameter value is used in correlating those requests at the >> server >> handling them (see Sections 17.2.3 and 9.2). > I am confused with this part: > there is no more sent-by part of the Via header? why is not > mentionned in the open issue part then? (like for Call-Id ,toTag, > and fromTag which > should actually be removed...) I didn't call that out as an open issue because we have clear consensus to not include the topmost via in the calculation. I should have made a note of that in the changelog - sorry for the confusion. > >> Another quick comment on the section 4 of draft-ietf-sip-fork-loop- >> fix-02.txt >>>> 4. Loop Detection Check >>>> >>>> Proxies required to perform loop-detection by RFC-XXXX (RFC- >>>> Editor: >>>> replace XXXX with the RFC number of this document) MUST >>>> perform the >>>> following loop-detection test before forwarding a request. >>>> Each Via >>>> header field value in the request whose sent-by value matches >>>> a value >>>> placed into previous requests by this proxy MUST be inspected >>>> for the >>>> "second part" defined in Section 4.2.1 of RFC-XXXX. This >>>> second part >>>> will not be present if the message was not forked when that Via >>>> header field value was added. If the second field is >>>> present, the >>>> proxy MUST perform the second part calculation described in >>>> Section 4.2.1 of RFC-XXXX on this request and compare the >>>> result to >>>> the value from the Via header field. If these values are >>>> equal, the >>>> request has looped and the proxy MUST reject the request with >>>> a 482 >>>> (Loop Detected) response. If the values differ, the request is >>>> spiraling and processing continues to the next step. >>> The question here is, how do I know that the "second part" is >>> present? >>> the common practice is to setup a branch with a "minus" >>> separator, eg: >>> branch=z9hg4bKRANDOMID-LOOPDETECTIONHASH >>> however, it is also common pratice for many implementation to >>> setup some additionnal information in their branch, also using >>> the "minus" separator, >>> e.g: >>> branch=z9hG4bKRANDOMID-MYIMPLEMENTATIONSTUFF-LOOPDETECTIONHASH >>> >>> So, since the "presence" of minus (or any other) separator may >>> not be enough, and in order to be able be sure the "loop >>> detection part" is here, >>> wouldn't it be useful to setup another kind of "magic cookie" for >>> that? >> >> So the only thing that will look into the branch for the second >> part is the thing that put that second part there. >> You don't need to know how anyone else forms their branch >> parameter with respect to this. >> >> Since you put the value in, you know how to recognize whether it's >> there. I don't see importance in making everyone >> do this the same way. > because if somebody use -XX at the end of the branch parameter (and > this is common practice), I will have to make unecessary > computation on the incoming request... > One possible solution to avoid this is to have some kind of magic > cookie, or a pre-defined separator... If I decide to use '--' as > separator, unfortunately, it may by used by somebody else in its > branch format (and for something ELSE than loop detection)... > What computation are you doing on other people's branch tag? You should only be looking inside ones you put there. I think you're here at IETF - could we take this to an in-person conversation? RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 14:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15gi-0001x0-3N; Thu, 13 Jul 2006 14:13:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15gg-0001wq-BB for sip@ietf.org; Thu, 13 Jul 2006 14:13:22 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15ga-0003F7-31 for sip@ietf.org; Thu, 13 Jul 2006 14:13:22 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 0C8416C030; Thu, 13 Jul 2006 13:12:21 -0400 (EDT) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses From: Scott Lawrence To: Jeroen van Bemmel In-Reply-To: <00da01c6a693$a0669ac0$31713b51@BEMBUSTER> References: <1150495197.10237.51.camel@sukothai.pingtel.com> <1151955580.2892.102.camel@sukothai.pingtel.com> <44ADF4E9.5000305@cisco.com> <1152802404.2840.81.camel@localhost.localdomain> <3c17e6330e8571d304ba52b461a628d2@telio.no> <00da01c6a693$a0669ac0$31713b51@BEMBUSTER> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Thu, 13 Jul 2006 14:12:24 -0400 Message-Id: <1152814344.2854.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > >> I > >> propose something like the following for the next revision of the > >> draft: > >> > >> When sending an error response that has a message/sipfrag body, > >> the responding server MUST examine all the Via header values in > >> the request. If any Via header value specifies UDP, then the > >> total size of the response body MUST NOT be greater than 200 > >> bytes and the server MUST follow the procedures in section X to > >> prune the returned message/sipfrag body to fit within this > >> limit. If no request Via header value specifies UDP, then the > >> server is free to either prune the returned message/sipfrag > >> body > >> as specified in section X or to return the full set of request On Thu, 2006-07-13 at 17:47 +0200, Jeroen van Bemmel wrote: > gzip on the body might help too If I'm not mistaken, it's not trivial to figure out how much any given text will compress with gzip unless you actually try each possibility. I'd rather preserve the human-readability and get one fewer headers. Also, it doesn't do all that well on short inputs. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 14:18:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15jp-0002xe-30; Thu, 13 Jul 2006 14:16:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15jo-0002xZ-0n for sip@ietf.org; Thu, 13 Jul 2006 14:16:36 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15ji-0003PU-Op for sip@ietf.org; Thu, 13 Jul 2006 14:16:36 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id BB2B66C030; Thu, 13 Jul 2006 13:15:36 -0400 (EDT) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses From: Scott Lawrence To: Hisham Khartabil In-Reply-To: <3c17e6330e8571d304ba52b461a628d2@telio.no> References: <1150495197.10237.51.camel@sukothai.pingtel.com> <1151955580.2892.102.camel@sukothai.pingtel.com> <44ADF4E9.5000305@cisco.com> <1152802404.2840.81.camel@localhost.localdomain> <3c17e6330e8571d304ba52b461a628d2@telio.no> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Thu, 13 Jul 2006 14:15:38 -0400 Message-Id: <1152814538.2854.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > I > > propose something like the following for the next revision of the > > draft: > > > > When sending an error response that has a message/sipfrag body, > > the responding server MUST examine all the Via header values in > > the request. If any Via header value specifies UDP, then the > > total size of the response body MUST NOT be greater than 200 > > bytes and the server MUST follow the procedures in section X to > > prune the returned message/sipfrag body to fit within this > > limit. If no request Via header value specifies UDP, then the > > server is free to either prune the returned message/sipfrag > > body > > as specified in section X or to return the full set of request > > headers. On Thu, 2006-07-13 at 17:21 +0200, Hisham Khartabil wrote: > Another option is to return, in the 4xx response, an http URI pointing > to a place where the server has stored the request. The requester can > then go and pull the SIP request. > > Might be an issue to interdomain cases, but not sure. I'm fairly sure that it would often be a problem. Even if all I get is the warning header, the request line and the topmost via, I suspect it's more useful than a URL I might not be able to reach (and I suspect that the URLs would often not be short). I also don't want to require that a proxy also be an http server in order to provide this functionality. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 14:22:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15oC-0003hK-9T; Thu, 13 Jul 2006 14:21:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15oA-0003hC-W8 for sip@ietf.org; Thu, 13 Jul 2006 14:21:06 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15oA-00042z-IB for sip@ietf.org; Thu, 13 Jul 2006 14:21:06 -0400 Received: from hkaplan [132.219.11.211] by acmepacket.com with ESMTP (SMTPD-9.03) id AF0A0158; Thu, 13 Jul 2006 14:20:58 -0400 From: "Hadriel Kaplan" To: "'Hisham Khartabil'" , "'Scott Lawrence'" Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses Date: Thu, 13 Jul 2006 14:20:51 -0400 Message-ID: <002501c6a6a9$12f863b0$d30bdb84@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <3c17e6330e8571d304ba52b461a628d2@telio.no> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcamkiyUQ0S7QwnURuC1dFgtItprNQAFbWhQ X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: 'SIP WG List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hisham, I don't like the http URI concept for that because of the security, performance, and reachability issues. I imagine that intermediate nodes in the return path may well want to log the diags info for certain response failures, without user intervention. With a mime attachment no problem (well, no more than other sip/mime issues). With an http uri it's an issue for a bunch of probably obvious reasons. I'd rather not have to create diags/logs for the diags problems. :) Cheers, -hadriel > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Thursday, July 13, 2006 11:21 AM > To: Scott Lawrence > Cc: SIP WG List > Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses > > Another option is to return, in the 4xx response, an http URI pointing > to a place where the server has stored the request. The requester can > then go and pull the SIP request. > > Might be an issue to interdomain cases, but not sure. > > Hisham > > On Jul 13, 2006, at 4:53 PM, Scott Lawrence wrote: > > > One of the open issues with draft-ietf-hop-limit-diagnostics-0x (for > > all > > x <= 3) is that the response will usually be very large. If any hop in > > the path is UDP, and the large response reaches that point, it may be > > fragmented into so many parts that it: > > - causes congestion problems in the reverse direction > > - fails reassembly (resulting in no response at all and > > triggering retries) > > Since either of these problems is arguably worse than not getting good > > diagnostic information, we have concluded that something different > > needs > > to be done. > > > > I've spent some time trying to sort through the various suggestions on > > how to cope with this, and I think that the simplest one is the best. > > I > > propose something like the following for the next revision of the > > draft: > > > > When sending an error response that has a message/sipfrag body, > > the responding server MUST examine all the Via header values in > > the request. If any Via header value specifies UDP, then the > > total size of the response body MUST NOT be greater than 200 > > bytes and the server MUST follow the procedures in section X to > > prune the returned message/sipfrag body to fit within this > > limit. If no request Via header value specifies UDP, then the > > server is free to either prune the returned message/sipfrag > > body > > as specified in section X or to return the full set of request > > headers. > > > > Even though this falls short of providing as much diagnostic > > information > > as I'd like, I think that this is the best chance of getting _some_ > > useful information back to both the originator and to the proxies along > > the path. It means that you have a better chance of getting better > > diagnostic information when you use TCP, and I think that may actually > > provide an incentive that's in a good direction anyway. > > > > The above text does not attempt to solve the general problem of SIP > > response size; it is deliberately limited to the class of diagnostic > > responses this draft is advocating. I think that the SIP WG should try > > to actually specify general rules for response sizes, but I would > > rather > > decouple that from making this diagnostic information available. > > > > -- > > Scott Lawrence tel:+1-781-938-5306;ext=162 or > > sip:slawrence@pingtel.com > > sipXpbx project coordinator - SIPfoundry > > http://www.sipfoundry.org/sipX > > Chief Architect - Pingtel Corp. http://www.pingtel.com/ > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 15:39:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16zl-0002Rt-LP; Thu, 13 Jul 2006 15:37:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16zk-0002Rh-P5 for sip@ietf.org; Thu, 13 Jul 2006 15:37:08 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G16yR-0002Jh-Lh for sip@ietf.org; Thu, 13 Jul 2006 15:35:49 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k6DJU8U12577; Thu, 13 Jul 2006 15:30:08 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses Date: Thu, 13 Jul 2006 14:35:44 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D3BBE07@zrc2hxm2.corp.nortel.com> In-Reply-To: <1152814344.2854.2.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Size of message/sipfrag in diagnostic responses thread-index: AcamqCdr54cLx9KKS/erMAI+TmZmVgACvTVA From: "Samir Srivastava" To: "Scott Lawrence" , "Jeroen van Bemmel" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Inline below. Thx Samir << Removed Unrelated stuff>> >=20 > On Thu, 2006-07-13 at 17:47 +0200, Jeroen van Bemmel wrote: > > gzip on the body might help too >=20 > If I'm not mistaken, it's not trivial to figure out how much=20 > any given text will compress with gzip unless you actually=20 > try each possibility.=20 >=20 > I'd rather preserve the human-readability and get one fewer headers. >=20 > Also, it doesn't do all that well on short inputs. SS>> Gzip can achieve good compression ratio, if there are loops and hop (RR, Via ) entries are repeated multiple times. Or should it be for sigcomp ?? >=20 > -- > Scott Lawrence tel:+1-781-938-5306;ext=3D162 or=20 > sip:slawrence@pingtel.com > sipXpbx project coordinator - SIPfoundry =20 > http://www.sipfoundry.org/sipX > Chief Architect - Pingtel Corp. http://www.pingtel.com/ >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 15:39:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G170E-0002oN-Mm; Thu, 13 Jul 2006 15:37:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16zy-0002b1-Fd for sip@ietf.org; Thu, 13 Jul 2006 15:37:23 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G16tN-00028B-Pz for sip@ietf.org; Thu, 13 Jul 2006 15:30:35 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6DJUQX28299; Thu, 13 Jul 2006 15:30:26 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses Date: Thu, 13 Jul 2006 14:30:26 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D3BBDE9@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Size of message/sipfrag in diagnostic responses thread-index: AcamkjpGHvVoLNnuTxCmyhuaxA4K8AACssJQAAFKC3AABCRMQA== From: "Samir Srivastava" To: "Samir Srivastava" , "Hisham Khartabil" , "Scott Lawrence" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >=20 > Might be an issue to interdomain cases, but not sure. >=20 > Hisham >=20 > Can SAML assertions take care of this ? Thx Samir=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 15:46:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G176n-00042x-W2; Thu, 13 Jul 2006 15:44:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1704-0002fJ-Pa for sip@ietf.org; Thu, 13 Jul 2006 15:37:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G16oW-0001up-RW for sip@ietf.org; Thu, 13 Jul 2006 15:25:34 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 13 Jul 2006 12:25:25 -0700 X-IronPort-AV: i="4.06,238,1149490800"; d="scan'208"; a="1838277857:sNHT19452380908" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DJPPOi001503; Thu, 13 Jul 2006 12:25:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DJPNJi002614; Thu, 13 Jul 2006 12:25:24 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 12:25:23 -0700 Received: from [10.21.152.185] ([10.21.152.185]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 12:25:23 -0700 Message-ID: <44B69E21.60402@cisco.com> Date: Thu, 13 Jul 2006 15:25:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses References: <1150495197.10237.51.camel@sukothai.pingtel.com> <1151955580.2892.102.camel@sukothai.pingtel.com> <44ADF4E9.5000305@cisco.com> <1152802404.2840.81.camel@localhost.localdomain> <3c17e6330e8571d304ba52b461a628d2@telio.no> In-Reply-To: <3c17e6330e8571d304ba52b461a628d2@telio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2006 19:25:23.0186 (UTC) FILETIME=[161A7520:01C6A6B2] DKIM-Signature: a=rsa-sha1; q=dns; l=3983; t=1152818725; x=1153682725; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Size=20of=20message/sipfrag=20in=20diagnostic=20response s; X=v=3Dcisco.com=3B=20h=3Dw39RYcUHqymjuRFCILGaT9ojwZo=3D; b=aVJ/JtkVp9gLgQg50QoBebDZx1yk0MrMDL3jy1rFfwqNHIShO1kQrHn8vtNrmHPxLnCy8zbR qzk15+rGhBREBAChxKTf8/896vn3hwTs0Ttn6Kfv7mhS7gIYLfiSyW2G; Authentication-Results: sj-dkim-3.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a function we want to be implemented universally in proxies. So we don't want to raise the bar at all high. Incorporating a web server into every proxy seems to raise the bar. And retaining the message so it can be retrieved, without any clear idea how long that will be is another problem. There is a lot of attraction to just sending the response and forgetting it. Paul Hisham Khartabil wrote: > Another option is to return, in the 4xx response, an http URI pointing > to a place where the server has stored the request. The requester can > then go and pull the SIP request. > > Might be an issue to interdomain cases, but not sure. > > Hisham > > On Jul 13, 2006, at 4:53 PM, Scott Lawrence wrote: > >> One of the open issues with draft-ietf-hop-limit-diagnostics-0x (for all >> x <= 3) is that the response will usually be very large. If any hop in >> the path is UDP, and the large response reaches that point, it may be >> fragmented into so many parts that it: >> - causes congestion problems in the reverse direction >> - fails reassembly (resulting in no response at all and >> triggering retries) >> Since either of these problems is arguably worse than not getting good >> diagnostic information, we have concluded that something different needs >> to be done. >> >> I've spent some time trying to sort through the various suggestions on >> how to cope with this, and I think that the simplest one is the best. I >> propose something like the following for the next revision of the draft: >> >> When sending an error response that has a message/sipfrag body, >> the responding server MUST examine all the Via header values in >> the request. If any Via header value specifies UDP, then the >> total size of the response body MUST NOT be greater than 200 >> bytes and the server MUST follow the procedures in section X to >> prune the returned message/sipfrag body to fit within this >> limit. If no request Via header value specifies UDP, then the >> server is free to either prune the returned message/sipfrag body >> as specified in section X or to return the full set of request >> headers. >> >> Even though this falls short of providing as much diagnostic information >> as I'd like, I think that this is the best chance of getting _some_ >> useful information back to both the originator and to the proxies along >> the path. It means that you have a better chance of getting better >> diagnostic information when you use TCP, and I think that may actually >> provide an incentive that's in a good direction anyway. >> >> The above text does not attempt to solve the general problem of SIP >> response size; it is deliberately limited to the class of diagnostic >> responses this draft is advocating. I think that the SIP WG should try >> to actually specify general rules for response sizes, but I would rather >> decouple that from making this diagnostic information available. >> >> -- >> Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com >> sipXpbx project coordinator - SIPfoundry >> http://www.sipfoundry.org/sipX >> Chief Architect - Pingtel Corp. http://www.pingtel.com/ >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 15:48:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G178d-0004Q2-HP; Thu, 13 Jul 2006 15:46:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G178d-0004Px-1O for sip@ietf.org; Thu, 13 Jul 2006 15:46:19 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G178b-0003V4-PD for sip@ietf.org; Thu, 13 Jul 2006 15:46:19 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6DJkC417705; Thu, 13 Jul 2006 15:46:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE:[Sip] Size of message/sipfrag in diagnostic responses Date: Thu, 13 Jul 2006 14:46:06 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D3BBE38@zrc2hxm2.corp.nortel.com> In-Reply-To: <002501c6a6a9$12f863b0$d30bdb84@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:[Sip] Size of message/sipfrag in diagnostic responses thread-index: AcamkiyUQ0S7QwnURuC1dFgtItprNQAFbWhQAAMLqbA= From: "Samir Srivastava" To: "Hadriel Kaplan" , "Hisham Khartabil" , "Scott Lawrence" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline. > -----Original Message-----=20 > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Thursday, July 13, 2006 2:21 PM > To: 'Hisham Khartabil'; 'Scott Lawrence' > Cc: 'SIP WG List' > Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses >=20 > Hi Hisham, > I don't like the http URI concept for that because of the=20 > security, performance, and reachability issues. I imagine=20 > that intermediate nodes in the return path may well want to=20 > log the diags info for certain response failures, without=20 > user intervention. With a mime attachment no problem (well,=20 > no more than other sip/mime issues). With an http uri it's=20 > an issue for a bunch of probably obvious reasons. I'd rather=20 > not have to create diags/logs for the diags problems. :)=20 > Cheers, -hadriel >=20 SS>> Nobody wants to handle cascaded faults, diagnostics. If http operation fails, that's it. Stop. Apart from security concerns (Which may be asserted with SAML etc, I am not sure as of now), what other concerns you have. Thx Samir << Removed unrelated stuff >>=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 15:54:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17EP-0007LT-5C; Thu, 13 Jul 2006 15:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17EM-0007KD-TE for sip@ietf.org; Thu, 13 Jul 2006 15:52:14 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G17EG-0003yV-6I for sip@ietf.org; Thu, 13 Jul 2006 15:52:14 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id D0D546C032; Thu, 13 Jul 2006 14:51:13 -0400 (EDT) Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses From: Scott Lawrence To: Samir Srivastava In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60D3BBE07@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60D3BBE07@zrc2hxm2.corp.nortel.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Thu, 13 Jul 2006 15:51:16 -0400 Message-Id: <1152820276.2850.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > On Thu, 2006-07-13 at 17:47 +0200, Jeroen van Bemmel wrote: > > > gzip on the body might help too > > > > If I'm not mistaken, it's not trivial to figure out how much > > any given text will compress with gzip unless you actually > > try each possibility. > > > > I'd rather preserve the human-readability and get one fewer headers. > > > > Also, it doesn't do all that well on short inputs. On Thu, 2006-07-13 at 14:35 -0500, Samir Srivastava wrote: > SS>> Gzip can achieve good compression ratio, if there are loops and > hop (RR, Via ) entries are repeated multiple times. Or should it be for > sigcomp ?? My point was that the output of the gzip compression would have to be less than 201 bytes. You can't just truncate gzip output at any byte boundary, so you'd have to select some part of the message to compress and see if you got <201, then try again if you didn't, etc. Too complex. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 16:06:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17Q3-0002Tg-B1; Thu, 13 Jul 2006 16:04:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17Q1-0002Tb-Ao for sip@ietf.org; Thu, 13 Jul 2006 16:04:17 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G17Q0-00054U-27 for sip@ietf.org; Thu, 13 Jul 2006 16:04:17 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6DJoKd23711; Thu, 13 Jul 2006 15:50:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses Date: Thu, 13 Jul 2006 14:50:20 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D3BBE58@zrc2hxm2.corp.nortel.com> In-Reply-To: <44B69E21.60402@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Size of message/sipfrag in diagnostic responses thread-index: AcamtM7lNG1SV+JOQZ6hgpzXRRMDEQAAEF8w From: "Samir Srivastava" To: "Paul Kyzivat" , "Hisham Khartabil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Fine. So what options are left ? Only compression or prunning. IMHO, how proxies are configured. They must be having the web interface for the configuration. Or they are just plain old vanila text file/cmd line configuration entities. Thx Samir=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Thursday, July 13, 2006 3:25 PM > To: Hisham Khartabil > Cc: SIP WG List > Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses >=20 > This is a function we want to be implemented universally in=20 > proxies. So we don't want to raise the bar at all high.=20 > Incorporating a web server into every proxy seems to raise=20 > the bar. And retaining the message so it can be retrieved,=20 > without any clear idea how long that will be is another=20 > problem. There is a lot of attraction to just sending the=20 > response and forgetting it. >=20 > Paul >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 16:20:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17dp-0000Sf-S6; Thu, 13 Jul 2006 16:18:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17do-0000Sa-VB for sip@ietf.org; Thu, 13 Jul 2006 16:18:32 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G17dn-0005fw-Mu for sip@ietf.org; Thu, 13 Jul 2006 16:18:32 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6DKISX18400; Thu, 13 Jul 2006 16:18:28 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses Date: Thu, 13 Jul 2006 15:18:28 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D3BBEC5@zrc2hxm2.corp.nortel.com> In-Reply-To: <1152820276.2850.7.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Size of message/sipfrag in diagnostic responses thread-index: AcamtdmnEhVikaEvTviY310tSgYKqAAAFi2w From: "Samir Srivastava" To: "Scott Lawrence" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > My point was that the output of the gzip compression would=20 > have to be less than 201 bytes. You can't just truncate gzip=20 > output at any byte boundary, so you'd have to select some=20 > part of the message to compress and see if you got <201, then=20 > try again if you didn't, etc. Too complex. I was not asking to truncate the compressed output. Options available are 1) use sigcomp everywhere. And everything has limits, so it may not help too in the extreme situations. 2) http indirection 3) At any hop, where proxy finds out that response will be increased further going down, it just rejects the request rightaway asking for a different transport. This check should be done before MAX-FORWARD check. When proxy will be doing this, it will not have to attach the response like in 483 in the body. It is different error code. I am not sure on this what 3261 says. As we are changing the 3261 behaviour for 483 response, can we do this ? Backward compatibility ?? Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 17:05:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18LQ-0001Ox-2a; Thu, 13 Jul 2006 17:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18LO-0001Os-4i for sip@ietf.org; Thu, 13 Jul 2006 17:03:34 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G18LN-0008Pr-My for sip@ietf.org; Thu, 13 Jul 2006 17:03:34 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6DL3Q419589; Thu, 13 Jul 2006 17:03:26 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: question on draft-ietf-sip-fork-loop-fix-02.txt Date: Thu, 13 Jul 2006 16:03:15 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D3BBFA8@zrc2hxm2.corp.nortel.com> In-Reply-To: <44B6636A.7050906@alcatel.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: question on draft-ietf-sip-fork-loop-fix-02.txt thread-index: AcamjzJh3vPWXVQoQEumsH6pFiK1TgACBHnA From: "Samir Srivastava" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, There is draft available for avoiding loops also. http://www.ietf.org/internet-drafts/draft-srivastava-sipping-loop-avoida nce-00.txt It got comments from the group. Refer following threads for the solution to them http://www1.ietf.org/mail-archive/web/sipping/current/msg11084.html http://www1.ietf.org/mail-archive/web/sipping/current/msg11085.html http://www1.ietf.org/mail-archive/web/sipping/current/msg11097.html I will be updating the draft with these. Appreciate your comments also on this. It has nice side effect of checking of SIP reachability at the addition of bindings when they are spanning across the domains i.e. * bindings are not added in vacum * . Thx Samir > -----Original Message----- > From: Thomas.Froment@alcatel.fr [mailto:Thomas.Froment@alcatel.fr]=20 > Sent: Thursday, July 13, 2006 11:15 AM > To: Robert Sparks > Cc: sip@ietf.org > Subject: [Sip] Re: question on draft-ietf-sip-fork-loop-fix-02.txt >=20 > Robert Sparks wrote: > > I have another open issue on the current algorithm (as it=20 > is presented=20 > > in RFC 3261) which suggests that the "Via" header should be added,=20 > > without telling that, of course, the branch parameter should NOT be=20 > > used in Hash calculation (overwise it will always be different and=20 > > loop will never be detected...) > > =20 > > the fork-loop-fix draft (at version -02) _REPLACES_ all of=20 > that text=20 > > in 3261. I don't think the replacement text has the problem=20 > you point=20 > > to does it? > This is the part which mentions the open issues: >=20 > > This second part MUST vary with any field used by the location > > > > service logic in determining where to retarget or forward this > > request. This is necessary to distinguish looped requests from > > spirals by allowing the proxy to recognize if none of the values > > affecting the processing of the request have changed. Hence, The > > second part MUST depend at least on the received=20 > Request-URI and any > > Route header field values in the received request. =20 > Implementers need > > to take care to include all fields used by the location=20 > service logic > > in that particular implementation. > > > > This second part MUST NOT include the request method. CANCEL and > > non-200 ACK requests MUST have the same branch parameter=20 > value as the > > corresponding request they cancel or acknowledge. This branch > > parameter value is used in correlating those requests at=20 > the server > > handling them (see Sections 17.2.3 and 9.2). > I am confused with this part: > there is no more sent-by part of the Via header? why is not=20 > mentionned in the open issue part then? (like for Call-Id=20 > ,toTag, and fromTag which should actually be removed...) >=20 > > Another quick comment on the section 4 of=20 > > draft-ietf-sip-fork-loop-fix-02.txt > >>> 4. Loop Detection Check > >>> > >>> Proxies required to perform loop-detection by RFC-XXXX=20 > (RFC-Editor: > >>> replace XXXX with the RFC number of this document)=20 > MUST perform the > >>> following loop-detection test before forwarding a=20 > request. Each Via > >>> header field value in the request whose sent-by value=20 > matches a=20 > >>> value > >>> placed into previous requests by this proxy MUST be=20 > inspected for=20 > >>> the > >>> "second part" defined in Section 4.2.1 of RFC-XXXX. =20 > This second=20 > >>> part > >>> will not be present if the message was not forked when that Via > >>> header field value was added. If the second field is=20 > present, the > >>> proxy MUST perform the second part calculation described in > >>> Section 4.2.1 of RFC-XXXX on this request and compare=20 > the result to > >>> the value from the Via header field. If these values=20 > are equal, the > >>> request has looped and the proxy MUST reject the=20 > request with a 482 > >>> (Loop Detected) response. If the values differ, the request is > >>> spiraling and processing continues to the next step. > >> The question here is, how do I know that the "second part"=20 > is present? > >> the common practice is to setup a branch with a "minus"=20 > separator, eg: > >> branch=3Dz9hg4bKRANDOMID-LOOPDETECTIONHASH > >> however, it is also common pratice for many implementation=20 > to setup=20 > >> some additionnal information in their branch, also using=20 > the "minus" > >> separator, > >> e.g: > >> branch=3Dz9hG4bKRANDOMID-MYIMPLEMENTATIONSTUFF-LOOPDETECTIONHASH > >> > >> So, since the "presence" of minus (or any other) separator=20 > may not be=20 > >> enough, and in order to be able be sure the "loop=20 > detection part" is=20 > >> here, wouldn't it be useful to setup another kind of=20 > "magic cookie"=20 > >> for that? > > > > So the only thing that will look into the branch for the=20 > second part=20 > > is the thing that put that second part there. > > You don't need to know how anyone else forms their branch parameter=20 > > with respect to this. > > > > Since you put the value in, you know how to recognize whether it's=20 > > there. I don't see importance in making everyone do this=20 > the same way. > because if somebody use -XX at the end of the branch=20 > parameter (and this is common practice), I will have to make=20 > unecessary computation on the incoming request... > One possible solution to avoid this is to have some kind of=20 > magic cookie, or a pre-defined separator... If I decide to=20 > use '--' as separator, unfortunately, it may by used by=20 > somebody else in its branch format (and for something ELSE=20 > than loop detection)... >=20 >=20 >=20 > =20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 17:16:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18WR-00043C-3d; Thu, 13 Jul 2006 17:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18WP-000437-Cz for sip@ietf.org; Thu, 13 Jul 2006 17:14:57 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G18WN-0000e0-22 for sip@ietf.org; Thu, 13 Jul 2006 17:14:57 -0400 Received: from [132.219.30.156] (h1e9c-net84db.lab.risq.net [132.219.30.156] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6DLGhri027385 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 13 Jul 2006 16:16:44 -0500 In-Reply-To: <1152802404.2840.81.camel@localhost.localdomain> References: <1150495197.10237.51.camel@sukothai.pingtel.com> <1151955580.2892.102.camel@sukothai.pingtel.com> <44ADF4E9.5000305@cisco.com> <1152802404.2840.81.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <39781D93-F289-4B58-B384-42B2A405DEC5@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses Date: Thu, 13 Jul 2006 16:14:16 -0500 To: Scott Lawrence X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 13, 2006, at 9:53 AM, Scott Lawrence wrote: > When sending an error response that has a message/sipfrag > body, > the responding server MUST examine all the Via header > values in > the request. If any Via header value specifies UDP, then the > total size of the response body MUST NOT be greater than 200 > bytes and the server MUST follow the procedures in section > X to > prune the returned message/sipfrag body to fit within this > limit. If no request Via header value specifies UDP, then the > server is free to either prune the returned message/sipfrag > body > as specified in section X or to return the full set of request > headers. Since UDP is the default, you may need this to say "Does not specify TCP, TLS, or SCTP". Also, this will still explode in environments where evil topology- hiding functions (common in SBCs) have suppressed the Via header fields. Some people would have me believe that this occurs in most if not all IMS deployments, giving us a low probability that large responses will ever actually work. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 18:07:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19Jc-0004At-LC; Thu, 13 Jul 2006 18:05:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19Jb-0004Ad-0q for sip@ietf.org; Thu, 13 Jul 2006 18:05:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11ks-0005If-GS for sip@ietf.org; Thu, 13 Jul 2006 10:01:26 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G11Y5-0007ik-On for sip@ietf.org; Thu, 13 Jul 2006 09:48:14 -0400 Received: from frmail28.netfr.alcatel.fr (frmail28.netfr.alcatel.fr [155.132.251.28]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6DDmA7W011556; Thu, 13 Jul 2006 15:48:10 +0200 Received: from [127.0.0.1] ([155.132.188.32]) by frmail28.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006071315480820:7127 ; Thu, 13 Jul 2006 15:48:08 +0200 Message-ID: <44B64F07.4090908@alcatel.fr> Date: Thu, 13 Jul 2006 15:47:51 +0200 From: Thomas.Froment@alcatel.fr User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: rjsparks@nostrum.com X-MIMETrack: Itemize by SMTP Server on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/13/2006 15:48:08, Serialize by Router on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/13/2006 15:48:09, Serialize complete at 07/13/2006 15:48:09 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: -2.6 (--) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org Subject: [Sip] question on draft-ietf-sip-fork-loop-fix-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org After you presented in SIP meeting the 3 open issues of current SIP loop detection algorithm which are identified in sip-fork-loop-fix: > Open Issue 1 : Why do all the Route header field values need to be > included? Only the top two in the received request will normally > influence processing (in general, the topmost and any others this > proxy removes from the message, plus the topmost in the message > the proxy emits). Can we simplify this to only include those > Route header field values that actually affect the processing of > the message? > Open Issue 2 : RFC 3261 recommends Call-ID, To-tag, and From-tag and > CSeq be included in this second part. Why? This are guaranteed > to be invariant each time the request passes through this proxy. > Further the created value will only be compared with Vias received > from previous times the request went through this proxy, so there > is no possibility of comparing this value with a hash created from > some other request with a different Call-ID, To-tag, or From-tag > or CSeq. I've removed these fields from the recommended set for > this version of the draft. > Do we agree on these two? > Open Issue 3 : RFC 3261 recommends including any Proxy-Require and > Proxy-Authorization header field values in the second part. Why > it it valuable to call these out as special cases? What is the > use case where they will be the only thing in a message returning > to a proxy that varies, making the return a spiral instead of a > loop? I haven't been able to remember the motivation - we need to > re-identify that and capture it here or remove the text making > these anything other than a case covered by the abstract "fields > used by the location service logic". This draft is taking the > second option. I think Jonathan noticed during the meeting that he remembers a good reason to keep Proxy-Require and Proxy-Authorization, but I am not sure to know what is the final decision on this open issue. I have another open issue on the current algorithm (as it is presented in RFC 3261) which suggests that the "Via" header should be added, without telling that, of course, the branch parameter should NOT be used in Hash calculation (overwise it will always be different and loop will never be detected...) Another quick comment on the section 4 of draft-ietf-sip-fork-loop-fix-02.txt > 4. Loop Detection Check > > Proxies required to perform loop-detection by RFC-XXXX (RFC-Editor: > replace XXXX with the RFC number of this document) MUST perform the > following loop-detection test before forwarding a request. Each Via > header field value in the request whose sent-by value matches a value > placed into previous requests by this proxy MUST be inspected for the > "second part" defined in Section 4.2.1 of RFC-XXXX. This second part > will not be present if the message was not forked when that Via > header field value was added. If the second field is present, the > proxy MUST perform the second part calculation described in > Section 4.2.1 of RFC-XXXX on this request and compare the result to > the value from the Via header field. If these values are equal, the > request has looped and the proxy MUST reject the request with a 482 > (Loop Detected) response. If the values differ, the request is > spiraling and processing continues to the next step. The question here is, how do I know that the "second part" is present? the common practice is to setup a branch with a "minus" separator, eg: branch=z9hg4bKRANDOMID-LOOPDETECTIONHASH however, it is also common pratice for many implementation to setup some additionnal information in their branch, also using the "minus" separator, e.g: branch=z9hG4bKRANDOMID-MYIMPLEMENTATIONSTUFF-LOOPDETECTIONHASH So, since the "presence" of minus (or any other) separator may not be enough, and in order to be able be sure the "loop detection part" is here, wouldn't it be useful to setup another kind of "magic cookie" for that? Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 18:57:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1A5e-0002Jq-2M; Thu, 13 Jul 2006 18:55:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1A5c-0002Jl-V5 for sip@ietf.org; Thu, 13 Jul 2006 18:55:24 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1A5b-0003Rk-Jy for sip@ietf.org; Thu, 13 Jul 2006 18:55:24 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2006 15:55:23 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DMtNZ2011431; Thu, 13 Jul 2006 15:55:23 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DMtHJm020183; Thu, 13 Jul 2006 15:55:23 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 15:55:18 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.113.206]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 15:55:16 -0700 Message-Id: <4.3.2.7.2.20060713174710.02763c40@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Jul 2006 17:55:16 -0500 To: Henning Schulzrinne , sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] Location header In-Reply-To: <66662E19-867B-4B7D-AE82-D1F907EB8940@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 13 Jul 2006 22:55:17.0485 (UTC) FILETIME=[68E3F9D0:01C6A6CF] DKIM-Signature: a=rsa-sha1; q=dns; l=2179; t=1152831323; x=1153695323; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20Location=20header; X=v=3Dcisco.com=3B=20h=3DYE8qwqfS5T4Lc8n1KWqZhwTwo7I=3D; b=XjcQJJ3LGUAxKeMEJrKg5Hoc5W6yg+h//O1Z46LYycZ8immzwwo+wA2Vp2WG9PnzoZcK/HjB gilJnEIKCNM+HnjHRolzXBGK5tV1JxM5BNgDHWwDxSDf6x4vsc1ts5jt; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Right now, the ID lists options 1 and 2 as the only options, and this keeps things simple. There have been a couple of comments here in Montreal that adding a data URL isn't really wanted. One reason given is the inability to encrypt it (easily). A message body can be encypted using S/MIME, and a URI can have the server posessing the PIDF-LO configured to challenge a dereference request - including responding with an encrypted PIDF-LO. Both these senarios have the PIDF-LO being able to be encrypted. I'm not so sure encrypting the data URL is so straightforward, or deployable. Others, please inform me and the list if this is untrue. Cannot the ID proceed as is (in this respect), and once someone wants to extend this doc (once it's an RFC), propose that extention as a separate ID? At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: >To follow up on the discussion in the SIP group. I think there are >roughly three options for the content of Location: > >(1) Point to content in the body --> can't be modified and cannot be >inserted by proxies (and may not be inspectable by proxies if encrypted) > >(2) Point to external location --> can be modified, can be added, but >can induce loops if changed in mid-stream and incurs another failure >mode (and possible security risks if the reference is generally >accessible) > >(3) Point to data URL (RFC 2397) as in > >Location: data:application/pidf+xml;base64, >Disadvantage: about 30% larger than as body; can't be encrypted >separately (except as XML-DSIG) > >Advantages: can be inserted/modified by proxies (similar to (2)), but >avoids difficulty of external reference > >I think these three methods all have different time-space-flexibility >trade-offs and thus I suspect they all serve a need. > >Henning > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 19:10:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1AIr-0005Dj-LW; Thu, 13 Jul 2006 19:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1AIq-0005De-K8 for sip@ietf.org; Thu, 13 Jul 2006 19:09:04 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1AIp-0004Jb-Bi for sip@ietf.org; Thu, 13 Jul 2006 19:09:04 -0400 Received: from [132.219.26.162] (h1aa2-net84db.lab.risq.net [132.219.26.162] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6DN8vUA019266 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 13 Jul 2006 19:09:02 -0400 (EDT) In-Reply-To: <4.3.2.7.2.20060713174710.02763c40@email.cisco.com> References: <4.3.2.7.2.20060713174710.02763c40@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] Location header Date: Thu, 13 Jul 2006 19:08:51 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think as long as the location information is used for routing (the only reason to have a Location header at all), the encryption argument is of dubious utility. I don't see any realistic possibility that the UAC can predict the public key of some intermediary router - by definition, by making routing dependent on location, you don't know where the request will end up. If you did, you'd put that address in the request-URI and only the UAS would have to know location (in which case we don't need the location header). Henning On Jul 13, 2006, at 6:55 PM, James M. Polk wrote: > Right now, the ID lists options 1 and 2 as the only options, and > this keeps things simple. There have been a couple of comments > here in Montreal that adding a data URL isn't really wanted. > > One reason given is the inability to encrypt it (easily). A > message body can be encypted using S/MIME, and a URI can have the > server posessing the PIDF-LO configured to challenge a dereference > request - including responding with an encrypted PIDF-LO. Both > these senarios have the PIDF-LO being able to be encrypted. I'm > not so sure encrypting the data URL is so straightforward, or > deployable. Others, please inform me and the list if this is untrue. > > Cannot the ID proceed as is (in this respect), and once someone > wants to extend this doc (once it's an RFC), propose that extention > as a separate ID? > > At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: >> To follow up on the discussion in the SIP group. I think there are >> roughly three options for the content of Location: >> >> (1) Point to content in the body --> can't be modified and cannot be >> inserted by proxies (and may not be inspectable by proxies if >> encrypted) >> >> (2) Point to external location --> can be modified, can be added, but >> can induce loops if changed in mid-stream and incurs another failure >> mode (and possible security risks if the reference is generally >> accessible) >> >> (3) Point to data URL (RFC 2397) as in >> >> Location: data:application/pidf+xml;base64,> PIDF-LO) >> >> Disadvantage: about 30% larger than as body; can't be encrypted >> separately (except as XML-DSIG) >> >> Advantages: can be inserted/modified by proxies (similar to (2)), but >> avoids difficulty of external reference >> >> I think these three methods all have different time-space-flexibility >> trade-offs and thus I suspect they all serve a need. >> >> Henning >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 19:26:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1AYJ-0000dJ-Ej; Thu, 13 Jul 2006 19:25:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1AYI-0000dD-EU for sip@ietf.org; Thu, 13 Jul 2006 19:25:02 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1AYH-0005UU-0Q for sip@ietf.org; Thu, 13 Jul 2006 19:25:02 -0400 Received: (qmail invoked by alias); 13 Jul 2006 23:24:59 -0000 Received: from h1f81-net84db.lab.risq.net (EHLO [132.219.31.129]) [132.219.31.129] by mail.gmx.net (mp037) with SMTP; 14 Jul 2006 01:24:59 +0200 X-Authenticated: #29516787 Message-ID: <44B6D64E.80909@gmx.net> Date: Thu, 13 Jul 2006 19:25:02 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Sip] Location header References: <4.3.2.7.2.20060713174710.02763c40@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060713174710.02763c40@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: sip@ietf.org, Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi James, please explain me the difference (from a security point of view) between * adding a location object into the header that is not encrypted, and * adding a reference to a location object to the header that can be resolved into a location object by everyone that knows the reference? Ciao Hannes James M. Polk wrote: > Right now, the ID lists options 1 and 2 as the only options, and this > keeps things simple. There have been a couple of comments here in > Montreal that adding a data URL isn't really wanted. > > One reason given is the inability to encrypt it (easily). A message > body can be encypted using S/MIME, and a URI can have the server > posessing the PIDF-LO configured to challenge a dereference request - > including responding with an encrypted PIDF-LO. Both these senarios > have the PIDF-LO being able to be encrypted. I'm not so sure encrypting > the data URL is so straightforward, or deployable. Others, please > inform me and the list if this is untrue. > > Cannot the ID proceed as is (in this respect), and once someone wants to > extend this doc (once it's an RFC), propose that extention as a separate > ID? > > At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: > >> To follow up on the discussion in the SIP group. I think there are >> roughly three options for the content of Location: >> >> (1) Point to content in the body --> can't be modified and cannot be >> inserted by proxies (and may not be inspectable by proxies if encrypted) >> >> (2) Point to external location --> can be modified, can be added, but >> can induce loops if changed in mid-stream and incurs another failure >> mode (and possible security risks if the reference is generally >> accessible) >> >> (3) Point to data URL (RFC 2397) as in >> >> Location: data:application/pidf+xml;base64,> >> Disadvantage: about 30% larger than as body; can't be encrypted >> separately (except as XML-DSIG) >> >> Advantages: can be inserted/modified by proxies (similar to (2)), but >> avoids difficulty of external reference >> >> I think these three methods all have different time-space-flexibility >> trade-offs and thus I suspect they all serve a need. >> >> Henning >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 19:33:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Aeg-0001Yi-7b; Thu, 13 Jul 2006 19:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Aee-0001Yb-SH for sip@ietf.org; Thu, 13 Jul 2006 19:31:36 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Aed-0005iD-I1 for sip@ietf.org; Thu, 13 Jul 2006 19:31:36 -0400 Received: from hkaplan [207.164.135.125] by acmepacket.com with ESMTP (SMTPD-9.03) id A7C6034C; Thu, 13 Jul 2006 19:31:18 -0400 From: "Hadriel Kaplan" To: "'Dean Willis'" , "'Scott Lawrence'" Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses Date: Thu, 13 Jul 2006 19:31:08 -0400 Message-ID: <003101c6a6d4$6bbb6a80$17e8a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <39781D93-F289-4B58-B384-42B2A405DEC5@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: AcamwWiSdwHPir89TimhoW8wTDNefgAD0hbA X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'SIP WG List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That's not a problem, in terms of fragmentation. They'll probably strip the attachment anyway. Or at least that's my guess. (I tried to say that in the meeting) I don't see much choice - it's too obvious a place to have all sorts of internal sensitive headers exposed. (for example, generate a request into an IMS network that you know will fail and trigger this diags response, and learn about P-headers and trunk-group-ids and other fun things) It's called topology hiding for a reason. :) One could argue the most likely party capable of actually rectifying the problem which caused the response is the same IMS network operator who strips them. So as long as the stripping device logged them they'll at least have the info. (hence my previous email on logging them on proxies) -hadriel > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Also, this will still explode in environments where evil topology- > hiding functions (common in SBCs) have suppressed the Via header > fields. Some people would have me believe that this occurs in most if > not all IMS deployments, giving us a low probability that large > responses will ever actually work. > > -- > Dean > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 22:06:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1D2e-0001gB-BV; Thu, 13 Jul 2006 22:04:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1D2c-0001em-NP for sip@ietf.org; Thu, 13 Jul 2006 22:04:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G13PA-0003RL-L7 for sip@ietf.org; Thu, 13 Jul 2006 11:47:08 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G13D9-0001C6-0Q for sip@ietf.org; Thu, 13 Jul 2006 11:34:45 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns4.neustar.com (Postfix) with ESMTP id E2CA62AC43; Thu, 13 Jul 2006 15:34:12 +0000 (GMT) Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 11:34:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Location header Date: Thu, 13 Jul 2006 11:34:12 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F44F2@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Location header Thread-Index: AcamDCLeMd4iReHeSkWqne/6qBZYFAAftJlQ From: "Peterson, Jon" To: "Hannes Tschofenig" , "Henning Schulzrinne" X-OriginalArrivalTime: 13 Jul 2006 15:34:12.0622 (UTC) FILETIME=[CA9A5AE0:01C6A691] X-Spam-Score: -5.9 (-----) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, the logical conclusion of this is pretty obvious. Why stop at = PIDF-LO and SAML? Create a Body header, composed of a MIME type and a = base64 encoded body, into which we can place location information, SAML = assertions, SDP, instant messages, or anything else that would = ordinarily be placed into a SIP message body. Deprecate the body of SIP = messages, and our problems will be solved! Of course, the various = Content-* headers would all need to be built into the Body header = eventually, but I'm sure that won't stop us. Rhetoric and layering concerns aside, I think the confidentiality = analysis of header vs. body below is unpersuasive. While it is true that = a body can be encrypted to prevent proxies from inspecting it, that is = surely also true for the base64 encoded blob that would appear in the = Body header, and the rational and circumstances associated with = encrypting either are identical. A pointer to an external location, from = my perspective, has much more interesting and powerful confidentiality = properties than an encrypted blob (be it in a body or a header). There = is no practical way I am aware of that a single body could be = selectively revealed to multiple elements in a SIP message path other = than through such a pointer to an external blob. What I mean is that the = external server could challenge and selectively authorize requests to = fetch the body which originate from various elements in the message = path. Compound this with the "unanticipated recipient" problems = associated with retargeting and you honestly begin to wonder if any = other approach for confidentiality works in SIP. I am also unpersuaded that an external reference is any more likely to = induce loops than proxies using the Body header. After all, if two = proxies keep changing the location information in such a way that it = causes a loop, it hardly matters if that location information is = provided by-reference or by-value - that is a problem with allowing = proxies to modify location information at all. I suspect it is only the integrity differences between header and body = that are material here. Headers can be modified, bodies cannot. For some = bodies, people argue this is a feature, for others a bug. From time to = time people propose a flag signifying "this body can be modified". The = current proposed flag is encoding the body as a header. The general = problem with such flags, however they are cast, is that they are not = themselves integrity-protected, and the recipient of a request has no = way to know who applied the flags. So far, despite numerous challenges = on numerous occasions, this WG has not exhibited a consensus to overturn = the RFC3261 normative language that prevents intermediaries from = changing bodies. In short, I am not convinced that recasting bodies as headers = accomplishes anything further than changing their integrity properties, = and I remain quite skeptical that changing the integrity properties of = bodies is warranted or wise. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, July 12, 2006 7:36 PM > To: Henning Schulzrinne > Cc: sip@ietf.org > Subject: Re: [Sip] Location header >=20 >=20 > Hi Henning, >=20 > I like your idea of using the data URL. > It would work nicely for PIDF-LO and SAML assertions. >=20 > Ciao > Hannes >=20 >=20 > Henning Schulzrinne wrote: > > To follow up on the discussion in the SIP group. I think there are =20 > > roughly three options for the content of Location: > >=20 > > (1) Point to content in the body --> can't be modified and=20 > cannot be =20 > > inserted by proxies (and may not be inspectable by proxies=20 > if encrypted) > >=20 > > (2) Point to external location --> can be modified, can be=20 > added, but =20 > > can induce loops if changed in mid-stream and incurs=20 > another failure =20 > > mode (and possible security risks if the reference is generally =20 > > accessible) > >=20 > > (3) Point to data URL (RFC 2397) as in > >=20 > > Location: data:application/pidf+xml;base64, of PIDF-LO) > >=20 > > Disadvantage: about 30% larger than as body; can't be encrypted =20 > > separately (except as XML-DSIG) > >=20 > > Advantages: can be inserted/modified by proxies (similar to=20 > (2)), but =20 > > avoids difficulty of external reference > >=20 > > I think these three methods all have different=20 > time-space-flexibility =20 > > trade-offs and thus I suspect they all serve a need. > >=20 > > Henning > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 22:20:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1DGY-0004IN-U5; Thu, 13 Jul 2006 22:18:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1DGX-0004IH-Gv for sip@ietf.org; Thu, 13 Jul 2006 22:18:53 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1DGX-0005Op-49 for sip@ietf.org; Thu, 13 Jul 2006 22:18:53 -0400 Received: from [132.219.27.189] (h1bbd-net84db.lab.risq.net [132.219.27.189] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6E2InT3004313 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 13 Jul 2006 22:18:49 -0400 (EDT) In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597054F44F2@stntexch03.cis.neustar.com> References: <24EAE5D4448B9D4592C6D234CBEBD597054F44F2@stntexch03.cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C2FE2A6-2219-4803-A4D1-0A546D420CC7@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] Location header Date: Thu, 13 Jul 2006 22:18:48 -0400 To: "Peterson, Jon" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'll avoid the temptation to pursue the general reductio-ad-absurdio arguments and focus on the proposal at hand. At least from my SIP background, SIP headers are appropriate for material meant for request routing and that are thus meant to be inspected and/or modified by proxies rather than (just) end systems. SDP presumably does not fall into that category, even though SBCs seem to think so. Length or base-64 encoding doesn't seem to be determining factor of the use of a header vs. body since I suspect that the base-64 encoded version of the "Identity" header, to pick one example, will often be larger than the Location header proposal. Thus, the only remaining difference between Location: some pointer to a location object and Location: some location object is the value vs. pointer distinction, i.e., one additional layer of dereferencing. I fail to see the deep architectural implications of this distinction, but maybe these can be explored. The modifiability of the header vs. body is not a major issue since either can be signed (or not). Even in the current conveyance draft, a proxy can simply replace one http pointer with another if it doesn't like the original one, so I again fail to see the major difference. We've discussed pointer vs. value issues in various places such as GEOPRIV, so I don't want to repeat the discussion, particularly since I'm likely to miss some of the arguments. My basic concern about changeability is not the proxies changing the location but the end system having no idea when and how long they need to keep the location information up-to-date and available. In some cases, it's a good idea for a moving object to update its location store, in others (such as routing) it is potentially a bad idea since you could suddenly find yourself at a proxy that doesn't know how to route the request. (Picture a car crossing the county boundary where the internal county PSAP routing is done by a separate proxy.) As a side issue, the draft currently provides no guidance on what kind of properties the referenced location information needs to have (how long to keep, whether it can change or not, etc.). This is more than just specifying HTTP GET. Note that I did not advocate that end systems inserting location information use the data: mechanism, as they don't need to. The by- value case is mostly of interest in the case that we need a proxy to insert location information. Without this case, we wouldn't need the location header at all since proxies could just inspect the message body and find the location information by disposition information. For the case of proxy insertion, the proxy needs to maintain a location store that is accessible by all downstream proxies, by unknown entities and for unknown periods of time, including external (outside-in) traversal of firewalls. It would be nice to have a simpler option for that case. Or are you opposed to proxies inserting location information? If so, I apologize for mis-understanding your basic argument. Henning On Jul 13, 2006, at 11:34 AM, Peterson, Jon wrote: > > Well, the logical conclusion of this is pretty obvious. Why stop at > PIDF-LO and SAML? Create a Body header, composed of a MIME type and > a base64 encoded body, into which we can place location > information, SAML assertions, SDP, instant messages, or anything > else that would ordinarily be placed into a SIP message body. > Deprecate the body of SIP messages, and our problems will be > solved! Of course, the various Content-* headers would all need to > be built into the Body header eventually, but I'm sure that won't > stop us. > > Rhetoric and layering concerns aside, I think the confidentiality > analysis of header vs. body below is unpersuasive. While it is true > that a body can be encrypted to prevent proxies from inspecting it, > that is surely also true for the base64 encoded blob that would > appear in the Body header, and the rational and circumstances > associated with encrypting either are identical. A pointer to an > external location, from my perspective, has much more interesting > and powerful confidentiality properties than an encrypted blob (be > it in a body or a header). There is no practical way I am aware of > that a single body could be selectively revealed to multiple > elements in a SIP message path other than through such a pointer to > an external blob. What I mean is that the external server could > challenge and selectively authorize requests to fetch the body > which originate from various elements in the message path. Compound > this with the "unanticipated recipient" problems associated with > retargeting and you honestly begin to wonder if any other approach > for confidentiality works in SIP. > > I am also unpersuaded that an external reference is any more likely > to induce loops than proxies using the Body header. After all, if > two proxies keep changing the location information in such a way > that it causes a loop, it hardly matters if that location > information is provided by-reference or by-value - that is a > problem with allowing proxies to modify location information at all. > > I suspect it is only the integrity differences between header and > body that are material here. Headers can be modified, bodies > cannot. For some bodies, people argue this is a feature, for others > a bug. From time to time people propose a flag signifying "this > body can be modified". The current proposed flag is encoding the > body as a header. The general problem with such flags, however they > are cast, is that they are not themselves integrity-protected, and > the recipient of a request has no way to know who applied the > flags. So far, despite numerous challenges on numerous occasions, > this WG has not exhibited a consensus to overturn the RFC3261 > normative language that prevents intermediaries from changing bodies. > > In short, I am not convinced that recasting bodies as headers > accomplishes anything further than changing their integrity > properties, and I remain quite skeptical that changing the > integrity properties of bodies is warranted or wise. > > Jon Peterson > NeuStar, Inc. > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, July 12, 2006 7:36 PM >> To: Henning Schulzrinne >> Cc: sip@ietf.org >> Subject: Re: [Sip] Location header >> >> >> Hi Henning, >> >> I like your idea of using the data URL. >> It would work nicely for PIDF-LO and SAML assertions. >> >> Ciao >> Hannes >> >> >> Henning Schulzrinne wrote: >>> To follow up on the discussion in the SIP group. I think there are >>> roughly three options for the content of Location: >>> >>> (1) Point to content in the body --> can't be modified and >> cannot be >>> inserted by proxies (and may not be inspectable by proxies >> if encrypted) >>> >>> (2) Point to external location --> can be modified, can be >> added, but >>> can induce loops if changed in mid-stream and incurs >> another failure >>> mode (and possible security risks if the reference is generally >>> accessible) >>> >>> (3) Point to data URL (RFC 2397) as in >>> >>> Location: data:application/pidf+xml;base64,> of PIDF-LO) >>> >>> Disadvantage: about 30% larger than as body; can't be encrypted >>> separately (except as XML-DSIG) >>> >>> Advantages: can be inserted/modified by proxies (similar to >> (2)), but >>> avoids difficulty of external reference >>> >>> I think these three methods all have different >> time-space-flexibility >>> trade-offs and thus I suspect they all serve a need. >>> >>> Henning >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 23:36:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ESJ-0007Go-3Y; Thu, 13 Jul 2006 23:35:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ESH-0007Gb-KL for sip@ietf.org; Thu, 13 Jul 2006 23:35:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G149I-0005fu-Mq for sip@ietf.org; Thu, 13 Jul 2006 12:34:48 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G13PR-0001Y4-Tz for sip@ietf.org; Thu, 13 Jul 2006 11:47:28 -0400 Received: (qmail 23896 invoked by uid 0); 13 Jul 2006 15:47:18 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 13 Jul 2006 15:47:18 -0000 Message-ID: <00da01c6a693$a0669ac0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Hisham Khartabil" , "Scott Lawrence" References: <1150495197.10237.51.camel@sukothai.pingtel.com><1151955580.2892.102.camel@sukothai.pingtel.com><44ADF4E9.5000305@cisco.com><1152802404.2840.81.camel@localhost.localdomain> <3c17e6330e8571d304ba52b461a628d2@telio.no> Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses Date: Thu, 13 Jul 2006 17:47:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: -2.4 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org gzip on the body might help too Regards, Jeroen ----- Original Message ----- From: "Hisham Khartabil" To: "Scott Lawrence" Cc: "SIP WG List" Sent: Thursday, July 13, 2006 5:21 PM Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses > Another option is to return, in the 4xx response, an http URI pointing > to a place where the server has stored the request. The requester can > then go and pull the SIP request. > > Might be an issue to interdomain cases, but not sure. > > Hisham > > On Jul 13, 2006, at 4:53 PM, Scott Lawrence wrote: > >> One of the open issues with draft-ietf-hop-limit-diagnostics-0x (for >> all >> x <= 3) is that the response will usually be very large. If any hop in >> the path is UDP, and the large response reaches that point, it may be >> fragmented into so many parts that it: >> - causes congestion problems in the reverse direction >> - fails reassembly (resulting in no response at all and >> triggering retries) >> Since either of these problems is arguably worse than not getting good >> diagnostic information, we have concluded that something different >> needs >> to be done. >> >> I've spent some time trying to sort through the various suggestions on >> how to cope with this, and I think that the simplest one is the best. >> I >> propose something like the following for the next revision of the >> draft: >> >> When sending an error response that has a message/sipfrag body, >> the responding server MUST examine all the Via header values in >> the request. If any Via header value specifies UDP, then the >> total size of the response body MUST NOT be greater than 200 >> bytes and the server MUST follow the procedures in section X to >> prune the returned message/sipfrag body to fit within this >> limit. If no request Via header value specifies UDP, then the >> server is free to either prune the returned message/sipfrag >> body >> as specified in section X or to return the full set of request >> headers. >> >> Even though this falls short of providing as much diagnostic >> information >> as I'd like, I think that this is the best chance of getting _some_ >> useful information back to both the originator and to the proxies along >> the path. It means that you have a better chance of getting better >> diagnostic information when you use TCP, and I think that may actually >> provide an incentive that's in a good direction anyway. >> >> The above text does not attempt to solve the general problem of SIP >> response size; it is deliberately limited to the class of diagnostic >> responses this draft is advocating. I think that the SIP WG should try >> to actually specify general rules for response sizes, but I would >> rather >> decouple that from making this diagnostic information available. >> >> -- >> Scott Lawrence tel:+1-781-938-5306;ext=162 or >> sip:slawrence@pingtel.com >> sipXpbx project coordinator - SIPfoundry >> http://www.sipfoundry.org/sipX >> Chief Architect - Pingtel Corp. http://www.pingtel.com/ >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 13 23:48:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1EdL-000115-3Q; Thu, 13 Jul 2006 23:46:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1EdJ-00010h-9v for sip@ietf.org; Thu, 13 Jul 2006 23:46:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12KY-0006yD-9D for sip@ietf.org; Thu, 13 Jul 2006 10:38:18 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G12F6-0008Vt-Cv for sip@ietf.org; Thu, 13 Jul 2006 10:32:41 -0400 Received: from [132.219.30.170] (h1eaa-net84db.lab.risq.net [132.219.30.170] (may be forged)) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6DEWQg7048225 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 13 Jul 2006 09:32:27 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <44B64F07.4090908@alcatel.fr> References: <44B64F07.4090908@alcatel.fr> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Thu, 13 Jul 2006 10:32:29 -0400 To: Thomas.Froment@alcatel.fr X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 132.219.30.170 is authenticated by a trusted mechanism) X-Spam-Score: -2.6 (--) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: sip@ietf.org Subject: [Sip] Re: question on draft-ietf-sip-fork-loop-fix-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 13, 2006, at 9:47 AM, Thomas.Froment@alcatel.fr wrote: > After you presented in SIP meeting the 3 open issues of current SIP > loop detection algorithm which are identified in sip-fork-loop-fix: >> Open Issue 1 : Why do all the Route header field values need to be >> included? Only the top two in the received request will >> normally >> influence processing (in general, the topmost and any others >> this >> proxy removes from the message, plus the topmost in the message >> the proxy emits). Can we simplify this to only include those >> Route header field values that actually affect the >> processing of >> the message? >> Open Issue 2 : RFC 3261 recommends Call-ID, To-tag, and From- >> tag and >> CSeq be included in this second part. Why? This are >> guaranteed >> to be invariant each time the request passes through this >> proxy. >> Further the created value will only be compared with Vias >> received >> from previous times the request went through this proxy, so >> there >> is no possibility of comparing this value with a hash >> created from >> some other request with a different Call-ID, To-tag, or From- >> tag >> or CSeq. I've removed these fields from the recommended set >> for >> this version of the draft. >> > Do we agree on these two? >> Open Issue 3 : RFC 3261 recommends including any Proxy-Require >> and >> Proxy-Authorization header field values in the second part. >> Why >> it it valuable to call these out as special cases? What is the >> use case where they will be the only thing in a message >> returning >> to a proxy that varies, making the return a spiral instead of a >> loop? I haven't been able to remember the motivation - we >> need to >> re-identify that and capture it here or remove the text making >> these anything other than a case covered by the abstract >> "fields >> used by the location service logic". This draft is taking the >> second option. > I think Jonathan noticed during the meeting that he remembers a > good reason to keep Proxy-Require and Proxy-Authorization, but I am > not sure to know what is the final decision on this open issue. > > I have another open issue on the current algorithm (as it is > presented in RFC 3261) which suggests that the "Via" header should > be added, > without telling that, of course, the branch parameter should NOT be > used in Hash calculation (overwise it will always be different and > loop will never be detected...) the fork-loop-fix draft (at version -02) _REPLACES_ all of that text in 3261. I don't think the replacement text has the problem you point to does it? > > > Another quick comment on the section 4 of draft-ietf-sip-fork-loop- > fix-02.txt >> 4. Loop Detection Check >> >> Proxies required to perform loop-detection by RFC-XXXX (RFC- >> Editor: >> replace XXXX with the RFC number of this document) MUST perform >> the >> following loop-detection test before forwarding a request. >> Each Via >> header field value in the request whose sent-by value matches a >> value >> placed into previous requests by this proxy MUST be inspected >> for the >> "second part" defined in Section 4.2.1 of RFC-XXXX. This >> second part >> will not be present if the message was not forked when that Via >> header field value was added. If the second field is present, the >> proxy MUST perform the second part calculation described in >> Section 4.2.1 of RFC-XXXX on this request and compare the >> result to >> the value from the Via header field. If these values are >> equal, the >> request has looped and the proxy MUST reject the request with a >> 482 >> (Loop Detected) response. If the values differ, the request is >> spiraling and processing continues to the next step. > The question here is, how do I know that the "second part" is present? > the common practice is to setup a branch with a "minus" separator, eg: > branch=z9hg4bKRANDOMID-LOOPDETECTIONHASH > however, it is also common pratice for many implementation to setup > some additionnal information in their branch, also using the > "minus" separator, > e.g: > branch=z9hG4bKRANDOMID-MYIMPLEMENTATIONSTUFF-LOOPDETECTIONHASH > > So, since the "presence" of minus (or any other) separator may not > be enough, and in order to be able be sure the "loop detection > part" is here, > wouldn't it be useful to setup another kind of "magic cookie" for > that? So the only thing that will look into the branch for the second part is the thing that put that second part there. You don't need to know how anyone else forms their branch parameter with respect to this. Since you put the value in, you know how to recognize whether it's there. I don't see importance in making everyone do this the same way. RjS > > Thomas > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 01:03:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1FoN-0006pC-4S; Fri, 14 Jul 2006 01:01:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1FoM-0006p7-25 for sip@ietf.org; Fri, 14 Jul 2006 01:01:58 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1FoK-0005lv-Q0 for sip@ietf.org; Fri, 14 Jul 2006 01:01:58 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6E512b26079; Fri, 14 Jul 2006 01:01:03 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses Date: Fri, 14 Jul 2006 00:01:00 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com> In-Reply-To: <00da01c6a693$a0669ac0$31713b51@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Size of message/sipfrag in diagnostic responses thread-index: Acam9pJOFEIPzvTqTwSTJK5SavSyugAC0J3Q From: "Samir Srivastava" To: "Jeroen van Bemmel" , "Hisham Khartabil" , "Scott Lawrence" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Joren, If it is good case where all hops are different, what will be the compression ratio ? If it is looping/spiraling, then it will be having good compression ratio for 483.=20 What about in general (No hop limit use case, no body in the response) where response size is big ? Thx Samir =20 > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: Thursday, July 13, 2006 11:47 AM > To: Hisham Khartabil; Scott Lawrence > Cc: SIP WG List > Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses >=20 > gzip on the body might help too >=20 > Regards, >=20 > Jeroen >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 01:30:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1GEV-0001Ca-1d; Fri, 14 Jul 2006 01:28:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1GET-0001CV-GD for sip@ietf.org; Fri, 14 Jul 2006 01:28:57 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1GER-00023S-3s for sip@ietf.org; Fri, 14 Jul 2006 01:28:57 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 13 Jul 2006 22:28:54 -0700 X-IronPort-AV: i="4.06,239,1149490800"; d="scan'208"; a="305736670:sNHT27560356" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6E5SsMx025532; Thu, 13 Jul 2006 22:28:54 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6E5SuHS008407; Thu, 13 Jul 2006 22:28:56 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 22:28:53 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.153.109]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 22:28:53 -0700 Message-Id: <4.3.2.7.2.20060714002144.03a291f8@email.cisco.com> X-Sender: jmpolk@email.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2006 00:28:47 -0500 To: Hannes Tschofenig From: "James M. Polk" Subject: Re: [Sip] Location header In-Reply-To: <44B6D64E.80909@gmx.net> References: <4.3.2.7.2.20060713174710.02763c40@email.cisco.com> <4.3.2.7.2.20060713174710.02763c40@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Jul 2006 05:28:53.0332 (UTC) FILETIME=[65084140:01C6A706] DKIM-Signature: a=rsa-sha1; q=dns; l=3357; t=1152854934; x=1153718934; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20Location=20header; X=v=3Dcisco.com=3B=20h=3DYE8qwqfS5T4Lc8n1KWqZhwTwo7I=3D; b=Q0vvwIZCAQqTueWJQOmAQvTykwbPNusTFJJIfXfHE+anOTGJT14FYnkNTZ9CT2JOlUwBO8tC XXW6mvgT/cXWzxT3qDPtsCrMRNsC5R4c+IMo+q8I+axBSHb/hPGlYLn8; Authentication-Results: sj-dkim-7.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: sip@ietf.org, Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 07:25 PM 7/13/2006 -0400, Hannes Tschofenig wrote: >Hi James, > >please explain me the difference (from a security point of view) between >* adding a location object into the header that is not encrypted, and >* adding a reference to a location object to the header that can be >resolved into a location object by everyone that knows the reference? The server which has the by-referenced PIDF-LO can challenge whoever asks for the PIDF-LO. The header URI allows for each intermediary to ask for the dereference, but only those that have permission, surviving the challenge(s), get the PIDF-LO. This means not all dereference attempts learn the UAC's location. This cannot be accomplished in a header. >Ciao >Hannes > >James M. Polk wrote: >>Right now, the ID lists options 1 and 2 as the only options, and this >>keeps things simple. There have been a couple of comments here in >>Montreal that adding a data URL isn't really wanted. >>One reason given is the inability to encrypt it (easily). A message >>body can be encypted using S/MIME, and a URI can have the server >>posessing the PIDF-LO configured to challenge a dereference request - >>including responding with an encrypted PIDF-LO. Both these senarios have >>the PIDF-LO being able to be encrypted. I'm not so sure encrypting the >>data URL is so straightforward, or deployable. Others, please inform me >>and the list if this is untrue. >>Cannot the ID proceed as is (in this respect), and once someone wants to >>extend this doc (once it's an RFC), propose that extention as a separate ID? >>At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: >> >>>To follow up on the discussion in the SIP group. I think there are >>>roughly three options for the content of Location: >>> >>>(1) Point to content in the body --> can't be modified and cannot be >>>inserted by proxies (and may not be inspectable by proxies if encrypted) >>> >>>(2) Point to external location --> can be modified, can be added, but >>>can induce loops if changed in mid-stream and incurs another failure >>>mode (and possible security risks if the reference is generally >>>accessible) >>> >>>(3) Point to data URL (RFC 2397) as in >>> >>>Location: data:application/pidf+xml;base64,>> >>>Disadvantage: about 30% larger than as body; can't be encrypted >>>separately (except as XML-DSIG) >>> >>>Advantages: can be inserted/modified by proxies (similar to (2)), but >>>avoids difficulty of external reference >>> >>>I think these three methods all have different time-space-flexibility >>>trade-offs and thus I suspect they all serve a need. >>> >>>Henning >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 02:58:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1HbF-0001ka-2P; Fri, 14 Jul 2006 02:56:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1HbD-0001kS-Du for sip@ietf.org; Fri, 14 Jul 2006 02:56:31 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1HbC-0005S9-0j for sip@ietf.org; Fri, 14 Jul 2006 02:56:31 -0400 Received: (qmail 16816 invoked by uid 0); 14 Jul 2006 06:56:28 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 14 Jul 2006 06:56:28 -0000 Message-ID: <002001c6a712$9ecb95b0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Samir Srivastava" , "Hisham Khartabil" , "Scott Lawrence" References: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com> Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses Date: Fri, 14 Jul 2006 08:56:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir, I was thinking specifically for the 483 case, reporting the via sequence. You have {200 + the size of the original body + request headers that you can omit + savings from using short header forms} to respond with, perhaps a simple text-based run-length encoding scheme could work as well. E.g. 111.222.111.222:1234/UDP,111.222.111.223:1234/UDP,17(111.222.111.224:1234/UDP,111.222.111.225:1234/UDP),17(111.222.111.224:1234/TCP,111.222.111.225:1234/TCP) FQDNs could be slightly longer, but assuming about 40 bytes per entry, you could report at least 5 (omitting the last one (UA itself) and the one-but-last one, since the UA will know those). Perhaps omitting the transport (port too?) (UA will know initial transport, if required only the moment of transistion could be encoded). Then you could report 10 entries easily. Add to that a string host encoding: 1=111.222.111.222:1234 2=111.222.111.223:1234 3=111.222.111.224:1234 4=111.222.111.225:1234 1,2,34(3,4) Regards, Jeroen ----- Original Message ----- From: "Samir Srivastava" To: "Jeroen van Bemmel" ; "Hisham Khartabil" ; "Scott Lawrence" Cc: "SIP WG List" Sent: Friday, July 14, 2006 7:01 AM Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses Joren, If it is good case where all hops are different, what will be the compression ratio ? If it is looping/spiraling, then it will be having good compression ratio for 483. What about in general (No hop limit use case, no body in the response) where response size is big ? Thx Samir > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Thursday, July 13, 2006 11:47 AM > To: Hisham Khartabil; Scott Lawrence > Cc: SIP WG List > Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses > > gzip on the body might help too > > Regards, > > Jeroen > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 03:15:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Hrt-0002Xm-Tc; Fri, 14 Jul 2006 03:13:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Hrs-0002Xe-Uu for sip@ietf.org; Fri, 14 Jul 2006 03:13:44 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Hrr-00066L-Kl for sip@ietf.org; Fri, 14 Jul 2006 03:13:44 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6E7Db801456; Fri, 14 Jul 2006 03:13:38 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses Date: Fri, 14 Jul 2006 02:13:20 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2D4@zrc2hxm2.corp.nortel.com> In-Reply-To: <002001c6a712$9ecb95b0$31713b51@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Size of message/sipfrag in diagnostic responses thread-index: AcanEqrWKLmyNjjVRi6RExroRqxwqgAAf/wg From: "Samir Srivastava" To: "Jeroen van Bemmel" , "Hisham Khartabil" , "Scott Lawrence" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, There was discussion in the meeting, whether response message exceeding should be fixed in general or 483 only. Chairs (Dean) said that Hop limit diagnostics cannot move without that fix. Thx Samir=20 > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: Friday, July 14, 2006 2:56 AM > To: Srivastava, Samir (SC100:8826); Hisham Khartabil; Scott Lawrence > Cc: SIP WG List > Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses >=20 > Samir, >=20 > I was thinking specifically for the 483 case, reporting the=20 > via sequence. >=20 > You have {200 + the size of the original body + request=20 > headers that you can omit + savings from using short header=20 > forms} to respond with, perhaps a simple text-based=20 > run-length encoding scheme could work as well. >=20 > E.g. >=20 > 111.222.111.222:1234/UDP,111.222.111.223:1234/UDP,17(111.222.1 > 11.224:1234/UDP,111.222.111.225:1234/UDP),17(111.222.111.224:1 > 234/TCP,111.222.111.225:1234/TCP) >=20 > FQDNs could be slightly longer, but assuming about 40 bytes=20 > per entry, you could report at least 5 (omitting the last one=20 > (UA itself) and the one-but-last one, since the UA will know=20 > those). Perhaps omitting the transport (port too?) (UA will=20 > know initial transport, if required only the moment of=20 > transistion could be encoded). Then you could report 10=20 > entries easily. Add to that a string host encoding: >=20 > 1=3D111.222.111.222:1234 > 2=3D111.222.111.223:1234 > 3=3D111.222.111.224:1234 > 4=3D111.222.111.225:1234 >=20 > 1,2,34(3,4) >=20 > Regards, >=20 > Jeroen >=20 >=20 > ----- Original Message ----- > From: "Samir Srivastava" > To: "Jeroen van Bemmel" ; "Hisham Khartabil"=20 > ; "Scott Lawrence" > Cc: "SIP WG List" > Sent: Friday, July 14, 2006 7:01 AM > Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses >=20 >=20 > Joren, >=20 > If it is good case where all hops are different, what will be the > compression ratio ? >=20 > If it is looping/spiraling, then it will be having good compression > ratio for 483. >=20 > What about in general (No hop limit use case, no body in the response) > where response size is big ? >=20 > Thx > Samir >=20 > > -----Original Message----- > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > Sent: Thursday, July 13, 2006 11:47 AM > > To: Hisham Khartabil; Scott Lawrence > > Cc: SIP WG List > > Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses > > > > gzip on the body might help too > > > > Regards, > > > > Jeroen > > > >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 06:19:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Kjl-0006IE-Ts; Fri, 14 Jul 2006 06:17:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Kjj-0006I9-Di for Sip@ietf.org; Fri, 14 Jul 2006 06:17:31 -0400 Received: from webmail.ptinovacao.pt ([194.65.138.21] helo=inoavrex07.ptin.corpPT.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Kjf-0002rP-Rp for Sip@ietf.org; Fri, 14 Jul 2006 06:17:31 -0400 Received: from INOAVREX05.ptin.corpPT.com ([10.112.15.67]) by inoavrex07.ptin.corpPT.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 11:15:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jul 2006 11:17:23 +0100 Message-ID: <75D349FBF7C131408F5061B7168072C30329DB49@INOAVREX06.ptin.corpPT.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: S-CSCF expected behavior Thread-Index: AcanKohfW6ExbiiZTYaW7GxX5A/+SAAAdtDQAACOIKA= From: =?iso-8859-1?Q?Ant=F3nio_Manuel_Amaral?= To: X-OriginalArrivalTime: 14 Jul 2006 10:15:58.0531 (UTC) FILETIME=[800D0930:01C6A72E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Sip] S-CSCF expected behavior X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear All, I don't know if this is the correct mailing list to put my question and = if not my apologies for that. Consider the following IMS scenario (IMS core Network) -> S-CSCF -> AS If the connection between AS and S-CSCF fails what is the expected = behavior of S-CSCF? It must release all active calls sending BYE = messages to caller and called clients in order to terminate the calls? Thanks in advance Regards AA=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 09:47:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NzK-0001YN-Ux; Fri, 14 Jul 2006 09:45:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NzK-0001YD-55 for sip@ietf.org; Fri, 14 Jul 2006 09:45:50 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1NzI-0007nb-M5 for sip@ietf.org; Fri, 14 Jul 2006 09:45:50 -0400 Received: (qmail invoked by alias); 14 Jul 2006 13:39:08 -0000 Received: from h1f81-net84db.lab.risq.net (EHLO [132.219.31.129]) [132.219.31.129] by mail.gmx.net (mp035) with SMTP; 14 Jul 2006 15:39:08 +0200 X-Authenticated: #29516787 Message-ID: <44B79E7B.2000004@gmx.net> Date: Fri, 14 Jul 2006 09:39:07 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Sip] Location header References: <4.3.2.7.2.20060713174710.02763c40@email.cisco.com> <4.3.2.7.2.20060713174710.02763c40@email.cisco.com> <4.3.2.7.2.20060714002144.03a291f8@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060714002144.03a291f8@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: sip@ietf.org, Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi James, James M. Polk wrote: > At 07:25 PM 7/13/2006 -0400, Hannes Tschofenig wrote: > >> Hi James, >> >> please explain me the difference (from a security point of view) between >> * adding a location object into the header that is not encrypted, and >> * adding a reference to a location object to the header that can be >> resolved into a location object by everyone that knows the reference? > > > The server which has the by-referenced PIDF-LO can challenge whoever > asks for the PIDF-LO. The header URI allows for each intermediary to > ask for the dereference, but only those that have permission, surviving > the challenge(s), get the PIDF-LO. This means not all dereference > attempts learn the UAC's location. This cannot be accomplished in a > header. This would assume that the entity that created the location object has a relationship with the final location recipient (and to share some credential with them). I think that this is a totally unrealistic assumption. Ciao Hannes > > >> Ciao >> Hannes >> >> James M. Polk wrote: >> >>> Right now, the ID lists options 1 and 2 as the only options, and this >>> keeps things simple. There have been a couple of comments here in >>> Montreal that adding a data URL isn't really wanted. >>> One reason given is the inability to encrypt it (easily). A message >>> body can be encypted using S/MIME, and a URI can have the server >>> posessing the PIDF-LO configured to challenge a dereference request - >>> including responding with an encrypted PIDF-LO. Both these senarios >>> have the PIDF-LO being able to be encrypted. I'm not so sure >>> encrypting the data URL is so straightforward, or deployable. >>> Others, please inform me and the list if this is untrue. >>> Cannot the ID proceed as is (in this respect), and once someone wants >>> to extend this doc (once it's an RFC), propose that extention as a >>> separate ID? >>> At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: >>> >>>> To follow up on the discussion in the SIP group. I think there are >>>> roughly three options for the content of Location: >>>> >>>> (1) Point to content in the body --> can't be modified and cannot be >>>> inserted by proxies (and may not be inspectable by proxies if >>>> encrypted) >>>> >>>> (2) Point to external location --> can be modified, can be added, but >>>> can induce loops if changed in mid-stream and incurs another failure >>>> mode (and possible security risks if the reference is generally >>>> accessible) >>>> >>>> (3) Point to data URL (RFC 2397) as in >>>> >>>> Location: data:application/pidf+xml;base64,>>> >>>> Disadvantage: about 30% larger than as body; can't be encrypted >>>> separately (except as XML-DSIG) >>>> >>>> Advantages: can be inserted/modified by proxies (similar to (2)), but >>>> avoids difficulty of external reference >>>> >>>> I think these three methods all have different time-space-flexibility >>>> trade-offs and thus I suspect they all serve a need. >>>> >>>> Henning >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 09:59:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OAU-0006u4-Js; Fri, 14 Jul 2006 09:57:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OAT-0006tr-4O for sip@ietf.org; Fri, 14 Jul 2006 09:57:21 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OAM-0001Ft-T2 for sip@ietf.org; Fri, 14 Jul 2006 09:57:21 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 702426C017; Fri, 14 Jul 2006 08:56:20 -0400 (EDT) Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses From: Scott Lawrence To: Samir Srivastava In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2D4@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2D4@zrc2hxm2.corp.nortel.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Fri, 14 Jul 2006 09:56:21 -0400 Message-Id: <1152885382.2863.40.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Fri, 2006-07-14 at 02:13 -0500, Samir Srivastava wrote: > Hi, > > There was discussion in the meeting, whether response message exceeding > should be fixed in general or 483 only. > > Chairs (Dean) said that Hop limit diagnostics cannot move without that > fix. The guidance I have received is that we cannot proceed with specifying a new diagnostic response behavior without at least limiting the size of the responses it generates for paths that include UDP. We are not required (and have not attempted in the proposed text) to solve the problem of response sizes in general. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 10:20:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OV7-00007L-Mq; Fri, 14 Jul 2006 10:18:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OV5-00006U-Ok for sip@ietf.org; Fri, 14 Jul 2006 10:18:39 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OOJ-0004ZI-PA for sip@ietf.org; Fri, 14 Jul 2006 10:11:45 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id DA9D26C017; Fri, 14 Jul 2006 09:10:44 -0400 (EDT) Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses From: Scott Lawrence To: Samir Srivastava In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60D3BBEC5@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60D3BBEC5@zrc2hxm2.corp.nortel.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Fri, 14 Jul 2006 10:10:46 -0400 Message-Id: <1152886246.2863.56.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Thu, 2006-07-13 at 15:18 -0500, Samir Srivastava wrote: > > My point was that the output of the gzip compression would > > have to be less than 201 bytes. You can't just truncate gzip > > output at any byte boundary, so you'd have to select some > > part of the message to compress and see if you got <201, then > > try again if you didn't, etc. Too complex. > > I was not asking to truncate the compressed output. Options available > are > > 1) use sigcomp everywhere. And everything has limits, so it may not > help too in the extreme situations. I believe that requiring sigcomp support in a proxy in order to provide these responses would be too large a barrier to deployment. I want this to be so easy that lots of implementations will do it quickly. > 2) http indirection I think this has been dealt with. > 3) At any hop, where proxy finds out that response will be increased > further going down, it just rejects the request rightaway asking for a > different transport. This check should be done before MAX-FORWARD check. > When proxy will be doing this, it will not have to attach the response > like in 483 in the body. It is different error code. I am not sure on > this what 3261 says. As we are changing the 3261 behaviour for 483 > response, can we do this ? Backward compatibility ?? There is no way for a proxy to detect that a request would fail further along the path. Yes, we are updating what 3261 says. I have been doing interoperability testing of a variant of these responses for 2 years and (other than the UDP size problem), have not encountered any UA that had a problem with these responses (even ones that had _lots_ of other problems with perfectly valid SIP). -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 10:21:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OVl-0000nU-O2; Fri, 14 Jul 2006 10:19:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OVj-0000kJ-Tl for sip@ietf.org; Fri, 14 Jul 2006 10:19:19 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OGs-0002c3-GX for sip@ietf.org; Fri, 14 Jul 2006 10:04:03 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 51DBB6C017; Fri, 14 Jul 2006 09:03:04 -0400 (EDT) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses From: Scott Lawrence To: Jeroen van Bemmel In-Reply-To: <002001c6a712$9ecb95b0$31713b51@BEMBUSTER> References: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com> <002001c6a712$9ecb95b0$31713b51@BEMBUSTER> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Fri, 14 Jul 2006 10:03:05 -0400 Message-Id: <1152885785.2863.48.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Fri, 2006-07-14 at 08:56 +0200, Jeroen van Bemmel wrote: > Samir, > > I was thinking specifically for the 483 case, reporting the via sequence. This is another issue that I'll start a thread on soon, but I'd like to be able to send this kind of diagnostic response for some other errors as well, and any solution to the size question should, I think, be independent of the error type. > You have {200 + the size of the original body + request headers that you can > omit + savings from using short header forms} to respond with, perhaps a > simple text-based run-length encoding scheme could work as well. I believe that it is important to minimize the manipulation of the returned diagnostic information because that introduces opportunities for the rejecting server to misrepresent the request, which adds to the problem. Pruning the response is (alas) unavoidable given UDP. The message/sipfrag specification (as I understand it) allow for modifying the message only by removing entire headers, and I think that's the most we should do. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 10:21:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OW4-00019j-3q; Fri, 14 Jul 2006 10:19:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OW2-00019Z-Ep for sip@ietf.org; Fri, 14 Jul 2006 10:19:38 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1OW1-0005xe-RT for sip@ietf.org; Fri, 14 Jul 2006 10:19:38 -0400 Received: (qmail invoked by alias); 14 Jul 2006 14:19:36 -0000 Received: from h1f81-net84db.lab.risq.net (EHLO [132.219.31.129]) [132.219.31.129] by mail.gmx.net (mp010) with SMTP; 14 Jul 2006 16:19:36 +0200 X-Authenticated: #29516787 Message-ID: <44B7A7FD.7060107@gmx.net> Date: Fri, 14 Jul 2006 10:19:41 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] Location header References: <072C5B76F7CEAB488172C6F64B30B5E301B36553@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301B36553@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: sip@ietf.org, "James Polk \(jmpolk\)" , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Mike, Michael Hammer (mhammer) wrote: > Hannes, > > If you are right, then you are saying that symmetric secret keys are out > of the question. That leaves some sort of public/private key type of > operation. The problem is not only the authentication but the authorization. Virtually everyone could be location recipient. > > Contrary to what Jon suggested earlier, there are ways of passing an > encrypted object to multiple recipients, namely by using a secret key to > encrypt the LO, then adding the secret key enrypted by the public key of > the intended recipient as an object for each recipient. We haven't even come to the problem of multiple recipient with a single message. ... and: S/MIME does not provide these capabilities. This also has > the characteristic that down-stream nodes upon learning of additional > recipients, can add new Pu(secret) objects for those new recipients as > needed. That does assume a chain of trust among those given access to > the secret. > > Is that practical? I think so, but others may have their opinion. > This is just an optimization of encrypting location objects to individual recipients. I am not sure we are even closen to optimizations. > BTW, can someone re-summarize what the requirements are? Requirements for what exactly? Most of the requirements are listed in the document provided by James & Brian. > It must be modifiable -> must be a header not body > It must provide confidentiality -> encrypted or selectively handed out > (by ref) > Downstream recipient unknown to UAC must have access -> ??? > ... What is 'it'? Ciao Hannes > > Mike > > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Friday, July 14, 2006 9:39 AM >>To: James Polk (jmpolk) >>Cc: sip@ietf.org; Henning Schulzrinne >>Subject: Re: [Sip] Location header >> >>Hi James, >> >>James M. Polk wrote: >> >>>At 07:25 PM 7/13/2006 -0400, Hannes Tschofenig wrote: >>> >>> >>>>Hi James, >>>> >>>>please explain me the difference (from a security point of view) >>>>between >>>>* adding a location object into the header that is not >> >>encrypted, and >> >>>>* adding a reference to a location object to the header >> >>that can be >> >>>>resolved into a location object by everyone that knows the >> >>reference? >> >>> >>>The server which has the by-referenced PIDF-LO can >> >>challenge whoever >> >>>asks for the PIDF-LO. The header URI allows for each >> >>intermediary to >> >>>ask for the dereference, but only those that have permission, >>>surviving the challenge(s), get the PIDF-LO. This means not all >>>dereference attempts learn the UAC's location. This cannot be >>>accomplished in a header. >> >>This would assume that the entity that created the location >>object has a >> relationship with the final location recipient (and to >>share some credential with them). >> >>I think that this is a totally unrealistic assumption. >> >> >>Ciao >>Hannes >> >> >>> >>>>Ciao >>>>Hannes >>>> >>>>James M. Polk wrote: >>>> >>>> >>>>>Right now, the ID lists options 1 and 2 as the only options, and >>>>>this keeps things simple. There have been a couple of >> >>comments here >> >>>>>in Montreal that adding a data URL isn't really wanted. >>>>>One reason given is the inability to encrypt it (easily). >> >> A message >> >>>>>body can be encypted using S/MIME, and a URI can have the server >>>>>posessing the PIDF-LO configured to challenge a >> >>dereference request >> >>>>>- including responding with an encrypted PIDF-LO. Both these >>>>>senarios have the PIDF-LO being able to be encrypted. I'm not so >>>>>sure encrypting the data URL is so straightforward, or deployable. >>>>>Others, please inform me and the list if this is untrue. >>>>>Cannot the ID proceed as is (in this respect), and once someone >>>>>wants to extend this doc (once it's an RFC), propose that >> >>extention >> >>>>>as a separate ID? >>>>>At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: >>>>> >>>>> >>>>>>To follow up on the discussion in the SIP group. I think >> >>there are >> >>>>>>roughly three options for the content of Location: >>>>>> >>>>>>(1) Point to content in the body --> can't be modified >> >>and cannot >> >>>>>>be inserted by proxies (and may not be inspectable by proxies if >>>>>>encrypted) >>>>>> >>>>>>(2) Point to external location --> can be modified, can >> >>be added, >> >>>>>>but can induce loops if changed in mid-stream and incurs another >>>>>>failure mode (and possible security risks if the reference is >>>>>>generally >>>>>>accessible) >>>>>> >>>>>>(3) Point to data URL (RFC 2397) as in >>>>>> >>>>>>Location: data:application/pidf+xml;base64,>>>>>PIDF-LO) >>>>>> >>>>>>Disadvantage: about 30% larger than as body; can't be encrypted >>>>>>separately (except as XML-DSIG) >>>>>> >>>>>>Advantages: can be inserted/modified by proxies (similar >> >>to (2)), >> >>>>>>but avoids difficulty of external reference >>>>>> >>>>>>I think these three methods all have different >>>>>>time-space-flexibility trade-offs and thus I suspect >> >>they all serve a need. >> >>>>>>Henning >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>This list is for NEW development of the core SIP Protocol Use >>>>>>sip-implementors@cs.columbia.edu for questions on >> >>current sip Use >> >>>>>>sipping@ietf.org for new developments on the application of sip >>>>> >>>>> >>>>>_______________________________________________ >>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>This list is for NEW development of the core SIP Protocol Use >>>>>sip-implementors@cs.columbia.edu for questions on current sip Use >>>>>sipping@ietf.org for new developments on the application of sip >>> >>> >>> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol Use >>sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 10:21:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OWQ-0001Kq-2s; Fri, 14 Jul 2006 10:20:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OWO-0001Kb-M8 for sip@ietf.org; Fri, 14 Jul 2006 10:20:00 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OWN-00061Q-E2 for sip@ietf.org; Fri, 14 Jul 2006 10:20:00 -0400 Received: from [132.219.27.189] (h1bbd-net84db.lab.risq.net [132.219.27.189] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6EEJu2L014408 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 14 Jul 2006 10:19:57 -0400 (EDT) In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301B36553@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E301B36553@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <261A6AFC-6ED2-4342-A1FF-AC6C85114B12@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] Location header Date: Fri, 14 Jul 2006 10:19:56 -0400 To: "Michael Hammer \(mhammer\)" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: sip@ietf.org, "James Polk \(jmpolk\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 14, 2006, at 10:05 AM, Michael Hammer ((mhammer)) wrote: > Hannes, > > Contrary to what Jon suggested earlier, there are ways of passing an > encrypted object to multiple recipients, namely by using a secret > key to > encrypt the LO, then adding the secret key enrypted by the public > key of > the intended recipient as an object for each recipient. This also has > the characteristic that down-stream nodes upon learning of additional > recipients, can add new Pu(secret) objects for those new recipients as > needed. That does assume a chain of trust among those given access to > the secret. > > Is that practical? I think so, but others may have their opinion. > I suspect there are multiple deployment scenarios, so it is probably impossible to say that it is (or not), in general. However, we might take two location-based routing scenarios that we have discussed: (1) emergency calling (2) calling for towing service For either, I'm having a really hard time picturing how the sender (or the originating VSP) can know the credentials or even identity of the proxies that are on the signaling path. My VSP is located in Germany; it is unlikely to have any relationship with the Montreal fire department or, more importantly, the routing model of the emergency calling network in Canada. I think the model that has been discussed is that there might be a province/state proxy, which routes to a county proxy which routes to a city proxy. Only the first one would be visible in LoST, so the caller has no way to determine the identity or public key of the other two. Clearly, there are going to be cases where such multiple-destination encryption is feasible, but this has no bearing on the value vs. reference discussion, since you can do the kind of thing you mentioned either way. > BTW, can someone re-summarize what the requirements are? > It must be modifiable -> must be a header not body Right. > It must provide confidentiality -> encrypted or selectively handed out > (by ref) I would qualify this as saying that it must be able to do this in some cases. Like other routing-related information (To, caller preferences, etc.), it's unlikely to be common, given your last requirement. Assuming you use TLS, the extra encryption of the information offers almost no value, since all those that are destinations for a TLS session also need to inspect the Location information. This is why we don't encrypt the From/To header, Route header and other similar routing/policy information, either. By the way, an interesting model is to split the routing from the end system information, if they need different degrees of precision: The routing-related information may only need city-level precision, for example, and the end-to-end information would have house-level precision. This doesn't help much with emergency calling since the caller won't know the destination public key ahead of time, as far as I can tell. (Unless all PSAPs in a state, say, share the same public/ private key pair.) > Downstream recipient unknown to UAC must have access -> ??? Indeed, with the minor qualification of "recipient*s*", i.e., there might be several. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 10:47:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Ouo-0001He-Uc; Fri, 14 Jul 2006 10:45:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Oun-0001HZ-MX for sip@ietf.org; Fri, 14 Jul 2006 10:45:13 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Oum-0001mE-1s for sip@ietf.org; Fri, 14 Jul 2006 10:45:13 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 14 Jul 2006 07:45:12 -0700 X-IronPort-AV: i="4.06,244,1149490800"; d="scan'208"; a="305847113:sNHT30281414" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6EEjBSX003104; Fri, 14 Jul 2006 07:45:11 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6EEj17H000192; Fri, 14 Jul 2006 07:45:10 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 10:45:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Location header Date: Fri, 14 Jul 2006 10:45:02 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B36584@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Location header Thread-Index: AcanUJA9J4EVVt4OQjWdF4DnIxpWFwAAmXZQ From: "Michael Hammer \(mhammer\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 14 Jul 2006 14:45:03.0438 (UTC) FILETIME=[172A56E0:01C6A754] DKIM-Signature: a=rsa-sha1; q=dns; l=8040; t=1152888311; x=1153752311; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Location=20header; X=v=3Dcisco.com=3B=20h=3DLNCrVuM0DNwc2cVWnvLt1u9qWXI=3D; b=ffDYetE0G/Fz428sDCXWQqYwWYVaV79ksJVu3DaziZd9BkbGSnT7mg7SDgyhme7Cvvb+2+R4 /JP7qpKRLMHzxEDIU9G225q4FxVdNU9z9OREQVj9bQDQC+3xo7dQwZI7; Authentication-Results: sj-dkim-7.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: sip@ietf.org, "James Polk \(jmpolk\)" , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hannes, I went back and re-read those requirements. My problem here is that the arguments for one approach versus another are not always covered by those requirements. In other words, a requirement is being inferred from the general requirement "do privacy". So, if someone argues that X is not good enough because it doesn't meet Y, and Y is not a requirement, then the argument is baseless. Much of the debate surrounds assumptions about topology and trust relationships (or not) between various nodes. Disagreement on assumptions/requirements -> Disagreement on solutions. Mike > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Friday, July 14, 2006 10:20 AM > To: Michael Hammer (mhammer) > Cc: James Polk (jmpolk); sip@ietf.org; Henning Schulzrinne > Subject: Re: [Sip] Location header >=20 > Hi Mike, >=20 > Michael Hammer (mhammer) wrote: > > Hannes, > >=20 > > If you are right, then you are saying that symmetric secret=20 > keys are=20 > > out of the question. That leaves some sort of=20 > public/private key type=20 > > of operation. >=20 > The problem is not only the authentication but the authorization. >=20 > Virtually everyone could be location recipient. >=20 > >=20 > > Contrary to what Jon suggested earlier, there are ways of=20 > passing an=20 > > encrypted object to multiple recipients, namely by using a=20 > secret key=20 > > to encrypt the LO, then adding the secret key enrypted by=20 > the public=20 > > key of the intended recipient as an object for each recipient. >=20 > We haven't even come to the problem of multiple recipient=20 > with a single message. >=20 > ... and: S/MIME does not provide these capabilities. >=20 > This also has > > the characteristic that down-stream nodes upon learning of=20 > additional=20 > > recipients, can add new Pu(secret) objects for those new=20 > recipients as=20 > > needed. That does assume a chain of trust among those=20 > given access to=20 > > the secret. > >=20 > > Is that practical? I think so, but others may have their opinion. > >=20 >=20 >=20 > This is just an optimization of encrypting location objects=20 > to individual recipients. I am not sure we are even closen to=20 > optimizations. >=20 >=20 > > BTW, can someone re-summarize what the requirements are? >=20 > Requirements for what exactly? Most of the requirements are listed in=20 > the document provided by James & Brian. >=20 > > It must be modifiable -> must be a header not body > > It must provide confidentiality -> encrypted or selectively=20 > handed out > > (by ref) > > Downstream recipient unknown to UAC must have access -> ??? > > ... > What is 'it'? >=20 >=20 > Ciao > Hannes >=20 > >=20 > > Mike > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > >>Sent: Friday, July 14, 2006 9:39 AM > >>To: James Polk (jmpolk) > >>Cc: sip@ietf.org; Henning Schulzrinne > >>Subject: Re: [Sip] Location header > >> > >>Hi James, > >> > >>James M. Polk wrote: > >> > >>>At 07:25 PM 7/13/2006 -0400, Hannes Tschofenig wrote: > >>> > >>> > >>>>Hi James, > >>>> > >>>>please explain me the difference (from a security point of view)=20 > >>>>between > >>>>* adding a location object into the header that is not=20 > >> > >>encrypted, and > >> > >>>>* adding a reference to a location object to the header=20 > >> > >>that can be=20 > >> > >>>>resolved into a location object by everyone that knows the=20 > >> > >>reference? > >> > >>> > >>>The server which has the by-referenced PIDF-LO can=20 > >> > >>challenge whoever=20 > >> > >>>asks for the PIDF-LO. The header URI allows for each=20 > >> > >>intermediary to=20 > >> > >>>ask for the dereference, but only those that have permission,=20 > >>>surviving the challenge(s), get the PIDF-LO. This means not all=20 > >>>dereference attempts learn the UAC's location. This cannot be=20 > >>>accomplished in a header. > >> > >>This would assume that the entity that created the location=20 > >>object has a > >> relationship with the final location recipient (and to=20 > >>share some credential with them). > >> > >>I think that this is a totally unrealistic assumption. > >> > >> > >>Ciao > >>Hannes > >> > >> > >>> > >>>>Ciao > >>>>Hannes > >>>> > >>>>James M. Polk wrote: > >>>> > >>>> > >>>>>Right now, the ID lists options 1 and 2 as the only options, and=20 > >>>>>this keeps things simple. There have been a couple of=20 > >> > >>comments here=20 > >> > >>>>>in Montreal that adding a data URL isn't really wanted. > >>>>>One reason given is the inability to encrypt it (easily).=20 > >> > >> A message=20 > >> > >>>>>body can be encypted using S/MIME, and a URI can have the server=20 > >>>>>posessing the PIDF-LO configured to challenge a=20 > >> > >>dereference request=20 > >> > >>>>>- including responding with an encrypted PIDF-LO. Both these=20 > >>>>>senarios have the PIDF-LO being able to be encrypted. =20 > I'm not so=20 > >>>>>sure encrypting the data URL is so straightforward, or=20 > deployable. > >>>>>Others, please inform me and the list if this is untrue. > >>>>>Cannot the ID proceed as is (in this respect), and once someone=20 > >>>>>wants to extend this doc (once it's an RFC), propose that=20 > >> > >>extention=20 > >> > >>>>>as a separate ID? > >>>>>At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: > >>>>> > >>>>> > >>>>>>To follow up on the discussion in the SIP group. I think=20 > >> > >>there are=20 > >> > >>>>>>roughly three options for the content of Location: > >>>>>> > >>>>>>(1) Point to content in the body --> can't be modified=20 > >> > >>and cannot=20 > >> > >>>>>>be inserted by proxies (and may not be inspectable by proxies if > >>>>>>encrypted) > >>>>>> > >>>>>>(2) Point to external location --> can be modified, can=20 > >> > >>be added,=20 > >> > >>>>>>but can induce loops if changed in mid-stream and=20 > incurs another=20 > >>>>>>failure mode (and possible security risks if the reference is=20 > >>>>>>generally > >>>>>>accessible) > >>>>>> > >>>>>>(3) Point to data URL (RFC 2397) as in > >>>>>> > >>>>>>Location: data:application/pidf+xml;base64, >>>>>>PIDF-LO) > >>>>>> > >>>>>>Disadvantage: about 30% larger than as body; can't be encrypted=20 > >>>>>>separately (except as XML-DSIG) > >>>>>> > >>>>>>Advantages: can be inserted/modified by proxies (similar=20 > >> > >>to (2)),=20 > >> > >>>>>>but avoids difficulty of external reference > >>>>>> > >>>>>>I think these three methods all have different=20 > >>>>>>time-space-flexibility trade-offs and thus I suspect=20 > >> > >>they all serve a need. > >> > >>>>>>Henning > >>>>>> > >>>>>> > >>>>>>_______________________________________________ > >>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>>This list is for NEW development of the core SIP Protocol Use=20 > >>>>>>sip-implementors@cs.columbia.edu for questions on=20 > >> > >>current sip Use=20 > >> > >>>>>>sipping@ietf.org for new developments on the application of sip > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>This list is for NEW development of the core SIP Protocol Use=20 > >>>>>sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>>>sipping@ietf.org for new developments on the application of sip > >>> > >>> > >>> > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol Use=20 > >>sip-implementors@cs.columbia.edu for questions on current sip=20 > >>Use sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 11:17:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1POM-0005s1-L8; Fri, 14 Jul 2006 11:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1POL-0005rw-O8 for sip@ietf.org; Fri, 14 Jul 2006 11:15:45 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1POL-0005Cn-1z for sip@ietf.org; Fri, 14 Jul 2006 11:15:45 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 14 Jul 2006 08:15:46 -0700 X-IronPort-AV: i="4.06,244,1149490800"; d="scan'208"; a="305855487:sNHT31105868" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6EFFixj009953; Fri, 14 Jul 2006 08:15:44 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6EFFh79010808; Fri, 14 Jul 2006 08:15:44 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 11:15:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Location header Date: Fri, 14 Jul 2006 11:15:42 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B365BD@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Location header Thread-Index: AcanVMGJ7yaCGMrRRSeJzA0eOeds7wAAhktA From: "Michael Hammer \(mhammer\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 14 Jul 2006 15:15:43.0578 (UTC) FILETIME=[5FF96BA0:01C6A758] DKIM-Signature: a=rsa-sha1; q=dns; l=10228; t=1152890144; x=1153754144; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Location=20header; X=v=3Dcisco.com=3B=20h=3DLNCrVuM0DNwc2cVWnvLt1u9qWXI=3D; b=RTeZISQELq003kSI/CMepLMMK6UcvYayMGbag5jJhFoU1GqbC5nB+WAefc7LBrXpO0txzV1o 2aNXyrBeAEPWmIT4eF51zvTL2VoQS3iLszycOZGdtNVyVCAwHFiPDiwq; Authentication-Results: sj-dkim-5.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f0ea5880a0890be2408609376fa519aa Cc: sip@ietf.org, "James Polk \(jmpolk\)" , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I wouldn't call them my requirements per se, I was just trying to read between the lines of the discussion and extract why some folks were arguing for or against based on a statement or requirement/assumption. The inclusion v. reference and header v. body arguments aside, it seemed as though there were two dimensions here: Set of nodes with which the Client has trust relationship versus not Set of nodes that have permitted "need to know" location versus not 1) Relationship + need to know 2) No Relation + need to know 3) Relationship + no need to know 4) No Relation + need to know I thought each of the above needed to be addressed. But, my suggestion for 4) based on overlapping trust groups seemed to be deemed jumping ahead of the immediate issues. =20 Mike > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Friday, July 14, 2006 10:50 AM > To: Michael Hammer (mhammer) > Cc: James Polk (jmpolk); sip@ietf.org; Henning Schulzrinne > Subject: Re: [Sip] Location header >=20 > Hi Mike, >=20 > I agree that the current document does not cover all the=20 > requirements and does not go into a deep discussion of the=20 > security/privacy aspects.=20 > I am happy to discuss these. >=20 > Maybe you could restate your requirements again in more details. >=20 > Ciao > Hannes >=20 > Michael Hammer (mhammer) wrote: > > Hannes, > >=20 > > I went back and re-read those requirements. My problem=20 > here is that=20 > > the arguments for one approach versus another are not=20 > always covered=20 > > by those requirements. In other words, a requirement is being=20 > > inferred from the general requirement "do privacy". So, if someone=20 > > argues that X is not good enough because it doesn't meet Y,=20 > and Y is=20 > > not a requirement, then the argument is baseless. > >=20 > > Much of the debate surrounds assumptions about topology and trust=20 > > relationships (or not) between various nodes. > >=20 > > Disagreement on assumptions/requirements -> Disagreement on=20 > solutions. > >=20 > > Mike > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>Sent: Friday, July 14, 2006 10:20 AM > >>To: Michael Hammer (mhammer) > >>Cc: James Polk (jmpolk); sip@ietf.org; Henning Schulzrinne > >>Subject: Re: [Sip] Location header > >> > >>Hi Mike, > >> > >>Michael Hammer (mhammer) wrote: > >> > >>>Hannes, > >>> > >>>If you are right, then you are saying that symmetric secret > >> > >>keys are > >> > >>>out of the question. That leaves some sort of > >> > >>public/private key type > >> > >>>of operation. > >> > >>The problem is not only the authentication but the authorization. > >> > >>Virtually everyone could be location recipient. > >> > >> > >>>Contrary to what Jon suggested earlier, there are ways of > >> > >>passing an > >> > >>>encrypted object to multiple recipients, namely by using a > >> > >>secret key > >> > >>>to encrypt the LO, then adding the secret key enrypted by > >> > >>the public > >> > >>>key of the intended recipient as an object for each recipient. > >> > >>We haven't even come to the problem of multiple recipient with a=20 > >>single message. > >> > >>... and: S/MIME does not provide these capabilities. > >> > >> This also has > >> > >>>the characteristic that down-stream nodes upon learning of > >> > >>additional > >> > >>>recipients, can add new Pu(secret) objects for those new > >> > >>recipients as > >> > >>>needed. That does assume a chain of trust among those > >> > >>given access to > >> > >>>the secret. > >>> > >>>Is that practical? I think so, but others may have their opinion. > >>> > >> > >> > >>This is just an optimization of encrypting location objects to=20 > >>individual recipients. I am not sure we are even closen to=20 > >>optimizations. > >> > >> > >> > >>>BTW, can someone re-summarize what the requirements are? > >> > >>Requirements for what exactly? Most of the requirements are=20 > listed in=20 > >>the document provided by James & Brian. > >> > >> > >>>It must be modifiable -> must be a header not body It must provide=20 > >>>confidentiality -> encrypted or selectively > >> > >>handed out > >> > >>>(by ref) > >>>Downstream recipient unknown to UAC must have access -> ??? > >>>... > >> > >>What is 'it'? > >> > >> > >>Ciao > >>Hannes > >> > >> > >>>Mike > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>Sent: Friday, July 14, 2006 9:39 AM > >>>>To: James Polk (jmpolk) > >>>>Cc: sip@ietf.org; Henning Schulzrinne > >>>>Subject: Re: [Sip] Location header > >>>> > >>>>Hi James, > >>>> > >>>>James M. Polk wrote: > >>>> > >>>> > >>>>>At 07:25 PM 7/13/2006 -0400, Hannes Tschofenig wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Hi James, > >>>>>> > >>>>>>please explain me the difference (from a security point=20 > of view)=20 > >>>>>>between > >>>>>>* adding a location object into the header that is not > >>>> > >>>>encrypted, and > >>>> > >>>> > >>>>>>* adding a reference to a location object to the header > >>>> > >>>>that can be > >>>> > >>>> > >>>>>>resolved into a location object by everyone that knows the > >>>> > >>>>reference? > >>>> > >>>> > >>>>>The server which has the by-referenced PIDF-LO can > >>>> > >>>>challenge whoever > >>>> > >>>> > >>>>>asks for the PIDF-LO. The header URI allows for each > >>>> > >>>>intermediary to > >>>> > >>>> > >>>>>ask for the dereference, but only those that have permission,=20 > >>>>>surviving the challenge(s), get the PIDF-LO. This means not all=20 > >>>>>dereference attempts learn the UAC's location. This cannot be=20 > >>>>>accomplished in a header. > >>>> > >>>>This would assume that the entity that created the=20 > location object=20 > >>>>has a relationship with the final location recipient=20 > (and to share=20 > >>>>some credential with them). > >>>> > >>>>I think that this is a totally unrealistic assumption. > >>>> > >>>> > >>>>Ciao > >>>>Hannes > >>>> > >>>> > >>>> > >>>>>>Ciao > >>>>>>Hannes > >>>>>> > >>>>>>James M. Polk wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Right now, the ID lists options 1 and 2 as the only=20 > options, and=20 > >>>>>>>this keeps things simple. There have been a couple of > >>>> > >>>>comments here > >>>> > >>>> > >>>>>>>in Montreal that adding a data URL isn't really wanted. > >>>>>>>One reason given is the inability to encrypt it (easily).=20 > >>>> > >>>>A message > >>>> > >>>> > >>>>>>>body can be encypted using S/MIME, and a URI can have=20 > the server=20 > >>>>>>>posessing the PIDF-LO configured to challenge a > >>>> > >>>>dereference request > >>>> > >>>> > >>>>>>>- including responding with an encrypted PIDF-LO. Both these=20 > >>>>>>>senarios have the PIDF-LO being able to be encrypted. > >> > >>I'm not so > >> > >>>>>>>sure encrypting the data URL is so straightforward, or > >> > >>deployable. > >> > >>>>>>>Others, please inform me and the list if this is untrue. > >>>>>>>Cannot the ID proceed as is (in this respect), and=20 > once someone=20 > >>>>>>>wants to extend this doc (once it's an RFC), propose that > >>>> > >>>>extention > >>>> > >>>> > >>>>>>>as a separate ID? > >>>>>>>At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>To follow up on the discussion in the SIP group. I think > >>>> > >>>>there are > >>>> > >>>> > >>>>>>>>roughly three options for the content of Location: > >>>>>>>> > >>>>>>>>(1) Point to content in the body --> can't be modified > >>>> > >>>>and cannot > >>>> > >>>> > >>>>>>>>be inserted by proxies (and may not be inspectable by=20 > proxies if > >>>>>>>>encrypted) > >>>>>>>> > >>>>>>>>(2) Point to external location --> can be modified, can > >>>> > >>>>be added, > >>>> > >>>> > >>>>>>>>but can induce loops if changed in mid-stream and > >> > >>incurs another > >> > >>>>>>>>failure mode (and possible security risks if the reference is=20 > >>>>>>>>generally > >>>>>>>>accessible) > >>>>>>>> > >>>>>>>>(3) Point to data URL (RFC 2397) as in > >>>>>>>> > >>>>>>>>Location: data:application/pidf+xml;base64, >>>>>>>>PIDF-LO) > >>>>>>>> > >>>>>>>>Disadvantage: about 30% larger than as body; can't be=20 > encrypted=20 > >>>>>>>>separately (except as XML-DSIG) > >>>>>>>> > >>>>>>>>Advantages: can be inserted/modified by proxies (similar > >>>> > >>>>to (2)), > >>>> > >>>> > >>>>>>>>but avoids difficulty of external reference > >>>>>>>> > >>>>>>>>I think these three methods all have different=20 > >>>>>>>>time-space-flexibility trade-offs and thus I suspect > >>>> > >>>>they all serve a need. > >>>> > >>>> > >>>>>>>>Henning > >>>>>>>> > >>>>>>>> > >>>>>>>>_______________________________________________ > >>>>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>>>>This list is for NEW development of the core SIP Protocol Use=20 > >>>>>>>>sip-implementors@cs.columbia.edu for questions on > >>>> > >>>>current sip Use > >>>> > >>>> > >>>>>>>>sipping@ietf.org for new developments on the=20 > application of sip > >>>>>>> > >>>>>>> > >>>>>>>_______________________________________________ > >>>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>>>This list is for NEW development of the core SIP Protocol Use=20 > >>>>>>>sip-implementors@cs.columbia.edu for questions on > >> > >>current sip Use > >> > >>>>>>>sipping@ietf.org for new developments on the application of sip > >>>>> > >>>>> > >>>>> > >>>>_______________________________________________ > >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>This list is for NEW development of the core SIP Protocol Use=20 > >>>>sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>>>sipping@ietf.org for new developments on the application of sip > >>>> > >>> > >>> > >>> > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 11:18:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1PP1-00066y-20; Fri, 14 Jul 2006 11:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1POz-00066o-Ff for sip@ietf.org; Fri, 14 Jul 2006 11:16:25 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1POx-0005fD-QI for sip@ietf.org; Fri, 14 Jul 2006 11:16:25 -0400 Received: (qmail invoked by alias); 14 Jul 2006 14:49:43 -0000 Received: from h1f81-net84db.lab.risq.net (EHLO [132.219.31.129]) [132.219.31.129] by mail.gmx.net (mp031) with SMTP; 14 Jul 2006 16:49:43 +0200 X-Authenticated: #29516787 Message-ID: <44B7AF0B.2010402@gmx.net> Date: Fri, 14 Jul 2006 10:49:47 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] Location header References: <072C5B76F7CEAB488172C6F64B30B5E301B36584@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301B36584@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: sip@ietf.org, "James Polk \(jmpolk\)" , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Mike, I agree that the current document does not cover all the requirements and does not go into a deep discussion of the security/privacy aspects. I am happy to discuss these. Maybe you could restate your requirements again in more details. Ciao Hannes Michael Hammer (mhammer) wrote: > Hannes, > > I went back and re-read those requirements. My problem here is that the > arguments for one approach versus another are not always covered by > those requirements. In other words, a requirement is being inferred > from the general requirement "do privacy". So, if someone argues that X > is not good enough because it doesn't meet Y, and Y is not a > requirement, then the argument is baseless. > > Much of the debate surrounds assumptions about topology and trust > relationships (or not) between various nodes. > > Disagreement on assumptions/requirements -> Disagreement on solutions. > > Mike > > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Friday, July 14, 2006 10:20 AM >>To: Michael Hammer (mhammer) >>Cc: James Polk (jmpolk); sip@ietf.org; Henning Schulzrinne >>Subject: Re: [Sip] Location header >> >>Hi Mike, >> >>Michael Hammer (mhammer) wrote: >> >>>Hannes, >>> >>>If you are right, then you are saying that symmetric secret >> >>keys are >> >>>out of the question. That leaves some sort of >> >>public/private key type >> >>>of operation. >> >>The problem is not only the authentication but the authorization. >> >>Virtually everyone could be location recipient. >> >> >>>Contrary to what Jon suggested earlier, there are ways of >> >>passing an >> >>>encrypted object to multiple recipients, namely by using a >> >>secret key >> >>>to encrypt the LO, then adding the secret key enrypted by >> >>the public >> >>>key of the intended recipient as an object for each recipient. >> >>We haven't even come to the problem of multiple recipient >>with a single message. >> >>... and: S/MIME does not provide these capabilities. >> >> This also has >> >>>the characteristic that down-stream nodes upon learning of >> >>additional >> >>>recipients, can add new Pu(secret) objects for those new >> >>recipients as >> >>>needed. That does assume a chain of trust among those >> >>given access to >> >>>the secret. >>> >>>Is that practical? I think so, but others may have their opinion. >>> >> >> >>This is just an optimization of encrypting location objects >>to individual recipients. I am not sure we are even closen to >>optimizations. >> >> >> >>>BTW, can someone re-summarize what the requirements are? >> >>Requirements for what exactly? Most of the requirements are listed in >>the document provided by James & Brian. >> >> >>>It must be modifiable -> must be a header not body >>>It must provide confidentiality -> encrypted or selectively >> >>handed out >> >>>(by ref) >>>Downstream recipient unknown to UAC must have access -> ??? >>>... >> >>What is 'it'? >> >> >>Ciao >>Hannes >> >> >>>Mike >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>Sent: Friday, July 14, 2006 9:39 AM >>>>To: James Polk (jmpolk) >>>>Cc: sip@ietf.org; Henning Schulzrinne >>>>Subject: Re: [Sip] Location header >>>> >>>>Hi James, >>>> >>>>James M. Polk wrote: >>>> >>>> >>>>>At 07:25 PM 7/13/2006 -0400, Hannes Tschofenig wrote: >>>>> >>>>> >>>>> >>>>>>Hi James, >>>>>> >>>>>>please explain me the difference (from a security point of view) >>>>>>between >>>>>>* adding a location object into the header that is not >>>> >>>>encrypted, and >>>> >>>> >>>>>>* adding a reference to a location object to the header >>>> >>>>that can be >>>> >>>> >>>>>>resolved into a location object by everyone that knows the >>>> >>>>reference? >>>> >>>> >>>>>The server which has the by-referenced PIDF-LO can >>>> >>>>challenge whoever >>>> >>>> >>>>>asks for the PIDF-LO. The header URI allows for each >>>> >>>>intermediary to >>>> >>>> >>>>>ask for the dereference, but only those that have permission, >>>>>surviving the challenge(s), get the PIDF-LO. This means not all >>>>>dereference attempts learn the UAC's location. This cannot be >>>>>accomplished in a header. >>>> >>>>This would assume that the entity that created the location >>>>object has a >>>> relationship with the final location recipient (and to >>>>share some credential with them). >>>> >>>>I think that this is a totally unrealistic assumption. >>>> >>>> >>>>Ciao >>>>Hannes >>>> >>>> >>>> >>>>>>Ciao >>>>>>Hannes >>>>>> >>>>>>James M. Polk wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Right now, the ID lists options 1 and 2 as the only options, and >>>>>>>this keeps things simple. There have been a couple of >>>> >>>>comments here >>>> >>>> >>>>>>>in Montreal that adding a data URL isn't really wanted. >>>>>>>One reason given is the inability to encrypt it (easily). >>>> >>>>A message >>>> >>>> >>>>>>>body can be encypted using S/MIME, and a URI can have the server >>>>>>>posessing the PIDF-LO configured to challenge a >>>> >>>>dereference request >>>> >>>> >>>>>>>- including responding with an encrypted PIDF-LO. Both these >>>>>>>senarios have the PIDF-LO being able to be encrypted. >> >>I'm not so >> >>>>>>>sure encrypting the data URL is so straightforward, or >> >>deployable. >> >>>>>>>Others, please inform me and the list if this is untrue. >>>>>>>Cannot the ID proceed as is (in this respect), and once someone >>>>>>>wants to extend this doc (once it's an RFC), propose that >>>> >>>>extention >>>> >>>> >>>>>>>as a separate ID? >>>>>>>At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>To follow up on the discussion in the SIP group. I think >>>> >>>>there are >>>> >>>> >>>>>>>>roughly three options for the content of Location: >>>>>>>> >>>>>>>>(1) Point to content in the body --> can't be modified >>>> >>>>and cannot >>>> >>>> >>>>>>>>be inserted by proxies (and may not be inspectable by proxies if >>>>>>>>encrypted) >>>>>>>> >>>>>>>>(2) Point to external location --> can be modified, can >>>> >>>>be added, >>>> >>>> >>>>>>>>but can inFrom sip-bounces@ietf.org Fri Jul 14 11:18:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1PP1-00066y-20; Fri, 14 Jul 2006 11:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1POz-00066o-Ff for sip@ietf.org; Fri, 14 Jul 2006 11:16:25 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1POx-0005fD-QI for sip@ietf.org; Fri, 14 Jul 2006 11:16:25 -0400 Received: (qmail invoked by alias); 14 Jul 2006 14:49:43 -0000 Received: from h1f81-net84db.lab.risq.net (EHLO [132.219.31.129]) [132.219.31.129] by mail.gmx.net (mp031) with SMTP; 14 Jul 2006 16:49:43 +0200 X-Authenticated: #29516787 Message-ID: <44B7AF0B.2010402@gmx.net> Date: Fri, 14 Jul 2006 10:49:47 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] Location header References: <072C5B76F7CEAB488172C6F64B30B5E301B36584@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301B36584@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: sip@ietf.org, "James Polk \(jmpolk\)" , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Mike, I agree that the current document does not cover all the requirements and does not go into a deep discussion of the security/privacy aspects. I am happy to discuss these. Maybe you could restate your requirements again in more details. Ciao Hannes Michael Hammer (mhammer) wrote: > Hannes, > > I went back and re-read those requirements. My problem here is that the > arguments for one approach versus another are not always covered by > those requirements. In other words, a requirement is being inferred > from the general requirement "do privacy". So, if someone argues that X > is not good enough because it doesn't meet Y, and Y is not a > requirement, then the argument is baseless. > > Much of the debate surrounds assumptions about topology and trust > relationships (or not) between various nodes. > > Disagreement on assumptions/requirements -> Disagreement on solutions. > > Mike > > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Friday, July 14, 2006 10:20 AM >>To: Michael Hammer (mhammer) >>Cc: James Polk (jmpolk); sip@ietf.org; Henning Schulzrinne >>Subject: Re: [Sip] Location header >> >>Hi Mike, >> >>Michael Hammer (mhammer) wrote: >> >>>Hannes, >>> >>>If you are right, then you are saying that symmetric secret >> >>keys are >> >>>out of the question. That leaves some sort of >> >>public/private key type >> >>>of operation. >> >>The problem is not only the authentication but the authorization. >> >>Virtually everyone could be location recipient. >> >> >>>Contrary to what Jon suggested earlier, there are ways of >> >>passing an >> >>>encrypted object to multiple recipients, namely by using a >> >>secret key >> >>>to encrypt the LO, then adding the secret key enrypted by >> >>the public >> >>>key of the intended recipient as an object for each recipient. >> >>We haven't even come to the problem of multiple recipient >>with a single message. >> >>... and: S/MIME does not provide these capabilities. >> >> This also has >> >>>the charactduce loops if changed in mid-stream and >> >>incurs another >> >>>>>>>>failure mode (and possible security risks if the reference is >>>>>>>>generally >>>>>>>>accessible) >>>>>>>> >>>>>>>>(3) Point to data URL (RFC 2397) as in >>>>>>>> >>>>>>>>Location: data:application/pidf+xml;base64,>>>>>>>PIDF-LO) >>>>>>>> >>>>>>>>Disadvantage: about 30% larger than as body; can't be encrypted >>>>>>>>separately (except as XML-DSIG) >>>>>>>> >>>>>>>>Advantages: can be inserted/modified by proxies (similar >>>> >>>>to (2)), >>>> >>>> >>>>>>>>but avoids difficulty of external reference >>>>>>>> >>>>>>>>I think these three methods all have different >>>>>>>>time-space-flexibility trade-offs and thus I suspect >>>> >>>>they all serve a need. >>>> >>>> >>>>>>>>Henning >>>>>>>> >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>>This list is for NEW development of the core SIP Protocol Use >>>>>>>>sip-implementors@cs.columbia.edu for questions on >>>> >>>>current sip Use >>>> >>>> >>>>>>>>sipping@ietf.org for new developments on the application of sip >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>This list is for NEW development of the core SIP Protocol Use >>>>>>>sip-implementors@cs.columbia.edu for questions on >> >>current sip Use >> >>>>>>>sipping@ietf.org for new developments on the application of sip >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol Use >>>>sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of sip >>>> >>> >>> >>> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 11:18:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1PP2-00069n-ND; Fri, 14 Jul 2006 11:16:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1PP1-00067X-74 for Sip@ietf.org; Fri, 14 Jul 2006 11:16:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OlS-0007HX-7w for Sip@ietf.org; Fri, 14 Jul 2006 10:35:34 -0400 Received: from s1.mailresponder.info ([193.24.237.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1NrT-0005pz-Q1 for Sip@ietf.org; Fri, 14 Jul 2006 09:37:46 -0400 Received: from moonfish.nero.com (193.47.77.31) by s1.mailresponder.info with MERCUR Mailserver (v4.02.30 ODAtMjQzOS03MTc5) for ; Fri, 14 Jul 2006 15:37:00 +0200 Received: from smtp.ahead.de (unknown [192.168.1.222]) by moonfish.nero.com (Postfix) with ESMTP id 162462157DD; Fri, 14 Jul 2006 15:36:49 +0200 (CEST) Received: from [192.168.10.32] (unknown [192.168.10.32]) by smtp.ahead.de (Postfix) with ESMTP id 990772DE92D; Fri, 14 Jul 2006 15:36:49 +0200 (CEST) Message-ID: <44B79DF1.2020801@nero.com> Date: Fri, 14 Jul 2006 15:36:49 +0200 From: Markus Hofmann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ant=F3nio_Manuel_Amaral?= Subject: Re: [Sip] S-CSCF expected behavior References: <75D349FBF7C131408F5061B7168072C30329DB49@INOAVREX06.ptin.corpPT.com> In-Reply-To: <75D349FBF7C131408F5061B7168072C30329DB49@INOAVREX06.ptin.corpPT.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Scan-Signature: eristic that down-stream nodes upon learning of >> >>additional >> >>>recipients, can add new Pu(secret) objects for those new >> >>recipients as >> >>>needed. That does assume a chain of trust among those >> >>given access to >> >>>the secret. >>> >>>Is that practical? I think so, but others may have their opinion. >>> >> >> >>This is just an optimization of encrypting location objects >>to individual recipients. I am not sure we are even closen to >>optimizations. >> >> >> >>>BTW, can someone re-summarize what the requirements are? >> >>Requirements for what exactly? Most of the requirements are listed in >>the document provided by James & Brian. >> >> >>>It must be modifiable -> must be a header not body >>>It must provide confidentiality -> encrypted or selectively >> >>handed out >> >>>(by ref) >>>Downstream recipient unknown to UAC must have access -> ??? >>>... >> >>What is 'it'? >> >> >>Ciao >>Hannes >> >> >>>Mike >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>Sent: Friday, July 14, 2006 9:39 AM >>>>To: James Polk (jmpolk) >>>>Cc: sip@ietf.org; Henning Schulzrinne >>>>Subject: Re: [Sip] Location header >>>> >>>>Hi James, >>>> >>>>James M. Polk wrote: >>>> >>>> >>>>>At 07:25 PM 7/13/2006 -0400, Hannes Tschofenig wrote: >>>>> >>>>> >>>>> >>>>>>Hi James, >>>>>> >>>>>>please explain me the difference (from a security point of view) >>>>>>between >>>>>>* adding a location object into the header that is not >>>> >>>>encrypted, and >>>> >>>> >>>>>>* adding a reference to a location object to the header >>>> >>>>that can be >>>> >>>> >>>>>>resolved into a location object by everyone that knows the >>>> >>>>reference? >>>> >>>> >>>>>The server which has the by-referenced PIDF-LO can >>>> >>>>challenge whoever >>>> >>>> >>>>>asks for the PIDF-LO. The header URI allows for each >>>> >>>>intermediary to >>>> >>>> >>>>>ask for the dereference, but only those that have permission, >>>>>surviving the challenge(s), get the PIDF-LO. This means not all >>>>>dereference attempts learn the UAC's location. This cannot be >>>>>accomplished in a header. >>>> >>>>This would assume that the entity that created the location >>>>object has a >>>> relationship with the final location recipient (and to >>>>share some credential with them). >>>> >>>>I think that this is a totally unrealistic assumption. >>>> >>>> >>>>Ciao >>>>Hannes >>>> >>>> >>>> >>>>>>Ciao >>>>>>Hannes >>>>>> >>>>>>James M. Polk wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Right now, the ID lists options 1 and 2 as the only options, and >>>>>>>this keeps things simple. There have been a couple of >>>> >>>>comments here >>>> >>>> >>>>>>>in Montreal that adding a data URL isn't really wanted. >>>>>>>One reason given is the inability to encrypt it (easily). >>>> >>>>A message >>>> >>>> >>>>>>>body can be encypted using S/MIME, and a URI can have the server >>>>>>>posessing the PIDF-LO configured to challenge a >>>> >>>>dereference request >>>> >>>> >>>>>>>- including responding with an encrypted PIDF-LO. Both these >>>>>>>senarios have the PIDF-LO being able to be encrypted. >> >>I'm not so >> >>>>>>>sure encrypting the data URL is so straightforward, or >> >>deployable. >> >>>>>>>Others, please inform me and the list if this is untrue. >>>>>>>Cannot the ID proceed as is (in this respect), and once someone >>>>>>>wants to extend this doc (once it's an RFC), propose that >>>> >>>>extention >>>> >>>> >>>>>>>as a separate ID? >>>>>>>At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>To follow up on the discussion in the SIP group. I think >>>> >>>>there are >>>> >>>> >>>>>>>>roughly three options for the content of Location: >>>>>>>> >>>>>>>>(1) Point to content in the body --> can't be modified >>>> >>>>and cannot >>>> >>>> >>>>>>>>be inserted by proxies (and may not be inspectable by proxies if >>>>>>>>encrypted) >>>>>>>> >>>>>>>>(2) Point to external location --> can be modified, can >>>> >>>>be added, >>>> >>>> >>>>>>>>but can in69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Ant=F3nio, I can't answer your question. I think you should contact the 3G which is responsible for IMS. Regards Markus Ant=F3nio Manuel Amaral wrote: > Dear All, >=20 > I don't know if this is the correct mailing list to put my question and= if not my apologies for that. >=20 > Consider the following IMS scenario >=20 >=20 > (IMS core Network) -> S-CSCF -> AS >=20 >=20 > If the connection between AS and S-CSCF fails what is the expected beha= vior of S-CSCF? It must release all active calls sending BYE messages to = caller and called clients in order to terminate the calls? >=20 > Thanks in advance >=20 > Regards >=20 > AA=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip duce loops if changed in mid-stream and >> >>incurs another >> >>>>>>>>failure mode (and possible security risks if the reference is >>>>>>>>generally >>>>>>>>accessible) >>>>>>>> >>>>>>>>(3) Point to data URL (RFC 2397) as in >>>>>>>> >>>>>>>>Location: data:application/pidf+xml;base64,>>>>>>>PIDF-LO) >>>>>>>> >>>>>>>>Disadvantage: about 30% larger than as body; can't be encrypted >>>>>>>>separately (except as XML-DSIG) >>>>>>>> >>>>>>>>Advantages: can be inserted/modified by proxies (similar >>>> >>>>to (2)), >>>> >>>> >>>>>>>>but avoids difficulty of external reference >>>>>>>> >>>>>>>>I think these three methods all have different >>>>>>>>time-space-flexibility trade-offs and thus I suspect >>>> >>>>they all serve a need. >>>> >>>> >>>>>>>>Henning >>>>>>>> >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>>This list is for NEW development of the core SIP Protocol Use >>>>>>>>sip-implementors@cs.columbia.edu for questions on >>>> >>>>current sip Use >>>> >>>> >>>>>>>>sipping@ietf.org for new developments on the application of sip >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>This list is for NEW development of the core SIP Protocol Use >>>>>>>sip-implementors@cs.columbia.edu for questions on >> >>current sip Use >> >>>>>>>sipping@ietf.org for new developments on the application of sip >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol Use >>>>sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of sip >>>> >>> >>> >>> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 11:18:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1PP2-00069n-ND; Fri, 14 Jul 2006 11:16:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1PP1-00067X-74 for Sip@ietf.org; Fri, 14 Jul 2006 11:16:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OlS-0007HX-7w for Sip@ietf.org; Fri, 14 Jul 2006 10:35:34 -0400 Received: from s1.mailresponder.info ([193.24.237.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1NrT-0005pz-Q1 for Sip@ietf.org; Fri, 14 Jul 2006 09:37:46 -0400 Received: from moonfish.nero.com (193.47.77.31) by s1.mailresponder.info with MERCUR Mailserver (v4.02.30 ODAtMjQzOS03MTc5) for ; Fri, 14 Jul 2006 15:37:00 +0200 Received: from smtp.ahead.de (unknown [192.168.1.222]) by moonfish.nero.com (Postfix) with ESMTP id 162462157DD; Fri, 14 Jul 2006 15:36:49 +0200 (CEST) Received: from [192.168.10.32] (unknown [192.168.10.32]) by smtp.ahead.de (Postfix) with ESMTP id 990772DE92D; Fri, 14 Jul 2006 15:36:49 +0200 (CEST) Message-ID: <44B79DF1.2020801@nero.com> Date: Fri, 14 Jul 2006 15:36:49 +0200 From: Markus Hofmann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ant=F3nio_Manuel_Amaral?= Subject: Re: [Sip] S-CSCF expected behavior References: <75D349FBF7C131408F5061B7168072C30329DB49@INOAVREX06.ptin.corpPT.com> In-Reply-To: <75D349FBF7C131408F5061B7168072C30329DB49@INOAVREX06.ptin.corpPT.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Ant=F3nio, I can't answer your question. I think you should contact the 3G which is responsible for IMS. Regards Markus Ant=F3nio Manuel Amaral wrote: > Dear All, >=20 > I don't know if this is the correct mailing list to put my question and= if not my apologies for that. >=20 > Consider the following IMS scenario >=20 >=20 > (IMS core Network) -> S-CSCF -> AS >=20 >=20 > If the connection between AS and S-CSCF fails what is the expected beha= vior of S-CSCF? It must release all active calls sending BYE messages to = caller and called clients in order to terminate the calls? >=20 > Thanks in advance >=20 > Regards >=20 > AA=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 11:22:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1PT1-00071q-8B; Fri, 14 Jul 2006 11:20:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1PSz-00071i-NR for sip@ietf.org; Fri, 14 Jul 2006 11:20:33 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1PSt-0006Hu-Bp for sip@ietf.org; Fri, 14 Jul 2006 11:20:33 -0400 Received: from [132.219.27.189] (h1bbd-net84db.lab.risq.net [132.219.27.189] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6EDOvir028205 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 14 Jul 2006 09:24:59 -0400 (EDT) In-Reply-To: <4.3.2.7.2.20060714002144.03a291f8@email.cisco.com> References: <4.3.2.7.2.20060713174710.02763c40@email.cisco.com> <4.3.2.7.2.20060713174710.02763c40@email.cisco.com> <4.3.2.7.2.20060714002144.03a291f8@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] Location header Date: Fri, 14 Jul 2006 09:24:54 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org For the purposes of routing, such challenges are unlikely to be feasible or even plausible. Are you going to give a special secret to all possible carriers, PSAPs, E-CSCFs in the world, for every single individual? Good luck... On Jul 14, 2006, at 1:28 AM, James M. Polk wrote: > At 07:25 PM 7/13/2006 -0400, Hannes Tschofenig wrote: >> Hi James, >> >> please explain me the difference (from a security point of view) >> between >> * adding a location object into the header that is not encrypted, and >> * adding a reference to a location object to the header that can >> be resolved into a location object by everyone that knows the >> reference? > > The server which has the by-referenced PIDF-LO can challenge > whoever asks for the PIDF-LO. The header URI allows for each > intermediary to ask for the dereference, but only those that have > permission, surviving the challenge(s), get the PIDF-LO. This > means not all dereference attempts learn the UAC's location. This > cannot be accomplished in a header. > > >> Ciao >> Hannes >> >> James M. Polk wrote: >>> Right now, the ID lists options 1 and 2 as the only options, and >>> this keeps things simple. There have been a couple of comments >>> here in Montreal that adding a data URL isn't really wanted. >>> One reason given is the inability to encrypt it (easily). A message >>> body can be encypted using S/MIME, and a URI can have the server >>> posessing the PIDF-LO configured to challenge a dereference >>> request - including responding with an encrypted PIDF-LO. Both >>> these senarios have the PIDF-LO being able to be encrypted. I'm >>> not so sure encrypting the data URL is so straightforward, or >>> deployable. Others, please inform me and the list if this is >>> untrue. >>> Cannot the ID proceed as is (in this respect), and once someone >>> wants to extend this doc (once it's an RFC), propose that >>> extention as a separate ID? >>> At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: >>> >>>> To follow up on the discussion in the SIP group. I think there are >>>> roughly three options for the content of Location: >>>> >>>> (1) Point to content in the body --> can't be modified and >>>> cannot be >>>> inserted by proxies (and may not be inspectable by proxies if >>>> encrypted) >>>> >>>> (2) Point to external location --> can be modified, can be >>>> added, but >>>> can induce loops if changed in mid-stream and incurs another >>>> failure >>>> mode (and possible security risks if the reference is generally >>>> accessible) >>>> >>>> (3) Point to data URL (RFC 2397) as in >>>> >>>> Location: data:application/pidf+xml;base64,>>> PIDF-LO) >>>> >>>> Disadvantage: about 30% larger than as body; can't be encrypted >>>> separately (except as XML-DSIG) >>>> >>>> Advantages: can be inserted/modified by proxies (similar to >>>> (2)), but >>>> avoids difficulty of external reference >>>> >>>> I think these three methods all have different time-space- >>>> flexibility >>>> trade-offs and thus I suspect they all serve a need. >>>> >>>> Henning >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 11:40:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Pk7-0008G6-2p; Fri, 14 Jul 2006 11:38:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Pk4-0008EC-VI for sip@ietf.org; Fri, 14 Jul 2006 11:38:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OlM-0007Gs-By for sip@ietf.org; Fri, 14 Jul 2006 10:35:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1OIV-0006KM-9l for sip@ietf.org; Fri, 14 Jul 2006 10:05:41 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 14 Jul 2006 07:05:40 -0700 X-IronPort-AV: i="4.06,243,1149490800"; d="scan'208"; a="305830370:sNHT29579520" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6EE5ci6018249; Fri, 14 Jul 2006 07:05:38 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6EE5b79015612; Fri, 14 Jul 2006 07:05:38 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 10:05:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Location header Date: Fri, 14 Jul 2006 10:05:36 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B36553@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Location header Thread-Index: AcanS98VHuV/NfUDRoC+oUsbUsaifQAANltg From: "Michael Hammer \(mhammer\)" To: "Hannes Tschofenig" , "James Polk \(jmpolk\)" X-OriginalArrivalTime: 14 Jul 2006 14:05:37.0760 (UTC) FILETIME=[951C8600:01C6A74E] DKIM-Signature: a=rsa-sha1; q=dns; l=5832; t=1152885938; x=1153749938; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Location=20header; X=v=3Dcisco.com=3B=20h=3DLNCrVuM0DNwc2cVWnvLt1u9qWXI=3D; b=B5NYpxiNSLYljtu7AEKAIgM8VHozYHk04zVy3vWvfzdmov2RP7vKVATf0mhpNs5P8F8KVzre QD9x6yY/Uw6AIlv/eAMFagF84vZOqE3Syd0qXULu+UYxaFamlG08/xRe; Authentication-Results: sj-dkim-7.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: sip@ietf.org, Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hannes, If you are right, then you are saying that symmetric secret keys are out of the question. That leaves some sort of public/private key type of operation. Contrary to what Jon suggested earlier, there are ways of passing an encrypted object to multiple recipients, namely by using a secret key to encrypt the LO, then adding the secret key enrypted by the public key of the intended recipient as an object for each recipient. This also has the characteristic that down-stream nodes upon learning of additional recipients, can add new Pu(secret) objects for those new recipients as needed. That does assume a chain of trust among those given access to the secret. Is that practical? I think so, but others may have their opinion. BTW, can someone re-summarize what the requirements are? It must be modifiable -> must be a header not body It must provide confidentiality -> encrypted or selectively handed out (by ref) Downstream recipient unknown to UAC must have access -> ??? ... Mike > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Friday, July 14, 2006 9:39 AM > To: James Polk (jmpolk) > Cc: sip@ietf.org; Henning Schulzrinne > Subject: Re: [Sip] Location header >=20 > Hi James, >=20 > James M. Polk wrote: > > At 07:25 PM 7/13/2006 -0400, Hannes Tschofenig wrote: > >=20 > >> Hi James, > >> > >> please explain me the difference (from a security point of view)=20 > >> between > >> * adding a location object into the header that is not=20 > encrypted, and > >> * adding a reference to a location object to the header=20 > that can be=20 > >> resolved into a location object by everyone that knows the=20 > reference? > >=20 > >=20 > > The server which has the by-referenced PIDF-LO can=20 > challenge whoever=20 > > asks for the PIDF-LO. The header URI allows for each=20 > intermediary to=20 > > ask for the dereference, but only those that have permission,=20 > > surviving the challenge(s), get the PIDF-LO. This means not all=20 > > dereference attempts learn the UAC's location. This cannot be=20 > > accomplished in a header. > This would assume that the entity that created the location=20 > object has a > relationship with the final location recipient (and to=20 > share some credential with them). >=20 > I think that this is a totally unrealistic assumption. >=20 >=20 > Ciao > Hannes >=20 > >=20 > >=20 > >> Ciao > >> Hannes > >> > >> James M. Polk wrote: > >> > >>> Right now, the ID lists options 1 and 2 as the only options, and=20 > >>> this keeps things simple. There have been a couple of=20 > comments here=20 > >>> in Montreal that adding a data URL isn't really wanted. > >>> One reason given is the inability to encrypt it (easily).=20 > A message=20 > >>> body can be encypted using S/MIME, and a URI can have the server=20 > >>> posessing the PIDF-LO configured to challenge a=20 > dereference request=20 > >>> - including responding with an encrypted PIDF-LO. Both these=20 > >>> senarios have the PIDF-LO being able to be encrypted. I'm not so=20 > >>> sure encrypting the data URL is so straightforward, or deployable. > >>> Others, please inform me and the list if this is untrue. > >>> Cannot the ID proceed as is (in this respect), and once someone=20 > >>> wants to extend this doc (once it's an RFC), propose that=20 > extention=20 > >>> as a separate ID? > >>> At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: > >>> > >>>> To follow up on the discussion in the SIP group. I think=20 > there are=20 > >>>> roughly three options for the content of Location: > >>>> > >>>> (1) Point to content in the body --> can't be modified=20 > and cannot=20 > >>>> be inserted by proxies (and may not be inspectable by proxies if > >>>> encrypted) > >>>> > >>>> (2) Point to external location --> can be modified, can=20 > be added,=20 > >>>> but can induce loops if changed in mid-stream and incurs another=20 > >>>> failure mode (and possible security risks if the reference is=20 > >>>> generally > >>>> accessible) > >>>> > >>>> (3) Point to data URL (RFC 2397) as in > >>>> > >>>> Location: data:application/pidf+xml;base64, >>>> PIDF-LO) > >>>> > >>>> Disadvantage: about 30% larger than as body; can't be encrypted=20 > >>>> separately (except as XML-DSIG) > >>>> > >>>> Advantages: can be inserted/modified by proxies (similar=20 > to (2)),=20 > >>>> but avoids difficulty of external reference > >>>> > >>>> I think these three methods all have different=20 > >>>> time-space-flexibility trade-offs and thus I suspect=20 > they all serve a need. > >>>> > >>>> Henning > >>>> > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>> sipping@ietf.org for new developments on the application of sip > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >=20 > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 11:40:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Pkb-0000Ke-6B; Fri, 14 Jul 2006 11:38:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1PkZ-0000KL-71 for sip@ietf.org; Fri, 14 Jul 2006 11:38:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OlQ-0007Gs-8C for sip@ietf.org; Fri, 14 Jul 2006 10:35:32 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1O2c-0005zf-Vv for sip@ietf.org; Fri, 14 Jul 2006 09:49:21 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 1440F6C033; Fri, 14 Jul 2006 08:48:22 -0400 (EDT) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses From: Scott Lawrence To: Dean Willis In-Reply-To: <39781D93-F289-4B58-B384-42B2A405DEC5@softarmor.com> References: <1150495197.10237.51.camel@sukothai.pingtel.com> <1151955580.2892.102.camel@sukothai.pingtel.com> <44ADF4E9.5000305@cisco.com> <1152802404.2840.81.camel@localhost.localdomain> <39781D93-F289-4B58-B384-42B2A405DEC5@softarmor.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Fri, 14 Jul 2006 09:48:23 -0400 Message-Id: <1152884903.2863.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Thu, 2006-07-13 at 16:14 -0500, Dean Willis wrote: > On Jul 13, 2006, at 9:53 AM, Scott Lawrence wrote: > > > When sending an error response that has a message/sipfrag > > body, > > the responding server MUST examine all the Via header > > values in > > the request. If any Via header value specifies UDP, then the > > total size of the response body MUST NOT be greater than 200 > > bytes and the server MUST follow the procedures in section > > X to > > prune the returned message/sipfrag body to fit within this > > limit. If no request Via header value specifies UDP, then the > > server is free to either prune the returned message/sipfrag > > body > > as specified in section X or to return the full set of request > > headers. > > Since UDP is the default, you may need this to say "Does not specify > TCP, TLS, or SCTP". I don't believe that we're in danger of the SIP standard adding any other transports that share the unreliable and network-hostile characteristics of UDP, but it seems likely that there will in the future be other reliable transports that can cope with large responses, so I'd prefer to express this in a way that doesn't need to be updated when that happens. Would it be more clear to replace 'specifies UDP' with 'indicates that UDP is used' ? > Also, this will still explode in environments where evil topology- > hiding functions (common in SBCs) have suppressed the Via header > fields. Some people would have me believe that this occurs in most if > not all IMS deployments, giving us a low probability that large > responses will ever actually work. People who deploy such things and don't keep them up to date when the protocol changes deserve what happens to them. I don't think that we need to maintain backward compatibility or otherwise protect the clueless from implementations that have chosen (for, I am sure, good and/or revenue-generating reasons) to violate MUST-level rules. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 14:05:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1S0N-0005sk-Rs; Fri, 14 Jul 2006 14:03:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1S0L-0005pJ-EB for sip@ietf.org; Fri, 14 Jul 2006 14:03:09 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1S0K-0004TX-LV for sip@ietf.org; Fri, 14 Jul 2006 14:03:09 -0400 Received: (qmail invoked by alias); 14 Jul 2006 18:03:07 -0000 Received: from h1f81-net84db.lab.risq.net (EHLO [132.219.31.129]) [132.219.31.129] by mail.gmx.net (mp007) with SMTP; 14 Jul 2006 20:03:07 +0200 X-Authenticated: #29516787 Message-ID: <44B7DC5F.3040802@gmx.net> Date: Fri, 14 Jul 2006 14:03:11 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] Location header References: <072C5B76F7CEAB488172C6F64B30B5E301B365BD@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301B365BD@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a9ddb14fac983e71b59f23b52a45b4e Cc: sip@ietf.org, "James Polk \(jmpolk\)" , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Mike, Michael Hammer (mhammer) wrote: > I wouldn't call them my requirements per se, I was just trying to read > between the lines of the discussion and extract why some folks were > arguing for or against based on a statement or requirement/assumption. > > The inclusion v. reference and header v. body arguments aside, it seemed > as though there were two dimensions here: > > Set of nodes with which the Client has trust relationship versus not I don't like the term trust since it is too fuzzy. Furthermore, we have multiple entities playing a role here: Target, SIP Proxy, Location Recipient > Set of nodes that have permitted "need to know" location versus not I agree with this one. > > 1) Relationship + need to know > 2) No Relation + need to know > 3) Relationship + no need to know > 4) No Relation + need to know > > I thought each of the above needed to be addressed. But, my suggestion > for 4) based on overlapping trust groups seemed to be deemed jumping > ahead of the immediate issues. I will write a longer mail that describes the scenario I can see. Ciao Hannes > > Mike > > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Friday, July 14, 2006 10:50 AM >>To: Michael Hammer (mhammer) >>Cc: James Polk (jmpolk); sip@ietf.org; Henning Schulzrinne >>Subject: Re: [Sip] Location header >> >>Hi Mike, >> >>I agree that the current document does not cover all the >>requirements and does not go into a deep discussion of the >>security/privacy aspects. >>I am happy to discuss these. >> >>Maybe you could restate your requirements again in more details. >> >>Ciao >>Hannes >> >>Michael Hammer (mhammer) wrote: >> >>>Hannes, >>> >>>I went back and re-read those requirements. My problem >> >>here is that >> >>>the arguments for one approach versus another are not >> >>always covered >> >>>by those requirements. In other words, a requirement is being >>>inferred from the general requirement "do privacy". So, if someone >>>argues that X is not good enough because it doesn't meet Y, >> >>and Y is >> >>>not a requirement, then the argument is baseless. >>> >>>Much of the debate surrounds assumptions about topology and trust >>>relationships (or not) between various nodes. >>> >>>Disagreement on assumptions/requirements -> Disagreement on >> >>solutions. >> >>>Mike >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>Sent: Friday, July 14, 2006 10:20 AM >>>>To: Michael Hammer (mhammer) >>>>Cc: James Polk (jmpolk); sip@ietf.org; Henning Schulzrinne >>>>Subject: Re: [Sip] Location header >>>> >>>>Hi Mike, >>>> >>>>Michael Hammer (mhammer) wrote: >>>> >>>> >>>>>Hannes, >>>>> >>>>>If you are right, then you are saying that symmetric secret >>>> >>>>keys are >>>> >>>> >>>>>out of the question. That leaves some sort of >>>> >>>>public/private key type >>>> >>>> >>>>>of operation. >>>> >>>>The problem is not only the authentication but the authorization. >>>> >>>>Virtually everyone could be location recipient. >>>> >>>> >>>> >>>>>Contrary to what Jon suggested earlier, there are ways of >>>> >>>>passing an >>>> >>>> >>>>>encrypted object to multiple recipients, namely by using a >>>> >>>>secret key >>>> >>>> >>>>>to encrypt the LO, then adding the secret key enrypted by >>>> >>>>the public >>>> >>>> >>>>>key of the intended recipient as an object for each recipient. >>>> >>>>We haven't even come to the problem of multiple recipient with a >>>>single message. >>>> >>>>... and: S/MIME does not provide these capabilities. >>>> >>>> This also has >>>> >>>> >>>>>the characteristic that down-stream nodes upon learning of >>>> >>>>additional >>>> >>>> >>>>>recipients, can add new Pu(secret) objects for those new >>>> >>>>recipients as >>>> >>>> >>>>>needed. That does assume a chain of trust among those >>>> >>>>given access to >>>> >>>> >>>>>the secret. >>>>> >>>>>Is that practical? I think so, but others may have their opinion. >>>>> >>>> >>>> >>>>This is just an optimization of encrypting location objects to >>>>individual recipients. I am not sure we are even closen to >>>>optimizations. >>>> >>>> >>>> >>>> >>>>>BTW, can someone re-summarize what the requirements are? >>>> >>>>Requirements for what exactly? Most of the requirements are >> >>listed in >> >>>>the document provided by James & Brian. >>>> >>>> >>>> >>>>>It must be modifiable -> must be a header not body It must provide >>>>>confidentiality -> encrypted or selectively >>>> >>>>handed out >>>> >>>> >>>>>(by ref) >>>>>Downstream recipient unknown to UAC must have access -> ??? >>>>>... >>>> >>>>What is 'it'? >>>> >>>> >>>>Ciao >>>>Hannes >>>> >>>> >>>> >>>>>Mike >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>Sent: Friday, July 14, 2006 9:39 AM >>>>>>To: James Polk (jmpolk) >>>>>>Cc: sip@ietf.org; Henning Schulzrinne >>>>>>Subject: Re: [Sip] Location header >>>>>> >>>>>>Hi James, >>>>>> >>>>>>James M. Polk wrote: >>>>>> >>>>>> >>>>>> >>>>>>>At 07:25 PM 7/13/2006 -0400, Hannes Tschofenig wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi James, >>>>>>>> >>>>>>>>please explain me the difference (from a security point >> >>of view) >> >>>>>>>>between >>>>>>>>* adding a location object into the header that is not >>>>>> >>>>>>encrypted, and >>>>>> >>>>>> >>>>>> >>>>>>>>* adding a reference to a location object to the header >>>>>> >>>>>>that can be >>>>>> >>>>>> >>>>>> >>>>>>>>resolved into a location object by everyone that knows the >>>>>> >>>>>>reference? >>>>>> >>>>>> >>>>>> >>>>>>>The server which has the by-referenced PIDF-LO can >>>>>> >>>>>>challenge whoever >>>>>> >>>>>> >>>>>> >>>>>>>asks for the PIDF-LO. The header URI allows for each >>>>>> >>>>>>intermediary to >>>>>> >>>>>> >>>>>> >>>>>>>ask for the dereference, but only those that have permission, >>>>>>>surviving the challenge(s), get the PIDF-LO. This means not all >>>>>>>dereference attempts learn the UAC's location. This cannot be >>>>>>>accomplished in a header. >>>>>> >>>>>>This would assume that the entity that created the >> >>location object >> >>>>>>has a relationship with the final location recipient >> >>(and to share >> >>>>>>some credential with them). >>>>>> >>>>>>I think that this is a totally unrealistic assumption. >>>>>> >>>>>> >>>>>>Ciao >>>>>>Hannes >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>Ciao >>>>>>>>Hannes >>>>>>>> >>>>>>>>James M. Polk wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Right now, the ID lists options 1 and 2 as the only >> >>options, and >> >>>>>>>>>this keeps things simple. There have been a couple of >>>>>> >>>>>>comments here >>>>>> >>>>>> >>>>>> >>>>>>>>>in Montreal that adding a data URL isn't really wanted. >>>>>>>>>One reason given is the inability to encrypt it (easily). >>>>>> >>>>>>A message >>>>>> >>>>>> >>>>>> >>>>>>>>>body can be encypted using S/MIME, and a URI can have >> >>the server >> >>>>>>>>>posessing the PIDF-LO configured to challenge a >>>>>> >>>>>>dereference request >>>>>> >>>>>> >>>>>> >>>>>>>>>- including responding with an encrypted PIDF-LO. Both these >>>>>>>>>senarios have the PIDF-LO being able to be encrypted. >>>> >>>>I'm not so >>>> >>>> >>>>>>>>>sure encrypting the data URL is so straightforward, or >>>> >>>>deployable. >>>> >>>> >>>>>>>>>Others, please inform me and the list if this is untrue. >>>>>>>>>Cannot the ID proceed as is (in this respect), and >> >>once someone >> >>>>>>>>>wants to extend this doc (once it's an RFC), propose that >>>>>> >>>>>>extention >>>>>> >>>>>> >>>>>> >>>>>>>>>as a separate ID? >>>>>>>>>At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>To follow up on the discussion in the SIP group. I think >>>>>> >>>>>>there are >>>>>> >>>>>> >>>>>> >>>>>>>>>>roughly three options for the content of Location: >>>>>>>>>> >>>>>>>>>>(1) Point to content in the body --> can't be modified >>>>>> >>>>>>and cannot >>>>>> >>>>>> >>>>>> >>>>>>>>>>be inserted by proxies (and may not be inspectable by >> >>proxies if >> >>>>>>>>>>encrypted) >>>>>>>>>> >>>>>>>>>>(2) Point to external location --> can be modified, can >>>>>> >>>>>>be added, >>>>>> >>>>>> >>>>>> >>>>>>>>>>but can induce loops if changed in mid-stream and >>>> >>>>incurs another >>>> >>>> >>>>>>>>>>failure mode (and possible security risks if the reference is >>>>>>>>>>generally >>>>>>>>>>accessible) >>>>>>>>>> >>>>>>>>>>(3) Point to data URL (RFC 2397) as in >>>>>>>>>> >>>>>>>>>>Location: data:application/pidf+xml;base64,>>>>>>>>>PIDF-LO) >>>>>>>>>> >>>>>>>>>>Disadvantage: about 30% larger than as body; can't be >> >>encrypted >> >>>>>>>>>>separately (except as XML-DSIG) >>>>>>>>>> >>>>>>>>>>Advantages: can be inserted/modified by proxies (similar >>>>>> >>>>>>to (2)), >>>>>> >>>>>> >>>>>> >>>>>>>>>>but avoids difficulty of external reference >>>>>>>>>> >>>>>>>>>>I think these three methods all have different >>>>>>>>>>time-space-flexibility trade-offs and thus I suspect >>>>>> >>>>>>they all serve a need. >>>>>> >>>>>> >>>>>> >>>>>>>>>>Henning >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>_______________________________________________ >>>>>>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>>>>This list is for NEW development of the core SIP Protocol Use >>>>>>>>>>sip-implementors@cs.columbia.edu for questions on >>>>>> >>>>>>current sip Use >>>>>> >>>>>> >>>>>> >>>>>>>>>>sipping@ietf.org for new developments on the >> >>application of sip >> >>>>>>>>> >>>>>>>>>_______________________________________________ >>>>>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>>>This list is for NEW development of the core SIP Protocol Use >>>>>>>>>sip-implementors@cs.columbia.edu for questions on >>>> >>>>current sip Use >>>> >>>> >>>>>>>>>sipping@ietf.org for new developments on the application of sip >>>>>>> >>>>>>> >>>>>>> >>>>>>_______________________________________________ >>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>This list is for NEW development of the core SIP Protocol Use >>>>>>sip-implementors@cs.columbia.edu for questions on current sip Use >>>>>>sipping@ietf.org for new developments on the application of sip >>>>>> >>>>> >>>>> >>>>> >>> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 14:23:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SIO-0006qf-7N; Fri, 14 Jul 2006 14:21:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SIN-0006qa-0O for sip@ietf.org; Fri, 14 Jul 2006 14:21:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1SIL-0000Gp-9Z for sip@ietf.org; Fri, 14 Jul 2006 14:21:46 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 14 Jul 2006 11:21:46 -0700 X-IronPort-AV: i="4.06,244,1149490800"; d="scan'208"; a="305898797:sNHT31081328" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6EILiVe031703; Fri, 14 Jul 2006 11:21:44 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6EILiHS016070; Fri, 14 Jul 2006 11:21:44 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 14:21:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Location header Date: Fri, 14 Jul 2006 14:21:42 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301B366AD@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Location header Thread-Index: Acanb8seKqGb58zCRcSv2xSsxzDwsAAAfPBw From: "Michael Hammer \(mhammer\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 14 Jul 2006 18:21:43.0786 (UTC) FILETIME=[5BFA04A0:01C6A772] DKIM-Signature: a=rsa-sha1; q=dns; l=12481; t=1152901304; x=1153765304; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Location=20header; X=v=3Dcisco.com=3B=20h=3DLNCrVuM0DNwc2cVWnvLt1u9qWXI=3D; b=MSLUD67JjoG0Dta7KZI6elhK3jSnVM3ru5Qh8dDZ9nQH7VxzpTa2GJw54MLy8O777NrOOAGE j9RZeVCdRXu4vWP64hc2e8dbYUJb3Riy0oyuVgnDnOK4dWd95hMOHyma; Authentication-Results: sj-dkim-8.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a50b6fe619b8c4df89c7095cedd22e37 Cc: sip@ietf.org, "James Polk \(jmpolk\)" , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yeah, trust is fuzzy. =20 But it all boils down to whether two parties have a means to pass information securely to each other, while excluding others. =20 The trust part is that party A gives it to party B "knowing" that B can see it. =20 A has to "trust" the B will do the right thing with the information. Mike > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Friday, July 14, 2006 2:03 PM > To: Michael Hammer (mhammer) > Cc: James Polk (jmpolk); sip@ietf.org; Henning Schulzrinne > Subject: Re: [Sip] Location header >=20 > Hi Mike, >=20 > Michael Hammer (mhammer) wrote: > > I wouldn't call them my requirements per se, I was just=20 > trying to read=20 > > between the lines of the discussion and extract why some folks were=20 > > arguing for or against based on a statement or=20 > requirement/assumption. > >=20 > > The inclusion v. reference and header v. body arguments aside, it=20 > > seemed as though there were two dimensions here: > >=20 > > Set of nodes with which the Client has trust relationship versus not >=20 > I don't like the term trust since it is too fuzzy. > Furthermore, we have multiple entities playing a role here:=20 > Target, SIP Proxy, Location Recipient >=20 > > Set of nodes that have permitted "need to know" location versus not >=20 > I agree with this one. >=20 > >=20 > > 1) Relationship + need to know > > 2) No Relation + need to know > > 3) Relationship + no need to know > > 4) No Relation + need to know > >=20 > > I thought each of the above needed to be addressed. But, my=20 > > suggestion for 4) based on overlapping trust groups seemed to be=20 > > deemed jumping ahead of the immediate issues. > I will write a longer mail that describes the scenario I can see. >=20 > Ciao > Hannes >=20 > > =20 > > Mike > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>Sent: Friday, July 14, 2006 10:50 AM > >>To: Michael Hammer (mhammer) > >>Cc: James Polk (jmpolk); sip@ietf.org; Henning Schulzrinne > >>Subject: Re: [Sip] Location header > >> > >>Hi Mike, > >> > >>I agree that the current document does not cover all the=20 > requirements=20 > >>and does not go into a deep discussion of the security/privacy=20 > >>aspects. > >>I am happy to discuss these. > >> > >>Maybe you could restate your requirements again in more details. > >> > >>Ciao > >>Hannes > >> > >>Michael Hammer (mhammer) wrote: > >> > >>>Hannes, > >>> > >>>I went back and re-read those requirements. My problem > >> > >>here is that > >> > >>>the arguments for one approach versus another are not > >> > >>always covered > >> > >>>by those requirements. In other words, a requirement is being=20 > >>>inferred from the general requirement "do privacy". So,=20 > if someone=20 > >>>argues that X is not good enough because it doesn't meet Y, > >> > >>and Y is > >> > >>>not a requirement, then the argument is baseless. > >>> > >>>Much of the debate surrounds assumptions about topology and trust=20 > >>>relationships (or not) between various nodes. > >>> > >>>Disagreement on assumptions/requirements -> Disagreement on > >> > >>solutions. > >> > >>>Mike > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>Sent: Friday, July 14, 2006 10:20 AM > >>>>To: Michael Hammer (mhammer) > >>>>Cc: James Polk (jmpolk); sip@ietf.org; Henning Schulzrinne > >>>>Subject: Re: [Sip] Location header > >>>> > >>>>Hi Mike, > >>>> > >>>>Michael Hammer (mhammer) wrote: > >>>> > >>>> > >>>>>Hannes, > >>>>> > >>>>>If you are right, then you are saying that symmetric secret > >>>> > >>>>keys are > >>>> > >>>> > >>>>>out of the question. That leaves some sort of > >>>> > >>>>public/private key type > >>>> > >>>> > >>>>>of operation. > >>>> > >>>>The problem is not only the authentication but the authorization. > >>>> > >>>>Virtually everyone could be location recipient. > >>>> > >>>> > >>>> > >>>>>Contrary to what Jon suggested earlier, there are ways of > >>>> > >>>>passing an > >>>> > >>>> > >>>>>encrypted object to multiple recipients, namely by using a > >>>> > >>>>secret key > >>>> > >>>> > >>>>>to encrypt the LO, then adding the secret key enrypted by > >>>> > >>>>the public > >>>> > >>>> > >>>>>key of the intended recipient as an object for each recipient. > >>>> > >>>>We haven't even come to the problem of multiple recipient with a=20 > >>>>single message. > >>>> > >>>>... and: S/MIME does not provide these capabilities. > >>>> > >>>> This also has > >>>> > >>>> > >>>>>the characteristic that down-stream nodes upon learning of > >>>> > >>>>additional > >>>> > >>>> > >>>>>recipients, can add new Pu(secret) objects for those new > >>>> > >>>>recipients as > >>>> > >>>> > >>>>>needed. That does assume a chain of trust among those > >>>> > >>>>given access to > >>>> > >>>> > >>>>>the secret. > >>>>> > >>>>>Is that practical? I think so, but others may have=20 > their opinion. > >>>>> > >>>> > >>>> > >>>>This is just an optimization of encrypting location objects to=20 > >>>>individual recipients. I am not sure we are even closen to=20 > >>>>optimizations. > >>>> > >>>> > >>>> > >>>> > >>>>>BTW, can someone re-summarize what the requirements are? > >>>> > >>>>Requirements for what exactly? Most of the requirements are > >> > >>listed in > >> > >>>>the document provided by James & Brian. > >>>> > >>>> > >>>> > >>>>>It must be modifiable -> must be a header not body It=20 > must provide=20 > >>>>>confidentiality -> encrypted or selectively > >>>> > >>>>handed out > >>>> > >>>> > >>>>>(by ref) > >>>>>Downstream recipient unknown to UAC must have access -> ??? > >>>>>... > >>>> > >>>>What is 'it'? > >>>> > >>>> > >>>>Ciao > >>>>Hannes > >>>> > >>>> > >>>> > >>>>>Mike > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>>Sent: Friday, July 14, 2006 9:39 AM > >>>>>>To: James Polk (jmpolk) > >>>>>>Cc: sip@ietf.org; Henning Schulzrinne > >>>>>>Subject: Re: [Sip] Location header > >>>>>> > >>>>>>Hi James, > >>>>>> > >>>>>>James M. Polk wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>At 07:25 PM 7/13/2006 -0400, Hannes Tschofenig wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Hi James, > >>>>>>>> > >>>>>>>>please explain me the difference (from a security point > >> > >>of view) > >> > >>>>>>>>between > >>>>>>>>* adding a location object into the header that is not > >>>>>> > >>>>>>encrypted, and > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>* adding a reference to a location object to the header > >>>>>> > >>>>>>that can be > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>resolved into a location object by everyone that knows the > >>>>>> > >>>>>>reference? > >>>>>> > >>>>>> > >>>>>> > >>>>>>>The server which has the by-referenced PIDF-LO can > >>>>>> > >>>>>>challenge whoever > >>>>>> > >>>>>> > >>>>>> > >>>>>>>asks for the PIDF-LO. The header URI allows for each > >>>>>> > >>>>>>intermediary to > >>>>>> > >>>>>> > >>>>>> > >>>>>>>ask for the dereference, but only those that have permission,=20 > >>>>>>>surviving the challenge(s), get the PIDF-LO. This=20 > means not all=20 > >>>>>>>dereference attempts learn the UAC's location. This cannot be=20 > >>>>>>>accomplished in a header. > >>>>>> > >>>>>>This would assume that the entity that created the > >> > >>location object > >> > >>>>>>has a relationship with the final location recipient > >> > >>(and to share > >> > >>>>>>some credential with them). > >>>>>> > >>>>>>I think that this is a totally unrealistic assumption. > >>>>>> > >>>>>> > >>>>>>Ciao > >>>>>>Hannes > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>Ciao > >>>>>>>>Hannes > >>>>>>>> > >>>>>>>>James M. Polk wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>Right now, the ID lists options 1 and 2 as the only > >> > >>options, and > >> > >>>>>>>>>this keeps things simple. There have been a couple of > >>>>>> > >>>>>>comments here > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>in Montreal that adding a data URL isn't really wanted. > >>>>>>>>>One reason given is the inability to encrypt it (easily).=20 > >>>>>> > >>>>>>A message > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>body can be encypted using S/MIME, and a URI can have > >> > >>the server > >> > >>>>>>>>>posessing the PIDF-LO configured to challenge a > >>>>>> > >>>>>>dereference request > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>- including responding with an encrypted PIDF-LO. =20 > Both these=20 > >>>>>>>>>senarios have the PIDF-LO being able to be encrypted. > >>>> > >>>>I'm not so > >>>> > >>>> > >>>>>>>>>sure encrypting the data URL is so straightforward, or > >>>> > >>>>deployable. > >>>> > >>>> > >>>>>>>>>Others, please inform me and the list if this is untrue. > >>>>>>>>>Cannot the ID proceed as is (in this respect), and > >> > >>once someone > >> > >>>>>>>>>wants to extend this doc (once it's an RFC), propose that > >>>>>> > >>>>>>extention > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>as a separate ID? > >>>>>>>>>At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>To follow up on the discussion in the SIP group. I think > >>>>>> > >>>>>>there are > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>roughly three options for the content of Location: > >>>>>>>>>> > >>>>>>>>>>(1) Point to content in the body --> can't be modified > >>>>>> > >>>>>>and cannot > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>be inserted by proxies (and may not be inspectable by > >> > >>proxies if > >> > >>>>>>>>>>encrypted) > >>>>>>>>>> > >>>>>>>>>>(2) Point to external location --> can be modified, can > >>>>>> > >>>>>>be added, > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>but can induce loops if changed in mid-stream and > >>>> > >>>>incurs another > >>>> > >>>> > >>>>>>>>>>failure mode (and possible security risks if the=20 > reference is=20 > >>>>>>>>>>generally > >>>>>>>>>>accessible) > >>>>>>>>>> > >>>>>>>>>>(3) Point to data URL (RFC 2397) as in > >>>>>>>>>> > >>>>>>>>>>Location: data:application/pidf+xml;base64, version of > >>>>>>>>>>PIDF-LO) > >>>>>>>>>> > >>>>>>>>>>Disadvantage: about 30% larger than as body; can't be > >> > >>encrypted > >> > >>>>>>>>>>separately (except as XML-DSIG) > >>>>>>>>>> > >>>>>>>>>>Advantages: can be inserted/modified by proxies (similar > >>>>>> > >>>>>>to (2)), > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>but avoids difficulty of external reference > >>>>>>>>>> > >>>>>>>>>>I think these three methods all have different=20 > >>>>>>>>>>time-space-flexibility trade-offs and thus I suspect > >>>>>> > >>>>>>they all serve a need. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>Henning > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>_______________________________________________ > >>>>>>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>>>>>>This list is for NEW development of the core SIP=20 > Protocol Use=20 > >>>>>>>>>>sip-implementors@cs.columbia.edu for questions on > >>>>>> > >>>>>>current sip Use > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>sipping@ietf.org for new developments on the > >> > >>application of sip > >> > >>>>>>>>> > >>>>>>>>>_______________________________________________ > >>>>>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>>>>>This list is for NEW development of the core SIP=20 > Protocol Use=20 > >>>>>>>>>sip-implementors@cs.columbia.edu for questions on > >>>> > >>>>current sip Use > >>>> > >>>> > >>>>>>>>>sipping@ietf.org for new developments on the=20 > application of sip > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>_______________________________________________ > >>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>>This list is for NEW development of the core SIP Protocol Use=20 > >>>>>>sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>>>>sipping@ietf.org for new developments on the application of sip > >>>>>> > >>>>> > >>>>> > >>>>> > >>> > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 15:18:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1T9L-00077P-8v; Fri, 14 Jul 2006 15:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1T9J-00073p-Ns for sip@ietf.org; Fri, 14 Jul 2006 15:16:29 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1T9I-0006Fw-CN for sip@ietf.org; Fri, 14 Jul 2006 15:16:29 -0400 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.03) id AD7F03B8; Fri, 14 Jul 2006 15:16:15 -0400 From: "Hadriel Kaplan" To: "'Scott Lawrence'" , "'Dean Willis'" Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses Date: Fri, 14 Jul 2006 15:16:08 -0400 Message-ID: <00c901c6a779$f60ee310$17e8a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcanW53sqA7VzBqZS5uyKAN7ACm2eQAEkIrA In-Reply-To: <1152884903.2863.36.camel@localhost.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'SIP WG List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Scott Lawrence [mailto:slawrence@pingtel.com] > > On Thu, 2006-07-13 at 16:14 -0500, Dean Willis wrote: > > Also, this will still explode in environments where evil topology- > > hiding functions (common in SBCs) have suppressed the Via header > > fields. Some people would have me believe that this occurs in most if > > not all IMS deployments, giving us a low probability that large > > responses will ever actually work. > > People who deploy such things and don't keep them up to date when the > protocol changes deserve what happens to them. I don't think that we > need to maintain backward compatibility or otherwise protect the > clueless from implementations that have chosen (for, I am sure, good > and/or revenue-generating reasons) to violate MUST-level rules. Actually, I think his point was that such evil practices will impact _your_ non-evil providers/UAs. And I take back what I said about it not being a problem, because I see Dean's point now and can think of how it can be a problem. The problem is if you're a good guy calling _through_ an evil provider (unbeknownst to you) transiting to other good providers. If the loop is in the other good provider, and they implement this draft, but the evil one doesn't strip the attachment, then the extra-large response may not get back to you because of UDP issues. So you'll not get the final response, and have a bad calling experience, and create issues for the good provider as well. That's not good, for the good guys. While I know at least some Via-hiding boxes can strip the attachment out, that doesn't mean all of them will/can. So perhaps you should size-limit all responses. The odds of some hop or other not being UDP isn't that good anyway today, and not many will want to implement a draft which negatively impacts them for even a subset of cases. Though I would like TCP-usage to get the benefit of TCP to promote its use in the future, if you want rapid ubiquitous adoption of this draft mechanism then you have to co-exist with such use cases, IMHO. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 22:10:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ZaI-0003GH-Oq; Fri, 14 Jul 2006 22:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ZaH-0003GC-HY for sip@ietf.org; Fri, 14 Jul 2006 22:08:45 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1ZaG-0005VZ-6S for sip@ietf.org; Fri, 14 Jul 2006 22:08:45 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 14 Jul 2006 19:08:43 -0700 X-IronPort-AV: i="4.06,245,1149490800"; d="scan'208"; a="1838816555:sNHT26170440" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6F28hmZ015176; Fri, 14 Jul 2006 19:08:43 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6F28g79029603; Fri, 14 Jul 2006 19:08:43 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 22:08:42 -0400 Received: from [192.168.1.100] ([10.86.243.31]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 22:08:42 -0400 Message-ID: <44B84E29.8090601@cisco.com> Date: Fri, 14 Jul 2006 22:08:41 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Sip] Location header References: <072C5B76F7CEAB488172C6F64B30B5E301B36553@xmb-rtp-20b.amer.cisco.com> <261A6AFC-6ED2-4342-A1FF-AC6C85114B12@cs.columbia.edu> In-Reply-To: <261A6AFC-6ED2-4342-A1FF-AC6C85114B12@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2006 02:08:42.0280 (UTC) FILETIME=[984CEA80:01C6A7B3] DKIM-Signature: a=rsa-sha1; q=dns; l=2071; t=1152929323; x=1153793323; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Location=20header; X=v=3Dcisco.com=3B=20h=3D5stgOrkqzvZmleb6hokXY1Rr++Y=3D; b=k1RQ4DjJGXVhQmb4J8TxXJ2qnNiYPzs4au5iPLenVOaV2fMRCnlmLRIHoCfwBto5/sYNHem9 wiATjXGegPzeGHnrsackv6Vlg1rOP4+5O5J7w3ZyV2TZa6A+k0ikjtLF; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org, "James Polk \(jmpolk\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Henning Schulzrinne wrote: > I suspect there are multiple deployment scenarios, so it is probably > impossible to say that it is (or not), in general. However, we might > take two location-based routing scenarios that we have discussed: > > (1) emergency calling > > (2) calling for towing service > > For either, I'm having a really hard time picturing how the sender (or > the originating VSP) can know the credentials or even identity of the > proxies that are on the signaling path. My VSP is located in Germany; > it is unlikely to have any relationship with the Montreal fire > department or, more importantly, the routing model of the emergency > calling network in Canada. True. Whats interesting is that, as Jon and others have said, location-by-reference allows the owner of the location to apply many different types of authorization policies. One type of authorization policy could simply be 'anyone on the path of this request is allowed to access the data for the duration of the dialog'. To provide this, as long as each hop was encrypted ala sips, if a proxy inserted an HTTP URI with a crypto-random URI, the proxy would grant access to the location information as long as the dialog is still active. Of course, you can always use traditional white lists if you happen to be in an environment where there is a pre-arranged relationship between parties. Location by reference allows both parties. I do think, though, that Henning raises a good point, which is that, if you do specify location by reference, you need to be very crisp on how long the entity is expected to cache the data, and whether it can change it. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 23:07:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1aSu-0003Ld-Fv; Fri, 14 Jul 2006 23:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1aSt-0003LY-IA for sip@ietf.org; Fri, 14 Jul 2006 23:05:11 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1aSs-000344-AQ for sip@ietf.org; Fri, 14 Jul 2006 23:05:11 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20060715030509m1200npv7ue>; Sat, 15 Jul 2006 03:05:09 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k6F357N1031625 for ; Fri, 14 Jul 2006 23:05:07 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k6F357EY031621; Fri, 14 Jul 2006 23:05:07 -0400 Date: Fri, 14 Jul 2006 23:05:07 -0400 Message-Id: <200607150305.k6F357EY031621@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1152814344.2854.2.camel@localhost.localdomain> (slawrence@pingtel.com) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses References: <1150495197.10237.51.camel@sukothai.pingtel.com> <1151955580.2892.102.camel@sukothai.pingtel.com> <44ADF4E9.5000305@cisco.com> <1152802404.2840.81.camel@localhost.localdomain> <3c17e6330e8571d304ba52b461a628d2@telio.no> <00da01c6a693$a0669ac0$31713b51@BEMBUSTER> <1152814344.2854.2.camel@localhost.localdomain> X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Scott Lawrence On Thu, 2006-07-13 at 17:47 +0200, Jeroen van Bemmel wrote: > gzip on the body might help too If I'm not mistaken, it's not trivial to figure out how much any given text will compress with gzip unless you actually try each possibility. Also, it doesn't do all that well on short inputs. I just googled up a few web pages and e-mail archives containing a total of 56 of SIP messages, extracted them, and ran gzip on them. It turns out that gzip compresses them poorly -- the median compression is 70% (compressed size / original size); 67% is at about the 25th percentile. My guess is that many of the longer fields are authentication, call-ID, and branch-parameter fields, all of which are pseudo-random. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 23:17:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1adA-0004hS-Pm; Fri, 14 Jul 2006 23:15:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ad9-0004hN-QQ for sip@ietf.org; Fri, 14 Jul 2006 23:15:47 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1ad8-0005Yq-JC for sip@ietf.org; Fri, 14 Jul 2006 23:15:47 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc12) with ESMTP id <20060715031545b1200k7d87e>; Sat, 15 Jul 2006 03:15:45 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k6F3FjN1031882 for ; Fri, 14 Jul 2006 23:15:45 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k6F3Fj3V031878; Fri, 14 Jul 2006 23:15:45 -0400 Date: Fri, 14 Jul 2006 23:15:45 -0400 Message-Id: <200607150315.k6F3Fj3V031878@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1152814538.2854.6.camel@localhost.localdomain> (slawrence@pingtel.com) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses References: <1150495197.10237.51.camel@sukothai.pingtel.com> <1151955580.2892.102.camel@sukothai.pingtel.com> <44ADF4E9.5000305@cisco.com> <1152802404.2840.81.camel@localhost.localdomain> <3c17e6330e8571d304ba52b461a628d2@telio.no> <1152814538.2854.6.camel@localhost.localdomain> X-Spam-Score: 2.1 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Scott Lawrence > Another option is to return, in the 4xx response, an http URI pointing > to a place where the server has stored the request. The requester can > then go and pull the SIP request. > > Might be an issue to interdomain cases, but not sure. I'm fairly sure that it would often be a problem. If we're going to this level of complexity, the right mechanism would likely be a SUBSCRIBE that gets a return NOTIFY containing the failed message -- using SIP to retrieve the message means that the interdomain issues are likely to be solved already. But I think that raises the bar for implementation too high -- people are unlikely to invest in installing that amount of machinery until the utility of the meachanism is proven. Let's implement the straightforward response body now. Later, if we decide a "remote retrival" mechanism would be useful, define how to put the branch-parameter from the top Via of the failing request in a SUBSCRIBE to retrieve the whole message... Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 23:31:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1aqk-0005pl-OI; Fri, 14 Jul 2006 23:29:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1aqj-0005pg-Tj for sip@ietf.org; Fri, 14 Jul 2006 23:29:49 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1aqi-0002Qs-Kt for sip@ietf.org; Fri, 14 Jul 2006 23:29:49 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20060715032947m11008od94e>; Sat, 15 Jul 2006 03:29:47 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k6F3TkN1032208 for ; Fri, 14 Jul 2006 23:29:46 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k6F3Tkul032204; Fri, 14 Jul 2006 23:29:46 -0400 Date: Fri, 14 Jul 2006 23:29:46 -0400 Message-Id: <200607150329.k6F3Tkul032204@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com> (samirsr@nortel.com) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses References: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Samir Srivastava" If it is looping/spiraling, then it will be having good compression ratio for 483. No, it won't, because most of the bytes in Via headers are in the branch parameters, which are all different, even when the message loops. Fortunately, a rather good job of pruning can be done by a simple algorithm: Sort all the headers by a weighting that says how valuable they are for diagnostics. The sort needs to be stable, in that all headers of the same type have their order preserved. Then retain an initial subset of the headers without going over the desired body length. The ordering of the headers will be something like this: Most valuable: Via Accept-* Content-* Least valuable: To From CSeq Call-ID Max-Forwards Contact Allow The last group of headers can always be omitted, even if you have no length restriction, because the UAC can reconstruct them, either (1) it is identical to the same header in the response, (2) it is generated with the same value in every request by the UAC, or (3) its value is constant in this situation (e.g., Max-Forwards is 0). Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 14 23:38:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1axB-00072N-Jm; Fri, 14 Jul 2006 23:36:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ax9-00072A-Ei for sip@ietf.org; Fri, 14 Jul 2006 23:36:27 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1ax8-0007iN-8T for sip@ietf.org; Fri, 14 Jul 2006 23:36:27 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc15) with ESMTP id <2006071503362501500q4slbe>; Sat, 15 Jul 2006 03:36:25 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k6F3aPN1032355 for ; Fri, 14 Jul 2006 23:36:25 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k6F3aPrQ032351; Fri, 14 Jul 2006 23:36:25 -0400 Date: Fri, 14 Jul 2006 23:36:25 -0400 Message-Id: <200607150336.k6F3aPrQ032351@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <00c901c6a779$f60ee310$17e8a8c0@acmepacket.com> (HKaplan@acmepacket.com) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses References: <00c901c6a779$f60ee310$17e8a8c0@acmepacket.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > Also, this will still explode in environments where evil topology- > > hiding functions (common in SBCs) have suppressed the Via header A representative of a company which makes evil devices mentioned to me that the Evil Device (TM) will most likely entirely consume such a 483 response (after logging it for internal use), but then generate a fresh 483 as if it came from the Evil Device at the point of entry to the Walled Garden (TM). This actually handles the separation of concerns sensibly -- If the routing error is inside of the Walled Garden, the Evil Device's log will capture the information that the Walled Garden's management will need to fix the problem. If due to some obscurity, the error happened before the request entered into the Walled Garden and generated a bogus request to the Walled Garden domain which caused the Walled Garden to fail, then a 483 from the Evil Device will show everything needed to diagnose the problem (including the request-URI at the point of entry to the Walled Garden). The messy case is when the loop goes through the Walled Garden but is not entirely contained by it, though correlating the logs of all the Even Devices should reveal the problem. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 15 01:37:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1cnz-0001B0-B2; Sat, 15 Jul 2006 01:35:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1cnx-0001A6-Ut for sip@ietf.org; Sat, 15 Jul 2006 01:35:05 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1cda-0006wE-VS for sip@ietf.org; Sat, 15 Jul 2006 01:24:25 -0400 Received: from [142.131.134.220] ([142.131.134.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6F5QEl5001585 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 15 Jul 2006 00:26:15 -0500 In-Reply-To: <1152884903.2863.36.camel@localhost.localdomain> References: <1150495197.10237.51.camel@sukothai.pingtel.com> <1151955580.2892.102.camel@sukothai.pingtel.com> <44ADF4E9.5000305@cisco.com> <1152802404.2840.81.camel@localhost.localdomain> <39781D93-F289-4B58-B384-42B2A405DEC5@softarmor.com> <1152884903.2863.36.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <269DA68F-70B5-4947-9983-4821A589CF41@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses Date: Sat, 15 Jul 2006 00:23:45 -0500 To: Scott Lawrence X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 14, 2006, at 8:48 AM, Scott Lawrence wrote: > > I don't believe that we're in danger of the SIP standard adding any > other transports that share the unreliable and network-hostile > characteristics of UDP, but it seems likely that there will in the > future be other reliable transports that can cope with large > responses, > so I'd prefer to express this in a way that doesn't need to be updated > when that happens. > I'll buy that. > Would it be more clear to replace 'specifies UDP' with 'indicates that > UDP is used' ? > There's probably some variation of language that would work here without saying TCP, etc. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 15 09:52:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1kXp-0007PB-7E; Sat, 15 Jul 2006 09:50:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1kXn-0007P6-Jp for sip@ietf.org; Sat, 15 Jul 2006 09:50:55 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1kXl-0002Gi-Bn for sip@ietf.org; Sat, 15 Jul 2006 09:50:55 -0400 Received: from lion.cs.columbia.edu (IDENT:Z2bA83KRO3GLj6oC2+vqBHG8uW8J6Z3O@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6FDoqlM029759 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 15 Jul 2006 09:50:52 -0400 (EDT) Received: from [192.168.0.41] (pool-138-89-20-244.mad.east.verizon.net [138.89.20.244]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6FDoooq008956 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 15 Jul 2006 09:50:51 -0400 In-Reply-To: <44B84E29.8090601@cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E301B36553@xmb-rtp-20b.amer.cisco.com> <261A6AFC-6ED2-4342-A1FF-AC6C85114B12@cs.columbia.edu> <44B84E29.8090601@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <585FEB01-4D57-4859-8D0C-D8204D8EDD64@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] Location header Date: Sat, 15 Jul 2006 09:50:34 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > One type of authorization policy could simply be 'anyone on the > path of this request is allowed to access the data for the duration > of the dialog'. To provide this, as long as each hop was encrypted > ala sips, if a proxy inserted an HTTP URI with a crypto-random > URI, the proxy would grant access to the location information as > long as the dialog is still active. That's essentially the same security model offered by the location-by- value approach, as far as I can tell. I agree that location-by-reference offers other security models; I never claimed that this is an either-or model; we can easily support both without changes in the header definition. After all, they are all URLs. The trade-off is that for the simple on-path-can-read, the by- reference approach incurs significant overhead, as the location provider has to be able to maintain an HTTP server that is accessible by any potential destination of the call. For the case of end-system inserted location, this now means another configuration option since the UA or proxy has to have write access to an HTTP server, which isn't even standardized right now. (HTTP PUT? XCAP? WebDAV? ftp? some other special protocol?) For proxy-inserted, that server has to be outside a NAT and globally reachable. In other words, for the common case you stipulate, by-reference only adds complexity and failure modes, with no increase in security or efficiency. (Actually, by reference is likely to be less efficient for the outbound-proxy inserts case, as multiple downstream proxies all have to open (TLS) connections to the server holding the location, each at several hundred or thousand bytes of traffic to get a 60-byte location object.) > > Of course, you can always use traditional white lists if you happen > to be in an environment where there is a pre-arranged relationship > between parties. Location by reference allows both parties. I'm not disagreeing and don't think I've ever said that location-by- reference is not useful in some circumstances. There's just no point paying the complexity and reliability cost when there is no functional difference. I think the basic design principle holds: simple things should be simple to do. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 15 11:13:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1lo5-0005rJ-Ml; Sat, 15 Jul 2006 11:11:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1lo4-0005rE-O8 for Sip@ietf.org; Sat, 15 Jul 2006 11:11:48 -0400 Received: from c243-111.rim.net ([216.9.243.111] helo=MHS02YKF.rim.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1lo2-0005DF-Es for Sip@ietf.org; Sat, 15 Jul 2006 11:11:48 -0400 Importance: normal Priority: normal Received: from ngw01ykf.rim.net ([10.102.108.30]) by MHS02YKF.rim.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 15 Jul 2006 11:11:44 -0400 Received: from XCH20YKF.rim.net ([10.102.100.35]) by ngw01ykf.rim.net (SAVSMTP 3.1.6.45) with SMTP id M2006071511114400623 ; Sat, 15 Jul 2006 11:11:44 -0400 Received: from XCH47YKF.rim.net ([10.64.31.217]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Sat, 15 Jul 2006 11:11:44 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] S-CSCF expected behavior Date: Sat, 15 Jul 2006 11:11:43 -0400 Message-ID: <61968779B8AC4C4BAB421D4C12F008C0038FB9BD@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] S-CSCF expected behavior thread-index: AcanKohfW6ExbiiZTYaW7GxX5A/+SAAAdtDQAACOIKAAPIMWAA== From: "Andrew Allen" To: =?iso-8859-1?Q?Ant=F3nio_Manuel_Amaral?= , X-OriginalArrivalTime: 15 Jul 2006 15:11:44.0958 (UTC) FILETIME=[FC28A5E0:01C6A820] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Antonio I suggest you subscribe to the 3GPP CT1 email list and ask this question = there. http://list.3gpp.org/scripts/wa.exe?SUBED1=3D3gpp_tsg_ct_wg1&A=3D1 Andrew -----Original Message----- From: Ant=F3nio Manuel Amaral [mailto:antonio-mn-amaral@ptinovacao.pt]=20 Sent: Friday, July 14, 2006 6:17 AM To: Sip@ietf.org Subject: [Sip] S-CSCF expected behavior Dear All, I don't know if this is the correct mailing list to put my question and = if not my apologies for that. Consider the following IMS scenario (IMS core Network) -> S-CSCF -> AS If the connection between AS and S-CSCF fails what is the expected = behavior of S-CSCF? It must release all active calls sending BYE = messages to caller and called clients in order to terminate the calls? Thanks in advance Regards AA=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 15 11:58:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1mVN-000494-E4; Sat, 15 Jul 2006 11:56:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1mVL-000473-QO for sip@ietf.org; Sat, 15 Jul 2006 11:56:31 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1mVK-0008CE-Bs for sip@ietf.org; Sat, 15 Jul 2006 11:56:31 -0400 Received: (qmail 8528 invoked by uid 0); 15 Jul 2006 15:56:28 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Jul 2006 15:56:28 -0000 Message-ID: <001e01c6a827$38b8bda0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com> <200607150329.k6F3Tkul032204@dragon.ariadne.com> Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses Date: Sat, 15 Jul 2006 17:56:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale, see inline Regards, jeroen > If it is looping/spiraling, then it will be having good compression > ratio for 483. > > No, it won't, because most of the bytes in Via headers are in the > branch parameters, which are all different, even when the message > loops. > I would say: prune those Via branch parameters. The only useful information they possibly provide, is whether the element is RFC3261 compliant or not. So take the first 7 chars of each via branch, and strip the rest. Then compression will be better too, the only problem is that the sender needs to support it (or at least be capable to log binary messages) > Fortunately, a rather good job of pruning can be done by a simple > algorithm: Sort all the headers by a weighting that says how valuable > they are for diagnostics. The sort needs to be stable, in that all > headers of the same type have their order preserved. Then retain an > initial subset of the headers without going over the desired body > length. > > The ordering of the headers will be something like this: > > Most valuable: Via > Add to this: the resulting request URI, Record-Route headers (many proxies append state in those, which might help) and Route headers. And as above, limit via branches to 7 chars (or even less, eg replace them with '1' or '0' depending on whether the magic cookie was there. Retain other parameters, such as 'alias' which might indicate that connection reuse is happening) > Accept-* including Accept-Contact and Reject-Contact, although in general all these UAC-inserted headers are less valuable; many UACs will either still have the original request (for retransmissions, in particular for UDP) or be able to reconstruct it. > > Content-* > > Least valuable: To > From > CSeq > Call-ID > Max-Forwards > Contact You'd perhaps also want any Contact header (though the UAC might reconstruct that). It could contain callee capabilities that explain why the request was routed in a particular way. > Allow > > The last group of headers can always be omitted, even if you have no > length restriction, because the UAC can reconstruct them, either (1) > it is identical to the same header in the response, (2) it is > generated with the same value in every request by the UAC, or (3) its > value is constant in this situation (e.g., Max-Forwards is 0). > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 15 17:55:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1s5A-0007Zt-KO; Sat, 15 Jul 2006 17:53:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1s58-0007X2-O6 for sip@ietf.org; Sat, 15 Jul 2006 17:53:50 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1s57-0006ub-9B for sip@ietf.org; Sat, 15 Jul 2006 17:53:50 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2006 14:53:48 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6FLrmZA003872; Sat, 15 Jul 2006 14:53:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6FLrm2D011081; Sat, 15 Jul 2006 14:53:48 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 15 Jul 2006 14:53:48 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.152.179]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Jul 2006 14:53:47 -0700 Message-Id: <4.3.2.7.2.20060715165232.02847818@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 15 Jul 2006 16:52:57 -0500 To: Henning Schulzrinne , Jonathan Rosenberg From: "James M. Polk" Subject: Re: [Sip] Location header In-Reply-To: <585FEB01-4D57-4859-8D0C-D8204D8EDD64@cs.columbia.edu> References: <44B84E29.8090601@cisco.com> <072C5B76F7CEAB488172C6F64B30B5E301B36553@xmb-rtp-20b.amer.cisco.com> <261A6AFC-6ED2-4342-A1FF-AC6C85114B12@cs.columbia.edu> <44B84E29.8090601@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 15 Jul 2006 21:53:47.0542 (UTC) FILETIME=[2656DB60:01C6A859] DKIM-Signature: a=rsa-sha1; q=dns; l=3585; t=1153000428; x=1153864428; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20Location=20header; X=v=3Dcisco.com=3B=20h=3DYE8qwqfS5T4Lc8n1KWqZhwTwo7I=3D; b=t4usgG/MQJ605R3aENZjXZ4RAtvpbG/LoOwS2F5bFv+8ZL818L55bY/zfIdRL/1T/kHE0NzW 0zwDN+9MFvs5ndF5vFDpnZBxQyjPsVv/BhF3vJb9PSgYxS2MVET6GMW3; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ok, let's bubble back up to use cases. What's the use case for a data URL giving Location in a header here, and does that function have to be solved/addressed now, in this document? I might add that just because something is possible, doesn't mean it needs to be specified every time. Reducing complexity means not taking on more than is necessary for the expected uses of a new protocol or extension to that protocol. If, in the future, that additional capability is needed, a new document can be written as an extension to this one. This allows, at least, for an implementation to be in 100% compliance with the earlier spec and choose not to do the additional function, which that implementation chooses not to offer. Again, this reduces complexity to where it is needed, yet allows any implementation to add functionality by incorporating additional spec(s). At 09:50 AM 7/15/2006 -0400, Henning Schulzrinne wrote: >>One type of authorization policy could simply be 'anyone on the >>path of this request is allowed to access the data for the duration >>of the dialog'. To provide this, as long as each hop was encrypted >>ala sips, if a proxy inserted an HTTP URI with a crypto-random >>URI, the proxy would grant access to the location information as >>long as the dialog is still active. > >That's essentially the same security model offered by the location-by- >value approach, as far as I can tell. > >I agree that location-by-reference offers other security models; I >never claimed that this is an either-or model; we can easily support >both without changes in the header definition. After all, they are >all URLs. > >The trade-off is that for the simple on-path-can-read, the by- reference >approach incurs significant overhead, as the location >provider has to be able to maintain an HTTP server that is accessible >by any potential destination of the call. For the case of end-system >inserted location, this now means another configuration option since >the UA or proxy has to have write access to an HTTP server, which >isn't even standardized right now. (HTTP PUT? XCAP? WebDAV? ftp? some >other special protocol?) For proxy-inserted, that server has to be >outside a NAT and globally reachable. > >In other words, for the common case you stipulate, by-reference only >adds complexity and failure modes, with no increase in security or >efficiency. (Actually, by reference is likely to be less efficient >for the outbound-proxy inserts case, as multiple downstream proxies >all have to open (TLS) connections to the server holding the >location, each at several hundred or thousand bytes of traffic to get >a 60-byte location object.) > > >> >>Of course, you can always use traditional white lists if you happen >>to be in an environment where there is a pre-arranged relationship >>between parties. Location by reference allows both parties. > >I'm not disagreeing and don't think I've ever said that location-by- >reference is not useful in some circumstances. There's just no point >paying the complexity and reliability cost when there is no >functional difference. > >I think the basic design principle holds: simple things should be >simple to do. > >Henning > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 16 09:57:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G275t-0006gc-8h; Sun, 16 Jul 2006 09:55:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G275s-0006fj-Dd for sip@ietf.org; Sun, 16 Jul 2006 09:55:36 -0400 Received: from rvil-eframer.radvision.com ([80.74.106.104] helo=eframer.radvision.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G275q-00083m-RI for sip@ietf.org; Sun, 16 Jul 2006 09:55:36 -0400 Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id k6GDwswj004354 for sip@ietf.org; Sun, 16 Jul 2006 16:58:54 +0300 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id k6GDwr17004348 for ; Sun, 16 Jul 2006 16:58:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] Update to RFC3329, aka Security Agreement Date: Sun, 16 Jul 2006 16:54:36 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Update to RFC3329, aka Security Agreement Thread-Index: AcZMfp+9hGcHNo7BR06KtHOp1PXezgAADfPAACApGxAW9sbCMA== From: "Sharon Laivand" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by eframer.radvision.com id k6GDwr17004348 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Aki and all... This email follows my conversation with Gonzalo at last IETF 66th - regarding RFC3329 issues. Here are some issues we thought of. I wonder if it can assist your draft. Anyway I will be glad to constantly contribute to this draft. Here are the comments/additions to the issues: 1. RFC3329 describes how the same security-agreement is used in several transactions, but does not specify the relations between those transactions. For example, a security-agreement can be obtained via OPTIONS transaction and then used by a call-leg. Since there is no SIP-wise relation between those two SIP entities, a key for comparison must be defined. This is extremely problematic on server side, because any incoming transaction must be verified according to the security-agreement used in previous (unrelated and even nonexistent) transactions. One possible solution that is not good for all cases: match of security-agreements to SIP dialogs using peer transport address. 2. A client that obtained a security-agreement with the server is responsible to select and initiate a security mechanism to use in further requests. The security-agreement negotiation process, however, does not necessarily indicate to the server what the client is about to choose (for example, if the server is the initiator of the negotiation). Possible Solution: The server will leave all resources open (for example, IPsec ports) waiting for the first protected request from the client. Once a request is received from the client, the server will conclude the choice made by the client and will release other resources. 3. The security-agreement process indicates to the client which security mechanism to use in its requests to the server. However, there are no explicit instructions for the server on how to send requests to the client. RFC3329 indicates the possibility to use the security that the client obtained for requests from the server, but it does not specify the correct behavior. Moreover, the server might want to send a request to the client before the client initiated the security mechanism (see 2). Possible solution: Once the client sends a protected request to the server via TLS or IPSec connection, the server will store this connection and use it in its requests to the client (connection reuse alike). Before that, any request from the server will be sent using regular address resolution. 4. RFC3329 does not discuss the possibility of several suggestions of the same security mechanism in one negotiation (for example, suggesting ipsec-3gpp with two different algorithms). draft-niemi-rfc3329-issues-00.txt states that future standardization will describe how it shell be done. Possible solution: In the mean time, till this issue is fixed; do not allow negotiating the same security mechanism twice. 5. RFC3329 requires security-agreement to be held upon 494 responses. 3GPP TS.33.203 however, allows the security-agreement to be held on other responses, specifically 401 responses that are generated by the second hop. Possible solution: Allow in RFC 3329 negotiating upon any 4xx response, i.e., can add Security-Sever list to 4xx responses on server side, and look for Security-Server list in 4xx responses on client side. 6. Another problem arouse from point 4, where the 401 response may contain Authentication info originating at a second hop, but (theoretically) may also contain Authentication info that is part of the security-agreement negotiation. It may not be possible to differ between the two. Possible solution: Consider authentication information as part of a security-agreement only if it arrived in a 494 response. I will be glad to know what you think of these issues... Thanks Sharon Laivand. -----Original Message----- From: Aki Niemi [mailto:aki.niemi@nokia.com] Sent: Tuesday, March 21, 2006 2:26 AM To: sip@ietf.org Subject: [Sip] Update to RFC3329, aka Security Agreement All, During the past couple of years, there have been a few reported issues on RFC 3329, based on implementation experience. I've gathered the set of issues in an I-D: http://www.ietf.org/internet-drafts/draft-niemi-rfc3329-issues-00.txt We've already talked about rfc3329bis among the authors, and we feel this would be appropriate in order to straighten out the issues and improve interop. Any comments are welcome. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 16 11:49:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G28pz-0003T9-4q; Sun, 16 Jul 2006 11:47:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G28px-0003T4-HF for sip@ietf.org; Sun, 16 Jul 2006 11:47:17 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G28pq-0004nh-93 for sip@ietf.org; Sun, 16 Jul 2006 11:47:17 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id B2C406C022; Sun, 16 Jul 2006 10:46:15 -0400 (EDT) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses From: Scott Lawrence To: Jeroen van Bemmel In-Reply-To: <001e01c6a827$38b8bda0$31713b51@BEMBUSTER> References: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com> <200607150329.k6F3Tkul032204@dragon.ariadne.com> <001e01c6a827$38b8bda0$31713b51@BEMBUSTER> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Sun, 16 Jul 2006 11:46:17 -0400 Message-Id: <1153064777.2917.85.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Sat, 2006-07-15 at 17:56 +0200, Jeroen van Bemmel wrote: > Dale, > > see inline > > Regards, > > jeroen > > > If it is looping/spiraling, then it will be having good compression > > ratio for 483. > > > > No, it won't, because most of the bytes in Via headers are in the > > branch parameters, which are all different, even when the message > > loops. > > > > I would say: prune those Via branch parameters. The only useful information > they possibly provide, is whether the element is RFC3261 compliant or not. > So take the first 7 chars of each via branch, and strip the rest. There are two reasons I don't like this approach: 1) The message/sipfrag definition does not allow header fields to be modified - just removed or included as is. 2) The branch parameters may well be useful to correlate information in log files (in fact, they may also have information coded into them that can be read by someone who knows how they are constructed). > Then compression will be better too, the only problem is that the sender > needs to support it (or at least be capable to log binary messages) None of which addresses the fact that you cannot easily predict how much of the message to include so that you get <201 bytes out of the compressor. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 16 11:53:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G28uE-0003sF-9p; Sun, 16 Jul 2006 11:51:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G28uD-0003sA-3V for sip@ietf.org; Sun, 16 Jul 2006 11:51:41 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G28u7-0005Nn-S1 for sip@ietf.org; Sun, 16 Jul 2006 11:51:41 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 75DFF6C026; Sun, 16 Jul 2006 10:50:41 -0400 (EDT) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses From: Scott Lawrence To: Dale.Worley@comcast.net In-Reply-To: <200607150329.k6F3Tkul032204@dragon.ariadne.com> References: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com> <200607150329.k6F3Tkul032204@dragon.ariadne.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Sun, 16 Jul 2006 11:50:43 -0400 Message-Id: <1153065043.2917.91.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Fri, 2006-07-14 at 23:29 -0400, Dale.Worley@comcast.net wrote: > From: "Samir Srivastava" > > If it is looping/spiraling, then it will be having good compression > ratio for 483. > > No, it won't, because most of the bytes in Via headers are in the > branch parameters, which are all different, even when the message > loops. > > Fortunately, a rather good job of pruning can be done by a simple > algorithm: Sort all the headers by a weighting that says how valuable > they are for diagnostics. The sort needs to be stable, in that all > headers of the same type have their order preserved. Then retain an > initial subset of the headers without going over the desired body > length. The more complicated the algorithm, the more chance of introducing errors that confuse rather than illuminate. I'd rather send back less but preserve all ordering than risk corrupting the information that does get back. Bad diagnostic information is worse than no diagnostic information. The key word is 'simple'. I will propose some additional text for the pruning section to recommend removing those headers that are identical to those in the returned response (call-id, cseq, etc). -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 16 12:07:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G298A-0007HP-5w; Sun, 16 Jul 2006 12:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2988-0007HK-MS for sip@ietf.org; Sun, 16 Jul 2006 12:06:04 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2984-0006dx-CY for sip@ietf.org; Sun, 16 Jul 2006 12:06:04 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id CCDCC6C036; Sun, 16 Jul 2006 11:05:05 -0400 (EDT) Subject: RE: [Sip] Size of message/sipfrag in diagnostic responses From: Scott Lawrence To: Hadriel Kaplan In-Reply-To: <00c901c6a779$f60ee310$17e8a8c0@acmepacket.com> References: <00c901c6a779$f60ee310$17e8a8c0@acmepacket.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Sun, 16 Jul 2006 12:05:07 -0400 Message-Id: <1153065907.2917.93.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: 'SIP WG List' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Fri, 2006-07-14 at 15:16 -0400, Hadriel Kaplan wrote: > > > -----Original Message----- > > From: Scott Lawrence [mailto:slawrence@pingtel.com] > > > > On Thu, 2006-07-13 at 16:14 -0500, Dean Willis wrote: > > > Also, this will still explode in environments where evil topology- > > > hiding functions (common in SBCs) have suppressed the Via header > > > fields. Some people would have me believe that this occurs in most if > > > not all IMS deployments, giving us a low probability that large > > > responses will ever actually work. > > > > People who deploy such things and don't keep them up to date when the > > protocol changes deserve what happens to them. I don't think that we > > need to maintain backward compatibility or otherwise protect the > > clueless from implementations that have chosen (for, I am sure, good > > and/or revenue-generating reasons) to violate MUST-level rules. > > Actually, I think his point was that such evil practices will impact _your_ > non-evil providers/UAs. And I take back what I said about it not being a > problem, because I see Dean's point now and can think of how it can be a > problem. The problem is if you're a good guy calling _through_ an evil > provider (unbeknownst to you) transiting to other good providers. > > If the loop is in the other good provider, and they implement this draft, > but the evil one doesn't strip the attachment, then the extra-large response > may not get back to you because of UDP issues. So you'll not get the final > response, and have a bad calling experience, and create issues for the good > provider as well. That's not good, for the good guys. While I know at > least some Via-hiding boxes can strip the attachment out, that doesn't mean > all of them will/can. > > So perhaps you should size-limit all responses. The odds of some hop or > other not being UDP isn't that good anyway today, and not many will want to > implement a draft which negatively impacts them for even a subset of cases. > Though I would like TCP-usage to get the benefit of TCP to promote its use > in the future, if you want rapid ubiquitous adoption of this draft mechanism > then you have to co-exist with such use cases, IMHO. I think that crippling a useful feature to allow for elements that blatantly violate the rules is going too far. In the scenario you describe, it will be pretty easy to detect that the problem occurs on the other size of the evilbox and that the evilbox has prevented the response from getting back, because if you do the progressive hop-limit trick it will show that you get responses from everywhere along the path until you get above the size limit. In any event, the proposed text says: If no request Via header value specifies UDP, then the server is free to either prune the returned message/sipfrag body as specified in section X or to return the full set of request headers. so if an implementation wishes to always prune to under 200, it is free to do so and avoid even this potential problem. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 16 12:11:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G29Bn-0000vR-KC; Sun, 16 Jul 2006 12:09:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G29Bm-0000vK-EL for sip@ietf.org; Sun, 16 Jul 2006 12:09:50 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G29Bk-0007Az-WA for sip@ietf.org; Sun, 16 Jul 2006 12:09:50 -0400 Received: (qmail 26284 invoked by uid 0); 16 Jul 2006 16:09:46 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 16 Jul 2006 16:09:46 -0000 Message-ID: <004901c6a8f2$3df387c0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Scott Lawrence" References: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com> <200607150329.k6F3Tkul032204@dragon.ariadne.com> <001e01c6a827$38b8bda0$31713b51@BEMBUSTER> <1153064777.2917.85.camel@localhost.localdomain> Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses Date: Sun, 16 Jul 2006 18:09:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Scott, >> see inline >> >> Regards, >> >> jeroen >> >> > If it is looping/spiraling, then it will be having good compression >> > ratio for 483. >> > >> > No, it won't, because most of the bytes in Via headers are in the >> > branch parameters, which are all different, even when the message >> > loops. >> > >> >> I would say: prune those Via branch parameters. The only useful >> information >> they possibly provide, is whether the element is RFC3261 compliant or >> not. >> So take the first 7 chars of each via branch, and strip the rest. > > There are two reasons I don't like this approach: > > 1) The message/sipfrag definition does not allow header fields to be > modified - just removed or included as is. > OK, so then perhaps either the message/sipfrag definition needs to be fixed as well, or message/sipfrag is not fit for the purpose we have here. "message/sipfrag-pruned" ? > 2) The branch parameters may well be useful to correlate information in > log files (in fact, they may also have information coded into them that > can be read by someone who knows how they are constructed). > Yes, all information may potentially be helpful. The problem is (as I'm sure you're aware of): "Somethin' 's gotta give". In my opinion, if the choice is between removing via's starting from the bottom (as the current draft suggests, such that the UA can detect that something is missing) or removing branch parameters until it fits, I'd rather have all via headers without branches. That for sure is something the UA can interpret, as opposed to a proprietary branch-encoded scheme which is much less likely to be understood. If desired, you could start with all vias including branches, and start pruning branch parameters first (so you'd still have some branch parameters left, preferrably at the bottom I would say) >> Then compression will be better too, the only problem is that the sender >> needs to support it (or at least be capable to log binary messages) > > None of which addresses the fact that you cannot easily predict how much > of the message to include so that you get <201 bytes out of the > compressor. Perhaps a streaming compressor like deflate (RFC1950) would then be better. I'm no expert, but I believe you could cut that off when you reach the maximum size? Regards, Jeroen > > -- > Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com > sipXpbx project coordinator - SIPfoundry > http://www.sipfoundry.org/sipX > Chief Architect - Pingtel Corp. http://www.pingtel.com/ > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 16 13:05:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2A1o-0004Eh-PO; Sun, 16 Jul 2006 13:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2A1m-0004Ec-SC for sip@ietf.org; Sun, 16 Jul 2006 13:03:35 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2A1h-0006Qt-JN for sip@ietf.org; Sun, 16 Jul 2006 13:03:34 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 02D8B6C027; Sun, 16 Jul 2006 12:02:34 -0400 (EDT) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses From: Scott Lawrence To: Jeroen van Bemmel In-Reply-To: <004901c6a8f2$3df387c0$31713b51@BEMBUSTER> References: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com> <200607150329.k6F3Tkul032204@dragon.ariadne.com> <001e01c6a827$38b8bda0$31713b51@BEMBUSTER> <1153064777.2917.85.camel@localhost.localdomain> <004901c6a8f2$3df387c0$31713b51@BEMBUSTER> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Sun, 16 Jul 2006 13:02:36 -0400 Message-Id: <1153069356.2917.110.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Sun, 2006-07-16 at 18:09 +0200, Jeroen van Bemmel wrote: > Hi Scott, > > >> see inline > >> > >> Regards, > >> > >> jeroen > >> > >> > If it is looping/spiraling, then it will be having good compression > >> > ratio for 483. > >> > > >> > No, it won't, because most of the bytes in Via headers are in the > >> > branch parameters, which are all different, even when the message > >> > loops. > >> > > >> > >> I would say: prune those Via branch parameters. The only useful > >> information > >> they possibly provide, is whether the element is RFC3261 compliant or > >> not. > >> So take the first 7 chars of each via branch, and strip the rest. > > > > There are two reasons I don't like this approach: > > > > 1) The message/sipfrag definition does not allow header fields to be > > modified - just removed or included as is. > > > > OK, so then perhaps either the message/sipfrag definition needs to be fixed > as well, or message/sipfrag is not fit for the purpose we have here. > "message/sipfrag-pruned" ? > > > 2) The branch parameters may well be useful to correlate information in > > log files (in fact, they may also have information coded into them that > > can be read by someone who knows how they are constructed). > > > > Yes, all information may potentially be helpful. The problem is (as I'm sure > you're aware of): "Somethin' 's gotta give". My choice would be UDP (only half :-) ) > In my opinion, if the choice is > between removing via's starting from the bottom (as the current draft > suggests, such that the UA can detect that something is missing) or removing > branch parameters until it fits, I'd rather have all via headers without > branches. On long paths, you won't have room for that in 200 bytes anyway. > That for sure is something the UA can interpret, as opposed to a > proprietary branch-encoded scheme which is much less likely to be > understood. I don't actually hope for UAs to interpret this - just human beings. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 17 04:58:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Ou3-00035H-Js; Mon, 17 Jul 2006 04:56:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Ou1-00035C-Sd for Sip@ietf.org; Mon, 17 Jul 2006 04:56:34 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Ou0-0008NQ-Ja for Sip@ietf.org; Mon, 17 Jul 2006 04:56:33 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6H8uU0m006013; Mon, 17 Jul 2006 03:56:31 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ95WRS>; Mon, 17 Jul 2006 09:56:30 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369DFAB@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: =?iso-8859-1?Q?=27Ant=F3nio_Manuel_Amaral=27?= , "'Sip@ietf.org'" Subject: RE: [Sip] S-CSCF expected behavior Date: Mon, 17 Jul 2006 09:56:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org To make this directly relevant to SIP, the IMS S-CSCF behaves exactly = as specified in RFC 3261. If it has a pending transaction, then section = 16.8 and section 16.9 of RFC 3261 apply.=20 The session timer (RFC 4028) may optionally be used by any of the IMS = entities that behave as a SIP proxy. regards Keith > -----Original Message----- > From: Ant=F3nio Manuel Amaral = [mailto:antonio-mn-amaral@ptinovacao.pt] > Sent: 14 July 2006 11:17 > To: Sip@ietf.org > Subject: [Sip] S-CSCF expected behavior >=20 >=20 >=20 > Dear All, >=20 > I don't know if this is the correct mailing list to put my=20 > question and if not my apologies for that. >=20 > Consider the following IMS scenario >=20 >=20 > (IMS core Network) -> S-CSCF -> AS >=20 >=20 > If the connection between AS and S-CSCF fails what is the=20 > expected behavior of S-CSCF? It must release all active calls=20 > sending BYE messages to caller and called clients in order to=20 > terminate the calls? >=20 > Thanks in advance >=20 > Regards >=20 > AA=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 17 07:13:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2R0K-0007W1-4W; Mon, 17 Jul 2006 07:11:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2R0I-0007Vu-Vc for sip@ietf.org; Mon, 17 Jul 2006 07:11:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Q8h-0007Aa-6j for sip@ietf.org; Mon, 17 Jul 2006 06:15:47 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G2Q1Y-0007G8-SF for sip@ietf.org; Mon, 17 Jul 2006 06:08:28 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6H98EJb000348; Mon, 17 Jul 2006 12:08:14 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 13:08:14 +0300 Received: from esdhcp034253.research.nokia.com ([172.21.34.253]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 Jul 2006 13:08:14 +0300 Subject: RE: [Sip] Update to RFC3329, aka Security Agreement From: Aki Niemi To: ext Sharon Laivand In-Reply-To: References: Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Mon, 17 Jul 2006 06:08:14 -0400 Message-Id: <1153130894.32143.45.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2006 10:08:14.0156 (UTC) FILETIME=[EA8048C0:01C6A988] X-Spam-Score: -2.6 (--) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On su, 2006-07-16 at 16:54 +0300, ext Sharon Laivand wrote: > Hi Aki and all... > > > This email follows my conversation with Gonzalo at last IETF 66th - > regarding RFC3329 issues. > > Here are some issues we thought of. I wonder if it can assist your > draft. Anyway I will be glad to constantly contribute to this draft. Thanks for your feedback. Some comments inline. > Here are the comments/additions to the issues: > > 1. > RFC3329 describes how the same security-agreement is used in several > transactions, but does not specify the relations between those > transactions. For example, a security-agreement can be obtained via > OPTIONS transaction and then used by a call-leg. Since there is no > SIP-wise relation between those two SIP entities, a key for comparison > must be defined. This is extremely problematic on server side, because > any incoming transaction must be verified according to the > security-agreement used in previous (unrelated and even nonexistent) > transactions. > One possible solution that is not good for all cases: match of > security-agreements to SIP dialogs using peer transport address. The primary reason this is underspecified is that back when RFC 3329 was in the works, we didn't have a clear architecture for this sort of thing. We do now, as outbound and SIP identity both rely on a UA having a "sentinel" of sorts in the network to whom it has a persistent security association and can send and receive traffic in a secure, identity-safe way. I would say the most common case is that this association is bootstrapped using a REGISTER, which was, in fact, the assumption of RFC 3329 as well. Perhaps not that clearly stated, though. > 2. > A client that obtained a security-agreement with the server is > responsible to select and initiate a security mechanism to use in > further requests. The security-agreement negotiation process, however, > does not necessarily indicate to the server what the client is about to > choose (for example, if the server is the initiator of the negotiation). > > Possible Solution: The server will leave all resources open (for > example, IPsec ports) waiting for the first protected request from the > client. Once a request is received from the client, the server will > conclude the choice made by the client and will release other resources. That is a possible solution, although I've since come to believe that choice in these sorts of situations is a bug and not a feature. This becomes especially hairy if there would be need to indicate preference accross different security mechanisms. Example: I am willing to do TLS, but only with the PSK cipher suites; otherwise, I want to do transport mode IPsec with IKE; but if it fails then perhaps TLS with RSA one-way. My suggestion in this case would be to *not* add TLS cipher suite identifiers to sec-agree, but e.g., to only ever do negotiation in the TLS handshake, effectively deprecating sec-agree... > 3. > The security-agreement process indicates to the client which security > mechanism to use in its requests to the server. However, there are no > explicit instructions for the server on how to send requests to the > client. RFC3329 indicates the possibility to use the security that the > client obtained for requests from the server, but it does not specify > the correct behavior. Moreover, the server might want to send a request > to the client before the client initiated the security mechanism (see > 2). > Possible solution: Once the client sends a protected request to the > server via TLS or IPSec connection, the server will store this > connection and use it in its requests to the client (connection reuse > alike). Before that, any request from the server will be sent using > regular address resolution. I agree. This is effectively what sip-outbound defines; the only missing thing is to clarify the security agreement procedure and say that before the setup of the secure channel is finished, the server would actually not send any requests to the UA. This would actually be a natural consequence of using a REGISTER to bootstrap the negotiation. > 4. > RFC3329 does not discuss the possibility of several suggestions of the > same security mechanism in one negotiation (for example, suggesting > ipsec-3gpp with two different algorithms). > draft-niemi-rfc3329-issues-00.txt states that future standardization > will describe how it shell be done. > Possible solution: In the mean time, till this issue is fixed; do not > allow negotiating the same security mechanism twice. I think RFC 3329 does allow several ipsec-3gpp mechanisms with different algorithms to be offered, even giving each one a different q-value for preference. Of course, in addition to not being well documented, as you add more supported algorithms, there is a combinatorial explosion resulting in more and more (redundant) ipsec-3gpp mechanisms offered. There's been a suggestion to change the 3GPP grammar to allow the hash and cipher algorithms be represented as a comma-separated list, which seems like a reasonable idea. > 5. > RFC3329 requires security-agreement to be held upon 494 responses. 3GPP > TS.33.203 however, allows the security-agreement to be held on other > responses, specifically 401 responses that are generated by the second > hop. > Possible solution: Allow in RFC 3329 negotiating upon any 4xx response, > i.e., can add Security-Sever list to 4xx responses on server side, and > look for Security-Server list in 4xx responses on client side. I'm not sure how to reconcile this in specification -- I *think* anyone actually implementing RFC 3329 is doing so to support the 3GPP TS. So in reality, this may not be such a big issue, but rather a place where 3GPP and/or we could clarify and document existing implementation practice. That said, allowing Security-Server to appear in a 401 would better accomodate using RFC 3329 with sip-outbound. > 6. > Another problem arouse from point 4, where the 401 response may contain > Authentication info originating at a second hop, but (theoretically) may > also contain Authentication info that is part of the security-agreement > negotiation. It may not be possible to differ between the two. > Possible solution: Consider authentication information as part of a > security-agreement only if it arrived in a 494 response. This is an interesting point. It might actually happen that a REGISTER/407 be challenged again with a 401 and a Security-Server. In which case the original (outbound) proxy would somehow need to be accomodated. I'm not sure how to address this... So let me ask a meta-question instead. ;-) How do we want to approach addressing these issues? The rfc3329-issues draft basically proposes three alternatives: 1) Document all of the found issues with suggestions of how to deal with them in an RFC errata entry. 2) Do #1 and fix the d-ver calculation as an update to RFC3329. 3) Revise RFC 3329. Personally, I'm inclined to go with #1, maybe #2, but definitely not #3. Reason being something I mentioned already above; I think keeping IPsec around as a potential way to secure SIP is not viable. I think TLS is a much better suited for securing SIP hops, and especially here, limiting the amount of choices makes interop better. Also, one of the key benefits of RFC 3329 is that it protects against bid-down; however, given most UAs in the wild today don't implement it pre-empts that benefit pretty well at this point. We sort of missed the boat on that one, unfortunately. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 17 11:22:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Uta-0001o1-7V; Mon, 17 Jul 2006 11:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2UtZ-0001nw-1g for Sip@ietf.org; Mon, 17 Jul 2006 11:20:29 -0400 Received: from web52809.mail.yahoo.com ([206.190.48.252]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G2UtW-0005QE-ND for Sip@ietf.org; Mon, 17 Jul 2006 11:20:29 -0400 Received: (qmail 75472 invoked by uid 60001); 17 Jul 2006 15:20:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LnxWpOqiYbnAiFozB5ahhlIebCz3HGCjjOi1Ezu9atFxGegSfV0lz9qJcubOZ7+Ez65j52a1q8O3UNtRR4ocMEKVQkkwJ8bh28+3VjoxfJ5ulajmEh82dQa+5T0Xw6ZQ5vBvDOwQ+Hvc+igYV2ZNeiTmbZtcTHrgvzZtR5rEz0g= ; Message-ID: <20060717152020.75405.qmail@web52809.mail.yahoo.com> Received: from [47.165.147.41] by web52809.mail.yahoo.com via HTTP; Mon, 17 Jul 2006 08:20:02 PDT Date: Mon, 17 Jul 2006 08:20:02 -0700 (PDT) From: Fatih "Eyüp" NAR Subject: RE: [Sip] S-CSCF expected behavior To: "Drage, Keith \(Keith\)" , "'António" Manuel Amaral' , "'Sip@ietf.org'" In-Reply-To: <475FF955A05DD411980D00508B6D5FB01369DFAB@en0033exch001u.uk.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org what about active sessions (INVITE transaction completed successfully with 200OK-ACK previously) on S-CSCF? ex: For the prepaid customer type once the connection dropped between AS and S-CSCF only way to prevent - "minus" credit is to end the session with BYE by S-. --- "Drage, Keith (Keith)" wrote: > To make this directly relevant to SIP, the IMS > S-CSCF behaves exactly as specified in RFC 3261. If > it has a pending transaction, then section 16.8 and > section 16.9 of RFC 3261 apply. > > The session timer (RFC 4028) may optionally be used > by any of the IMS entities that behave as a SIP > proxy. > > regards > > Keith > > > -----Original Message----- > > From: António Manuel Amaral > [mailto:antonio-mn-amaral@ptinovacao.pt] > > Sent: 14 July 2006 11:17 > > To: Sip@ietf.org > > Subject: [Sip] S-CSCF expected behavior > > > > > > > > Dear All, > > > > I don't know if this is the correct mailing list > to put my > > question and if not my apologies for that. > > > > Consider the following IMS scenario > > > > > > (IMS core Network) -> S-CSCF -> AS > > > > > > If the connection between AS and S-CSCF fails what > is the > > expected behavior of S-CSCF? It must release all > active calls > > sending BYE messages to caller and called clients > in order to > > terminate the calls? > > > > Thanks in advance > > > > Regards > > > > AA > > > > > > > > _______________________________________________ > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > Protocol > > Use sip-implementors@cs.columbia.edu for questions > on current sip > > Use sipping@ietf.org for new developments on the > application of sip > > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 17 12:53:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2WK5-0001xk-J2; Mon, 17 Jul 2006 12:51:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2WK3-0001wt-Kd for sip@ietf.org; Mon, 17 Jul 2006 12:51:55 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2WK1-0005vv-NT for sip@ietf.org; Mon, 17 Jul 2006 12:51:55 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0ECBC775; Mon, 17 Jul 2006 18:51:53 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 18:51:52 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 18:51:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Date: Mon, 17 Jul 2006 18:51:52 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1238@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: A coment to draft-ietf-sip-outbound-04 Thread-Index: AcakeCc9qMeQzYfmS+6SLoDgv2TI3AEno4rW References: <44AB9820.4050200@nokia.com><4E14323C-8338-4AF5-AF2A-4602ADB7F00D@cisco.com><44AC0861.1020604@nokia.com> <44AD56B7.9020905@cisco.com><44ADF80B.2000204@nokia.com><44B0E7B3.3060801@nokia.com><003801c6a354$5f9c0a80$31713b51@BEMBUSTER><5ff412ad9f184bb5d8e5f552b09b3ad0@ekabal.com><010601c6a455$42a96150$31713b51@BEMBUSTER><17586.43680.630973.131072@rautu.tutpro.com><7.0.1.0.0.20060710153817.0333c730@stevecrocker.com><20060710194750.4B521F0B16@rautu> <7.0.1.0.0.20060710192359.0333cde8@stevecrocker.com> From: "Christer Holmberg \(JO/LMF\)" To: "Joel M. Halpern" , "Juha Heinanen" X-OriginalArrivalTime: 17 Jul 2006 16:51:52.0562 (UTC) FILETIME=[4DCBC520:01C6A9C1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: Miguel Garcia , Rohan Mahy , sip@ietf.org, Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0968920364==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0968920364== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A9C1.4D94E049" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A9C1.4D94E049 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 If the UA chooses to only establish a single flow there is really = nothing the network can do about it, even if the network allows the UA = to establish multiple flows. =20 But, as we have discussed before, it would be useful if the network = could indicate the max number of flows it allows the UA to establish. = And, if thet network indicates max-flow=3D1 the UA can assume that the = network can provide reliability even with a single flow. =20 Regards, =20 Christer =20 ________________________________ From: Joel M. Halpern [mailto:joel@stevecrocker.com] Sent: Tue 11/07/2006 01:25 To: Juha Heinanen Cc: Miguel Garcia; Rohan Mahy; sip@ietf.org; Cullen Jennings Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04 By this interpretation, a network could not offer redundant / backup connectivity (via outbound) to UAs which want to take advantage of that without also mandating that all UAs make connect to all the = entities. Yours, Joel At 03:47 PM 7/10/2006, Juha Heinanen wrote: >Joel M. Halpern writes: > > > Nor is it "outbound"s job to mandate specific redundancy mechanisms > > (it currently seems to do so, although I think all of that is > > intended as examples.) > >outbound can support any number of redundancy mechanisms. if a domain >chooses to require two flows from a particular UA, then it is up to >outbound UA to do so. another domain may have different policy. as >long as outbound UA is able to setup at least two flows everything is >ok. > >-- juha > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C6A9C1.4D94E049 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04=0A= =0A= =0A=
=0A=
 
=0A=
Hi,
=0A=
 
=0A=
If the UA chooses to only = establish a =0A= single flow there is really nothing the network can do about it, = even if =0A= the network allows the UA to establish multiple flows.
=0A=
 
=0A=
But, as we have discussed = before, it would =0A= be useful if the network could indicate the max number of flows it = allows the UA =0A= to establish. And, if thet network indicates max-flow=3D1 the UA can = assume that =0A= the network can provide reliability even with a single flow.
=0A=
 
=0A=
Regards,
=0A=
 
=0A=
Christer
=0A=
 
=0A=

=0A=
=0A= From: Joel M. Halpern =0A= [mailto:joel@stevecrocker.com]
Sent: Tue 11/07/2006 =0A= 01:25
To: Juha Heinanen
Cc: Miguel Garcia; Rohan = Mahy; =0A= sip@ietf.org; Cullen Jennings
Subject: Re: [Sip] Re: A coment = to =0A= draft-ietf-sip-outbound-04

=0A=
=0A=

By this interpretation, a network could not offer = redundant / =0A= backup
connectivity (via outbound) to UAs which want to take = advantage =0A= of
that without also mandating that all UAs make connect  to all = the =0A= entities.
Yours,
Joel

At 03:47 PM 7/10/2006, Juha Heinanen =0A= wrote:
>Joel M. Halpern writes:
>
>  > Nor is = it =0A= "outbound"s job to mandate specific redundancy mechanisms
>  = > (it =0A= currently seems to do so, although I think all of that is
>  = > =0A= intended as examples.)
>
>outbound can support any number of =0A= redundancy mechanisms.  if a domain
>chooses to require two = flows =0A= from a particular UA, then it is up to
>outbound UA to do = so.  =0A= another domain may have different policy.  as
>long as = outbound UA is =0A= able to setup at least two flows everything = is
>ok.
>
>-- =0A= juha
>
>_______________________________________________
&g= t;Sip =0A= mailing list  https://www1.ietf.org= /mailman/listinfo/sip
>This =0A= list is for NEW development of the core SIP Protocol
>Use =0A= sip-implementors@cs.columbia.edu for questions on current sip
>Use =0A= sipping@ietf.org for new developments on the application of =0A= sip


_______________________________________________
Sip = mailing =0A= list  https://www1.ietf.org= /mailman/listinfo/sip
This =0A= list is for NEW development of the core SIP Protocol
Use =0A= sip-implementors@cs.columbia.edu for questions on current sip
Use =0A= sipping@ietf.org for new developments on the application of =0A= sip

=0A= =0A= =0A= ------_=_NextPart_001_01C6A9C1.4D94E049-- --===============0968920364== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0968920364==-- From sip-bounces@ietf.org Mon Jul 17 16:57:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2a7s-0006xl-U7; Mon, 17 Jul 2006 16:55:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2a7p-0006u2-R8; Mon, 17 Jul 2006 16:55:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Zcp-00063H-6G; Mon, 17 Jul 2006 16:23:31 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G2ZUj-0007Y2-4G; Mon, 17 Jul 2006 16:15:11 -0400 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k6HK7vnw054765 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 17 Jul 2006 15:07:58 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Mon, 17 Jul 2006 15:07:56 -0500 To: IETF SIP List , sipping , simple@ietf.org, sip-implementors@cs.columbia.edu X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: -1.5 (-) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Sip] Registration for SIPit 19 is open X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: RjS@sipit.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Registration for SIPit 19. This SIPit will take place at the University of New Hampshire InterOperability Laboratory October 16-20. Space is limited to 120 participants, so register early. Registration will close September 29. For more information, and to register, see http://www.sipit.net RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 17 19:38:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ceF-0002Do-7f; Mon, 17 Jul 2006 19:37:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ceD-0002Dj-S6 for sip@ietf.org; Mon, 17 Jul 2006 19:37:09 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2ceC-0005uv-Jo for sip@ietf.org; Mon, 17 Jul 2006 19:37:09 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20060717233707m1300d9a6le>; Mon, 17 Jul 2006 23:37:07 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k6HNb6N1006795 for ; Mon, 17 Jul 2006 19:37:06 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k6HNb6Cs006791; Mon, 17 Jul 2006 19:37:06 -0400 Date: Mon, 17 Jul 2006 19:37:06 -0400 Message-Id: <200607172337.k6HNb6Cs006791@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <001e01c6a827$38b8bda0$31713b51@BEMBUSTER> (jbemmel@zonnet.nl) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses References: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com> <200607150329.k6F3Tkul032204@dragon.ariadne.com> <001e01c6a827$38b8bda0$31713b51@BEMBUSTER> X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Jeroen van Bemmel" I would say: prune those Via branch parameters. The only useful information they possibly provide, is whether the element is RFC3261 compliant or not. So take the first 7 chars of each via branch, and strip the rest. Then compression will be better too, the only problem is that the sender needs to support it (or at least be capable to log binary messages) This idea has advantages. But it branches into the territory of revising the definition of message/sipfrag, and possibly dinking with parsers for it. As for compression, in theory one could add a Content-Encoding header -- but again, that's burdening implementations. Most compression algorithms are stream-oriented, and one could order the headers according to importance, then start compressing, and chop the output at 200 bytes. But again, you'd force implementations to have a gzip decompresser that returns "the output so far" rather than just an error indication. IMHO, the primary design goal is to make it *easy* to deploy this mechanism widely. After it has proven its worth, and attracted significant commitment from implementors -- and we've discovered what the problems with it are *in practice* -- then redesign for better performance. "First make it work. Then make it fast." You'd perhaps also want any Contact header (though the UAC might reconstruct that). It could contain callee capabilities that explain why the request was routed in a particular way. Presumably the Contact header in the failed request has the same value as was put there when the UAC sent the request. The response should contain a Contact, of course, but that's not what we're talking about. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 17 19:52:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2cqw-0003Er-OI; Mon, 17 Jul 2006 19:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2cqw-0003El-3C for sip@ietf.org; Mon, 17 Jul 2006 19:50:18 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2cqu-0002Ij-Kl for sip@ietf.org; Mon, 17 Jul 2006 19:50:18 -0400 Received: (qmail 22790 invoked by uid 0); 17 Jul 2006 23:50:14 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 17 Jul 2006 23:50:14 -0000 Message-ID: <008101c6a9fb$bfdd88d0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com><200607150329.k6F3Tkul032204@dragon.ariadne.com><001e01c6a827$38b8bda0$31713b51@BEMBUSTER> <200607172337.k6HNb6Cs006791@dragon.ariadne.com> Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses Date: Tue, 18 Jul 2006 01:49:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Simplest and fastest is probably: for UDP, return the warning and as much as will fit in ( 200 + Content-Length ) bytes To get more diagnostics, send the request again using TCP (similar to authentication challenge but different transport) Trade-off is that there is no guarantee that the same thing will happen (but likely). Of course you can still add things like "if sender supports deflate, it is recommended to use that" Regards, jeroen ----- Original Message ----- From: To: Sent: Tuesday, July 18, 2006 1:37 AM Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses > From: "Jeroen van Bemmel" > > I would say: prune those Via branch parameters. The only useful > information > they possibly provide, is whether the element is RFC3261 compliant or > not. > So take the first 7 chars of each via branch, and strip the rest. > > Then compression will be better too, the only problem is that the sender > needs to support it (or at least be capable to log binary messages) > > This idea has advantages. But it branches into the territory of > revising the definition of message/sipfrag, and possibly dinking with > parsers for it. > > As for compression, in theory one could add a Content-Encoding header > -- but again, that's burdening implementations. Most compression > algorithms are stream-oriented, and one could order the headers > according to importance, then start compressing, and chop the output > at 200 bytes. But again, you'd force implementations to have a gzip > decompresser that returns "the output so far" rather than just an > error indication. > > IMHO, the primary design goal is to make it *easy* to deploy this > mechanism widely. After it has proven its worth, and attracted > significant commitment from implementors -- and we've discovered what > the problems with it are *in practice* -- then redesign for better > performance. > > "First make it work. Then make it fast." > > You'd perhaps also want any Contact header (though the UAC might > reconstruct > that). It could contain callee capabilities that explain why the request > was > routed in a particular way. > > Presumably the Contact header in the failed request has the same value > as was put there when the UAC sent the request. The response should > contain a Contact, of course, but that's not what we're talking about. > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 17 21:01:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2dvz-0004xz-S7; Mon, 17 Jul 2006 20:59:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2dvy-0004tA-1a for sip@ietf.org; Mon, 17 Jul 2006 20:59:34 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2dvw-0006qE-QU for sip@ietf.org; Mon, 17 Jul 2006 20:59:34 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20060718005931m1400i9gbee>; Tue, 18 Jul 2006 00:59:31 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k6I0xUN1008767 for ; Mon, 17 Jul 2006 20:59:30 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k6I0xUbr008763; Mon, 17 Jul 2006 20:59:30 -0400 Date: Mon, 17 Jul 2006 20:59:30 -0400 Message-Id: <200607180059.k6I0xUbr008763@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <008101c6a9fb$bfdd88d0$31713b51@BEMBUSTER> (jbemmel@zonnet.nl) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses References: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com><200607150329.k6F3Tkul032204@dragon.ariadne.com><001e01c6a827$38b8bda0$31713b51@BEMBUSTER> <200607172337.k6HNb6Cs006791@dragon.ariadne.com> <008101c6a9fb$bfdd88d0$31713b51@BEMBUSTER> X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Jeroen van Bemmel" Of course you can still add things like "if sender supports deflate, it is recommended to use that" Ah, yes. And conveniently, there is an "Accept-Encoding" header for the UAC to indicate just that. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 08:55:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2p5A-0003BJ-C1; Tue, 18 Jul 2006 08:53:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2p58-0003An-FX; Tue, 18 Jul 2006 08:53:46 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2p57-0007hT-8d; Tue, 18 Jul 2006 08:53:46 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G2p51-0001n1-Vr; Tue, 18 Jul 2006 07:53:40 -0500 From: "Brian Rosen" To: Date: Tue, 18 Jul 2006 08:53:40 -0400 Message-ID: <0aca01c6aa69$33aecea0$bc1cdb84@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcanccRW/NWGkyQmT2aWMgniADQTiAC9qaOQ X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: geopriv@ietf.org Subject: [Sip] SIP Location Conveyance: dereferencing location-by-reference X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In sip-location-conveyance, we allow a URI in the Location header to provide for location-by-reference. We must have some kind of text that says what the recipient does with this URI. Our proposal is to change the ABNF, which currently allows this URI to be AbsoluteURI (meaning any scheme) and replace it with HTTP/HTTPS only. Of course, there would still be the cid: for message body identification. We would then define a dereference process as doing an HTTP/HTTPS GET, with no parameters, on the URI, and expect to receive in return a PIDF-LO, exactly as it would appear in a body. The text would state MUST implement TLS, except for the emergency case. The text would further state that additional dereferencing procedures could be defined by a standards track RFC. Brian and James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 08:58:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2p87-0006lr-Mf; Tue, 18 Jul 2006 08:56:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2p86-0006kr-66; Tue, 18 Jul 2006 08:56:50 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2p84-000894-Vd; Tue, 18 Jul 2006 08:56:50 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G2p7z-0001yT-BR; Tue, 18 Jul 2006 07:56:44 -0500 From: "Brian Rosen" To: Date: Tue, 18 Jul 2006 08:56:44 -0400 Message-ID: <0acb01c6aa69$a1365ba0$bc1cdb84@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcancuzY1NeercHcSZCJ+O+ZQ5cIsgC9kjcg X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: geopriv@ietf.org Subject: [Sip] Reason Header with 424 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It has been pointed out that the new 424 Bad Location Information error code defined in location-conveyance does not provide sufficient information for the recipient to know what was wrong with the location that prompted the error. We propose to resolve this by allowing a Reason header in the 424(Bad Location Information) response. We note that RFC3326 Which defines the Reason header states that it normally isn't used in a response, but a standards track RFC could allow this functionality. We propose that this document do so. Our expectation would be that geopriv would process an RFC that establishes a sub-registry for the Reason codes. We'll write a draft on this to get the ball started if this seems like a reasonable approach. We would not make location-conveyance normatively dependent on the subregistry. Brian and James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 09:01:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pAb-0002pE-Cq; Tue, 18 Jul 2006 08:59:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pAZ-0002VM-CG; Tue, 18 Jul 2006 08:59:23 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2pAY-0008FT-2m; Tue, 18 Jul 2006 08:59:23 -0400 Received: from [192.168.0.41] (pool-138-89-20-244.mad.east.verizon.net [138.89.20.244]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6ICxKfB024016 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 18 Jul 2006 08:59:21 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <243008CB-DE70-49D2-8EAF-BA74A91B68CF@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Tue, 18 Jul 2006 08:59:13 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, James: this is simply false. If desired, XML-DSIG is a well-known and accepted mechanism to achieve integrity. Such specification is no longer than the MUST NOT that you propose. You are also willfully ignoring the other technical arguments made as part of this discussion. Henning On Jul 18, 2006, at 8:48 AM, Rosen, Brian wrote: > There was a desire expressed by Hannes to provide a way for a proxy to > insert location-by-value. He had proposed a SIP Location header > specific way. In IETF66, Henning suggested just using a data URI. > > Doing this may run afoul of the geopriv location privacy concerns, > because there is no way for the user to sign the header to provide > assurance that the PIDF, and specifically the retention and other > policy > bits are preserved. Note that S/MIME provides sufficient integrity > protection for a body. It's probably okay to use TLS per hop to > provide > privacy, but not integrity protection. The authors believe that there > is no really compelling use case for this feature, and the effort to > define acceptable security mechanisms for location data in a header > would be a significant effort, further delaying the draft. > > We propose, therefore, to state in sip-location-conveyance, that a > Data > URI MUST NOT be used in the Location header until a standards track > RFC > defines a suitable security mechanism to protect the PIDF in the > header. > > Brian and James > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 09:20:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pT6-0006nL-64; Tue, 18 Jul 2006 09:18:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pT5-0006mv-6y for sip@ietf.org; Tue, 18 Jul 2006 09:18:31 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G2pT3-0000YP-O2 for sip@ietf.org; Tue, 18 Jul 2006 09:18:31 -0400 Received: (qmail invoked by alias); 18 Jul 2006 13:18:28 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp033) with SMTP; 18 Jul 2006 15:18:28 +0200 X-Authenticated: #29516787 Message-ID: <44BCDFA2.7010104@gmx.net> Date: Tue, 18 Jul 2006 15:18:26 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header References: <243008CB-DE70-49D2-8EAF-BA74A91B68CF@cs.columbia.edu> In-Reply-To: <243008CB-DE70-49D2-8EAF-BA74A91B68CF@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sip@ietf.org, "Rosen, Brian" , geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have to agree with Henning here. You can sign the PIDF-LO, encode it and then put it into the data URI. Even if you do not sign the PIDF-LO in the header it makes no difference since that's what you accomplish by sending a location reference (in the header) as well. The argument that you can use authorization policies to decide who is allowed to resolve the reference to the location object is a bit misleading. Where do these policies come from? Ciao Hannes Henning Schulzrinne wrote: > Brian, James: > > this is simply false. If desired, XML-DSIG is a well-known and accepted > mechanism to achieve integrity. Such specification is no longer than > the MUST NOT that you propose. You are also willfully ignoring the > other technical arguments made as part of this discussion. > > Henning > > On Jul 18, 2006, at 8:48 AM, Rosen, Brian wrote: > >> There was a desire expressed by Hannes to provide a way for a proxy to >> insert location-by-value. He had proposed a SIP Location header >> specific way. In IETF66, Henning suggested just using a data URI. >> >> Doing this may run afoul of the geopriv location privacy concerns, >> because there is no way for the user to sign the header to provide >> assurance that the PIDF, and specifically the retention and other policy >> bits are preserved. Note that S/MIME provides sufficient integrity >> protection for a body. It's probably okay to use TLS per hop to provide >> privacy, but not integrity protection. The authors believe that there >> is no really compelling use case for this feature, and the effort to >> define acceptable security mechanisms for location data in a header >> would be a significant effort, further delaying the draft. >> >> We propose, therefore, to state in sip-location-conveyance, that a Data >> URI MUST NOT be used in the Location header until a standards track RFC >> defines a suitable security mechanism to protect the PIDF in the header. >> >> Brian and James >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 09:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pae-0007zs-DP; Tue, 18 Jul 2006 09:26:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pac-0007yq-F7 for sip@ietf.org; Tue, 18 Jul 2006 09:26:18 -0400 Received: from [65.220.123.2] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2paV-0000rX-JU for sip@ietf.org; Tue, 18 Jul 2006 09:26:18 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id D9A526C020; Tue, 18 Jul 2006 08:25:14 -0400 (EDT) Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses From: Scott Lawrence To: Dale.Worley@comcast.net In-Reply-To: <200607180059.k6I0xUbr008763@dragon.ariadne.com> References: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2B5@zrc2hxm2.corp.nortel.com> <200607150329.k6F3Tkul032204@dragon.ariadne.com> <001e01c6a827$38b8bda0$31713b51@BEMBUSTER> <200607172337.k6HNb6Cs006791@dragon.ariadne.com> <008101c6a9fb$bfdd88d0$31713b51@BEMBUSTER> <200607180059.k6I0xUbr008763@dragon.ariadne.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Tue, 18 Jul 2006 09:25:16 -0400 Message-Id: <1153229116.2885.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mon, 2006-07-17 at 20:59 -0400, Dale.Worley@comcast.net wrote: > From: "Jeroen van Bemmel" > > Of course you can still add things like "if sender supports > deflate, it is recommended to use that" > > Ah, yes. And conveniently, there is an "Accept-Encoding" header for > the UAC to indicate just that. But since that applies generically to any response, I don't think there is any need to call it out specifically here. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 09:40:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pmW-000084-IP; Tue, 18 Jul 2006 09:38:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pmV-00007k-CC; Tue, 18 Jul 2006 09:38:35 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2pmV-0001K7-2J; Tue, 18 Jul 2006 09:38:35 -0400 Received: from [192.168.0.41] (pool-138-89-20-244.mad.east.verizon.net [138.89.20.244]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6IDcMfB028580 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 18 Jul 2006 09:38:22 -0400 (EDT) In-Reply-To: <44BCDFA2.7010104@gmx.net> References: <243008CB-DE70-49D2-8EAF-BA74A91B68CF@cs.columbia.edu> <44BCDFA2.7010104@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25FF45DA-99A6-4ABD-8952-1BAA1E9FB403@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header Date: Tue, 18 Jul 2006 09:38:15 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: sip@ietf.org, "Rosen, Brian" , geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I find this discussion somewhat strange, given that draft-ietf-sip- location-conveyance-03 expends significant wording to detail all the cases where security (of any kind) is *not* to be used. To pick just one UAC-9 A UAC MUST be capable of transmitting a SIP request without protecting the PIDF-LO message body. It is RECOMMENDED this not be the default configuration of any UA. This requirement is orthogonal to the use of TLS or IPSec hop-by-hop between SIP elements. I probably missed it, but I didn't see a 'MUST use S/MIME' or 'MUST use TLS or S/MIME for by-reference' in the document. Indeed, another message regarding this draft explicitly allowed HTTP as a retrieval mechanism, with no mention of HTTPS, S/MIME or other security wrapper. The closest I see is SIP endpoints SHOULD implement S/MIME to encrypt the PIDF-LO message body (part) end-to-end. It then continues The SIPS-URI from [RFC3261] MUST be implemented for message protection (message integrity and confidentiality) and SHOULD be used when S/MIME is not used. Once SIPS is used, there is no technical difference between by-value (without XML-DSIG), by-attachment and by-reference that I can find. The draft leaves unexplained such details as to what key or even which crypto mechanisms the UAs should use to give proxies a chance to get at the data. It is also rather vague on whether "protecting" (in req. UAC-9) means encryption or integrity. Thus, we should at least be consistent: If we don't want unsigned and/ or unencrypted location information, ever, the draft should state that. We can then discuss which mechanisms are appropriate in each of the delivery mechanisms (attachment, by value, by reference) and how we can get intermediaries access to this information. Just waving the S/MIME flag is no more useful than pulling out the "just do IPsec" security section template. In summary: All three delivery mechanisms allow exactly equivalent security properties; the current draft does not mandate the use of such mechanisms for the two it specifies. Henning On Jul 18, 2006, at 9:18 AM, Hannes Tschofenig wrote: > I have to agree with Henning here. > > You can sign the PIDF-LO, encode it and then put it into the data URI. > > Even if you do not sign the PIDF-LO in the header it makes no > difference since that's what you accomplish by sending a location > reference (in the header) as well. > > The argument that you can use authorization policies to decide who > is allowed to resolve the reference to the location object is a bit > misleading. Where do these policies come from? > > Ciao > Hannes > > Henning Schulzrinne wrote: >> Brian, James: >> this is simply false. If desired, XML-DSIG is a well-known and >> accepted mechanism to achieve integrity. Such specification is no >> longer than the MUST NOT that you propose. You are also willfully >> ignoring the other technical arguments made as part of this >> discussion. >> Henning >> On Jul 18, 2006, at 8:48 AM, Rosen, Brian wrote: >>> There was a desire expressed by Hannes to provide a way for a >>> proxy to >>> insert location-by-value. He had proposed a SIP Location header >>> specific way. In IETF66, Henning suggested just using a data URI. >>> >>> Doing this may run afoul of the geopriv location privacy concerns, >>> because there is no way for the user to sign the header to provide >>> assurance that the PIDF, and specifically the retention and >>> other policy >>> bits are preserved. Note that S/MIME provides sufficient integrity >>> protection for a body. It's probably okay to use TLS per hop to >>> provide >>> privacy, but not integrity protection. The authors believe that >>> there >>> is no really compelling use case for this feature, and the effort to >>> define acceptable security mechanisms for location data in a header >>> would be a significant effort, further delaying the draft. >>> >>> We propose, therefore, to state in sip-location-conveyance, that >>> a Data >>> URI MUST NOT be used in the Location header until a standards >>> track RFC >>> defines a suitable security mechanism to protect the PIDF in the >>> header. >>> >>> Brian and James >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www1.ietf.org/mailman/listinfo/geopriv >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 09:59:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2q4c-0000Xk-W0; Tue, 18 Jul 2006 09:57:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2q4b-0000Wi-Em; Tue, 18 Jul 2006 09:57:17 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2q4Z-00027U-5z; Tue, 18 Jul 2006 09:57:17 -0400 Received: from [192.168.0.41] (pool-138-89-20-244.mad.east.verizon.net [138.89.20.244]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6IDvEfB000070 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 18 Jul 2006 09:57:14 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B6E5F53-EC65-46D6-AF84-7940CE567FFB@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Tue, 18 Jul 2006 09:57:07 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, a four-step process: - take any PIDF-LO - wrap in XML-DSIG as specified by the relevant W3C recommendation - convert to base-64 - make into a data URL, as in the example I gave in an earlier message data:application/pidf+xml;base64, Or did I miss the point of your question? See http://en.wikipedia.org/wiki/Data:_URL for additional data URL examples, btw. Henning On Jul 18, 2006, at 9:06 AM, Rosen, Brian wrote: > Perhaps some enlightenment is in order. It's not clear to me how you > dsig a Data uri in a Location header (or maybe you mean dsig the > pidf-lo > and put both the pidf-lo and the signature in the Data URI) somehow? > Are there some examples of this kind of thing elsewhere? > > If we are ignoring technical arguments (as opposed to use cases), it's > out of forgetfulness, and not willfulness. What were you referring > to? > > Brian > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 10:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qTa-0005bg-OE; Tue, 18 Jul 2006 10:23:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qTY-0005ah-Sy; Tue, 18 Jul 2006 10:23:04 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2qTW-000322-BB; Tue, 18 Jul 2006 10:23:04 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k6IEN15W007961; Tue, 18 Jul 2006 16:23:01 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k6IEN1bG002572; Tue, 18 Jul 2006 16:23:01 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 16:23:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jul 2006 16:22:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Location Conveyance: Scenarios thread-index: Acaqdajsevs2OAARSZe6JQwQSoN4fQ== From: "Tschofenig, Hannes" To: , X-OriginalArrivalTime: 18 Jul 2006 14:23:01.0026 (UTC) FILETIME=[AC994820:01C6AA75] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: Subject: [Sip] Location Conveyance: Scenarios X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all,=20 I have compiled a few message flows that would make it easier to discuss the different scenarios. I have listed some challenges along with each of the scenarios.=20 1) Location by End Host / Per Value/ in Body UA Alice SIP Proxy UAS-A UAS-B UAS-C | SIP Message | | | | |---------------------------->| | | | | Location (value/body) | | | |----------------->| | | | | SIP Message | |<-----------------------------------------------| | | Problems:=20 * Likelyhood of the UA using S/MIME; nice on paper but does it reflect reality? * UA Alice needs to know that (a) intermediaries do not need to process the PIDF-LO=20 (b) recipient has a certificate * Unclear what happens if there are multiple recipients.=20 2) Location by End Host / Per Reference / in Body UA Alice SIP Proxy UAS-A UAS-B UAS-C | SIP Message | | | | |---------------------------->| | | | | Location (ref./body) | | | |----------------->| | | | | Dereference | = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | SIP Message | |<-----------------------------------------------| | | Problems:=20 * Can be protected using S/MIME (see issue above) * If not protected then the considerations of who is allowed to dereference to a PIDF-LO are applicable. There is certainly a difference between a reference pointing to a PIDF-LO at the UA itself and a reference obtained using one of the discussed Geopriv L7 protocols.=20 It might be difficult for the end host to make the PIDF-LO available. It might be difficult for him to have a server-side certificate but it might be easier to control access to it.=20 3) Location by SIP Proxy / Per Reference / in Header UA Alice SIP Proxy UAS-A UAS-B UAS-C | SIP Message | | | | |---------------------------->| | | | | | SIP Message | | |----------------->| | | Location | | | (ref./header) | | | | | | | | | Dereference | | = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | SIP Message | |<-----------------------------------------------| | | | | | | Problems: * What should the SIP proxy but into the PIDF-LO when it is created (policies, identifiers, etc.)? * Authorization aspects: see above (Why cannot just everyone that sees the reference in the header passing by dereference it?) * Signing of the reference theoretically possible. SIP Proxy, however, needs to know the intended recipient.=20 4) Location by SIP Proxy / Per Value / in Header UA Alice SIP Proxy UAS-A UAS-B UAS-C | SIP Message | | | | |---------------------------->| | | | | | SIP Message | | |----------------->| | | Location | | | (value/header) | | | | | SIP Message | |<-----------------------------------------------| | | | | | | Problems: * What should the SIP proxy but into the PIDF-LO when it is created (policies, identifiers, etc.)? * Data URI approach possible but with increased message size.=20 * Signing of the PIDF-LO possible but approach similar. SIP Proxy, however, needs to know the intended recipient. 5) Location by SBC / Per Value / in Body UA Alice SIP Proxy UAS-A UAS-B UAS-C (SBC) | SIP Message | | | | |---------------------------->| | | | | Location (value/body) | SIP Message | | |----------------->| | | Location | | | (value/body) | | | | | SIP Message | |<-----------------------------------------------| | | | | | | Problems: * If there is no solution for the cases available where the SIP proxy can add a PIDF-LO and a reference is not acceptable (because of the latency) it is likely that boxes will just do it.=20 * Does not play "nicely" with SIP.=20 * Problems with E2E security =20 6) Location by End Host / Per Referene / in Header UA Alice SIP Proxy UAS-A UAS-B UAS-C | SIP Message | | | | |---------------------------->| | | | | Location (ref./header) | | | |----------------->| | | | | Dereference | = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | SIP Message | |<-----------------------------------------------| | | Problems: * Not sure about S/MIME usage * Simlar considerations as in (2) Finally, I think it would be useful to differentiate between location based services in general and emergency services since the requirements are, in most cases, different.=20 Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 10:59:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2r17-0003Ag-QZ; Tue, 18 Jul 2006 10:57:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2r15-00038H-Oc; Tue, 18 Jul 2006 10:57:43 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2r15-00055N-EC; Tue, 18 Jul 2006 10:57:43 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6IEvWfB004337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Jul 2006 10:57:32 -0400 (EDT) Message-ID: <44BCF6D8.5010900@cs.columbia.edu> Date: Tue, 18 Jul 2006 10:57:28 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Tschofenig, Hannes" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: geopriv@ietf.org, sip@ietf.org Subject: [Sip] Re: [Geopriv] Location Conveyance: Scenarios X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks, Hannes; these are helpful to focus the discussion. I think, however, that the issue of security (encryption or integrity) and conveyance are essentially orthogonal. In other words, you can apply the same techniques, with similar problems, in all three conveyance mechanisms (by-value, by-attachment, by-reference). The procedural details differ (such as XML-DSIG and XML encryption vs. S/MIME vs. TLS), but the strength and the certificate problems are similar, albeit not identical. (For example, it is probably somewhat harder to deal with multi-recipient cases in S/MIME than in other mechanisms.) It might help streamline the discussion if we can agree on this general statement or show that it is mistaken. Henning Tschofenig, Hannes wrote: > Hi all, > > I have compiled a few message flows that would make it easier to discuss > the different scenarios. I have listed some challenges along with each > of the scenarios. > > > 1) Location by End Host / Per Value/ in Body > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > > | SIP Message | | | | > |---------------------------->| | | | > | Location (value/body) | | > | |----------------->| > | | | > | SIP Message | > |<-----------------------------------------------| > | | > > Problems: > * Likelyhood of the UA using S/MIME; nice on paper but does it reflect > reality? > * UA Alice needs to know that (a) intermediaries do not need to process > the PIDF-LO > (b) recipient has a certificate > * Unclear what happens if there are multiple recipients. > > > > 2) Location by End Host / Per Reference / in Body > > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > > | SIP Message | | | | > |---------------------------->| | | | > | Location (ref./body) | | > | |----------------->| > | | | > | Dereference | > |<==============================================>| > | | > | | > | SIP Message | > |<-----------------------------------------------| > | | > > Problems: > * Can be protected using S/MIME (see issue above) > * If not protected then the considerations of who is allowed to > dereference to a PIDF-LO are applicable. There is certainly a difference > between a reference pointing to a PIDF-LO at the UA itself and a > reference obtained using one of the discussed Geopriv L7 protocols. > It might be difficult for the end host to make the PIDF-LO available. It > might be difficult for him to have a server-side certificate but it > might be easier to control access to it. > > > 3) Location by SIP Proxy / Per Reference / in Header > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > > | SIP Message | | | | > |---------------------------->| | | | > | | SIP Message | > | |----------------->| > | | Location | > | | (ref./header) | > | | | > | | | > | | Dereference | > | |<================>| > | | | > | SIP Message | > |<-----------------------------------------------| > | | > | | > | | > > Problems: > > * What should the SIP proxy but into the PIDF-LO when it is created > (policies, identifiers, etc.)? > * Authorization aspects: see above (Why cannot just everyone that sees > the reference in the header passing by dereference it?) > * Signing of the reference theoretically possible. SIP Proxy, however, > needs to know the intended recipient. > > > 4) Location by SIP Proxy / Per Value / in Header > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > > | SIP Message | | | | > |---------------------------->| | | | > | | SIP Message | > | |----------------->| > | | Location | > | | (value/header) | > | | | > | SIP Message | > |<-----------------------------------------------| > | | > | | > | | > > Problems: > > * What should the SIP proxy but into the PIDF-LO when it is created > (policies, identifiers, etc.)? > * Data URI approach possible but with increased message size. > * Signing of the PIDF-LO possible but approach similar. SIP Proxy, > however, needs to know the intended recipient. > > > 5) Location by SBC / Per Value / in Body > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > (SBC) > | SIP Message | | | | > |---------------------------->| | | | > | Location (value/body) | SIP Message | > | |----------------->| > | | Location | > | | (value/body) | > | | | > | SIP Message | > |<-----------------------------------------------| > | | > | | > | | > > Problems: > > * If there is no solution for the cases available where the SIP proxy > can add a PIDF-LO and a reference is not acceptable (because of the > latency) it is likely that boxes will just do it. > * Does not play "nicely" with SIP. > * Problems with E2E security > > > 6) Location by End Host / Per Referene / in Header > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > > | SIP Message | | | | > |---------------------------->| | | | > | Location (ref./header) | | > | |----------------->| > | | | > | Dereference | > |<==============================================>| > | | > | | > | SIP Message | > |<-----------------------------------------------| > | | > > Problems: > > * Not sure about S/MIME usage > * Simlar considerations as in (2) > > Finally, I think it would be useful to differentiate between location > based services in general and emergency services since the requirements > are, in most cases, different. > > Ciao > Hannes > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 11:17:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rHz-0000do-OD; Tue, 18 Jul 2006 11:15:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rHy-0000dS-5C; Tue, 18 Jul 2006 11:15:10 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2rHw-0006Vc-CZ; Tue, 18 Jul 2006 11:15:10 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k6IFEuPo028552; Tue, 18 Jul 2006 17:14:56 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k6IFEusg014757; Tue, 18 Jul 2006 17:14:56 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 17:14:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jul 2006 17:14:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Location Conveyance: Scenarios thread-index: AcaqeqCZ+MsW1NWhSfanVll8Io0VCAAAgOLQ From: "Tschofenig, Hannes" To: "Henning Schulzrinne" X-OriginalArrivalTime: 18 Jul 2006 15:14:56.0012 (UTC) FILETIME=[ED466CC0:01C6AA7C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: geopriv@ietf.org, sip@ietf.org Subject: [Sip] AW: [Geopriv] Location Conveyance: Scenarios X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Henning, > Thanks, Hannes; these are helpful to focus the discussion. >=20 > I think, however, that the issue of security (encryption or=20 > integrity)=20 > and conveyance are essentially orthogonal. In other words,=20 > you can apply=20 > the same techniques, with similar problems, in all three conveyance=20 > mechanisms (by-value, by-attachment, by-reference). I fully agree with you.=20 I don't recall that the document ever discussed the possibility of protecting a location-by-reference.=20 Hence, I was puzzled why the encryption is a big deal in one case and not an issue at all in the second one.=20 > The procedural=20 > details differ (such as XML-DSIG and XML encryption vs.=20 > S/MIME vs. TLS),=20 > but the strength and the certificate problems are similar, albeit not=20 > identical. (For example, it is probably somewhat harder to deal with=20 > multi-recipient cases in S/MIME than in other mechanisms.) I agree with you.=20 >=20 > It might help streamline the discussion if we can agree on=20 > this general=20 > statement or show that it is mistaken. >=20 Ciao Hannes > Henning >=20 > Tschofenig, Hannes wrote: > > Hi all,=20 > >=20 > > I have compiled a few message flows that would make it=20 > easier to discuss > > the different scenarios. I have listed some challenges=20 > along with each > > of the scenarios.=20 > >=20 > >=20 > > 1) Location by End Host / Per Value/ in Body > >=20 > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > >=20 > > | SIP Message | | | | > > |---------------------------->| | | | > > | Location (value/body) | | > > | |----------------->| > > | | | > > | SIP Message | > > |<-----------------------------------------------| > > | | > >=20 > > Problems:=20 > > * Likelyhood of the UA using S/MIME; nice on paper but does=20 > it reflect > > reality? > > * UA Alice needs to know that (a) intermediaries do not=20 > need to process > > the PIDF-LO=20 > > (b) recipient has a certificate > > * Unclear what happens if there are multiple recipients.=20 > >=20 > >=20 > >=20 > > 2) Location by End Host / Per Reference / in Body > >=20 > >=20 > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > >=20 > > | SIP Message | | | | > > |---------------------------->| | | | > > | Location (ref./body) | | > > | |----------------->| > > | | | > > | Dereference | > > = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | > > | | > > | SIP Message | > > |<-----------------------------------------------| > > | | > >=20 > > Problems:=20 > > * Can be protected using S/MIME (see issue above) > > * If not protected then the considerations of who is allowed to > > dereference to a PIDF-LO are applicable. There is certainly=20 > a difference > > between a reference pointing to a PIDF-LO at the UA itself and a > > reference obtained using one of the discussed Geopriv L7 protocols.=20 > > It might be difficult for the end host to make the PIDF-LO=20 > available. It > > might be difficult for him to have a server-side certificate but it > > might be easier to control access to it.=20 > >=20 > >=20 > > 3) Location by SIP Proxy / Per Reference / in Header > >=20 > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > >=20 > > | SIP Message | | | | > > |---------------------------->| | | | > > | | SIP Message | > > | |----------------->| > > | | Location | > > | | (ref./header) | > > | | | > > | | | > > | | Dereference | > > | = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | | > > | SIP Message | > > |<-----------------------------------------------| > > | | > > | | > > | | > >=20 > > Problems: > >=20 > > * What should the SIP proxy but into the PIDF-LO when it is created > > (policies, identifiers, etc.)? > > * Authorization aspects: see above (Why cannot just=20 > everyone that sees > > the reference in the header passing by dereference it?) > > * Signing of the reference theoretically possible. SIP=20 > Proxy, however, > > needs to know the intended recipient.=20 > >=20 > >=20 > > 4) Location by SIP Proxy / Per Value / in Header > >=20 > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > >=20 > > | SIP Message | | | | > > |---------------------------->| | | | > > | | SIP Message | > > | |----------------->| > > | | Location | > > | | (value/header) | > > | | | > > | SIP Message | > > |<-----------------------------------------------| > > | | > > | | > > | | > >=20 > > Problems: > >=20 > > * What should the SIP proxy but into the PIDF-LO when it is created > > (policies, identifiers, etc.)? > > * Data URI approach possible but with increased message size.=20 > > * Signing of the PIDF-LO possible but approach similar. SIP Proxy, > > however, needs to know the intended recipient. > >=20 > >=20 > > 5) Location by SBC / Per Value / in Body > >=20 > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > > (SBC) > > | SIP Message | | | | > > |---------------------------->| | | | > > | Location (value/body) | SIP Message | > > | |----------------->| > > | | Location | > > | | (value/body) | > > | | | > > | SIP Message | > > |<-----------------------------------------------| > > | | > > | | > > | | > >=20 > > Problems: > >=20 > > * If there is no solution for the cases available where the=20 > SIP proxy > > can add a PIDF-LO and a reference is not acceptable (because of the > > latency) it is likely that boxes will just do it.=20 > > * Does not play "nicely" with SIP.=20 > > * Problems with E2E security > > =20 > >=20 > > 6) Location by End Host / Per Referene / in Header > >=20 > > UA Alice SIP Proxy UAS-A UAS-B UAS-C > >=20 > > | SIP Message | | | | > > |---------------------------->| | | | > > | Location (ref./header) | | > > | |----------------->| > > | | | > > | Dereference | > > = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | > > | | > > | SIP Message | > > |<-----------------------------------------------| > > | | > >=20 > > Problems: > >=20 > > * Not sure about S/MIME usage > > * Simlar considerations as in (2) > >=20 > > Finally, I think it would be useful to differentiate=20 > between location > > based services in general and emergency services since the=20 > requirements > > are, in most cases, different.=20 > >=20 > > Ciao > > Hannes > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 16:28:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2w8r-0002eA-8o; Tue, 18 Jul 2006 16:26:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2w8p-0002e5-Pv for sip@ietf.org; Tue, 18 Jul 2006 16:26:03 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2w8o-0003HN-Ec for sip@ietf.org; Tue, 18 Jul 2006 16:26:03 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Jul 2006 16:26:00 -0400 X-IronPort-AV: i="4.06,255,1149480000"; d="scan'208"; a="93113239:sNHT4443302390" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6IKQ01c005360; Tue, 18 Jul 2006 16:26:00 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6IKP689007504; Tue, 18 Jul 2006 16:26:00 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 16:25:33 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 16:25:33 -0400 Message-ID: <44BD43BC.7@cisco.com> Date: Tue, 18 Jul 2006 16:25:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] Update to RFC3329, aka Security Agreement References: <1153130894.32143.45.camel@macbuster.research.nokia.com> In-Reply-To: <1153130894.32143.45.camel@macbuster.research.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2006 20:25:33.0345 (UTC) FILETIME=[51FDC110:01C6AAA8] DKIM-Signature: a=rsa-sha1; q=dns; l=2889; t=1153254360; x=1154118360; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Update=20to=20RFC3329, =20aka=20Security=20Agreement |To:Aki=20Niemi=20; X=v=3Dcisco.com=3B=20h=3DFvVbjSIktdxUrMEIEIRSiFXr3Kk=3D; b=V3wy0TtZKEzAupNKMwBtrS+UfrDzmr0FxMNffC3TzGMRHL+sSXTB6RQtPSdGkG1QJOPzTfKt GwMpwyyr33DALfWN2HG54E6Ym148xvmgPRAXpZMIHfHTz0tAwojBRmV/; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ext Sharon Laivand , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki Niemi wrote: > On su, 2006-07-16 at 16:54 +0300, ext Sharon Laivand wrote: >> Hi Aki and all... >> >> >> This email follows my conversation with Gonzalo at last IETF 66th - >> regarding RFC3329 issues. >> >> Here are some issues we thought of. I wonder if it can assist your >> draft. Anyway I will be glad to constantly contribute to this draft. > > Thanks for your feedback. Some comments inline. > >> Here are the comments/additions to the issues: >> >> 1. >> RFC3329 describes how the same security-agreement is used in several >> transactions, but does not specify the relations between those >> transactions. For example, a security-agreement can be obtained via >> OPTIONS transaction and then used by a call-leg. Since there is no >> SIP-wise relation between those two SIP entities, a key for comparison >> must be defined. This is extremely problematic on server side, because >> any incoming transaction must be verified according to the >> security-agreement used in previous (unrelated and even nonexistent) >> transactions. >> One possible solution that is not good for all cases: match of >> security-agreements to SIP dialogs using peer transport address. > > The primary reason this is underspecified is that back when RFC 3329 was > in the works, we didn't have a clear architecture for this sort of > thing. > > We do now, as outbound and SIP identity both rely on a UA having a > "sentinel" of sorts in the network to whom it has a persistent security > association and can send and receive traffic in a secure, identity-safe > way. > > I would say the most common case is that this association is > bootstrapped using a REGISTER, which was, in fact, the assumption of RFC > 3329 as well. Perhaps not that clearly stated, though. When using Digest, I think it is *only* in conjunction with REGISTER that you can bootstrap a security association. Furthermore, it has to be a first-party REGISTER, where To and From (and/or P-Asserted-Identity) are the same. The reason is because Digest authenticates the *source* of the request, not the destination. For some request where source and destination are different, you can't in general know whether the success of the request is dependent on the source being able to authenticate. For instance, suppose there was a REGISTER where From is Alice, and To is Bob. Bob might send a 401 challenge, and Alice might successfully respond to it. But that doesn't mean that any entity responsible for Alice believes this is Alice, it only means that Bob believes this is Alice. It could be that 'Bob' is just a hack server in the network that believes any answer to its challenges. The end result is that 3rd party registrations are not allowed in IMS, and because of the design of the system support for them can't readily be added. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 16:29:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wAF-000333-GS; Tue, 18 Jul 2006 16:27:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wAE-00032j-QC; Tue, 18 Jul 2006 16:27:30 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2wAD-0003Kq-J1; Tue, 18 Jul 2006 16:27:30 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6IKRPfB027508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Jul 2006 16:27:26 -0400 (EDT) Message-ID: <44BD4428.4050802@cs.columbia.edu> Date: Tue, 18 Jul 2006 16:27:20 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "James M. Polk" References: <4.3.2.7.2.20060718145001.03633dd8@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060718145001.03633dd8@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, "Rosen, Brian" , geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James M. Polk wrote: > Henning > > Remind us what the unique use-case is for a data URL, where neither a > by-reference URI nor a by-value PIDF-LO can be used? The use case is proxy-inserted location, where the proxy does not have access to a globally-accessible HTTP server where it can deposit this information. This could be a proxy behind a (corporate) firewall or NAT, for example. > > In other words, why is this needed, and what would it be used for that > every element necessary couldn't use one of the two methods of Location > Conveyance already specified in the doc? See above. The incremental complexity is essentially zero. > > Complexity is an issue in location conveyance - especially during > emergency calling, but I've heard you state this isn't an issue with a > data URL. Are you sure? Are others sure? I don't get your complexity point. The complexity of a data URL is likely to be significantly lower than - setting up a custom web server outside the security or NAT perimeter - that allows remote writes by the proxy server - using a proxy-to-webserver protocol that isn't standardized - using a webserver-to-proxy protocol (to get the object identifier back) that isn't standardized, either - automatically cleaning up location state just at the right time (not too early to avoid resolution problems and not too late to avoid exposure and denial-of-service problems where the attacker uses bogus SIP INVITEs to create lots of location entries) - and hoping that the server is always accessible, so that emergency calls don't fail The data URL solution is self-contained; the reference solution is basically of the "and then magic happens" kind, where the proposed solution only provides a tiny part of what's needed to actually build a real system. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 16:40:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wKp-0004IC-Gr; Tue, 18 Jul 2006 16:38:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wKn-0004I1-MU; Tue, 18 Jul 2006 16:38:25 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2vqk-0002QA-EV; Tue, 18 Jul 2006 16:07:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G2veY-0004HQ-Bm; Tue, 18 Jul 2006 15:54:50 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 18 Jul 2006 12:54:45 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6IJsjmQ032387; Tue, 18 Jul 2006 12:54:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6IJsjJi022356; Tue, 18 Jul 2006 12:54:45 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Jul 2006 12:54:45 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.128]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 12:54:44 -0700 Message-Id: <4.3.2.7.2.20060718145001.03633dd8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jul 2006 14:54:43 -0500 To: Henning Schulzrinne , "Rosen, Brian" From: "James M. Polk" In-Reply-To: <1B6E5F53-EC65-46D6-AF84-7940CE567FFB@cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 Jul 2006 19:54:45.0009 (UTC) FILETIME=[044C1010:01C6AAA4] DKIM-Signature: a=rsa-sha1; q=dns; l=1659; t=1153252485; x=1154116485; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Geopriv]=20Location-by-value=20in=20a=20SIP=20Location=20Header; X=v=3Dcisco.com=3B=20h=3Dr4y4h+w4Et3xIrggQ7oCHB5m+hI=3D; b=pHChkbNXYY7kQ2kUZ2h2fh/joFUB4JZOb8XBANB03KrOtNB2joQ6kKXbDhek+BYpa2aNvtyp K4O+zi1LID8qv1XblJy6/A4MaJ6jGzDcnncB4DpX9eqqwrpBxu0zVVQy; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -1.9 (-) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Henning Remind us what the unique use-case is for a data URL, where neither a by-reference URI nor a by-value PIDF-LO can be used? In other words, why is this needed, and what would it be used for that every element necessary couldn't use one of the two methods of Location Conveyance already specified in the doc? Complexity is an issue in location conveyance - especially during emergency calling, but I've heard you state this isn't an issue with a data URL. Are you sure? Are others sure? At 09:57 AM 7/18/2006 -0400, Henning Schulzrinne wrote: >Brian, > >a four-step process: > >- take any PIDF-LO >- wrap in XML-DSIG as specified by the relevant W3C recommendation >- convert to base-64 >- make into a data URL, as in the example I gave in an earlier message > > data:application/pidf+xml;base64, > >Or did I miss the point of your question? > >See http://en.wikipedia.org/wiki/Data:_URL for additional data URL >examples, btw. > >Henning > >On Jul 18, 2006, at 9:06 AM, Rosen, Brian wrote: > >>Perhaps some enlightenment is in order. It's not clear to me how you >>dsig a Data uri in a Location header (or maybe you mean dsig the >>pidf-lo >>and put both the pidf-lo and the signature in the Data URI) somehow? >>Are there some examples of this kind of thing elsewhere? >> >>If we are ignoring technical arguments (as opposed to use cases), it's >>out of forgetfulness, and not willfulness. What were you referring >>to? >> >>Brian > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 17:01:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wfl-0006u2-9V; Tue, 18 Jul 2006 17:00:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wfk-0006tu-55; Tue, 18 Jul 2006 17:00:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2wfh-0006SU-Pv; Tue, 18 Jul 2006 17:00:04 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 18 Jul 2006 14:00:02 -0700 X-IronPort-AV: i="4.06,255,1149490800"; d="scan'208"; a="306524508:sNHT28268032" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6IL01qN007490; Tue, 18 Jul 2006 14:00:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6IL01HU003551; Tue, 18 Jul 2006 14:00:01 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 14:00:00 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.128]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 14:00:00 -0700 Message-Id: <4.3.2.7.2.20060718155056.0336ec00@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jul 2006 15:59:59 -0500 To: Henning Schulzrinne From: "James M. Polk" In-Reply-To: <44BD4428.4050802@cs.columbia.edu> References: <4.3.2.7.2.20060718145001.03633dd8@email.cisco.com> <4.3.2.7.2.20060718145001.03633dd8@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 Jul 2006 21:00:00.0573 (UTC) FILETIME=[2227B6D0:01C6AAAD] DKIM-Signature: a=rsa-sha1; q=dns; l=2744; t=1153256401; x=1154120401; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Geopriv]=20Location-by-value=20in=20a=20SIP=20Location=20Header; X=v=3Dcisco.com=3B=20h=3Dr4y4h+w4Et3xIrggQ7oCHB5m+hI=3D; b=OWnqTT4RVjtz9fHVZqY+l1bE+8JZHHmPOvSPi5W7BrymGX2jJDSyfcYUZmfFM3KURB24zKbO UFJ/Zt87QinLnJ81lSlVlnjmuAHxXkPApL1DtPsQPX3+djqHF9f5r7p7; Authentication-Results: sj-dkim-8.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sip@ietf.org, "Rosen, Brian" , geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 04:27 PM 7/18/2006 -0400, Henning Schulzrinne wrote: >James M. Polk wrote: >>Henning >>Remind us what the unique use-case is for a data URL, where neither a >>by-reference URI nor a by-value PIDF-LO can be used? > >The use case is proxy-inserted location, where the proxy does not have >access to a globally-accessible HTTP server where it can deposit this >information. This could be a proxy behind a (corporate) firewall or NAT, >for example. ok, but how would a UA know it's behind a corporate NAT/FW, instead of at a home using the SP's LIS beyond the NAT/FW, to know to use a data URL instead of by-value or by-reference PIDF-LO? >>In other words, why is this needed, and what would it be used for that >>every element necessary couldn't use one of the two methods of Location >>Conveyance already specified in the doc? > >See above. The incremental complexity is essentially zero. > >>Complexity is an issue in location conveyance - especially during >>emergency calling, but I've heard you state this isn't an issue with a >>data URL. Are you sure? Are others sure? > >I don't get your complexity point. We're talking about all SIP elements that understand this extension now, if we do as you and Hannes are suggesting, include a third representation. That's more code for every UA to include, and every location aware SIP server. I hear your arguments below essentialling meaning location by-reference is a woefully underspecified user-case, and that it is the one that ought to be the one that may be dropped from the list within this extension proposal (because there is not enough there). Are you going down that path here? >The complexity of a data URL is likely to be significantly lower than > >- setting up a custom web server outside the security or NAT perimeter >- that allows remote writes by the proxy server >- using a proxy-to-webserver protocol that isn't standardized >- using a webserver-to-proxy protocol (to get the object identifier back) >that isn't standardized, either >- automatically cleaning up location state just at the right time (not too >early to avoid resolution problems and not too late to avoid exposure and >denial-of-service problems where the attacker uses bogus SIP INVITEs to >create lots of location entries) >- and hoping that the server is always accessible, so that emergency calls >don't fail > >The data URL solution is self-contained; the reference solution is >basically of the "and then magic happens" kind, where the proposed >solution only provides a tiny part of what's needed to actually build a >real system. should by-reference be taken out as an incomplete piece to an underspecified solution, IYO? >Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 17:29:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x6N-0001hd-RV; Tue, 18 Jul 2006 17:27:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x6M-0001hD-4J; Tue, 18 Jul 2006 17:27:34 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2x6K-0000y7-T8; Tue, 18 Jul 2006 17:27:34 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6ILRVfB001221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Jul 2006 17:27:31 -0400 (EDT) Message-ID: <44BD523E.5060201@cs.columbia.edu> Date: Tue, 18 Jul 2006 17:27:26 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "James M. Polk" References: <4.3.2.7.2.20060718145001.03633dd8@email.cisco.com> <4.3.2.7.2.20060718145001.03633dd8@email.cisco.com> <4.3.2.7.2.20060718155056.0336ec00@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060718155056.0336ec00@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sip@ietf.org, "Rosen, Brian" , geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> The use case is proxy-inserted location, where the proxy does not have ^^^^^^^^^^^^^^ I'm assuming that the proxy knows whether it has access to a web server or not. The UA really wouldn't know or care in that case. > ok, but how would a UA know it's behind a corporate NAT/FW, instead of > at a home using the SP's LIS beyond the NAT/FW, to know to use a data > URL instead of by-value or by-reference PIDF-LO? I would expect a UA to always use by-attachment unless it used an L7 location mechanism that provided a reference to an object on a LIS somewhere. (This, by the way, raises some additional issues; how can the UA know that the pointer it got from the LIS is accessible, by policy, to a random third party?) > We're talking about all SIP elements that understand this extension now, > if we do as you and Hannes are suggesting, include a third > representation. That's more code for every UA to include, and every > location aware SIP server. I generally share concerns about code complexity, but we're talking pretty trivial code here. In a PHP-like language, it would be something like if (url['scheme'] == 'http') { $fd = fopen($url); $lo = fread($fd); } elseif (url['scheme'] == 'data') { $u = split(',', $url); $lo = base64_decode($u[1]); } Only the last elseif is data-specific. In other words, not exactly a big deal. > > I hear your arguments below essentialling meaning location by-reference > is a woefully underspecified user-case, and that it is the one that > ought to be the one that may be dropped from the list within this > extension proposal (because there is not enough there). Are you going > down that path here? There may well be deployments where by-reference is valuable (such as where the LIS already provides by-reference location information to the proxy), but I fear that if we only do S/MIME attachments, the practical outcome is going to be lots of SBCs modifying SIP bodies. > should by-reference be taken out as an incomplete piece to an > underspecified solution, IYO? I believe it is currently underspecified; I won't go as far as suggesting it be taken out as noted above. > > >> Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 18 19:15:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ylP-0008JB-Dc; Tue, 18 Jul 2006 19:14:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ylO-0008J3-2T; Tue, 18 Jul 2006 19:14:02 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2ylM-0007hC-Pr; Tue, 18 Jul 2006 19:14:02 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 18:13:59 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 18 Jul 2006 18:13:59 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 18:13:58 -0500 Message-ID: From: "Thomson, Martin" To: "Andrew Newton" , "Brian Rosen" Date: Tue, 18 Jul 2006 18:12:18 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 18 Jul 2006 23:13:58.0687 (UTC) FILETIME=[D93E92F0:01C6AABF] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <44BD51AC.8030306@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Geopriv] SIP Location Conveyance:dereferencing location-by-reference Thread-Index: AcaqsKojEpTbEKw4QW+uKohcyfSzCgADn06g X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] RE: [Geopriv] SIP Location Conveyance:dereferencing location-by-reference X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1317283984==" Errors-To: sip-bounces@ietf.org --===============1317283984== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSBzZWUgbm8gaGFybSBpbiBzaW1wbGlmeWluZyB0aGUgaGVhZGVyIHRvIGJlIGp1c3QgJ2Fic29s dXRlVVJJJyBhcyBpbiBSRkMgMzk4Ni4gIFRleHQgaW4gdGhlIGRvY3VtZW50IGNhbiBzYXkgdGhh dCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IGh0dHBzOiBhbmQgY2lkOiAod2l0aCBhcHBy b3ByaWF0ZSBjYXV0aW9ucyByZWdhcmRpbmcgdGhlIGRlZ2VuZXJhdGUgY2FzZSBvZiBodHRwOiku DQoNCkFuZHksDQoNCkRpc2N1c3Npb25zIHRvIGRhdGUgb24gYSBzdWJzY3JpcHRpb24gVVJJIGlu ZGljYXRlIHRoYXQgaXQgaXMgZm9yIExJUyAtPiBUYXJnZXQgcHVycG9zZXMgb25seS4gIFdlIGhh dmUgbm90IHlldCByZWFjaGVkIHRoZSBwb2ludCB3aGVyZSB3ZSBkaXNjdXNzIHRoZSBjcmVhdGlv biBvZiBhIHJlZmVyZW5jZS4gIFRoZXJlIGFyZSBvYnZpb3VzIHNpbWlsYXJpdGllcywgYnV0IEkg dGhpbmsgdGhhdCB3ZSB3b3VsZCBuZWVkIHRvIHJlc29sdmUgc29tZSBwcml2YWN5IGFuZCBzZWN1 cml0eSBjb25jZXJucyBmaXJzdC4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBBbmRyZXcgTmV3dG9uIFttYWlsdG86YW5keUBoeHIudXNdDQo+IFNlbnQ6IFdlZG5lc2Rh eSwgMTkgSnVseSAyMDA2IDc6MjUgQU0NCj4gVG86IEJyaWFuIFJvc2VuDQo+IENjOiBzaXBAaWV0 Zi5vcmc7IGdlb3ByaXZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtHZW9wcml2XSBTSVAgTG9j YXRpb24gQ29udmV5YW5jZTpkZXJlZmVyZW5jaW5nIGxvY2F0aW9uLWJ5LQ0KPiByZWZlcmVuY2UN Cj4gDQo+IA0KPiANCj4gQnJpYW4gUm9zZW4gd3JvdGU6DQo+ID4gSW4gc2lwLWxvY2F0aW9uLWNv bnZleWFuY2UsIHdlIGFsbG93IGEgVVJJIGluIHRoZSBMb2NhdGlvbiBoZWFkZXIgdG8NCj4gcHJv dmlkZQ0KPiA+IGZvciBsb2NhdGlvbi1ieS1yZWZlcmVuY2UuICBXZSBtdXN0IGhhdmUgc29tZSBr aW5kIG9mIHRleHQgdGhhdCBzYXlzDQo+IHdoYXQNCj4gPiB0aGUgcmVjaXBpZW50IGRvZXMgd2l0 aCB0aGlzIFVSSS4NCj4gPg0KPiA+IE91ciBwcm9wb3NhbCBpcyB0byBjaGFuZ2UgdGhlIEFCTkYs IHdoaWNoIGN1cnJlbnRseSBhbGxvd3MgdGhpcyBVUkkgdG8NCj4gYmUNCj4gPiBBYnNvbHV0ZVVS SSAobWVhbmluZyBhbnkgc2NoZW1lKSBhbmQgcmVwbGFjZSBpdCB3aXRoIEhUVFAvSFRUUFMgb25s eS4NCj4gT2YNCj4gPiBjb3Vyc2UsIHRoZXJlIHdvdWxkIHN0aWxsIGJlIHRoZSBjaWQ6IGZvciBt ZXNzYWdlIGJvZHkgaWRlbnRpZmljYXRpb24uDQo+IFdlDQo+ID4gd291bGQgdGhlbiBkZWZpbmUg YSBkZXJlZmVyZW5jZSBwcm9jZXNzIGFzIGRvaW5nIGFuIEhUVFAvSFRUUFMgR0VULCB3aXRoDQo+ IG5vDQo+ID4gcGFyYW1ldGVycywgb24gdGhlIFVSSSwgYW5kIGV4cGVjdCB0byByZWNlaXZlIGlu IHJldHVybiBhIFBJREYtTE8sDQo+IGV4YWN0bHkNCj4gPiBhcyBpdCB3b3VsZCBhcHBlYXIgaW4g YSBib2R5LiAgVGhlIHRleHQgd291bGQgc3RhdGUgTVVTVCBpbXBsZW1lbnQgVExTLA0KPiA+IGV4 Y2VwdCBmb3IgdGhlIGVtZXJnZW5jeSBjYXNlLiAgVGhlIHRleHQgd291bGQgZnVydGhlciBzdGF0 ZSB0aGF0DQo+IGFkZGl0aW9uYWwNCj4gPiBkZXJlZmVyZW5jaW5nIHByb2NlZHVyZXMgY291bGQg YmUgZGVmaW5lZCBieSBhIHN0YW5kYXJkcyB0cmFjayBSRkMuDQo+IA0KPiBJJ20gbm90IHN1cmUg aXQgaXMgYXMgc2ltcGxlIGFzIHRoaXMuDQo+IA0KPiBXaGF0IGhhcHBlbnMgd2hlbiBhIGNsaWVu dCBnZXRzIGEgc3Vic2NyaWJhYmxlIGxvY2F0aW9uIHJlZmVyZW5jZSBVUkkNCj4gdmlhIHRoZSBM Ny1MQ1AsIGFuZCBwdXRzIHRoYXQgaW50byBhIExvY2F0aW9uIGhlYWRlciBpbiBhbiBJTlZJVEU/ ICBIb3cNCj4gaXMgdGhlIHN1YnNjcmlwdGlvbiBkb25lIHdpdGggSFRUUD8NCj4gDQo+IC1hbmR5 DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gR2VvcHJpdiBtYWlsaW5nIGxpc3QNCj4gR2VvcHJpdkBpZXRmLm9yZw0KPiBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2DQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWdu YXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0 YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkg YW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBl bWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpbbWYyXQ== --===============1317283984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1317283984==-- From sip-bounces@ietf.org Tue Jul 18 19:16:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ylw-00008u-FV; Tue, 18 Jul 2006 19:14:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ylv-00008f-0D; Tue, 18 Jul 2006 19:14:35 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2ylt-0007if-M3; Tue, 18 Jul 2006 19:14:34 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 18:14:32 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 18 Jul 2006 18:14:32 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 18:14:31 -0500 Message-ID: From: "Thomson, Martin" To: "Rosen, Brian" , "Henning Schulzrinne" Date: Tue, 18 Jul 2006 18:14:30 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 18 Jul 2006 23:14:31.0937 (UTC) FILETIME=[ED101F10:01C6AABF] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Geopriv] Location-by-value in a SIP Location Header Thread-Index: Acaqaf7jfWewMixZS0itJGlcoxIm1QAAGogQABVeiMA= X-Spam-Score: 0.5 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2087304446==" Errors-To: sip-bounces@ietf.org --===============2087304446== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SWYgeW91IHdhbnQgdGVjaG5pY2FsbHkgZmVhc2libGUsIEkgY2FuIHBvc3QgYSBVUkkgdG8gdGhl IGxpc3QgdGhhdCBpbmNsdWRlcyBhIGNvbXBsZXRlIFBJREYtTE8gd2l0aCBEU2lnLiAgSXQncyBh IGxpdHRsZSBsb25nIHRob3VnaC4NCg0KSSdtIG5vdCBzdWdnZXN0aW5nIHRoYXQgdGhpcyBhIGdv b2QgaWRlYSwgYnV0IEkgc2VlIG5vIHJlYXNvbiB0byBwcmV2ZW50IGl0Lg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvc2VuLCBCcmlhbiBbbWFpbHRvOkJyaWFuLlJv c2VuQG5ldXN0YXIuYml6XQ0KPiBTZW50OiBUdWVzZGF5LCAxOCBKdWx5IDIwMDYgMTE6MDcgUE0N Cj4gVG86IEhlbm5pbmcgU2NodWx6cmlubmUNCj4gQ2M6IHNpcEBpZXRmLm9yZzsgZ2VvcHJpdkBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0dlb3ByaXZdIExvY2F0aW9uLWJ5LXZhbHVlIGluIGEg U0lQIExvY2F0aW9uIEhlYWRlcg0KPiANCj4gUGVyaGFwcyBzb21lIGVubGlnaHRlbm1lbnQgaXMg aW4gb3JkZXIuICBJdCdzIG5vdCBjbGVhciB0byBtZSBob3cgeW91DQo+IGRzaWcgYSBEYXRhIHVy aSBpbiBhIExvY2F0aW9uIGhlYWRlciAob3IgbWF5YmUgeW91IG1lYW4gZHNpZyB0aGUgcGlkZi1s bw0KPiBhbmQgcHV0IGJvdGggdGhlIHBpZGYtbG8gYW5kIHRoZSBzaWduYXR1cmUgaW4gdGhlIERh dGEgVVJJKSBzb21laG93Pw0KPiBBcmUgdGhlcmUgc29tZSBleGFtcGxlcyBvZiB0aGlzIGtpbmQg b2YgdGhpbmcgZWxzZXdoZXJlPw0KPiANCj4gSWYgd2UgYXJlIGlnbm9yaW5nIHRlY2huaWNhbCBh cmd1bWVudHMgKGFzIG9wcG9zZWQgdG8gdXNlIGNhc2VzKSwgaXQncw0KPiBvdXQgb2YgZm9yZ2V0 ZnVsbmVzcywgYW5kIG5vdCB3aWxsZnVsbmVzcy4gIFdoYXQgd2VyZSB5b3UgcmVmZXJyaW5nIHRv Pw0KPiANCj4gQnJpYW4NCj4gDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogSGVubmluZyBTY2h1bHpyaW5uZSBbbWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHVd DQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTgsIDIwMDYgODo1OSBBTQ0KPiBUbzogUm9zZW4sIEJy aWFuDQo+IENjOiBzaXBAaWV0Zi5vcmc7IGdlb3ByaXZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFtHZW9wcml2XSBMb2NhdGlvbi1ieS12YWx1ZSBpbiBhIFNJUCBMb2NhdGlvbiBIZWFkZXINCj4g DQo+IEJyaWFuLCBKYW1lczoNCj4gDQo+IHRoaXMgaXMgc2ltcGx5IGZhbHNlLiBJZiBkZXNpcmVk LCBYTUwtRFNJRyBpcyBhIHdlbGwta25vd24gYW5kDQo+IGFjY2VwdGVkIG1lY2hhbmlzbSB0byBh Y2hpZXZlIGludGVncml0eS4gU3VjaCBzcGVjaWZpY2F0aW9uIGlzIG5vDQo+IGxvbmdlciB0aGFu IHRoZSBNVVNUIE5PVCB0aGF0IHlvdSBwcm9wb3NlLiBZb3UgYXJlIGFsc28gd2lsbGZ1bGx5DQo+ IGlnbm9yaW5nIHRoZSBvdGhlciB0ZWNobmljYWwgYXJndW1lbnRzIG1hZGUgYXMgcGFydCBvZiB0 aGlzIGRpc2N1c3Npb24uDQo+IA0KPiBIZW5uaW5nDQo+IA0KPiBPbiBKdWwgMTgsIDIwMDYsIGF0 IDg6NDggQU0sIFJvc2VuLCBCcmlhbiB3cm90ZToNCj4gDQo+ID4gVGhlcmUgd2FzIGEgZGVzaXJl IGV4cHJlc3NlZCBieSBIYW5uZXMgdG8gcHJvdmlkZSBhIHdheSBmb3IgYSBwcm94eSB0bw0KPiA+ IGluc2VydCBsb2NhdGlvbi1ieS12YWx1ZS4gIEhlIGhhZCBwcm9wb3NlZCBhIFNJUCBMb2NhdGlv biBoZWFkZXINCj4gPiBzcGVjaWZpYyB3YXkuICBJbiBJRVRGNjYsIEhlbm5pbmcgc3VnZ2VzdGVk IGp1c3QgdXNpbmcgYSBkYXRhIFVSSS4NCj4gPg0KPiA+IERvaW5nIHRoaXMgbWF5IHJ1biBhZm91 bCBvZiB0aGUgZ2VvcHJpdiBsb2NhdGlvbiBwcml2YWN5IGNvbmNlcm5zLA0KPiA+IGJlY2F1c2Ug dGhlcmUgaXMgbm8gd2F5IGZvciB0aGUgdXNlciB0byBzaWduIHRoZSBoZWFkZXIgdG8gcHJvdmlk ZQ0KPiA+IGFzc3VyYW5jZSB0aGF0IHRoZSBQSURGLCBhbmQgc3BlY2lmaWNhbGx5IHRoZSByZXRl bnRpb24gYW5kIG90aGVyDQo+ID4gcG9saWN5DQo+ID4gYml0cyBhcmUgcHJlc2VydmVkLiAgTm90 ZSB0aGF0IFMvTUlNRSBwcm92aWRlcyBzdWZmaWNpZW50IGludGVncml0eQ0KPiA+IHByb3RlY3Rp b24gZm9yIGEgYm9keS4gIEl0J3MgcHJvYmFibHkgb2theSB0byB1c2UgVExTIHBlciBob3AgdG8N Cj4gPiBwcm92aWRlDQo+ID4gcHJpdmFjeSwgYnV0IG5vdCBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4g IFRoZSBhdXRob3JzIGJlbGlldmUgdGhhdCB0aGVyZQ0KPiA+IGlzIG5vIHJlYWxseSBjb21wZWxs aW5nIHVzZSBjYXNlIGZvciB0aGlzIGZlYXR1cmUsIGFuZCB0aGUgZWZmb3J0IHRvDQo+ID4gZGVm aW5lIGFjY2VwdGFibGUgc2VjdXJpdHkgbWVjaGFuaXNtcyBmb3IgbG9jYXRpb24gZGF0YSBpbiBh IGhlYWRlcg0KPiA+IHdvdWxkIGJlIGEgc2lnbmlmaWNhbnQgZWZmb3J0LCBmdXJ0aGVyIGRlbGF5 aW5nIHRoZSBkcmFmdC4NCj4gPg0KPiA+IFdlIHByb3Bvc2UsIHRoZXJlZm9yZSwgdG8gc3RhdGUg aW4gc2lwLWxvY2F0aW9uLWNvbnZleWFuY2UsIHRoYXQgYQ0KPiA+IERhdGENCj4gPiBVUkkgTVVT VCBOT1QgYmUgdXNlZCBpbiB0aGUgTG9jYXRpb24gaGVhZGVyIHVudGlsIGEgc3RhbmRhcmRzIHRy YWNrDQo+ID4gUkZDDQo+ID4gZGVmaW5lcyBhIHN1aXRhYmxlIHNlY3VyaXR5IG1lY2hhbmlzbSB0 byBwcm90ZWN0IHRoZSBQSURGIGluIHRoZQ0KPiA+IGhlYWRlci4NCj4gPg0KPiA+IEJyaWFuIGFu ZCBKYW1lcw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiBHZW9wcml2IG1haWxpbmcgbGlzdA0KPiA+IEdlb3ByaXZAaWV0Zi5vcmcN Cj4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2DQo+IA0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g R2VvcHJpdiBtYWlsaW5nIGxpc3QNCj4gR2VvcHJpdkBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCBy ZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBv ciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQg aXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRl bGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBp cyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpb bWYyXQ== --===============2087304446== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2087304446==-- From sip-bounces@ietf.org Wed Jul 19 01:07:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G34F9-0004Jp-Rc; Wed, 19 Jul 2006 01:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G34F8-0004Jj-J1 for sip@ietf.org; Wed, 19 Jul 2006 01:05:06 -0400 Received: from plmler4.mail.eds.com ([199.228.142.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G34F7-0001FR-6x for sip@ietf.org; Wed, 19 Jul 2006 01:05:06 -0400 Received: from plmlir1.mail.eds.com (plmlir1-2.mail.eds.com [199.228.142.131]) by plmler4.mail.eds.com (8.13.7/8.12.10) with ESMTP id k6J5528M004571; Wed, 19 Jul 2006 00:05:03 -0500 Received: from plmlir1.mail.eds.com (localhost [127.0.0.1]) by plmlir1.mail.eds.com (8.13.7/8.12.10) with ESMTP id k6J54bjb031171; Wed, 19 Jul 2006 00:04:37 -0500 Received: from usut001.3com.com ([205.142.126.149]) by plmlir1.mail.eds.com (8.13.7/8.12.10) with ESMTP id k6J54b9C031166; Wed, 19 Jul 2006 00:04:37 -0500 To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Udit_Goyal@3com.com Date: Wed, 19 Jul 2006 10:38:06 +0530 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 07/18/2006 10:04:37 PM, Serialize complete at 07/18/2006 10:04:37 PM X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip-implementors@cs.columbia.edu Subject: [Sip] How to reject a binding for REGISTER X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1912661103==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1912661103== Content-Type: multipart/alternative; boundary="=_alternative 001C0AF1652571B0_=" This is a multipart message in MIME format. --=_alternative 001C0AF1652571B0_= Content-Type: text/plain; charset="US-ASCII" Hi, If registrar receives a REGISTER request with two Contact headers, and registrar wants to register only one binding, how it can indicate this in the response message (should it omit the Contact header not supported in 200 ok response) One scenario happening is UAC sending two Contact headers with same IP and port but protocol as TCP and UDP, but server does not support TCP, so it want to only create binding for UDP Contact header, so it wants to indicate to UAC that it has created only one binding. Thanks, Udit --=_alternative 001C0AF1652571B0_= Content-Type: text/html; charset="US-ASCII"
Hi,

If registrar receives a REGISTER request with two Contact headers, and registrar wants to register only one binding,
how it can indicate this in the response message (should it omit the Contact header not supported in 200 ok response)

One scenario happening is UAC sending two Contact headers with same IP and port but protocol as TCP and UDP, but server does not support TCP, so it want to only create binding for UDP Contact header, so it wants to indicate to UAC that it has created only one binding.

Thanks,
Udit
--=_alternative 001C0AF1652571B0_=-- --===============1912661103== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1912661103==-- From sip-bounces@ietf.org Wed Jul 19 02:15:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G35J9-0007az-Ge; Wed, 19 Jul 2006 02:13:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G35J7-0007al-MU for sip@ietf.org; Wed, 19 Jul 2006 02:13:17 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17] helo=jaguar.hss.hns.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G35J6-0006kL-Io for sip@ietf.org; Wed, 19 Jul 2006 02:13:17 -0400 Received: from jaguar.hss.hns.com (localhost [127.0.0.1]) by jaguar.hss.hns.com (8.13.6/8.12.10) with ESMTP id k6J6Ecxt007800 for ; Wed, 19 Jul 2006 11:44:38 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by jaguar.hss.hns.com (8.13.6/8.13.6) with ESMTP id k6J6EY6G007772; Wed, 19 Jul 2006 11:44:34 +0530 (IST) Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k6J6E0L06805; Wed, 19 Jul 2006 11:44:01 +0530 (IST) In-Reply-To: To: Udit_Goyal@3com.com Subject: Re: [Sip] How to reject a binding for REGISTER MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Retesh Chadha Date: Wed, 19 Jul 2006 11:45:57 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 19/07/2006 11:43:01 AM, Serialize complete at 19/07/2006 11:43:01 AM X-Spam-Score: 0.6 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0521981012==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0521981012== Content-Type: multipart/alternative; boundary="=_alternative 00222670652571B0_=" This is a multipart message in MIME format. --=_alternative 00222670652571B0_= Content-Type: text/plain; charset="US-ASCII" Hi I didnt find this mentioned in RFC 3261 and so this means that its upto the particular Registrar implementation. But I think it should send 200 ok with the current bindings (ie omitting the un-acceptable contact). 200 ok is the only appropriate response here, because REGISTER request is valid and atleast one contact is accepted by the Registrar. Regards Retesh Udit_Goyal@3com.com 07/19/2006 10:38 AM To sip@ietf.org cc sip-implementors@cs.columbia.edu Subject [Sip] How to reject a binding for REGISTER Hi, If registrar receives a REGISTER request with two Contact headers, and registrar wants to register only one binding, how it can indicate this in the response message (should it omit the Contact header not supported in 200 ok response) One scenario happening is UAC sending two Contact headers with same IP and port but protocol as TCP and UDP, but server does not support TCP, so it want to only create binding for UDP Contact header, so it wants to indicate to UAC that it has created only one binding. Thanks, Udit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip *********************** FSS-Unclassified *********************** --=_alternative 00222670652571B0_= Content-Type: text/html; charset="US-ASCII"
Hi
I didnt find this mentioned in RFC 3261 and so this means that its upto the particular Registrar implementation.
But I think it should send 200 ok with the current bindings (ie omitting the un-acceptable contact). 200 ok is the only appropriate response here, because REGISTER request is valid and atleast one contact is accepted by the Registrar.

Regards
Retesh



Udit_Goyal@3com.com

07/19/2006 10:38 AM

To
sip@ietf.org
cc
sip-implementors@cs.columbia.edu
Subject
[Sip] How to reject a binding for REGISTER






Hi,

If registrar receives a REGISTER request with two Contact headers, and registrar wants to register only one binding,
how it can indicate this in the response message (should it omit the Contact header not supported in 200 ok response)

One scenario happening is UAC sending two Contact headers with same IP and port but protocol as TCP and UDP, but server does not support TCP, so it want to only create binding for UDP Contact header, so it wants to indicate to UAC that it has created only one binding.

Thanks,
Udit _______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


***********************  FSS-Unclassified   *********************** --=_alternative 00222670652571B0_=-- --===============0521981012== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0521981012==-- From sip-bounces@ietf.org Wed Jul 19 08:38:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3BHe-0006wB-Av; Wed, 19 Jul 2006 08:36:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3BHc-0006vl-Uk; Wed, 19 Jul 2006 08:36:08 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3BHc-0007KG-Jr; Wed, 19 Jul 2006 08:36:08 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6JCZpCx015817; Wed, 19 Jul 2006 07:35:51 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ9760A>; Wed, 19 Jul 2006 13:35:51 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29098F@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Thomson, Martin'" , "Rosen, Brian" , Henning Schulzrinne Date: Wed, 19 Jul 2006 13:35:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" X-Spam-Score: 0.5 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As SIP WG chair) Just to set some limits to this discussion, let me state where we are in the progression of this work item. Remember it is now being classed as urgent and we need to get an RFC out of the door, and the SIP chairs are working with the GEOPRIV chairs as to the quickest way to do this: 1) The requirements in the document have been approved by the SIPPING group (a long time ago) and therefore we should not be inventing new requirements without a clear use case that has clear agreement. 2) The SIP group have already identified that two mechanisms to support these requirements should be documented (e.g. the location by value in a body, and the location by reference in a header. These two mechanisms appear to support all the current requirements. In other words, SIP have agreed the technical solution, and we are in the stage of trying to document it. 3) Using a data URL appears to add a third mechanism, if only because it will at least need to have a different set of security considerations documented for it. We should only be adding a third mechanism if: a) the existing mechanism can be shown not to meet all the requirements; or b) the use case where it offers advantages is clearly identified; and c) the compatibility issues are addressed (i.e. does the UAS need to support all of what is now three mechanisms or is there some other support requirement); and d) this can be shown as impossible to be discussed as a future extension. Could I also suggest (in addition to the above) that if people want to proceed with this discussion, it would be appropriate to submit an i-d targeted at the SIP WG identifying the technical solution proposed (with as much completeness as is possible). And remember if you think this discussion is needed, it needs to occur quickly. regards Keith > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: 19 July 2006 00:15 > To: Rosen, Brian; Henning Schulzrinne > Cc: sip@ietf.org; geopriv@ietf.org > Subject: RE: [Geopriv] Location-by-value in a SIP Location Header > > > If you want technically feasible, I can post a URI to the > list that includes a complete PIDF-LO with DSig. It's a > little long though. > > I'm not suggesting that this a good idea, but I see no reason > to prevent it. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Tuesday, 18 July 2006 11:07 PM > > To: Henning Schulzrinne > > Cc: sip@ietf.org; geopriv@ietf.org > > Subject: RE: [Geopriv] Location-by-value in a SIP Location Header > > > > Perhaps some enlightenment is in order. It's not clear to > me how you > > dsig a Data uri in a Location header (or maybe you mean > dsig the pidf-lo > > and put both the pidf-lo and the signature in the Data URI) somehow? > > Are there some examples of this kind of thing elsewhere? > > > > If we are ignoring technical arguments (as opposed to use > cases), it's > > out of forgetfulness, and not willfulness. What were you > referring to? > > > > Brian > > > > > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, July 18, 2006 8:59 AM > > To: Rosen, Brian > > Cc: sip@ietf.org; geopriv@ietf.org > > Subject: Re: [Geopriv] Location-by-value in a SIP Location Header > > > > Brian, James: > > > > this is simply false. If desired, XML-DSIG is a well-known and > > accepted mechanism to achieve integrity. Such specification is no > > longer than the MUST NOT that you propose. You are also willfully > > ignoring the other technical arguments made as part of this > discussion. > > > > Henning > > > > On Jul 18, 2006, at 8:48 AM, Rosen, Brian wrote: > > > > > There was a desire expressed by Hannes to provide a way > for a proxy to > > > insert location-by-value. He had proposed a SIP Location header > > > specific way. In IETF66, Henning suggested just using a data URI. > > > > > > Doing this may run afoul of the geopriv location privacy concerns, > > > because there is no way for the user to sign the header to provide > > > assurance that the PIDF, and specifically the retention and other > > > policy > > > bits are preserved. Note that S/MIME provides sufficient > integrity > > > protection for a body. It's probably okay to use TLS per hop to > > > provide > > > privacy, but not integrity protection. The authors > believe that there > > > is no really compelling use case for this feature, and > the effort to > > > define acceptable security mechanisms for location data > in a header > > > would be a significant effort, further delaying the draft. > > > > > > We propose, therefore, to state in sip-location-conveyance, that a > > > Data > > > URI MUST NOT be used in the Location header until a > standards track > > > RFC > > > defines a suitable security mechanism to protect the PIDF in the > > > header. > > > > > > Brian and James > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 09:08:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3BlL-0002t7-KX; Wed, 19 Jul 2006 09:06:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3BlI-0002st-JJ for sip@ietf.org; Wed, 19 Jul 2006 09:06:48 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3BlF-0000sd-Tt for sip@ietf.org; Wed, 19 Jul 2006 09:06:48 -0400 Received: (qmail invoked by alias); 19 Jul 2006 13:00:03 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp043) with SMTP; 19 Jul 2006 15:00:03 +0200 X-Authenticated: #29516787 Message-ID: <44BE2CC7.9080202@gmx.net> Date: Wed, 19 Jul 2006 14:59:51 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" References: <475FF955A05DD411980D00508B6D5FB00C29098F@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C29098F@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: sip@ietf.org, "Rosen, Brian" , geopriv@ietf.org, "'Thomson, Martin'" , Henning Schulzrinne Subject: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Keith, Drage, Keith (Keith) wrote: > (As SIP WG chair) > > Just to set some limits to this discussion, let me state where we are > in the progression of this work item. Remember it is now being > classed as urgent and we need to get an RFC out of the door, and the > SIP chairs are working with the GEOPRIV chairs as to the quickest way > to do this: > > 1) The requirements in the document have been approved by the SIPPING > group (a long time ago) and therefore we should not be inventing new > requirements without a clear use case that has clear agreement. At that time when the requirements were written we weren't even close to understand how the VoIP emergency service solutions would look like. > > 2) The SIP group have already identified that two mechanisms to > support these requirements should be documented (e.g. the location by > value in a body, and the location by reference in a header. These two > mechanisms appear to support all the current requirements. In other > words, SIP have agreed the technical solution, and we are in the > stage of trying to document it. Actually, as James pointed out the document supports implicitly three mechanisms: * Location by Value in the Body (by end host) * Location by Reference in the Header (by end host and by the proxy) * Location by Reference in the Body (by end host) In my scenario mail I wanted to point out that it is necessary to describe these 3 mechanisms and to discuss the difference between an end host and a proxy doing the processing. > > 3) Using a data URL appears to add a third mechanism, if only because > it will at least need to have a different set of security > considerations documented for it. As I argued in my long list of scenarios I don't believe that the security properties are different compared to the approach where Location by Reference (with the reference being added by the proxy) is used. > We should only be adding a third mechanism if: > > a) the existing mechanism can be shown not to meet all the > requirements; or b) the use case where it offers advantages is > clearly identified; and c) the compatibility issues are addressed > (i.e. does the UAS need to support all of what is now three > mechanisms or is there some other support requirement); and d) this > can be shown as impossible to be discussed as a future extension. Within the emergency work we got the feedback that a number of folks are interested in attaching location information per value by a SIP proxy. I don't want them to do it without having us to look at the implications. The 3GPP architecture wasn't quite detailed enough on this subject to judge whether they are one of the potential consumers. Are they? You know it better than I do. We still need to have a discussion on some of these issues in ECRIT. Ted provided excellent meeting minutes. > > Could I also suggest (in addition to the above) that if people want > to proceed with this discussion, it would be appropriate to submit an > i-d targeted at the SIP WG identifying the technical solution > proposed (with as much completeness as is possible). And remember if > you think this discussion is needed, it needs to occur quickly. Sure, we can do this. Still, I believe it also helps the solutions offered in the current document if we discuss the security aspects. I am interested to have a good location conveyance document that covers a discussion about these issues. In GEOPRIV we had a long discussion about the security aspects of retrieving location information from the access network using a layer 7 protocol. If we ignore the details then there is a lot of similarity. > > regards Ciao Hannes > > Keith > > >> -----Original Message----- From: Thomson, Martin >> [mailto:Martin.Thomson@andrew.com] Sent: 19 July 2006 00:15 To: >> Rosen, Brian; Henning Schulzrinne Cc: sip@ietf.org; >> geopriv@ietf.org Subject: RE: [Geopriv] Location-by-value in a SIP >> Location Header >> >> >> If you want technically feasible, I can post a URI to the list that >> includes a complete PIDF-LO with DSig. It's a little long though. >> >> I'm not suggesting that this a good idea, but I see no reason to >> prevent it. >> >> >>> -----Original Message----- From: Rosen, Brian >>> [mailto:Brian.Rosen@neustar.biz] Sent: Tuesday, 18 July 2006 >>> 11:07 PM To: Henning Schulzrinne Cc: sip@ietf.org; >>> geopriv@ietf.org Subject: RE: [Geopriv] Location-by-value in a >>> SIP Location Header >>> >>> Perhaps some enlightenment is in order. It's not clear to >> >> me how you >> >>> dsig a Data uri in a Location header (or maybe you mean >> >> dsig the pidf-lo >> >>> and put both the pidf-lo and the signature in the Data URI) >>> somehow? Are there some examples of this kind of thing elsewhere? >>> >>> >>> If we are ignoring technical arguments (as opposed to use >> >> cases), it's >> >>> out of forgetfulness, and not willfulness. What were you >> >> referring to? >> >>> Brian >>> >>> >>> >>> -----Original Message----- From: Henning Schulzrinne >>> [mailto:hgs@cs.columbia.edu] Sent: Tuesday, July 18, 2006 8:59 AM >>> To: Rosen, Brian Cc: sip@ietf.org; geopriv@ietf.org Subject: Re: >>> [Geopriv] Location-by-value in a SIP Location Header >>> >>> Brian, James: >>> >>> this is simply false. If desired, XML-DSIG is a well-known and >>> accepted mechanism to achieve integrity. Such specification is no >>> longer than the MUST NOT that you propose. You are also >>> willfully ignoring the other technical arguments made as part of >>> this >> >> discussion. >> >>> Henning >>> >>> On Jul 18, 2006, at 8:48 AM, Rosen, Brian wrote: >>> >>> >>>> There was a desire expressed by Hannes to provide a way >> >> for a proxy to >> >>>> insert location-by-value. He had proposed a SIP Location >>>> header specific way. In IETF66, Henning suggested just using a >>>> data URI. >>>> >>>> Doing this may run afoul of the geopriv location privacy >>>> concerns, because there is no way for the user to sign the >>>> header to provide assurance that the PIDF, and specifically the >>>> retention and other policy bits are preserved. Note that >>>> S/MIME provides sufficient >> >> integrity >> >>>> protection for a body. It's probably okay to use TLS per hop >>>> to provide privacy, but not integrity protection. The authors >>>> >> >> believe that there >> >>>> is no really compelling use case for this feature, and >> >> the effort to >> >>>> define acceptable security mechanisms for location data >> >> in a header >> >>>> would be a significant effort, further delaying the draft. >>>> >>>> We propose, therefore, to state in sip-location-conveyance, >>>> that a Data URI MUST NOT be used in the Location header until a >>>> >> >> standards track >> >>>> RFC defines a suitable security mechanism to protect the PIDF >>>> in the header. >>>> >>>> Brian and James >>>> >>>> _______________________________________________ Geopriv mailing >>>> list Geopriv@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/geopriv >>> >>> >>> _______________________________________________ Geopriv mailing >>> list Geopriv@ietf.org >>> https://www1.ietf.org/mailman/listinfo/geopriv >> >> -------------------------------------------------------------- >> ---------------------------------- This message is for the >> designated recipient only and may contain privileged, proprietary, >> or otherwise private information. If you have received it in error, >> please notify the sender immediately and delete the original. Any >> unauthorized use of this email is prohibited. >> -------------------------------------------------------------- >> ---------------------------------- [mf2] >> > > > _______________________________________________ Geopriv mailing list > Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 09:33:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3C9D-0004uW-8M; Wed, 19 Jul 2006 09:31:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3C9B-0004ty-SL; Wed, 19 Jul 2006 09:31:29 -0400 Received: from smail3.alcatel.fr ([62.23.212.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3C9A-0002S4-AF; Wed, 19 Jul 2006 09:31:29 -0400 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k6JDVLcJ030253; Wed, 19 Jul 2006 15:31:21 +0200 Received: from [139.54.131.75] (nx1075.nextenso.alcatel.fr [139.54.131.75]) by missrv1.nextenso.alcatel.fr (8.13.5/8.12.8) with ESMTP id k6JDVKDG030649; Wed, 19 Jul 2006 15:31:20 +0200 Message-ID: <44BE3426.3050502@alcatel.fr> Date: Wed, 19 Jul 2006 15:31:18 +0200 From: Thomas Froment User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Silvestr.Peknik@tietoenator.com, sip@ietf.org References: <3ACC9A25264A684F82C71840111F979801EC5E54@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F979801EC5E54@carrera.eu.tieto.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Milan.Kunc@tietoenator.com, simple@ietf.org Subject: [Sip] Re: [Simple] UDP - what if response is bigger than 1500 bytes (ethernet MTU)? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Silvestr.Peknik@tietoenator.com wrote: > Hello, > > Could someone help me with following problem? > > I am not sure what should be done when the response to SIP request sent > over UDP is bigger than 1500 bytes? It can happen e.g. when PUBBLISH > request is responded by 415 Unsupported Media Type and Accept, > Accept-Encoding and Accept-Language headers are added. > This is a good question: I think it was mentionned in last SIP WG IETF meeting that having responses greater than path MTU (-200 bytes) in SIP was not currently well specified. It was an open issue on draft-ietf-sip-hop-limit-diagnostics-03.txt which raises this problem since it leads naturally to send big SIP responses. SIP WG people may probably answer you if something is planned to handle this problem... Thomas > Thank you, > Silvestr Peknik > > Extract from RFC3261: > 18.1.1 Sending requests: > ... > If a request is within 200 bytes of the path MTU, or if it is larger > than 1300 bytes and the path MTU is unknown, the request MUST be sent > using an RFC 2914 [43] congestion controlled transport protocol, such > as TCP. If this causes a change in the transport protocol from the > one indicated in the top Via, the value in the top Via MUST be > changed. This prevents fragmentation of messages over UDP and > provides congestion control for larger messages. However, > implementations MUST be able to handle messages up to the maximum > datagram packet size. For UDP, this size is 65,535 bytes, including > IP and UDP headers. > > The 200 byte "buffer" between the message size and the MTU > accommodates the fact that the response in SIP can be larger than > the request. This happens due to the addition of Record-Route > header field values to the responses to INVITE, for example. With > the extra buffer, the response can be about 170 bytes larger than > the request, and still not be fragmented on IPv4 (about 30 bytes > is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when > path MTU is not known, based on the assumption of a 1500 byte > Ethernet MTU. > ... > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 09:57:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3CWC-0006YK-PZ; Wed, 19 Jul 2006 09:55:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3CWA-0006YF-W3 for sip@ietf.org; Wed, 19 Jul 2006 09:55:14 -0400 Received: from omr6.networksolutionsemail.com ([205.178.146.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3CW9-0003dj-9N for sip@ietf.org; Wed, 19 Jul 2006 09:55:14 -0400 Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k6JDtCrn020290 for ; Wed, 19 Jul 2006 09:55:12 -0400 Received: (qmail 30490 invoked by uid 78); 19 Jul 2006 13:55:06 -0000 Received: from unknown (HELO ?210.5.103.179?) (joegen@opensipstack.org@210.5.103.179) by 10.49.36.69 with SMTP; 19 Jul 2006 13:55:06 -0000 Message-ID: <44BE39A4.4030404@opensipstack.org> Date: Wed, 19 Jul 2006 21:54:44 +0800 From: "Joegen E. Baclor" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Retesh Chadha Subject: Re: [Sip] How to reject a binding for REGISTER References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think the Registrar should just accept the binding. Registars and proxies are not always the same application. The decision what transport to be used to contact the registered user is between the Proxy and the caller, not between the Registrar and the registered user. Retesh Chadha wrote: > > Hi > I didnt find this mentioned in RFC 3261 and so this means that its > upto the particular Registrar implementation. > But I think it should send 200 ok with the current bindings (ie > omitting the un-acceptable contact). 200 ok is the only appropriate > response here, because REGISTER request is valid and atleast one > contact is accepted by the Registrar. > > Regards > Retesh > > > > *Udit_Goyal@3com.com* > > 07/19/2006 10:38 AM > > > To > sip@ietf.org > cc > sip-implementors@cs.columbia.edu > Subject > [Sip] How to reject a binding for REGISTER > > > > > > > > > > > Hi, > > If registrar receives a REGISTER request with two Contact headers, and > registrar wants to register only one binding, > how it can indicate this in the response message (should it omit the > Contact header not supported in 200 ok response) > > One scenario happening is UAC sending two Contact headers with same IP > and port but protocol as TCP and UDP, but server does not support TCP, > so it want to only create binding for UDP Contact header, so it wants > to indicate to UAC that it has created only one binding. > > Thanks, > Udit _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > *********************** FSS-Unclassified *********************** > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 11:39:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3E7G-0000am-0R; Wed, 19 Jul 2006 11:37:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3E7D-0000Zl-R8 for Sip@ietf.org; Wed, 19 Jul 2006 11:37:35 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3E47-0003Oj-H4 for Sip@ietf.org; Wed, 19 Jul 2006 11:34:24 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6JFYLhQ012769; Wed, 19 Jul 2006 10:34:21 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ98D5Z>; Wed, 19 Jul 2006 16:34:20 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290995@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Fatih \"Ey|p\" NAR'" , "Drage, Keith (Keith)" , "\"'Antsnio\" Manuel Amaral'" , "'Sip@ietf.org'" Subject: RE: [Sip] S-CSCF expected behavior Date: Wed, 19 Jul 2006 16:34:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Unless I have misread your question, then RFC 4028, as previously = indicated, is your only mechanism on active calls. regards Keith > -----Original Message----- > From: Fatih "Ey|p" NAR [mailto:fenar@yahoo.com] > Sent: 17 July 2006 16:20 > To: Drage, Keith (Keith); "'Antsnio" Manuel Amaral'; 'Sip@ietf.org' > Subject: RE: [Sip] S-CSCF expected behavior >=20 >=20 > what about active sessions (INVITE transaction > completed successfully with 200OK-ACK previously) on > S-CSCF? >=20 > ex: For the prepaid customer type once the connection > dropped between AS and S-CSCF only way to prevent - > "minus" credit is to end the session with BYE by S-. >=20 >=20 >=20 > --- "Drage, Keith (Keith)" wrote: >=20 > > To make this directly relevant to SIP, the IMS > > S-CSCF behaves exactly as specified in RFC 3261. If > > it has a pending transaction, then section 16.8 and > > section 16.9 of RFC 3261 apply.=20 > >=20 > > The session timer (RFC 4028) may optionally be used > > by any of the IMS entities that behave as a SIP > > proxy. > >=20 > > regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: Ant=F3nio Manuel Amaral > > [mailto:antonio-mn-amaral@ptinovacao.pt] > > > Sent: 14 July 2006 11:17 > > > To: Sip@ietf.org > > > Subject: [Sip] S-CSCF expected behavior > > >=20 > > >=20 > > >=20 > > > Dear All, > > >=20 > > > I don't know if this is the correct mailing list > > to put my=20 > > > question and if not my apologies for that. > > >=20 > > > Consider the following IMS scenario > > >=20 > > >=20 > > > (IMS core Network) -> S-CSCF -> AS > > >=20 > > >=20 > > > If the connection between AS and S-CSCF fails what > > is the=20 > > > expected behavior of S-CSCF? It must release all > > active calls=20 > > > sending BYE messages to caller and called clients > > in order to=20 > > > terminate the calls? > > >=20 > > > Thanks in advance > > >=20 > > > Regards > > >=20 > > > AA=20 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list=20 > > https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP > > Protocol > > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > > Use sipping@ietf.org for new developments on the > > application of sip > > >=20 > >=20 > > _______________________________________________ > > Sip mailing list=20 > > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > > Protocol > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > Use sipping@ietf.org for new developments on the > > application of sip > >=20 >=20 >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around=20 > http://mail.yahoo.com=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 11:52:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EKC-0005k6-7M; Wed, 19 Jul 2006 11:51:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x45-0001UO-AE; Tue, 18 Jul 2006 17:25:13 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2x43-0000p0-3M; Tue, 18 Jul 2006 17:25:13 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 18 Jul 2006 17:25:20 -0400 id 0158800A.44BD51C1.00005611 Message-ID: <44BD51AC.8030306@hxr.us> Date: Tue, 18 Jul 2006 17:25:00 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Brian Rosen References: <0aca01c6aa69$33aecea0$bc1cdb84@cis.neustar.com> In-Reply-To: <0aca01c6aa69$33aecea0$bc1cdb84@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Wed, 19 Jul 2006 11:50:58 -0400 Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] Re: [Geopriv] SIP Location Conveyance: dereferencing location-by-reference X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Rosen wrote: > In sip-location-conveyance, we allow a URI in the Location header to provide > for location-by-reference. We must have some kind of text that says what > the recipient does with this URI. > > Our proposal is to change the ABNF, which currently allows this URI to be > AbsoluteURI (meaning any scheme) and replace it with HTTP/HTTPS only. Of > course, there would still be the cid: for message body identification. We > would then define a dereference process as doing an HTTP/HTTPS GET, with no > parameters, on the URI, and expect to receive in return a PIDF-LO, exactly > as it would appear in a body. The text would state MUST implement TLS, > except for the emergency case. The text would further state that additional > dereferencing procedures could be defined by a standards track RFC. I'm not sure it is as simple as this. What happens when a client gets a subscribable location reference URI via the L7-LCP, and puts that into a Location header in an INVITE? How is the subscription done with HTTP? -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 11:53:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EKc-00062d-1x; Wed, 19 Jul 2006 11:51:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pHb-0001Lc-LY; Tue, 18 Jul 2006 09:06:39 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2pHa-0000Gw-Dt; Tue, 18 Jul 2006 09:06:39 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6ID6W9Q004913; Tue, 18 Jul 2006 13:06:32 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 09:06:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jul 2006 09:06:31 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Location-by-value in a SIP Location Header Thread-Index: Acaqaf7jfWewMixZS0itJGlcoxIm1QAAGogQ From: "Rosen, Brian" To: "Henning Schulzrinne" X-OriginalArrivalTime: 18 Jul 2006 13:06:32.0773 (UTC) FILETIME=[FDC96F50:01C6AA6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Wed, 19 Jul 2006 11:51:25 -0400 Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Perhaps some enlightenment is in order. It's not clear to me how you dsig a Data uri in a Location header (or maybe you mean dsig the pidf-lo and put both the pidf-lo and the signature in the Data URI) somehow? Are there some examples of this kind of thing elsewhere? If we are ignoring technical arguments (as opposed to use cases), it's out of forgetfulness, and not willfulness. What were you referring to? Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Tuesday, July 18, 2006 8:59 AM To: Rosen, Brian Cc: sip@ietf.org; geopriv@ietf.org Subject: Re: [Geopriv] Location-by-value in a SIP Location Header Brian, James: this is simply false. If desired, XML-DSIG is a well-known and =20 accepted mechanism to achieve integrity. Such specification is no =20 longer than the MUST NOT that you propose. You are also willfully =20 ignoring the other technical arguments made as part of this discussion. Henning On Jul 18, 2006, at 8:48 AM, Rosen, Brian wrote: > There was a desire expressed by Hannes to provide a way for a proxy to > insert location-by-value. He had proposed a SIP Location header > specific way. In IETF66, Henning suggested just using a data URI. > > Doing this may run afoul of the geopriv location privacy concerns, > because there is no way for the user to sign the header to provide > assurance that the PIDF, and specifically the retention and other =20 > policy > bits are preserved. Note that S/MIME provides sufficient integrity > protection for a body. It's probably okay to use TLS per hop to =20 > provide > privacy, but not integrity protection. The authors believe that there > is no really compelling use case for this feature, and the effort to > define acceptable security mechanisms for location data in a header > would be a significant effort, further delaying the draft. > > We propose, therefore, to state in sip-location-conveyance, that a =20 > Data > URI MUST NOT be used in the Location header until a standards track =20 > RFC > defines a suitable security mechanism to protect the PIDF in the =20 > header. > > Brian and James > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 11:53:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EKy-0006DD-70; Wed, 19 Jul 2006 11:51:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G34Zq-0001ms-MY for sip@ietf.org; Wed, 19 Jul 2006 01:26:30 -0400 Received: from smtpauth00.csee.siteprotect.com ([64.41.126.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G34Zo-0002tT-E3 for sip@ietf.org; Wed, 19 Jul 2006 01:26:30 -0400 Received: from gkhetarpallt1 (unknown [221.134.154.130]) by smtpauth00.csee.siteprotect.com (Postfix) with ESMTP id 9F79832C01C; Wed, 19 Jul 2006 00:26:26 -0500 (CDT) From: "Gaurav Kheterpal" To: , Date: Wed, 19 Jul 2006 10:57:51 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acaq8PZv844rjmdqRPKmXL5YT1D/ugAAboDQ Message-Id: <20060719052626.9F79832C01C@smtpauth00.csee.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-Mailman-Approved-At: Wed, 19 Jul 2006 11:51:46 -0400 Cc: sip-implementors@cs.columbia.edu Subject: [Sip] RE: [Sip-implementors] How to reject a binding for REGISTER X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Refer to Section 10.2.1 in RFC 3261: "The 2xx response to the REGISTER request will contain, in a Contact header field, a complete list of bindings that have been registered for this address-of-record at this registrar." The registrar will only add those URIs in the Contact headers for 200 OK for which it has been successfully been able to create a AOR binding. As for the differentiation between TCP & UDP, I think it can be done in a way similar to the original INVITE request: Contact:..@<...>;transport=udp If the registrar does not support TCP, it will not add the corresponding CONTACT header in 200 OK. A similar thread for INVITE might help: https://lists.cs.columbia.edu/pipermail/sip-implementors/2004-July/006694.ht ml I hope this helps. Regards, Gaurav -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Udit_Goyal@3com.com Sent: Wednesday, July 19, 2006 10:38 AM To: sip@ietf.org Cc: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] How to reject a binding for REGISTER Hi, If registrar receives a REGISTER request with two Contact headers, and registrar wants to register only one binding, how it can indicate this in the response message (should it omit the Contact header not supported in 200 ok response) One scenario happening is UAC sending two Contact headers with same IP and port but protocol as TCP and UDP, but server does not support TCP, so it want to only create binding for UDP Contact header, so it wants to indicate to UAC that it has created only one binding. Thanks, Udit _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 11:54:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ELl-0006ZH-7j; Wed, 19 Jul 2006 11:52:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3CA1-0005Gh-90; Wed, 19 Jul 2006 09:32:21 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3C9z-0002Tk-L6; Wed, 19 Jul 2006 09:32:21 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 19 Jul 2006 06:32:19 -0700 X-IronPort-AV: i="4.06,260,1149490800"; d="scan'208"; a="306676936:sNHT28745296" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6JDWJDf002957; Wed, 19 Jul 2006 06:32:19 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6JDWIHU026089; Wed, 19 Jul 2006 06:32:18 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 09:32:18 -0400 Received: from mlinsnerwxp ([161.44.11.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 09:32:17 -0400 From: "Marc Linsner" To: "'Drage, Keith \(Keith\)'" Date: Wed, 19 Jul 2006 09:32:15 -0400 Message-ID: <008601c6ab37$c020bdc0$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C29098F@en0033exch001u.uk.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcarL/w4VS2bMVseQhqjXfhnEB5w0gABQzmQ X-OriginalArrivalTime: 19 Jul 2006 13:32:18.0025 (UTC) FILETIME=[C13DED90:01C6AB37] DKIM-Signature: a=rsa-sha1; q=dns; l=7166; t=1153315939; x=1154179939; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Geopriv]=20Location-by-value=20in=20a=20SIP=20Location=20Header; X=v=3Dcisco.com=3B=20h=3DL/nJ7eSYCu2yHFSsS4GWRmfiU0E=3D; b=HaCb5QXWs9ZmE5Qc3PXp9L917IPbFAcRaQOS7p5LudKRQo29Yg8xNvRg5awj04ZjE84ozAjH lCHBeUS3kf8NmT+FDNWs2hJd8c32m5xHoZ1iBbs/tfByvF4092UMRZij; Authentication-Results: sj-dkim-5.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-Mailman-Approved-At: Wed, 19 Jul 2006 11:52:35 -0400 Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keith, A couple of issues with your statements below: - As you point out in #2, the SIP group has identified two mechanisms, location by value in the body and location by reference in the header. The issue stems from the fact that location by reference is yet to be a mechanism. This has been mired down with technical discussions in GeoPriv for a long time. - Your list of reasons needs to be expanded to include 'the identified mechanism has no technical solution'. As you express, there are many reasons to complete this work quickly, but to have a total solution it is important to examine these alternatives mechanisms. Like you, I certainly hope this comes to a resolution very soon. Thanks, -Marc- > > (As SIP WG chair) > > Just to set some limits to this discussion, let me state > where we are in the progression of this work item. Remember > it is now being classed as urgent and we need to get an RFC > out of the door, and the SIP chairs are working with the > GEOPRIV chairs as to the quickest way to do this: > > 1) The requirements in the document have been approved by > the SIPPING group (a long time ago) and therefore we should > not be inventing new requirements without a clear use case > that has clear agreement. > > 2) The SIP group have already identified that two > mechanisms to support these requirements should be documented > (e.g. the location by value in a body, and the location by > reference in a header. These two mechanisms appear to support > all the current requirements. In other words, SIP have agreed > the technical solution, and we are in the stage of trying to > document it. > > 3) Using a data URL appears to add a third mechanism, if > only because it will at least need to have a different set of > security considerations documented for it. > > We should only be adding a third mechanism if: > > a) the existing mechanism can be shown not to meet all the > requirements; or > b) the use case where it offers advantages is clearly > identified; and > c) the compatibility issues are addressed (i.e. does the > UAS need to support all of what is now three mechanisms or is > there some other support requirement); and > d) this can be shown as impossible to be discussed as a > future extension. > > Could I also suggest (in addition to the above) that if > people want to proceed with this discussion, it would be > appropriate to submit an i-d targeted at the SIP WG > identifying the technical solution proposed (with as much > completeness as is possible). And remember if you think this > discussion is needed, it needs to occur quickly. > > regards > > Keith > > > -----Original Message----- > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > Sent: 19 July 2006 00:15 > > To: Rosen, Brian; Henning Schulzrinne > > Cc: sip@ietf.org; geopriv@ietf.org > > Subject: RE: [Geopriv] Location-by-value in a SIP Location Header > > > > > > If you want technically feasible, I can post a URI to the list that > > includes a complete PIDF-LO with DSig. It's a little long though. > > > > I'm not suggesting that this a good idea, but I see no reason to > > prevent it. > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > Sent: Tuesday, 18 July 2006 11:07 PM > > > To: Henning Schulzrinne > > > Cc: sip@ietf.org; geopriv@ietf.org > > > Subject: RE: [Geopriv] Location-by-value in a SIP Location Header > > > > > > Perhaps some enlightenment is in order. It's not clear to > > me how you > > > dsig a Data uri in a Location header (or maybe you mean > > dsig the pidf-lo > > > and put both the pidf-lo and the signature in the Data > URI) somehow? > > > Are there some examples of this kind of thing elsewhere? > > > > > > If we are ignoring technical arguments (as opposed to use > > cases), it's > > > out of forgetfulness, and not willfulness. What were you > > referring to? > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Tuesday, July 18, 2006 8:59 AM > > > To: Rosen, Brian > > > Cc: sip@ietf.org; geopriv@ietf.org > > > Subject: Re: [Geopriv] Location-by-value in a SIP Location Header > > > > > > Brian, James: > > > > > > this is simply false. If desired, XML-DSIG is a well-known and > > > accepted mechanism to achieve integrity. Such specification is no > > > longer than the MUST NOT that you propose. You are also willfully > > > ignoring the other technical arguments made as part of this > > discussion. > > > > > > Henning > > > > > > On Jul 18, 2006, at 8:48 AM, Rosen, Brian wrote: > > > > > > > There was a desire expressed by Hannes to provide a way > > for a proxy to > > > > insert location-by-value. He had proposed a SIP > Location header > > > > specific way. In IETF66, Henning suggested just using > a data URI. > > > > > > > > Doing this may run afoul of the geopriv location > privacy concerns, > > > > because there is no way for the user to sign the header > to provide > > > > assurance that the PIDF, and specifically the retention > and other > > > > policy bits are preserved. Note that S/MIME provides sufficient > > integrity > > > > protection for a body. It's probably okay to use TLS > per hop to > > > > provide privacy, but not integrity protection. The authors > > believe that there > > > > is no really compelling use case for this feature, and > > the effort to > > > > define acceptable security mechanisms for location data > > in a header > > > > would be a significant effort, further delaying the draft. > > > > > > > > We propose, therefore, to state in > sip-location-conveyance, that a > > > > Data URI MUST NOT be used in the Location header until a > > standards track > > > > RFC > > > > defines a suitable security mechanism to protect the > PIDF in the > > > > header. > > > > > > > > Brian and James > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > immediately > > and delete the original. Any unauthorized use of this email is > > prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 12:31:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Evo-00023V-Ed; Wed, 19 Jul 2006 12:29:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Evm-00021d-EU; Wed, 19 Jul 2006 12:29:50 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Evl-0002bB-33; Wed, 19 Jul 2006 12:29:50 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 19 Jul 2006 09:29:49 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6JGTmat017413; Wed, 19 Jul 2006 09:29:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6JGTl7H023065; Wed, 19 Jul 2006 09:29:48 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Jul 2006 09:29:48 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.81.245]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 09:29:47 -0700 Message-Id: <4.3.2.7.2.20060719112337.028a2578@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2006 11:29:45 -0500 To: Andrew Newton , Brian Rosen From: "James M. Polk" Subject: Re: [Sip] Re: [Geopriv] SIP Location Conveyance: dereferencing location-by-reference In-Reply-To: <44BD51AC.8030306@hxr.us> References: <0aca01c6aa69$33aecea0$bc1cdb84@cis.neustar.com> <0aca01c6aa69$33aecea0$bc1cdb84@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 19 Jul 2006 16:29:47.0866 (UTC) FILETIME=[8D0AB3A0:01C6AB50] DKIM-Signature: a=rsa-sha1; q=dns; l=1839; t=1153326588; x=1154190588; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20Re=3A=20[Geopriv]=20SIP=20Location=20Conveyance=3A=0A=20 =20dereferencing=09location-by-reference; X=v=3Dcisco.com=3B=20h=3D1KBT/kgYMoBQgzw83y7YxXnsnRo=3D; b=wiD0B33ULnGVBXxaHBDTHpv5LkQQyv30DFdBqD4Y+kQJEXCV5zPQGzgKgc73+jRnQWjDfq6T zzBUXXfu7xzzuWfdudXcuFc0JVcceVWkhiqdokPy2F1JGKZErgrSacKz; Authentication-Results: sj-dkim-8.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 05:25 PM 7/18/2006 -0400, Andrew Newton wrote: >Brian Rosen wrote: >>In sip-location-conveyance, we allow a URI in the Location header to provide >>for location-by-reference. We must have some kind of text that says what >>the recipient does with this URI. >>Our proposal is to change the ABNF, which currently allows this URI to be >>AbsoluteURI (meaning any scheme) and replace it with HTTP/HTTPS only. Of >>course, there would still be the cid: for message body identification. We >>would then define a dereference process as doing an HTTP/HTTPS GET, with no >>parameters, on the URI, and expect to receive in return a PIDF-LO, exactly >>as it would appear in a body. The text would state MUST implement TLS, >>except for the emergency case. The text would further state that additional >>dereferencing procedures could be defined by a standards track RFC. > >I'm not sure it is as simple as this. > >What happens when a client gets a subscribable location reference URI via >the L7-LCP, you mean a SIP or SIPS URI? You expect SIP to be a dereference capable protocol? Why? >and puts that into a Location header in an INVITE? INVITEs don't do subscriptions, SUBSCRIBEs do, so this L7 value put into a Location header that's in an INVITE wouldn't create a subscription in the first place. The above offering is to make sure dereferencing is done with HTTP/HTTPS, not SIP. > How is the subscription done with HTTP? It isn't done with an INVITE either. sorry... >-andy > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 13:00:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FNX-000078-Du; Wed, 19 Jul 2006 12:58:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FNV-00006x-Uf for sip@ietf.org; Wed, 19 Jul 2006 12:58:29 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3FNU-0006l6-L2 for sip@ietf.org; Wed, 19 Jul 2006 12:58:29 -0400 Received: from [192.168.2.109] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6JH0NKP013470 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 19 Jul 2006 12:00:24 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP WG List From: Dean Willis Date: Wed, 19 Jul 2006 11:57:44 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Sip] Notes on SIP at IETF 66 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've posted the raw notes from the recorders of SIP meetings at IETF 66 on our supplemental site: http://www.softarmor.com/sipwg/meets/ietf66/notes/index.html We'll work these up into minutes. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 13:02:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FPo-0000WU-2t; Wed, 19 Jul 2006 13:00:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FPn-0000V2-85; Wed, 19 Jul 2006 13:00:51 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3FPk-0006uz-TY; Wed, 19 Jul 2006 13:00:51 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6JH0kfB027217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jul 2006 13:00:47 -0400 (EDT) Message-ID: <44BE6543.40203@cs.columbia.edu> Date: Wed, 19 Jul 2006 13:00:51 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Sip] Re: [Geopriv] SIP Location Conveyance: dereferencing location-by-reference References: <0aca01c6aa69$33aecea0$bc1cdb84@cis.neustar.com> <0aca01c6aa69$33aecea0$bc1cdb84@cis.neustar.com> <4.3.2.7.2.20060719112337.028a2578@email.cisco.com> <44BE6301.7080804@hxr.us> In-Reply-To: <44BE6301.7080804@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sip@ietf.org, geopriv@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I suspect we're talking about two different use cases: - proxies will find subscriptions rather tedious when doing call routing (do a SUBSCRIBE, wait for authorization, NOTIFY just to get a location to route a call?), and don't get any benefit from the subscription model; - UASs will find subscriptions helpful, in some limited circumstances (e.g., if I call OnStar for directions, they might want to see where I'm going in real time, rather than where I was five minutes ago while all their agents were busy assisting other customers) I don't see particular security issues as long as the UAC realizes that any subscription URI that it hands out might be used by anybody that is on the call path. In some cases, that's an acceptable model, particularly if the caller identity is obscured, so that you only know that "random caller abc17 is at location X waiting for tow truck". (In that case, subscriptions are probably somewhat pointless.) In short, I think we should allow all of these and simply make sensible recommendations, such as that location information meant for call routing should NOT just use subscriptions and also provide location by-value/by-attachment, simply because location subscriptions are too painful and useless for proxies in practice. Henning Andrew Newton wrote: > James M. Polk wrote: >> At 05:25 PM 7/18/2006 -0400, Andrew Newton wrote: >>> What happens when a client gets a subscribable location reference URI >>> via the L7-LCP, >> >> you mean a SIP or SIPS URI? >> >> You expect SIP to be a dereference capable protocol? Why? > > I actually didn't mention SIP as the dereference protocol. What I am > asking is which dereference protocol with a subscription mechanism are > you going to specify? Or should implementers assume XMPP for this > feature? :) > >>> and puts that into a Location header in an INVITE? >> >> INVITEs don't do subscriptions, SUBSCRIBEs do, so this L7 value put >> into a Location header that's in an INVITE wouldn't create a >> subscription in the first place. > > Thanks for the clarification, but I was talking about the dereference > being orchestrated via subscription rather than polling. I wasn't > really talking about the conveyance itself, other than to ask how a > conveyee is to know what to do with the reference. > >> The above offering is to make sure dereferencing is done with >> HTTP/HTTPS, not SIP. > > I know, which is why I asked... > >>> How is the subscription done with HTTP? > > -andy > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 14:02:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GM0-0005v5-DQ; Wed, 19 Jul 2006 14:01:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GLz-0005uk-KK; Wed, 19 Jul 2006 14:00:59 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3GLx-0002Y9-69; Wed, 19 Jul 2006 14:00:59 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3GJt-0002R8-6d; Wed, 19 Jul 2006 12:58:49 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'James M. Polk'" Subject: RE: [Sip] Re: [Geopriv] SIP Location Conveyance: dereferencing location-by-reference Date: Wed, 19 Jul 2006 13:58:52 -0400 Message-ID: <01ec01c6ab5d$009c7680$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcarU5NizFA3QStHT8WekSsRKg5cRAACD8zQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44BE6301.7080804@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The original message said: The text would further state that additional dereferencing procedures could be defined by a standards track RFC. Therefore, the proposed L7 protocol could specify its own dereference procedure, including a subscription process. We already have the mechanisms needed to get a presence subscription out of an AoR. Given the security concerns about location, it does seem wise to restrict what kind of URI can be a location-by-reference to those that have reviews of the geopriv privacy concerns. I don't think we need to make the mechanism completely general at the outset. We propose to have the basic mechanism be readily extensible by standards track RFCs. That would seem to balance security concerns against utility. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, July 19, 2006 12:51 PM > To: James M. Polk > Cc: Brian Rosen; sip@ietf.org; geopriv@ietf.org > Subject: Re: [Sip] Re: [Geopriv] SIP Location Conveyance: dereferencing > location-by-reference > > James M. Polk wrote: > > At 05:25 PM 7/18/2006 -0400, Andrew Newton wrote: > >> What happens when a client gets a subscribable location reference URI > >> via the L7-LCP, > > > > you mean a SIP or SIPS URI? > > > > You expect SIP to be a dereference capable protocol? Why? > > I actually didn't mention SIP as the dereference protocol. What I am > asking is which dereference protocol with a subscription mechanism are > you going to specify? Or should implementers assume XMPP for this > feature? :) > > >> and puts that into a Location header in an INVITE? > > > > INVITEs don't do subscriptions, SUBSCRIBEs do, so this L7 value put into > > a Location header that's in an INVITE wouldn't create a subscription in > > the first place. > > Thanks for the clarification, but I was talking about the dereference > being orchestrated via subscription rather than polling. I wasn't > really talking about the conveyance itself, other than to ask how a > conveyee is to know what to do with the reference. > > > The above offering is to make sure dereferencing is done with > > HTTP/HTTPS, not SIP. > > I know, which is why I asked... > > >> How is the subscription done with HTTP? > > -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 15:14:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HTD-0002jH-Ua; Wed, 19 Jul 2006 15:12:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HTC-0002j7-K2 for sip@ietf.org; Wed, 19 Jul 2006 15:12:30 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3HTB-0003WG-8o for sip@ietf.org; Wed, 19 Jul 2006 15:12:30 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k6JJCJNG004638; Wed, 19 Jul 2006 14:12:20 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k6JJCEC20307; Wed, 19 Jul 2006 14:12:19 -0500 (CDT) Message-ID: <44BE840E.4090800@lucent.com> Date: Wed, 19 Jul 2006 14:12:14 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: SIP LIST Subject: [Sip] Review of draft-ietf-sip-hop-limit-diagnostics-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Scott: I went through draft-ietf-sip-hop-limit-diagnostics-03; here are my comments on the draft. I went through the existing WG list discussions regarding this draft to make sure that I was not duplicating any items that have already been discussed. To the best of my knowledge, the following have not yet been discussed. 1) In Montreal, I had mentioned to you that the ICMP sends back more than 64 bits of original datagram, and that maybe 64 "bits" was transcribed in error. As it turns out, rfc792 does indeed say 64 bits of orgininal datagram. However, in practice, we have observed far more data is returned from the original datagram than 64-bits. RFC1122 allows implementations to send more than 8 octets (see Section 3.2.2 of rfc1122). So... what we have observed is that Linux returns 520 bytes of the original datagram, and Solaris returns 64 bytes; but for Solaris, this is configurable in the kernel. And ICMPv6 (rfc2463) tries to fit as much of the original datagram without exceeding the minimum IPv6 MTU in the ICMP message. So, what does this all mean to hop-limit-diagnostics-03? Probably no changes, but interesting and relevant background information if you will like to maintain it in the text. 2) Section 3.1, third paragraph talks about removal of "Via and Route headers". I think you meant Record-Route headers instead of (or in addition to?) Route headers. In a dialog-establishing INVITE, there'll be greater chances of Record-Route headers being present than Route headers (which, if they are present consists of a pre-loaded Route set). Moreover, the Route headers would be consumed at every hop thereby reducing the size of the message, whereas the R-R headers are inserted, thus increasing the size. It seems that we ought to preserve the Via headers as much as possible, at the expense of R-R or Route headers. The Vias give diagnostic information on which intermediaries have handled the request, which is of interest. The Route header, on the other hand, portends which intermediary will handle the request beyond the element that generated a 483. 3) Nit: Section 3.1, third paragraph, first sentence is incomplete. It states, "...acceptable; the only exception to this rule is when ." 4) In the SIP messages, headers that continue should be indented (LWS). The Via headers, for instance, contain a branch parameter that begins on a new line without the continuation LWS. 5) Section 5 appears to lay the legal groundwork for why a UAC should accept a response that contains a body for which the UAC did not express an interest in receiving. I think this is good to have. I would change the first sentence of the second paragraph to read as follows: Note that a UAC MUST be prepared to receive message bodies that it does not understand and did not request in a response; this is ... That is, move the object of what the UAC must be prepared to do closer to the UAC. 6) In Section 6, it appears that the 483 response has been pruned, although the text does not indicate so. By my count, if the UAC started with a M-F of 9, then it should have 9 Via headers, whereas the example shows the number of Via headers to be 7. You may just want to simply mention that the request has been pruned in the response. Other than that, I am glad that the draft is out -- need this stuff. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 15:19:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HYM-0003Iz-OY; Wed, 19 Jul 2006 15:17:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HYL-0003Ir-3n for sip@ietf.org; Wed, 19 Jul 2006 15:17:49 -0400 Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3HYJ-0004vF-Rd for sip@ietf.org; Wed, 19 Jul 2006 15:17:49 -0400 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k6JJHlx10382 for ; Wed, 19 Jul 2006 14:17:47 -0500 Date: Wed, 19 Jul 2006 14:17:47 -0500 Message-Id: <200607191917.k6JJHlx10382@smapp01.siteprotect.com> From: fwmiller@cornfed.com To: sip@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] SIP Security mechanism? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've been reading about the ZRTP lately. I read Henning's comment at the IETF meeting about how S/MIME relies on the receiver's public key to be available to allow for encryption/decryption to work. Why couldnt we put in place a mechanism that did a key exchange for SIP signaling similar to whats done in ZRTP (i.e. modified Diffie-Hellman) prior to any signaling traffic, then use the exchanged keys as the basis for S/MIME encryption of the bodies? Or we could even get really carried away and use it to do encryption of the entire SIP message if the signaling did not traverse proxies? This could be useful for encrypting UDP signaling, again if no proxy were involved. Thoughts? FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 15:31:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Hjq-0004Xm-IH; Wed, 19 Jul 2006 15:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FNB-0008V1-Mt; Wed, 19 Jul 2006 12:58:09 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3FNA-0006bq-Gz; Wed, 19 Jul 2006 12:58:09 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Wed, 19 Jul 2006 12:58:20 -0400 id 01588015.44BE64AC.00002CDC Message-ID: <44BE6498.4090801@hxr.us> Date: Wed, 19 Jul 2006 12:58:00 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Thomson, Martin" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Wed, 19 Jul 2006 15:29:39 -0400 Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] Re: [Geopriv] SIP Location Conveyance:dereferencing location-by-reference X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thomson, Martin wrote: > Discussions to date on a subscription URI indicate that it is for LIS -> Target purposes only. We have not yet reached the point where we discuss the creation of a reference. There are obvious similarities, but I think that we would need to resolve some privacy and security concerns first. Excuse me for not understanding, but LIS -> Target seems to miss the need outlined in the use case given on the L7-LCP DT list... which is a mobile device that has a link that very much looks like a fixed wired connection (and LI is derived from the network, i.e. not GPS). -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 15:31:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Hjp-0004XB-Rp; Wed, 19 Jul 2006 15:29:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FGc-0007Bk-OV; Wed, 19 Jul 2006 12:51:22 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3FGb-0004Z0-Hr; Wed, 19 Jul 2006 12:51:22 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Wed, 19 Jul 2006 12:51:33 -0400 id 01588015.44BE6315.00002AE0 Message-ID: <44BE6301.7080804@hxr.us> Date: Wed, 19 Jul 2006 12:51:13 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Sip] Re: [Geopriv] SIP Location Conveyance: dereferencing location-by-reference References: <0aca01c6aa69$33aecea0$bc1cdb84@cis.neustar.com> <0aca01c6aa69$33aecea0$bc1cdb84@cis.neustar.com> <4.3.2.7.2.20060719112337.028a2578@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060719112337.028a2578@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Wed, 19 Jul 2006 15:29:39 -0400 Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James M. Polk wrote: > At 05:25 PM 7/18/2006 -0400, Andrew Newton wrote: >> What happens when a client gets a subscribable location reference URI >> via the L7-LCP, > > you mean a SIP or SIPS URI? > > You expect SIP to be a dereference capable protocol? Why? I actually didn't mention SIP as the dereference protocol. What I am asking is which dereference protocol with a subscription mechanism are you going to specify? Or should implementers assume XMPP for this feature? :) >> and puts that into a Location header in an INVITE? > > INVITEs don't do subscriptions, SUBSCRIBEs do, so this L7 value put into > a Location header that's in an INVITE wouldn't create a subscription in > the first place. Thanks for the clarification, but I was talking about the dereference being orchestrated via subscription rather than polling. I wasn't really talking about the conveyance itself, other than to ask how a conveyee is to know what to do with the reference. > The above offering is to make sure dereferencing is done with > HTTP/HTTPS, not SIP. I know, which is why I asked... >> How is the subscription done with HTTP? -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 15:31:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Hjr-0004YM-CN; Wed, 19 Jul 2006 15:29:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Fva-0001Oz-Vq; Wed, 19 Jul 2006 13:33:42 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3FvZ-0000TM-Q0; Wed, 19 Jul 2006 13:33:42 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Wed, 19 Jul 2006 13:28:48 -0400 id 015880B3.44BE6BD0.000033BE Message-ID: <44BE6BBC.5000408@hxr.us> Date: Wed, 19 Jul 2006 13:28:28 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Sip] Re: [Geopriv] SIP Location Conveyance: dereferencing location-by-reference References: <0aca01c6aa69$33aecea0$bc1cdb84@cis.neustar.com> <0aca01c6aa69$33aecea0$bc1cdb84@cis.neustar.com> <4.3.2.7.2.20060719112337.028a2578@email.cisco.com> <44BE6301.7080804@hxr.us> <44BE6543.40203@cs.columbia.edu> In-Reply-To: <44BE6543.40203@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Wed, 19 Jul 2006 15:29:39 -0400 Cc: sip@ietf.org, geopriv@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Henning Schulzrinne wrote: > > In short, I think we should allow all of these and simply make sensible > recommendations, such as that location information meant for call > routing should NOT just use subscriptions and also provide location > by-value/by-attachment, simply because location subscriptions are too > painful and useless for proxies in practice. Agreed. And I'm not advocating that subscription is the only method, it was just my understanding that there was a desire to have it. What I would like is a small list of things I need to implement. AbsoluteURI leaves the number of possibilities wide open. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 15:39:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Hro-0005rQ-2e; Wed, 19 Jul 2006 15:37:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Hrn-0005rK-IB for sip@ietf.org; Wed, 19 Jul 2006 15:37:55 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3Hrk-0000Ek-3W for sip@ietf.org; Wed, 19 Jul 2006 15:37:55 -0400 Received: (qmail invoked by alias); 19 Jul 2006 19:37:50 -0000 Received: from p54985EF9.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.94.249] by mail.gmx.net (mp033) with SMTP; 19 Jul 2006 21:37:50 +0200 X-Authenticated: #29516787 Message-ID: <44BE8A0B.5090401@gmx.net> Date: Wed, 19 Jul 2006 21:37:47 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fwmiller@cornfed.com Subject: Re: [Sip] SIP Security mechanism? References: <200607191917.k6JJHlx10382@smapp01.siteprotect.com> In-Reply-To: <200607191917.k6JJHlx10382@smapp01.siteprotect.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If you run a DH then the outcome is a symmetric key. S/MIME does not work with symmetric keys. Ciao Hannes fwmiller@cornfed.com wrote: > I've been reading about the ZRTP lately. I read Henning's comment at > the IETF meeting about how S/MIME relies on the receiver's public key > to be available to allow for encryption/decryption to work. > > Why couldnt we put in place a mechanism that did a key exchange for > SIP signaling similar to whats done in ZRTP (i.e. modified > Diffie-Hellman) prior to any signaling traffic, then use the > exchanged keys as the basis for S/MIME encryption of the bodies? Or > we could even get really carried away and use it to do encryption of > the entire SIP message if the signaling did not traverse proxies? > This could be useful for encrypting UDP signaling, again if no proxy > were involved. > > Thoughts? FM > > > _______________________________________________ Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 15:48:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3I0H-0000i5-VS; Wed, 19 Jul 2006 15:46:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3I0G-0000i0-H4 for sip@ietf.org; Wed, 19 Jul 2006 15:46:40 -0400 Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3I0F-0001zE-8b for sip@ietf.org; Wed, 19 Jul 2006 15:46:40 -0400 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k6JJkZx12177; Wed, 19 Jul 2006 14:46:35 -0500 Date: Wed, 19 Jul 2006 14:46:35 -0500 Message-Id: <200607191946.k6JJkZx12177@smapp01.siteprotect.com> From: fwmiller@cornfed.com To: "Hannes Tschofenig" , fwmiller@cornfed.com Subject: Re: [Sip] SIP Security mechanism? X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The idea is the general concept of doing some kind of key exchange between the UAs prior to doing signaling. This would address the problem of maintaining the public key infrastructure. If that particular algorithm and key set does not work, perhaps some algoritm that had the "UAS" generate an asymmetric public key dynamically would work. The key exchange could be for each endpoint to have the other endpoint generate an asymmetric key? I'm not a crypto person but this seems like it might be doable, does any crypto person here know of how that could be done? FM ------------------------------------------------ On Wed, 19 Jul 2006 21:37:47 +0200, Hannes Tschofenig wrote: > If you run a DH then the outcome is a symmetric key. S/MIME does not > work with symmetric keys. > > Ciao > Hannes > > fwmiller@cornfed.com wrote: > > I've been reading about the ZRTP lately. I read Henning's comment at > > the IETF meeting about how S/MIME relies on the receiver's public key > > to be available to allow for encryption/decryption to work. > > > > Why couldnt we put in place a mechanism that did a key exchange for > > SIP signaling similar to whats done in ZRTP (i.e. modified > > Diffie-Hellman) prior to any signaling traffic, then use the > > exchanged keys as the basis for S/MIME encryption of the bodies? Or > > we could even get really carried away and use it to do encryption of > > the entire SIP message if the signaling did not traverse proxies? > > This could be useful for encrypting UDP signaling, again if no proxy > > were involved. > > > > Thoughts? FM > > > > > > _______________________________________________ Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > > development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 15:49:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3I0w-00012v-Os; Wed, 19 Jul 2006 15:47:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3I0u-00012g-Ul; Wed, 19 Jul 2006 15:47:20 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3I0t-00021Y-JL; Wed, 19 Jul 2006 15:47:20 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 19 Jul 2006 12:47:20 -0700 X-IronPort-AV: i="4.06,260,1149490800"; d="scan'208"; a="435268842:sNHT27105404" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6JJlIwf022607; Wed, 19 Jul 2006 12:47:18 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6JJlIiB014937; Wed, 19 Jul 2006 12:47:18 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 12:47:18 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.81.245]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 12:47:18 -0700 Message-Id: <4.3.2.7.2.20060719143558.03a1dc88@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2006 14:46:51 -0500 To: Andrew Newton From: "James M. Polk" Subject: Re: [Sip] Re: [Geopriv] SIP Location Conveyance: dereferencing location-by-reference In-Reply-To: <44BE6301.7080804@hxr.us> References: <4.3.2.7.2.20060719112337.028a2578@email.cisco.com> <0aca01c6aa69$33aecea0$bc1cdb84@cis.neustar.com> <0aca01c6aa69$33aecea0$bc1cdb84@cis.neustar.com> <4.3.2.7.2.20060719112337.028a2578@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 19 Jul 2006 19:47:18.0218 (UTC) FILETIME=[2466EAA0:01C6AB6C] DKIM-Signature: a=rsa-sha1; q=dns; l=1789; t=1153338438; x=1154202438; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20Re=3A=20[Geopriv]=20SIP=20Location=20Conveyance=3A=0A=20 =20dereferencing=09location-by-reference; X=v=3Dcisco.com=3B=20h=3D1KBT/kgYMoBQgzw83y7YxXnsnRo=3D; b=MXBM9YcoMF6qy31S/vf7FXOwIDu0KYwNecklVW+u7/7iZnZfk22CvN+XX+PWbAjgYjqo1oFI HRGnzPzM1VAfEIt/m7XIo0g2bPHdgPlDkd2LZe7eORDU+bz21uXaSphW; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 12:51 PM 7/19/2006 -0400, Andrew Newton wrote: >James M. Polk wrote: >>At 05:25 PM 7/18/2006 -0400, Andrew Newton wrote: >>>What happens when a client gets a subscribable location reference URI >>>via the L7-LCP, >>you mean a SIP or SIPS URI? >>You expect SIP to be a dereference capable protocol? Why? > >I actually didn't mention SIP as the dereference protocol. you mentioned subscriptions, and sip-location-conveyance doesn't, but SIP does with SUBSCRIBE - so I made that leap. Why do you want a subscription, and where's the requirement for that? The ID currently doesn't have one. >What I am asking is which dereference protocol with a subscription >mechanism are you going to specify? Or should implementers assume XMPP >for this feature? :) > >>>and puts that into a Location header in an INVITE? >>INVITEs don't do subscriptions, SUBSCRIBEs do, so this L7 value put into >>a Location header that's in an INVITE wouldn't create a subscription in >>the first place. > >Thanks for the clarification, but I was talking about the dereference >being orchestrated via subscription rather than polling. I wasn't really >talking about the conveyance itself, other than to ask how a conveyee is >to know what to do with the reference. > >>The above offering is to make sure dereferencing is done with HTTP/HTTPS, >>not SIP. > >I know, which is why I asked... > >>> How is the subscription done with HTTP? > >-andy > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 17:05:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JCc-0002Vb-Nh; Wed, 19 Jul 2006 17:03:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JCb-0002VV-2X for sip@ietf.org; Wed, 19 Jul 2006 17:03:29 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3JCZ-0008Tk-LA for sip@ietf.org; Wed, 19 Jul 2006 17:03:29 -0400 Received: (qmail invoked by alias); 19 Jul 2006 21:03:26 -0000 Received: from p54985EF9.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.94.249] by mail.gmx.net (mp030) with SMTP; 19 Jul 2006 23:03:26 +0200 X-Authenticated: #29516787 Message-ID: <44BE9E1B.9090903@gmx.net> Date: Wed, 19 Jul 2006 23:03:23 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fwmiller@cornfed.com Subject: Re: [Sip] SIP Security mechanism? References: <200607191946.k6JJkZx12177@smapp01.siteprotect.com> In-Reply-To: <200607191946.k6JJkZx12177@smapp01.siteprotect.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, it is true that the recent security work in SIP focused on media security. Some of the proposed mechanisms could also provide security for SIP signaling if signaling messages are exchanged between the end points (after the initial exchange via proxies that carries, for example, a finger print attribute). Ciao Hannes fwmiller@cornfed.com wrote: > The idea is the general concept of doing some kind of key exchange > between the UAs prior to doing signaling. This would address the > problem of maintaining the public key infrastructure. > > If that particular algorithm and key set does not work, perhaps some > algoritm that had the "UAS" generate an asymmetric public key > dynamically would work. The key exchange could be for each endpoint > to have the other endpoint generate an asymmetric key? I'm not a > crypto person but this seems like it might be doable, does any crypto > person here know of how that could be done? > > > FM > > > > ------------------------------------------------ On Wed, 19 Jul 2006 > 21:37:47 +0200, Hannes Tschofenig wrote: > > >> If you run a DH then the outcome is a symmetric key. S/MIME does >> not work with symmetric keys. >> >> Ciao Hannes >> >> fwmiller@cornfed.com wrote: >> >>> I've been reading about the ZRTP lately. I read Henning's >>> comment at the IETF meeting about how S/MIME relies on the >>> receiver's public key to be available to allow for >>> encryption/decryption to work. >>> >>> Why couldnt we put in place a mechanism that did a key exchange >>> for SIP signaling similar to whats done in ZRTP (i.e. modified >>> Diffie-Hellman) prior to any signaling traffic, then use the >>> exchanged keys as the basis for S/MIME encryption of the bodies? >>> Or we could even get really carried away and use it to do >>> encryption of the entire SIP message if the signaling did not >>> traverse proxies? This could be useful for encrypting UDP >>> signaling, again if no proxy were involved. >>> >>> Thoughts? FM >>> >>> >>> _______________________________________________ Sip mailing list >>> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW >>> development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >>> >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 17:28:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JYv-0006o7-5k; Wed, 19 Jul 2006 17:26:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JYt-0006nZ-IC; Wed, 19 Jul 2006 17:26:31 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3JYs-0002q9-6k; Wed, 19 Jul 2006 17:26:31 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3JW8-00076g-Ho; Wed, 19 Jul 2006 16:23:41 -0500 From: "Brian Rosen" To: Date: Wed, 19 Jul 2006 17:23:44 -0400 Message-ID: <026c01c6ab79$9fe2a0e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcareZxJ2SPVtSd3T9mM5oXpCTpVAw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org, "'Ecrit@Ietf. Org'" Subject: [Sip] Routing of calls based on location X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU REPLY, SEND IT ONLY TO GEOPRIV The SIP Location Conveyance document anticipates the ability to route a call based on the location of the caller. The original impetus for this is emergency calling. In ecrit, a mechanism has been defined (LoST) that takes a service request (in the form of a newly defined service urn) and a location and returns a URI. This mechanism is not limited to emergency calling, and could be used for arbitrary location based routing by defining new service urns. However, this opens up the issue of geopriv privacy concerns because the sender does not know the identity of the element (proxy) that will route the call using LoST. It may be that the UAC itself does this, but it may be some other intermediary. If the identity of the intermediary is not known, then protecting the location information becomes more difficult, because we cannot encrypt using keying material from the intended recipient. In fact, we would need to use hop-by-hop security, with transitive trust. This is what the emergency case does, but it also allows no channel security if necessary (usually meaning, try it with TLS and if that fails, try again without TLS). We propose to explicitly allow hop-by-hop security when sending location using SIP for the purpose of location based routing. We will specify you MUST use TLS if sending location by reference (and there will be some words about the choice of URI construction which is raised in another email I am about to send). An important issue that we need to discuss is what "Do Not Distribute" means in this case. We would like it to allow the data to be passed onward. Indeed, SIP proxies shouldn't be dropping headers. We propose that it means that it cannot be distributed except that the location header (and body of course) is passed as it normally would. Note that although this is an issue that concerns the SIP working group, because the location conveyance document is a sip document, it really is a geopriv issue. It also affects ecrit, since we are using its protocol beyond its initial purpose. We ask that this discussion be held on the geopriv list, and not copied to either sip or ecrit. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 17:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Jlh-0004BH-G0; Wed, 19 Jul 2006 17:39:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Jlg-0004B7-RM for sip@ietf.org; Wed, 19 Jul 2006 17:39:44 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Jlf-0003Pe-KY for sip@ietf.org; Wed, 19 Jul 2006 17:39:44 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3Jku-0001gr-SH for sip@ietf.org; Wed, 19 Jul 2006 16:38:57 -0500 From: "Brian Rosen" To: Date: Wed, 19 Jul 2006 17:39:01 -0400 Message-ID: <027901c6ab7b$c1f95d70$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acareu0r7/hzUt4KSMaSljrF58lp2gAAMb2Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sip] More on the contents of the Location header URI - http X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I started a discussion of what can be in the location header besides a cid:. We remain convinced that AbsoluteURI is a poor choice; we must be more specific, including privacy concerns. It is now clear that simply saying "https:" is not enough. There could be multiple location resolution protocols that use http transport. We need something else that would differentiate which one. The simple GET mechanism we proposed would need at least a parameter of some sort. After thinking about it for a while, I think the best resolution is Andy's suggestion of a registry, used in conjunction with a parameter. I'm ambivalent on whether the parameter is a URI parameter or a parameter on the Location header. We would define the registry (and the parameter) in location-conveyance and create one entry (the simple GET with PIDF-LO return). It may be, for example, that the proposed L7 location acquisition protocol defines another http based resolution protocol. That document could define another entry in the registry. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 18:41:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Khj-0007Kv-Tz; Wed, 19 Jul 2006 18:39:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Khi-0007KN-Rk; Wed, 19 Jul 2006 18:39:42 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Khh-0008HR-Jv; Wed, 19 Jul 2006 18:39:42 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 17:39:39 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 19 Jul 2006 17:39:38 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 17:39:38 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , "Andrew Newton" Date: Wed, 19 Jul 2006 17:44:11 -0500 Subject: RE: [Sip] Re: [Geopriv] SIP LocationConveyance: dereferencing location-by-reference MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 19 Jul 2006 22:39:38.0233 (UTC) FILETIME=[3787FE90:01C6AB84] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <44BE6543.40203@cs.columbia.edu> Content-class: urn:content-classes:message Thread-Topic: [Sip] Re: [Geopriv] SIP LocationConveyance: dereferencing location-by-reference Thread-Index: AcarVPBNlzJgJd54Qpyzd4zKjfPnAgALqBAg X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, geopriv@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1903328446==" Errors-To: sip-bounces@ietf.org --===============1903328446== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGVubmluZyBTY2h1bHpy aW5uZSBbbWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHVdDQo+IFNlbnQ6IFRodXJzZGF5LCAyMCBK dWx5IDIwMDYgMzowMSBBTQ0KPiBUbzogQW5kcmV3IE5ld3Rvbg0KPiBDYzogc2lwQGlldGYub3Jn OyBnZW9wcml2QGlldGYub3JnOyBKYW1lcyBNLiBQb2xrDQo+IFN1YmplY3Q6IFJlOiBbU2lwXSBS ZTogW0dlb3ByaXZdIFNJUCBMb2NhdGlvbkNvbnZleWFuY2U6IGRlcmVmZXJlbmNpbmcNCj4gbG9j YXRpb24tYnktcmVmZXJlbmNlDQo+IA0KPiBJIHN1c3BlY3Qgd2UncmUgdGFsa2luZyBhYm91dCB0 d28gZGlmZmVyZW50IHVzZSBjYXNlczoNCj4gDQo+IC0gcHJveGllcyB3aWxsIGZpbmQgc3Vic2Ny aXB0aW9ucyByYXRoZXIgdGVkaW91cyB3aGVuIGRvaW5nIGNhbGwgcm91dGluZw0KPiAoZG8gYSBT VUJTQ1JJQkUsIHdhaXQgZm9yIGF1dGhvcml6YXRpb24sIE5PVElGWSBqdXN0IHRvIGdldCBhIGxv Y2F0aW9uDQo+IHRvIHJvdXRlIGEgY2FsbD8pLCBhbmQgZG9uJ3QgZ2V0IGFueSBiZW5lZml0IGZy b20gdGhlIHN1YnNjcmlwdGlvbiBtb2RlbDsNCj4gDQo+IC0gVUFTcyB3aWxsIGZpbmQgc3Vic2Ny aXB0aW9ucyBoZWxwZnVsLCBpbiBzb21lIGxpbWl0ZWQgY2lyY3Vtc3RhbmNlcw0KPiAoZS5nLiwg aWYgSSBjYWxsIE9uU3RhciBmb3IgZGlyZWN0aW9ucywgdGhleSBtaWdodCB3YW50IHRvIHNlZSB3 aGVyZSBJJ20NCj4gZ29pbmcgaW4gcmVhbCB0aW1lLCByYXRoZXIgdGhhbiB3aGVyZSBJIHdhcyBm aXZlIG1pbnV0ZXMgYWdvIHdoaWxlIGFsbA0KPiB0aGVpciBhZ2VudHMgd2VyZSBidXN5IGFzc2lz dGluZyBvdGhlciBjdXN0b21lcnMpDQoNCkkgZGlzYWdyZWUgLSB0aGlzIHNvcnQgb2Ygc3lzdGVt IGlzLCBpbiBlZmZlY3QsIHByb3ZpZGVkIGJ5IGEgY2VsbHVsYXIgbmV0d29yay4gIEZvciBQaGFz ZSBJSSwgUFNBUHMgYXJlLCBpbiBlZmZlY3QsIGdpdmVuIGEgcmVmZXJlbmNlIHRvIGxvY2F0aW9u IGluZm9ybWF0aW9uICh0aHJvdWdoIHRoZSBjYWxsYmFjayBudW1iZXIsIGFuZCwgaW4gdGhlIFVT LCB0aGUgY2hhaW4gdGhyb3VnaCB0aGUgQUxJKS4NCiANCj4gSSBkb24ndCBzZWUgcGFydGljdWxh ciBzZWN1cml0eSBpc3N1ZXMgYXMgbG9uZyBhcyB0aGUgVUFDIHJlYWxpemVzIHRoYXQNCj4gYW55 IHN1YnNjcmlwdGlvbiBVUkkgdGhhdCBpdCBoYW5kcyBvdXQgbWlnaHQgYmUgdXNlZCBieSBhbnli b2R5IHRoYXQgaXMNCj4gb24gdGhlIGNhbGwgcGF0aC4gSW4gc29tZSBjYXNlcywgdGhhdCdzIGFu IGFjY2VwdGFibGUgbW9kZWwsDQo+IHBhcnRpY3VsYXJseSBpZiB0aGUgY2FsbGVyIGlkZW50aXR5 IGlzIG9ic2N1cmVkLCBzbyB0aGF0IHlvdSBvbmx5IGtub3cNCj4gdGhhdCAicmFuZG9tIGNhbGxl ciBhYmMxNyBpcyBhdCBsb2NhdGlvbiBYIHdhaXRpbmcgZm9yIHRvdyB0cnVjayIuIChJbg0KPiB0 aGF0IGNhc2UsIHN1YnNjcmlwdGlvbnMgYXJlIHByb2JhYmx5IHNvbWV3aGF0IHBvaW50bGVzcy4p DQo+IA0KPiBJbiBzaG9ydCwgSSB0aGluayB3ZSBzaG91bGQgYWxsb3cgYWxsIG9mIHRoZXNlIGFu ZCBzaW1wbHkgbWFrZSBzZW5zaWJsZQ0KPiByZWNvbW1lbmRhdGlvbnMsIHN1Y2ggYXMgdGhhdCBs b2NhdGlvbiBpbmZvcm1hdGlvbiBtZWFudCBmb3IgY2FsbA0KPiByb3V0aW5nIHNob3VsZCBOT1Qg anVzdCB1c2Ugc3Vic2NyaXB0aW9ucyBhbmQgYWxzbyBwcm92aWRlIGxvY2F0aW9uDQo+IGJ5LXZh bHVlL2J5LWF0dGFjaG1lbnQsIHNpbXBseSBiZWNhdXNlIGxvY2F0aW9uIHN1YnNjcmlwdGlvbnMg YXJlIHRvbw0KPiBwYWluZnVsIGFuZCB1c2VsZXNzIGZvciBwcm94aWVzIGluIHByYWN0aWNlLg0K PiANCg0KSSBhbSBoYXBweSB3aXRoIHRoYXQgY29uY2x1c2lvbi4gIEtlZXAgdGhlIGJhc2ljIGVs ZW1lbnQgc2ltcGxlLCBhbmQgcHJvdmlkZSBndWlkYW5jZSBzbyB0aGF0IGl0IGlzbid0IG1pc3Vz ZWQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNz YWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWlu IHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlv bi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRo b3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ== --===============1903328446== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1903328446==-- From sip-bounces@ietf.org Wed Jul 19 18:48:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Ko7-00086X-Vi; Wed, 19 Jul 2006 18:46:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Ko6-00086P-Sc; Wed, 19 Jul 2006 18:46:18 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Ko5-0000m3-KR; Wed, 19 Jul 2006 18:46:18 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k6JMkB3i017697; Wed, 19 Jul 2006 17:46:12 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k6JMkAC24682; Wed, 19 Jul 2006 17:46:10 -0500 (CDT) Message-ID: <44BEB632.9020006@lucent.com> Date: Wed, 19 Jul 2006 17:46:10 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Froment References: <3ACC9A25264A684F82C71840111F979801EC5E54@carrera.eu.tieto.com> <44BE3426.3050502@alcatel.fr> In-Reply-To: <44BE3426.3050502@alcatel.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org, Milan.Kunc@tietoenator.com, Silvestr.Peknik@tietoenator.com, simple@ietf.org Subject: [Sip] Re: [Simple] UDP - what if response is bigger than 1500 bytes (ethernet MTU)? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thomas Froment wrote: > This is a good question: I think it was mentionned in last SIP WG IETF > meeting that having responses greater than path MTU (-200 bytes) > in SIP was not currently well specified. It was an open issue on > draft-ietf-sip-hop-limit-diagnostics-03.txt which raises this problem > since it leads naturally to send big SIP responses. > SIP WG people may probably answer you if something is planned to handle > this problem... This remains a problem; I have had a quick chat with Scott Lawrence on it and we'll be submitting a draft latter part of next week on one way to deal with this. Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 18:48:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Kos-0000HH-Kh; Wed, 19 Jul 2006 18:47:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Koq-0000HC-W3 for sip@ietf.org; Wed, 19 Jul 2006 18:47:04 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Koo-0000pi-OW for sip@ietf.org; Wed, 19 Jul 2006 18:47:04 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3KnT-0000in-AE for sip@ietf.org; Wed, 19 Jul 2006 17:45:40 -0500 From: "Brian Rosen" To: Date: Wed, 19 Jul 2006 18:45:38 -0400 Message-ID: <028c01c6ab85$1422e8b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcarfW72ymdBf5AsRhS5KSXmrt5k/AAA7vIg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Sip] Allowing sip: (or prez:) in the location header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Suppose we allowed sip: or prez: as the location header URI. The resolution of this scheme would be "subscribe to presence". Note that if you asked for immediate expiration (0), you will get the immediate NOTIFY. This constitutes one reasonable way to provide location-by-reference. It is a form of "pull" (you send a SUBSCRIBE, you get one NOTIFY in return with the PIDF-LO). If your subscription has a longer expiration, it is a form of "push", and you might want to have a filter to limit how many pushes you get. Note that normally, presence provides identity as well as location. It may be that in some uses for the Location header, such as a location based routing, the identity information is not appropriate. The policy of the presence server for that use may be to only return the LO part of the PIDF. Also note that the form of the URI itself could inadvertently provide identity information (prez:brian.rosen@neustar.biz), which might not be desirable. If the idea to allow sip: and prez: is acceptable in the Location header URI, the text would contain a discussion of this issue. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 19:28:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LR4-0004Pp-KD; Wed, 19 Jul 2006 19:26:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LR3-0004Pd-5p; Wed, 19 Jul 2006 19:26:33 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3LR1-00055E-TW; Wed, 19 Jul 2006 19:26:33 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 18:26:30 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 19 Jul 2006 18:26:29 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 18:26:29 -0500 Message-ID: From: "Winterbottom, James" To: "Rosen, Brian" , Date: Wed, 19 Jul 2006 18:26:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 19 Jul 2006 23:26:29.0302 (UTC) FILETIME=[C30F1560:01C6AB8A] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Geopriv] More on the contents of the Location header URI - http Thread-Index: Acareu0r7/hzUt4KSMaSljrF58lp2gADxGNw X-Spam-Score: 0.5 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] More on the contents of the Location header URI - http X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, I am not sure that I agree with you on this one. The problem is not in the request protocol at all, the GET works fine providing the return type is always a PIDF-LO. Cheers James > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Thursday, 20 July 2006 7:33 AM > To: sip@ietf.org > Cc: geopriv@ietf.org > Subject: [Geopriv] More on the contents of the Location header URI - http >=20 > I started a discussion of what can be in the location header besides a > cid:. > We remain convinced that AbsoluteURI is a poor choice; we must be more > specific, including privacy concerns. >=20 > It is now clear that simply saying "https:" is not enough. There could > be multiple location resolution protocols that use http transport. We > need something else that would differentiate which one. The simple GET > mechanism we proposed would need at least a parameter of some sort. >=20 > After thinking about it for a while, I think the best resolution is > Andy's suggestion of a registry, used in conjunction with a parameter. > I'm ambivalent on whether the parameter is a URI parameter or a > parameter on the Location header. We would define the registry (and the > parameter) in location-conveyance and create one entry (the simple GET > with PIDF-LO return). It may be, for example, that the proposed L7 > location acquisition protocol defines another http based resolution > protocol. That document could define another entry in the registry. >=20 > Brian >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 19:38:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Lam-0005j6-ND; Wed, 19 Jul 2006 19:36:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Lal-0005iz-AA for sip@ietf.org; Wed, 19 Jul 2006 19:36:35 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Lak-0005ol-1E for sip@ietf.org; Wed, 19 Jul 2006 19:36:35 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 18:36:33 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 19 Jul 2006 18:36:33 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 18:36:32 -0500 Message-ID: From: "Thomson, Martin" To: "Brian Rosen" , Date: Wed, 19 Jul 2006 18:35:45 -0500 Subject: RE: [Sip] Allowing sip: (or prez:) in the location header MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 19 Jul 2006 23:36:32.0830 (UTC) FILETIME=[2ACA25E0:01C6AB8C] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <028c01c6ab85$1422e8b0$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Sip] Allowing sip: (or prez:) in the location header Thread-Index: AcarfW72ymdBf5AsRhS5KSXmrt5k/AAA7vIgAAJyIJA= X-Spam-Score: 0.5 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1958694652==" Errors-To: sip-bounces@ietf.org --===============1958694652== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message QnJpYW4sDQoNClllcywgeW91IGNhbiB1c2UgYSBzaXA6IG9yIHByZXM6IFVSSSB0byByZXRyaWV2 ZSBsb2NhdGlvbiBieS1yZWZlcmVuY2UuICBJdCB3b3Jrcy4gIFllcywgeW91IGNhbiB1c2UgYSBw dWxsIG1ldGhvZCB0byByZXRyaWV2ZSB0aGUgaW5mb3JtYXRpb247IHRoYXQncyBhIGZlYXR1cmUg b2YgU1VCU0NSSUJFL05PVElGWS4gIEkgc2VlIG5vIHJlYXNvbiB0byBwcmV2ZW50IHRoaXMsIGJ1 dCB5b3UgZG9uJ3QgYWN0dWFsbHkgaGF2ZSB0byBkb2N1bWVudCBldmVyeSBwb3NzaWJsZSByZXRy aWV2YWwgbWV0aG9kLg0KDQpJZGVudGl0eSBtaWdodCBiZSBhIHByb2JsZW0sIGJ1dCB0aGF0IGNh biBiZSBhZGRyZXNzZWQgYnkgdGhlIHVzZSBvZiB1bmxpbmtlZCBwc2V1ZG9ueW1zLiAgVGhpcyBp cyBub3Qgc3BlY2lmaWMgdG8gdGhlIGRlcmVmZXJlbmNlIG1ldGhvZC4gIFRoZSBzYW1lIHByb2Js ZW0gZXhpc3RzIG5vIG1hdHRlciBob3cgeW91IHJlc29sdmUgbG9jYXRpb24gLSBvciBhcmUgeW91 IHN1Z2dlc3RpbmcgdGhhdCB0aGUgc2lwOiBvciBwcmVzOiBVUklzIGRlcmVmZXJlbmNlIHRvIGEg UElERi1MTywgYnV0IG90aGVyIGZvcm1zIHdvdWxkIG5vdD8gIENsZWFybHksIHRoYXQgcHJvYmxl bSBhbHJlYWR5IGV4aXN0cyB3aXRoIHRoZSBjaWQ6IFVSTCBhbmQgc2hvdWxkIGV4aXN0IHdpdGgg dGhlIGh0dHBzOiBVUkwuDQoNCldoYXQgSSB0YWtlIGZyb20gdGhpcyBpcyB0aGF0IHlvdSBuZWVk IHRvIGhhdmUgdGV4dCB0aGF0IGV4cGxhaW5zIHRoZSBpbXBhY3Qgb2YgdGhlIGFzc29jaWF0aW9u IGJldHdlZW4gaWRlbnRpdHkgYW5kIGxvY2F0aW9uLiAgVGhvc2UgY29uY2VybnMgYXJlIGxhcmdl bHkgY292ZXJlZCBieSBvdGhlciBHRU9QUklWIGRvY3VtZW50cywgYnV0IHRoZXJlIGlzIG5vIGhh cm0gaW4gYmVpbmcgZXhwbGljaXQuDQoNCkNoZWVycywNCk1hcnRpbg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86YnJAYnJpYW5yb3Nl bi5uZXRdDQo+IFNlbnQ6IFRodXJzZGF5LCAyMCBKdWx5IDIwMDYgODo0NiBBTQ0KPiBUbzogc2lw QGlldGYub3JnDQo+IFN1YmplY3Q6IFtTaXBdIEFsbG93aW5nIHNpcDogKG9yIHByZXo6KSBpbiB0 aGUgbG9jYXRpb24gaGVhZGVyDQo+IA0KPiBTdXBwb3NlIHdlIGFsbG93ZWQgc2lwOiBvciBwcmV6 OiBhcyB0aGUgbG9jYXRpb24gaGVhZGVyIFVSSS4gIFRoZQ0KPiByZXNvbHV0aW9uDQo+IG9mIHRo aXMgc2NoZW1lIHdvdWxkIGJlICJzdWJzY3JpYmUgdG8gcHJlc2VuY2UiLg0KPiANCj4gTm90ZSB0 aGF0IGlmIHlvdSBhc2tlZCBmb3IgaW1tZWRpYXRlIGV4cGlyYXRpb24gKDApLCB5b3Ugd2lsbCBn ZXQgdGhlDQo+IGltbWVkaWF0ZSBOT1RJRlkuICBUaGlzIGNvbnN0aXR1dGVzIG9uZSByZWFzb25h YmxlIHdheSB0byBwcm92aWRlDQo+IGxvY2F0aW9uLWJ5LXJlZmVyZW5jZS4gIEl0IGlzIGEgZm9y bSBvZiAicHVsbCIgKHlvdSBzZW5kIGEgU1VCU0NSSUJFLCB5b3UNCj4gZ2V0IG9uZSBOT1RJRlkg aW4gcmV0dXJuIHdpdGggdGhlIFBJREYtTE8pLiAgSWYgeW91ciBzdWJzY3JpcHRpb24gaGFzIGEN Cj4gbG9uZ2VyIGV4cGlyYXRpb24sIGl0IGlzIGEgZm9ybSBvZiAicHVzaCIsIGFuZCB5b3UgbWln aHQgd2FudCB0byBoYXZlIGENCj4gZmlsdGVyIHRvIGxpbWl0IGhvdyBtYW55IHB1c2hlcyB5b3Ug Z2V0Lg0KPiANCj4gTm90ZSB0aGF0IG5vcm1hbGx5LCBwcmVzZW5jZSBwcm92aWRlcyBpZGVudGl0 eSBhcyB3ZWxsIGFzIGxvY2F0aW9uLiAgSXQNCj4gbWF5DQo+IGJlIHRoYXQgaW4gc29tZSB1c2Vz IGZvciB0aGUgTG9jYXRpb24gaGVhZGVyLCBzdWNoIGFzIGEgbG9jYXRpb24gYmFzZWQNCj4gcm91 dGluZywgdGhlIGlkZW50aXR5IGluZm9ybWF0aW9uIGlzIG5vdCBhcHByb3ByaWF0ZS4gIFRoZSBw b2xpY3kgb2YgdGhlDQo+IHByZXNlbmNlIHNlcnZlciBmb3IgdGhhdCB1c2UgbWF5IGJlIHRvIG9u bHkgcmV0dXJuIHRoZSBMTyBwYXJ0IG9mIHRoZQ0KPiBQSURGLg0KPiBBbHNvIG5vdGUgdGhhdCB0 aGUgZm9ybSBvZiB0aGUgVVJJIGl0c2VsZiBjb3VsZCBpbmFkdmVydGVudGx5IHByb3ZpZGUNCj4g aWRlbnRpdHkgaW5mb3JtYXRpb24gKHByZXo6YnJpYW4ucm9zZW5AbmV1c3Rhci5iaXopLCB3aGlj aCBtaWdodCBub3QgYmUNCj4gZGVzaXJhYmxlLiAgSWYgdGhlIGlkZWEgdG8gYWxsb3cgc2lwOiBh bmQgcHJlejogaXMgYWNjZXB0YWJsZSBpbiB0aGUNCj4gTG9jYXRpb24gaGVhZGVyIFVSSSwgdGhl IHRleHQgd291bGQgY29udGFpbiBhIGRpc2N1c3Npb24gb2YgdGhpcyBpc3N1ZS4NCj4gDQo+IEJy aWFuDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwDQo+IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBj b3JlIFNJUCBQcm90b2NvbA0KPiBVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUg Zm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcA0KPiBVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3Ig bmV3IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVz aWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3By aWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUg cmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRl bHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhp cyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpbbWYyXQ== --===============1958694652== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1958694652==-- From sip-bounces@ietf.org Wed Jul 19 19:58:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Ltb-0008B0-Pq; Wed, 19 Jul 2006 19:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LtZ-0008AE-SZ; Wed, 19 Jul 2006 19:56:01 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Lsh-0000SE-8S; Wed, 19 Jul 2006 19:55:08 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3LpZ-0003S9-Jz; Wed, 19 Jul 2006 18:51:59 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "Rosen, Brian" , Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location header URI- http Date: Wed, 19 Jul 2006 19:51:58 -0400 Message-ID: <02b901c6ab8e$55e22eb0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acareu0r7/hzUt4KSMaSljrF58lp2gADxGNwAAD2RlA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The problem is that HTTP is used as a transport protocol by several mechanisms, and you need to know from the contents of the location header which mechanism is used. Is it SOAP, raw GET, LCP, RELO, HELD or something else, all of which would say "https:blahblah"? Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, July 19, 2006 7:26 PM > To: Rosen, Brian; sip@ietf.org > Cc: geopriv@ietf.org > Subject: [Sip] RE: [Geopriv] More on the contents of the Location header > URI- http > > Brian, > > I am not sure that I agree with you on this one. > The problem is not in the request protocol at all, the GET works fine > providing the return type is always a PIDF-LO. > > Cheers > James > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Thursday, 20 July 2006 7:33 AM > > To: sip@ietf.org > > Cc: geopriv@ietf.org > > Subject: [Geopriv] More on the contents of the Location header URI - > http > > > > I started a discussion of what can be in the location header besides a > > cid:. > > We remain convinced that AbsoluteURI is a poor choice; we must be more > > specific, including privacy concerns. > > > > It is now clear that simply saying "https:" is not enough. There > could > > be multiple location resolution protocols that use http transport. We > > need something else that would differentiate which one. The simple > GET > > mechanism we proposed would need at least a parameter of some sort. > > > > After thinking about it for a while, I think the best resolution is > > Andy's suggestion of a registry, used in conjunction with a parameter. > > I'm ambivalent on whether the parameter is a URI parameter or a > > parameter on the Location header. We would define the registry (and > the > > parameter) in location-conveyance and create one entry (the simple GET > > with PIDF-LO return). It may be, for example, that the proposed L7 > > location acquisition protocol defines another http based resolution > > protocol. That document could define another entry in the registry. > > > > Brian > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 19:58:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3LuA-00009X-3M; Wed, 19 Jul 2006 19:56:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Lu8-000088-2e for sip@ietf.org; Wed, 19 Jul 2006 19:56:36 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3LgE-0006JJ-0t for sip@ietf.org; Wed, 19 Jul 2006 19:42:14 -0400 Received: from [192.168.2.109] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6JNi9LB015705 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 19 Jul 2006 18:44:10 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) References: <9A350671-A740-4793-BAC4-FBA62AD0F5B2@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 19 Jul 2006 18:41:30 -0500 To: SIP WG List X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Subject: [Sip] Protocol Shepherding Writeup for SIP MIB -- draft-ietf-sip-mib X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As the shepherding WG chair for sip-mib, I've submitted the following writeup to the IESG. ---- forwarded text follows ---- The SIP working group would like to request publication of the standards-track document draft-ietf-sip-mib-11, which has already completed MIB Doctor review. A Protocol Shepherd writeup follows, including a draft Document Announcement Writeup. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The Document Shepherd for draft-ietf-sip-mib-11.txt is Dean Willis, co-chair of the SIP Working Group. He has reviewed this document and believes it is ready for forwarding to the iESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been widely reviewed within the working group and within the wider community, including discussion at several standards organizations. It has also been reviewed by Dan Romascanu as the specified MIB doctor. The document shepherd has no concerns about the depth or breadth of the reviews that have been performed. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document shepherd has no concerns that the draft needs broader review. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if those issues have been discussed in the WG and the WG has indicated that it still wishes to advance the document, detail those concerns here. The document shepherd has personal concerns about whether there is any need for a SIP MIB given ongoing evolution in the systems management environment, but there is a reasonable consensus in the working group and broader community to advance the document despite these concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document enjoys a strong consensus of all working group participants known to the document shepherd who care about a MIB at all. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire will be entered into the ID Tracker.) There are no known indications of extreme discontent. (1.g) Has the Document Shepherd verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. The document shepherd read through the document, executed the current idnits against it, and worked through the checklist at http:// www.ietf.org/ID-Checklist.html and found no issues. The MIB data in the document was verified by a third party using the usual tools. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are correctly divided, and all normative references are to completed standards-track documents. (1.i) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Document Announcement Writeup for SIP MIB, draft-ietf-sip-mib Technical Summary: This document defines a portion of the Management Information Base (a MIB) including a set of objects used to manage Session Initiation Protocol (SIP) entities, including SIP User Agents, Proxies, Redirect (aka Location) Servers, and Registrars. Note that this MIB is restricted to management and monitoring activities. Following extended discussion, the working group chose not to pursue device configuration using the SIP MIB, and will rely instead on the SIP Configuration Framework being developed in the SIPPING working group. Working Group Summary: The SIP Working Group developed this document over a greater than six- year period, with the first draft appearing in March of 2000. One of the key decisions in its development was the choice to exclude device configuration functions from the MIB. This decision was reached after the SIP community decided to pursue a SIP-specific configuration model as outlined in "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config- framework-08.txt. This decision significantly reduced the scope and complexity of the SIP MIB. While not all participants in the working group are convinced of the need for a SIP MIB, there seems to be a very strong consensus on the technical detail of the draft and a general agreement on its applicability. Document Quality: The document shepherd is aware of at least one pre-specification implementation of the SIP MIB developed by a major equipment provider. The SIPIT interoperability events have not included SIP MIB testing in their events, and the coordinator of those events reports that he stopped asking about SIP MIB implementations some years ago because of the general lack of interest in the development community. However, the industry is beginning to see requirements for SIP MIB compliance appear in large-scale Requests For Information and Requests For Proposal. The document has also received considerable attention from related standards development organizations, including PacketCable. Development of this specification was assisted greatly by the support of Dan Romascanu acting as the designated "MIB Doctor", with additional commentary received from David Harrington.. The document's "Contributors" section also cites review by Tom Taylor, Kavitha Patchayappan, Dan Romascanu, Cullen Jennings, Orit Levin, AC Mahendran, Mary Barnes, Rohan Mahy, Bob Penfield, Charles Eckel and Dean Willis. Both Allison Mankin and Cullen Jennings oversaw the development as Area Directors, with Cullen Jennings serving as the Responsible Area Director at the time of publication request. Dean Willis served as the WG Chair Shepherd. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 20:02:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Lxo-0000lG-OO; Wed, 19 Jul 2006 20:00:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Lxn-0000l8-BF; Wed, 19 Jul 2006 20:00:23 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Lxm-0001ZU-1W; Wed, 19 Jul 2006 20:00:23 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 19:00:17 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 19 Jul 2006 19:00:16 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 19:00:15 -0500 Message-ID: From: "Winterbottom, James" To: "Brian Rosen" , "Rosen, Brian" , Date: Wed, 19 Jul 2006 19:00:14 -0500 Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location header URI- http MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 20 Jul 2006 00:00:15.0596 (UTC) FILETIME=[7AD302C0:01C6AB8F] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <02b901c6ab8e$55e22eb0$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] More on the contents of the Location header URI- http Thread-Index: Acareu0r7/hzUt4KSMaSljrF58lp2gADxGNwAAD2RlAAAFWXUA== X-Spam-Score: 0.5 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Providing all mechanisms support a base GET AND they return a PIDF-LO there is no problem. That is all that needs to be said. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 20 July 2006 9:52 AM > To: Winterbottom, James; Rosen, Brian; sip@ietf.org > Cc: geopriv@ietf.org > Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location > header URI- http >=20 > The problem is that HTTP is used as a transport protocol by several > mechanisms, and you need to know from the contents of the location header > which mechanism is used. Is it SOAP, raw GET, LCP, RELO, HELD or > something > else, all of which would say "https:blahblah"? >=20 > Brian >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Wednesday, July 19, 2006 7:26 PM > > To: Rosen, Brian; sip@ietf.org > > Cc: geopriv@ietf.org > > Subject: [Sip] RE: [Geopriv] More on the contents of the Location header > > URI- http > > > > Brian, > > > > I am not sure that I agree with you on this one. > > The problem is not in the request protocol at all, the GET works fine > > providing the return type is always a PIDF-LO. > > > > Cheers > > James > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > Sent: Thursday, 20 July 2006 7:33 AM > > > To: sip@ietf.org > > > Cc: geopriv@ietf.org > > > Subject: [Geopriv] More on the contents of the Location header URI - > > http > > > > > > I started a discussion of what can be in the location header besides a > > > cid:. > > > We remain convinced that AbsoluteURI is a poor choice; we must be more > > > specific, including privacy concerns. > > > > > > It is now clear that simply saying "https:" is not enough. There > > could > > > be multiple location resolution protocols that use http transport. We > > > need something else that would differentiate which one. The simple > > GET > > > mechanism we proposed would need at least a parameter of some sort. > > > > > > After thinking about it for a while, I think the best resolution is > > > Andy's suggestion of a registry, used in conjunction with a parameter. > > > I'm ambivalent on whether the parameter is a URI parameter or a > > > parameter on the Location header. We would define the registry (and > > the > > > parameter) in location-conveyance and create one entry (the simple GET > > > with PIDF-LO return). It may be, for example, that the proposed L7 > > > location acquisition protocol defines another http based resolution > > > protocol. That document could define another entry in the registry. > > > > > > Brian > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 20:04:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3M00-0001AK-Us; Wed, 19 Jul 2006 20:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3M00-0001AF-8E for sip@ietf.org; Wed, 19 Jul 2006 20:02:40 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Lzz-00020V-S7 for sip@ietf.org; Wed, 19 Jul 2006 20:02:40 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3LzA-0005BL-GO; Wed, 19 Jul 2006 19:01:49 -0500 From: "Brian Rosen" To: "'Thomson, Martin'" , Subject: RE: [Sip] Allowing sip: (or prez:) in the location header Date: Wed, 19 Jul 2006 20:01:54 -0400 Message-ID: <02bf01c6ab8f$b7b40860$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcarfW72ymdBf5AsRhS5KSXmrt5k/AAA7vIgAAJyIJAAANpnAA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think we are going to be explicit about what is allowed to be in the Location header, and not use AbsoluteURI. We think something DOES have to document every possible retrieval mechanism and discuss the geopriv privacy issues and how they are dealt with. That is precisely what we propose. We'll define some of them in location-conveyance, and specify how a standards track document adds more possibilities. Please note that we don't want a lot of possibilities here; every dereferencer has to implement all choices. Incidentally, I think we will specify in the language that an extension to the allowed URIs in a Location header is NOT a SIP extension, and does not come under the 3427 process. This would allow geopriv, for example, to define the L7 protocol, and if it has a location-by-reference construction with a dereferencing procedure, it would be allowed to add to the methods listed in location-conveyance without running through 3427. That language, since it is part of sip-location, would have to be acceptable to sip/sipping. Agree that the identity issues of URL construction are generic and can be treated in the text as generic, not tied to any particular scheme. It may be more likely in prez:, simply because the default type of uri is an AoR, which almost always has identity data. Brian > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Wednesday, July 19, 2006 7:36 PM > To: Brian Rosen; sip@ietf.org > Subject: RE: [Sip] Allowing sip: (or prez:) in the location header > > Brian, > > Yes, you can use a sip: or pres: URI to retrieve location by-reference. > It works. Yes, you can use a pull method to retrieve the information; > that's a feature of SUBSCRIBE/NOTIFY. I see no reason to prevent this, > but you don't actually have to document every possible retrieval method. > > Identity might be a problem, but that can be addressed by the use of > unlinked pseudonyms. This is not specific to the dereference method. The > same problem exists no matter how you resolve location - or are you > suggesting that the sip: or pres: URIs dereference to a PIDF-LO, but other > forms would not? Clearly, that problem already exists with the cid: URL > and should exist with the https: URL. > > What I take from this is that you need to have text that explains the > impact of the association between identity and location. Those concerns > are largely covered by other GEOPRIV documents, but there is no harm in > being explicit. > > Cheers, > Martin > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 20 July 2006 8:46 AM > > To: sip@ietf.org > > Subject: [Sip] Allowing sip: (or prez:) in the location header > > > > Suppose we allowed sip: or prez: as the location header URI. The > > resolution > > of this scheme would be "subscribe to presence". > > > > Note that if you asked for immediate expiration (0), you will get the > > immediate NOTIFY. This constitutes one reasonable way to provide > > location-by-reference. It is a form of "pull" (you send a SUBSCRIBE, > you > > get one NOTIFY in return with the PIDF-LO). If your subscription has a > > longer expiration, it is a form of "push", and you might want to have a > > filter to limit how many pushes you get. > > > > Note that normally, presence provides identity as well as location. It > > may > > be that in some uses for the Location header, such as a location based > > routing, the identity information is not appropriate. The policy of the > > presence server for that use may be to only return the LO part of the > > PIDF. > > Also note that the form of the URI itself could inadvertently provide > > identity information (prez:brian.rosen@neustar.biz), which might not be > > desirable. If the idea to allow sip: and prez: is acceptable in the > > Location header URI, the text would contain a discussion of this issue. > > > > Brian > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 20:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3MB6-0002aM-GH; Wed, 19 Jul 2006 20:14:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3MB4-0002a1-Vr; Wed, 19 Jul 2006 20:14:06 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3MB4-0005Fm-JK; Wed, 19 Jul 2006 20:14:06 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3M9m-00073I-TR; Wed, 19 Jul 2006 19:12:51 -0500 From: "Brian Rosen" To: , "'Winterbottom, James'" Subject: Re: [Sip] RE: [Geopriv] More on the contents of the Location header URI- http Date: Wed, 19 Jul 2006 20:12:52 -0400 Message-ID: <02c301c6ab91$402fa630$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acareu0r7/hzUt4KSMaSljrF58lp2gADxGNwAAD2RlAAAFWXUAAALkMQAABPJbA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Actually, it means that a base GET/return PIDF is ALL you could implement; you can't get anything back from the PIDF that would tell you anything else is acceptable, and you can't tell from the URI. That would mean a SOAP based mechanism could never be specified, for example. You couldn't have an optional parameter unless you were prepared to try it, have it fail, and then try something else. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, July 19, 2006 8:00 PM > To: Brian Rosen; Rosen, Brian; sip@ietf.org > Cc: geopriv@ietf.org > Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location > header URI- http > > Providing all mechanisms support a base GET AND they return a PIDF-LO > there is no problem. That is all that needs to be said. > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 20 July 2006 9:52 AM > > To: Winterbottom, James; Rosen, Brian; sip@ietf.org > > Cc: geopriv@ietf.org > > Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location > > header URI- http > > > > The problem is that HTTP is used as a transport protocol by several > > mechanisms, and you need to know from the contents of the location > header > > which mechanism is used. Is it SOAP, raw GET, LCP, RELO, HELD or > > something > > else, all of which would say "https:blahblah"? > > > > Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Wednesday, July 19, 2006 7:26 PM > > > To: Rosen, Brian; sip@ietf.org > > > Cc: geopriv@ietf.org > > > Subject: [Sip] RE: [Geopriv] More on the contents of the Location > header > > > URI- http > > > > > > Brian, > > > > > > I am not sure that I agree with you on this one. > > > The problem is not in the request protocol at all, the GET works > fine > > > providing the return type is always a PIDF-LO. > > > > > > Cheers > > > James > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > Sent: Thursday, 20 July 2006 7:33 AM > > > > To: sip@ietf.org > > > > Cc: geopriv@ietf.org > > > > Subject: [Geopriv] More on the contents of the Location header URI > - > > > http > > > > > > > > I started a discussion of what can be in the location header > besides a > > > > cid:. > > > > We remain convinced that AbsoluteURI is a poor choice; we must be > more > > > > specific, including privacy concerns. > > > > > > > > It is now clear that simply saying "https:" is not enough. There > > > could > > > > be multiple location resolution protocols that use http transport. > We > > > > need something else that would differentiate which one. The > simple > > > GET > > > > mechanism we proposed would need at least a parameter of some > sort. > > > > > > > > After thinking about it for a while, I think the best resolution > is > > > > Andy's suggestion of a registry, used in conjunction with a > parameter. > > > > I'm ambivalent on whether the parameter is a URI parameter or a > > > > parameter on the Location header. We would define the registry > (and > > > the > > > > parameter) in location-conveyance and create one entry (the simple > GET > > > > with PIDF-LO return). It may be, for example, that the proposed > L7 > > > > location acquisition protocol defines another http based > resolution > > > > protocol. That document could define another entry in the > registry. > > > > > > > > Brian > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 20:16:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3MBf-0002sF-HY; Wed, 19 Jul 2006 20:14:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3MBe-0002s2-Ce; Wed, 19 Jul 2006 20:14:42 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3MBe-0005Qh-0X; Wed, 19 Jul 2006 20:14:42 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 19:14:41 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 19 Jul 2006 19:14:41 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 19:14:40 -0500 Message-ID: From: "Winterbottom, James" To: "Rosen, Brian" , "Brian Rosen" , Date: Wed, 19 Jul 2006 19:14:38 -0500 Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location header URI- http MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 20 Jul 2006 00:14:40.0293 (UTC) FILETIME=[7E394D50:01C6AB91] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] More on the contents of the Location header URI- http Thread-Index: Acareu0r7/hzUt4KSMaSljrF58lp2gADxGNwAAD2RlAAAFWXUAAALkMQAABAvKA= X-Spam-Score: 0.5 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What it means is that you MUST provide a Get mechanism with no parameters, you MAY provide anything you like on top of that. If you are prepared to take the hit with trying something specific first then that is your prerogative, or you may decide to do the GET first, and something special as a second-try, which is also okay. I simply don't agree with your reasoning to exclude a simple GET mechanism now.=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Thursday, 20 July 2006 10:09 AM > To: Winterbottom, James; Brian Rosen; sip@ietf.org > Cc: geopriv@ietf.org > Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location > header URI- http >=20 > Actually, it means that a base GET/return PIDF is ALL you could > implement; you can't get anything back from the PIDF that would tell you > anything else is acceptable, and you can't tell from the URI. >=20 > That would mean a SOAP based mechanism could never be specified, for > example. You couldn't have an optional parameter unless you were > prepared to try it, have it fail, and then try something else. >=20 > Brian >=20 >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Wednesday, July 19, 2006 8:00 PM > > To: Brian Rosen; Rosen, Brian; sip@ietf.org > > Cc: geopriv@ietf.org > > Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location > > header URI- http > > > > Providing all mechanisms support a base GET AND they return a PIDF-LO > > there is no problem. That is all that needs to be said. > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, 20 July 2006 9:52 AM > > > To: Winterbottom, James; Rosen, Brian; sip@ietf.org > > > Cc: geopriv@ietf.org > > > Subject: RE: [Sip] RE: [Geopriv] More on the contents of the > Location > > > header URI- http > > > > > > The problem is that HTTP is used as a transport protocol by several > > > mechanisms, and you need to know from the contents of the location > > header > > > which mechanism is used. Is it SOAP, raw GET, LCP, RELO, HELD or > > > something > > > else, all of which would say "https:blahblah"? > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: Wednesday, July 19, 2006 7:26 PM > > > > To: Rosen, Brian; sip@ietf.org > > > > Cc: geopriv@ietf.org > > > > Subject: [Sip] RE: [Geopriv] More on the contents of the Location > > header > > > > URI- http > > > > > > > > Brian, > > > > > > > > I am not sure that I agree with you on this one. > > > > The problem is not in the request protocol at all, the GET works > > fine > > > > providing the return type is always a PIDF-LO. > > > > > > > > Cheers > > > > James > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > > Sent: Thursday, 20 July 2006 7:33 AM > > > > > To: sip@ietf.org > > > > > Cc: geopriv@ietf.org > > > > > Subject: [Geopriv] More on the contents of the Location header > URI > > - > > > > http > > > > > > > > > > I started a discussion of what can be in the location header > > besides a > > > > > cid:. > > > > > We remain convinced that AbsoluteURI is a poor choice; we must > be > > more > > > > > specific, including privacy concerns. > > > > > > > > > > It is now clear that simply saying "https:" is not enough. > There > > > > could > > > > > be multiple location resolution protocols that use http > transport. > > We > > > > > need something else that would differentiate which one. The > > simple > > > > GET > > > > > mechanism we proposed would need at least a parameter of some > > sort. > > > > > > > > > > After thinking about it for a while, I think the best resolution > > is > > > > > Andy's suggestion of a registry, used in conjunction with a > > parameter. > > > > > I'm ambivalent on whether the parameter is a URI parameter or a > > > > > parameter on the Location header. We would define the registry > > (and > > > > the > > > > > parameter) in location-conveyance and create one entry (the > simple > > GET > > > > > with PIDF-LO return). It may be, for example, that the proposed > > L7 > > > > > location acquisition protocol defines another http based > > resolution > > > > > protocol. That document could define another entry in the > > registry. > > > > > > > > > > Brian > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > [mf2] > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of > sip > > > > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 19 20:35:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3MUP-0006al-FT; Wed, 19 Jul 2006 20:34:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3MUN-0006ag-EL for sip@ietf.org; Wed, 19 Jul 2006 20:34:03 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3MUM-0000hz-W6 for sip@ietf.org; Wed, 19 Jul 2006 20:34:03 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 19:34:01 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 19 Jul 2006 19:34:01 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 19:34:00 -0500 Message-ID: From: "Thomson, Martin" To: "Brian Rosen" , Date: Wed, 19 Jul 2006 19:33:17 -0500 Subject: RE: [Sip] Allowing sip: (or prez:) in the location header MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 20 Jul 2006 00:34:00.0841 (UTC) FILETIME=[31F6DF90:01C6AB94] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <02bf01c6ab8f$b7b40860$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Sip] Allowing sip: (or prez:) in the location header Thread-Index: AcarfW72ymdBf5AsRhS5KSXmrt5k/AAA7vIgAAJyIJAAANpnAAAAfwmw X-Spam-Score: 0.5 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1193493571==" Errors-To: sip-bounces@ietf.org --===============1193493571== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message VGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gdXNpbmcgQUJORiB0byBsaW1pdCB3aGF0IGlz IHBvc3NpYmxlIGFuZCBwcm92aWRpbmcgYSBiYXNlbGluZSBmb3IgaW1wbGVtZW50YXRpb25zLg0K DQpJIHdhcyBoYXBweSB3aXRoIHRoZSBvcmlnaW5hbCBwcm9wb3NhbC4gIFRoYXQgaXMsIGRlZmlu ZSB0aGUgaGVhZGVyIHRvIGluY2x1ZGUgQWJzb2x1dGVVUkkgYW5kIHNheSB0aGF0IGltcGxlbWVu dGF0aW9ucyBNVVNUIGltcGxlbWVudCBodHRwcyBhbmQgY2lkLiAgSSBoYWQgYXNzdW1lZCB0aGF0 IHRoZSBodHRwcyBkZXJlZmVuY2Ugd291bGQgYmUgYXMgc2ltcGxlIGFzIHRoZSBkZXJlZmVyZW5j ZSBtZXRob2QgZm9yIHRoZSBmb2xsb3dpbmc6IDxodHRwczovL2lldGYub3JnLz4uICBFeHRyYSBm dW5jdGlvbmFsaXR5L2ZsZXhpYmlsaXR5IGluIGRlcmVmZXJlbmNpbmcgd2lsbCBhY3R1YWxseSBi ZSB1c2VmdWwgaW4gc29tZSBjYXNlcy4NCg0KU28gaGVyZSBpcyBteSBjb25jcmV0ZSBwcm9wb3Nh bDoNCg0KVGhlIEFCTkYgZGVmaW5lcyBhIGxvY2F0aW9uIFVSSSBhcyB0aGUgZm9sbG93aW5nOg0K DQpMb2NhdGlvbiAgICAgICA9ICJMb2NhdGlvbiIgSENPTE9OIGxvY2F0aW9uLXBhcmFtICooQ09N TUEgbG9jYXRpb24tcGFyYW0pDQpsb2NhdGlvbi1wYXJhbSA9IExBUVVPVCBhYnNvbHV0ZVVSSSBS QVFVT1QgKiggU0VNSSBnZW5lcmljLXBhcmFtICkNCg0KVGhpcyBpcyBhIGNvcHkgYW5kIHBhc3Rl IG9mIHRoZSBBbGVydC1JbmZvIGhlYWRlciBBQk5GIGZyb20gUkZDIDMyNjEuICBUaGlzIGZvbGxv d3MgdGhlIHByaW5jaXBsZSBvZiBsZWFzdCBzdXJwcmlzZS4NCg0KVGhlbiB3ZSBoYXZlIHRleHQg dGhhdCBzYXlzIHNvbWV0aGluZyB0byB0aGlzIGVmZmVjdDoNCg0KICAiSW1wbGVtZW50YXRpb25z IE1VU1Qgc3VwcG9ydCB0aGUgY2lkOiBVUkwgW3JlZl0gZm9yIGxvY2F0aW9uIGJ5LXZhbHVlIGFu ZCB0aGUgaHR0cHM6IFVSTCBbcmVmXSBmb3IgbG9jYXRpb24gYnktcmVmZXJlbmNlLiAgVGhlIGh0 dHBzOiBVUkkgTVVTVCBiZSBhY2Nlc3NpYmxlIHVzaW5nIGFuIEhUVFAgR0VUIG1ldGhvZC4gIEFu eSBVUkkgdGhhdCBpcyBpbmNsdWRlZCBpbiB0aGlzIGhlYWRlciBNVVNUIGRlcmVmZXJlbmNlIHRv IGEgUElERi1MTyBkb2N1bWVudCAod2l0aCBhIE1JTUUtdHlwZSBvZiAiYXBwbGljYXRpb24vcGlk Zit4bWwiKS4iDQoNCiAgIlBhcmFtZXRlcnMgTUFZIGJlIGluY2x1ZGVkIHRvIGluZGljYXRlIGFk ZGl0aW9uYWwgZmVhdHVyZXMgb2YgdGhlIFVSSTsgZm9yIGluc3RhbmNlLCB3aXRoIGFuIGh0dHBz OiBVUkksIHBhcmFtZXRlcnMgY291bGQgaW5kaWNhdGUgdGhhdCBhIFBPU1QgdG8gdGhlIFVSSSB3 aXRoIGEgcmVxdWVzdCBib2R5IHByb3ZpZGVzIHRoZSByZXF1ZXN0ZXIgYWRkaXRpb25hbCBjb250 cm9sIG92ZXIgdGhlIGluZm9ybWF0aW9uLiAgSG93ZXZlciwgdGhlIHJlcXVlc3RlciBNVVNUIGJl IGFibGUgdG8gdXNlIGFuIEhUVFAgR0VUIHJlcXVlc3QgaWYgdGhpcyBhZGRpdGlvbmFsIGZ1bmN0 aW9uYWxpdHkgaXMgbm90IHN1cHBvcnRlZC4iDQoNCllvdSBjYW4gdGhlbiBzZXR1cCBhIHJlZ2lz dHJ5IGZvciBwYXJhbWV0ZXJzIHdpdGggSUFOQSwgZm9sbG93aW5nIHRoZSBzdGFuZGFyZCBmb3Jt IGZvciB0aG9zZSB0aGluZ3MuICBJIHdpbGwgbGV0IHRoZSBTSVAgZm9sa3MgbWFrZSB0aGUgY2Fs bCBvbiBhdm9pZGluZyAzNDI3IHByb2Nlc3MsIGJ1dCBpdCdzIG5vdCBhIGJhZCBpZGVhLjENCg0K Q2hlZXJzLA0KTWFydGluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog QnJpYW4gUm9zZW4gW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0NCj4gU2VudDogVGh1cnNkYXks IDIwIEp1bHkgMjAwNiAxMDowMiBBTQ0KPiBUbzogVGhvbXNvbiwgTWFydGluOyBzaXBAaWV0Zi5v cmcNCj4gU3ViamVjdDogUkU6IFtTaXBdIEFsbG93aW5nIHNpcDogKG9yIHByZXo6KSBpbiB0aGUg bG9jYXRpb24gaGVhZGVyDQo+IA0KPiBJIHRoaW5rIHdlIGFyZSBnb2luZyB0byBiZSBleHBsaWNp dCBhYm91dCB3aGF0IGlzIGFsbG93ZWQgdG8gYmUgaW4gdGhlDQo+IExvY2F0aW9uIGhlYWRlciwg YW5kIG5vdCB1c2UgQWJzb2x1dGVVUkkuICBXZSB0aGluayBzb21ldGhpbmcgRE9FUyBoYXZlIHRv DQo+IGRvY3VtZW50IGV2ZXJ5IHBvc3NpYmxlIHJldHJpZXZhbCBtZWNoYW5pc20gYW5kIGRpc2N1 c3MgdGhlIGdlb3ByaXYNCj4gcHJpdmFjeQ0KPiBpc3N1ZXMgYW5kIGhvdyB0aGV5IGFyZSBkZWFs dCB3aXRoLiAgVGhhdCBpcyBwcmVjaXNlbHkgd2hhdCB3ZSBwcm9wb3NlLg0KPiBXZSdsbCBkZWZp bmUgc29tZSBvZiB0aGVtIGluIGxvY2F0aW9uLWNvbnZleWFuY2UsIGFuZCBzcGVjaWZ5IGhvdyBh DQo+IHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudCBhZGRzIG1vcmUgcG9zc2liaWxpdGllcy4NCj4g DQo+IFBsZWFzZSBub3RlIHRoYXQgd2UgZG9uJ3Qgd2FudCBhIGxvdCBvZiBwb3NzaWJpbGl0aWVz IGhlcmU7IGV2ZXJ5DQo+IGRlcmVmZXJlbmNlciBoYXMgdG8gaW1wbGVtZW50IGFsbCBjaG9pY2Vz Lg0KPiANCj4gSW5jaWRlbnRhbGx5LCBJIHRoaW5rIHdlIHdpbGwgc3BlY2lmeSBpbiB0aGUgbGFu Z3VhZ2UgdGhhdCBhbiBleHRlbnNpb24gdG8NCj4gdGhlIGFsbG93ZWQgVVJJcyBpbiBhIExvY2F0 aW9uIGhlYWRlciBpcyBOT1QgYSBTSVAgZXh0ZW5zaW9uLCBhbmQgZG9lcyBub3QNCj4gY29tZSB1 bmRlciB0aGUgMzQyNyBwcm9jZXNzLiAgIFRoaXMgd291bGQgYWxsb3cgZ2VvcHJpdiwgZm9yIGV4 YW1wbGUsIHRvDQo+IGRlZmluZSB0aGUgTDcgcHJvdG9jb2wsIGFuZCBpZiBpdCBoYXMgYSBsb2Nh dGlvbi1ieS1yZWZlcmVuY2UgY29uc3RydWN0aW9uDQo+IHdpdGggYSBkZXJlZmVyZW5jaW5nIHBy b2NlZHVyZSwgaXQgd291bGQgYmUgYWxsb3dlZCB0byBhZGQgdG8gdGhlIG1ldGhvZHMNCj4gbGlz dGVkIGluIGxvY2F0aW9uLWNvbnZleWFuY2Ugd2l0aG91dCBydW5uaW5nIHRocm91Z2ggMzQyNy4g IFRoYXQNCj4gbGFuZ3VhZ2UsDQo+IHNpbmNlIGl0IGlzIHBhcnQgb2Ygc2lwLWxvY2F0aW9uLCB3 b3VsZCBoYXZlIHRvIGJlIGFjY2VwdGFibGUgdG8NCj4gc2lwL3NpcHBpbmcuDQo+IA0KPiBBZ3Jl ZSB0aGF0IHRoZSBpZGVudGl0eSBpc3N1ZXMgb2YgVVJMIGNvbnN0cnVjdGlvbiBhcmUgZ2VuZXJp YyBhbmQgY2FuIGJlDQo+IHRyZWF0ZWQgaW4gdGhlIHRleHQgYXMgZ2VuZXJpYywgbm90IHRpZWQg dG8gYW55IHBhcnRpY3VsYXIgc2NoZW1lLiAgSXQgbWF5DQo+IGJlIG1vcmUgbGlrZWx5IGluIHBy ZXo6LCBzaW1wbHkgYmVjYXVzZSB0aGUgZGVmYXVsdCB0eXBlIG9mIHVyaSBpcyBhbiBBb1IsDQo+ IHdoaWNoIGFsbW9zdCBhbHdheXMgaGFzIGlkZW50aXR5IGRhdGEuDQo+IA0KPiBCcmlhbg0KPiAN Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFRob21zb24sIE1hcnRp biBbbWFpbHRvOk1hcnRpbi5UaG9tc29uQGFuZHJldy5jb21dDQo+ID4gU2VudDogV2VkbmVzZGF5 LCBKdWx5IDE5LCAyMDA2IDc6MzYgUE0NCj4gPiBUbzogQnJpYW4gUm9zZW47IHNpcEBpZXRmLm9y Zw0KPiA+IFN1YmplY3Q6IFJFOiBbU2lwXSBBbGxvd2luZyBzaXA6IChvciBwcmV6OikgaW4gdGhl IGxvY2F0aW9uIGhlYWRlcg0KPiA+DQo+ID4gQnJpYW4sDQo+ID4NCj4gPiBZZXMsIHlvdSBjYW4g dXNlIGEgc2lwOiBvciBwcmVzOiBVUkkgdG8gcmV0cmlldmUgbG9jYXRpb24gYnktcmVmZXJlbmNl Lg0KPiA+IEl0IHdvcmtzLiAgWWVzLCB5b3UgY2FuIHVzZSBhIHB1bGwgbWV0aG9kIHRvIHJldHJp ZXZlIHRoZSBpbmZvcm1hdGlvbjsNCj4gPiB0aGF0J3MgYSBmZWF0dXJlIG9mIFNVQlNDUklCRS9O T1RJRlkuICBJIHNlZSBubyByZWFzb24gdG8gcHJldmVudCB0aGlzLA0KPiA+IGJ1dCB5b3UgZG9u J3QgYWN0dWFsbHkgaGF2ZSB0byBkb2N1bWVudCBldmVyeSBwb3NzaWJsZSByZXRyaWV2YWwgbWV0 aG9kLg0KPiA+DQo+ID4gSWRlbnRpdHkgbWlnaHQgYmUgYSBwcm9ibGVtLCBidXQgdGhhdCBjYW4g YmUgYWRkcmVzc2VkIGJ5IHRoZSB1c2Ugb2YNCj4gPiB1bmxpbmtlZCBwc2V1ZG9ueW1zLiAgVGhp cyBpcyBub3Qgc3BlY2lmaWMgdG8gdGhlIGRlcmVmZXJlbmNlIG1ldGhvZC4NCj4gVGhlDQo+ID4g c2FtZSBwcm9ibGVtIGV4aXN0cyBubyBtYXR0ZXIgaG93IHlvdSByZXNvbHZlIGxvY2F0aW9uIC0g b3IgYXJlIHlvdQ0KPiA+IHN1Z2dlc3RpbmcgdGhhdCB0aGUgc2lwOiBvciBwcmVzOiBVUklzIGRl cmVmZXJlbmNlIHRvIGEgUElERi1MTywgYnV0DQo+IG90aGVyDQo+ID4gZm9ybXMgd291bGQgbm90 PyAgQ2xlYXJseSwgdGhhdCBwcm9ibGVtIGFscmVhZHkgZXhpc3RzIHdpdGggdGhlIGNpZDogVVJM DQo+ID4gYW5kIHNob3VsZCBleGlzdCB3aXRoIHRoZSBodHRwczogVVJMLg0KPiA+DQo+ID4gV2hh dCBJIHRha2UgZnJvbSB0aGlzIGlzIHRoYXQgeW91IG5lZWQgdG8gaGF2ZSB0ZXh0IHRoYXQgZXhw bGFpbnMgdGhlDQo+ID4gaW1wYWN0IG9mIHRoZSBhc3NvY2lhdGlvbiBiZXR3ZWVuIGlkZW50aXR5 IGFuZCBsb2NhdGlvbi4gIFRob3NlIGNvbmNlcm5zDQo+ID4gYXJlIGxhcmdlbHkgY292ZXJlZCBi eSBvdGhlciBHRU9QUklWIGRvY3VtZW50cywgYnV0IHRoZXJlIGlzIG5vIGhhcm0gaW4NCj4gPiBi ZWluZyBleHBsaWNpdC4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNYXJ0aW4NCj4gPg0KPiA+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IEJyaWFuIFJvc2VuIFttYWls dG86YnJAYnJpYW5yb3Nlbi5uZXRdDQo+ID4gPiBTZW50OiBUaHVyc2RheSwgMjAgSnVseSAyMDA2 IDg6NDYgQU0NCj4gPiA+IFRvOiBzaXBAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFtTaXBdIEFs bG93aW5nIHNpcDogKG9yIHByZXo6KSBpbiB0aGUgbG9jYXRpb24gaGVhZGVyDQo+ID4gPg0KPiA+ ID4gU3VwcG9zZSB3ZSBhbGxvd2VkIHNpcDogb3IgcHJlejogYXMgdGhlIGxvY2F0aW9uIGhlYWRl ciBVUkkuICBUaGUNCj4gPiA+IHJlc29sdXRpb24NCj4gPiA+IG9mIHRoaXMgc2NoZW1lIHdvdWxk IGJlICJzdWJzY3JpYmUgdG8gcHJlc2VuY2UiLg0KPiA+ID4NCj4gPiA+IE5vdGUgdGhhdCBpZiB5 b3UgYXNrZWQgZm9yIGltbWVkaWF0ZSBleHBpcmF0aW9uICgwKSwgeW91IHdpbGwgZ2V0IHRoZQ0K PiA+ID4gaW1tZWRpYXRlIE5PVElGWS4gIFRoaXMgY29uc3RpdHV0ZXMgb25lIHJlYXNvbmFibGUg d2F5IHRvIHByb3ZpZGUNCj4gPiA+IGxvY2F0aW9uLWJ5LXJlZmVyZW5jZS4gIEl0IGlzIGEgZm9y bSBvZiAicHVsbCIgKHlvdSBzZW5kIGEgU1VCU0NSSUJFLA0KPiA+IHlvdQ0KPiA+ID4gZ2V0IG9u ZSBOT1RJRlkgaW4gcmV0dXJuIHdpdGggdGhlIFBJREYtTE8pLiAgSWYgeW91ciBzdWJzY3JpcHRp b24gaGFzDQo+IGENCj4gPiA+IGxvbmdlciBleHBpcmF0aW9uLCBpdCBpcyBhIGZvcm0gb2YgInB1 c2giLCBhbmQgeW91IG1pZ2h0IHdhbnQgdG8gaGF2ZQ0KPiBhDQo+ID4gPiBmaWx0ZXIgdG8gbGlt aXQgaG93IG1hbnkgcHVzaGVzIHlvdSBnZXQuDQo+ID4gPg0KPiA+ID4gTm90ZSB0aGF0IG5vcm1h bGx5LCBwcmVzZW5jZSBwcm92aWRlcyBpZGVudGl0eSBhcyB3ZWxsIGFzIGxvY2F0aW9uLg0KPiBJ dA0KPiA+ID4gbWF5DQo+ID4gPiBiZSB0aGF0IGluIHNvbWUgdXNlcyBmb3IgdGhlIExvY2F0aW9u IGhlYWRlciwgc3VjaCBhcyBhIGxvY2F0aW9uIGJhc2VkDQo+ID4gPiByb3V0aW5nLCB0aGUgaWRl bnRpdHkgaW5mb3JtYXRpb24gaXMgbm90IGFwcHJvcHJpYXRlLiAgVGhlIHBvbGljeSBvZg0KPiB0 aGUNCj4gPiA+IHByZXNlbmNlIHNlcnZlciBmb3IgdGhhdCB1c2UgbWF5IGJlIHRvIG9ubHkgcmV0 dXJuIHRoZSBMTyBwYXJ0IG9mIHRoZQ0KPiA+ID4gUElERi4NCj4gPiA+IEFsc28gbm90ZSB0aGF0 IHRoZSBmb3JtIG9mIHRoZSBVUkkgaXRzZWxmIGNvdWxkIGluYWR2ZXJ0ZW50bHkgcHJvdmlkZQ0K PiA+ID4gaWRlbnRpdHkgaW5mb3JtYXRpb24gKHByZXo6YnJpYW4ucm9zZW5AbmV1c3Rhci5iaXop LCB3aGljaCBtaWdodCBub3QNCj4gYmUNCj4gPiA+IGRlc2lyYWJsZS4gIElmIHRoZSBpZGVhIHRv IGFsbG93IHNpcDogYW5kIHByZXo6IGlzIGFjY2VwdGFibGUgaW4gdGhlDQo+ID4gPiBMb2NhdGlv biBoZWFkZXIgVVJJLCB0aGUgdGV4dCB3b3VsZCBjb250YWluIGEgZGlzY3Vzc2lvbiBvZiB0aGlz DQo+IGlzc3VlLg0KPiA+ID4NCj4gPiA+IEJyaWFuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBTaXAgbWFp bGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXANCj4g PiA+IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90 b2NvbA0KPiA+ID4gVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVz dGlvbnMgb24gY3VycmVudCBzaXANCj4gPiA+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcg ZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCj4gPg0KPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiAtLQ0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBUaGlzIG1lc3Nh Z2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCj4gPiBjb250 YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1h dGlvbi4NCj4gPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyDQo+ID4gaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBB bnkgdW5hdXRob3JpemVkIHVzZSBvZg0KPiA+IHRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCj4g PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4g W21mMl0NCj4gDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhp cyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpj b250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZv cm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkg dW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ== --===============1193493571== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1193493571==-- From sip-bounces@ietf.org Wed Jul 19 20:37:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3MWB-0006zn-O2; Wed, 19 Jul 2006 20:35:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3MW9-0006xj-Tg; Wed, 19 Jul 2006 20:35:53 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3MW9-0000pr-FN; Wed, 19 Jul 2006 20:35:53 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3MTX-0002Rz-7v; Wed, 19 Jul 2006 19:33:12 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "Rosen, Brian" , Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location header URI- http Date: Wed, 19 Jul 2006 20:33:17 -0400 Message-ID: <02c701c6ab94$1a18a4d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acareu0r7/hzUt4KSMaSljrF58lp2gADxGNwAAD2RlAAAFWXUAAALkMQAABAvKAAAKrn0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Suppose the L7 protocol defines an optional parameter foo. What is the dereferencer to do? If it tries foo, but the URI is to a raw GET processor, it will get a generic error. There is nothing else it could do though, since it can't tell from anything it has that foo is optional, but legal. A registry and a parameter would tell it that foo is legal (if it was an L7 protocol URI). I'm not excluding a simple GET; I'm just advocating a parameter and a registry that says it IS a simple GET. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, July 19, 2006 8:15 PM > To: Rosen, Brian; Brian Rosen; sip@ietf.org > Cc: geopriv@ietf.org > Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location > header URI- http > > > What it means is that you MUST provide a Get mechanism with no > parameters, you MAY provide anything you like on top of that. If you are > prepared to take the hit with trying something specific first then that > is your prerogative, or you may decide to do the GET first, and > something special as a second-try, which is also okay. I simply don't > agree with your reasoning to exclude a simple GET mechanism now. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Thursday, 20 July 2006 10:09 AM > > To: Winterbottom, James; Brian Rosen; sip@ietf.org > > Cc: geopriv@ietf.org > > Subject: RE: [Sip] RE: [Geopriv] More on the contents of the Location > > header URI- http > > > > Actually, it means that a base GET/return PIDF is ALL you could > > implement; you can't get anything back from the PIDF that would tell > you > > anything else is acceptable, and you can't tell from the URI. > > > > That would mean a SOAP based mechanism could never be specified, for > > example. You couldn't have an optional parameter unless you were > > prepared to try it, have it fail, and then try something else. > > > > Brian > > > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Wednesday, July 19, 2006 8:00 PM > > > To: Brian Rosen; Rosen, Brian; sip@ietf.org > > > Cc: geopriv@ietf.org > > > Subject: RE: [Sip] RE: [Geopriv] More on the contents of the > Location > > > header URI- http > > > > > > Providing all mechanisms support a base GET AND they return a > PIDF-LO > > > there is no problem. That is all that needs to be said. > > > > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, 20 July 2006 9:52 AM > > > > To: Winterbottom, James; Rosen, Brian; sip@ietf.org > > > > Cc: geopriv@ietf.org > > > > Subject: RE: [Sip] RE: [Geopriv] More on the contents of the > > Location > > > > header URI- http > > > > > > > > The problem is that HTTP is used as a transport protocol by > several > > > > mechanisms, and you need to know from the contents of the location > > > header > > > > which mechanism is used. Is it SOAP, raw GET, LCP, RELO, HELD or > > > > something > > > > else, all of which would say "https:blahblah"? > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > > Sent: Wednesday, July 19, 2006 7:26 PM > > > > > To: Rosen, Brian; sip@ietf.org > > > > > Cc: geopriv@ietf.org > > > > > Subject: [Sip] RE: [Geopriv] More on the contents of the > Location > > > header > > > > > URI- http > > > > > > > > > > Brian, > > > > > > > > > > I am not sure that I agree with you on this one. > > > > > The problem is not in the request protocol at all, the GET works > > > fine > > > > > providing the return type is always a PIDF-LO. > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > > -----Original Message----- > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > > > Sent: Thursday, 20 July 2006 7:33 AM > > > > > > To: sip@ietf.org > > > > > > Cc: geopriv@ietf.org > > > > > > Subject: [Geopriv] More on the contents of the Location header > > URI > > > - > > > > > http > > > > > > > > > > > > I started a discussion of what can be in the location header > > > besides a > > > > > > cid:. > > > > > > We remain convinced that AbsoluteURI is a poor choice; we must > > be > > > more > > > > > > specific, including privacy concerns. > > > > > > > > > > > > It is now clear that simply saying "https:" is not enough. > > There > > > > > could > > > > > > be multiple location resolution protocols that use http > > transport. > > > We > > > > > > need something else that would differentiate which one. The > > > simple > > > > > GET > > > > > > mechanism we proposed would need at least a parameter of some > > > sort. > > > > > > > > > > > > After thinking about it for a while, I think the best > resolution > > > is > > > > > > Andy's suggestion of a registry, used in conjunction with a > > > parameter. > > > > > > I'm ambivalent on whether the parameter is a URI parameter or > a > > > > > > parameter on the Location header. We would define the > registry > > > (and > > > > > the > > > > > > parameter) in location-conveyance and create one entry (the > > simple > > > GET > > > > > > with PIDF-LO return). It may be, for example, that the > proposed > > > L7 > > > > > > location acquisition protocol defines another http based > > > resolution > > > > > > protocol. That document could define another entry in the > > > registry. > > > > > > > > > > > > Brian > > > > > > > > > > > > _______________________________________________ > > > > > > Geopriv mailing list > > > > > > Geopriv@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > This message is for the designated recipient only and may > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > If you have received it in error, please notify the sender > > > > > immediately and delete the original. Any unauthorized use of > > > > > this email is prohibited. > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > [mf2] > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on current > sip > > > > > Use sipping@ietf.org for new developments on the application of > > sip > > > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 02:06:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ReE-0003Sg-N3; Thu, 20 Jul 2006 02:04:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ReD-0003SX-8r for sip@ietf.org; Thu, 20 Jul 2006 02:04:33 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ReB-0000o8-M1 for sip@ietf.org; Thu, 20 Jul 2006 02:04:33 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k6K64QLf014915; Thu, 20 Jul 2006 08:04:26 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k6K64QGt029320; Thu, 20 Jul 2006 08:04:26 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 08:04:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Security mechanism? Date: Thu, 20 Jul 2006 08:04:25 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Security mechanism? thread-index: Acardt+jZYx9eoMLRFWykyXYjDXHAwASwv2Q From: "Fries, Steffen" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 20 Jul 2006 06:04:26.0370 (UTC) FILETIME=[5AE68620:01C6ABC2] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, there have been discussions about reusing a symmetric key for S/MIME in the SIPPING area a while ago. The draft is meanwhile expired but maybe interesting for this. Ist draft-ono-sipping-smime-keyreuse-01.txt =20 Ciao Steffen > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Wednesday, July 19, 2006 11:03 PM > To: fwmiller@cornfed.com > Cc: sip@ietf.org > Subject: Re: [Sip] SIP Security mechanism? >=20 > Hi, >=20 > it is true that the recent security work in SIP focused on=20 > media security. >=20 > Some of the proposed mechanisms could also provide security=20 > for SIP signaling if signaling messages are exchanged between=20 > the end points (after the initial exchange via proxies that=20 > carries, for example, a finger print attribute). >=20 > Ciao > Hannes >=20 >=20 > fwmiller@cornfed.com wrote: > > The idea is the general concept of doing some kind of key exchange=20 > > between the UAs prior to doing signaling. This would address the=20 > > problem of maintaining the public key infrastructure. > >=20 > > If that particular algorithm and key set does not work,=20 > perhaps some=20 > > algoritm that had the "UAS" generate an asymmetric public key=20 > > dynamically would work. The key exchange could be for each=20 > endpoint=20 > > to have the other endpoint generate an asymmetric key? I'm not a=20 > > crypto person but this seems like it might be doable, does=20 > any crypto=20 > > person here know of how that could be done? > >=20 > >=20 > > FM > >=20 > >=20 > >=20 > > ------------------------------------------------ On Wed, 19 Jul 2006 > > 21:37:47 +0200, Hannes Tschofenig wrote: > >=20 > >=20 > >> If you run a DH then the outcome is a symmetric key.=20 > S/MIME does not=20 > >> work with symmetric keys. > >>=20 > >> Ciao Hannes > >>=20 > >> fwmiller@cornfed.com wrote: > >>=20 > >>> I've been reading about the ZRTP lately. I read=20 > Henning's comment=20 > >>> at the IETF meeting about how S/MIME relies on the=20 > receiver's public=20 > >>> key to be available to allow for encryption/decryption to work. > >>>=20 > >>> Why couldnt we put in place a mechanism that did a key=20 > exchange for=20 > >>> SIP signaling similar to whats done in ZRTP (i.e. modified > >>> Diffie-Hellman) prior to any signaling traffic, then use the=20 > >>> exchanged keys as the basis for S/MIME encryption of the bodies? > >>> Or we could even get really carried away and use it to do=20 > encryption=20 > >>> of the entire SIP message if the signaling did not=20 > traverse proxies?=20 > >>> This could be useful for encrypting UDP signaling, again=20 > if no proxy=20 > >>> were involved. > >>>=20 > >>> Thoughts? FM > >>>=20 > >>>=20 > >>> _______________________________________________ Sip mailing list=20 > >>> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW=20 > >>> development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current=20 > sip Use =20 > >>> sipping@ietf.org for new developments on the application of sip > >>>=20 > >>>=20 > >>=20 > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 04:21:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Tl9-0005cZ-5j; Thu, 20 Jul 2006 04:19:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Tl8-0005bH-8X for sip@ietf.org; Thu, 20 Jul 2006 04:19:50 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3Thz-0006OS-4l for sip@ietf.org; Thu, 20 Jul 2006 04:16:35 -0400 Received: (qmail invoked by alias); 20 Jul 2006 08:09:53 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp021) with SMTP; 20 Jul 2006 10:09:53 +0200 X-Authenticated: #29516787 Message-ID: <44BF3A4F.9020602@gmx.net> Date: Thu, 20 Jul 2006 10:09:51 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen References: <026c01c6ab79$9fe2a0e0$640fa8c0@cis.neustar.com> In-Reply-To: <026c01c6ab79$9fe2a0e0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: geopriv@ietf.org, sip@ietf.org, "'Ecrit@Ietf. Org'" Subject: [Sip] Re: [Geopriv] Routing of calls based on location X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Brian, thanks for raising this issue. Please find my comments below: Brian Rosen wrote: > NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU REPLY, SEND IT ONLY TO > GEOPRIV > > The SIP Location Conveyance document anticipates the ability to route a call > based on the location of the caller. The original impetus for this is > emergency calling. In ecrit, a mechanism has been defined (LoST) that takes > a service request (in the form of a newly defined service urn) and a > location and returns a URI. This mechanism is not limited to emergency > calling, and could be used for arbitrary location based routing by defining > new service urns. > > However, this opens up the issue of geopriv privacy concerns because the > sender does not know the identity of the element (proxy) that will route the > call using LoST. It may be that the UAC itself does this, but it may be > some other intermediary. Actually, I think we need to be a bit more precise here. There are two cases: (a) End Host runs LoST (b) Proxy runs LoST In case of (a) there is no problem. The problem starts with (b). This was actually one of the reasons why I started the mailing list threat about ' Explicit Indication of Location Object Consumer' (see http://www1.ietf.org/mail-archive/web/sip/current/msg14356.html). > > If the identity of the intermediary is not known, then protecting the > location information becomes more difficult, because we cannot encrypt using > keying material from the intended recipient. In many cases the identity of the intermediary is known with (b) since it is the outbound proxy. The identity of the final recipient is for sure not known. In fact there are at least two intendent recipients here: * final recipient (i.e., the entity behind the URI returned by LoST) * proxy that needs to inspect location information in order to perform location based routing. So, in previous mailing list conversations we discussed whether these two entities should be treated separately, i.e., by putting two PIDF-LOs in the message; one for the intermediary and one for the end point. From a security point of view it seems to be a waste because you might not know both entities in advance anyway. In fact, we would need to use > hop-by-hop security, with transitive trust. You might be able to know the location based routing proxy. What happens if you send a SIP signaling message with a service URN parameter to your outbound proxy but it does not have the location-based routing capability? In some sense you need to know already ahead of time whether this functionality is support. This is what the emergency case > does, but it also allows no channel security if necessary (usually meaning, > try it with TLS and if that fails, try again without TLS). The emergency case is somewhat special because you additionally have to consider what happens if none of the security works/can be used. > > We propose to explicitly allow hop-by-hop security when sending location > using SIP for the purpose of location based routing. We will specify you > MUST use TLS if sending location by reference (and there will be some words > about the choice of URI construction which is raised in another email I am > about to send). I think that this is largely orthogonal issue. > > An important issue that we need to discuss is what "Do Not Distribute" means > in this case. We would like it to allow the data to be passed onward. > Indeed, SIP proxies shouldn't be dropping headers. We propose that it means > that it cannot be distributed except that the location header (and body of > course) is passed as it normally would. Let us look at the scenario where the end host attaches location information. It would set the policies and then it knows that he is going to request an intermediary to perform location-based routing. In this case preventing further distribution of the PIDF-LO would essentially mean that the proxy removes it and sends the message to the URI provided by LoST. Now, it depends on the application whether this is a desired functionality but I could imagine it is. I might want to find the nearest "something" but I don't want to tell them where I am because it is not relevant for them. This does not apply to emergency calls but that's a separate story. In fact there more than just remove the PIDF-LO or keep it. In some sense this aspect is similar to the discussed usage of 2 PIDF-LOs in a message where one is used for routing and the other one is used for the final recipient (both might have a different precision). The proxy might also be told to reduce the granularity of location information by the user before forwarding the message. > Note that although this is an issue that concerns the SIP working group, > because the location conveyance document is a sip document, it really is a > geopriv issue. It also affects ecrit, since we are using its protocol > beyond its initial purpose. We ask that this discussion be held on the > geopriv list, and not copied to either sip or ecrit. > > Brian Ciao Hannes > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 05:34:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Utw-00024N-2e; Thu, 20 Jul 2006 05:33:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Utt-0001z5-KB for sip@ietf.org; Thu, 20 Jul 2006 05:32:57 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3Uts-0004cP-66 for sip@ietf.org; Thu, 20 Jul 2006 05:32:57 -0400 Received: (qmail invoked by alias); 20 Jul 2006 09:32:55 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp028) with SMTP; 20 Jul 2006 11:32:55 +0200 X-Authenticated: #29516787 Message-ID: <44BF4DBF.9080407@gmx.net> Date: Thu, 20 Jul 2006 11:32:47 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] Allowing sip: (or prez:) in the location header References: <028c01c6ab85$1422e8b0$640fa8c0@cis.neustar.com> In-Reply-To: <028c01c6ab85$1422e8b0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Brian, in a previous mail discussion you told me that we should not create new requirements on the fly. We are very early in the discussion about the Subscription URI concept in the Geopriv-L7 design team. It will take much longer to discuss it. It would make more sense to compile a separate draft, if someone wants it. In the location conveyance document I would like to see a simple HTTPS based mechanism (if you think that the proxy behavior belongs into this document). This would prevent further delaying the document. Ciao Hannes Brian Rosen wrote: > Suppose we allowed sip: or prez: as the location header URI. The resolution > of this scheme would be "subscribe to presence". > > Note that if you asked for immediate expiration (0), you will get the > immediate NOTIFY. This constitutes one reasonable way to provide > location-by-reference. It is a form of "pull" (you send a SUBSCRIBE, you > get one NOTIFY in return with the PIDF-LO). If your subscription has a > longer expiration, it is a form of "push", and you might want to have a > filter to limit how many pushes you get. > > Note that normally, presence provides identity as well as location. It may > be that in some uses for the Location header, such as a location based > routing, the identity information is not appropriate. The policy of the > presence server for that use may be to only return the LO part of the PIDF. > Also note that the form of the URI itself could inadvertently provide > identity information (prez:brian.rosen@neustar.biz), which might not be > desirable. If the idea to allow sip: and prez: is acceptable in the > Location header URI, the text would contain a discussion of this issue. > > Brian > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 06:02:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3VKp-0003NK-MD; Thu, 20 Jul 2006 06:00:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3VKn-0003Eh-Nf for sip@ietf.org; Thu, 20 Jul 2006 06:00:45 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3VKl-0006og-W9 for sip@ietf.org; Thu, 20 Jul 2006 06:00:45 -0400 Received: (qmail invoked by alias); 20 Jul 2006 09:54:02 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp018) with SMTP; 20 Jul 2006 11:54:02 +0200 X-Authenticated: #29516787 Message-ID: <44BF52B8.3040609@gmx.net> Date: Thu, 20 Jul 2006 11:54:00 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] RE: [Geopriv] More on the contents of the Location header URI- http References: <02b901c6ab8e$55e22eb0$640fa8c0@cis.neustar.com> In-Reply-To: <02b901c6ab8e$55e22eb0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.6 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip@ietf.org, "Rosen, Brian" , geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That's fine and there are ways to address this issue. A registry would be fine for me with a single mandatory to implement mechanism. Ciao Hannes Brian Rosen wrote: > The problem is that HTTP is used as a transport protocol by several > mechanisms, and you need to know from the contents of the location header > which mechanism is used. Is it SOAP, raw GET, LCP, RELO, HELD or something > else, all of which would say "https:blahblah"? > > Brian > > >>-----Original Message----- >>From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] >>Sent: Wednesday, July 19, 2006 7:26 PM >>To: Rosen, Brian; sip@ietf.org >>Cc: geopriv@ietf.org >>Subject: [Sip] RE: [Geopriv] More on the contents of the Location header >>URI- http >> >>Brian, >> >>I am not sure that I agree with you on this one. >>The problem is not in the request protocol at all, the GET works fine >>providing the return type is always a PIDF-LO. >> >>Cheers >>James >> >> >>>-----Original Message----- >>>From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>Sent: Thursday, 20 July 2006 7:33 AM >>>To: sip@ietf.org >>>Cc: geopriv@ietf.org >>>Subject: [Geopriv] More on the contents of the Location header URI - >> >>http >> >>>I started a discussion of what can be in the location header besides a >>>cid:. >>>We remain convinced that AbsoluteURI is a poor choice; we must be more >>>specific, including privacy concerns. >>> >>>It is now clear that simply saying "https:" is not enough. There >> >>could >> >>>be multiple location resolution protocols that use http transport. We >>>need something else that would differentiate which one. The simple >> >>GET >> >>>mechanism we proposed would need at least a parameter of some sort. >>> >>>After thinking about it for a while, I think the best resolution is >>>Andy's suggestion of a registry, used in conjunction with a parameter. >>>I'm ambivalent on whether the parameter is a URI parameter or a >>>parameter on the Location header. We would define the registry (and >> >>the >> >>>parameter) in location-conveyance and create one entry (the simple GET >>>with PIDF-LO return). It may be, for example, that the proposed L7 >>>location acquisition protocol defines another http based resolution >>>protocol. That document could define another entry in the registry. >>> >>>Brian >>> >>>_______________________________________________ >>>Geopriv mailing list >>>Geopriv@ietf.org >>>https://www1.ietf.org/mailman/listinfo/geopriv >> >>-------------------------------------------------------------------------- >>---------------------- >>This message is for the designated recipient only and may >>contain privileged, proprietary, or otherwise private information. >>If you have received it in error, please notify the sender >>immediately and delete the original. Any unauthorized use of >>this email is prohibited. >>-------------------------------------------------------------------------- >>---------------------- >>[mf2] >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 08:12:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XMJ-0000AG-AG; Thu, 20 Jul 2006 08:10:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XMH-00008j-HQ for sip@ietf.org; Thu, 20 Jul 2006 08:10:25 -0400 Received: from mail.tieto.com ([194.110.47.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Vsu-0002DR-B8 for sip@ietf.org; Thu, 20 Jul 2006 06:36:03 -0400 Received: from camaro.eu.tieto.com ([192.176.143.43]) by mail.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 13:37:10 +0300 Received: from carrera.eu.tieto.com ([192.176.158.112]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 12:35:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jul 2006 12:35:52 +0200 Message-ID: <3ACC9A25264A684F82C71840111F979801EC6119@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How to distinguish parameters in To header Thread-Index: Acar6EZCpW86PuA5SJGa+D0jjX0K2g== From: To: X-OriginalArrivalTime: 20 Jul 2006 10:35:54.0474 (UTC) FILETIME=[475DF4A0:01C6ABE8] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Sip] How to distinguish parameters in To header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, there is some weird thing aroud To header (analogously all headers of the similar form). Consider now To header. Its grammar is the following: To =3D ( "To" / "t" ) HCOLON ( name-addr / addr-spec ) *( SEMI to-param = ) where to-param =3D tag-param / generic-param tag-param =3D "tag" EQUAL token name-addr =3D [ display-name ] LAQUOT addr-spec RAQUOT addr-spec =3D SIP-URI / SIPS-URI / absoluteURI SIP-URI =3D "sip:" [ userinfo ] hostport uri-parameters [ headers ] uri-parameters =3D *( ";" uri-parameter) The problem lies in the fact that both To header and SIP-URI may have own parameters. Using above mentioned grammar there is possibility to construct To header where there is no chance to distinguish between SIP-URI parameters and To header parameters. Se example bellow: SIP-URI =3D sip:wolf@fairytale.com;uriparam=3Dvalue Additional To header param =3D tparam=3Dvalue and the complete and valid header is To: sip:wolf@fairytale.com;uriparam=3Dvalue;tparam=3Dvalue and again, there is now no chance to distinguish whether - all parameters are SIP-URI specific - one parameter is SIP-URI specific and one To header specific - all parameters are To header specific br, Martin +-------------------------------------+ Martin Hynar Software Specialist TietoEnator Czech Software Center Phone: +420 599 096 022 Mobile: +420 724 035 397 E-mail: Martin.Hynar@TietoEnator.com Vystavni 292/13 CZ-709 16 Ostrava www.tietoenator.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 08:13:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XND-0001gi-CE; Thu, 20 Jul 2006 08:11:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XNB-0001fr-Oa for sip@ietf.org; Thu, 20 Jul 2006 08:11:21 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3XNA-0006rD-H7 for sip@ietf.org; Thu, 20 Jul 2006 08:11:21 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6KCBJuJ014557 for ; Thu, 20 Jul 2006 07:11:19 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ987DA>; Thu, 20 Jul 2006 13:11:19 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29099D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@ietf.org'" Date: Thu, 20 Jul 2006 13:11:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sip] draft-ietf-sip-outbound and STUN keepalives X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) Previous mails on the SIP list have expressed the view that the STUN keepalive mechanism should be documented separately as it is a useful mechanism in its own right. See http://www3.ietf.org/proceedings/06jul/slides/sip-5.pdf slide 5 for the issue as raised at the IETF #66 meeting. After discussion with the editor, the WG chairs propose the following: - that the documentation on STUN keepalive will REMAIN in the outbound document, and WILL NOT be split to a separate specification; - that the STUN keepalive mechanism WILL BE separated within the outbound specification, such that it is clear that it can be implemented independently of the rest of the outbound specification, and so that the keepalive material is clearly referencable in its own right. We believe that this meets the requirements of at least most of the working group, and for pragmatic reasons we want to work against more fragmentation of the SIP documentation. If you have problems with this proposal and desire a different solution, then please raise your concerns to the list, or direct to the WG chairs, in response to this mail. regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 08:31:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XeQ-0005Dl-Lf; Thu, 20 Jul 2006 08:29:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XeO-0005D3-Ng for sip@ietf.org; Thu, 20 Jul 2006 08:29:08 -0400 Received: from mail2.abbeynet.it ([151.9.176.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Xd7-00009R-47 for sip@ietf.org; Thu, 20 Jul 2006 08:27:50 -0400 Received: from mail2.abbeynet.it (localhost.localdomain [127.0.0.1]) by mail2.abbeynet.it (Postfix) with SMTP id BFBE350B36 for ; Thu, 20 Jul 2006 14:27:43 +0200 (CEST) Received: from [192.168.0.74] (marco-ambu.localnet [192.168.0.74]) by mail2.abbeynet.it (Postfix) with ESMTP id AFFD450B36 for ; Thu, 20 Jul 2006 14:27:43 +0200 (CEST) Message-ID: <44BF76C0.1030208@abbeynet.it> Date: Thu, 20 Jul 2006 14:27:44 +0200 From: Marco Ambu User-Agent: Mozilla Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 Cc: sip@ietf.org Subject: Re: [Sip] How to distinguish parameters in To header References: <3ACC9A25264A684F82C71840111F979801EC6119@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F979801EC6119@carrera.eu.tieto.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Martin.Hynar@tietoenator.com ha scritto: > Hi, > > there is some weird thing aroud To header (analogously all headers of > the similar form). Consider now To header. Its grammar is the following: > > To = ( "To" / "t" ) HCOLON ( name-addr / addr-spec ) *( SEMI to-param ) > > where > to-param = tag-param / generic-param > tag-param = "tag" EQUAL token > name-addr = [ display-name ] LAQUOT addr-spec RAQUOT > addr-spec = SIP-URI / SIPS-URI / absoluteURI > > SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] > uri-parameters = *( ";" uri-parameter) > > > The problem lies in the fact that both To header and SIP-URI may have > own parameters. Using above mentioned grammar there is possibility to > construct To header where there is no chance to distinguish between > SIP-URI parameters and To header parameters. Se example bellow: > > SIP-URI = sip:wolf@fairytale.com;uriparam=value > Additional To header param = tparam=value > > and the complete and valid header is > To: sip:wolf@fairytale.com;uriparam=value;tparam=value > > and again, there is now no chance to distinguish whether > - all parameters are SIP-URI specific > - one parameter is SIP-URI specific and one To header specific > - all parameters are To header specific > > > br, Martin > > Fortunately the way to distinguish URI parameters from header parameters exists! This thread has been already discussed in sip-implementors mailing list, so you can check the mailing list archives. RFC 3261 - 20.10 "When the header field value contains a display name, the URI including all URI parameters is enclosed in "<" and ">". If no "<" and ">" are present, all parameters after the URI are header parameters, not URI parameters." [cut] "Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, semicolon, or question mark." [cut] "These rules for parsing a display name, URI and URI parameters, and header parameters also apply for the header fields To and From." So if URI is in the addr-spec form (is not encolsed in "<" and ">") all the parameters are header parameters. To: sip:wolf@fairytale.com;uriparam=value -> "uriparam" is a header parameter To: ;headerparam=value2 -> "uriparam" is an URI parameter and "headerparam" is a header parameter. -- Marco Ambu Abbeynet S.p.a. E-mail: marco.ambu@abbeynet.it VoIP address: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 08:31:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XfL-0005iN-Sp; Thu, 20 Jul 2006 08:30:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XfK-0005h7-L9 for sip@ietf.org; Thu, 20 Jul 2006 08:30:06 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3XWG-0008ON-7t for sip@ietf.org; Thu, 20 Jul 2006 08:20:45 -0400 Received: from [71.161.52.216] (helo=JMHLap3.stevecrocker.com) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1G3XWG-0005FA-33 for sip@ietf.org; Thu, 20 Jul 2006 08:20:44 -0400 Message-Id: <7.0.1.0.0.20060720082001.03e557c0@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 20 Jul 2006 08:20:39 -0400 To: "'sip@ietf.org'" From: "Joel M. Halpern" Subject: Re: [Sip] draft-ietf-sip-outbound and STUN keepalives In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C29099D@en0033exch001u.uk .lucent.com> References: <475FF955A05DD411980D00508B6D5FB00C29099D@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120f39a0adbdc32739fe2ac6b94d0b3d94901e4618a3e0fb58a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.161.52.216 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This looks like a good solution to me. Thank you. Joel At 08:11 AM 7/20/2006, Drage, Keith (Keith) wrote: >(As WG chair) > >Previous mails on the SIP list have expressed the view that the STUN >keepalive mechanism should be documented separately as it is a >useful mechanism in its own right. > >See http://www3.ietf.org/proceedings/06jul/slides/sip-5.pdf slide 5 >for the issue as raised at the IETF #66 meeting. > >After discussion with the editor, the WG chairs propose the following: > >- that the documentation on STUN keepalive will REMAIN in the >outbound document, and WILL NOT be split to a separate specification; > >- that the STUN keepalive mechanism WILL BE separated within >the outbound specification, such that it is clear that it can be >implemented independently of the rest of the outbound specification, >and so that the keepalive material is clearly referencable in its own right. > >We believe that this meets the requirements of at least most of the >working group, and for pragmatic reasons we want to work against >more fragmentation of the SIP documentation. > >If you have problems with this proposal and desire a different >solution, then please raise your concerns to the list, or direct to >the WG chairs, in response to this mail. > >regards > >Keith > >Keith Drage >drage@lucent.com >tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 08:31:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XfM-0005jp-Rx; Thu, 20 Jul 2006 08:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XfK-0005hV-UT for sip@ietf.org; Thu, 20 Jul 2006 08:30:06 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3XVo-0008NV-AJ for sip@ietf.org; Thu, 20 Jul 2006 08:20:17 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6KCKDqJ023751 for ; Thu, 20 Jul 2006 07:20:15 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ987LW>; Thu, 20 Jul 2006 13:20:13 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29099E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@ietf.org'" Date: Thu, 20 Jul 2006 13:20:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Sip] draft-ietf-sip-outbound and draft-johns-sip-outbound-middialog-dr aft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) We discussed this document at IETF#66. See http://www3.ietf.org/proceedings/06jul/slides/sip-4.pdf for the presentation and http://www.ietf.org/internet-drafts/draft-johns-sip-outbound-middialog-draft-00.txt for the draft itself. The chairs have discussed this draft with the outbound editor, and we came to the conclusion that this problem is separable from the general outbound discussion, and that outbound is still useful without addressing this problem. We therefore propose that the existing charter item on outbound WILL NOT address this issue. If anyone has issues with this proposal, can they please make this known direct to the SIP WG list, or direct to the SIP WG chairs, in response to this mail. This in no way prevents the author of http://www.ietf.org/internet-drafts/draft-johns-sip-outbound-middialog-draft-00.txt continuing to progress the work with a view to a future SIP WG charter item, and we encourage SIP WG members to review the draft and make comments on the document. regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 09:35:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3YfH-00088E-2Z; Thu, 20 Jul 2006 09:34:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3YfE-00086N-LL; Thu, 20 Jul 2006 09:34:04 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3YfE-0008EO-9Q; Thu, 20 Jul 2006 09:34:04 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6KDY28P008703; Thu, 20 Jul 2006 08:34:02 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ980ZH>; Thu, 20 Jul 2006 14:34:01 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C2909A2@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Marc Linsner'" Date: Thu, 20 Jul 2006 14:33:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.5 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At the moment, I do not see the location by reference as unsolveable. There are specific security considerations that need to be taken into account, and these are by no means complete at the moment. I do not at the moment see putting a location within a SIP header as an alternative to location by reference; rather I see it as another potential solution which SIP have discussed and rejected in the past. regards Keith > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: 19 July 2006 14:32 > To: 'Drage, Keith (Keith)' > Cc: sip@ietf.org; geopriv@ietf.org > Subject: RE: [Geopriv] Location-by-value in a SIP Location Header > > > Keith, > > A couple of issues with your statements below: > > - As you point out in #2, the SIP group has identified two mechanisms, > location by value in the body and location by reference in > the header. The > issue stems from the fact that location by reference is yet to be a > mechanism. This has been mired down with technical > discussions in GeoPriv > for a long time. > > - Your list of reasons needs to be expanded to include 'the identified > mechanism has no technical solution'. > > As you express, there are many reasons to complete this work > quickly, but to > have a total solution it is important to examine these alternatives > mechanisms. Like you, I certainly hope this comes to a > resolution very > soon. > > Thanks, > > -Marc- > > > > > > > (As SIP WG chair) > > > > Just to set some limits to this discussion, let me state > > where we are in the progression of this work item. Remember > > it is now being classed as urgent and we need to get an RFC > > out of the door, and the SIP chairs are working with the > > GEOPRIV chairs as to the quickest way to do this: > > > > 1) The requirements in the document have been approved by > > the SIPPING group (a long time ago) and therefore we should > > not be inventing new requirements without a clear use case > > that has clear agreement. > > > > 2) The SIP group have already identified that two > > mechanisms to support these requirements should be documented > > (e.g. the location by value in a body, and the location by > > reference in a header. These two mechanisms appear to support > > all the current requirements. In other words, SIP have agreed > > the technical solution, and we are in the stage of trying to > > document it. > > > > 3) Using a data URL appears to add a third mechanism, if > > only because it will at least need to have a different set of > > security considerations documented for it. > > > > We should only be adding a third mechanism if: > > > > a) the existing mechanism can be shown not to meet all the > > requirements; or > > b) the use case where it offers advantages is clearly > > identified; and > > c) the compatibility issues are addressed (i.e. does the > > UAS need to support all of what is now three mechanisms or is > > there some other support requirement); and > > d) this can be shown as impossible to be discussed as a > > future extension. > > > > Could I also suggest (in addition to the above) that if > > people want to proceed with this discussion, it would be > > appropriate to submit an i-d targeted at the SIP WG > > identifying the technical solution proposed (with as much > > completeness as is possible). And remember if you think this > > discussion is needed, it needs to occur quickly. > > > > regards > > > > Keith > > > > > -----Original Message----- > > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > Sent: 19 July 2006 00:15 > > > To: Rosen, Brian; Henning Schulzrinne > > > Cc: sip@ietf.org; geopriv@ietf.org > > > Subject: RE: [Geopriv] Location-by-value in a SIP Location Header > > > > > > > > > If you want technically feasible, I can post a URI to the > list that > > > includes a complete PIDF-LO with DSig. It's a little long though. > > > > > > I'm not suggesting that this a good idea, but I see no reason to > > > prevent it. > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > Sent: Tuesday, 18 July 2006 11:07 PM > > > > To: Henning Schulzrinne > > > > Cc: sip@ietf.org; geopriv@ietf.org > > > > Subject: RE: [Geopriv] Location-by-value in a SIP > Location Header > > > > > > > > Perhaps some enlightenment is in order. It's not clear to > > > me how you > > > > dsig a Data uri in a Location header (or maybe you mean > > > dsig the pidf-lo > > > > and put both the pidf-lo and the signature in the Data > > URI) somehow? > > > > Are there some examples of this kind of thing elsewhere? > > > > > > > > If we are ignoring technical arguments (as opposed to use > > > cases), it's > > > > out of forgetfulness, and not willfulness. What were you > > > referring to? > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > Sent: Tuesday, July 18, 2006 8:59 AM > > > > To: Rosen, Brian > > > > Cc: sip@ietf.org; geopriv@ietf.org > > > > Subject: Re: [Geopriv] Location-by-value in a SIP > Location Header > > > > > > > > Brian, James: > > > > > > > > this is simply false. If desired, XML-DSIG is a well-known and > > > > accepted mechanism to achieve integrity. Such > specification is no > > > > longer than the MUST NOT that you propose. You are also > willfully > > > > ignoring the other technical arguments made as part of this > > > discussion. > > > > > > > > Henning > > > > > > > > On Jul 18, 2006, at 8:48 AM, Rosen, Brian wrote: > > > > > > > > > There was a desire expressed by Hannes to provide a way > > > for a proxy to > > > > > insert location-by-value. He had proposed a SIP > > Location header > > > > > specific way. In IETF66, Henning suggested just using > > a data URI. > > > > > > > > > > Doing this may run afoul of the geopriv location > > privacy concerns, > > > > > because there is no way for the user to sign the header > > to provide > > > > > assurance that the PIDF, and specifically the retention > > and other > > > > > policy bits are preserved. Note that S/MIME provides > sufficient > > > integrity > > > > > protection for a body. It's probably okay to use TLS > > per hop to > > > > > provide privacy, but not integrity protection. The authors > > > believe that there > > > > > is no really compelling use case for this feature, and > > > the effort to > > > > > define acceptable security mechanisms for location data > > > in a header > > > > > would be a significant effort, further delaying the draft. > > > > > > > > > > We propose, therefore, to state in > > sip-location-conveyance, that a > > > > > Data URI MUST NOT be used in the Location header until a > > > standards track > > > > > RFC > > > > > defines a suitable security mechanism to protect the > > PIDF in the > > > > > header. > > > > > > > > > > Brian and James > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > -------------------------------------------------------------- > > > ---------------------------------- > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > immediately > > > and delete the original. Any unauthorized use of this email is > > > prohibited. > > > -------------------------------------------------------------- > > > ---------------------------------- > > > [mf2] > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 11:00:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ZzO-0007De-QK; Thu, 20 Jul 2006 10:58:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ZzM-0007BA-N9; Thu, 20 Jul 2006 10:58:56 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ZkG-0004uT-KO; Thu, 20 Jul 2006 10:43:21 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 20 Jul 2006 10:43:31 -0400 id 015880E8.44BF9694.00000F81 Message-ID: <44BF9680.6000100@hxr.us> Date: Thu, 20 Jul 2006 10:43:12 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Henning Schulzrinne References: <1B6E5F53-EC65-46D6-AF84-7940CE567FFB@cs.columbia.edu> In-Reply-To: <1B6E5F53-EC65-46D6-AF84-7940CE567FFB@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org, "Rosen, Brian" , geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Henning Schulzrinne wrote: > a four-step process: > > - take any PIDF-LO > - wrap in XML-DSIG as specified by the relevant W3C recommendation > - convert to base-64 > - make into a data URL, as in the example I gave in an earlier message > > data:application/pidf+xml;base64, Here's a rather naive question... what's the point of XML-DSIG? -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 11:58:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ata-0005Ws-0A; Thu, 20 Jul 2006 11:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3atY-0005WN-Ig; Thu, 20 Jul 2006 11:57:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ZWh-0003tN-Se; Thu, 20 Jul 2006 10:29:19 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3ZSy-0003qA-QB; Thu, 20 Jul 2006 10:25:30 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 20 Jul 2006 10:25:30 -0400 id 015880E8.44BF925A.00000C0A Message-ID: <44BF9246.3020705@hxr.us> Date: Thu, 20 Jul 2006 10:25:10 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Drage, Keith (Keith)" References: <475FF955A05DD411980D00508B6D5FB00C2909A1@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C2909A1@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Drage, Keith (Keith) wrote: > We will need to consider than outside this mail. Personally I think by reference works better for the 3G architecture in this use case. There is certainly no explicit 3GPP requirement at the moment. Actually, there are many environments where reference works better. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 12:16:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bAU-0002YW-Ac; Thu, 20 Jul 2006 12:14:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bAT-0002Xo-IC for sip@ietf.org; Thu, 20 Jul 2006 12:14:29 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3YQk-00072t-95 for sip@ietf.org; Thu, 20 Jul 2006 09:19:08 -0400 Received: by ug-out-1314.google.com with SMTP id m2so820343uge for ; Thu, 20 Jul 2006 06:19:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=J0z1VWu0nyOHwTVWpGCZad0+AHtCIwvt3K464X0NpdTB+XfSuS0tS/761LsSCIML/AOfYbM9W0X7M+dmQ4JoyeO18MOY/WqHdEwNLogQhvl7ue4WM+xPlE7dg/M7f3tM/pkWCl8SMfDx+gZwjzfNYpAJtd9mZzCkUb0pkdSdDf4= Received: by 10.78.177.11 with SMTP id z11mr334270hue; Thu, 20 Jul 2006 06:19:05 -0700 (PDT) Received: by 10.78.200.4 with HTTP; Thu, 20 Jul 2006 06:19:05 -0700 (PDT) Message-ID: <52db68bc0607200619o50341173uabe9f9e29881e0a4@mail.gmail.com> Date: Thu, 20 Jul 2006 18:49:05 +0530 From: Sudhir To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 2.0 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Sip] Query reagrding RFC 3665 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0447360517==" Errors-To: sip-bounces@ietf.org --===============0447360517== Content-Type: multipart/alternative; boundary="----=_Part_18174_15398522.1153401545077" ------=_Part_18174_15398522.1153401545077 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, In RFC 3261 the construction of ACK requestURI MUST conatain original request as it said in below paragraph *17.1.1.3 Construction of the ACK Request* The ACK request constructed by the client transaction MUST contain values for the Call-ID, From, and Request-URI that are equal to the values of those header fields in the request passed to the transport by the client transaction (call this the "original request"). But, in RFC 3665 the contruction of RequestURI for ACK is taken from ConatctHeader of 200 OK as shown below. Could I know which is the approipraite one. Should I go for 3261 or Informational RFC 3665 *RFC 3665 3.1. Successful Session Establishment* INVITE sip:bob@biloxi.example.com SIP/2.0 200 OK contact Header: ACK sip:bob@client.biloxi.example.com SIP/2.0 thanks in advance regards Sudhir ------=_Part_18174_15398522.1153401545077 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All,
 
In RFC 3261 the construction of ACK requestURI MUST conatain original request as it said in below paragraph 
17.1.1.3 Construction of the ACK Request

The ACK request constructed by the client transaction MUST contain
values for the Call-ID, From, and Request-URI that are equal to the
values of those header fields in the request passed to the transport
by the client transaction (call this the "original request").

But, in RFC 3665 the contruction of RequestURI for ACK is taken from ConatctHeader of 200 OK as shown below. Could I know which is the approipraite one. Should I go for 3261 or Informational RFC 3665

RFC 3665 3.1. Successful Session Establishment
INVITE sip:bob@biloxi.example.com SIP/2.0

200 OK contact Header: <sip:bob@client.biloxi.example.com>
ACK sip:bob@client.biloxi.example.com SIP/2.0

thanks in advance

regards

Sudhir

 

 

------=_Part_18174_15398522.1153401545077-- --===============0447360517== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0447360517==-- From sip-bounces@ietf.org Thu Jul 20 12:34:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bRt-0000nW-2O; Thu, 20 Jul 2006 12:32:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bRq-0000nC-S0; Thu, 20 Jul 2006 12:32:26 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3bRo-0002K9-JF; Thu, 20 Jul 2006 12:32:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3bRc-0006gl-JW; Thu, 20 Jul 2006 11:32:12 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Drage, Keith \(Keith\)'" Date: Thu, 20 Jul 2006 12:32:11 -0400 Message-ID: <03bf01c6ac1a$10c45fb0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcasFSV+ztAGvHZeQDCx5V04qW5PyAABCfZA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44BF9246.3020705@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Much as I'd love to dispute this, I think it's a settled issue; we're supporting location-by-reference in location-conveyance. I don't think we need to continue to debate this. It's in there. What is still at issue is whether location-by-value in a header is in there. We need a real use case. I'm having trouble understanding how you can have a SIP proxy that can get a call to the outside of some domain, but can't provide a server to resolve a reference. If we have bought off on location-by-value in a body, and location-by-reference in a header, what case is not covered by those two options? Much as I would prefer proxy insertion by value over proxy insertion by reference (even if I think proxy insertion is a bad idea, that's another settled issue), I think a proxy can always use by-reference. Fewer options are better. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, July 20, 2006 10:25 AM > To: Drage, Keith (Keith) > Cc: sip@ietf.org; geopriv@ietf.org > Subject: Re: [Geopriv] Location-by-value in a SIP Location Header > > Drage, Keith (Keith) wrote: > > We will need to consider than outside this mail. Personally I think by > reference works better for the 3G architecture in this use case. There is > certainly no explicit 3GPP requirement at the moment. > > > Actually, there are many environments where reference works better. > > -andy > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 12:56:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bnk-0007pV-A5; Thu, 20 Jul 2006 12:55:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bnj-0007p3-CN; Thu, 20 Jul 2006 12:55:03 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3be3-0003ap-Gi; Thu, 20 Jul 2006 12:45:05 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 20 Jul 2006 12:45:15 -0400 id 015880EC.44BFB31B.0000253E Message-ID: <44BFB307.70001@hxr.us> Date: Thu, 20 Jul 2006 12:44:55 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Brian Rosen References: <03bf01c6ac1a$10c45fb0$640fa8c0@cis.neustar.com> In-Reply-To: <03bf01c6ac1a$10c45fb0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org, geopriv@ietf.org, "'Drage, Keith \(Keith\)'" Subject: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Rosen wrote: > Much as I'd love to dispute this, I think it's a settled issue; we're > supporting location-by-reference in location-conveyance. I don't think we > need to continue to debate this. It's in there. > > What is still at issue is whether location-by-value in a header is in there. > We need a real use case. I'm having trouble understanding how you can have > a SIP proxy that can get a call to the outside of some domain, but can't > provide a server to resolve a reference. > > If we have bought off on location-by-value in a body, and > location-by-reference in a header, what case is not covered by those two > options? > Much as I would prefer proxy insertion by value over proxy insertion by > reference (even if I think proxy insertion is a bad idea, that's another > settled issue), I think a proxy can always use by-reference. Fewer options > are better. I agree. Fewer options are better. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 13:16:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3c6X-0005OW-2O; Thu, 20 Jul 2006 13:14:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3c6U-0005GQ-5V for sip@ietf.org; Thu, 20 Jul 2006 13:14:26 -0400 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3bv0-0005UT-SE for sip@ietf.org; Thu, 20 Jul 2006 13:02:36 -0400 Received: from Inbox ([84.241.192.146]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J2P002Y4R8IS990@jes-fe1.zx.nl> for sip@ietf.org; Thu, 20 Jul 2006 18:58:06 +0100 (WEST) Date: Thu, 20 Jul 2006 19:02:45 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] Allowing sip: (or prez:) in the location header To: Brian Rosen , "'Thomson, Martin'" , sip@ietf.org Message-id: <0J2P002Y5R8KS990@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, To me using ABNF rules to restrict allowable schemes is not a good idea. AB= NF defines syntax, not semantics Compare this with the Route header in SIP. The ABNF allows any scheme, text= says it MUST be sip: or sips:. That suffices (you could define which error= response must be sent) Moreover, the protocol to use is a policy decision. You can make recommenda= tions, even define new mechanisms, but I think the choice should be left to= implementors Regards, Jeroen -----Oorspronkelijk bericht ----- Van: "Brian Rosen" Aan: "'Thomson, Martin'" ; sip@ietf.org Verzonden: 20-7-06 18:19 Onderwerp: RE: [Sip] Allowing sip: (or prez:) in the location header There is a point to limiting what can be sent in the Location header to specific protocols which has received adequate review in both sip and geopriv. So, here is my concrete proposal: Location =3D "Location" HCOLON location-param *(COMMA location-param) location-param =3D LAQUOT allowed-scheme HCOLON ":" ( hier-part / opaque-pa= rt ) RAQUOT *( SEMI loc-param ) ; hier-part and opaque-part from 3261 allowed-scheme =3D 'cid' / 'http' / 'https' / 'sip' / 'sips' / 'prez' loc-param =3D 'location-dereference-protocol=3D' deref-protocol / generic-param deref-protocol =3D token allowed-scheme may be extended by a standards-track RFC. Such an extension is NOT considered a SIP extension and is NOT subject to the process defined by RFC3427. Corresponding resolution processes for such schemes MUST be included in the RFC, and MAY be subject to review against RFC3693. This document (in Section ?) defines a new IANA registry for deref-protocol= , and populates it with one initial value, 'rawGET'. rawGET indicates that the location reference may be dereferenced by sending a GET with no parameters on the URI, using HTTPS (except in the emergency case, where HTT= P is permitted), and expects to receive one PIDF-LO document (with a MIME-typ= e of "application/pidf+xml")in response. deref-protocol MUST be included if the scheme is HTTPS (or HTTP in the emergency case). Other schemes may or may not require deref-protocol. A standards-track RFC is required to add a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 13:38:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3cSO-0004AQ-Ln; Thu, 20 Jul 2006 13:37:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3cSN-00049D-32 for sip@ietf.org; Thu, 20 Jul 2006 13:37:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3cKm-0000QO-5X for sip@ietf.org; Thu, 20 Jul 2006 13:29:12 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3cKk-0006Vn-Ij for sip@ietf.org; Thu, 20 Jul 2006 13:29:12 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 20 Jul 2006 13:29:11 -0400 id 015880EC.44BFBD68.00002CB9 Message-ID: <44BFBD54.5020108@hxr.us> Date: Thu, 20 Jul 2006 13:28:52 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jeroen Van Bemmel Subject: Re: [Sip] Allowing sip: (or prez:) in the location header References: <0J2P002Y5R8KS990@jes-fe1.zx.nl> In-Reply-To: <0J2P002Y5R8KS990@jes-fe1.zx.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org, "'Thomson, Martin'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen Van Bemmel wrote: > Brian, > > To me using ABNF rules to restrict allowable schemes is not a good idea. ABNF defines syntax, not semantics > > Compare this with the Route header in SIP. The ABNF allows any scheme, text says it MUST be sip: or sips:. That suffices (you could define which error response must be sent) I agree. The same is also true for a lot of specs that use XML Schema but then use 2119 language on top of that. > Moreover, the protocol to use is a policy decision. You can make recommendations, even define new mechanisms, but I think the choice should be left to implementors I disagree with this. What is my server gonna do with a mailto: or dns: URI? There should be a small list of acceptable choices if we want interoperability. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 13:38:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3cSX-0004Fs-B8; Thu, 20 Jul 2006 13:37:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3cSV-0004DK-Nu for sip@ietf.org; Thu, 20 Jul 2006 13:37:11 -0400 Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3cSU-0001Ox-4D for sip@ietf.org; Thu, 20 Jul 2006 13:37:11 -0400 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J2P00G5FQA2T4@tid.hi.inet> for sip@ietf.org; Thu, 20 Jul 2006 19:37:14 +0200 (MEST) Received: from matrix2 (matrix2.hi.inet [10.95.28.131]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0J2P006QWQA1UD@tid.hi.inet> for sip@ietf.org; Thu, 20 Jul 2006 19:37:14 +0200 (MEST) Date: Thu, 20 Jul 2006 19:37:08 +0200 From: =?iso-8859-1?Q?Gustavo_Garc=EDa_Bernardo?= Subject: RE: [Sip] Query reagrding RFC 3665 In-reply-to: <52db68bc0607200619o50341173uabe9f9e29881e0a4@mail.gmail.com> To: 'Sudhir' , sip@ietf.org Message-id: <000c01c6ac23$207d4030$831c5f0a@matrix2> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcasF6pqLu1gTFBiS9CZlyqNH0as3QACd/Eg X-Spam-Score: 0.1 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0760827583==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0760827583== Content-type: multipart/alternative; boundary="Boundary_(ID_eHnJxWg+rsXEe7OaPzgi0w)" This is a multi-part message in MIME format. --Boundary_(ID_eHnJxWg+rsXEe7OaPzgi0w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable The rules in RFC3261 17.1.1.3 are for ACKs created for non 2XX INVITE responses (ACKs created in transactions layer). For 2XX responses, the = ACKs are created in UA layer, using the same rules as any other request = inside a established dialog. =20 =93The UAC uses the remote target and route set to build the Request-URI and Route header field of the request.=94 (RFC3261 12.2.1.1 = Generating the Request) =20 Where the remote target is the Contact received in 2XX response. =20 So, the second one (according to RFC3665 too), is the correct. =20 G. =20 _____ =20 De: Sudhir [mailto:t.sudhirkumar@gmail.com]=20 Enviado el: jueves, 20 de julio de 2006 15:19 Para: sip@ietf.org Asunto: [Sip] Query reagrding RFC 3665 =20 Hi All, =20 In RFC 3261 the construction of ACK requestURI MUST conatain original request as it said in below paragraph=20 17.1.1.3 Construction of the ACK Request The ACK request constructed by the client transaction MUST contain values for the Call-ID, From, and Request-URI that are equal to the values of those header fields in the request passed to the transport by the client transaction (call this the "original request").=20 But, in RFC 3665 the contruction of RequestURI for ACK is taken from ConatctHeader of 200 OK as shown below. Could I know which is the approipraite one. Should I go for 3261 or Informational RFC 3665 RFC 3665 3.1. Successful Session Establishment INVITE sip:bob@biloxi.example.com SIP/2.0 200 OK contact Header: ACK sip:bob@client.biloxi.example.com SIP/2.0=20 thanks in advance regards Sudhir =20 =20 --Boundary_(ID_eHnJxWg+rsXEe7OaPzgi0w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

The rules in = RFC3261 17.1.1.3 are for ACKs created for non 2XX INVITE responses (ACKs created = in transactions layer). =A0For 2XX responses, the ACKs are created in UA = layer, using the same rules as any other request inside a established = dialog.

 =

“The UAC = uses the remote target and route set to build the = Request-URI

=A0=A0 and Route = header field of the request.” (RFC3261 12.2.1.1 Generating the = Request)

 =

Where the remote = target is the Contact received in 2XX response.

 =

So, the second = one (according to RFC3665 too), is the correct.

 =

G.

 =

De: = Sudhir [mailto:t.sudhirkumar@gmail.com]
Enviado el: jueves, 20 de = julio de 2006 15:19
Para: sip@ietf.org
Asunto: [Sip] Query = reagrding RFC 3665

 

Hi All,

 

In RFC 3261 the construction of ACK requestURI MUST = conatain original request as it said in below = paragraph 

17.1.1.3 = Construction of the ACK Request

The ACK request constructed by the client transaction MUST contain
values for the Call-ID, From, and Request-URI that are equal to the
values of those header fields in the request passed to the transport
by the client transaction (call this the "original request"). =

But, in RFC 3665 the contruction of RequestURI for ACK is taken from = ConatctHeader of 200 OK as shown below. Could I know which is the approipraite one. = Should I go for 3261 or Informational RFC 3665

RFC 3665 3.1. Successful Session = Establishment
INVITE sip:bob@biloxi.example.com= SIP/2.0

200 OK contact Header: <sip:bob@client.biloxi.e= xample.com>
ACK sip:bob@client.biloxi.e= xample.com SIP/2.0

thanks in advance

regards

Sudhir

 

 

--Boundary_(ID_eHnJxWg+rsXEe7OaPzgi0w)-- --===============0760827583== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0760827583==-- From sip-bounces@ietf.org Thu Jul 20 13:38:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3cSO-0004AQ-Ln; Thu, 20 Jul 2006 13:37:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3cSN-00049D-32 for sip@ietf.org; Thu, 20 Jul 2006 13:37:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3cKm-0000QO-5X for sip@ietf.org; Thu, 20 Jul 2006 13:29:12 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3cKk-0006Vn-Ij for sip@ietf.org; Thu, 20 Jul 2006 13:29:12 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 20 Jul 2006 13:29:11 -0400 id 015880EC.44BFBD68.00002CB9 Message-ID: <44BFBD54.5020108@hxr.us> Date: Thu, 20 Jul 2006 13:28:52 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jeroen Van Bemmel Subject: Re: [Sip] Allowing sip: (or prez:) in the location header References: <0J2P002Y5R8KS990@jes-fe1.zx.nl> In-Reply-To: <0J2P002Y5R8KS990@jes-fe1.zx.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org, "'Thomson, Martin'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen Van Bemmel wrote: > Brian, > > To me using ABNF rules to restrict allowable schemes is not a good idea. ABNF defines syntax, not semantics > > Compare this with the Route header in SIP. The ABNF allows any scheme, text says it MUST be sip: or sips:. That suffices (you could define which error response must be sent) I agree. The same is also true for a lot of specs that use XML Schema but then use 2119 language on top of that. > Moreover, the protocol to use is a policy decision. You can make recommendations, even define new mechanisms, but I think the choice should be left to implementors I disagree with this. What is my server gonna do with a mailto: or dns: URI? There should be a small list of acceptable choices if we want interoperability. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 13:38:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3cSX-0004Fs-B8; Thu, 20 Jul 2006 13:37:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3cSV-0004DK-Nu for sip@ietf.org; Thu, 20 Jul 2006 13:37:11 -0400 Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3cSU-0001Ox-4D for sip@ietf.org; Thu, 20 Jul 2006 13:37:11 -0400 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J2P00G5FQA2T4@tid.hi.inet> for sip@ietf.org; Thu, 20 Jul 2006 19:37:14 +0200 (MEST) Received: from matrix2 (matrix2.hi.inet [10.95.28.131]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0J2P006QWQA1UD@tid.hi.inet> for sip@ietf.org; Thu, 20 Jul 2006 19:37:14 +0200 (MEST) Date: Thu, 20 Jul 2006 19:37:08 +0200 From: =?iso-8859-1?Q?Gustavo_Garc=EDa_Bernardo?= Subject: RE: [Sip] Query reagrding RFC 3665 In-reply-to: <52db68bc0607200619o50341173uabe9f9e29881e0a4@mail.gmail.com> To: 'Sudhir' , sip@ietf.org Message-id: <000c01c6ac23$207d4030$831c5f0a@matrix2> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcasF6pqLu1gTFBiS9CZlyqNH0as3QACd/Eg X-Spam-Score: 0.1 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0760827583==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0760827583== Content-type: multipart/alternative; boundary="Boundary_(ID_eHnJxWg+rsXEe7OaPzgi0w)" This is a multi-part message in MIME format. --Boundary_(ID_eHnJxWg+rsXEe7OaPzgi0w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable The rules in RFC3261 17.1.1.3 are for ACKs created for non 2XX INVITE responses (ACKs created in transactions layer). For 2XX responses, the = ACKs are created in UA layer, using the same rules as any other request = inside a established dialog. =20 =93The UAC uses the remote target and route set to build the Request-URI and Route header field of the request.=94 (RFC3261 12.2.1.1 = Generating the Request) =20 Where the remote target is the Contact received in 2XX response. =20 So, the second one (according to RFC3665 too), is the correct. =20 G. =20 _____ =20 De: Sudhir [mailto:t.sudhirkumar@gmail.com]=20 Enviado el: jueves, 20 de julio de 2006 15:19 Para: sip@ietf.org Asunto: [Sip] Query reagrding RFC 3665 =20 Hi All, =20 In RFC 3261 the construction of ACK requestURI MUST conatain original request as it said in below paragraph=20 17.1.1.3 Construction of the ACK Request The ACK request constructed by the client transaction MUST contain values for the Call-ID, From, and Request-URI that are equal to the values of those header fields in the request passed to the transport by the client transaction (call this the "original request").=20 But, in RFC 3665 the contruction of RequestURI for ACK is taken from ConatctHeader of 200 OK as shown below. Could I know which is the approipraite one. Should I go for 3261 or Informational RFC 3665 RFC 3665 3.1. Successful Session Establishment INVITE sip:bob@biloxi.example.com SIP/2.0 200 OK contact Header: ACK sip:bob@client.biloxi.example.com SIP/2.0=20 thanks in advance regards Sudhir =20 =20 --Boundary_(ID_eHnJxWg+rsXEe7OaPzgi0w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

The rules in = RFC3261 17.1.1.3 are for ACKs created for non 2XX INVITE responses (ACKs created = in transactions layer). =A0For 2XX responses, the ACKs are created in UA = layer, using the same rules as any other request inside a established = dialog.

 =

“The UAC = uses the remote target and route set to build the = Request-URI

=A0=A0 and Route = header field of the request.” (RFC3261 12.2.1.1 Generating the = Request)

 =

Where the remote = target is the Contact received in 2XX response.

 =

So, the second = one (according to RFC3665 too), is the correct.

 =

G.

 =

De: = Sudhir [mailto:t.sudhirkumar@gmail.com]
Enviado el: jueves, 20 de = julio de 2006 15:19
Para: sip@ietf.org
Asunto: [Sip] Query = reagrding RFC 3665

 

Hi All,

 

In RFC 3261 the construction of ACK requestURI MUST = conatain original request as it said in below = paragraph 

17.1.1.3 = Construction of the ACK Request

The ACK request constructed by the client transaction MUST contain
values for the Call-ID, From, and Request-URI that are equal to the
values of those header fields in the request passed to the transport
by the client transaction (call this the "original request"). =

But, in RFC 3665 the contruction of RequestURI for ACK is taken from = ConatctHeader of 200 OK as shown below. Could I know which is the approipraite one. = Should I go for 3261 or Informational RFC 3665

RFC 3665 3.1. Successful Session = Establishment
INVITE sip:bob@biloxi.example.com= SIP/2.0

200 OK contact Header: <sip:bob@client.biloxi.e= xample.com>
ACK sip:bob@client.biloxi.e= xample.com SIP/2.0

thanks in advance

regards

Sudhir

 

 

--Boundary_(ID_eHnJxWg+rsXEe7OaPzgi0w)-- --===============0760827583== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0760827583==-- From sip-bounces@ietf.org Thu Jul 20 14:58:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3dhu-0004Pf-Dl; Thu, 20 Jul 2006 14:57:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3dhs-0004OT-Lv for sip@ietf.org; Thu, 20 Jul 2006 14:57:08 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3dhr-0004KI-4s for sip@ietf.org; Thu, 20 Jul 2006 14:57:08 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3dhh-0006jG-5V; Thu, 20 Jul 2006 13:56:57 -0500 From: "Brian Rosen" To: "'Jeroen Van Bemmel'" , "'Thomson, Martin'" , Subject: RE: [Sip] Allowing sip: (or prez:) in the location header Date: Thu, 20 Jul 2006 14:57:00 -0400 Message-ID: <041c01c6ac2e$49e5d530$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcasHk0mpBcM1db2TJC4dbtnt4v2sAADpxew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <0J2P002Y5R8KS990@jes-fe1.zx.nl> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen I don't agree that this is a semantic issue; we are restricting precisely what may appear in allowed-scheme. I usually think it's better to have the ABNF precise, rather than relying on text to state what is actually permitted on the wire. We are talking about what is syntactically allowed, not how you interpret it. The ABNF =/ syntax (from RFC4234) is a convenient way to add a scheme to the list, even when used by independently created RFCs. I, like Andy, don't believe the decision on which protocols can appear in allowed-scheme can be left to implementation. Every dereferencer has to be prepared to use every possible protocol, especially on the Internet, because there is no way to ask for a specific URI or limit the schemes the location acquisition mechanism may obtain. Brian > -----Original Message----- > From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Thursday, July 20, 2006 1:03 PM > To: Brian Rosen; 'Thomson, Martin'; sip@ietf.org > Subject: RE: [Sip] Allowing sip: (or prez:) in the location header > > Brian, > > To me using ABNF rules to restrict allowable schemes is not a good idea. > ABNF defines syntax, not semantics > > Compare this with the Route header in SIP. The ABNF allows any scheme, > text says it MUST be sip: or sips:. That suffices (you could define which > error response must be sent) > > Moreover, the protocol to use is a policy decision. You can make > recommendations, even define new mechanisms, but I think the choice should > be left to implementors > > Regards, > > Jeroen > -----Oorspronkelijk bericht ----- > Van: "Brian Rosen" > Aan: "'Thomson, Martin'" ; sip@ietf.org > Verzonden: 20-7-06 18:19 > Onderwerp: RE: [Sip] Allowing sip: (or prez:) in the location header > > There is a point to limiting what can be sent in the Location header to > specific protocols which has received adequate review in both sip and > geopriv. > > So, here is my concrete proposal: > Location = "Location" HCOLON location-param *(COMMA location-param) > location-param = LAQUOT allowed-scheme HCOLON ":" ( hier-part / opaque- > part > ) RAQUOT *( SEMI loc-param ) ; hier-part and opaque-part from 3261 > allowed-scheme = 'cid' / 'http' / 'https' / 'sip' / 'sips' / 'prez' > loc-param = 'location-dereference-protocol=' deref-protocol / > generic-param > deref-protocol = token > > allowed-scheme may be extended by a standards-track RFC. Such an > extension > is NOT considered a SIP extension and is NOT subject to the process > defined > by RFC3427. Corresponding resolution processes for such schemes MUST be > included in the RFC, and MAY be subject to review against RFC3693. > > This document (in Section ?) defines a new IANA registry for deref- > protocol, > and populates it with one initial value, 'rawGET'. rawGET indicates that > the location reference may be dereferenced by sending a GET with no > parameters on the URI, using HTTPS (except in the emergency case, where > HTTP > is permitted), and expects to receive one PIDF-LO document (with a MIME- > type > of "application/pidf+xml")in response. deref-protocol MUST be included if > the scheme is HTTPS (or HTTP in the emergency case). Other schemes may or > may not require deref-protocol. A standards-track RFC is required to add > a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 16:42:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fJm-0008GS-Tl; Thu, 20 Jul 2006 16:40:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fIq-0006zc-NE for sip@ietf.org; Thu, 20 Jul 2006 16:39:24 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3fFJ-0006hv-BG for sip@ietf.org; Thu, 20 Jul 2006 16:35:46 -0400 Received: (qmail 15652 invoked by uid 0); 20 Jul 2006 20:35:44 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 20 Jul 2006 20:35:44 -0000 Message-ID: <003a01c6ac3c$10eef9b0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Thu, 20 Jul 2006 22:35:40 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Sip] location conveyance : use case for missing requirement X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0171559337==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0171559337== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C6AC4C.D45FD4E0" This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C6AC4C.D45FD4E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For scenario 1 (seeking nearest Pizza Hut) I think one would want to = provide the location to the proxy, such that it can locate the nearest = X. However, I may not want that X to know my location. So I would like = to request the proxy to use my location for the lookup, and then remove = it from the request Hence a new requirement: it must be possible for the UAC to indicate to = a proxy that it should remove the location information Regards, Jeroen ------=_NextPart_000_0037_01C6AC4C.D45FD4E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
For scenario 1 (seeking nearest Pizza = Hut) I think=20 one would want to provide the location to the proxy, such that it can = locate the=20 nearest X. However, I may not want that X to know my location. So I = would like=20 to request the proxy to use my location for the lookup, and then remove = it from=20 the request
 
Hence a new requirement: it must be = possible for=20 the UAC to indicate to a proxy that it should remove the location=20 information
 
Regards,
 
Jeroen
------=_NextPart_000_0037_01C6AC4C.D45FD4E0-- --===============0171559337== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0171559337==-- From sip-bounces@ietf.org Thu Jul 20 16:42:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fK1-0008R8-To; Thu, 20 Jul 2006 16:40:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fIs-000709-3R for sip@ietf.org; Thu, 20 Jul 2006 16:39:26 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3fB2-0006TV-T2 for sip@ietf.org; Thu, 20 Jul 2006 16:31:22 -0400 Received: (qmail 12399 invoked by uid 0); 20 Jul 2006 20:31:19 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 20 Jul 2006 20:31:19 -0000 Message-ID: <003301c6ac3b$72d29890$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Andrew Newton" References: <0J2P002Y5R8KS990@jes-fe1.zx.nl> <44BFBD54.5020108@hxr.us> Subject: Re: [Sip] Allowing sip: (or prez:) in the location header Date: Thu, 20 Jul 2006 22:31:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org, "'Thomson, Martin'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Andrew, >> Moreover, the protocol to use is a policy decision. You can make >> recommendations, even define new mechanisms, but I think the choice >> should be left to implementors > > I disagree with this. What is my server gonna do with a mailto: or dns: > URI? There should be a small list of acceptable choices if we want > interoperability. In such a case your server should probably respond with "4xx Location URI Scheme not supported", where 4xx is TBD. However, if retrieving the location is not critical to completing the call, then it should probably ignore the header. So there seems to be a need for a parameter indicating "optional" versus "required" IMO the text in the draft should say: - proxies MUST support HTTP, SHOULD support HTTPS, MAY support cid (for dereferencing) - UAS MUST support HTTP and cid, SHOULD support HTTPS (for dereferencing) - TBD: define whether and when proxy/UAS should generate error for unsupported URI scheme (and then indicate which schemes are supported) - UAC/Proxy SHOULD use HTTPS when adding Location by reference - UAC MAY use cid for location by value, but SHOULD then ensure confidentiality But above all: the draft should specify what is minimally needed to meet the stated requirements, while not unnecessarily restricting solutions that might have additional requirements which are not currently foreseen Regards, jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 17:29:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3g3Q-0000Lh-He; Thu, 20 Jul 2006 17:27:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3g3O-0000LN-J8 for sip@ietf.org; Thu, 20 Jul 2006 17:27:30 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3g3N-00012P-6k for sip@ietf.org; Thu, 20 Jul 2006 17:27:30 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3g3C-0006YW-AQ; Thu, 20 Jul 2006 16:27:18 -0500 From: "Brian Rosen" To: "'Jeroen van Bemmel'" , "'Andrew Newton'" Subject: RE: [Sip] Allowing sip: (or prez:) in the location header Date: Thu, 20 Jul 2006 17:27:21 -0400 Message-ID: <045e01c6ac43$4b9a7d80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcasO3OmXlXjfodWTX+uckDAISG8WAAA/yag X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <003301c6ac3b$72d29890$31713b51@BEMBUSTER> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: sip@ietf.org, "'Thomson, Martin'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't think you have the big picture. Location comes from the access network, via some acquisition protocol, or in some cases, can be self generated in the endpoint. The access network decides what the representation of the location is if it's supplying location, although it may give an endpoint some options (value/reference, civic/geo). The UAC gets this location and puts it in the SIP message. Some entity, could be a proxy for location based routing, or the UAS, gets the location and does something with it. For the sake of argument, assume its location-by-reference. Call the proxy or UAS the "de-referencer". It's the access network (could be a broadband carrier, could be an enterprise) that is putting up the server that provides the de-reference service. Call the server a "Location Information Server" = LIS Okay, so the access network chooses some protocol, makes up a suitable URI and passes it via the acquisition protocol to the UAC. The UAC passes it to the de-referencer, who presents it to the LIS. The LIS responds with the location value. The problem is that the de-referencer can't control which LIS, and can't control what protocol decision the LIS made. It has to implement EVERY ONE of the protocols that could appear in the Location header. If the LIS implements a protocol the de-referencer doesn't understand, the whole mechanism fails, with no recourse. On the Internet, which is where we want the protocols to work, you can't control which access network the UAC is coming from. So, instead, we restrict the list of allowed de-referencing protocols to a small number, and make that list very explicit. Now a de-referencer knows that if he implements ALL of the listed protocols, he will be able to dereference any location reference he gets. There is another big picture aspect. The whole location thing comes under geopriv. We have to do a sip Location header in sip, but geopriv has to review our work. The "priv" part of geopriv is privacy. They care, a whole lot, about the privacy aspects of location. One expression of that concern is to have the security posture of "what is not explicitly permitted is prohibited". They really truly want to look at every IETF protocol that is used to de-reference location, and decide if it provides sufficient privacy protection for location. They really do want an explicit list, and they want to scrutinize every protocol on that list to see how it addresses their concerns. SIP is what geopriv calls a "using protocol" and they review them seriously. This means, for example, that it's probably not okay to use HTTP to de-reference. There is a specific, limited exemption for emergency calls on that. So HTTPS is a MUST, and HTTP is MUST NOT except for the emergency case. I believe that "AbsoluteURI" would not be acceptable to geopriv, but of course I can't speak for the group. Brian > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Thursday, July 20, 2006 4:31 PM > To: Andrew Newton > Cc: Brian Rosen; 'Thomson, Martin'; sip@ietf.org > Subject: Re: [Sip] Allowing sip: (or prez:) in the location header > > Andrew, > > >> Moreover, the protocol to use is a policy decision. You can make > >> recommendations, even define new mechanisms, but I think the choice > >> should be left to implementors > > > > I disagree with this. What is my server gonna do with a mailto: or dns: > > URI? There should be a small list of acceptable choices if we want > > interoperability. > > In such a case your server should probably respond with "4xx Location URI > Scheme not supported", where 4xx is TBD. However, if retrieving the > location > is not critical to completing the call, then it should probably ignore the > header. So there seems to be a need for a parameter indicating "optional" > versus "required" > > IMO the text in the draft should say: > - proxies MUST support HTTP, SHOULD support HTTPS, MAY support cid (for > dereferencing) > - UAS MUST support HTTP and cid, SHOULD support HTTPS (for dereferencing) > - TBD: define whether and when proxy/UAS should generate error for > unsupported URI scheme (and then indicate which schemes are supported) > - UAC/Proxy SHOULD use HTTPS when adding Location by reference > - UAC MAY use cid for location by value, but SHOULD then ensure > confidentiality > > But above all: the draft should specify what is minimally needed to meet > the > stated requirements, while not unnecessarily restricting solutions that > might have additional requirements which are not currently foreseen > > Regards, > > jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 17:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gIE-0003px-MH; Thu, 20 Jul 2006 17:42:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gIB-0003nX-KO for sip@ietf.org; Thu, 20 Jul 2006 17:42:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3gCs-0001sY-7Z for sip@ietf.org; Thu, 20 Jul 2006 17:37:19 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2006 14:37:17 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KLbHaF004005; Thu, 20 Jul 2006 14:37:17 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6KLbHiB011559; Thu, 20 Jul 2006 14:37:17 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 14:37:17 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.253]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 14:37:16 -0700 Message-Id: <4.3.2.7.2.20060720163255.02a08240@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2006 16:37:15 -0500 To: "Jeroen van Bemmel" , From: "James M. Polk" Subject: Re: [Sip] location conveyance : use case for missing requirement In-Reply-To: <003a01c6ac3c$10eef9b0$31713b51@BEMBUSTER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Jul 2006 21:37:17.0047 (UTC) FILETIME=[AC061070:01C6AC44] DKIM-Signature: a=rsa-sha1; q=dns; l=1362; t=1153431437; x=1154295437; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20location=20conveyance=20=3A=20use=20case=20for=20missing =0A=20=20requirement; X=v=3Dcisco.com=3B=20h=3Du9eqK2bRPlEPk9RmnLIgS0S8+sw=3D; b=dzxqOE1nG91MTyqSGImZg8kf2aRNI2w31qDcyKXHRR0eNPRr6O5WKb0hddKlphkd2ZTrfZA0 +Oi8RmONUkbUUkO49PddyJPQXhmvMyz2oIX2EcctInBDPTSiFauMi820; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 10:35 PM 7/20/2006 +0200, Jeroen van Bemmel wrote: >For scenario 1 (seeking nearest Pizza Hut) I think one would want to >provide the location to the proxy, such that it can locate the nearest X. >However, I may not want that X to know my location. So I would like to >request the proxy to use my location for the lookup, and then remove it >from the request This can be solved by Pizza Hut responding with a 302 with the URI of nearest X (store, I assume). This way, I send the new SIP Request with or without my Location (which will probably be needed if I want the pizza delivered, but not needed if I'm traveling to the store's location). > >Hence a new requirement: it must be possible for the UAC to indicate to a >proxy that it should remove the location information given the above, I'm not sure this requirement is needed. But it might be interesting if I can ask Pizza Hut to 3XX me to the nearest store. I don't know how we would indicate that in a request to Pizza-Hut.com > >Regards, > >Jeroen >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 18:08:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gep-0003W5-U5; Thu, 20 Jul 2006 18:06:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3geo-0003V9-Bq for sip@ietf.org; Thu, 20 Jul 2006 18:06:10 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3gYK-0004Tn-5f for sip@ietf.org; Thu, 20 Jul 2006 17:59:30 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2006 14:59:28 -0700 X-IronPort-AV: i="4.07,163,1151910000"; d="scan'208"; a="1840361548:sNHT26738556" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KLxRRD025664; Thu, 20 Jul 2006 14:59:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6KLxR2D018219; Thu, 20 Jul 2006 14:59:27 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Jul 2006 14:59:27 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.253]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 14:59:26 -0700 Message-Id: <4.3.2.7.2.20060720164240.033c6550@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2006 16:59:24 -0500 To: "Brian Rosen" , "'Thomson, Martin'" , From: "James M. Polk" Subject: RE: [Sip] Allowing sip: in location header not good In-Reply-To: <03b201c6ac18$4925e290$640fa8c0@cis.neustar.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Jul 2006 21:59:26.0784 (UTC) FILETIME=[C49BD400:01C6AC47] DKIM-Signature: a=rsa-sha1; q=dns; l=2103; t=1153432767; x=1154296767; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Sip]=20Allowing=20sip=3A=20in=20location=20header=20not=20good; X=v=3Dcisco.com=3B=20h=3DAgLzqLz+aqlNDghejLoTQFzKAsA=3D; b=fG+CvR3vs+Y0ZKI8g0Pl8fV2LuvQCCi9YLp+XQRl7nVD/MQq3C3YnxmdfiHUmj+wRrQlrFJD oJyUHsdXeopRE23l9VzgUqFqz4Ob0PpOa0a6iX4FGKNIMbKUjNK/27fT; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 12:19 PM 7/20/2006 -0400, Brian Rosen wrote: >There is a point to limiting what can be sent in the Location header to >specific protocols which has received adequate review in both sip and >geopriv. > >So, here is my concrete proposal: >Location = "Location" HCOLON location-param *(COMMA location-param) >location-param = LAQUOT allowed-scheme HCOLON ":" ( hier-part / opaque-part >) RAQUOT *( SEMI loc-param ) ; hier-part and opaque-part from 3261 >allowed-scheme = 'cid' / 'http' / 'https' / 'sip' / 'sips' / 'prez' >loc-param = 'location-dereference-protocol=' deref-protocol / >generic-param >deref-protocol = token I'm still not a fan of using 'sip' here. 'sip' or 'sips' means using SUBSCRIBE and that's a PULL mechanism in this scenario; i.e. the UAC that's subscribing to another SIP element is not using its location to do anything (that will come back in the NOTIFY). The UAC (in the SUB transaction) in this scenario is PULLING another UA's location from somewhere, and that's not "Location Conveyance" - which is what I got hammered on in the Paris meeting. Clear consensus from that meeting was that this document describes PUSHING my UAC's location to somewhere else. Using HTTP(S) to fetch (presumably with a GET request) my location-by-reference once from a server is not a pull, it is a Content-Indirection operation, which is a fake of a PUSH, IMO. Using a SUBSCRIBE, you are always receiving something in the NOTIFY. If "location" is what's returned in that NOTIFY, this is a "Location Retreaval" PULL, and against what the Paris meeting said to do, and is for another document, a PULL mechanism document that hasn't been written yet. Therefore, I recommend we remove sip: and sips: from the BNF above. I'm still thinking about what to do about the 'pres' proposal. Adam's scenario (on the mike in Montreal) about using SUBSCRIBE to a weather service did not have Adam's location coming back in the NOTIFY, so that use-case doesn't apply to this discussion (but is a great use-case!) comments James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 19:21:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ho5-0001Sv-Db; Thu, 20 Jul 2006 19:19:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ho4-0001Qa-7p; Thu, 20 Jul 2006 19:19:48 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ho2-0001CT-FH; Thu, 20 Jul 2006 19:19:48 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2006 16:19:45 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KNJjbr011667; Thu, 20 Jul 2006 16:19:45 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6KNJhiD018008; Thu, 20 Jul 2006 16:19:43 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 16:19:43 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.253]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 16:19:42 -0700 Message-Id: <4.3.2.7.2.20060720175701.036a4240@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2006 18:19:41 -0500 To: "Brian Rosen" , "'Thomson, Martin'" , , geopriv@ietf.org From: "James M. Polk" Subject: RE: [Sip] Allowing sip: in location header not good In-Reply-To: <046001c6ac4b$75123510$640fa8c0@cis.neustar.com> References: <4.3.2.7.2.20060720164240.033c6550@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Jul 2006 23:19:42.0909 (UTC) FILETIME=[FB3E2ED0:01C6AC52] DKIM-Signature: a=rsa-sha1; q=dns; l=6008; t=1153437585; x=1154301585; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Sip]=20Allowing=20sip=3A=20in=20location=20header=20not=20good; X=v=3Dcisco.com=3B=20h=3DAgLzqLz+aqlNDghejLoTQFzKAsA=3D; b=oB579ESqI8kgvEENofzh68e5jIOGv0ns77ydvVkFHS+6KN9ZdFvECchldV6XY1tIehXc8/AA 47JoAiclcSrWbFIyRNqOCnnNz+ILRAjrjBt9N71Fc/Gv+4DSrr9yB7Gf; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 06:25 PM 7/20/2006 -0400, Brian Rosen wrote: >Dueling authors. Pistols at 40 paces? Have you a second? > >Remind me what the religious argument against pull is? Jon Peterson had the strongest opinion on the list, but there were several opinions at the Paris meeting, including Rohan (especially brutal about this point) and Dean. Most seemed to hang on the idea that our doc is all about "conveying" - which means giving or showing something else what I have. SUB and NOT have to do with me receiving what your location is, which is not conveying, by definition. Before Paris, our doc (dear co-author :-) discussed both conveying and receiving location. I can't remember who from the SIMPLE WG got on me for trying to have SUB/NOT or PUBLISH in our ID. >I'm conveying location by reference using an IETF procedure designed >expressly to convey location: presence. I think if you looked at this, you'd likely see that I push my presence location up to a compositor server, and others subscribe to that server to learn my presence. Those others are pulling my location from the compositor. >Whether I get one NOTIFY or >multiple ones can't possibly matter to the sip protocol, the Location >header, the security considerations or anything else I can think of. ...except the pov of the document (being about conveying). >Look at it this way: suppose I were to say if you use sip/sips, you MUST set >Expiry to zero. Then, I think, the Geopriv folks will say that LoST cannot then take that location (in or out of a PIDF-LO) and send it to a LoST server - because it was distributed after the flag was set to "no".... >That's plain and simple location by reference. I completely understand the idea, but I think we may have unearthed another problem in the last 24 hours. If the INVITE has a PIDF-LO with this element no Can a ESRP (emergency services routing proxy that does the LoST query for the PSAP URI) send location anywhere? Geopriv might say no, because it violates one of its "priv" rules. Now what? Do we make an exception? We have to get their buy-in for this. We don't have it yet. >You get a >URI, you send it using a defined protocol to a server, it sends you a PIDF. ..-LO >If you buy that, what in the document prevents me from allowing any value I >want in Expiry? The is a binary value: yes or no, not a hop-count field... this may have us in a pickle in this use case, even if most don't believe it's a problem. At the end of the day, I think we should have allowed-scheme = 'cid' / 'http' / 'https' / 'pres' (and I'm not so sure about 'pres') until the location-retreavel ID is written that extends this document (which will define how to SUBSCRIBE/NOTIFY and PUBLISH location). I'm fine with defining the additional sematics surrounding how to use HTTP and HTTPS (i.e. with request type and so on), as I consider that part of the dereferencing part of conveyance. That said, once you have SUBSCRIBE, you have tracking with multiple NOTIFYs, and that's an event package that isn't proposed yet, because it needs to have a timing interval and a trigger on what is considered a move. This would be a more general use-case that Rohan's movement trigger event package ID. >Brian > > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Thursday, July 20, 2006 5:59 PM > > To: Brian Rosen; 'Thomson, Martin'; sip@ietf.org > > Subject: RE: [Sip] Allowing sip: in location header not good > > > > At 12:19 PM 7/20/2006 -0400, Brian Rosen wrote: > > >There is a point to limiting what can be sent in the Location header to > > >specific protocols which has received adequate review in both sip and > > >geopriv. > > > > > >So, here is my concrete proposal: > > >Location = "Location" HCOLON location-param *(COMMA location-param) > > >location-param = LAQUOT allowed-scheme HCOLON ":" ( hier-part / opaque- > > part > > >) RAQUOT *( SEMI loc-param ) ; hier-part and opaque-part from 3261 > > >allowed-scheme = 'cid' / 'http' / 'https' / 'sip' / 'sips' / 'prez' > > >loc-param = 'location-dereference-protocol=' deref-protocol / > > >generic-param > > >deref-protocol = token > > > > I'm still not a fan of using 'sip' here. 'sip' or 'sips' means using > > SUBSCRIBE and that's a PULL mechanism in this scenario; i.e. the UAC > > that's > > subscribing to another SIP element is not using its location to do > > anything > > (that will come back in the NOTIFY). The UAC (in the SUB transaction) in > > this scenario is PULLING another UA's location from somewhere, and that's > > not "Location Conveyance" - which is what I got hammered on in the Paris > > meeting. > > > > Clear consensus from that meeting was that this document describes PUSHING > > my UAC's location to somewhere else. > > > > Using HTTP(S) to fetch (presumably with a GET request) my > > location-by-reference once from a server is not a pull, it is a > > Content-Indirection operation, which is a fake of a PUSH, IMO. > > > > Using a SUBSCRIBE, you are always receiving something in the NOTIFY. If > > "location" is what's returned in that NOTIFY, this is a "Location > > Retreaval" PULL, and against what the Paris meeting said to do, and is for > > another document, a PULL mechanism document that hasn't been written yet. > > > > Therefore, I recommend we remove sip: and sips: from the BNF above. I'm > > still thinking about what to do about the 'pres' proposal. > > > > Adam's scenario (on the mike in Montreal) about using SUBSCRIBE to a > > weather service did not have Adam's location coming back in the NOTIFY, so > > that use-case doesn't apply to this discussion (but is a great use-case!) > > > > comments > > > > James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 19:30:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3hwJ-0007CX-N8; Thu, 20 Jul 2006 19:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3hwI-0007CS-6d for sip@ietf.org; Thu, 20 Jul 2006 19:28:18 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3hwF-0002Qb-Hu for sip@ietf.org; Thu, 20 Jul 2006 19:28:18 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2006 16:28:14 -0700 X-IronPort-AV: i="4.07,164,1151910000"; d="scan'208"; a="307078952:sNHT29132956" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KNSE8J026777; Thu, 20 Jul 2006 16:28:14 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6KNSB79021014; Thu, 20 Jul 2006 16:28:11 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 19:28:11 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 19:28:11 -0400 Message-ID: <44C0118A.2050105@cisco.com> Date: Thu, 20 Jul 2006 19:28:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] Allowing sip: (or prez:) in the location header References: <041c01c6ac2e$49e5d530$640fa8c0@cis.neustar.com> In-Reply-To: <041c01c6ac2e$49e5d530$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2006 23:28:11.0210 (UTC) FILETIME=[2A36C2A0:01C6AC54] DKIM-Signature: a=rsa-sha1; q=dns; l=4609; t=1153438094; x=1154302094; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Allowing=20sip=3A=20(or=20prez=3A)=20in=20the=20location =20header; X=v=3Dcisco.com=3B=20h=3DED6rJY2rneCveiROfpaiH3eGIOY=3D; b=PkhV/IInOpvYqsw+p+PCreImuqxTr/SZ+X0Xi4fTeyaJGHVCrTkffVNw1tG37XNJasHig+R/ VIROvKrlpGsP4JK5lKsfaivhqIvVbt3dmrQvjrJCObJEozziXNq/PHeP; Authentication-Results: sj-dkim-5.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: sip@ietf.org, "'Thomson, Martin'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, In general I could go with either a syntactic or semantic constraint. In general I think a syntactic constraint is preferred if it is possible, and the fallback to semantic constraint comes when the concept can't be represented precisely in the syntax, or is too cumbersome to do in practice. But I am concerned with how you have tried to do this in syntax. What you have ended up with is a looser definition for a SIP URI than is present in 3261. That at least "smells a little funny". If you want to do it in syntax, then I think you should enumerate the syntactic type of each kind of URI you want to permit. That still allows new ones to be added, but then at least each one will be properly constrained. Paul Brian Rosen wrote: > Jeroen > > I don't agree that this is a semantic issue; we are restricting precisely > what may appear in allowed-scheme. I usually think it's better to have the > ABNF precise, rather than relying on text to state what is actually > permitted on the wire. We are talking about what is syntactically allowed, > not how you interpret it. > > The ABNF =/ syntax (from RFC4234) is a convenient way to add a scheme to the > list, even when used by independently created RFCs. > > I, like Andy, don't believe the decision on which protocols can appear in > allowed-scheme can be left to implementation. Every dereferencer has to be > prepared to use every possible protocol, especially on the Internet, because > there is no way to ask for a specific URI or limit the schemes the location > acquisition mechanism may obtain. > > Brian > >> -----Original Message----- >> From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: Thursday, July 20, 2006 1:03 PM >> To: Brian Rosen; 'Thomson, Martin'; sip@ietf.org >> Subject: RE: [Sip] Allowing sip: (or prez:) in the location header >> >> Brian, >> >> To me using ABNF rules to restrict allowable schemes is not a good idea. >> ABNF defines syntax, not semantics >> >> Compare this with the Route header in SIP. The ABNF allows any scheme, >> text says it MUST be sip: or sips:. That suffices (you could define which >> error response must be sent) >> >> Moreover, the protocol to use is a policy decision. You can make >> recommendations, even define new mechanisms, but I think the choice should >> be left to implementors >> >> Regards, >> >> Jeroen >> -----Oorspronkelijk bericht ----- >> Van: "Brian Rosen" >> Aan: "'Thomson, Martin'" ; sip@ietf.org >> Verzonden: 20-7-06 18:19 >> Onderwerp: RE: [Sip] Allowing sip: (or prez:) in the location header >> >> There is a point to limiting what can be sent in the Location header to >> specific protocols which has received adequate review in both sip and >> geopriv. >> >> So, here is my concrete proposal: >> Location = "Location" HCOLON location-param *(COMMA location-param) >> location-param = LAQUOT allowed-scheme HCOLON ":" ( hier-part / opaque- >> part >> ) RAQUOT *( SEMI loc-param ) ; hier-part and opaque-part from 3261 >> allowed-scheme = 'cid' / 'http' / 'https' / 'sip' / 'sips' / 'prez' >> loc-param = 'location-dereference-protocol=' deref-protocol / >> generic-param >> deref-protocol = token >> >> allowed-scheme may be extended by a standards-track RFC. Such an >> extension >> is NOT considered a SIP extension and is NOT subject to the process >> defined >> by RFC3427. Corresponding resolution processes for such schemes MUST be >> included in the RFC, and MAY be subject to review against RFC3693. >> >> This document (in Section ?) defines a new IANA registry for deref- >> protocol, >> and populates it with one initial value, 'rawGET'. rawGET indicates that >> the location reference may be dereferenced by sending a GET with no >> parameters on the URI, using HTTPS (except in the emergency case, where >> HTTP >> is permitted), and expects to receive one PIDF-LO document (with a MIME- >> type >> of "application/pidf+xml")in response. deref-protocol MUST be included if >> the scheme is HTTPS (or HTTP in the emergency case). Other schemes may or >> may not require deref-protocol. A standards-track RFC is required to add >> a > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 19:55:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iKq-0008Sd-JH; Thu, 20 Jul 2006 19:53:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iKp-0008Ri-2N for sip@ietf.org; Thu, 20 Jul 2006 19:53:39 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3iEn-0005SO-LO for sip@ietf.org; Thu, 20 Jul 2006 19:47:26 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 18:47:25 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 20 Jul 2006 18:47:24 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 18:47:23 -0500 Message-ID: From: "Thomson, Martin" To: "Brian Rosen" , "Jeroen van Bemmel" , "Andrew Newton" Date: Thu, 20 Jul 2006 18:45:13 -0500 Subject: RE: [Sip] Allowing sip: (or prez:) in the location header MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 20 Jul 2006 23:47:23.0724 (UTC) FILETIME=[D92A70C0:01C6AC56] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <045e01c6ac43$4b9a7d80$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Sip] Allowing sip: (or prez:) in the location header Thread-Index: AcasO3OmXlXjfodWTX+uckDAISG8WAAA/yagAANFnPA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0556674270==" Errors-To: sip-bounces@ietf.org --===============0556674270== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message Tm8sIEkgdGhpbmsgdGhhdCBKZXJvZW4gaGFzIGV4YWN0bHkgdGhlIHJpZ2h0IGlkZWEuICBSZXN0 cmljdGlvbiBjYW4gZXhpc3QgYXQgdHdvIGxldmVscywgYW5kIGluIHRoaXMgY2FzZSwgdGV4dCBp cyB0aGUgY29ycmVjdCBwbGFjZSBmb3IgdGhvc2UgY2hvaWNlcy4gIEkgZG9uJ3QgbGlrZSB0byBh cmd1ZSBmcm9tIHByZWNlZGVudCwgYnV0IHRoZXJlIGlzIGEgY2xlYXIgcHJlY2VkZW50IGZvciB0 aGlzLg0KDQpUaGUgaXNzdWUgb2YgYXR0YWNoaW5nIGFkZGl0aW9uYWwgcGFyYW1ldGVycyB0byBh IFVSSSAoIlVSSSBtZXRhZGF0YSIpIGlzIGEgZ29vZCBvbmUsIGFuZCBwZXJtaXRzIHRoZSB1c2Ug b2YgdmFsdWUtYWRkIHByb3RvY29scy4gIEJ1dCB0aGF0IHNob3VsZCBub3QgYWZmZWN0IHRoZSBi YXNpYyBzcGVjaWZpY2F0aW9uLCBpdCBjYW4gcmVtYWluIG9wdGlvbmFsLg0KDQpUaGlzIGNhbiBi ZSB2ZXJ5IHNpbXBseSBzcGVjaWZpZWQ6IElmIHRoZSBodHRwczogVVJJIGV4aXN0cyBhIHJhdyBH RVQgTVVTVCBiZSBwb3NzaWJsZS4gIEFuIGh0dHBzOiBVUkkgaXMgd2lkZWx5IHVuZGVyc3Rvb2Qs IGFuZCBJIGRvbid0IHRoaW5rIHRoYXQgdGhpcyBiZWhhdmlvdXIgaXMgY29udHJhZGljdG9yeSB0 byBhbnkgZXhwZWN0YXRpb25zLiAgVGhlIHZhbHVlLWFkZCBwcm90b2NvbHMgY2FuIGJlIGV4ZXJj aXNlZCBieSBhIFBPU1QsIGlmIHRoZSBwYXJhbWV0ZXJzIGluZGljYXRlIGEgc3BlY2lmaWMgcHJv dG9jb2wgaXMgc3VwcG9ydGVkIGFuZCB0aGUgcmVxdWVzdGVyIHVuZGVyc3RhbmRzIHRoZSBwYXJh bWV0ZXIgYW5kIHRoZSBwcm90b2NvbC4gIEEgR0VUIHNob3VsZCBzdGlsbCBiZSBwb3NzaWJsZSBy ZWdhcmRsZXNzLg0KDQpZb3UgZG9uJ3QgbmVlZCB0byBjcmVhdGUgYSByZWdpc3RyeSBmb3IgcHJv dG9jb2xzIHJpZ2h0IG5vdzsgbGV0IHRob3NlIHByb3RvY29sIHNwZWNpZmljYXRpb25zIChwbGVh c2UsIGxldCB0aGVyZSBiZSBvbmx5IG9uZSkgZGVhbCB3aXRoIHRoYXQuDQoNCk9uZSBwcm9ibGVt IHdpdGggbGltaXRpbmcgYXMgeW91IGhhdmUgaXMgdGhhdCB5b3UgaGF2ZSB0byBiZSB2ZXJ5IGNs ZWFyIGluIGhvdyBlYWNoIG9mIHRob3NlIHByb3RvY29scyBhcmUgdXNlZC4gIE5vdywgZ2l2ZW4g UGF1bCdzIGNvbW1lbnRzLCBJIHRoaW5rIHRoYXQgc2lwW3NdIGFuZCBwcmVzIG5lZWQgYSBsaXR0 bGUgbW9yZSBpbmZvIC0gZG8geW91IHdhbnQgdG8gaW5jbHVkZSB0aGF0IGFzIHdlbGw/DQoNClVs dGltYXRlbHksIEkgYW0gYXJndWluZyBmb3IgYSBzbWFsbGVyIGxvY2F0aW9uIGNvbnZleWFuY2Ug ZHJhZnQuICBUaGUgcHJvYmxlbSB3aXRoIHRoZXNlIGRpc2N1c3Npb25zIGlzIHRoYXQgeW91IGNh biwgZWZmZWN0aXZlbHksIHJlZmluZSBpbmRlZmluaXRlbHkuICBEbyB3ZSBzdGFydCB0byBkaXNj dXNzIHdoYXQgYXV0aGVudGljYXRpb24gbWV0aG9kcyBhcmUgYXBwcm9wcmlhdGUgaW4gdGhlIEhU VFAgR0VUPyAgV2hhdCBhYm91dCBIVFRQIGhlYWRlcnM/ICBIb3cgd2UgZGVhbCB3aXRoIGNhY2hp bmc/ICBUTFMgY2lwaGVyLXN1aXRlcz8gIEkgdGhpbmsgdGhhdCBpdCdzIGltcG9ydGFudCB0byBr bm93IHdoZW4gdG8gZHJhdyB0aGUgbGluZS4NCg0KUmVnYXJkcywNCk1hcnRpbg0KDQpwLnMuLi4g cy9wcmV6L3ByZXMvDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJp YW4gUm9zZW4gW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0NCj4gU2VudDogRnJpZGF5LCAyMSBK dWx5IDIwMDYgNzoyNyBBTQ0KPiBUbzogJ0plcm9lbiB2YW4gQmVtbWVsJzsgJ0FuZHJldyBOZXd0 b24nDQo+IENjOiBUaG9tc29uLCBNYXJ0aW47IHNpcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTog W1NpcF0gQWxsb3dpbmcgc2lwOiAob3IgcHJlejopIGluIHRoZSBsb2NhdGlvbiBoZWFkZXINCj4g DQo+IEkgZG9uJ3QgdGhpbmsgeW91IGhhdmUgdGhlIGJpZyBwaWN0dXJlLg0KPiANCj4gTG9jYXRp b24gY29tZXMgZnJvbSB0aGUgYWNjZXNzIG5ldHdvcmssIHZpYSBzb21lIGFjcXVpc2l0aW9uIHBy b3RvY29sLCBvcg0KPiBpbg0KPiBzb21lIGNhc2VzLCBjYW4gYmUgc2VsZiBnZW5lcmF0ZWQgaW4g dGhlIGVuZHBvaW50LiAgIFRoZSBhY2Nlc3MgbmV0d29yaw0KPiBkZWNpZGVzIHdoYXQgdGhlIHJl cHJlc2VudGF0aW9uIG9mIHRoZSBsb2NhdGlvbiBpcyBpZiBpdCdzIHN1cHBseWluZw0KPiBsb2Nh dGlvbiwgYWx0aG91Z2ggaXQgbWF5IGdpdmUgYW4gZW5kcG9pbnQgc29tZSBvcHRpb25zICh2YWx1 ZS9yZWZlcmVuY2UsDQo+IGNpdmljL2dlbykuDQo+IA0KPiBUaGUgVUFDIGdldHMgdGhpcyBsb2Nh dGlvbiBhbmQgcHV0cyBpdCBpbiB0aGUgU0lQIG1lc3NhZ2UuDQo+IA0KPiBTb21lIGVudGl0eSwg Y291bGQgYmUgYSBwcm94eSBmb3IgbG9jYXRpb24gYmFzZWQgcm91dGluZywgb3IgdGhlIFVBUywg Z2V0cw0KPiB0aGUgbG9jYXRpb24gYW5kIGRvZXMgc29tZXRoaW5nIHdpdGggaXQuDQo+IA0KPiBG b3IgdGhlIHNha2Ugb2YgYXJndW1lbnQsIGFzc3VtZSBpdHMgbG9jYXRpb24tYnktcmVmZXJlbmNl Lg0KPiBDYWxsIHRoZSBwcm94eSBvciBVQVMgdGhlICJkZS1yZWZlcmVuY2VyIi4NCj4gDQo+IEl0 J3MgdGhlIGFjY2VzcyBuZXR3b3JrIChjb3VsZCBiZSBhIGJyb2FkYmFuZCBjYXJyaWVyLCBjb3Vs ZCBiZSBhbg0KPiBlbnRlcnByaXNlKSB0aGF0IGlzIHB1dHRpbmcgdXAgdGhlIHNlcnZlciB0aGF0 IHByb3ZpZGVzIHRoZSBkZS1yZWZlcmVuY2UNCj4gc2VydmljZS4gIENhbGwgdGhlIHNlcnZlciBh ICJMb2NhdGlvbiBJbmZvcm1hdGlvbiBTZXJ2ZXIiID0gTElTDQo+IA0KPiBPa2F5LCBzbyB0aGUg YWNjZXNzIG5ldHdvcmsgY2hvb3NlcyBzb21lIHByb3RvY29sLCBtYWtlcyB1cCBhIHN1aXRhYmxl IFVSSQ0KPiBhbmQgcGFzc2VzIGl0IHZpYSB0aGUgYWNxdWlzaXRpb24gcHJvdG9jb2wgdG8gdGhl IFVBQy4gIFRoZSBVQUMgcGFzc2VzIGl0DQo+IHRvDQo+IHRoZSBkZS1yZWZlcmVuY2VyLCB3aG8g cHJlc2VudHMgaXQgdG8gdGhlIExJUy4gIFRoZSBMSVMgcmVzcG9uZHMgd2l0aCB0aGUNCj4gbG9j YXRpb24gdmFsdWUuDQo+IA0KPiBUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBkZS1yZWZlcmVuY2Vy IGNhbid0IGNvbnRyb2wgd2hpY2ggTElTLCBhbmQgY2FuJ3QNCj4gY29udHJvbCB3aGF0IHByb3Rv Y29sIGRlY2lzaW9uIHRoZSBMSVMgbWFkZS4gIEl0IGhhcyB0byBpbXBsZW1lbnQgRVZFUlkNCj4g T05FDQo+IG9mIHRoZSBwcm90b2NvbHMgdGhhdCBjb3VsZCBhcHBlYXIgaW4gdGhlIExvY2F0aW9u IGhlYWRlci4gIElmIHRoZSBMSVMNCj4gaW1wbGVtZW50cyBhIHByb3RvY29sIHRoZSBkZS1yZWZl cmVuY2VyIGRvZXNuJ3QgdW5kZXJzdGFuZCwgdGhlIHdob2xlDQo+IG1lY2hhbmlzbSBmYWlscywg d2l0aCBubyByZWNvdXJzZS4gIE9uIHRoZSBJbnRlcm5ldCwgd2hpY2ggaXMgd2hlcmUgd2UNCj4g d2FudA0KPiB0aGUgcHJvdG9jb2xzIHRvIHdvcmssIHlvdSBjYW4ndCBjb250cm9sIHdoaWNoIGFj Y2VzcyBuZXR3b3JrIHRoZSBVQUMgaXMNCj4gY29taW5nIGZyb20uDQo+IA0KPiBTbywgaW5zdGVh ZCwgd2UgcmVzdHJpY3QgdGhlIGxpc3Qgb2YgYWxsb3dlZCBkZS1yZWZlcmVuY2luZyBwcm90b2Nv bHMgdG8gYQ0KPiBzbWFsbCBudW1iZXIsIGFuZCBtYWtlIHRoYXQgbGlzdCB2ZXJ5IGV4cGxpY2l0 LiAgTm93IGEgZGUtcmVmZXJlbmNlciBrbm93cw0KPiB0aGF0IGlmIGhlIGltcGxlbWVudHMgQUxM IG9mIHRoZSBsaXN0ZWQgcHJvdG9jb2xzLCBoZSB3aWxsIGJlIGFibGUgdG8NCj4gZGVyZWZlcmVu Y2UgYW55IGxvY2F0aW9uIHJlZmVyZW5jZSBoZSBnZXRzLg0KPiANCj4gDQo+IA0KPiBUaGVyZSBp cyBhbm90aGVyIGJpZyBwaWN0dXJlIGFzcGVjdC4gIFRoZSB3aG9sZSBsb2NhdGlvbiB0aGluZyBj b21lcyB1bmRlcg0KPiBnZW9wcml2LiAgV2UgaGF2ZSB0byBkbyBhIHNpcCBMb2NhdGlvbiBoZWFk ZXIgaW4gc2lwLCBidXQgZ2VvcHJpdiBoYXMgdG8NCj4gcmV2aWV3IG91ciB3b3JrLiAgVGhlICJw cml2IiBwYXJ0IG9mIGdlb3ByaXYgaXMgcHJpdmFjeS4gIFRoZXkgY2FyZSwgYQ0KPiB3aG9sZQ0K PiBsb3QsIGFib3V0IHRoZSBwcml2YWN5IGFzcGVjdHMgb2YgbG9jYXRpb24uICBPbmUgZXhwcmVz c2lvbiBvZiB0aGF0DQo+IGNvbmNlcm4NCj4gaXMgdG8gaGF2ZSB0aGUgc2VjdXJpdHkgcG9zdHVy ZSBvZiAid2hhdCBpcyBub3QgZXhwbGljaXRseSBwZXJtaXR0ZWQgaXMNCj4gcHJvaGliaXRlZCIu ICBUaGV5IHJlYWxseSB0cnVseSB3YW50IHRvIGxvb2sgYXQgZXZlcnkgSUVURiBwcm90b2NvbCB0 aGF0DQo+IGlzDQo+IHVzZWQgdG8gZGUtcmVmZXJlbmNlIGxvY2F0aW9uLCBhbmQgZGVjaWRlIGlm IGl0IHByb3ZpZGVzIHN1ZmZpY2llbnQNCj4gcHJpdmFjeQ0KPiBwcm90ZWN0aW9uIGZvciBsb2Nh dGlvbi4gIFRoZXkgcmVhbGx5IGRvIHdhbnQgYW4gZXhwbGljaXQgbGlzdCwgYW5kIHRoZXkNCj4g d2FudCB0byBzY3J1dGluaXplIGV2ZXJ5IHByb3RvY29sIG9uIHRoYXQgbGlzdCB0byBzZWUgaG93 IGl0IGFkZHJlc3Nlcw0KPiB0aGVpcg0KPiBjb25jZXJucy4gIFNJUCBpcyB3aGF0IGdlb3ByaXYg Y2FsbHMgYSAidXNpbmcgcHJvdG9jb2wiIGFuZCB0aGV5IHJldmlldw0KPiB0aGVtDQo+IHNlcmlv dXNseS4gIFRoaXMgbWVhbnMsIGZvciBleGFtcGxlLCB0aGF0IGl0J3MgcHJvYmFibHkgbm90IG9r YXkgdG8gdXNlDQo+IEhUVFANCj4gdG8gZGUtcmVmZXJlbmNlLiAgVGhlcmUgaXMgYSBzcGVjaWZp YywgbGltaXRlZCBleGVtcHRpb24gZm9yIGVtZXJnZW5jeQ0KPiBjYWxscw0KPiBvbiB0aGF0LiAg U28gSFRUUFMgaXMgYSBNVVNULCBhbmQgSFRUUCBpcyBNVVNUIE5PVCBleGNlcHQgZm9yIHRoZQ0K PiBlbWVyZ2VuY3kNCj4gY2FzZS4gIEkgYmVsaWV2ZSB0aGF0ICJBYnNvbHV0ZVVSSSIgd291bGQg bm90IGJlIGFjY2VwdGFibGUgdG8gZ2VvcHJpdiwNCj4gYnV0DQo+IG9mIGNvdXJzZSBJIGNhbid0 IHNwZWFrIGZvciB0aGUgZ3JvdXAuDQo+IA0KPiBCcmlhbg0KPiANCj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEplcm9lbiB2YW4gQmVtbWVsIFttYWlsdG86amJlbW1l bEB6b25uZXQubmxdDQo+ID4gU2VudDogVGh1cnNkYXksIEp1bHkgMjAsIDIwMDYgNDozMSBQTQ0K PiA+IFRvOiBBbmRyZXcgTmV3dG9uDQo+ID4gQ2M6IEJyaWFuIFJvc2VuOyAnVGhvbXNvbiwgTWFy dGluJzsgc2lwQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtTaXBdIEFsbG93aW5nIHNpcDog KG9yIHByZXo6KSBpbiB0aGUgbG9jYXRpb24gaGVhZGVyDQo+ID4NCj4gPiBBbmRyZXcsDQo+ID4N Cj4gPiA+PiBNb3Jlb3ZlciwgdGhlIHByb3RvY29sIHRvIHVzZSBpcyBhIHBvbGljeSBkZWNpc2lv bi4gWW91IGNhbiBtYWtlDQo+ID4gPj4gcmVjb21tZW5kYXRpb25zLCBldmVuIGRlZmluZSBuZXcg bWVjaGFuaXNtcywgYnV0IEkgdGhpbmsgdGhlIGNob2ljZQ0KPiA+ID4+IHNob3VsZCBiZSBsZWZ0 IHRvIGltcGxlbWVudG9ycw0KPiA+ID4NCj4gPiA+IEkgZGlzYWdyZWUgd2l0aCB0aGlzLiAgV2hh dCBpcyBteSBzZXJ2ZXIgZ29ubmEgZG8gd2l0aCBhIG1haWx0bzogb3INCj4gZG5zOg0KPiA+ID4g VVJJPyAgVGhlcmUgc2hvdWxkIGJlIGEgc21hbGwgbGlzdCBvZiBhY2NlcHRhYmxlIGNob2ljZXMg aWYgd2Ugd2FudA0KPiA+ID4gaW50ZXJvcGVyYWJpbGl0eS4NCj4gPg0KPiA+IEluIHN1Y2ggYSBj YXNlIHlvdXIgc2VydmVyIHNob3VsZCBwcm9iYWJseSByZXNwb25kIHdpdGggIjR4eCBMb2NhdGlv bg0KPiBVUkkNCj4gPiBTY2hlbWUgbm90IHN1cHBvcnRlZCIsIHdoZXJlIDR4eCBpcyBUQkQuIEhv d2V2ZXIsIGlmIHJldHJpZXZpbmcgdGhlDQo+ID4gbG9jYXRpb24NCj4gPiBpcyBub3QgY3JpdGlj YWwgdG8gY29tcGxldGluZyB0aGUgY2FsbCwgdGhlbiBpdCBzaG91bGQgcHJvYmFibHkgaWdub3Jl DQo+IHRoZQ0KPiA+IGhlYWRlci4gU28gdGhlcmUgc2VlbXMgdG8gYmUgYSBuZWVkIGZvciBhIHBh cmFtZXRlciBpbmRpY2F0aW5nDQo+ICJvcHRpb25hbCINCj4gPiB2ZXJzdXMgInJlcXVpcmVkIg0K PiA+DQo+ID4gSU1PIHRoZSB0ZXh0IGluIHRoZSBkcmFmdCBzaG91bGQgc2F5Og0KPiA+IC0gcHJv eGllcyBNVVNUIHN1cHBvcnQgSFRUUCwgU0hPVUxEIHN1cHBvcnQgSFRUUFMsIE1BWSBzdXBwb3J0 IGNpZCAoZm9yDQo+ID4gZGVyZWZlcmVuY2luZykNCj4gPiAtIFVBUyBNVVNUIHN1cHBvcnQgSFRU UCBhbmQgY2lkLCBTSE9VTEQgc3VwcG9ydCBIVFRQUyAoZm9yDQo+IGRlcmVmZXJlbmNpbmcpDQo+ ID4gLSBUQkQ6IGRlZmluZSB3aGV0aGVyIGFuZCB3aGVuIHByb3h5L1VBUyBzaG91bGQgZ2VuZXJh dGUgZXJyb3IgZm9yDQo+ID4gdW5zdXBwb3J0ZWQgVVJJIHNjaGVtZSAoYW5kIHRoZW4gaW5kaWNh dGUgd2hpY2ggc2NoZW1lcyBhcmUgc3VwcG9ydGVkKQ0KPiA+IC0gVUFDL1Byb3h5IFNIT1VMRCB1 c2UgSFRUUFMgd2hlbiBhZGRpbmcgTG9jYXRpb24gYnkgcmVmZXJlbmNlDQo+ID4gLSBVQUMgTUFZ IHVzZSBjaWQgZm9yIGxvY2F0aW9uIGJ5IHZhbHVlLCBidXQgU0hPVUxEIHRoZW4gZW5zdXJlDQo+ ID4gY29uZmlkZW50aWFsaXR5DQo+ID4NCj4gPiBCdXQgYWJvdmUgYWxsOiB0aGUgZHJhZnQgc2hv dWxkIHNwZWNpZnkgd2hhdCBpcyBtaW5pbWFsbHkgbmVlZGVkIHRvIG1lZXQNCj4gPiB0aGUNCj4g PiBzdGF0ZWQgcmVxdWlyZW1lbnRzLCB3aGlsZSBub3QgdW5uZWNlc3NhcmlseSByZXN0cmljdGlu ZyBzb2x1dGlvbnMgdGhhdA0KPiA+IG1pZ2h0IGhhdmUgYWRkaXRpb25hbCByZXF1aXJlbWVudHMg d2hpY2ggYXJlIG5vdCBjdXJyZW50bHkgZm9yZXNlZW4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4N Cj4gPiBqZXJvZW4NCj4gDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQg bWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0 ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwu ICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ== --===============0556674270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0556674270==-- From sip-bounces@ietf.org Thu Jul 20 19:59:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iOo-0001OA-JK; Thu, 20 Jul 2006 19:57:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iOn-0001O2-7h; Thu, 20 Jul 2006 19:57:45 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3iOm-0006vw-0u; Thu, 20 Jul 2006 19:57:45 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 18:57:43 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 20 Jul 2006 18:57:43 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 18:57:43 -0500 Message-ID: From: "Thomson, Martin" To: "James M. Polk" , "Brian Rosen" , , Date: Thu, 20 Jul 2006 18:55:44 -0500 Subject: RE: [Sip] Allowing sip: in location header not good MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 20 Jul 2006 23:57:43.0094 (UTC) FILETIME=[4A56CD60:01C6AC58] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <4.3.2.7.2.20060720175701.036a4240@email.cisco.com> Content-class: urn:content-classes:message Thread-Topic: [Sip] Allowing sip: in location header not good Thread-Index: AcasUv5CCbe/H3HyTFazJYKgaGGq/QABGkkg X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0645656665==" Errors-To: sip-bounces@ietf.org --===============0645656665== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSBkb24ndCB0aGluayB0aGF0IHlvdSBuZWVkIHRvIHByZWNsdWRlIHRoZSB1c2Ugb2YgU0lQIGhl cmUsIGJ1dCB0aGVyZSBhcmUgYSBsb3Qgb2YgdGhpbmdzIHRoYXQgbmVlZCB0byBiZSBjb25zaWRl cmVkIGJlZm9yZSBTVUIvTk9UIGFyZSBhbGxvd2VkLg0KDQpUaGF0IGlzIHRvIHNheSAtIHRoZSBs b2NhdGlvbiBjb252ZXlhbmNlIGRvY3VtZW50IGRvZXNuJ3QgY292ZXIgaXRzIHVzZSwgYW5kIG5v dGhpbmcgZWxzZSBkb2VzLi4ueWV0LiAgV2hlbiBzb21lb25lIGRvZXMgYSB1c2luZy1wcm90b2Nv bCBzcGVjaWZpY2F0aW9uIGZvciBTVUIvTk9ULCB0aGVuIHdlIGhhdmUgYSBwbGFjZSB0byBkZXNj cmliZSBob3cgdG8gdXNlIHNpcFtzXTogaW4gdGhlIExvY2F0aW9uIGhlYWRlci4NCg0KRmFjdCBp cyAtIEkgZG9uJ3QgdGhpbmsgdGhhdCB3ZSBoYXZlIEFOWSB1c2luZy1wcm90b2NvbCBkZWZpbmVk LCBoZW5jZSB0aGUgcHJvYmxlbXMgd2UgYXJlIGhhdmluZyBpbiBkZWNpZGluZyB3aGF0IGdvZXMg aW4gdGhlIGhlYWRlci4NCg0KDQo+ICAgICAgICAgICAgICAgICAgKGFuZCBJJ20gbm90IHNvIHN1 cmUgYWJvdXQgJ3ByZXMnKQ0KDQpBIHByZXM6IFVSSSBpcyBpbiBlZmZlY3QgYSBzaXBbc106IFVS SSBmb3IgdGhlc2UgcHVycG9zZXMuDQoNCg0KQ2hlZXJzLA0KTWFydGluDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2ln bmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmll dGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJl Y2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5 IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMg ZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KW21mMl0= --===============0645656665== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0645656665==-- From sip-bounces@ietf.org Thu Jul 20 20:22:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ikc-0001T1-UG; Thu, 20 Jul 2006 20:20:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ikb-0001Sw-2M for sip@ietf.org; Thu, 20 Jul 2006 20:20:17 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ika-0008Fr-LD for sip@ietf.org; Thu, 20 Jul 2006 20:20:17 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3ikP-0006WE-3Q; Thu, 20 Jul 2006 19:20:05 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" Subject: RE: [Sip] Allowing sip: (or prez:) in the location header Date: Thu, 20 Jul 2006 20:20:06 -0400 Message-ID: <04ae01c6ac5b$6f6e0340$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcasVCl+EqdkBuhaSjuoxKLi/PrwkAAAgSIw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44C0118A.2050105@cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: sip@ietf.org, "'Thomson, Martin'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just to make sure I'm following you, the part you are unhappy with would be the "heir-part / opaque-part" which is the definition of AbsoluteURI in 3261? You would want me to define something that was closer to what each URI scheme uses for what comes after the colon? So maybe: location-param = LAQUOT allowed-URI RAQUOT *( SEMI loc-param ) ;cid-url from RFC2111 ;http_URL from RFC2616; ;SIP/SIPS-URI from RFC3261 ;PRES-URI from RFC3859 allowed-URI = cid-uri / http_URL / https_URL / SIP-URI / SIPS-URI / PRES-URI Amusing side note on this. I don't believe there is any actual definition of an https_URL. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, July 20, 2006 7:28 PM > To: Brian Rosen > Cc: 'Jeroen Van Bemmel'; 'Thomson, Martin'; sip@ietf.org > Subject: Re: [Sip] Allowing sip: (or prez:) in the location header > > Brian, > > In general I could go with either a syntactic or semantic constraint. In > general I think a syntactic constraint is preferred if it is possible, > and the fallback to semantic constraint comes when the concept can't be > represented precisely in the syntax, or is too cumbersome to do in > practice. > > But I am concerned with how you have tried to do this in syntax. What > you have ended up with is a looser definition for a SIP URI than is > present in 3261. That at least "smells a little funny". > > If you want to do it in syntax, then I think you should enumerate the > syntactic type of each kind of URI you want to permit. That still allows > new ones to be added, but then at least each one will be properly > constrained. > > Paul > > Brian Rosen wrote: > > Jeroen > > > > I don't agree that this is a semantic issue; we are restricting > precisely > > what may appear in allowed-scheme. I usually think it's better to have > the > > ABNF precise, rather than relying on text to state what is actually > > permitted on the wire. We are talking about what is syntactically > allowed, > > not how you interpret it. > > > > The ABNF =/ syntax (from RFC4234) is a convenient way to add a scheme to > the > > list, even when used by independently created RFCs. > > > > I, like Andy, don't believe the decision on which protocols can appear > in > > allowed-scheme can be left to implementation. Every dereferencer has to > be > > prepared to use every possible protocol, especially on the Internet, > because > > there is no way to ask for a specific URI or limit the schemes the > location > > acquisition mechanism may obtain. > > > > Brian > > > >> -----Original Message----- > >> From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl] > >> Sent: Thursday, July 20, 2006 1:03 PM > >> To: Brian Rosen; 'Thomson, Martin'; sip@ietf.org > >> Subject: RE: [Sip] Allowing sip: (or prez:) in the location header > >> > >> Brian, > >> > >> To me using ABNF rules to restrict allowable schemes is not a good > idea. > >> ABNF defines syntax, not semantics > >> > >> Compare this with the Route header in SIP. The ABNF allows any scheme, > >> text says it MUST be sip: or sips:. That suffices (you could define > which > >> error response must be sent) > >> > >> Moreover, the protocol to use is a policy decision. You can make > >> recommendations, even define new mechanisms, but I think the choice > should > >> be left to implementors > >> > >> Regards, > >> > >> Jeroen > >> -----Oorspronkelijk bericht ----- > >> Van: "Brian Rosen" > >> Aan: "'Thomson, Martin'" ; sip@ietf.org > >> Verzonden: 20-7-06 18:19 > >> Onderwerp: RE: [Sip] Allowing sip: (or prez:) in the location header > >> > >> There is a point to limiting what can be sent in the Location header to > >> specific protocols which has received adequate review in both sip and > >> geopriv. > >> > >> So, here is my concrete proposal: > >> Location = "Location" HCOLON location-param *(COMMA location- > param) > >> location-param = LAQUOT allowed-scheme HCOLON ":" ( hier-part / opaque- > >> part > >> ) RAQUOT *( SEMI loc-param ) ; hier-part and opaque-part from 3261 > >> allowed-scheme = 'cid' / 'http' / 'https' / 'sip' / 'sips' / 'prez' > >> loc-param = 'location-dereference-protocol=' deref-protocol / > >> generic-param > >> deref-protocol = token > >> > >> allowed-scheme may be extended by a standards-track RFC. Such an > >> extension > >> is NOT considered a SIP extension and is NOT subject to the process > >> defined > >> by RFC3427. Corresponding resolution processes for such schemes MUST > be > >> included in the RFC, and MAY be subject to review against RFC3693. > >> > >> This document (in Section ?) defines a new IANA registry for deref- > >> protocol, > >> and populates it with one initial value, 'rawGET'. rawGET indicates > that > >> the location reference may be dereferenced by sending a GET with no > >> parameters on the URI, using HTTPS (except in the emergency case, where > >> HTTP > >> is permitted), and expects to receive one PIDF-LO document (with a > MIME- > >> type > >> of "application/pidf+xml")in response. deref-protocol MUST be included > if > >> the scheme is HTTPS (or HTTP in the emergency case). Other schemes may > or > >> may not require deref-protocol. A standards-track RFC is required to > add > >> a > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 20:55:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3jH6-00015B-S7; Thu, 20 Jul 2006 20:53:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3jH4-000123-Qi; Thu, 20 Jul 2006 20:53:51 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3jH3-0003TR-KY; Thu, 20 Jul 2006 20:53:50 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 20 Jul 2006 20:54:01 -0400 id 015880F1.44C025A9.0000778E In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6EC3E78C-FB29-4E95-B050-C95E26B99FED@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] RE: [Sip] Allowing sip: in location header not good Date: Thu, 20 Jul 2006 20:53:45 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org, geopriv@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 20, 2006, at 7:55 PM, Thomson, Martin wrote: > That is to say - the location conveyance document doesn't cover its > use, and nothing else does...yet. When someone does a using- > protocol specification for SUB/NOT, then we have a place to > describe how to use sip[s]: in the Location header. I guess we've all forgotten about RFC 4079. Here's the link: http://www.ietf.org/rfc/rfc4079.txt -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 20:56:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3jHy-0001ge-3x; Thu, 20 Jul 2006 20:54:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3jHw-0001ew-02; Thu, 20 Jul 2006 20:54:44 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3jHu-0003YA-Mr; Thu, 20 Jul 2006 20:54:43 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3jHi-0007vh-5z; Thu, 20 Jul 2006 19:54:30 -0500 From: "Brian Rosen" To: "'Thomson, Martin'" , "'James M. Polk'" , , Subject: RE: [Sip] Allowing sip: in location header not good Date: Thu, 20 Jul 2006 20:54:35 -0400 Message-ID: <04ba01c6ac60$3e598590$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcasUv5CCbe/H3HyTFazJYKgaGGq/QABGkkgAAHOPFA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think that ship has sailed. PIDF-LO is precisely defined in presence, and we don't need any documents that further describe how location is conveyed in a presence subscription. All this document would do is describe how you might go about specifying a presence uri that would be a little less general (provide less information) than the one you would get by using the "From:" URI. The ruleset for this presence uri would be different from the more general uri. Now, it does occur to me that if we allow sip/sips/pres, then we have a minimal resolution protocol for location by reference. It might be then acceptable to drop the whole raw GET idea completely, and leave that to the L7 protocol. I kind of like that idea, because the raw GET is really defining a whole new protocol and I don't think we want to, or need to, do that in this document. We brought it up because without at least a minimal dereference solution, the mechanism does not meet the requirements. A presence subscription would do that, with no need for more. And if we do that, we could drop the resolution-protocol parameter and registry, because sip/sips/pres doesn't need it. Brian > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, July 20, 2006 7:56 PM > To: James M. Polk; Brian Rosen; sip@ietf.org; geopriv@ietf.org > Subject: RE: [Sip] Allowing sip: in location header not good > > I don't think that you need to preclude the use of SIP here, but there are > a lot of things that need to be considered before SUB/NOT are allowed. > > That is to say - the location conveyance document doesn't cover its use, > and nothing else does...yet. When someone does a using-protocol > specification for SUB/NOT, then we have a place to describe how to use > sip[s]: in the Location header. > > Fact is - I don't think that we have ANY using-protocol defined, hence the > problems we are having in deciding what goes in the header. > > > > (and I'm not so sure about 'pres') > > A pres: URI is in effect a sip[s]: URI for these purposes. > > > Cheers, > Martin > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 21:39:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3jxi-0005yW-Ru; Thu, 20 Jul 2006 21:37:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3jwj-0004wc-Lm for sip@ietf.org; Thu, 20 Jul 2006 21:36:53 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3joF-00067f-Su for sip@ietf.org; Thu, 20 Jul 2006 21:28:10 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Q00F77CTPUX@szxga02-in.huawei.com> for sip@ietf.org; Fri, 21 Jul 2006 09:44:13 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Q00COSCTO74@szxga02-in.huawei.com> for sip@ietf.org; Fri, 21 Jul 2006 09:44:13 +0800 (CST) Received: from z53160 ([10.164.5.15]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2Q0070LC5WIE@szxml03-in.huawei.com> for sip@ietf.org; Fri, 21 Jul 2006 09:29:59 +0800 (CST) Date: Fri, 21 Jul 2006 09:27:17 +0800 From: Stephen Zhou Subject: RE: [Sip] Query reagrding RFC 3665 In-reply-to: <52db68bc0607200619o50341173uabe9f9e29881e0a4@mail.gmail.com> To: 'Sudhir' , sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcasF7bvllWZICAKTy2a1H0NVA9SOAATQg/A X-Spam-Score: 0.3 (/) X-Scan-Signature: 578029c71870398e30dc7af6a1ae528d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2106956307==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2106956307== Content-type: multipart/alternative; boundary="Boundary_(ID_y5yo1gmkmOpcodx6xHArOA)" This is a multi-part message in MIME format. --Boundary_(ID_y5yo1gmkmOpcodx6xHArOA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Sudhir, The contact is the last-hop route. So if no Route header in 200OK message, you should put the last-hop route to Request-URI. Stephen _____ From: Sudhir [mailto:t.sudhirkumar@gmail.com] Sent: Thursday, July 20, 2006 9:19 PM To: sip@ietf.org Subject: [Sip] Query reagrding RFC 3665 Hi All, In RFC 3261 the construction of ACK requestURI MUST conatain original request as it said in below paragraph 17.1.1.3 Construction of the ACK Request The ACK request constructed by the client transaction MUST contain values for the Call-ID, From, and Request-URI that are equal to the values of those header fields in the request passed to the transport by the client transaction (call this the "original request"). But, in RFC 3665 the contruction of RequestURI for ACK is taken from ConatctHeader of 200 OK as shown below. Could I know which is the approipraite one. Should I go for 3261 or Informational RFC 3665 RFC 3665 3.1. Successful Session Establishment INVITE sip:bob@biloxi.example.com SIP/2.0 200 OK contact Header: ACK sip:bob@client.biloxi.example.com SIP/2.0 thanks in advance regards Sudhir --Boundary_(ID_y5yo1gmkmOpcodx6xHArOA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Sudhir,

 

The contact is the last-hop route.

So if no Route header in 200OK message, you should put the last-hop route to Request-URI.

 

Stephen

 

From: Sudhir [mailto:t.sudhirkumar@gmail.com]
Sent: Thursday, July 20, 2006 9:19 PM
To: sip@ietf.org
Subject: [Sip] Query reagrding RFC 3665

 

Hi All,

 

In RFC 3261 the construction of ACK requestURI MUST conatain original request as it said in below paragraph 

17.1.1.3 Construction of the ACK Request

The ACK request constructed by the client transaction MUST contain
values for the Call-ID, From, and Request-URI that are equal to the
values of those header fields in the request passed to the transport
by the client transaction (call this the "original request").

But, in RFC 3665 the contruction of RequestURI for ACK is taken from ConatctHeader of 200 OK as shown below. Could I know which is the approipraite one. Should I go for 3261 or Informational RFC 3665

RFC 3665 3.1. Successful Session Establishment
INVITE sip:bob@biloxi.example.com SIP/2.0

200 OK contact Header: <sip:bob@client.biloxi.example.com>
ACK sip:bob@client.biloxi.example.com SIP/2.0

thanks in advance

regards

Sudhir

 

 

--Boundary_(ID_y5yo1gmkmOpcodx6xHArOA)-- --===============2106956307== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2106956307==-- From sip-bounces@ietf.org Thu Jul 20 21:46:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3k2h-0003ip-SI; Thu, 20 Jul 2006 21:43:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3k2f-0003gm-Pi for sip@ietf.org; Thu, 20 Jul 2006 21:43:01 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3k2a-00082t-JJ for sip@ietf.org; Thu, 20 Jul 2006 21:43:01 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Q00FU6DIEUX@szxga02-in.huawei.com> for sip@ietf.org; Fri, 21 Jul 2006 09:59:03 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Q00CM2DID74@szxga02-in.huawei.com> for sip@ietf.org; Fri, 21 Jul 2006 09:59:02 +0800 (CST) Received: from z53160 ([10.164.5.15]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2Q006GGCULLF@szxml03-in.huawei.com> for sip@ietf.org; Fri, 21 Jul 2006 09:44:49 +0800 (CST) Date: Fri, 21 Jul 2006 09:42:06 +0800 From: Stephen Zhou Subject: RE: [Sip] Query reagrding RFC 3665 In-reply-to: <52db68bc0607200619o50341173uabe9f9e29881e0a4@mail.gmail.com> To: 'Sudhir' , sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcasF7bvllWZICAKTy2a1H0NVA9SOAATvcMA X-Spam-Score: 0.3 (/) X-Scan-Signature: 8a7d7b1ff9fdb39b8762b25bc5367e56 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0620477502==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0620477502== Content-type: multipart/alternative; boundary="Boundary_(ID_sRF8TLNt/IKLxQyPXrLirQ)" This is a multi-part message in MIME format. --Boundary_(ID_sRF8TLNt/IKLxQyPXrLirQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Omit my previous letter. The contact is the last-hop route. So if no Record-Route header in 200OK message, you should put the last-hop route to Request-URI. Stephen _____ From: Sudhir [mailto:t.sudhirkumar@gmail.com] Sent: Thursday, July 20, 2006 9:19 PM To: sip@ietf.org Subject: [Sip] Query reagrding RFC 3665 Hi All, In RFC 3261 the construction of ACK requestURI MUST conatain original request as it said in below paragraph 17.1.1.3 Construction of the ACK Request The ACK request constructed by the client transaction MUST contain values for the Call-ID, From, and Request-URI that are equal to the values of those header fields in the request passed to the transport by the client transaction (call this the "original request"). But, in RFC 3665 the contruction of RequestURI for ACK is taken from ConatctHeader of 200 OK as shown below. Could I know which is the approipraite one. Should I go for 3261 or Informational RFC 3665 RFC 3665 3.1. Successful Session Establishment INVITE sip:bob@biloxi.example.com SIP/2.0 200 OK contact Header: ACK sip:bob@client.biloxi.example.com SIP/2.0 thanks in advance regards Sudhir --Boundary_(ID_sRF8TLNt/IKLxQyPXrLirQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

 

Omit my previous letter.

 

The contact is the last-hop route.

So if no Record-Route header in 200OK message, you should put the last-hop route to Request-URI.

 

Stephen

 

From: Sudhir [mailto:t.sudhirkumar@gmail.com]
Sent: Thursday, July 20, 2006 9:19 PM
To: sip@ietf.org
Subject: [Sip] Query reagrding RFC 3665

 

Hi All,

 

In RFC 3261 the construction of ACK requestURI MUST conatain original request as it said in below paragraph 

17.1.1.3 Construction of the ACK Request

The ACK request constructed by the client transaction MUST contain
values for the Call-ID, From, and Request-URI that are equal to the
values of those header fields in the request passed to the transport
by the client transaction (call this the "original request").

But, in RFC 3665 the contruction of RequestURI for ACK is taken from ConatctHeader of 200 OK as shown below. Could I know which is the approipraite one. Should I go for 3261 or Informational RFC 3665

RFC 3665 3.1. Successful Session Establishment
INVITE sip:bob@biloxi.example.com SIP/2.0

200 OK contact Header: <sip:bob@client.biloxi.example.com>
ACK sip:bob@client.biloxi.example.com SIP/2.0

thanks in advance

regards

Sudhir

 

 

--Boundary_(ID_sRF8TLNt/IKLxQyPXrLirQ)-- --===============0620477502== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0620477502==-- From sip-bounces@ietf.org Thu Jul 20 22:20:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3kaw-0001zD-Uj; Thu, 20 Jul 2006 22:18:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3kav-0001yX-03; Thu, 20 Jul 2006 22:18:25 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3kX7-0003dE-0h; Thu, 20 Jul 2006 22:14:30 -0400 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6L2GBpB021548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jul 2006 21:16:19 -0500 Message-ID: <44C03890.7080303@softarmor.com> Date: Thu, 20 Jul 2006 21:14:40 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] Allowing sip: in location header not good References: <04ba01c6ac60$3e598590$640fa8c0@cis.neustar.com> In-Reply-To: <04ba01c6ac60$3e598590$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip@ietf.org, geopriv@ietf.org, "'James M. Polk'" , "'Thomson, Martin'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Rosen wrote: > I think that ship has sailed. PIDF-LO is precisely defined in presence, and > we don't need any documents that further describe how location is conveyed > in a presence subscription. All this document would do is describe how you > might go about specifying a presence uri that would be a little less general > (provide less information) than the one you would get by using the "From:" > URI. The ruleset for this presence uri would be different from the more > general uri. > > Now, it does occur to me that if we allow sip/sips/pres, then we have a > minimal resolution protocol for location by reference. It might be then > acceptable to drop the whole raw GET idea completely, and leave that to the > L7 protocol. I kind of like that idea, because the raw GET is really > defining a whole new protocol and I don't think we want to, or need to, do > that in this document. We brought it up because without at least a minimal > dereference solution, the mechanism does not meet the requirements. A > presence subscription would do that, with no need for more. > > And if we do that, we could drop the resolution-protocol parameter and > registry, because sip/sips/pres doesn't need it. > Brian's words here are the first to make me say "Aha! I think we have something new" that I've read so far this evening. There may be some merit in this approach -- please consider it carefully. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 20 22:20:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3kbN-0002dO-Tk; Thu, 20 Jul 2006 22:18:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3kb4-00023X-Og; Thu, 20 Jul 2006 22:18:34 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3kDD-0000r6-Vo; Thu, 20 Jul 2006 21:53:57 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 20:53:55 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 20 Jul 2006 20:53:54 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 20:53:54 -0500 Message-ID: From: "Thomson, Martin" To: "Andrew Newton" Date: Thu, 20 Jul 2006 20:51:00 -0500 Subject: RE: [Geopriv] RE: [Sip] Allowing sip: in location header not good MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 21 Jul 2006 01:53:54.0209 (UTC) FILETIME=[85728910:01C6AC68] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <6EC3E78C-FB29-4E95-B050-C95E26B99FED@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Geopriv] RE: [Sip] Allowing sip: in location header not good Thread-Index: AcasYCH7zQii9JgPQxqBeZnsYkQS3wAB4OAA X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, geopriv@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0987035009==" Errors-To: sip-bounces@ietf.org --===============0987035009== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message WWVzLCBJIGhhZCBmb3Jnb3R0ZW4uDQoNClRoYXQgZG9jdW1lbnQgaXMgaW5mb3JtYXRpb25hbCwg c2F5aW5nIHRoYXQgbG9jYXRpb24gaXMgcHJlc2VuY2UuICBXaGF0IEkgaGF2ZW4ndCBnb3R0ZW4g eWV0LCBpcyB3aGV0aGVyIG9yIG5vdCB0aGlzIGRvY3VtZW50IGNvbnNlcXVlbnRseSBpbXBsaWVz IHRoYXQgUkZDcyAzMjY1LzM4NTkvZXRjLi4uIGRlZmluZSBhIHVzaW5nIHByb3RvY29sIHRoYXQg bWVldHMgUkZDIDM2OTMgcmVxdWlyZW1lbnRzLg0KDQpNDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogQW5kcmV3IE5ld3RvbiBbbWFpbHRvOmFuZHlAaHhyLnVzXQ0KPiBT ZW50OiBGcmlkYXksIDIxIEp1bHkgMjAwNiAxMDo1NCBBTQ0KPiBUbzogVGhvbXNvbiwgTWFydGlu DQo+IENjOiBKYW1lcyBNLiBQb2xrOyBCcmlhbiBSb3Nlbjsgc2lwQGlldGYub3JnOyBnZW9wcml2 QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbR2VvcHJpdl0gUkU6IFtTaXBdIEFsbG93aW5nIHNp cDogaW4gbG9jYXRpb24gaGVhZGVyIG5vdCBnb29kDQo+IA0KPiANCj4gT24gSnVsIDIwLCAyMDA2 LCBhdCA3OjU1IFBNLCBUaG9tc29uLCBNYXJ0aW4gd3JvdGU6DQo+ID4gVGhhdCBpcyB0byBzYXkg LSB0aGUgbG9jYXRpb24gY29udmV5YW5jZSBkb2N1bWVudCBkb2Vzbid0IGNvdmVyIGl0cw0KPiA+ IHVzZSwgYW5kIG5vdGhpbmcgZWxzZSBkb2VzLi4ueWV0LiAgV2hlbiBzb21lb25lIGRvZXMgYSB1 c2luZy0NCj4gPiBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGZvciBTVUIvTk9ULCB0aGVuIHdlIGhh dmUgYSBwbGFjZSB0bw0KPiA+IGRlc2NyaWJlIGhvdyB0byB1c2Ugc2lwW3NdOiBpbiB0aGUgTG9j YXRpb24gaGVhZGVyLg0KPiANCj4gSSBndWVzcyB3ZSd2ZSBhbGwgZm9yZ290dGVuIGFib3V0IFJG QyA0MDc5LiAgSGVyZSdzIHRoZSBsaW5rOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL3JmYy9yZmM0 MDc5LnR4dA0KPiANCj4gLWFuZHkNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5 IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBw cml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmln aW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQu DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============0987035009== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0987035009==-- From sip-bounces@ietf.org Fri Jul 21 00:29:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3mcE-0006Fe-1Q; Fri, 21 Jul 2006 00:27:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3mbx-0005pM-RJ for sip@ietf.org; Fri, 21 Jul 2006 00:27:37 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3mV6-0003Vq-HQ for sip@ietf.org; Fri, 21 Jul 2006 00:20:32 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 23:20:32 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 20 Jul 2006 23:20:31 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 23:20:30 -0500 Message-ID: From: "Thomson, Martin" To: "Brian Rosen" , "Paul Kyzivat" Date: Thu, 20 Jul 2006 23:18:38 -0500 Subject: RE: [Sip] Allowing sip: (or prez:) in the location header MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 21 Jul 2006 04:20:30.0939 (UTC) FILETIME=[00B502B0:01C6AC7D] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <04ae01c6ac5b$6f6e0340$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Sip] Allowing sip: (or prez:) in the location header Thread-Index: AcasVCl+EqdkBuhaSjuoxKLi/PrwkAAAgSIwAAjWr1A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1006216945==" Errors-To: sip-bounces@ietf.org --===============1006216945== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message TXkgbGFzdCBlbWFpbCBvbiB0aGUgdG9waWMsIEkgaG9wZS4NCg0KVGhlIGJlbG93IGlzIGZpbmUs IGJ1dCBJIHdvdWxkIGxpa2UgdG8gcG9pbnQgb3V0IHRoYXQgd2UgYXJlIGFibGUgdG8gZG8gc29t ZSBuaWNlIHRoaW5ncyB3aXRoIFNJUCBiZWNhdXNlIHRoZSBhdXRob3JzIHNhdyBmaXQgdG8gZGVm aW5lIHRoZSByZXF1ZXN0IFVSSSBhczoNCg0KUmVxdWVzdC1VUkkgICAgPSAgU0lQLVVSSSAvIFNJ UFMtVVJJIC8gYWJzb2x1dGVVUkkNCg0KVGhpcyBoYXMgZW5hYmxlZCB0aGUgdXNlIG9mIG90aGVy IHZhbHVlcy4gIFRoaW5rIHByZXM6IGFuZCB1cm46c2VydmljZTouDQoNCkknZCBhbHNvIGxpa2Ug dG8gcG9pbnQgb3V0IHRoYXQgdGhlIGFib3ZlIGNvbnRhaW5zIHJlZHVuZGFuY2llcy4gIElmIHdl IGdvIGJ5IFJGQyAzOTg2IGRlZmluaXRpb25zIGZvciBhYnNvbHV0ZVVSSSAoYW5kIHdlIHNob3Vs ZCwgZm9yIG5ldyBzcGVjaWZpY2F0aW9ucyksIFNJUC1VUkkgZGVmaW5lcyBhIHN1YnNldCBvZiBh YnNvbHV0ZVVSSSwgdGhlcmVmb3JlIGl0IGlzIG5vdCByZXF1aXJlZCBpbiB0aGF0IGRlZmluaXRp b24uDQoNCkNoZWVycywNCk1hcnRpbg0KDQpwLnMuIGh0dHBzOiBpcyB2ZXJ5IGxvb3NlbHkgZGVm aW5lZCBpbiBSRkMgMjgxOCBhY2NvcmRpbmcgdG8gdGhlIElBTkEgVVJJIHNjaGVtZSByZWdpc3Ry eS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBSb3NlbiBb bWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0XQ0KPiBTZW50OiBGcmlkYXksIDIxIEp1bHkgMjAwNiAx MDoyMCBBTQ0KPiBUbzogJ1BhdWwgS3l6aXZhdCcNCj4gQ2M6ICdKZXJvZW4gVmFuIEJlbW1lbCc7 IFRob21zb24sIE1hcnRpbjsgc2lwQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbU2lwXSBBbGxv d2luZyBzaXA6IChvciBwcmV6OikgaW4gdGhlIGxvY2F0aW9uIGhlYWRlcg0KPiANCj4gSnVzdCB0 byBtYWtlIHN1cmUgSSdtIGZvbGxvd2luZyB5b3UsIHRoZSBwYXJ0IHlvdSBhcmUgdW5oYXBweSB3 aXRoIHdvdWxkDQo+IGJlDQo+IHRoZSAiaGVpci1wYXJ0IC8gb3BhcXVlLXBhcnQiIHdoaWNoIGlz IHRoZSBkZWZpbml0aW9uIG9mIEFic29sdXRlVVJJIGluDQo+IDMyNjE/ICBZb3Ugd291bGQgd2Fu dCBtZSB0byBkZWZpbmUgc29tZXRoaW5nIHRoYXQgd2FzIGNsb3NlciB0byB3aGF0IGVhY2gNCj4g VVJJIHNjaGVtZSB1c2VzIGZvciB3aGF0IGNvbWVzIGFmdGVyIHRoZSBjb2xvbj8NCj4gDQo+IFNv IG1heWJlOg0KPiBsb2NhdGlvbi1wYXJhbSA9IExBUVVPVCBhbGxvd2VkLVVSSSBSQVFVT1QgKigg U0VNSSBsb2MtcGFyYW0gKQ0KPiA7Y2lkLXVybCBmcm9tIFJGQzIxMTENCj4gO2h0dHBfVVJMIGZy b20gUkZDMjYxNjsNCj4gO1NJUC9TSVBTLVVSSSBmcm9tIFJGQzMyNjENCj4gO1BSRVMtVVJJIGZy b20gUkZDMzg1OQ0KPiBhbGxvd2VkLVVSSSA9IGNpZC11cmkgLyBodHRwX1VSTCAvIGh0dHBzX1VS TCAvIFNJUC1VUkkgLyBTSVBTLVVSSQ0KPiAgICAgICAgICAgICAgIC8gUFJFUy1VUkkNCj4gDQo+ IA0KPiBBbXVzaW5nIHNpZGUgbm90ZSBvbiB0aGlzLiAgSSBkb24ndCBiZWxpZXZlIHRoZXJlIGlz IGFueSBhY3R1YWwgZGVmaW5pdGlvbg0KPiBvZiBhbiBodHRwc19VUkwuDQo+IA0KPiBCcmlhbg0K PiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFBhdWwgS3l6aXZh dCBbbWFpbHRvOnBreXppdmF0QGNpc2NvLmNvbV0NCj4gPiBTZW50OiBUaHVyc2RheSwgSnVseSAy MCwgMjAwNiA3OjI4IFBNDQo+ID4gVG86IEJyaWFuIFJvc2VuDQo+ID4gQ2M6ICdKZXJvZW4gVmFu IEJlbW1lbCc7ICdUaG9tc29uLCBNYXJ0aW4nOyBzaXBAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBS ZTogW1NpcF0gQWxsb3dpbmcgc2lwOiAob3IgcHJlejopIGluIHRoZSBsb2NhdGlvbiBoZWFkZXIN Cj4gPg0KPiA+IEJyaWFuLA0KPiA+DQo+ID4gSW4gZ2VuZXJhbCBJIGNvdWxkIGdvIHdpdGggZWl0 aGVyIGEgc3ludGFjdGljIG9yIHNlbWFudGljIGNvbnN0cmFpbnQuIEluDQo+ID4gZ2VuZXJhbCBJ IHRoaW5rIGEgc3ludGFjdGljIGNvbnN0cmFpbnQgaXMgcHJlZmVycmVkIGlmIGl0IGlzIHBvc3Np YmxlLA0KPiA+IGFuZCB0aGUgZmFsbGJhY2sgdG8gc2VtYW50aWMgY29uc3RyYWludCBjb21lcyB3 aGVuIHRoZSBjb25jZXB0IGNhbid0IGJlDQo+ID4gcmVwcmVzZW50ZWQgcHJlY2lzZWx5IGluIHRo ZSBzeW50YXgsIG9yIGlzIHRvbyBjdW1iZXJzb21lIHRvIGRvIGluDQo+ID4gcHJhY3RpY2UuDQo+ ID4NCj4gPiBCdXQgSSBhbSBjb25jZXJuZWQgd2l0aCBob3cgeW91IGhhdmUgdHJpZWQgdG8gZG8g dGhpcyBpbiBzeW50YXguIFdoYXQNCj4gPiB5b3UgaGF2ZSBlbmRlZCB1cCB3aXRoIGlzIGEgbG9v c2VyIGRlZmluaXRpb24gZm9yIGEgU0lQIFVSSSB0aGFuIGlzDQo+ID4gcHJlc2VudCBpbiAzMjYx LiBUaGF0IGF0IGxlYXN0ICJzbWVsbHMgYSBsaXR0bGUgZnVubnkiLg0KPiA+DQo+ID4gSWYgeW91 IHdhbnQgdG8gZG8gaXQgaW4gc3ludGF4LCB0aGVuIEkgdGhpbmsgeW91IHNob3VsZCBlbnVtZXJh dGUgdGhlDQo+ID4gc3ludGFjdGljIHR5cGUgb2YgZWFjaCBraW5kIG9mIFVSSSB5b3Ugd2FudCB0 byBwZXJtaXQuIFRoYXQgc3RpbGwgYWxsb3dzDQo+ID4gbmV3IG9uZXMgdG8gYmUgYWRkZWQsIGJ1 dCB0aGVuIGF0IGxlYXN0IGVhY2ggb25lIHdpbGwgYmUgcHJvcGVybHkNCj4gPiBjb25zdHJhaW5l ZC4NCj4gPg0KPiA+IAlQYXVsDQo+ID4NCj4gPiBCcmlhbiBSb3NlbiB3cm90ZToNCj4gPiA+IEpl cm9lbg0KPiA+ID4NCj4gPiA+IEkgZG9uJ3QgYWdyZWUgdGhhdCB0aGlzIGlzIGEgc2VtYW50aWMg aXNzdWU7IHdlIGFyZSByZXN0cmljdGluZw0KPiA+IHByZWNpc2VseQ0KPiA+ID4gd2hhdCBtYXkg YXBwZWFyIGluIGFsbG93ZWQtc2NoZW1lLiAgSSB1c3VhbGx5IHRoaW5rIGl0J3MgYmV0dGVyIHRv DQo+IGhhdmUNCj4gPiB0aGUNCj4gPiA+IEFCTkYgcHJlY2lzZSwgcmF0aGVyIHRoYW4gcmVseWlu ZyBvbiB0ZXh0IHRvIHN0YXRlIHdoYXQgaXMgYWN0dWFsbHkNCj4gPiA+IHBlcm1pdHRlZCBvbiB0 aGUgd2lyZS4gIFdlIGFyZSB0YWxraW5nIGFib3V0IHdoYXQgaXMgc3ludGFjdGljYWxseQ0KPiA+ IGFsbG93ZWQsDQo+ID4gPiBub3QgaG93IHlvdSBpbnRlcnByZXQgaXQuDQo+ID4gPg0KPiA+ID4g VGhlIEFCTkYgPS8gc3ludGF4IChmcm9tIFJGQzQyMzQpIGlzIGEgY29udmVuaWVudCB3YXkgdG8g YWRkIGEgc2NoZW1lDQo+IHRvDQo+ID4gdGhlDQo+ID4gPiBsaXN0LCBldmVuIHdoZW4gdXNlZCBi eSBpbmRlcGVuZGVudGx5IGNyZWF0ZWQgUkZDcy4NCj4gPiA+DQo+ID4gPiBJLCBsaWtlIEFuZHks IGRvbid0IGJlbGlldmUgdGhlIGRlY2lzaW9uIG9uIHdoaWNoIHByb3RvY29scyBjYW4gYXBwZWFy DQo+ID4gaW4NCj4gPiA+IGFsbG93ZWQtc2NoZW1lIGNhbiBiZSBsZWZ0IHRvIGltcGxlbWVudGF0 aW9uLiAgRXZlcnkgZGVyZWZlcmVuY2VyIGhhcw0KPiB0bw0KPiA+IGJlDQo+ID4gPiBwcmVwYXJl ZCB0byB1c2UgZXZlcnkgcG9zc2libGUgcHJvdG9jb2wsIGVzcGVjaWFsbHkgb24gdGhlIEludGVy bmV0LA0KPiA+IGJlY2F1c2UNCj4gPiA+IHRoZXJlIGlzIG5vIHdheSB0byBhc2sgZm9yIGEgc3Bl Y2lmaWMgVVJJIG9yIGxpbWl0IHRoZSBzY2hlbWVzIHRoZQ0KPiA+IGxvY2F0aW9uDQo+ID4gPiBh Y3F1aXNpdGlvbiBtZWNoYW5pc20gbWF5IG9idGFpbi4NCj4gPiA+DQo+ID4gPiBCcmlhbg0KPiA+ ID4NCj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206IEplcm9l biBWYW4gQmVtbWVsIFttYWlsdG86amJlbW1lbEB6b25uZXQubmxdDQo+ID4gPj4gU2VudDogVGh1 cnNkYXksIEp1bHkgMjAsIDIwMDYgMTowMyBQTQ0KPiA+ID4+IFRvOiBCcmlhbiBSb3NlbjsgJ1Ro b21zb24sIE1hcnRpbic7IHNpcEBpZXRmLm9yZw0KPiA+ID4+IFN1YmplY3Q6IFJFOiBbU2lwXSBB bGxvd2luZyBzaXA6IChvciBwcmV6OikgaW4gdGhlIGxvY2F0aW9uIGhlYWRlcg0KPiA+ID4+DQo+ ID4gPj4gQnJpYW4sDQo+ID4gPj4NCj4gPiA+PiBUbyBtZSB1c2luZyBBQk5GIHJ1bGVzIHRvIHJl c3RyaWN0IGFsbG93YWJsZSBzY2hlbWVzIGlzIG5vdCBhIGdvb2QNCj4gPiBpZGVhLg0KPiA+ID4+ IEFCTkYgZGVmaW5lcyBzeW50YXgsIG5vdCBzZW1hbnRpY3MNCj4gPiA+Pg0KPiA+ID4+IENvbXBh cmUgdGhpcyB3aXRoIHRoZSBSb3V0ZSBoZWFkZXIgaW4gU0lQLiBUaGUgQUJORiBhbGxvd3MgYW55 DQo+IHNjaGVtZSwNCj4gPiA+PiB0ZXh0IHNheXMgaXQgTVVTVCBiZSBzaXA6IG9yIHNpcHM6LiBU aGF0IHN1ZmZpY2VzICh5b3UgY291bGQgZGVmaW5lDQo+ID4gd2hpY2gNCj4gPiA+PiBlcnJvciBy ZXNwb25zZSBtdXN0IGJlIHNlbnQpDQo+ID4gPj4NCj4gPiA+PiBNb3Jlb3ZlciwgdGhlIHByb3Rv Y29sIHRvIHVzZSBpcyBhIHBvbGljeSBkZWNpc2lvbi4gWW91IGNhbiBtYWtlDQo+ID4gPj4gcmVj b21tZW5kYXRpb25zLCBldmVuIGRlZmluZSBuZXcgbWVjaGFuaXNtcywgYnV0IEkgdGhpbmsgdGhl IGNob2ljZQ0KPiA+IHNob3VsZA0KPiA+ID4+IGJlIGxlZnQgdG8gaW1wbGVtZW50b3JzDQo+ID4g Pj4NCj4gPiA+PiBSZWdhcmRzLA0KPiA+ID4+DQo+ID4gPj4gSmVyb2VuDQo+ID4gPj4gLS0tLS1P b3JzcHJvbmtlbGlqayBiZXJpY2h0IC0tLS0tDQo+ID4gPj4gVmFuOiAiQnJpYW4gUm9zZW4iIDxi ckBicmlhbnJvc2VuLm5ldD4NCj4gPiA+PiBBYW46ICInVGhvbXNvbiwgTWFydGluJyIgPE1hcnRp bi5UaG9tc29uQGFuZHJldy5jb20+OyBzaXBAaWV0Zi5vcmcNCj4gPiA+PiBWZXJ6b25kZW46IDIw LTctMDYgMTg6MTkNCj4gPiA+PiBPbmRlcndlcnA6IFJFOiBbU2lwXSBBbGxvd2luZyBzaXA6IChv ciBwcmV6OikgaW4gdGhlIGxvY2F0aW9uIGhlYWRlcg0KPiA+ID4+DQo+ID4gPj4gVGhlcmUgaXMg YSBwb2ludCB0byBsaW1pdGluZyB3aGF0IGNhbiBiZSBzZW50IGluIHRoZSBMb2NhdGlvbiBoZWFk ZXINCj4gdG8NCj4gPiA+PiBzcGVjaWZpYyBwcm90b2NvbHMgd2hpY2ggaGFzIHJlY2VpdmVkIGFk ZXF1YXRlIHJldmlldyBpbiBib3RoIHNpcCBhbmQNCj4gPiA+PiBnZW9wcml2Lg0KPiA+ID4+DQo+ ID4gPj4gU28sIGhlcmUgaXMgbXkgY29uY3JldGUgcHJvcG9zYWw6DQo+ID4gPj4gTG9jYXRpb24g ICAgICAgPSAiTG9jYXRpb24iIEhDT0xPTiBsb2NhdGlvbi1wYXJhbSAqKENPTU1BIGxvY2F0aW9u LQ0KPiA+IHBhcmFtKQ0KPiA+ID4+IGxvY2F0aW9uLXBhcmFtID0gTEFRVU9UIGFsbG93ZWQtc2No ZW1lIEhDT0xPTiAiOiIgKCBoaWVyLXBhcnQgLw0KPiBvcGFxdWUtDQo+ID4gPj4gcGFydA0KPiA+ ID4+ICkgUkFRVU9UICooIFNFTUkgbG9jLXBhcmFtICkgOyBoaWVyLXBhcnQgYW5kIG9wYXF1ZS1w YXJ0IGZyb20gMzI2MQ0KPiA+ID4+IGFsbG93ZWQtc2NoZW1lID0gJ2NpZCcgLyAnaHR0cCcgLyAn aHR0cHMnIC8gJ3NpcCcgLyAnc2lwcycgLyAncHJleicNCj4gPiA+PiBsb2MtcGFyYW0gICAgICA9 ICdsb2NhdGlvbi1kZXJlZmVyZW5jZS1wcm90b2NvbD0nIGRlcmVmLXByb3RvY29sIC8NCj4gPiA+ PiBnZW5lcmljLXBhcmFtDQo+ID4gPj4gZGVyZWYtcHJvdG9jb2wgPSB0b2tlbg0KPiA+ID4+DQo+ ID4gPj4gYWxsb3dlZC1zY2hlbWUgbWF5IGJlIGV4dGVuZGVkIGJ5IGEgc3RhbmRhcmRzLXRyYWNr IFJGQy4gIFN1Y2ggYW4NCj4gPiA+PiBleHRlbnNpb24NCj4gPiA+PiBpcyBOT1QgY29uc2lkZXJl ZCBhIFNJUCBleHRlbnNpb24gYW5kIGlzIE5PVCBzdWJqZWN0IHRvIHRoZSBwcm9jZXNzDQo+ID4g Pj4gZGVmaW5lZA0KPiA+ID4+IGJ5IFJGQzM0MjcuICBDb3JyZXNwb25kaW5nIHJlc29sdXRpb24g cHJvY2Vzc2VzIGZvciBzdWNoIHNjaGVtZXMgTVVTVA0KPiA+IGJlDQo+ID4gPj4gaW5jbHVkZWQg aW4gdGhlIFJGQywgYW5kIE1BWSBiZSBzdWJqZWN0IHRvIHJldmlldyBhZ2FpbnN0IFJGQzM2OTMu DQo+ID4gPj4NCj4gPiA+PiBUaGlzIGRvY3VtZW50IChpbiBTZWN0aW9uID8pIGRlZmluZXMgYSBu ZXcgSUFOQSByZWdpc3RyeSBmb3IgZGVyZWYtDQo+ID4gPj4gcHJvdG9jb2wsDQo+ID4gPj4gYW5k IHBvcHVsYXRlcyBpdCB3aXRoIG9uZSBpbml0aWFsIHZhbHVlLCAncmF3R0VUJy4gIHJhd0dFVCBp bmRpY2F0ZXMNCj4gPiB0aGF0DQo+ID4gPj4gdGhlIGxvY2F0aW9uIHJlZmVyZW5jZSBtYXkgYmUg ZGVyZWZlcmVuY2VkIGJ5IHNlbmRpbmcgYSBHRVQgd2l0aCBubw0KPiA+ID4+IHBhcmFtZXRlcnMg b24gdGhlIFVSSSwgdXNpbmcgSFRUUFMgKGV4Y2VwdCBpbiB0aGUgZW1lcmdlbmN5IGNhc2UsDQo+ IHdoZXJlDQo+ID4gPj4gSFRUUA0KPiA+ID4+IGlzIHBlcm1pdHRlZCksIGFuZCBleHBlY3RzIHRv IHJlY2VpdmUgb25lIFBJREYtTE8gZG9jdW1lbnQgKHdpdGggYQ0KPiA+IE1JTUUtDQo+ID4gPj4g dHlwZQ0KPiA+ID4+IG9mICJhcHBsaWNhdGlvbi9waWRmK3htbCIpaW4gcmVzcG9uc2UuICBkZXJl Zi1wcm90b2NvbCBNVVNUIGJlDQo+IGluY2x1ZGVkDQo+ID4gaWYNCj4gPiA+PiB0aGUgc2NoZW1l IGlzIEhUVFBTIChvciBIVFRQIGluIHRoZSBlbWVyZ2VuY3kgY2FzZSkuICBPdGhlciBzY2hlbWVz DQo+IG1heQ0KPiA+IG9yDQo+ID4gPj4gbWF5IG5vdCByZXF1aXJlIGRlcmVmLXByb3RvY29sLiAg QSBzdGFuZGFyZHMtdHJhY2sgUkZDIGlzIHJlcXVpcmVkIHRvDQo+ID4gYWRkDQo+ID4gPj4gYQ0K PiA+ID4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+ID4gU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2lwDQo+ID4gPiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9w bWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wNCj4gPiA+IFVzZSBzaXAtaW1wbGVtZW50b3Jz QGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwDQo+ID4gPiBVc2Ug c2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24g b2Ygc2lwDQo+ID4gPg0KPiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFu ZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2 YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5h bC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============1006216945== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1006216945==-- From sip-bounces@ietf.org Fri Jul 21 09:27:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3v0I-0006Fe-Qq; Fri, 21 Jul 2006 09:25:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3v0F-00069C-Kk for sip@ietf.org; Fri, 21 Jul 2006 09:25:15 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3unw-0008BW-Cb for sip@ietf.org; Fri, 21 Jul 2006 09:12:34 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6LDCUGL003146 for ; Fri, 21 Jul 2006 08:12:31 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 Jul 2006 08:12:30 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 Jul 2006 15:12:29 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Allowing sip: (or prez:) in the location header Date: Fri, 21 Jul 2006 15:12:28 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918013AD58@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Allowing sip: (or prez:) in the location header Thread-Index: AcasO3OmXlXjfodWTX+uckDAISG8WAAA/yagAANFnPAABA4REAAaT3qw From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 21 Jul 2006 13:12:29.0015 (UTC) FILETIME=[515CE670:01C6ACC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As individual) In this discussion it is probably worth remembering the endpoint we are trying to get to. There should be a limitation on the number of protocols specified because: - the consumer of the location header needs to support all the protocols indicated in order to fetch the location. In the case of emergency calls that must happen first time, i.e. without sending the 424 response code back to the UAC, and getting a new request containing a new location header with a new URI which we then might support. - GEOPRIV wants to maintain supervision of all GEOPRIV using protocols in order to ensure the privacy requirements are met, and remember, such privacy requirements are only overridable in certain jurisdictions for emergency call, not necessarily in all jurisdictions. Therefore any potential extension is going to need GEOPRIV WG decision. Therefore any extension to such a list is going to be "RFC required" or possibly even "standards track RFC required". Therefore both precise ABNF and RFC 2119 text can be updated by such an RFC, and we just need to decide which one presents the clearer requirement to the reader, both in its original form, and in any later potential updates RFC that modifies the location-conveyance RFC. Regards Keith =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 21 July 2006 01:43 > To: 'Thomson, Martin'; 'Jeroen van Bemmel'; 'Andrew Newton' > Cc: sip@ietf.org > Subject: RE: [Sip] Allowing sip: (or prez:) in the location header >=20 > We're dealing with a couple of issues here, so I'll take them=20 > one at a time. >=20 > There is precedent for ABNF precise, and precedent for text=20 > explanations. I can tell you from long experience that=20 > precise ABNF produces more interoperable implementations. =20 > We're forever correcting people that the ABNF is not=20 > definitive, and the text restricts what you can do. If the=20 > ABNF gets out of hand, then we often take short cuts using=20 > normative text. I'd prefer to avoid that. >=20 > I think it's inescapable that we are creating a precise list=20 > of protocols, and prohibiting that which is not explicitly=20 > allowed. I don't see you arguing against that, just how it's=20 > represented in the document. >=20 > Generally, I think the parameter and registry is a better=20 > solution than squandering the GET method for a no parameter=20 > resolution. It works, and it's not terrible, but I think=20 > explicitly stating the resolution protocol is much clearer. =20 > I have another thought on that whole subject, but that will=20 > wait for another email. >=20 > I think the text says "HTTPS must be used, except for the=20 > emergency case". > I don't think the draft needs to talk about HTTP headers for=20 > the simple GET case, which is all we allow. I think=20 > authentication and cipher suites must be covered for all TLS=20 > uses alike, so no sweat there. >=20 > Brian >=20 > > -----Original Message----- > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > Sent: Thursday, July 20, 2006 7:45 PM > > To: Brian Rosen; Jeroen van Bemmel; Andrew Newton > > Cc: sip@ietf.org > > Subject: RE: [Sip] Allowing sip: (or prez:) in the location header > >=20 > > No, I think that Jeroen has exactly the right idea. =20 > Restriction can=20 > > exist at two levels, and in this case, text is the correct=20 > place for=20 > > those choices. I don't like to argue from precedent, but=20 > there is a=20 > > clear precedent for this. > >=20 > > The issue of attaching additional parameters to a URI ("URI=20 > metadata")=20 > > is a good one, and permits the use of value-add protocols. =20 > But that=20 > > should not affect the basic specification, it can remain optional. > >=20 > > This can be very simply specified: If the https: URI exists=20 > a raw GET=20 > > MUST be possible. An https: URI is widely understood, and I don't=20 > > think that this behaviour is contradictory to any=20 > expectations. The=20 > > value-add protocols can be exercised by a POST, if the parameters=20 > > indicate a specific protocol is supported and the requester=20 > > understands the parameter and the protocol. A GET should=20 > still be possible regardless. > >=20 > > You don't need to create a registry for protocols right=20 > now; let those=20 > > protocol specifications (please, let there be only one)=20 > deal with that. > >=20 > > One problem with limiting as you have is that you have to be very=20 > > clear in how each of those protocols are used. Now, given Paul's=20 > > comments, I think that sip[s] and pres need a little more info - do=20 > > you want to include that as well? > >=20 > > Ultimately, I am arguing for a smaller location conveyance=20 > draft. The=20 > > problem with these discussions is that you can, effectively, refine=20 > > indefinitely. Do we start to discuss what authentication=20 > methods are=20 > > appropriate in the HTTP GET? What about HTTP headers? How we deal=20 > > with caching? TLS cipher-suites? I think that it's=20 > important to know=20 > > when to draw the line. > >=20 > > Regards, > > Martin > >=20 > > p.s... s/prez/pres/ > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, 21 July 2006 7:27 AM > > > To: 'Jeroen van Bemmel'; 'Andrew Newton' > > > Cc: Thomson, Martin; sip@ietf.org > > > Subject: RE: [Sip] Allowing sip: (or prez:) in the location header > > > > > > I don't think you have the big picture. > > > > > > Location comes from the access network, via some acquisition=20 > > > protocol, > > or > > > in > > > some cases, can be self generated in the endpoint. The=20 > access network > > > decides what the representation of the location is if=20 > it's supplying=20 > > > location, although it may give an endpoint some options > > (value/reference, > > > civic/geo). > > > > > > The UAC gets this location and puts it in the SIP message. > > > > > > Some entity, could be a proxy for location based routing, or the=20 > > > UAS, > > gets > > > the location and does something with it. > > > > > > For the sake of argument, assume its location-by-reference. > > > Call the proxy or UAS the "de-referencer". > > > > > > It's the access network (could be a broadband carrier, could be an > > > enterprise) that is putting up the server that provides the=20 > > > de-reference service. Call the server a "Location Information=20 > > > Server" =3D LIS > > > > > > Okay, so the access network chooses some protocol, makes up a=20 > > > suitable > > URI > > > and passes it via the acquisition protocol to the UAC. The UAC=20 > > > passes > > it > > > to > > > the de-referencer, who presents it to the LIS. The LIS responds=20 > > > with > > the > > > location value. > > > > > > The problem is that the de-referencer can't control which=20 > LIS, and=20 > > > can't control what protocol decision the LIS made. It has to=20 > > > implement EVERY ONE of the protocols that could appear in the=20 > > > Location header. If the LIS implements a protocol the=20 > de-referencer=20 > > > doesn't understand, the whole mechanism fails, with no=20 > recourse. On=20 > > > the Internet, which is where we want the protocols to work, you=20 > > > can't control which access network the UAC is coming from. > > > > > > So, instead, we restrict the list of allowed de-referencing=20 > > > protocols to > > a > > > small number, and make that list very explicit. Now a=20 > de-referencer > > knows > > > that if he implements ALL of the listed protocols, he=20 > will be able=20 > > > to dereference any location reference he gets. > > > > > > > > > > > > There is another big picture aspect. The whole location=20 > thing comes > > under > > > geopriv. We have to do a sip Location header in sip, but geopriv=20 > > > has to review our work. The "priv" part of geopriv is privacy. =20 > > > They care, a whole lot, about the privacy aspects of=20 > location. One=20 > > > expression of that concern is to have the security=20 > posture of "what=20 > > > is not explicitly permitted is prohibited". They really=20 > truly want=20 > > > to look at every IETF protocol that is used to de-reference=20 > > > location, and decide if it provides sufficient privacy protection=20 > > > for location. They really do want an explicit list, and=20 > they want=20 > > > to scrutinize every protocol on that list to see how it addresses=20 > > > their concerns. SIP is what geopriv calls a "using protocol" and=20 > > > they review them seriously. This means, for example, that it's=20 > > > probably not okay to use HTTP to de-reference. There is=20 > a specific,=20 > > > limited exemption for emergency calls on that. So HTTPS=20 > is a MUST,=20 > > > and HTTP is MUST NOT except for the emergency case. I=20 > believe that=20 > > > "AbsoluteURI" would not be acceptable to geopriv, but of course I=20 > > > can't speak for the group. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > > Sent: Thursday, July 20, 2006 4:31 PM > > > > To: Andrew Newton > > > > Cc: Brian Rosen; 'Thomson, Martin'; sip@ietf.org > > > > Subject: Re: [Sip] Allowing sip: (or prez:) in the=20 > location header > > > > > > > > Andrew, > > > > > > > > >> Moreover, the protocol to use is a policy decision. You can=20 > > > > >> make recommendations, even define new mechanisms,=20 > but I think=20 > > > > >> the choice should be left to implementors > > > > > > > > > > I disagree with this. What is my server gonna do=20 > with a mailto:=20 > > > > > or > > > dns: > > > > > URI? There should be a small list of acceptable=20 > choices if we=20 > > > > > want interoperability. > > > > > > > > In such a case your server should probably respond with "4xx=20 > > > > Location > > > URI > > > > Scheme not supported", where 4xx is TBD. However, if retrieving=20 > > > > the location is not critical to completing the call, then it=20 > > > > should probably ignore > > > the > > > > header. So there seems to be a need for a parameter indicating > > > "optional" > > > > versus "required" > > > > > > > > IMO the text in the draft should say: > > > > - proxies MUST support HTTP, SHOULD support HTTPS, MAY=20 > support cid > > (for > > > > dereferencing) > > > > - UAS MUST support HTTP and cid, SHOULD support HTTPS (for > > > dereferencing) > > > > - TBD: define whether and when proxy/UAS should=20 > generate error for=20 > > > > unsupported URI scheme (and then indicate which schemes are=20 > > > > supported) > > > > - UAC/Proxy SHOULD use HTTPS when adding Location by reference > > > > - UAC MAY use cid for location by value, but SHOULD then ensure=20 > > > > confidentiality > > > > > > > > But above all: the draft should specify what is=20 > minimally needed=20 > > > > to > > meet > > > > the > > > > stated requirements, while not unnecessarily=20 > restricting solutions > > that > > > > might have additional requirements which are not currently=20 > > > > foreseen > > > > > > > > Regards, > > > > > > > > jeroen > > > > >=20 > >=20 > ---------------------------------------------------------------------- > > ---- > > ---------------------- > > This message is for the designated recipient only and may contain=20 > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender=20 > immediately=20 > > and delete the original. Any unauthorized use of this email is=20 > > prohibited. > >=20 > ---------------------------------------------------------------------- > > ---- > > ---------------------- > > [mf2] >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 21 09:30:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3v3F-0001WX-Mu; Fri, 21 Jul 2006 09:28:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3v3D-0001WR-Sc for sip@ietf.org; Fri, 21 Jul 2006 09:28:19 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3v3C-0004ha-8t for sip@ietf.org; Fri, 21 Jul 2006 09:28:19 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 21 Jul 2006 06:28:17 -0700 X-IronPort-AV: i="4.07,167,1151910000"; d="scan'208"; a="1840553803:sNHT28489284" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6LDSHH7013012; Fri, 21 Jul 2006 06:28:17 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6LDSFHW002613; Fri, 21 Jul 2006 06:28:16 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 09:28:16 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 09:28:16 -0400 Message-ID: <44C0D66F.7010201@cisco.com> Date: Fri, 21 Jul 2006 09:28:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] Allowing sip: (or prez:) in the location header References: <045e01c6ac43$4b9a7d80$640fa8c0@cis.neustar.com> In-Reply-To: <045e01c6ac43$4b9a7d80$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2006 13:28:16.0137 (UTC) FILETIME=[85E43F90:01C6ACC9] DKIM-Signature: a=rsa-sha1; q=dns; l=5480; t=1153488497; x=1154352497; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Allowing=20sip=3A=20(or=20prez=3A)=20in=20the=20location =20header; X=v=3Dcisco.com=3B=20h=3DED6rJY2rneCveiROfpaiH3eGIOY=3D; b=o/4HE2ZvE1supJpusNctON483XkVxljuniCcldIc5fjsYdXKwY1fQjSMq/5ttWQkB4kdhEH+ yg7I4XqR8KVFHs0t0fSQKygvtfSWQtz6cJ83HMnPjHJFcWKRQKpWrZDp; Authentication-Results: sj-dkim-6.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: sip@ietf.org, "'Thomson, Martin'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Rosen wrote: > I don't think you have the big picture. Nice explanation. More below. > Location comes from the access network, via some acquisition protocol, or in > some cases, can be self generated in the endpoint. The access network > decides what the representation of the location is if it's supplying > location, although it may give an endpoint some options (value/reference, > civic/geo). > > The UAC gets this location and puts it in the SIP message. > > Some entity, could be a proxy for location based routing, or the UAS, gets > the location and does something with it. > > For the sake of argument, assume its location-by-reference. > Call the proxy or UAS the "de-referencer". > > It's the access network (could be a broadband carrier, could be an > enterprise) that is putting up the server that provides the de-reference > service. Call the server a "Location Information Server" = LIS > > Okay, so the access network chooses some protocol, makes up a suitable URI > and passes it via the acquisition protocol to the UAC. The UAC passes it to > the de-referencer, who presents it to the LIS. The LIS responds with the > location value. > > The problem is that the de-referencer can't control which LIS, and can't > control what protocol decision the LIS made. It has to implement EVERY ONE > of the protocols that could appear in the Location header. If the LIS > implements a protocol the de-referencer doesn't understand, the whole > mechanism fails, with no recourse. On the Internet, which is where we want > the protocols to work, you can't control which access network the UAC is > coming from. > > So, instead, we restrict the list of allowed de-referencing protocols to a > small number, and make that list very explicit. Now a de-referencer knows > that if he implements ALL of the listed protocols, he will be able to > dereference any location reference he gets. > > There is another big picture aspect. The whole location thing comes under > geopriv. We have to do a sip Location header in sip, but geopriv has to > review our work. The "priv" part of geopriv is privacy. They care, a whole > lot, about the privacy aspects of location. One expression of that concern > is to have the security posture of "what is not explicitly permitted is > prohibited". They really truly want to look at every IETF protocol that is > used to de-reference location, and decide if it provides sufficient privacy > protection for location. They really do want an explicit list, and they > want to scrutinize every protocol on that list to see how it addresses their > concerns. SIP is what geopriv calls a "using protocol" and they review them > seriously. This means, for example, that it's probably not okay to use HTTP > to de-reference. There is a specific, limited exemption for emergency calls > on that. So HTTPS is a MUST, and HTTP is MUST NOT except for the emergency > case. I believe that "AbsoluteURI" would not be acceptable to geopriv, but > of course I can't speak for the group. I fail to see how the exception could work in practice. How can the LIS know when it should accept an HTTP query and when it should not? What is to prevent somebody from changing an HTTPS URI to an HTTP URI and then dereferencing it? Paul > Brian > >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: Thursday, July 20, 2006 4:31 PM >> To: Andrew Newton >> Cc: Brian Rosen; 'Thomson, Martin'; sip@ietf.org >> Subject: Re: [Sip] Allowing sip: (or prez:) in the location header >> >> Andrew, >> >>>> Moreover, the protocol to use is a policy decision. You can make >>>> recommendations, even define new mechanisms, but I think the choice >>>> should be left to implementors >>> I disagree with this. What is my server gonna do with a mailto: or dns: >>> URI? There should be a small list of acceptable choices if we want >>> interoperability. >> In such a case your server should probably respond with "4xx Location URI >> Scheme not supported", where 4xx is TBD. However, if retrieving the >> location >> is not critical to completing the call, then it should probably ignore the >> header. So there seems to be a need for a parameter indicating "optional" >> versus "required" >> >> IMO the text in the draft should say: >> - proxies MUST support HTTP, SHOULD support HTTPS, MAY support cid (for >> dereferencing) >> - UAS MUST support HTTP and cid, SHOULD support HTTPS (for dereferencing) >> - TBD: define whether and when proxy/UAS should generate error for >> unsupported URI scheme (and then indicate which schemes are supported) >> - UAC/Proxy SHOULD use HTTPS when adding Location by reference >> - UAC MAY use cid for location by value, but SHOULD then ensure >> confidentiality >> >> But above all: the draft should specify what is minimally needed to meet >> the >> stated requirements, while not unnecessarily restricting solutions that >> might have additional requirements which are not currently foreseen >> >> Regards, >> >> jeroen > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 21 09:46:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vIk-0005aI-8d; Fri, 21 Jul 2006 09:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vIi-00058V-Sl for sip@ietf.org; Fri, 21 Jul 2006 09:44:20 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3vFs-0007qF-Cz for sip@ietf.org; Fri, 21 Jul 2006 09:41:27 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 735596E0002; Fri, 21 Jul 2006 15:41:23 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 15:41:22 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 15:41:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-outbound and STUN keepalives Date: Fri, 21 Jul 2006 15:41:21 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1266@esealmw113.eemea.ericsson.se> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C29099D@en0033exch001u.uk.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound and STUN keepalives Thread-Index: Acar9aD2HDzks15+QaOQUdyxn/eROwAMT+iQ From: "Christer Holmberg \(JO/LMF\)" To: "Drage, Keith \(Keith\)" , , "Rohan Mahy" X-OriginalArrivalTime: 21 Jul 2006 13:41:22.0310 (UTC) FILETIME=[5A7CBA60:01C6ACCB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Keith, I am ok with the proposal. In the "STUN keep-alive: Where to document it?" thread = (http://www1.ietf.org/mail-archive/web/sip/current/msg15227.html) it is = discussed where different things related to STUN keep-alive should be = documented. Some things MAY have to be documented in 3489bis. Regards, Christer =20 -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: 20. hein=E4kuuta 2006 15:11 To: 'sip@ietf.org' Subject: [Sip] draft-ietf-sip-outbound and STUN keepalives (As WG chair) Previous mails on the SIP list have expressed the view that the STUN = keepalive mechanism should be documented separately as it is a useful = mechanism in its own right. See http://www3.ietf.org/proceedings/06jul/slides/sip-5.pdf slide 5 for = the issue as raised at the IETF #66 meeting.=09 After discussion with the editor, the WG chairs propose the following: - that the documentation on STUN keepalive will REMAIN in the outbound = document, and WILL NOT be split to a separate specification; - that the STUN keepalive mechanism WILL BE separated within the = outbound specification, such that it is clear that it can be implemented = independently of the rest of the outbound specification, and so that the = keepalive material is clearly referencable in its own right. We believe that this meets the requirements of at least most of the = working group, and for pragmatic reasons we want to work against more = fragmentation of the SIP documentation. If you have problems with this proposal and desire a different solution, = then please raise your concerns to the list, or direct to the WG chairs, = in response to this mail. regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use = sip-implementors@cs.columbia.edu for questions on current sip Use = sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 21 10:44:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wDh-0007AT-0C; Fri, 21 Jul 2006 10:43:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wDf-0007AO-HO for sip@ietf.org; Fri, 21 Jul 2006 10:43:11 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3wDb-0001H0-1q for sip@ietf.org; Fri, 21 Jul 2006 10:43:11 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3wDO-0007I0-6j; Fri, 21 Jul 2006 09:42:54 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" Subject: RE: [Sip] Allowing sip: (or prez:) in the location header Date: Fri, 21 Jul 2006 10:42:51 -0400 Message-ID: <054301c6acd3$f3d669b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcasyYeZtGUHDi9+TjObg7gVE7/89wACQigw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44C0D66F.7010201@cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: sip@ietf.org, "'Thomson, Martin'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There are no protocol police. There is nothing to stop it from doing so. There is nothing to stop a server from not even implementing HTTPS. They seem to do it with sip TLS all the time. All we can do is write the spec the right way, and ask the implementers to please follow the spec. This observation is one reason why we want the reference itself to be protected in transit. Of course, mere possession of a location is not really useful. You need to be able to associate the location with some person (or thing). The reference, therefore, might want to be opaque, and you again want to protect the signaling that would show an observer the relationship between an identity and a location. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, July 21, 2006 9:28 AM > To: Brian Rosen > Cc: 'Jeroen van Bemmel'; 'Andrew Newton'; sip@ietf.org; 'Thomson, Martin' > Subject: Re: [Sip] Allowing sip: (or prez:) in the location header > > > > Brian Rosen wrote: > > I don't think you have the big picture. > > Nice explanation. More below. > > > Location comes from the access network, via some acquisition protocol, > or in > > some cases, can be self generated in the endpoint. The access network > > decides what the representation of the location is if it's supplying > > location, although it may give an endpoint some options > (value/reference, > > civic/geo). > > > > The UAC gets this location and puts it in the SIP message. > > > > Some entity, could be a proxy for location based routing, or the UAS, > gets > > the location and does something with it. > > > > For the sake of argument, assume its location-by-reference. > > Call the proxy or UAS the "de-referencer". > > > > It's the access network (could be a broadband carrier, could be an > > enterprise) that is putting up the server that provides the de-reference > > service. Call the server a "Location Information Server" = LIS > > > > Okay, so the access network chooses some protocol, makes up a suitable > URI > > and passes it via the acquisition protocol to the UAC. The UAC passes > it to > > the de-referencer, who presents it to the LIS. The LIS responds with > the > > location value. > > > > The problem is that the de-referencer can't control which LIS, and can't > > control what protocol decision the LIS made. It has to implement EVERY > ONE > > of the protocols that could appear in the Location header. If the LIS > > implements a protocol the de-referencer doesn't understand, the whole > > mechanism fails, with no recourse. On the Internet, which is where we > want > > the protocols to work, you can't control which access network the UAC is > > coming from. > > > > So, instead, we restrict the list of allowed de-referencing protocols to > a > > small number, and make that list very explicit. Now a de-referencer > knows > > that if he implements ALL of the listed protocols, he will be able to > > dereference any location reference he gets. > > > > There is another big picture aspect. The whole location thing comes > under > > geopriv. We have to do a sip Location header in sip, but geopriv has to > > review our work. The "priv" part of geopriv is privacy. They care, a > whole > > lot, about the privacy aspects of location. One expression of that > concern > > is to have the security posture of "what is not explicitly permitted is > > prohibited". They really truly want to look at every IETF protocol that > is > > used to de-reference location, and decide if it provides sufficient > privacy > > protection for location. They really do want an explicit list, and they > > want to scrutinize every protocol on that list to see how it addresses > their > > concerns. SIP is what geopriv calls a "using protocol" and they review > them > > seriously. This means, for example, that it's probably not okay to use > HTTP > > to de-reference. There is a specific, limited exemption for emergency > calls > > on that. So HTTPS is a MUST, and HTTP is MUST NOT except for the > emergency > > case. I believe that "AbsoluteURI" would not be acceptable to geopriv, > but > > of course I can't speak for the group. > > I fail to see how the exception could work in practice. How can the LIS > know when it should accept an HTTP query and when it should not? What is > to prevent somebody from changing an HTTPS URI to an HTTP URI and then > dereferencing it? > > Paul > > > Brian > > > >> -----Original Message----- > >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > >> Sent: Thursday, July 20, 2006 4:31 PM > >> To: Andrew Newton > >> Cc: Brian Rosen; 'Thomson, Martin'; sip@ietf.org > >> Subject: Re: [Sip] Allowing sip: (or prez:) in the location header > >> > >> Andrew, > >> > >>>> Moreover, the protocol to use is a policy decision. You can make > >>>> recommendations, even define new mechanisms, but I think the choice > >>>> should be left to implementors > >>> I disagree with this. What is my server gonna do with a mailto: or > dns: > >>> URI? There should be a small list of acceptable choices if we want > >>> interoperability. > >> In such a case your server should probably respond with "4xx Location > URI > >> Scheme not supported", where 4xx is TBD. However, if retrieving the > >> location > >> is not critical to completing the call, then it should probably ignore > the > >> header. So there seems to be a need for a parameter indicating > "optional" > >> versus "required" > >> > >> IMO the text in the draft should say: > >> - proxies MUST support HTTP, SHOULD support HTTPS, MAY support cid (for > >> dereferencing) > >> - UAS MUST support HTTP and cid, SHOULD support HTTPS (for > dereferencing) > >> - TBD: define whether and when proxy/UAS should generate error for > >> unsupported URI scheme (and then indicate which schemes are supported) > >> - UAC/Proxy SHOULD use HTTPS when adding Location by reference > >> - UAC MAY use cid for location by value, but SHOULD then ensure > >> confidentiality > >> > >> But above all: the draft should specify what is minimally needed to > meet > >> the > >> stated requirements, while not unnecessarily restricting solutions that > >> might have additional requirements which are not currently foreseen > >> > >> Regards, > >> > >> jeroen > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 21 13:12:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3yWE-0001AW-3M; Fri, 21 Jul 2006 13:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3yVg-0000NT-7q for sip@ietf.org; Fri, 21 Jul 2006 13:09:56 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3yLR-0006NC-BE for sip@ietf.org; Fri, 21 Jul 2006 12:59:23 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6LGxHv04930 for ; Fri, 21 Jul 2006 12:59:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-outbound and STUN keepalives Date: Fri, 21 Jul 2006 11:59:13 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0B9E2121@zrc2hxm0.corp.nortel.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C29099D@en0033exch001u.uk.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound and STUN keepalives Thread-Index: Acar9aV/GwqS+4NJTOWMcBthCQGjhwA8TEjQ From: "Francois Audet" To: "Drage, Keith \(Keith\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is perfect. In fact, I tought that this is what has been proposed all along: that=20 is certainly what I personally wanted.=20 FA> -----Original Message----- FA> From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 FA> Sent: Thursday, July 20, 2006 5:11 AM FA> To: 'sip@ietf.org' FA> Subject: [Sip] draft-ietf-sip-outbound and STUN keepalives FA>=20 FA> (As WG chair) FA>=20 FA> Previous mails on the SIP list have expressed the view that=20 FA> the STUN keepalive mechanism should be documented=20 FA> separately as it is a useful mechanism in its own right. FA>=20 FA> See http://www3.ietf.org/proceedings/06jul/slides/sip-5.pdf=20 FA> slide 5 for the issue as raised at the IETF #66 meeting.=09 FA>=20 FA> After discussion with the editor, the WG chairs propose the=20 FA> following: FA>=20 FA> - that the documentation on STUN keepalive will REMAIN in=20 FA> the outbound document, and WILL NOT be split to a separate=20 FA> specification; FA>=20 FA> - that the STUN keepalive mechanism WILL BE separated=20 FA> within the outbound specification, such that it is clear=20 FA> that it can be implemented independently of the rest of the=20 FA> outbound specification, and so that the keepalive material=20 FA> is clearly referencable in its own right. FA>=20 FA> We believe that this meets the requirements of at least=20 FA> most of the working group, and for pragmatic reasons we=20 FA> want to work against more fragmentation of the SIP documentation. FA>=20 FA> If you have problems with this proposal and desire a=20 FA> different solution, then please raise your concerns to the=20 FA> list, or direct to the WG chairs, in response to this mail. FA>=20 FA> regards FA>=20 FA> Keith FA>=20 FA> Keith Drage FA> drage@lucent.com FA> tel: +44 1793 776249 FA>=20 FA> _______________________________________________ FA> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip FA> This list is for NEW development of the core SIP Protocol=20 FA> Use sip-implementors@cs.columbia.edu for questions on=20 FA> current sip Use sipping@ietf.org for new developments on=20 FA> the application of sip FA>=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 21 14:21:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3zb0-00089W-F0; Fri, 21 Jul 2006 14:19:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3zaz-00089J-Fj for sip@ietf.org; Fri, 21 Jul 2006 14:19:29 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3zay-0001kC-2E for sip@ietf.org; Fri, 21 Jul 2006 14:19:29 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 21 Jul 2006 11:19:27 -0700 X-IronPort-AV: i="4.07,169,1151910000"; d="scan'208"; a="1840637657:sNHT26799248" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6LIJRgx005340; Fri, 21 Jul 2006 11:19:27 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6LIJPHW020315; Fri, 21 Jul 2006 11:19:26 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 14:19:25 -0400 Received: from [192.168.1.100] ([10.86.242.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 14:19:25 -0400 Message-ID: <44C11AAC.2010705@cisco.com> Date: Fri, 21 Jul 2006 14:19:24 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] draft-ietf-sip-outbound and STUN keepalives References: <5EB80D22825EEE42872083AD5BFFB594017F1266@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1266@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Jul 2006 18:19:25.0131 (UTC) FILETIME=[323931B0:01C6ACF2] DKIM-Signature: a=rsa-sha1; q=dns; l=3084; t=1153505967; x=1154369967; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-outbound=20and=20STUN=20keepalives; X=v=3Dcisco.com=3B=20h=3DOJDy4KgcZfWl9zbi6aWoKXDhiiw=3D; b=oKiQxkkzKkeWyWVzyksF86GkQxZnfIpEIKmcfuEFzDJBhg/kbaRuKsL6x50zGF+TwAunS+/A UjrOTsrTzkT6rKvuwcpO8n9hRlDcaNSQcUrOqM1sShjOg3EtBKf//xp7; Authentication-Results: sj-dkim-6.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip@ietf.org, Rohan Mahy , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Right. I mentioned this in the behave meeting. The idea is that rfc3489bis formally defines the usage, and calls out additional things that an actual protocol that uses it, would have to say. Then sip-outbound says those things. -Jonathan R. Christer Holmberg (JO/LMF) wrote: > Hi Keith, > > I am ok with the proposal. > > In the "STUN keep-alive: Where to document it?" thread (http://www1.ietf.org/mail-archive/web/sip/current/msg15227.html) it is discussed where different things related to STUN keep-alive should be documented. Some things MAY have to be documented in 3489bis. > > Regards, > > Christer > > > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 20. heinäkuuta 2006 15:11 > To: 'sip@ietf.org' > Subject: [Sip] draft-ietf-sip-outbound and STUN keepalives > > (As WG chair) > > Previous mails on the SIP list have expressed the view that the STUN keepalive mechanism should be documented separately as it is a useful mechanism in its own right. > > See http://www3.ietf.org/proceedings/06jul/slides/sip-5.pdf slide 5 for the issue as raised at the IETF #66 meeting. > > After discussion with the editor, the WG chairs propose the following: > > - that the documentation on STUN keepalive will REMAIN in the outbound document, and WILL NOT be split to a separate specification; > > - that the STUN keepalive mechanism WILL BE separated within the outbound specification, such that it is clear that it can be implemented independently of the rest of the outbound specification, and so that the keepalive material is clearly referencable in its own right. > > We believe that this meets the requirements of at least most of the working group, and for pragmatic reasons we want to work against more fragmentation of the SIP documentation. > > If you have problems with this proposal and desire a different solution, then please raise your concerns to the list, or direct to the WG chairs, in response to this mail. > > regards > > Keith > > Keith Drage > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 21 18:09:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G43A6-0002Ed-77; Fri, 21 Jul 2006 18:07:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G43A4-0002AD-65 for sip@ietf.org; Fri, 21 Jul 2006 18:07:56 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G43A2-0001G4-SX for sip@ietf.org; Fri, 21 Jul 2006 18:07:56 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 21 Jul 2006 15:07:54 -0700 X-IronPort-AV: i="4.07,170,1151910000"; d="scan'208"; a="1840710296:sNHT24402708" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6LM7stj018646; Fri, 21 Jul 2006 15:07:54 -0700 Received: from [192.168.0.105] (sjc-vpn2-575.cisco.com [10.21.114.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6LM6x7R003912; Fri, 21 Jul 2006 15:07:53 -0700 (PDT) In-Reply-To: <200607191917.k6JJHlx10382@smapp01.siteprotect.com> References: <200607191917.k6JJHlx10382@smapp01.siteprotect.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80F48847-9BC0-41DD-BCF9-E7D3A97636FF@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] SIP Security mechanism? Date: Fri, 21 Jul 2006 00:17:03 -0700 To: fwmiller@cornfed.com X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1307; t=1153519674; x=1154383674; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20SIP=20Security=20mechanism?; X=v=3Dcisco.com=3B=20h=3Damc0bTVpZ40OS+UQ5cge4zi44Os=3D; b=BrJyU6rKunNnGFbQ4XqLYEddiTObUd2CXR0iEmrXpyJ67ckOcuNMPlQ/4L0Q+1aiad7cxjk5 Zj2slBL3HIVUZI0tGEfd0FtM8uKRxtxADGn+4M7qWitIJRTOCzDJxlTc; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org you might want to have a read of draft-ietf-sipping-certs-04 if your goal is to make sure that users can find the keys of other users for use with S/MIME On Jul 19, 2006, at 12:17 PM, fwmiller@cornfed.com wrote: > > > I've been reading about the ZRTP lately. I read Henning's comment > at the IETF meeting about how S/MIME relies on the receiver's > public key to be available to allow for encryption/decryption to work. > > Why couldnt we put in place a mechanism that did a key exchange for > SIP signaling similar to whats done in ZRTP (i.e. modified Diffie- > Hellman) prior to any signaling traffic, then use the exchanged > keys as the basis for S/MIME encryption of the bodies? Or we could > even get really carried away and use it to do encryption of the > entire SIP message if the signaling did not traverse proxies? This > could be useful for encrypting UDP signaling, again if no proxy > were involved. > > Thoughts? > FM > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 21 22:00:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G46lG-0001MZ-Ot; Fri, 21 Jul 2006 21:58:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G46lF-0001MT-NW for sip@ietf.org; Fri, 21 Jul 2006 21:58:33 -0400 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G46lD-0001xU-97 for sip@ietf.org; Fri, 21 Jul 2006 21:58:33 -0400 Received: from dimension.cornfed.com (pool-141-157-85-154.balt.east.verizon.net [141.157.85.154]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k6M1wTu11205; Fri, 21 Jul 2006 20:58:29 -0500 Subject: Re: [Sip] SIP Security mechanism? From: "Frank W. Miller" To: Cullen Jennings In-Reply-To: <80F48847-9BC0-41DD-BCF9-E7D3A97636FF@cisco.com> References: <200607191917.k6JJHlx10382@smapp01.siteprotect.com> <80F48847-9BC0-41DD-BCF9-E7D3A97636FF@cisco.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Fri, 21 Jul 2006 21:58:20 -0400 Message-Id: <1153533500.2522.27.camel@dimension.cornfed.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for the pointer. I have scanned this draft over. The goal of your draft is similar to what I'm targeting but slightly different. Please correct me if I am misunderstanding something. The draft (which is now draft-ietf-sip-certs-01 I believe) has the goal is to provide a way to make the distribution of certificates more automated by providing specific infrastructure that is based on simple user actions. The draft specifies publication and an event package that allows for notification to interested User Agents of certificates. The great benefit to this approach is its preservation of user authentication. My thought was much simpler. Let me drop in a quote from the ZRTP draft, draft-zimmermann-avt-zrtp-01.txt: ZRTP is key agreement protocol which performs Diffie-Hellman key exchange during call setup in-band in the Real-time Transport Protocol (RTP) [1] media stream which has been established using some other signaling protocol such as Session Initiation Protocol (SIP) [11]. This generates a shared secret which is then used to generate keys and salt for a Secure RTP (SRTP) [2] session. Although it uses a public key algorithm, it does not rely on a public key infrastructure (PKI). Were we to put in place some sort of simple transaction that did this key exchange before any other signaling, we could use the keys to do encryption of the message bodies (similar to what S/MIME is doing) without having to deal with PKI at all. Since the main problem with the use of S/MIME to date has been the certificate management, this approach is also targeting the problem that your draft is. However, there are a couple of differences. First, your draft approach preserves full S/MIME certificate based authentication, this approach would likely not do that, it would be to allow for encryption only. The ZRTP draft proposes prompting the user with a short authentication string for the media but I don't know if that would be useful for the signaling. Second, this approach would be much simpler, likely requiring only a couple of messages between the UA endpoints. It would not require the centralized server elements that would be necessary for the PUBLISH/SUBSCRIBE/NOTIFY components of your draft. Consider the messages used to do key exchange in ZRTP (again from the ZRTP draft): Alice Bob | | | Alice and Bob establish a media session.| | | | RTP | |<=======================================>| | | | Hello (ver,cid,hash,cipher,pkt,sas,Alice's ZID) F1 |---------------------------------------->| | HelloACK F2 | |<----------------------------------------| | Hello (ver,cid,hash,cipher,pkt,sas,Bob's ZID) F3 |<----------------------------------------| | HelloACK F4 | |---------------------------------------->| | | | Bob acts as the initiator | | | | Commit (Bob's ZID,hash,cipher,pkt,hvi) F5 |<----------------------------------------| | DHPart1 (pvr,rs1IDr,rs2IDr,sigsIDr,srtpsIDr,other_secretIDr) F6 |---------------------------------------->| | DHPart2 (pvi,rs1IDi,rs2IDi,sigsIDi,ssrtpIDi,other_secretIDi) F7 |<----------------------------------------| | | | Alice and Bob generate SRTP session key.| | | | SRTP begins | |<=======================================>| | | | Confirm1 (plaintext,sasflag,hmac) F8 | |---------------------------------------->| | Confirm2 (plaintext,sasflag,hmac) F9 | |<----------------------------------------| | Confirm2AK F10 | |---------------------------------------->| They are generating keys for each of media streams here, i.e. an inband message exchange is happening in each direction. Something like this could probably be simplified to just two messages for the signaling, something like: Bob Alice | HELLO | |------------------------------->| | 200 OK | |<-------------------------------| | | This example uses a new method I made up called HELLO but I suppose this could be folded into the INVITE transaction too, using a mechanism similar to the 407. The key that Alice is supposed to use to encrypt the bodies sent to Bob would be in the HELLO and the key that Bob is supposed to use encrypt the bodies sent to Alice would be in the 200 OK. Is this clearer? Does it make sense? Its simpler but the authentication may not be there. That works for the media because you can possibly recognize someone's voice. In the signaling the authentication thing may be a bigger issue. FM On Fri, 2006-07-21 at 00:17 -0700, Cullen Jennings wrote: > you might want to have a read of draft-ietf-sipping-certs-04 if your > goal is to make sure that users can find the keys of other users for > use with S/MIME > > On Jul 19, 2006, at 12:17 PM, fwmiller@cornfed.com wrote: > > > > > > > I've been reading about the ZRTP lately. I read Henning's comment > > at the IETF meeting about how S/MIME relies on the receiver's > > public key to be available to allow for encryption/decryption to work. > > > > Why couldnt we put in place a mechanism that did a key exchange for > > SIP signaling similar to whats done in ZRTP (i.e. modified Diffie- > > Hellman) prior to any signaling traffic, then use the exchanged > > keys as the basis for S/MIME encryption of the bodies? Or we could > > even get really carried away and use it to do encryption of the > > entire SIP message if the signaling did not traverse proxies? This > > could be useful for encrypting UDP signaling, again if no proxy > > were involved. > > > > Thoughts? > > FM > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 21 23:34:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G48EW-00014H-UJ; Fri, 21 Jul 2006 23:32:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G48EV-000149-8X; Fri, 21 Jul 2006 23:32:51 -0400 Received: from mail.tieto.com ([194.110.47.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G48ET-0006rW-7A; Fri, 21 Jul 2006 23:32:51 -0400 Received: from camaro.eu.tieto.com ([192.176.143.43]) by mail.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Jul 2006 06:34:04 +0300 Received: from mail pickup service by camaro.eu.tieto.com with Microsoft SMTPSVC; Fri, 21 Jul 2006 16:42:34 +0200 Received: from viper.eu.tieto.com ([194.110.47.167]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 02:54:00 +0200 Received: from veyron.eu.tieto.com ([194.110.47.230]) by viper.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 03:54:00 +0300 Received: from ebb03.tieto.com ([194.142.141.100]) by veyron.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 03:54:00 +0300 Received: from megatron.ietf.org ([156.154.16.145]) by ebb03.tieto.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 03:54:00 +0300 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3jH7-00015I-I4; Thu, 20 Jul 2006 20:53:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3jH4-000123-Qi; Thu, 20 Jul 2006 20:53:51 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3jH3-0003TR-KY; Thu, 20 Jul 2006 20:53:50 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 20 Jul 2006 20:54:01 -0400 id 015880F1.44C025A9.0000778E In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6EC3E78C-FB29-4E95-B050-C95E26B99FED@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] RE: [Sip] Allowing sip: in location header not good Date: Thu, 20 Jul 2006 20:53:45 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 21 Jul 2006 00:54:00.0309 (UTC) FILETIME=[2750EA50:01C6AC60] X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org, geopriv@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 20, 2006, at 7:55 PM, Thomson, Martin wrote: > That is to say - the location conveyance document doesn't cover its > use, and nothing else does...yet. When someone does a using- > protocol specification for SUB/NOT, then we have a place to > describe how to use sip[s]: in the Location header. I guess we've all forgotten about RFC 4079. Here's the link: http://www.ietf.org/rfc/rfc4079.txt -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 23 19:24:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4nHA-0006BK-OP; Sun, 23 Jul 2006 19:22:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4nH9-0006BB-4E; Sun, 23 Jul 2006 19:22:19 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4nH6-0002Yj-Op; Sun, 23 Jul 2006 19:22:19 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Jul 2006 18:22:16 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sun, 23 Jul 2006 18:22:15 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Jul 2006 18:22:14 -0500 Message-ID: From: "Thomson, Martin" To: "Drage, Keith \(Keith\)" , "Andrew Newton" Date: Sun, 23 Jul 2006 18:21:32 -0500 Subject: RE: [Geopriv] RE: [Sip] Allowing sip: in location header not good MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 23 Jul 2006 23:22:14.0964 (UTC) FILETIME=[D51D2F40:01C6AEAE] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <5D1A7985295922448D5550C94DE2918013AD68@DEEXC1U01.de.lucent.com> Content-class: urn:content-classes:message Thread-Topic: [Geopriv] RE: [Sip] Allowing sip: in location header not good Thread-Index: AcasYCH7zQii9JgPQxqBeZnsYkQS3wAB4OAAABgpDfAAeW5x4A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: sip@ietf.org, geopriv@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1281105753==" Errors-To: sip-bounces@ietf.org --===============1281105753== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message UkZDIDQxMTk6IEEgUHJlc2VuY2UtYmFzZWQgR0VPUFJJViBMb2NhdGlvbiBPYmplY3QgRm9ybWF0 DQoNClRoZSB0aXRsZSBpbmRpY2F0ZXMgYW4gb2JqZWN0IGZvcm1hdC4gIFJGQyA0MTE5IGFkZHJl c3NlcyB0aGUgb2JqZWN0IGZvcm1hdCByZXF1aXJlbWVudHMgb2YgUkZDIDM2OTMgLSBJIHRlcm1z IG9mIGNsYWltcywgaXQgbWFrZXMgbm9uZSByZWxhdGVkIHRvIGEgdXNpbmcgcHJvdG9jb2wuDQoN ClNlY3Rpb25zIDMgYW5kIDQgYXJlIHRoZSBjbG9zZXN0IGl0IGdldHMgdG8gYSB1c2luZyBwcm90 b2NvbC4gIEluIHRoZXNlIHNlY3Rpb25zIGl0IG9ubHkgY292ZXJzIHJlcXVpcmVtZW50cyBmb3Ig dGhpcyBwYXJ0aWN1bGFyIG9iamVjdCBpbiByZWxhdGlvbiB0byBhIHVzaW5nIHByb3RvY29sLg0K DQpJIGRvbid0IGtub3cgaWYgdGhvc2UgUkZDcyBhcmUgZW5vdWdoIHRvIGNsYXNzaWZ5IGFzIGEg ZGVmaW5pdGl2ZSAidXNpbmcgcHJvdG9jb2wiLCBidXQgZXZpZGVudGx5IGl0IGlzIGZvciBzb21l IHBlb3BsZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRHJhZ2Us IEtlaXRoIChLZWl0aCkgW21haWx0bzpkcmFnZUBsdWNlbnQuY29tXQ0KPiBTZW50OiBGcmlkYXks IDIxIEp1bHkgMjAwNiAxMToyMiBQTQ0KPiBUbzogVGhvbXNvbiwgTWFydGluOyBBbmRyZXcgTmV3 dG9uDQo+IENjOiBzaXBAaWV0Zi5vcmc7IGdlb3ByaXZAaWV0Zi5vcmc7IEphbWVzIE0uIFBvbGsN Cj4gU3ViamVjdDogUkU6IFtHZW9wcml2XSBSRTogW1NpcF0gQWxsb3dpbmcgc2lwOiBpbiBsb2Nh dGlvbiBoZWFkZXIgbm90IGdvb2QNCj4gDQo+IEkgYWx3YXlzIHVuZGVyc3Rvb2QgdGhhdCBSRkMg NDExOSB3YXMgdGhlIHByZXNlbmNlIHVzaW5nIHByb3RvY29sDQo+IGRlZmluaXRpb24gZm9yIFJG QyA0MDc5IGFyY2hpdGVjdHVyZS4NCj4gDQo+IElmIHRoYXQgaXMgbm90IHRoZSBjYXNlIHRoZW4g d2UgaGF2ZSBhIGhvbGUgaW4gdGhlIFJGQ3MgZnJvbSBHRU9QUklWLA0KPiBiZWNhdXNlIG1hbnkg b3JnYW5pc2F0aW9ucyBhcmUgYWxyZWFkeSB1c2luZyBSRkMgNDExOSBpbiBwcmVzZW5jZSBiYXNl ZA0KPiBhcmNoaXRlY3R1cmVzLg0KPiANCj4gUmVnYXJkcw0KPiANCj4gS2VpdGgNCj4gDQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBUaG9tc29uLCBNYXJ0aW4gW21h aWx0bzpNYXJ0aW4uVGhvbXNvbkBhbmRyZXcuY29tXQ0KPiA+IFNlbnQ6IDIxIEp1bHkgMjAwNiAw Mjo1MQ0KPiA+IFRvOiBBbmRyZXcgTmV3dG9uDQo+ID4gQ2M6IHNpcEBpZXRmLm9yZzsgZ2VvcHJp dkBpZXRmLm9yZzsgSmFtZXMgTS4gUG9saw0KPiA+IFN1YmplY3Q6IFJFOiBbR2VvcHJpdl0gUkU6 IFtTaXBdIEFsbG93aW5nIHNpcDogaW4gbG9jYXRpb24NCj4gPiBoZWFkZXIgbm90IGdvb2QNCj4g Pg0KPiA+IFllcywgSSBoYWQgZm9yZ290dGVuLg0KPiA+DQo+ID4gVGhhdCBkb2N1bWVudCBpcyBp bmZvcm1hdGlvbmFsLCBzYXlpbmcgdGhhdCBsb2NhdGlvbiBpcw0KPiA+IHByZXNlbmNlLiAgV2hh dCBJIGhhdmVuJ3QgZ290dGVuIHlldCwgaXMgd2hldGhlciBvciBub3QgdGhpcw0KPiA+IGRvY3Vt ZW50IGNvbnNlcXVlbnRseSBpbXBsaWVzIHRoYXQgUkZDcyAzMjY1LzM4NTkvZXRjLi4uDQo+ID4g ZGVmaW5lIGEgdXNpbmcgcHJvdG9jb2wgdGhhdCBtZWV0cyBSRkMgMzY5MyByZXF1aXJlbWVudHMu DQo+ID4NCj4gPiBNDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g PiBGcm9tOiBBbmRyZXcgTmV3dG9uIFttYWlsdG86YW5keUBoeHIudXNdDQo+ID4gPiBTZW50OiBG cmlkYXksIDIxIEp1bHkgMjAwNiAxMDo1NCBBTQ0KPiA+ID4gVG86IFRob21zb24sIE1hcnRpbg0K PiA+ID4gQ2M6IEphbWVzIE0uIFBvbGs7IEJyaWFuIFJvc2VuOyBzaXBAaWV0Zi5vcmc7IGdlb3By aXZAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbR2VvcHJpdl0gUkU6IFtTaXBdIEFsbG93 aW5nIHNpcDogaW4gbG9jYXRpb24NCj4gPiBoZWFkZXIgbm90DQo+ID4gPiBnb29kDQo+ID4gPg0K PiA+ID4NCj4gPiA+IE9uIEp1bCAyMCwgMjAwNiwgYXQgNzo1NSBQTSwgVGhvbXNvbiwgTWFydGlu IHdyb3RlOg0KPiA+ID4gPiBUaGF0IGlzIHRvIHNheSAtIHRoZSBsb2NhdGlvbiBjb252ZXlhbmNl IGRvY3VtZW50IGRvZXNuJ3QNCj4gPiBjb3ZlciBpdHMNCj4gPiA+ID4gdXNlLCBhbmQgbm90aGlu ZyBlbHNlIGRvZXMuLi55ZXQuICBXaGVuIHNvbWVvbmUgZG9lcyBhIHVzaW5nLQ0KPiA+ID4gPiBw cm90b2NvbCBzcGVjaWZpY2F0aW9uIGZvciBTVUIvTk9ULCB0aGVuIHdlIGhhdmUgYSBwbGFjZQ0K PiA+IHRvIGRlc2NyaWJlDQo+ID4gPiA+IGhvdyB0byB1c2Ugc2lwW3NdOiBpbiB0aGUgTG9jYXRp b24gaGVhZGVyLg0KPiA+ID4NCj4gPiA+IEkgZ3Vlc3Mgd2UndmUgYWxsIGZvcmdvdHRlbiBhYm91 dCBSRkMgNDA3OS4gIEhlcmUncyB0aGUgbGluazoNCj4gPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv cmZjL3JmYzQwNzkudHh0DQo+ID4gPg0KPiA+ID4gLWFuZHkNCj4gPg0KPiA+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFRoaXMgbWVzc2FnZSBpcyBm b3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KPiA+IGNvbnRhaW4gcHJp dmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLg0K PiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXINCj4gPiBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1 dGhvcml6ZWQgdXNlIG9mDQo+ID4gdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KPiA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFttZjJdDQo+ID4N Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IFNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpcA0KPiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAg UHJvdG9jb2wNCj4gVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVz dGlvbnMgb24gY3VycmVudCBzaXANCj4gVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZl bG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcA0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQg cmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwg b3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVk IGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBk ZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwg aXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K W21mMl0= --===============1281105753== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1281105753==-- From sip-bounces@ietf.org Mon Jul 24 10:21:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G51H9-0007gF-KE; Mon, 24 Jul 2006 10:19:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G51H8-0007g9-Gb for Sip@ietf.org; Mon, 24 Jul 2006 10:19:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G51H8-0004f6-E9 for Sip@ietf.org; Mon, 24 Jul 2006 10:19:14 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G51H3-0000p6-Kt for Sip@ietf.org; Mon, 24 Jul 2006 10:19:14 -0400 Received: from bemail02.netfr.alcatel.fr (bemail02.netfr.alcatel.fr [155.132.251.36]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6OEJ62Y024635 for ; Mon, 24 Jul 2006 16:19:06 +0200 Received: from [138.203.251.40] ([138.203.251.40]) by bemail02.netfr.alcatel.fr (Lotus Domino Release 6.5.4FP2HF315) with ESMTP id 2006072416190469-10322 ; Mon, 24 Jul 2006 16:19:04 +0200 Message-ID: <44C4D6D8.7090907@alcatel.be> Date: Mon, 24 Jul 2006 16:19:04 +0200 From: olivier.ro.rousseau@alcatel.be Organization: Alcatel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sip@ietf.org X-MIMETrack: Itemize by SMTP Server on BEMAIL02/BE/ALCATEL(Release 6.5.4FP2HF315 | February 22, 2006) at 07/24/2006 16:19:04, Serialize by Router on BEMAIL02/BE/ALCATEL(Release 6.5.4FP2HF315 | February 22, 2006) at 07/24/2006 16:19:05, Serialize complete at 07/24/2006 16:19:05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: -2.6 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Sip] modification of a P-Asserted-Identity by a proxy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, I am designing a CNIP service in a proxy and I plan to remove the display name of the P-Asserted-Identity if the called party has not subscribed to the CNIP. But I am not sure if my proxy handling the services of the called party is allowed to perform this modification. I was reading the RFC3325 and I was wondering whether if in the case a proxy receives a P-Asserted-Identity from a trusted node and it forwards it to a trusted node if he is allowed to modify it. In the chapter 5 of the FRC, I do not see a mention that the proxy must copy the header transparently from one leg to the other in this case, so can I consider that this modification is allowed as it is not forbidden. Thanks is advance, Olivier _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 24 10:39:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G51Yp-0006XB-OX; Mon, 24 Jul 2006 10:37:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G51Yo-0006Wz-Fz for sip@ietf.org; Mon, 24 Jul 2006 10:37:30 -0400 Received: from mail.flextronicssoftware.com ([203.145.155.2] helo=delta.hss.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G51Ym-0007Vk-JO for sip@ietf.org; Mon, 24 Jul 2006 10:37:30 -0400 Received: from pragati.blr.hss.hns.com ([10.203.193.22]) by delta.hss.co.in (8.13.6/8.13.6) with ESMTP id k6OEbK2Z013066; Mon, 24 Jul 2006 20:07:21 +0530 To: sip-implementors@cs.columbia.edu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Kingston.Smiler@flextronicssoftware.com Date: Mon, 24 Jul 2006 20:08:13 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 30, 2005) at 07/24/2006 08:04:12 PM, Serialize complete at 07/24/2006 08:04:12 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org Subject: [Sip] Regarding non-INVITE server transaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1216890898==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1216890898== Content-Type: multipart/alternative; boundary="=_alternative 0050520F652571B5_=" This is a multipart message in MIME format. --=_alternative 0050520F652571B5_= Content-Type: text/plain; charset="US-ASCII" Hi, If the non-IST doesn't receive any RESPONSE message then what will happen? RFC 3261 (in Figure 8: non-INVITE server transaction ) doesn't mention properly what will happen if the non-IST doesn't receive any provisional response/final response. Regards, S.Kingston Smiler. *********************** FSS-Unclassified *********************** --=_alternative 0050520F652571B5_= Content-Type: text/html; charset="US-ASCII"

Hi,
       If the non-IST doesn't receive any RESPONSE message then what will happen?
RFC 3261 (in Figure 8: non-INVITE server transaction ) doesn't mention properly
what will happen if the  non-IST doesn't receive any provisional response/final response.
 
Regards,
S.Kingston Smiler.



***********************  FSS-Unclassified   *********************** --=_alternative 0050520F652571B5_=-- --===============1216890898== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1216890898==-- From sip-bounces@ietf.org Mon Jul 24 11:45:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G52aa-0003IU-T0; Mon, 24 Jul 2006 11:43:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ZMF-0004AA-Qs; Thu, 20 Jul 2006 10:18:31 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ZME-0003LE-Ki; Thu, 20 Jul 2006 10:18:31 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Jul 2006 10:18:30 -0400 X-IronPort-AV: i="4.07,163,1151899200"; d="scan'208"; a="93308249:sNHT29014980" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KEIUud010070; Thu, 20 Jul 2006 10:18:30 -0400 Received: from [68.48.124.145] (che-vpn-cluster-2-172.cisco.com [10.86.242.172]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6KEITdU000361; Thu, 20 Jul 2006 10:18:29 -0400 (EDT) In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C2909A1@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00C2909A1@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Date: Thu, 20 Jul 2006 10:18:33 -0400 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.624) DKIM-Signature: a=rsa-sha1; q=dns; l=454; t=1153405110; x=1154269110; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:John=20Schnizlein=20 |Subject:Re=3A=20[Geopriv]=20Location-by-value=20in=20a=20SIP=20Location=20Header |To:=22Drage,=20Keith=20(Keith)=22=20; X=v=3Dcisco.com=3B=20h=3DJ7Wm8sbspg7pVdY51VDlDreA3Z4=3D; b=NTAz4AOLwFk9ORzIyFvwzWVPwZdYilpjkv3BIllJqlgXuCWPtDvqz8uHnQXZY0DgXflBYHpx x7ZkHzSLz20HuQcFqCu4cFc96w/utj5wSofayI7qsHSC4mbaTDN3EvVR; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Mon, 24 Jul 2006 11:43:23 -0400 Cc: geopriv@ietf.org, sip@ietf.org Subject: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From where do you draw the idea that the WG agreed to location by reference? There were several individual submissions on this subject, none of which reached consensus to even include as a WG item, much less as a WG consensus in favor. John On Jul 20, 2006, at 9:24 AM, Drage, Keith (Keith) wrote: > In terms of previous WG agreements we have only two mechanisms: > - location by value in a body > - location by reference in a header _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 24 11:45:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G52ac-0003Ij-DG; Mon, 24 Jul 2006 11:43:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G40My-0006CI-CC; Fri, 21 Jul 2006 15:09:04 -0400 Received: from mail.tieto.com ([194.110.47.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G40Mv-0006RU-NV; Fri, 21 Jul 2006 15:09:04 -0400 Received: from viper.eu.tieto.com ([194.110.47.167]) by mail.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 22:10:13 +0300 Received: from mail pickup service by viper.eu.tieto.com with Microsoft SMTPSVC; Fri, 21 Jul 2006 22:08:55 +0300 Received: from camaro.eu.tieto.com ([192.176.143.43]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 02:14:43 +0200 Received: from ebb03.tieto.com ([194.142.141.100]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 01:53:47 +0200 Received: from megatron.ietf.org ([156.154.16.145]) by ebb03.tieto.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 02:53:47 +0300 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iKr-0008Sn-Gc; Thu, 20 Jul 2006 19:53:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iKp-0008Ri-I7; Thu, 20 Jul 2006 19:53:39 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3iDH-0005Q4-7U; Thu, 20 Jul 2006 19:45:54 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6KNjeoL029083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Jul 2006 16:45:41 -0700 Received: from [10.0.1.3] (vpn-10-50-16-128.qualcomm.com [10.50.16.128]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6KNjc7i000721; Thu, 20 Jul 2006 16:45:40 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4.3.2.7.2.20060720175701.036a4240@email.cisco.com> References: <4.3.2.7.2.20060720164240.033c6550@email.cisco.com> <4.3.2.7.2.20060720175701.036a4240@email.cisco.com> Date: Thu, 20 Jul 2006 16:45:37 -0700 To: "James M. Polk" , "Brian Rosen" , "'Thomson, Martin'" , , geopriv@ietf.org From: Ted Hardie Subject: [Geopriv] RE: [Sip] Allowing sip: in location header not good Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 20 Jul 2006 23:53:47.0793 (UTC) FILETIME=[BE16B810:01C6AC57] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Mon, 24 Jul 2006 11:43:23 -0400 Cc: X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 6:19 PM -0500 7/20/06, James M. Polk wrote: > >If the INVITE has a PIDF-LO with this element > > no > >Can a ESRP (emergency services routing proxy that does the LoST query for the PSAP URI) send location anywhere? Geopriv might say no, because it violates one of its "priv" rules. Now what? Do we make an exception? We have to get their buy-in for this. We don't have it yet. Do you mean "send onward in the SIP signaling path" or "send to the LoST server"? The problem here is that if the originating client has to allow all retransmission in order to get the call through, their privacy protection has gone to nil; in places where you have to be able to protect privacy during the emergency call, that's a problem. So just saying "it must be set to 'yes'" doesn't solve the problem. I think we really need to be able to distinguish between using the location to route the call and forwarding the target of the call forwarding the location; I believe that means we need to be able to break the first out of "retransmission-allowed" into a separate permission. My two cents, Ted _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 24 11:45:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G52ab-0003Ib-NS; Mon, 24 Jul 2006 11:43:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iKp-0008Ri-I7; Thu, 20 Jul 2006 19:53:39 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3iDH-0005Q4-7U; Thu, 20 Jul 2006 19:45:54 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6KNjeoL029083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Jul 2006 16:45:41 -0700 Received: from [10.0.1.3] (vpn-10-50-16-128.qualcomm.com [10.50.16.128]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6KNjc7i000721; Thu, 20 Jul 2006 16:45:40 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4.3.2.7.2.20060720175701.036a4240@email.cisco.com> References: <4.3.2.7.2.20060720164240.033c6550@email.cisco.com> <4.3.2.7.2.20060720175701.036a4240@email.cisco.com> Date: Thu, 20 Jul 2006 16:45:37 -0700 To: "James M. Polk" , "Brian Rosen" , "'Thomson, Martin'" , , geopriv@ietf.org From: Ted Hardie Subject: [Geopriv] RE: [Sip] Allowing sip: in location header not good Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Mon, 24 Jul 2006 11:43:23 -0400 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 6:19 PM -0500 7/20/06, James M. Polk wrote: > >If the INVITE has a PIDF-LO with this element > > no > >Can a ESRP (emergency services routing proxy that does the LoST query for the PSAP URI) send location anywhere? Geopriv might say no, because it violates one of its "priv" rules. Now what? Do we make an exception? We have to get their buy-in for this. We don't have it yet. Do you mean "send onward in the SIP signaling path" or "send to the LoST server"? The problem here is that if the originating client has to allow all retransmission in order to get the call through, their privacy protection has gone to nil; in places where you have to be able to protect privacy during the emergency call, that's a problem. So just saying "it must be set to 'yes'" doesn't solve the problem. I think we really need to be able to distinguish between using the location to route the call and forwarding the target of the call forwarding the location; I believe that means we need to be able to break the first out of "retransmission-allowed" into a separate permission. My two cents, Ted _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 24 14:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54kc-0002VU-Pd; Mon, 24 Jul 2006 14:01:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54ka-0002VA-Ut; Mon, 24 Jul 2006 14:01:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G53AK-0005gq-UA; Mon, 24 Jul 2006 12:20:20 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G52vG-0002ji-AT; Mon, 24 Jul 2006 12:04:49 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G52v4-0002hQ-Gz; Mon, 24 Jul 2006 11:04:36 -0500 From: "Brian Rosen" To: "'John Schnizlein'" , "'Drage, Keith \(Keith\)'" Subject: RE: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header Date: Mon, 24 Jul 2006 12:04:36 -0400 Message-ID: <08a601c6af3a$df643c50$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcavOCiNcGuAiFMhRuSAQYDA+gJAkwAAkBig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.5 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: geopriv@ietf.org, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, to be precise, Location by reference has been in the SIP Location header for a while, and no one has objected to that part of the text. It's not in any location acquisition protocol yet, although EVERY ONE of the L7 protocols has included it. I, personally, would prefer if the only location-by-reference was a presence subscription. I think we have to allow that. It would be nice if that was it; one mechanism is always better than many if you can get away with it. Brian > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Thursday, July 20, 2006 10:19 AM > To: Drage, Keith (Keith) > Cc: geopriv@ietf.org; sip@ietf.org > Subject: [Sip] Re: [Geopriv] Location-by-value in a SIP Location Header > > From where do you draw the idea that the WG agreed to location by > reference? There were several individual submissions on this subject, > none of which reached consensus to even include as a WG item, much less > as a WG consensus in favor. > > John > > On Jul 20, 2006, at 9:24 AM, Drage, Keith (Keith) wrote: > > > In terms of previous WG agreements we have only two mechanisms: > > - location by value in a body > > - location by reference in a header > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 24 16:36:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5783-0003FU-Vw; Mon, 24 Jul 2006 16:34:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5781-0003FM-Vi; Mon, 24 Jul 2006 16:34:13 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5780-0001US-LL; Mon, 24 Jul 2006 16:34:13 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k6OKY9sB020485; Mon, 24 Jul 2006 15:34:09 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Jul 2006 15:34:09 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Jul 2006 22:34:07 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 24 Jul 2006 22:34:06 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918013B316@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Location-by-value in a SIP Location Header Thread-Index: AcasB2YA1e/K/QM6SX2WIofwXFjhUQDV0Oiw From: "Drage, Keith \(Keith\)" To: "John Schnizlein" , "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 24 Jul 2006 20:34:07.0273 (UTC) FILETIME=[82CB7190:01C6AF60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: geopriv@ietf.org, sip@ietf.org Subject: [Sip] RE: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well all I can say is that it has been there from the draft-ietf-sip-location-conveyance-01 version (dated July 17th 2005) which was explicitly presented in the Paris IETF#63 SIP WG meeting in August 2005.=20 Unfortunately the minutes are not particularly helpful in terms of WG discussion at that time. The concept also had discussion on the SIP list at that time, with nobody proposing to take it out after it was added, although there was some call for more discussion of the various location provision capabilities. Regards Keith =20 > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com]=20 > Sent: 20 July 2006 15:19 > To: Drage, Keith (Keith) > Cc: geopriv@ietf.org; 'Hannes Tschofenig'; sip@ietf.org > Subject: Re: [Geopriv] Location-by-value in a SIP Location Header >=20 > From where do you draw the idea that the WG agreed to=20 > location by reference? There were several individual=20 > submissions on this subject, none of which reached consensus=20 > to even include as a WG item, much less as a WG consensus in favor. >=20 > John >=20 > On Jul 20, 2006, at 9:24 AM, Drage, Keith (Keith) wrote: >=20 > > In terms of previous WG agreements we have only two mechanisms: > > - location by value in a body > > - location by reference in a header >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 24 22:53:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5D1U-0004GJ-Ea; Mon, 24 Jul 2006 22:51:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5D1S-0004GD-FD for sip@ietf.org; Mon, 24 Jul 2006 22:51:50 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5D1R-0002eZ-6Z for sip@ietf.org; Mon, 24 Jul 2006 22:51:50 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 24 Jul 2006 19:51:49 -0700 X-IronPort-AV: i="4.07,177,1151910000"; d="scan'208"; a="307761503:sNHT25254984" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6P2pm9h001643; Mon, 24 Jul 2006 19:51:48 -0700 Received: from [192.168.0.105] (sjc-vpn2-798.cisco.com [10.21.115.30]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6P2pPHV007870; Mon, 24 Jul 2006 19:51:47 -0700 (PDT) In-Reply-To: <1152814344.2854.2.camel@localhost.localdomain> References: <1150495197.10237.51.camel@sukothai.pingtel.com> <1151955580.2892.102.camel@sukothai.pingtel.com> <44ADF4E9.5000305@cisco.com> <1152802404.2840.81.camel@localhost.localdomain> <3c17e6330e8571d304ba52b461a628d2@telio.no> <00da01c6a693$a0669ac0$31713b51@BEMBUSTER> <1152814344.2854.2.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Size of message/sipfrag in diagnostic responses Date: Sun, 23 Jul 2006 08:59:11 -0700 To: Scott Lawrence X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=685; t=1153795908; x=1154659908; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Size=20of=20message/sipfrag=20in=20diagnostic=20response s; X=v=3Dcisco.com=3B=20h=3DOEaNJ8UXsQyMuXYJO4I0JnSQkHU=3D; b=gyI8mHyyHLV4MO887XBNKqpr/33BXkYviaGIZ1jm6mjnXa52mJsmB5NMTUXYSUbIhhFiRZ0N x/o3oFFP37mCtn1JMm+rbb2HyCV77BAXooTXGxKGQGo1oTsO0fj1igz3; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 13, 2006, at 11:12 AM, Scott Lawrence wrote: >> gzip on the body might help too > > If I'm not mistaken, it's not trivial to figure out how much any given > text will compress with gzip unless you actually try each possibility. > I suspect you could use LZ77 (the gzip algo) in a streaming mode or select some other streaming compression technique to solve this so you add each header in order until it gets too big then use the previous result. However, I'm not arguing for this one way or the other - since this is meant to help humans debug, it seems like having it be easily human readable would be best. Cullen (with my individual hat on) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 05:00:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5IkY-0004wr-Py; Tue, 25 Jul 2006 04:58:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5IkW-0004wl-OS for sip@ietf.org; Tue, 25 Jul 2006 04:58:44 -0400 Received: from bugor.portaone.com ([65.61.200.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5IkV-0004L4-DZ for sip@ietf.org; Tue, 25 Jul 2006 04:58:44 -0400 Received: from bugor.portaone.com (localhost [127.0.0.1]) by bugor.portaone.com (8.13.4/8.13.4) with ESMTP id k6P8sbKB033517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 01:54:37 -0700 (PDT) (envelope-from netch@bugor.portaone.com) Received: (from netch@localhost) by bugor.portaone.com (8.13.4/8.13.4/Submit) id k6P8san9033516; Tue, 25 Jul 2006 01:54:36 -0700 (PDT) (envelope-from netch) Date: Tue, 25 Jul 2006 01:54:36 -0700 From: Valentin Nechayev To: Kingston.Smiler@flextronicssoftware.com Message-ID: <20060725085436.GA98614@portaone.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-42: On X-Virus-Scanned: ClamAV 0.88.2/1618/Mon Jul 24 18:12:40 2006 on bugor.portaone.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] Regarding non-INVITE server transaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: netch@portaone.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Mon, Jul 24, 2006 at 20:08:13, Kingston.Smiler wrote about "[Sip-implementors] Regarding non-INVITE server transaction": > If the non-IST doesn't receive any RESPONSE message then what will > happen? > RFC 3261 (in Figure 8: non-INVITE server transaction ) doesn't mention > properly > what will happen if the non-IST doesn't receive any provisional > response/final response. ==={{{ 8.1.3.1 Transaction Layer Errors In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code. ===}}} -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:netch@portaone.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 05:14:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5IyQ-0002ig-EL; Tue, 25 Jul 2006 05:13:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5IyO-0002ib-RB for sip@ietf.org; Tue, 25 Jul 2006 05:13:04 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5IyL-0007tE-JM for sip@ietf.org; Tue, 25 Jul 2006 05:13:04 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Y0037VCHPG2@szxga03-in.huawei.com> for sip@ietf.org; Tue, 25 Jul 2006 17:17:49 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Y00HYTCHP1U@szxga03-in.huawei.com> for sip@ietf.org; Tue, 25 Jul 2006 17:17:49 +0800 (CST) Received: from k19120I ([10.78.183.14]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2Y00EWGCKEW6@szxml04-in.huawei.com> for sip@ietf.org; Tue, 25 Jul 2006 17:19:26 +0800 (CST) Date: Tue, 25 Jul 2006 17:07:55 +0800 From: Manjunath Warad In-reply-to: <20060725085436.GA98614@portaone.com> To: netch@portaone.com, Kingston.Smiler@flextronicssoftware.com Message-id: <029e01c6afc9$d0bb4920$0eb74e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: [Sip] RE: [Sip-implementors] Regarding non-INVITE server transaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Below mentioned behaviour is for client transaction, not for server transaction. Rgds, Manju -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Valentin Nechayev Sent: Tuesday, July 25, 2006 4:55 PM To: Kingston.Smiler@flextronicssoftware.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Regarding non-INVITE server transaction Mon, Jul 24, 2006 at 20:08:13, Kingston.Smiler wrote about "[Sip-implementors] Regarding non-INVITE server transaction": > If the non-IST doesn't receive any RESPONSE message then what will > happen? > RFC 3261 (in Figure 8: non-INVITE server transaction ) doesn't mention > properly > what will happen if the non-IST doesn't receive any provisional > response/final response. ==={{{ 8.1.3.1 Transaction Layer Errors In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code. ===}}} -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:netch@portaone.com _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 08:55:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5MPo-0003LI-TM; Tue, 25 Jul 2006 08:53:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5MPn-0003K3-II for sip@ietf.org; Tue, 25 Jul 2006 08:53:35 -0400 Received: from mail.flextronicssoftware.com ([203.145.155.2] helo=delta.hss.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5MPk-0003eJ-Uk for sip@ietf.org; Tue, 25 Jul 2006 08:53:35 -0400 Received: from pragati.blr.hss.hns.com ([10.203.193.22]) by delta.hss.co.in (8.13.6/8.13.6) with ESMTP id k6PCnR2K004195; Tue, 25 Jul 2006 18:19:27 +0530 In-Reply-To: To: Stephen Zhou Subject: RE: [Sip] RE: [Sip-implementors] Regarding non-INVITE servertransaction MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Kingston.Smiler@flextronicssoftware.com Date: Tue, 25 Jul 2006 18:20:21 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 30, 2005) at 07/25/2006 06:16:24 PM, Serialize complete at 07/25/2006 06:16:24 PM X-Spam-Score: 1.0 (+) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0838811873==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0838811873== Content-Type: multipart/alternative; boundary="=_alternative 004671B6652571B6_=" This is a multipart message in MIME format. --=_alternative 004671B6652571B6_= Content-Type: text/plain; charset="US-ASCII" Hi, I agree with Stephen because it is not a problem in non - IST; This is generic to non-IST as well as IST. But consider a scenario like this UAC of UAS of UAS of UE2 UE1 proxy | | | | | non-INV | | non-INV | |--------------------->| |---------------------------->| | | | 2xx | | | | *<---------------| | | | | UAC of Proxy Here UAS of UE2 is re-transmitting the 2xx message toward proxy. But the message that has been sent by UAS of UE2 hasn't reached UAC of proxy (due to network breakage or some other means). So the proxy core (TU) doesn't send the response to UAS of proxy. In this case how will UAS txn of proxy can be released. Regards, S.Kingston Smiler. Stephen Zhou 07/25/2006 03:21 PM To "'Manjunath Warad'" , netch@portaone.com, Kingston Smiler/BLR/HSS@HSS cc sip@ietf.org, sip-implementors@cs.columbia.edu Subject RE: [Sip] RE: [Sip-implementors] Regarding non-INVITE servertransaction Hi, Manjunath is right. We MUST assume the communication between TU layer and transation lay in a sip stack is reliable. If there have problems, I thinks this is program problem rather than protocol(transaction layer) problem. Additionally, the same issue exist in IST, if the IST cann't receive the responses from TU. BR, Stephen -----Original Message----- From: Manjunath Warad [mailto:manjunathwarad@huawei.com] Sent: Tuesday, July 25, 2006 5:08 PM To: netch@portaone.com; Kingston.Smiler@flextronicssoftware.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip] RE: [Sip-implementors] Regarding non-INVITE server transaction Hi, Below mentioned behaviour is for client transaction, not for server transaction. Rgds, Manju -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Valentin Nechayev Sent: Tuesday, July 25, 2006 4:55 PM To: Kingston.Smiler@flextronicssoftware.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Regarding non-INVITE server transaction Mon, Jul 24, 2006 at 20:08:13, Kingston.Smiler wrote about "[Sip-implementors] Regarding non-INVITE server transaction": > If the non-IST doesn't receive any RESPONSE message then what will > happen? > RFC 3261 (in Figure 8: non-INVITE server transaction ) doesn't mention > properly > what will happen if the non-IST doesn't receive any provisional > response/final response. ==={{{ 8.1.3.1 Transaction Layer Errors In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code. ===}}} -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:netch@portaone.com _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip *********************** FSS-Unclassified *********************** --=_alternative 004671B6652571B6_= Content-Type: text/html; charset="US-ASCII"
Hi,
       I agree with Stephen because it is not a problem in non - IST;
This is generic to non-IST as well as IST.

But consider a scenario like this

UAC of        UAS of                     UAS of UE2
      UE1                 proxy                
 |                |      |                        |
 |         non-INV        |      |     non-INV                |
 |--------------------->|      |---------------------------->|
 |                |      |                2xx        |
 |                |      |                *<---------------|
 |                |      |                        |
                    UAC of
                                     Proxy
       

         Here UAS of UE2 is re-transmitting the 2xx message toward proxy.
But the message that has been sent by UAS of UE2 hasn't reached UAC of proxy
(due to network breakage or some other means). So the proxy core (TU) doesn't
send the response to UAS of proxy.  In this case how will UAS txn of proxy can be released.

Regards,
S.Kingston Smiler.


Stephen Zhou <zhouhong@huawei.com>

07/25/2006 03:21 PM

To
"'Manjunath Warad'" <manjunathwarad@huawei.com>, netch@portaone.com, Kingston Smiler/BLR/HSS@HSS
cc
sip@ietf.org, sip-implementors@cs.columbia.edu
Subject
RE: [Sip] RE: [Sip-implementors] Regarding non-INVITE         servertransaction





Hi,

Manjunath is right.

We MUST assume the communication between TU layer and transation lay in a
sip stack  is reliable. If there have problems, I thinks this is program
problem rather than protocol(transaction layer) problem.
Additionally, the same issue exist in IST, if the IST cann't receive the
responses from TU.

BR,
Stephen
-----Original Message-----
From: Manjunath Warad [mailto:manjunathwarad@huawei.com]
Sent: Tuesday, July 25, 2006 5:08 PM
To: netch@portaone.com; Kingston.Smiler@flextronicssoftware.com
Cc: sip@ietf.org; sip-implementors@cs.columbia.edu
Subject: [Sip] RE: [Sip-implementors] Regarding non-INVITE server
transaction

Hi,
                Below mentioned behaviour is for client transaction, not for
server transaction.

Rgds,
Manju

-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Valentin
Nechayev
Sent: Tuesday, July 25, 2006 4:55 PM
To: Kingston.Smiler@flextronicssoftware.com
Cc: sip@ietf.org; sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] Regarding non-INVITE server transaction

Mon, Jul 24, 2006 at 20:08:13, Kingston.Smiler wrote about
"[Sip-implementors] Regarding non-INVITE server transaction":

>         If the non-IST doesn't receive any RESPONSE message then what
will
> happen?
> RFC 3261 (in Figure 8: non-INVITE server transaction ) doesn't mention

> properly
> what will happen if the  non-IST doesn't receive any provisional
> response/final response.

==={{{
8.1.3.1 Transaction Layer Errors

  In some cases, the response returned by the transaction layer will
  not be a SIP message, but rather a transaction layer error.  When a
  timeout error is received from the transaction layer, it MUST be
  treated as if a 408 (Request Timeout) status code has been received.
  If a fatal transport error is reported by the transport layer
  (generally, due to fatal ICMP errors in UDP or connection failures in
  TCP), the condition MUST be treated as a 503 (Service Unavailable)
  status code.
===}}}

--
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:netch@portaone.com
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


***********************  FSS-Unclassified   *********************** --=_alternative 004671B6652571B6_=-- --===============0838811873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0838811873==-- From sip-bounces@ietf.org Tue Jul 25 09:29:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Mx9-0004pC-My; Tue, 25 Jul 2006 09:28:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Mx8-0004p4-0x for sip@ietf.org; Tue, 25 Jul 2006 09:28:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Jnn-00036l-Qu for sip@ietf.org; Tue, 25 Jul 2006 06:06:11 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5Jf5-0000F1-7Z for sip@ietf.org; Tue, 25 Jul 2006 05:57:13 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Y00F73EIC4K@szxga03-in.huawei.com> for sip@ietf.org; Tue, 25 Jul 2006 18:01:24 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Y00NDWEIC3H@szxga03-in.huawei.com> for sip@ietf.org; Tue, 25 Jul 2006 18:01:24 +0800 (CST) Received: from z53160 ([10.164.5.15]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2Y00E6HE6G9T@szxml03-in.huawei.com> for sip@ietf.org; Tue, 25 Jul 2006 17:54:19 +0800 (CST) Date: Tue, 25 Jul 2006 17:51:27 +0800 From: Stephen Zhou Subject: RE: [Sip] RE: [Sip-implementors] Regarding non-INVITE server transaction In-reply-to: <029e01c6afc9$d0bb4920$0eb74e0a@china.huawei.com> To: 'Manjunath Warad' , netch@portaone.com, Kingston.Smiler@flextronicssoftware.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcavysA7VUn7w+MeSE6ptqSK4R9JoAAAq/Ew X-Spam-Score: -2.6 (--) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Manjunath is right. We MUST assume the communication between TU layer and transation lay in a sip stack is reliable. If there have problems, I thinks this is program problem rather than protocol(transaction layer) problem. Additionally, the same issue exist in IST, if the IST cann't receive the responses from TU. BR, Stephen -----Original Message----- From: Manjunath Warad [mailto:manjunathwarad@huawei.com] Sent: Tuesday, July 25, 2006 5:08 PM To: netch@portaone.com; Kingston.Smiler@flextronicssoftware.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip] RE: [Sip-implementors] Regarding non-INVITE server transaction Hi, Below mentioned behaviour is for client transaction, not for server transaction. Rgds, Manju -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Valentin Nechayev Sent: Tuesday, July 25, 2006 4:55 PM To: Kingston.Smiler@flextronicssoftware.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Regarding non-INVITE server transaction Mon, Jul 24, 2006 at 20:08:13, Kingston.Smiler wrote about "[Sip-implementors] Regarding non-INVITE server transaction": > If the non-IST doesn't receive any RESPONSE message then what will > happen? > RFC 3261 (in Figure 8: non-INVITE server transaction ) doesn't mention > properly > what will happen if the non-IST doesn't receive any provisional > response/final response. ==={{{ 8.1.3.1 Transaction Layer Errors In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code. ===}}} -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:netch@portaone.com _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 13:43:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Quj-00069z-PI; Tue, 25 Jul 2006 13:41:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Quh-00066F-Ip for sip@ietf.org; Tue, 25 Jul 2006 13:41:47 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Qug-000487-8l for sip@ietf.org; Tue, 25 Jul 2006 13:41:47 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G5QuY-0003Uz-Vs for sip@ietf.org; Tue, 25 Jul 2006 12:41:39 -0500 From: "Brian Rosen" To: Date: Tue, 25 Jul 2006 13:41:42 -0400 Message-ID: <013501c6b011$98b8d360$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawERldoiEvROTuT2KasGKrfOW37QAAHIzg X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Sip] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have put out a number of emails on proposed changes to location conveyance. Some of them have sparked a number of comments. My summary of consensus on these issues is: 1. We proposed to explicitly disallow use of a Data URI, which would allow specification of a Location-by-value in a header. There was a lot of list traffic on this, currently in the state where Keith asked for a real use case for it. So far, we don't see a use case that cannot be provided by location-by-reference in a header. If we don't get a good use case, I think consensus is to disallow location-by-value in a header. 2. Dereferencing location-by-reference. We had initially proposed to document a process to use a raw HTTP(S) Get to dereference. There was a lot of discussion, and then I made a new proposal, see item 6. 3. We proposed to allow a Reason header with a 424 Bad Location response. This seems to be acceptable to the WG. Geopriv will create and populate the registry in a separate draft. 4. We proposed to explicitly allow hop-by-hop TLS security for location when the endpoint wished to allow routing based on location. We further proposed to interpret "Do not Distribute" flags as allowing sending of the location to the routing database (LoST for example). Hannes pointed out that there was a proposal to allow two Location headers, one of which could be used for routing and another for onward forwarding to the recipient. Hannes' message seemed to agree that "Do not distribute" would allow sending of the location to the routing-by-location database, but would obligate the proxy that did that to remove the location before it forwarded the message. There were no other messages on this thread. We conclude that allowing hop-by-hop security for location based routing is acceptable, and Do Not Distribute DOES allow forwarding to a routing database, but requires that the proxy doing the location based route to remove the location it uses for that purpose. 5. We proposed to create a parameter and a registry to distinguish multiple ways to dereference a location where HTTP(S) was the transport. Resolution of this issue depends on resolution of issue 6. 6. We proposed to allow sip/sips and pres: in the location header. I later speculated that if we allow this, it forms a simple way to do location-by-reference, and we could eliminate the raw HTTP(S) Get proposal, with the parameter and registry entirely. There was some list traffic in favor of this. Martin Thompson is skeptical that SIP Presence Subscribe/Notify is actually allowed as a geopriv "using protocol". Several of think that it is. If we don't get any more comments on this proposal, we will allow sip/sips and pres, not have any http(s) resolution text, and not propose a parameter and accompanying registry. If this does not reflect your position, please speak up now. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 13:57:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5R85-0002Uz-6V; Tue, 25 Jul 2006 13:55:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5R84-0002Ss-4T for sip@ietf.org; Tue, 25 Jul 2006 13:55:36 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5R81-0006lU-Qu for sip@ietf.org; Tue, 25 Jul 2006 13:55:36 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2006 10:55:33 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,180,1151910000"; d="scan'208"; a="33319828:sNHT24228312" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PHtWK4006959 for ; Tue, 25 Jul 2006 13:55:32 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6PHtWdU029700 for ; Tue, 25 Jul 2006 13:55:32 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 13:55:32 -0400 Received: from [192.168.1.100] ([10.86.242.175]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 13:55:32 -0400 Message-ID: <44C65B13.5040803@cisco.com> Date: Tue, 25 Jul 2006 13:55:31 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2006 17:55:32.0638 (UTC) FILETIME=[860B1BE0:01C6B013] DKIM-Signature: a=rsa-sha1; q=dns; l=1289; t=1153850132; x=1154714132; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Hitchhikers=20guide=20-=20when=20is=20it=20done? |To:IETF=20SIP=20List=20; X=v=3Dcisco.com=3B=20h=3D0vgTzIrDzitxD8mqF7D8kDeKUGY=3D; b=Wj0uuOkJSpfXkU/EQoKPIzZXWc5NWblz/vCGQ+9Yrn+9CE4CNK+bVVLHDiBGvRlONixXP1Q9 PrufhD3OZlT8dSAboIgflzF2UB3wfaVLfROhJ/dcEZuClk+qK90oWVZR; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Sip] Hitchhikers guide - when is it done? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org During the IETF meeting, I discussed the one current open issue in the Hitchhikers guide. The issue is: when does the document finish? When do we send to IESG to issue an RFC? There were two approaches: 1. split the document in two. One part contains only the core specs, and issues relatively soon. The other part has everything else, and basically ends up being the last RFC produced by the SIP WG before it shuts its doors (which has always been 1.5 years from now for the last 5 years). 2. keep it as one document. Issue an RFC at some point, and then revise it a few times as needed. We need to decide when to issue it. I'd like to propose option 2. I think people get more value from it as a consolidated document. Furthermore, I'd propose that we send the document to IESG for consideration as informational at the instant all of the documents listed as 'core' have RFC numbers issued by RFC-ed. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 14:00:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RBC-00042v-O9; Tue, 25 Jul 2006 13:58:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G52fj-0006qe-0h for sip@ietf.org; Mon, 24 Jul 2006 11:48:43 -0400 Received: from web61114.mail.yahoo.com ([209.73.179.43]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G52fg-0000J0-K3 for sip@ietf.org; Mon, 24 Jul 2006 11:48:42 -0400 Received: (qmail 28597 invoked by uid 60001); 24 Jul 2006 15:48:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PMvuaoL4zJpJbcejLY67WTtCvn/U73vPo5T2eb/QVk8o2CiJeeho8PfTMkWuUZLDWpb4xwcw4nT8OMUegKik7ioy2LE0ImpucBZBJaRCrwOWHe4gr1Pwen14IGZSujrr7YF74XabzkjD8xYFO6j4d95TDhJ5ezYse4bDiPHJN9E= ; Message-ID: <20060724154840.28595.qmail@web61114.mail.yahoo.com> Received: from [65.119.52.228] by web61114.mail.yahoo.com via HTTP; Mon, 24 Jul 2006 08:48:37 PDT Date: Mon, 24 Jul 2006 08:48:37 -0700 (PDT) From: Somesh S Shanbhag To: Kingston.Smiler@flextronicssoftware.com, sip-implementors@cs.columbia.edu In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-Mailman-Approved-At: Tue, 25 Jul 2006 13:58:49 -0400 Cc: sip@ietf.org Subject: [Sip] Re: [Sip-implementors] Regarding non-INVITE server transaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: someshss@yahoo.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0128636132==" Errors-To: sip-bounces@ietf.org --===============0128636132== Content-Type: multipart/alternative; boundary="0-1329810658-1153756117=:21165" Content-Transfer-Encoding: 8bit --0-1329810658-1153756117=:21165 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Kingston, RFC 3261 section 8.2.6.1 suggests the following ... One largely non-method-specific guideline for the generation of responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response to a non-INVITE request as soon as possible. When a 100 (Trying) response is generated, any Timestamp header field present in the request MUST be copied into this 100 (Trying) response. If there is a delay in generating the response, the UAS SHOULD add a delay value into the Timestamp value in the response. This value MUST contain the difference between the time of sending of the response and receipt of the request, measured in seconds. So, Its expected that the UAS respond to non-INVITE requests immediately with preferably a final response and not a provisional response... So, I think if the case that you have mentioned takes place I think Transaction User (TU) must take care and Transaction Layer shall remain un-noticed .... Thanks & Regards, Somesh S. Shanbhag Kingston.Smiler@flextronicssoftware.com wrote: Hi, If the non-IST doesn't receive any RESPONSE message then what will happen? RFC 3261 (in Figure 8: non-INVITE server transaction ) doesn't mention properly what will happen if the non-IST doesn't receive any provisional response/final response. Regards, S.Kingston Smiler. *********************** FSS-Unclassified *********************** _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ----------------------------------------- SIMPLICITY IS THE BEAUTY. BE NATURAL LIVE NATURAL. ----------------------------------------- Somesh S. Shanbhag Focus Area - VoIP Team (FA-VoIP) Mascon Global Limited #59/2, 100Ft Ring Road Banashankari II stage Bangalore-560070 Karnataka INDIA Website: http://www.mgl.com/ ----------------------------------------- --------------------------------- Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. --0-1329810658-1153756117=:21165 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Kingston,

RFC 3261 section 8.2.6.1 suggests the following ...

   One largely non-method-specific guideline for the generation of
   responses is that UASs SHOULD NOT issue a provisional response for a
   non-INVITE request.  Rather, UASs SHOULD generate a final response to
   a non-INVITE request as soon as possible.

   When a 100 (Trying) response is generated, any Timestamp header field
   present in the request MUST be copied into this 100 (Trying)
   response.  If there is a delay in generating the response, the UAS
   SHOULD add a delay value into the Timestamp value in the response.
   This value MUST contain the difference between the time of sending of
   the response and receipt of the request, measured in seconds.

So, Its expected that the UAS respond to non-INVITE requests
immediately with preferably a final response and not a
provisional response...

So, I think if the case that you
 have mentioned takes place I think
Transaction User (TU) must take care and Transaction Layer
shall remain un-noticed ....

Thanks & Regards,
Somesh S. Shanbhag

Kingston.Smiler@flextronicssoftware.com wrote:
Hi,
If the non-IST doesn't receive any RESPONSE message then what will
happen?
RFC 3261 (in Figure 8: non-INVITE server transaction ) doesn't mention
properly
what will happen if the non-IST doesn't receive any provisional
response/final response.

Regards,
S.Kingston Smiler.



*********************** FSS-Unclassified ***********************
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors



-----------------------------------------
SIMPLICITY IS THE BEAUTY.
BE NATURAL LIVE NATURAL.
-----------------------------------------
Somesh S. Shanbhag
Focus Area - VoIP Team (FA-VoIP)
Mascon Global Limited
#59/2, 100Ft Ring Road
Banashankari II stage
Bangalore-560070
Karnataka
INDIA
Website: http://www.mgl.com/
-----------------------------------------

Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta. --0-1329810658-1153756117=:21165-- --===============0128636132== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0128636132==-- From sip-bounces@ietf.org Tue Jul 25 14:07:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RIH-0006n4-KA; Tue, 25 Jul 2006 14:06:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RIG-0006mz-4V for sip@ietf.org; Tue, 25 Jul 2006 14:06:08 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5RIE-0000Zb-Pf for sip@ietf.org; Tue, 25 Jul 2006 14:06:08 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G5RI1-00059y-DQ; Tue, 25 Jul 2006 13:05:53 -0500 From: "Brian Rosen" To: "'Jonathan Rosenberg'" , "'IETF SIP List'" Subject: RE: [Sip] Hitchhikers guide - when is it done? Date: Tue, 25 Jul 2006 14:05:56 -0400 Message-ID: <014401c6b014$fbb97e30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawE8ahnXfPsVxNQqG9FuQnc4Cw0QAAHq5g In-Reply-To: <44C65B13.5040803@cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I like it, but I want to know why you want to wait until you have core RFC numbers. Whenever you put it in, you will block on normative references. SIP will be guaranteed to move on before it issues. You have to decide if you try to edit it as that happens (AUTH48) or not. I'd submit it when it's done, and not wait. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Tuesday, July 25, 2006 1:56 PM > To: IETF SIP List > Subject: [Sip] Hitchhikers guide - when is it done? > > During the IETF meeting, I discussed the one current open issue in the > Hitchhikers guide. The issue is: when does the document finish? When do > we send to IESG to issue an RFC? > > There were two approaches: > > 1. split the document in two. One part contains only the core specs, and > issues relatively soon. The other part has everything else, and > basically ends up being the last RFC produced by the SIP WG before it > shuts its doors (which has always been 1.5 years from now for the last 5 > years). > > 2. keep it as one document. Issue an RFC at some point, and then revise > it a few times as needed. We need to decide when to issue it. > > > I'd like to propose option 2. I think people get more value from it as a > consolidated document. Furthermore, I'd propose that we send the > document to IESG for consideration as informational at the instant all > of the documents listed as 'core' have RFC numbers issued by RFC-ed. > > Comments? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 14:08:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RJK-0007Lz-Jg; Tue, 25 Jul 2006 14:07:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RJJ-0007KE-9D for sip@ietf.org; Tue, 25 Jul 2006 14:07:13 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5RJG-0000ic-U7 for sip@ietf.org; Tue, 25 Jul 2006 14:07:13 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k6PI71mZ024473; Tue, 25 Jul 2006 13:07:06 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Jul 2006 13:07:05 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Jul 2006 20:07:03 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Hitchhikers guide - when is it done? Date: Tue, 25 Jul 2006 20:07:02 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918013B758@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Hitchhikers guide - when is it done? Thread-Index: AcawE68tojfok2+SRh+EhwiVDfcbugAAUwKQ From: "Drage, Keith \(Keith\)" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 25 Jul 2006 18:07:03.0896 (UTC) FILETIME=[2210B580:01C6B015] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As individual) I also prefer option 2. I think the IETF has to solve the problem of more rapid revision of documents. Regards Keith=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: 25 July 2006 18:56 > To: IETF SIP List > Subject: [Sip] Hitchhikers guide - when is it done? >=20 > During the IETF meeting, I discussed the one current open=20 > issue in the Hitchhikers guide. The issue is: when does the=20 > document finish? When do we send to IESG to issue an RFC? >=20 > There were two approaches: >=20 > 1. split the document in two. One part contains only the core=20 > specs, and issues relatively soon. The other part has=20 > everything else, and basically ends up being the last RFC=20 > produced by the SIP WG before it shuts its doors (which has=20 > always been 1.5 years from now for the last 5 years). >=20 > 2. keep it as one document. Issue an RFC at some point, and=20 > then revise it a few times as needed. We need to decide when=20 > to issue it. >=20 >=20 > I'd like to propose option 2. I think people get more value=20 > from it as a=20 > consolidated document. Furthermore, I'd propose that we send the=20 > document to IESG for consideration as informational at the=20 > instant all=20 > of the documents listed as 'core' have RFC numbers issued by RFC-ed. >=20 > Comments? >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 14:15:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RPg-0001wk-1j; Tue, 25 Jul 2006 14:13:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RPe-0001u0-QL for sip@ietf.org; Tue, 25 Jul 2006 14:13:46 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5RPc-0001VN-Ac for sip@ietf.org; Tue, 25 Jul 2006 14:13:46 -0400 Received: (qmail 30353 invoked by uid 0); 25 Jul 2006 18:13:42 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 25 Jul 2006 18:13:42 -0000 Message-ID: <002601c6b016$0f429a30$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Brian Rosen" , References: <013501c6b011$98b8d360$640fa8c0@cis.neustar.com> Subject: Re: [Sip] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 20:13:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, Your point 4 below is a concrete use case for point 1 (location by value in header). Using location for routing decisions benefits from quick access, a lookup by reference introduces delay. If you want a proxy to remove the location info, you cannot put the location info in the body, because proxies are not allowed to modify that. So you are left with location by reference. The use of TLS is then only to protect this URL? Regards, Jeroen ----- Original Message ----- From: "Brian Rosen" To: Sent: Tuesday, July 25, 2006 7:41 PM Subject: [Sip] Consensus on changes to location-conveyance >I have put out a number of emails on proposed changes to location > conveyance. Some of them have sparked a number of comments. My summary > of > consensus on these issues is: > > 1. We proposed to explicitly disallow use of a Data URI, which would allow > specification of a Location-by-value in a header. There was a lot of list > traffic on this, currently in the state where Keith asked for a real use > case for it. So far, we don't see a use case that cannot be provided by > location-by-reference in a header. If we don't get a good use case, I > think > consensus is to disallow location-by-value in a header. > > 2. Dereferencing location-by-reference. We had initially proposed to > document a process to use a raw HTTP(S) Get to dereference. There was a > lot > of discussion, and then I made a new proposal, see item 6. > > 3. We proposed to allow a Reason header with a 424 Bad Location response. > This seems to be acceptable to the WG. Geopriv will create and populate > the > registry in a separate draft. > > 4. We proposed to explicitly allow hop-by-hop TLS security for location > when > the endpoint wished to allow routing based on location. We further > proposed > to interpret "Do not Distribute" flags as allowing sending of the location > to the routing database (LoST for example). Hannes pointed out that there > was a proposal to allow two Location headers, one of which could be used > for > routing and another for onward forwarding to the recipient. Hannes' > message > seemed to agree that "Do not distribute" would allow sending of the > location > to the routing-by-location database, but would obligate the proxy that did > that to remove the location before it forwarded the message. There were > no > other messages on this thread. We conclude that allowing hop-by-hop > security for location based routing is acceptable, and Do Not Distribute > DOES allow forwarding to a routing database, but requires that the proxy > doing the location based route to remove the location it uses for that > purpose. > > 5. We proposed to create a parameter and a registry to distinguish > multiple > ways to dereference a location where HTTP(S) was the transport. > Resolution > of this issue depends on resolution of issue 6. > > 6. We proposed to allow sip/sips and pres: in the location header. I > later > speculated that if we allow this, it forms a simple way to do > location-by-reference, and we could eliminate the raw HTTP(S) Get > proposal, > with the parameter and registry entirely. There was some list traffic in > favor of this. Martin Thompson is skeptical that SIP Presence > Subscribe/Notify is actually allowed as a geopriv "using protocol". > Several > of think that it is. If we don't get any more comments on this proposal, > we > will allow sip/sips and pres, not have any http(s) resolution text, and > not > propose a parameter and accompanying registry. > > If this does not reflect your position, please speak up now. > > Brian > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 14:32:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Rg4-0002Gg-OI; Tue, 25 Jul 2006 14:30:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Rg3-0002GG-PA for sip@ietf.org; Tue, 25 Jul 2006 14:30:43 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Rg3-0006AV-BU for sip@ietf.org; Tue, 25 Jul 2006 14:30:43 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G5Rfv-0007D3-Vj; Tue, 25 Jul 2006 13:30:36 -0500 From: "Brian Rosen" To: "'Jeroen van Bemmel'" , Subject: RE: [Sip] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 14:30:39 -0400 Message-ID: <014801c6b018$6f8293d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawFg7Bb4beKUR4S9WU8aXw9Cf3oAAAVxWg In-Reply-To: <002601c6b016$0f429a30$31713b51@BEMBUSTER> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen I've always disliked location-by-reference because it has delay, and introduces the possibility (in the emergency case especially) where the dereferencer has connectivity to the endpoint but not the LIS. The WG however, has consensus that these issues are not significant, and the benefits outweigh the problems. Having said that using a reference is NOT seen as a performance problem then it's not a performance problem, and you can't argue it's a use case. Agree that if the endpoint wants location to be removed after routing before forwarding, then it has to use by-reference. Don't see that as a problem. Yes, TLS protects the URL, which is important, because anyone observing the SIP messaging can connect the identity of the SIP correspondent with the location (if it is allowed to dereference it), which is bad. Brian > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Tuesday, July 25, 2006 2:14 PM > To: Brian Rosen; sip@ietf.org > Subject: Re: [Sip] Consensus on changes to location-conveyance > > Brian, > > Your point 4 below is a concrete use case for point 1 (location by value > in > header). Using location for routing decisions benefits from quick access, > a > lookup by reference introduces delay. > > If you want a proxy to remove the location info, you cannot put the > location > info in the body, because proxies are not allowed to modify that. So you > are > left with location by reference. The use of TLS is then only to protect > this > URL? > > Regards, > > Jeroen > > ----- Original Message ----- > From: "Brian Rosen" > To: > Sent: Tuesday, July 25, 2006 7:41 PM > Subject: [Sip] Consensus on changes to location-conveyance > > > >I have put out a number of emails on proposed changes to location > > conveyance. Some of them have sparked a number of comments. My summary > > of > > consensus on these issues is: > > > > 1. We proposed to explicitly disallow use of a Data URI, which would > allow > > specification of a Location-by-value in a header. There was a lot of > list > > traffic on this, currently in the state where Keith asked for a real use > > case for it. So far, we don't see a use case that cannot be provided by > > location-by-reference in a header. If we don't get a good use case, I > > think > > consensus is to disallow location-by-value in a header. > > > > 2. Dereferencing location-by-reference. We had initially proposed to > > document a process to use a raw HTTP(S) Get to dereference. There was a > > lot > > of discussion, and then I made a new proposal, see item 6. > > > > 3. We proposed to allow a Reason header with a 424 Bad Location > response. > > This seems to be acceptable to the WG. Geopriv will create and populate > > the > > registry in a separate draft. > > > > 4. We proposed to explicitly allow hop-by-hop TLS security for location > > when > > the endpoint wished to allow routing based on location. We further > > proposed > > to interpret "Do not Distribute" flags as allowing sending of the > location > > to the routing database (LoST for example). Hannes pointed out that > there > > was a proposal to allow two Location headers, one of which could be used > > for > > routing and another for onward forwarding to the recipient. Hannes' > > message > > seemed to agree that "Do not distribute" would allow sending of the > > location > > to the routing-by-location database, but would obligate the proxy that > did > > that to remove the location before it forwarded the message. There were > > no > > other messages on this thread. We conclude that allowing hop-by-hop > > security for location based routing is acceptable, and Do Not Distribute > > DOES allow forwarding to a routing database, but requires that the proxy > > doing the location based route to remove the location it uses for that > > purpose. > > > > 5. We proposed to create a parameter and a registry to distinguish > > multiple > > ways to dereference a location where HTTP(S) was the transport. > > Resolution > > of this issue depends on resolution of issue 6. > > > > 6. We proposed to allow sip/sips and pres: in the location header. I > > later > > speculated that if we allow this, it forms a simple way to do > > location-by-reference, and we could eliminate the raw HTTP(S) Get > > proposal, > > with the parameter and registry entirely. There was some list traffic > in > > favor of this. Martin Thompson is skeptical that SIP Presence > > Subscribe/Notify is actually allowed as a geopriv "using protocol". > > Several > > of think that it is. If we don't get any more comments on this > proposal, > > we > > will allow sip/sips and pres, not have any http(s) resolution text, and > > not > > propose a parameter and accompanying registry. > > > > If this does not reflect your position, please speak up now. > > > > Brian > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 14:45:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Rsw-0006ve-Hk; Tue, 25 Jul 2006 14:44:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Rsu-0006vY-Uq for sip@ietf.org; Tue, 25 Jul 2006 14:44:00 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Rst-0008Rf-Lr for sip@ietf.org; Tue, 25 Jul 2006 14:44:00 -0400 Received: by ug-out-1314.google.com with SMTP id m2so2982366uge for ; Tue, 25 Jul 2006 11:43:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=bUQF9zp8hoOdGKxyIzaSDe8UWkOucKCzumE982af5ZJ4yQqMUnrOSu8eA0uJD8R/hAlfjfkr84CbVRx52x3viAxCmv6PuHQ07C5ZY247gefjt+8jRajogrpIPKIfxDeMUMcQTI6Okmnm/dgohcFL33vLEEYkuLKheS/RKfxWYmg= Received: by 10.78.166.7 with SMTP id o7mr2555322hue; Tue, 25 Jul 2006 11:43:58 -0700 (PDT) Received: by 10.78.138.13 with HTTP; Tue, 25 Jul 2006 11:43:58 -0700 (PDT) Message-ID: Date: Tue, 25 Jul 2006 19:43:58 +0100 From: "banuprakash gm" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] SIP stack X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1294982406==" Errors-To: sip-bounces@ietf.org --===============1294982406== Content-Type: multipart/alternative; boundary="----=_Part_1685_11695120.1153853038643" ------=_Part_1685_11695120.1153853038643 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline *Hi, ** ** I am supposed to build a additional features sip based ip phone for *the dissertation ** * Could somebody give me guidance as to how I can go about this? ** Where can I get a SIP stack ? How can I code (preferably in *C++) *using this stack? ** * *SIP stack which i can run on windows xp * * Anxiously awainting ur responses....* kind regards, banu ------=_Part_1685_11695120.1153853038643 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 
Hi,

	   I am supposed to build a additional features  sip based ip phone for
the dissertation 

 Could somebody give me guidance as to how I can go about this?

	Where can I get a SIP stack ? How can I code (preferably in
C++) using this stack? 

SIP stack  which i can run on windows xp 

 
Anxiously awainting ur responses....

kind regards,
banu
------=_Part_1685_11695120.1153853038643-- --===============1294982406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1294982406==-- From sip-bounces@ietf.org Tue Jul 25 14:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Rvz-0000g7-SM; Tue, 25 Jul 2006 14:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Rvx-0000fx-Pu for sip@ietf.org; Tue, 25 Jul 2006 14:47:09 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Rvw-0001D4-HN for sip@ietf.org; Tue, 25 Jul 2006 14:47:09 -0400 Received: by ug-out-1314.google.com with SMTP id m2so2983756uge for ; Tue, 25 Jul 2006 11:47:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=F05PVsoP6/PTy+WjVaf/cJihF5uhmUbkUSjMNhS350kaesCHHyuHyPpAGy6ZLw6+VRi7jJKL4gyOaUN5w0pyjE2JDPmAsGhBFYcTRUxGsCsrHIXcxnOHyEI1uxSbaxzSkDP8E3mQt6mB6whsk7fMNP3+x91FbK6V2FfxMO9N7Mw= Received: by 10.78.120.6 with SMTP id s6mr2551717huc; Tue, 25 Jul 2006 11:47:07 -0700 (PDT) Received: by 10.78.138.13 with HTTP; Tue, 25 Jul 2006 11:47:07 -0700 (PDT) Message-ID: Date: Tue, 25 Jul 2006 19:47:07 +0100 From: "banuprakash gm" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Sip] SIP's practical applications X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1525419931==" Errors-To: sip-bounces@ietf.org --===============1525419931== Content-Type: multipart/alternative; boundary="----=_Part_1797_17595336.1153853227586" ------=_Part_1797_17595336.1153853227586 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi , Thanks a lot for the response. I am new to SIP's practical applications. Could you please give me guidance as to how I can use this SIP stack to develop a additional features like security and privacy Thanks in advance.. Regards Banu ------=_Part_1797_17595336.1153853227586 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 
Hi ,

Thanks a lot for the response.

I am new to SIP's practical applications. Could you please give me
guidance as to how I can use this SIP stack to develop a additional features like security  and privacy



Thanks in advance..

Regards
Banu
------=_Part_1797_17595336.1153853227586-- --===============1525419931== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1525419931==-- From sip-bounces@ietf.org Tue Jul 25 15:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SE2-0000wq-OI; Tue, 25 Jul 2006 15:05:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SE1-0000tP-Nl for sip@ietf.org; Tue, 25 Jul 2006 15:05:49 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5SE0-0007iF-61 for sip@ietf.org; Tue, 25 Jul 2006 15:05:49 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.7/8.13.7) with ESMTP id k6PJ5khE086054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Jul 2006 19:05:47 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6PJ93Hu140594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Jul 2006 21:09:03 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6PJ5kdG007108 for ; Tue, 25 Jul 2006 21:05:46 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6PJ5kYC007102; Tue, 25 Jul 2006 21:05:46 +0200 In-Reply-To: <5D1A7985295922448D5550C94DE2918013B758@DEEXC1U01.de.lucent.com> Subject: RE: [Sip] Hitchhikers guide - when is it done? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Tue, 25 Jul 2006 22:08:49 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 25/07/2006 22:09:02, Serialize complete at 25/07/2006 22:09:02 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Option 2 also. Issuing a list of core RFCs as option 1 suggests requires a strict list of core vs. non core sooner then later. Later will be better in this case. --Avshalom "Drage, Keith \(Keith\)" 25/07/2006 21:07 To "Jonathan Rosenberg" , "IETF SIP List" cc Subject RE: [Sip] Hitchhikers guide - when is it done? (As individual) I also prefer option 2. I think the IETF has to solve the problem of more rapid revision of documents. Regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 25 July 2006 18:56 > To: IETF SIP List > Subject: [Sip] Hitchhikers guide - when is it done? > > During the IETF meeting, I discussed the one current open > issue in the Hitchhikers guide. The issue is: when does the > document finish? When do we send to IESG to issue an RFC? > > There were two approaches: > > 1. split the document in two. One part contains only the core > specs, and issues relatively soon. The other part has > everything else, and basically ends up being the last RFC > produced by the SIP WG before it shuts its doors (which has > always been 1.5 years from now for the last 5 years). > > 2. keep it as one document. Issue an RFC at some point, and > then revise it a few times as needed. We need to decide when > to issue it. > > > I'd like to propose option 2. I think people get more value > from it as a > consolidated document. Furthermore, I'd propose that we send the > document to IESG for consideration as informational at the > instant all > of the documents listed as 'core' have RFC numbers issued by RFC-ed. > > Comments? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 15:42:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Sll-00020s-LO; Tue, 25 Jul 2006 15:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Slk-00020g-9e for sip@ietf.org; Tue, 25 Jul 2006 15:40:40 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Slh-0003c7-Uf for sip@ietf.org; Tue, 25 Jul 2006 15:40:40 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k6PJeaaK022052; Tue, 25 Jul 2006 19:40:36 GMT Subject: Re: [Sip] Hitchhikers guide - when is it done? From: Daryl Malas To: Jonathan Rosenberg In-Reply-To: <44C65B13.5040803@cisco.com> References: <44C65B13.5040803@cisco.com> Content-Type: text/plain Date: Tue, 25 Jul 2006 13:41:33 -0600 Message-Id: <1153856493.19821.57.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I like option 2. I would like to see it submitted sooner rather than later. Any pending or new RFC's can be added to a new revision, which will obsolete this one down the road. --Daryl On Tue, 2006-07-25 at 13:55 -0400, Jonathan Rosenberg wrote: > During the IETF meeting, I discussed the one current open issue in the > Hitchhikers guide. The issue is: when does the document finish? When do > we send to IESG to issue an RFC? > > There were two approaches: > > 1. split the document in two. One part contains only the core specs, and > issues relatively soon. The other part has everything else, and > basically ends up being the last RFC produced by the SIP WG before it > shuts its doors (which has always been 1.5 years from now for the last 5 > years). > > 2. keep it as one document. Issue an RFC at some point, and then revise > it a few times as needed. We need to decide when to issue it. > > > I'd like to propose option 2. I think people get more value from it as a > consolidated document. Furthermore, I'd propose that we send the > document to IESG for consideration as informational at the instant all > of the documents listed as 'core' have RFC numbers issued by RFC-ed. > > Comments? > > -Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 15:52:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SvQ-0007Nv-88; Tue, 25 Jul 2006 15:50:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Sv2-0006rj-8L; Tue, 25 Jul 2006 15:50:16 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Sv1-0007nK-Vx; Tue, 25 Jul 2006 15:50:16 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns1.neustar.com (Postfix) with ESMTP id E929B26E1E; Tue, 25 Jul 2006 19:50:15 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 15:50:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jul 2006 15:50:14 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcawERldoiEvROTuT2KasGKrfOW37QABTfWwAAKqafA= From: "Rosen, Brian" To: "Marc Linsner" , X-OriginalArrivalTime: 25 Jul 2006 19:50:15.0740 (UTC) FILETIME=[8CB11FC0:01C6B023] X-Spam-Score: -2.3 (--) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org When the original PIDF-LO RFC came out, location-by-reference was defined. You have a URI. You can exchange the URI for location. There is a protocol defined for that purpose (SIP SUBSCRIBE). That is location by reference. It also serves as the location update mechanism, clearly something we need. Some day, there may be other location URI references. We don't need to cover them in this draft. The basic location by reference horse has left the barn. Were you planning on creating an RFC that specifically disallows a Subscribe on a sip/sips/pres URI to get location? THAT WAS THE POINT OF MAKING IT PART OF A PIDF. I do think there is some value in defining a way to express a location-by-reference aka presence URI which is not just the AoR. That is one reason why I want to define the Location URI as being able to contain a sip/sips/pres URI. The purpose is to allow a UA or a proxy to insert location where there is no association between the identity of the SIP user and the location.=20 But that is all I think we need. We have a requirement for proxy insertion of location. If we disallow location-by-reference (which I think is a good idea in general, but futile in practice), then we would need something like the Data URI to support location insertion by proxy. If we DO allow location-by-reference, then it also serves to meet the location insertion by proxy requirement, and we don't need the Data URI. We're looking for a use case which requires proxy insertion by value, but haven't heard one yet. You can make an argument that you can take the From:, assume it's an AoR, and SUBSCRIBE to the presence of that AoR to get location, thus not needing a Location header. I really think letting the Location header specify an alternate presence URI is a good idea. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Tuesday, July 25, 2006 3:29 PM > To: Rosen, Brian; sip@ietf.org > Cc: geopriv@ietf.org > Subject: RE: [Geopriv] Consensus on changes to location-conveyance >=20 > In-line..... >=20 > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Tuesday, July 25, 2006 1:38 PM > > To: sip@ietf.org > > Cc: geopriv@ietf.org > > Subject: [Geopriv] Consensus on changes to location-conveyance > > > > I have put out a number of emails on proposed changes to > > location conveyance. Some of them have sparked a number of > > comments. My summary of consensus on these issues is: > > > > 1. We proposed to explicitly disallow use of a Data URI, > > which would allow specification of a Location-by-value in a > > header. There was a lot of list traffic on this, currently > > in the state where Keith asked for a real use case for it. > > So far, we don't see a use case that cannot be provided by > > location-by-reference in a header. If we don't get a good > > use case, I think consensus is to disallow location-by-value > > in a header. > > >=20 > I see a problem here. Location-by-reference is nothing more than 'magic > happens here'! Please point to a wg item documenting the > location-by-reference mechanism. How can you state the > location-by-reference will cover all the use cases that the Data URI would > when location-by-reference hasn't even been defined anywhere? You're > loading up the magic with a lot of assumptions. Location-by-reference is > an > individual submission as a solution to a set of requirements that haven't > been fleshed-out in geopriv. >=20 > I believe that Henning/Hannes also recognized this issue, hence the > suggestion of a Data URI. Dismissing this suggestion based on an already > accepted non-existent mechanism seems like getting the cart before the > horse. >=20 > ..........snip >=20 > > 6. We proposed to allow sip/sips and pres: in the location > > header. I later speculated that if we allow this, it forms a > > simple way to do location-by-reference, and we could > > eliminate the raw HTTP(S) Get proposal, with the parameter > > and registry entirely. There was some list traffic in favor > > of this. Martin Thompson is skeptical that SIP Presence > > Subscribe/Notify is actually allowed as a geopriv "using > > protocol". Several of think that it is. If we don't get any > > more comments on this proposal, we will allow sip/sips and > > pres, not have any > > http(s) resolution text, and not propose a parameter and > > accompanying registry. >=20 > I certainly think it's more prudent to define the dereferencing mechanism > prior to making claims about the protocol. >=20 > Do I believe location-by-reference will happen? Probably, but making > assumptions about the mechanism now is quite premature. >=20 > -Marc- >=20 > > > > If this does not reflect your position, please speak up now. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 16:06:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5T9A-0002Gd-IX; Tue, 25 Jul 2006 16:04:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5T98-0002GQ-Hk; Tue, 25 Jul 2006 16:04:50 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5T97-0003aZ-69; Tue, 25 Jul 2006 16:04:50 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 25 Jul 2006 16:04:58 -0400 id 01588119.44C6796A.000067A5 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 16:04:48 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: sip@ietf.org, geopriv@ietf.org, Marc Linsner X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org For the record, I agree with Brian. -andy On Jul 25, 2006, at 3:50 PM, Rosen, Brian wrote: > When the original PIDF-LO RFC came out, location-by-reference was > defined. > > You have a URI. You can exchange the URI for location. There is a > protocol defined for that purpose (SIP SUBSCRIBE). That is > location by > reference. It also serves as the location update mechanism, clearly > something we need. > > Some day, there may be other location URI references. We don't > need to > cover them in this draft. The basic location by reference horse has > left the barn. Were you planning on creating an RFC that specifically > disallows a Subscribe on a sip/sips/pres URI to get location? > THAT WAS > THE POINT OF MAKING IT PART OF A PIDF. > > I do think there is some value in defining a way to express a > location-by-reference aka presence URI which is not just the AoR. > That > is one reason why I want to define the Location URI as being able to > contain a sip/sips/pres URI. The purpose is to allow a UA or a > proxy to > insert location where there is no association between the identity of > the SIP user and the location. > > But that is all I think we need. > > We have a requirement for proxy insertion of location. If we disallow > location-by-reference (which I think is a good idea in general, but > futile in practice), then we would need something like the Data URI to > support location insertion by proxy. If we DO allow > location-by-reference, then it also serves to meet the location > insertion by proxy requirement, and we don't need the Data URI. We're > looking for a use case which requires proxy insertion by value, but > haven't heard one yet. > > You can make an argument that you can take the From:, assume it's an > AoR, and SUBSCRIBE to the presence of that AoR to get location, > thus not > needing a Location header. I really think letting the Location header > specify an alternate presence URI is a good idea. > > Brian > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Tuesday, July 25, 2006 3:29 PM >> To: Rosen, Brian; sip@ietf.org >> Cc: geopriv@ietf.org >> Subject: RE: [Geopriv] Consensus on changes to location-conveyance >> >> In-line..... >> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Tuesday, July 25, 2006 1:38 PM >>> To: sip@ietf.org >>> Cc: geopriv@ietf.org >>> Subject: [Geopriv] Consensus on changes to location-conveyance >>> >>> I have put out a number of emails on proposed changes to >>> location conveyance. Some of them have sparked a number of >>> comments. My summary of consensus on these issues is: >>> >>> 1. We proposed to explicitly disallow use of a Data URI, >>> which would allow specification of a Location-by-value in a >>> header. There was a lot of list traffic on this, currently >>> in the state where Keith asked for a real use case for it. >>> So far, we don't see a use case that cannot be provided by >>> location-by-reference in a header. If we don't get a good >>> use case, I think consensus is to disallow location-by-value >>> in a header. >>> >> >> I see a problem here. Location-by-reference is nothing more than > 'magic >> happens here'! Please point to a wg item documenting the >> location-by-reference mechanism. How can you state the >> location-by-reference will cover all the use cases that the Data URI > would >> when location-by-reference hasn't even been defined anywhere? You're >> loading up the magic with a lot of assumptions. Location-by- >> reference > is >> an >> individual submission as a solution to a set of requirements that > haven't >> been fleshed-out in geopriv. >> >> I believe that Henning/Hannes also recognized this issue, hence the >> suggestion of a Data URI. Dismissing this suggestion based on an > already >> accepted non-existent mechanism seems like getting the cart before >> the >> horse. >> >> ..........snip >> >>> 6. We proposed to allow sip/sips and pres: in the location >>> header. I later speculated that if we allow this, it forms a >>> simple way to do location-by-reference, and we could >>> eliminate the raw HTTP(S) Get proposal, with the parameter >>> and registry entirely. There was some list traffic in favor >>> of this. Martin Thompson is skeptical that SIP Presence >>> Subscribe/Notify is actually allowed as a geopriv "using >>> protocol". Several of think that it is. If we don't get any >>> more comments on this proposal, we will allow sip/sips and >>> pres, not have any >>> http(s) resolution text, and not propose a parameter and >>> accompanying registry. >> >> I certainly think it's more prudent to define the dereferencing > mechanism >> prior to making claims about the protocol. >> >> Do I believe location-by-reference will happen? Probably, but making >> assumptions about the mechanism now is quite premature. >> >> -Marc- >> >>> >>> If this does not reflect your position, please speak up now. >>> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 16:23:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TPY-0004zT-HQ; Tue, 25 Jul 2006 16:21:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TPW-0004zB-C6; Tue, 25 Jul 2006 16:21:46 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5TPV-0006SQ-6A; Tue, 25 Jul 2006 16:21:46 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 25 Jul 2006 16:21:54 -0400 id 01588119.44C67D63.00006AF6 In-Reply-To: <00be01c6b020$9e9eb100$1f0d0d0a@amer.cisco.com> References: <00be01c6b020$9e9eb100$1f0d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61B807C4-F245-4358-A5B0-3978F6DB36D1@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Tue, 25 Jul 2006 16:21:44 -0400 To: Marc Linsner X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: sip@ietf.org, "'Rosen, Brian'" , geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 25, 2006, at 3:29 PM, Marc Linsner wrote: > Do I believe location-by-reference will happen? Probably, but making > assumptions about the mechanism now is quite premature. Perhaps nothing will save us. We've had by-value since step one, and now by-value take 2 is being proposed. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 16:31:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TXe-0008Ej-4c; Tue, 25 Jul 2006 16:30:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TXc-0008Dq-2D for sip@ietf.org; Tue, 25 Jul 2006 16:30:08 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5TXZ-0008Fq-DF for sip@ietf.org; Tue, 25 Jul 2006 16:30:08 -0400 Received: (qmail 470 invoked by uid 0); 25 Jul 2006 20:30:03 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 25 Jul 2006 20:30:03 -0000 Message-ID: <008c01c6b029$1b5bb320$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Brian Rosen" , References: <014801c6b018$6f8293d0$640fa8c0@cis.neustar.com> Subject: Re: [Sip] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 22:30:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, Three more remarks: 1 - Location by value is much easier to get interoperable than location by reference, also because the latter has many semantic issues (in addition to performance, chance at failure): * When dereferencing, for what time instance do I get the location? * if { moment of call }, how do you guarantee that the dereferenced source will have exactly that information? * if { moment of dereference }, for how long is the URI supposed / assumed to be usable? * how does the user control/limit access to that location information? All of the above is clear for location-by-value. It is therefore much easier to ensure privacy for that, in a way that is easily explained to the user: either you give your location at that moment, or you dont. Period 2 - In particular for emergency scenarios, I think you would want both (by value and by reference), even within the same request: rough location by value (eg cell-id) could be used to route the call to the appropriate emergency center, then a Location URI (provided in the same request) can be dereferenced from there, which may give a more precise location after some time (say 10s of seconds). Moreover, the reference could be used to track the location over time 3 Rather than relying on TLS for security of the location-user mapping, I always assumed there would be requirements for access control at the location server? To me requiring TLS is a definite way to ensure that this will not see widespread use... Regards, Jeroen ----- Original Message ----- From: "Brian Rosen" To: "'Jeroen van Bemmel'" ; Sent: Tuesday, July 25, 2006 8:30 PM Subject: RE: [Sip] Consensus on changes to location-conveyance > Jeroen > > I've always disliked location-by-reference because it has delay, and > introduces the possibility (in the emergency case especially) where the > dereferencer has connectivity to the endpoint but not the LIS. > > The WG however, has consensus that these issues are not significant, and > the > benefits outweigh the problems. > > Having said that using a reference is NOT seen as a performance problem > then > it's not a performance problem, and you can't argue it's a use case. > > Agree that if the endpoint wants location to be removed after routing > before > forwarding, then it has to use by-reference. Don't see that as a problem. > > Yes, TLS protects the URL, which is important, because anyone observing > the > SIP messaging can connect the identity of the SIP correspondent with the > location (if it is allowed to dereference it), which is bad. > > Brian > >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: Tuesday, July 25, 2006 2:14 PM >> To: Brian Rosen; sip@ietf.org >> Subject: Re: [Sip] Consensus on changes to location-conveyance >> >> Brian, >> >> Your point 4 below is a concrete use case for point 1 (location by value >> in >> header). Using location for routing decisions benefits from quick access, >> a >> lookup by reference introduces delay. >> >> If you want a proxy to remove the location info, you cannot put the >> location >> info in the body, because proxies are not allowed to modify that. So you >> are >> left with location by reference. The use of TLS is then only to protect >> this >> URL? >> >> Regards, >> >> Jeroen >> >> ----- Original Message ----- >> From: "Brian Rosen" >> To: >> Sent: Tuesday, July 25, 2006 7:41 PM >> Subject: [Sip] Consensus on changes to location-conveyance >> >> >> >I have put out a number of emails on proposed changes to location >> > conveyance. Some of them have sparked a number of comments. My >> > summary >> > of >> > consensus on these issues is: >> > >> > 1. We proposed to explicitly disallow use of a Data URI, which would >> allow >> > specification of a Location-by-value in a header. There was a lot of >> list >> > traffic on this, currently in the state where Keith asked for a real >> > use >> > case for it. So far, we don't see a use case that cannot be provided >> > by >> > location-by-reference in a header. If we don't get a good use case, I >> > think >> > consensus is to disallow location-by-value in a header. >> > >> > 2. Dereferencing location-by-reference. We had initially proposed to >> > document a process to use a raw HTTP(S) Get to dereference. There was >> > a >> > lot >> > of discussion, and then I made a new proposal, see item 6. >> > >> > 3. We proposed to allow a Reason header with a 424 Bad Location >> response. >> > This seems to be acceptable to the WG. Geopriv will create and >> > populate >> > the >> > registry in a separate draft. >> > >> > 4. We proposed to explicitly allow hop-by-hop TLS security for location >> > when >> > the endpoint wished to allow routing based on location. We further >> > proposed >> > to interpret "Do not Distribute" flags as allowing sending of the >> location >> > to the routing database (LoST for example). Hannes pointed out that >> there >> > was a proposal to allow two Location headers, one of which could be >> > used >> > for >> > routing and another for onward forwarding to the recipient. Hannes' >> > message >> > seemed to agree that "Do not distribute" would allow sending of the >> > location >> > to the routing-by-location database, but would obligate the proxy that >> did >> > that to remove the location before it forwarded the message. There >> > were >> > no >> > other messages on this thread. We conclude that allowing hop-by-hop >> > security for location based routing is acceptable, and Do Not >> > Distribute >> > DOES allow forwarding to a routing database, but requires that the >> > proxy >> > doing the location based route to remove the location it uses for that >> > purpose. >> > >> > 5. We proposed to create a parameter and a registry to distinguish >> > multiple >> > ways to dereference a location where HTTP(S) was the transport. >> > Resolution >> > of this issue depends on resolution of issue 6. >> > >> > 6. We proposed to allow sip/sips and pres: in the location header. I >> > later >> > speculated that if we allow this, it forms a simple way to do >> > location-by-reference, and we could eliminate the raw HTTP(S) Get >> > proposal, >> > with the parameter and registry entirely. There was some list traffic >> in >> > favor of this. Martin Thompson is skeptical that SIP Presence >> > Subscribe/Notify is actually allowed as a geopriv "using protocol". >> > Several >> > of think that it is. If we don't get any more comments on this >> proposal, >> > we >> > will allow sip/sips and pres, not have any http(s) resolution text, and >> > not >> > propose a parameter and accompanying registry. >> > >> > If this does not reflect your position, please speak up now. >> > >> > Brian >> > >> > >> > _______________________________________________ >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 16:43:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tiz-0007cY-Mk; Tue, 25 Jul 2006 16:41:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tiy-0007Zo-6a; Tue, 25 Jul 2006 16:41:52 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Tix-0001lW-R6; Tue, 25 Jul 2006 16:41:52 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6PKfjox008271; Tue, 25 Jul 2006 20:41:45 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 16:41:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 16:41:31 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F4511@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcawJZpkqbGyCVnSTue1IO2WT/AgKAAAR94g From: "Peterson, Jon" To: "Andrew Newton" , "Rosen, Brian" X-OriginalArrivalTime: 25 Jul 2006 20:41:45.0189 (UTC) FILETIME=[BE25A150:01C6B02A] X-Spam-Score: 0.5 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: sip@ietf.org, geopriv@ietf.org, Marc Linsner X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As Brian points out, the whole point of using PIDF for location = information was the similarity of the early defined use cases to the = presence architecture. This certainly included use cases in which one = wanted to fetch or subscribe to location information. Those operations = require the existence of a reference, and that reference was commonly = described as a URI, at the time. Lately, I think the idea of having a = URI pointing to location information has become associated with a = specific proposal (i.e. HELD), but clearly RFC4079 sketched out an = architecture for using presence to acquire location information and it = specifically mentions URIs as a way to refer to presence.=20 There is no "hidden magic" in any of this. Subscribing to presence, and = using URIs to indicate presence information, is exhaustively specified = for SIP. PIDF-LO was designed to reuse all of that work and specifically = not to require us to go out and reinvent everything in order to be able = to refer to location information out in the network. Basically, I support the direction re: bullet 6. I might further suggest = that the CID URI scheme be permitted in the Location header, in order to = be able to refer to MIME bodies included in SIP messages. I'm also = neutral/favorable on using HTTP GET. But I think either of these URI = schemes and their usage in the Location header could just as well be = described in subsequent documents. Jon Peterson NeuStar, Inc, > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, July 25, 2006 1:05 PM > To: Rosen, Brian > Cc: sip@ietf.org; geopriv@ietf.org; Marc Linsner > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to > location-conveyance >=20 >=20 > For the record, I agree with Brian. >=20 > -andy >=20 > On Jul 25, 2006, at 3:50 PM, Rosen, Brian wrote: >=20 > > When the original PIDF-LO RFC came out, location-by-reference was > > defined. > > > > You have a URI. You can exchange the URI for location. There is a > > protocol defined for that purpose (SIP SUBSCRIBE). That is =20 > > location by > > reference. It also serves as the location update mechanism, clearly > > something we need. > > > > Some day, there may be other location URI references. We don't =20 > > need to > > cover them in this draft. The basic location by reference horse has > > left the barn. Were you planning on creating an RFC that=20 > specifically > > disallows a Subscribe on a sip/sips/pres URI to get location? =20 > > THAT WAS > > THE POINT OF MAKING IT PART OF A PIDF. > > > > I do think there is some value in defining a way to express a > > location-by-reference aka presence URI which is not just the AoR. =20 > > That > > is one reason why I want to define the Location URI as being able to > > contain a sip/sips/pres URI. The purpose is to allow a UA or a =20 > > proxy to > > insert location where there is no association between the=20 > identity of > > the SIP user and the location. > > > > But that is all I think we need. > > > > We have a requirement for proxy insertion of location. If=20 > we disallow > > location-by-reference (which I think is a good idea in general, but > > futile in practice), then we would need something like the=20 > Data URI to > > support location insertion by proxy. If we DO allow > > location-by-reference, then it also serves to meet the location > > insertion by proxy requirement, and we don't need the Data=20 > URI. We're > > looking for a use case which requires proxy insertion by value, but > > haven't heard one yet. > > > > You can make an argument that you can take the From:, assume it's an > > AoR, and SUBSCRIBE to the presence of that AoR to get location, =20 > > thus not > > needing a Location header. I really think letting the=20 > Location header > > specify an alternate presence URI is a good idea. > > > > Brian > > > >> -----Original Message----- > >> From: Marc Linsner [mailto:mlinsner@cisco.com] > >> Sent: Tuesday, July 25, 2006 3:29 PM > >> To: Rosen, Brian; sip@ietf.org > >> Cc: geopriv@ietf.org > >> Subject: RE: [Geopriv] Consensus on changes to location-conveyance > >> > >> In-line..... > >> > >>> -----Original Message----- > >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > >>> Sent: Tuesday, July 25, 2006 1:38 PM > >>> To: sip@ietf.org > >>> Cc: geopriv@ietf.org > >>> Subject: [Geopriv] Consensus on changes to location-conveyance > >>> > >>> I have put out a number of emails on proposed changes to > >>> location conveyance. Some of them have sparked a number of > >>> comments. My summary of consensus on these issues is: > >>> > >>> 1. We proposed to explicitly disallow use of a Data URI, > >>> which would allow specification of a Location-by-value in a > >>> header. There was a lot of list traffic on this, currently > >>> in the state where Keith asked for a real use case for it. > >>> So far, we don't see a use case that cannot be provided by > >>> location-by-reference in a header. If we don't get a good > >>> use case, I think consensus is to disallow location-by-value > >>> in a header. > >>> > >> > >> I see a problem here. Location-by-reference is nothing more than > > 'magic > >> happens here'! Please point to a wg item documenting the > >> location-by-reference mechanism. How can you state the > >> location-by-reference will cover all the use cases that=20 > the Data URI > > would > >> when location-by-reference hasn't even been defined=20 > anywhere? You're > >> loading up the magic with a lot of assumptions. Location-by-=20 > >> reference > > is > >> an > >> individual submission as a solution to a set of requirements that > > haven't > >> been fleshed-out in geopriv. > >> > >> I believe that Henning/Hannes also recognized this issue, hence the > >> suggestion of a Data URI. Dismissing this suggestion based on an > > already > >> accepted non-existent mechanism seems like getting the=20 > cart before =20 > >> the > >> horse. > >> > >> ..........snip > >> > >>> 6. We proposed to allow sip/sips and pres: in the location > >>> header. I later speculated that if we allow this, it forms a > >>> simple way to do location-by-reference, and we could > >>> eliminate the raw HTTP(S) Get proposal, with the parameter > >>> and registry entirely. There was some list traffic in favor > >>> of this. Martin Thompson is skeptical that SIP Presence > >>> Subscribe/Notify is actually allowed as a geopriv "using > >>> protocol". Several of think that it is. If we don't get any > >>> more comments on this proposal, we will allow sip/sips and > >>> pres, not have any > >>> http(s) resolution text, and not propose a parameter and > >>> accompanying registry. > >> > >> I certainly think it's more prudent to define the dereferencing > > mechanism > >> prior to making claims about the protocol. > >> > >> Do I believe location-by-reference will happen? Probably,=20 > but making > >> assumptions about the mechanism now is quite premature. > >> > >> -Marc- > >> > >>> > >>> If this does not reflect your position, please speak up now. > >>> > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 16:44:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tjk-0000ST-7V; Tue, 25 Jul 2006 16:42:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tji-0000QQ-6D; Tue, 25 Jul 2006 16:42:38 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Tjh-0001z3-Bo; Tue, 25 Jul 2006 16:42:37 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6PKgaox008341; Tue, 25 Jul 2006 20:42:37 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 16:42:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jul 2006 16:42:35 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcawKZxZAaHsJrZ2T7CK9PirQWRobgAAErbw From: "Rosen, Brian" To: "Ted Hardie" , X-OriginalArrivalTime: 25 Jul 2006 20:42:36.0736 (UTC) FILETIME=[DCDF1400:01C6B02A] X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks. To define the "retransmission for routing" bit, we need to rev PIDF-LO. I don't think doing that in location-conveyance is the right place. Would you agree? Is there consensus one way or the other on this? Generally, I do agree explicit is better than implicit for any kind of permission. I'm loath to generate yet one more RFC, but this one looks simple enough. With respect to an HTTP protocol for location by reference dereferencing, I have no problem with having some other document specify this. We're going to have a simple mechanism defined in location-conveyance to allow such an extension; it won't require the SIP change process. If that is an acceptable compromise, then we can close this issue, although I'll certainly be holding off a couple of days to hear from other folks. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Tuesday, July 25, 2006 4:34 PM > To: Rosen, Brian; sip@ietf.org > Cc: geopriv@ietf.org > Subject: RE: [Geopriv] Consensus on changes to location-conveyance >=20 > At 2:45 PM -0400 7/25/06, Rosen, Brian wrote: > >Summarizing, you think hop-by-hop security (TLS) is acceptable when the > >location is sent for the purposes of location based routing, but you are > >not in favor of defining "retransmission=3Dno" to permit sending the > >location to the routing database (e.g. LoST). You want a more explicit > >permission. >=20 > Yes. >=20 > >I don't think a cid: with a ruleset is acceptable, as it would not > >permit location by reference added by a proxy to specify this. >=20 > Fair enough. >=20 >=20 >=20 > >If this is the consensus, I think we would have to add a bit to the PIDF > >to explicitly control this behavior. >=20 > I think an extension that says "retransmission for routing=3Dyes" is = the > cleanest > way to go. >=20 >=20 > >Why do you think we must specify an HTTP dereference procedure in this > >document? What is the purpose when the SIP based method is available? > >We had believed we had to have SOME method of dereferencing to make > >location-by-reference meaningful in the document. If we have one sip > >based method, we meet the requirement. Having more options, especially > >completely new HTTP based protocols IN THIS DOCUMENT seems unnecessary > >and unwise. For example, if we define such a protocol, it becomes a > >geopriv "using protocol" and needs an explicit analysis against the > >geopriv criteria. >=20 > I don't think we have to do it in this document, but I read your previous > message as a statement of consensus about the HTTP dereference mechanisms > that have been discussed. I don't agree with that statement, since I > think the > HTTP discussions somewhat over-thought the potential problems. In > particular, a > lot of the discussion was around the idea that > http://dereference.example.org/foo-pidf-lo > might mean lots of different things, depending on what http meant. There > are > already ways to deal with that; none of them are perfect (see, for > example, > the discussion in draft-reschke-webdav-mount-05.txt and its appendix A for > a similar > problem in a different context), but they can work, especially if you set > a baseline > approach. >=20 > regards, > Ted Hardie >=20 >=20 >=20 > >Brian > > > >> -----Original Message----- > >> From: Ted Hardie [mailto:hardie@qualcomm.com] > >> Sent: Tuesday, July 25, 2006 2:19 PM > >> To: Rosen, Brian; sip@ietf.org > >> Cc: geopriv@ietf.org > >> Subject: Re: [Geopriv] Consensus on changes to location-conveyance > >> > >> At 1:38 PM -0400 7/25/06, Rosen, Brian wrote: > >> >4. We proposed to explicitly allow hop-by-hop TLS security for > >location > >> >when the endpoint wished to allow routing based on location. We > >further > >> >proposed to interpret "Do not Distribute" flags as allowing sending > >of > >> >the location to the routing database (LoST for example). Hannes > >pointed > >> >out that there was a proposal to allow two Location headers, one of > >> >which could be used for routing and another for onward forwarding to > >the > >> >recipient. Hannes' message seemed to agree that "Do not distribute" > >> >would allow sending of the location to the routing-by-location > >database, > >> >but would obligate the proxy that did that to remove the location > >before > >> >it forwarded the message. There were no other messages on this > >thread. > >> > >> Actually, I commented on the same problem, though it may have been > >> connected to one of the related threads; here's the text of that > >message: > >> > >> >At 5:23 PM -0400 7/19/06, Brian Rosen wrote: > >> >>NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU REPLY, SEND IT > >> ONLY TO > >> >>GEOPRIV > >> >>However, this opens up the issue of geopriv privacy concerns because > >the > >> >>sender does not know the identity of the element (proxy) that will > >route > >> the > >> >>call using LoST. It may be that the UAC itself does this, but it > >may be > >> >>some other intermediary. > >> >> > >> >>If the identity of the intermediary is not known, then protecting > >the > >> >>location information becomes more difficult, because we cannot > >encrypt > >> using > >> >>keying material from the intended recipient. > >> > > >> >Just to mention this, it appears to also rule out the idea of > >encrypting > >> >with the user's key, since there is no way of knowing whether the > >> "intended > >> >recipient" has that key material either. Intended recipient is > >actually > >> >a bit of a problematic term here, since it's really the on-path > >network > >> elements > >> >which consume the information. They aren't the intended recipient of > >> >the communication, they are the recipients of the signaling (of which > >> location > >> >is now a part). > >> > > >> >This is a bit confusing because it seems to be possible to include a > >> >"re-transmission allowed" rule with a value of "no" (intended to be > >> >consumed by the "intended recipient" of the underlying > >communication), > >> >while still wanting to allow the location to be passed along the > >path. > >> > > >> >>In fact, we would need to use > >> >>hop-by-hop security, with transitive trust. This is what the > >emergency > >> case > >> >>does, but it also allows no channel security if necessary (usually > >> meaning, > >> >>try it with TLS and if that fails, try again without TLS). > >> > > >> >While I certainly encourage hop-by-hop security, I don't think it > >really > >> >meets the geopriv privacy concerns. I think you have to have some > >way > >> of > >> >expressing "re-transmission for routing permitted" (and likely > >retention > >> >limited), since that is a separate statement. > >> > > >> >Just typing aloud here, but could we come up with a way to use an > >> >external ruleset to express this? With an embedded cid, that would > >> >not actually require dereferencing. > >> > Ted > >> > > >> > >> > >> > >> >We conclude that allowing hop-by-hop security for location based > >routing > >> >is acceptable, and Do Not Distribute DOES allow forwarding to a > >routing > >> >database, but requires that the proxy doing the location based route > >to > >> >remove the location it uses for that purpose. > >> > >> To reiterate this, I do not believe that this is sufficient; I think > >you > >> have to > >> have some way of saying "re-transmission for routing permitted" before > >> you meet the geopriv privacy concerns. > >> > >> >5. We proposed to create a parameter and a registry to distinguish > >> >multiple ways to dereference a location where HTTP(S) was the > >transport. > >> >Resolution of this issue depends on resolution of issue 6. > >> > >> I believe that an HTTP GET of a PIDF-LO object is a reasonable > >baseline. > >> Saying that other mechanisms should update this document with their > >> dereferencing mechanisms if they could be confused with the baseline > >> seems to me to be sufficient. I'm not sure a registry is needed. In > >> practice, > >> I don't think we would hit the interoperability problems often. These > >> days, > >> extensions to HTTP commonly use different mime types to indicate the > >> special > >> handling, and I expect anyone creating a more feature-rich > >dereferencing > >> mechanism built on HTTP would not end up using pidf-lo. > >> > >> That means the "uri confusion" aspects of the discussion are probably > >not > >> that severe. The only issue is if someone supports only the more > >feature- > >> rich > >> alternative and not a baseline GET of the pidf-lo. I think we should > >> discourage that, by establishing a real baseline. > >> > >> Note also that HTTP URIs don't indicate the HTTP Method directly; > >often > >> they > >> support multiple methods (e.g. HEAD and GET). > >> > >> >6. We proposed to allow sip/sips and pres: in the location header. I > >> >later speculated that if we allow this, it forms a simple way to do > >> >location-by-reference, and we could eliminate the raw HTTP(S) Get > >> >proposal, with the parameter and registry entirely. There was some > >list > >> >traffic in favor of this. Martin Thompson is skeptical that SIP > >> >Presence Subscribe/Notify is actually allowed as a geopriv "using > >> >protocol". Several of think that it is. If we don't get any more > >> >comments on this proposal, we will allow sip/sips and pres, not have > >any > >> >http(s) resolution text, and not propose a parameter and accompanying > >> >registry. > >> > >> I share some of Martin's skepticism here, but I won't fall on my sword > >> if the WG goes in this direction. > >> > >> Thanks for the clear set of issues and opportunity to comment, > >> > >> Ted Hardie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 17:08:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5U6e-0002f3-4Q; Tue, 25 Jul 2006 17:06:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5U6c-0002ev-8V for sip@ietf.org; Tue, 25 Jul 2006 17:06:18 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5U6b-0004qi-MA for sip@ietf.org; Tue, 25 Jul 2006 17:06:18 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G5U6S-0002bn-EF; Tue, 25 Jul 2006 16:06:09 -0500 From: "Brian Rosen" To: "'Jeroen van Bemmel'" , Subject: RE: [Sip] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 17:06:09 -0400 Message-ID: <020301c6b02e$2ac733c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawKRpqB68po2iUQ7uJUAaY1ud2BQAAtUWw In-Reply-To: <008c01c6b029$1b5bb320$31713b51@BEMBUSTER> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen I'm a big believer in location-by-value over location-by-reference, especially for the emergency case. You won't find me arguing for location- by-reference. However, there is clear sentiment to support it, and a requirement to support proxy insertion of location, which I also think is a bad idea. Given that we have to support proxy insertion, and the sentiment to support -by-reference, I'm leaning towards one mechanism. To be fair, whether you get location by value or by reference, the validity issues on the PIDF are the same. When you have a reference, you do not know for how long the reference is valid. When you place the call, you may get a "fresh" location before you place the call, or you may not. If you have to dereference it, at least there is an opportunity for the LIS to say "I have someone that wants this location now, I can give him my best current estimate of that location". I do worry quite a bit about proxy insertion of location and how the USERS's notion of access control will be honored and reflected in the ruleset. I think whether you get the value by location or by reference, the rules that are supposed to be in there should be the same, and will mean the same thing. I agree that you may want to send both a value and a reference for a case where there may be mobility. I think you must control both the integrity and the privacy of the location reference in the SIP header. The former is important to make sure that the PIDF, with its ruleset, is delivered intact. The latter is important to make sure the user's identity cannot be linked with his location if he wishes to do so. Access control at the LIS on a dereference may be another chance to control access. Brian > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Tuesday, July 25, 2006 4:30 PM > To: Brian Rosen; sip@ietf.org > Subject: Re: [Sip] Consensus on changes to location-conveyance > > Brian, > > Three more remarks: > > 1 - Location by value is much easier to get interoperable than location by > reference, also because the latter has many semantic issues (in addition > to > performance, chance at failure): > * When dereferencing, for what time instance do I get the location? > * if { moment of call }, how do you guarantee that the dereferenced source > will have exactly that information? > * if { moment of dereference }, for how long is the URI supposed / assumed > to be usable? > * how does the user control/limit access to that location information? > > All of the above is clear for location-by-value. It is therefore much > easier > to ensure privacy for that, in a way that is easily explained to the user: > either you give your location at that moment, or you dont. Period > > 2 - In particular for emergency scenarios, I think you would want both (by > value and by reference), even within the same request: rough location by > value (eg cell-id) could be used to route the call to the appropriate > emergency center, then a Location URI (provided in the same request) can > be > dereferenced from there, which may give a more precise location after some > time (say 10s of seconds). Moreover, the reference could be used to track > the location over time > > 3 Rather than relying on TLS for security of the location-user mapping, I > always assumed there would be requirements for access control at the > location server? To me requiring TLS is a definite way to ensure that this > will not see widespread use... > > Regards, > > Jeroen > > > ----- Original Message ----- > From: "Brian Rosen" > To: "'Jeroen van Bemmel'" ; > Sent: Tuesday, July 25, 2006 8:30 PM > Subject: RE: [Sip] Consensus on changes to location-conveyance > > > > Jeroen > > > > I've always disliked location-by-reference because it has delay, and > > introduces the possibility (in the emergency case especially) where the > > dereferencer has connectivity to the endpoint but not the LIS. > > > > The WG however, has consensus that these issues are not significant, and > > the > > benefits outweigh the problems. > > > > Having said that using a reference is NOT seen as a performance problem > > then > > it's not a performance problem, and you can't argue it's a use case. > > > > Agree that if the endpoint wants location to be removed after routing > > before > > forwarding, then it has to use by-reference. Don't see that as a > problem. > > > > Yes, TLS protects the URL, which is important, because anyone observing > > the > > SIP messaging can connect the identity of the SIP correspondent with the > > location (if it is allowed to dereference it), which is bad. > > > > Brian > > > >> -----Original Message----- > >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > >> Sent: Tuesday, July 25, 2006 2:14 PM > >> To: Brian Rosen; sip@ietf.org > >> Subject: Re: [Sip] Consensus on changes to location-conveyance > >> > >> Brian, > >> > >> Your point 4 below is a concrete use case for point 1 (location by > value > >> in > >> header). Using location for routing decisions benefits from quick > access, > >> a > >> lookup by reference introduces delay. > >> > >> If you want a proxy to remove the location info, you cannot put the > >> location > >> info in the body, because proxies are not allowed to modify that. So > you > >> are > >> left with location by reference. The use of TLS is then only to protect > >> this > >> URL? > >> > >> Regards, > >> > >> Jeroen > >> > >> ----- Original Message ----- > >> From: "Brian Rosen" > >> To: > >> Sent: Tuesday, July 25, 2006 7:41 PM > >> Subject: [Sip] Consensus on changes to location-conveyance > >> > >> > >> >I have put out a number of emails on proposed changes to location > >> > conveyance. Some of them have sparked a number of comments. My > >> > summary > >> > of > >> > consensus on these issues is: > >> > > >> > 1. We proposed to explicitly disallow use of a Data URI, which would > >> allow > >> > specification of a Location-by-value in a header. There was a lot of > >> list > >> > traffic on this, currently in the state where Keith asked for a real > >> > use > >> > case for it. So far, we don't see a use case that cannot be provided > >> > by > >> > location-by-reference in a header. If we don't get a good use case, > I > >> > think > >> > consensus is to disallow location-by-value in a header. > >> > > >> > 2. Dereferencing location-by-reference. We had initially proposed to > >> > document a process to use a raw HTTP(S) Get to dereference. There > was > >> > a > >> > lot > >> > of discussion, and then I made a new proposal, see item 6. > >> > > >> > 3. We proposed to allow a Reason header with a 424 Bad Location > >> response. > >> > This seems to be acceptable to the WG. Geopriv will create and > >> > populate > >> > the > >> > registry in a separate draft. > >> > > >> > 4. We proposed to explicitly allow hop-by-hop TLS security for > location > >> > when > >> > the endpoint wished to allow routing based on location. We further > >> > proposed > >> > to interpret "Do not Distribute" flags as allowing sending of the > >> location > >> > to the routing database (LoST for example). Hannes pointed out that > >> there > >> > was a proposal to allow two Location headers, one of which could be > >> > used > >> > for > >> > routing and another for onward forwarding to the recipient. Hannes' > >> > message > >> > seemed to agree that "Do not distribute" would allow sending of the > >> > location > >> > to the routing-by-location database, but would obligate the proxy > that > >> did > >> > that to remove the location before it forwarded the message. There > >> > were > >> > no > >> > other messages on this thread. We conclude that allowing hop-by-hop > >> > security for location based routing is acceptable, and Do Not > >> > Distribute > >> > DOES allow forwarding to a routing database, but requires that the > >> > proxy > >> > doing the location based route to remove the location it uses for > that > >> > purpose. > >> > > >> > 5. We proposed to create a parameter and a registry to distinguish > >> > multiple > >> > ways to dereference a location where HTTP(S) was the transport. > >> > Resolution > >> > of this issue depends on resolution of issue 6. > >> > > >> > 6. We proposed to allow sip/sips and pres: in the location header. I > >> > later > >> > speculated that if we allow this, it forms a simple way to do > >> > location-by-reference, and we could eliminate the raw HTTP(S) Get > >> > proposal, > >> > with the parameter and registry entirely. There was some list > traffic > >> in > >> > favor of this. Martin Thompson is skeptical that SIP Presence > >> > Subscribe/Notify is actually allowed as a geopriv "using protocol". > >> > Several > >> > of think that it is. If we don't get any more comments on this > >> proposal, > >> > we > >> > will allow sip/sips and pres, not have any http(s) resolution text, > and > >> > not > >> > propose a parameter and accompanying registry. > >> > > >> > If this does not reflect your position, please speak up now. > >> > > >> > Brian > >> > > >> > > >> > _______________________________________________ > >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> > This list is for NEW development of the core SIP Protocol > >> > Use sip-implementors@cs.columbia.edu for questions on current sip > >> > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 17:45:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5UgS-0000qF-QU; Tue, 25 Jul 2006 17:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5UgR-0000kA-6k for sip@ietf.org; Tue, 25 Jul 2006 17:43:19 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5UgO-0000aq-Ta for sip@ietf.org; Tue, 25 Jul 2006 17:43:19 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k6PLhFtA016111; Tue, 25 Jul 2006 16:43:15 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k6PLhBa26249; Tue, 25 Jul 2006 16:43:11 -0500 (CDT) Message-ID: <44C6906F.40802@lucent.com> Date: Tue, 25 Jul 2006 16:43:11 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Hitchhikers guide - when is it done? References: <44C65B13.5040803@cisco.com> In-Reply-To: <44C65B13.5040803@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry for being the voice out on the left field, but I think 1 is better. Once the 'core' documents have RFC numbers, it makes sense to go ahed and publish that as an Informational (maybe name it "A Hitchhikers Guide to SIP - Part 1: Core Specification"). Then deal with the current I-Ds and other work as a separate Informational, probably named "A Hitchhikers Guide to SIP - Part 2: Extensions". The first RFC will have an informative reference to the second to-be RFC, so readers can be warned that the document is split into to (plus the naming convention of the title is a clue). With Part 2 being in flux for a while, I would presume that it would be easier from a process point of view to rev a I-D than it is to obsolete or update a RFC. Plus there is some poetic justice in the SIP WG closing doors when the last RFC issued is one that (partially) summarizes what we have done as a WG. Too bad RFC number 4242 is already taken. Thanks. Jonathan Rosenberg wrote: > During the IETF meeting, I discussed the one current open issue in the > Hitchhikers guide. The issue is: when does the document finish? When do > we send to IESG to issue an RFC? > > There were two approaches: > > 1. split the document in two. One part contains only the core specs, and > issues relatively soon. The other part has everything else, and > basically ends up being the last RFC produced by the SIP WG before it > shuts its doors (which has always been 1.5 years from now for the last 5 > years). > > 2. keep it as one document. Issue an RFC at some point, and then revise > it a few times as needed. We need to decide when to issue it. > > > I'd like to propose option 2. I think people get more value from it as a > consolidated document. Furthermore, I'd propose that we send the > document to IESG for consideration as informational at the instant all > of the documents listed as 'core' have RFC numbers issued by RFC-ed. > > Comments? - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 18:16:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VB2-0000lQ-Ti; Tue, 25 Jul 2006 18:14:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VB1-0000kx-2U; Tue, 25 Jul 2006 18:14:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5S3K-0003iU-Om; Tue, 25 Jul 2006 14:54:46 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5Rud-0002zV-CX; Tue, 25 Jul 2006 14:45:48 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns4.neustar.com (Postfix) with ESMTP id 4A53A2AC25; Tue, 25 Jul 2006 18:45:17 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 14:45:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jul 2006 14:45:15 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcawFse8I7UwfX35RzK33ETYq9dzmgAAjLaQ From: "Rosen, Brian" To: "Ted Hardie" , X-OriginalArrivalTime: 25 Jul 2006 18:45:17.0031 (UTC) FILETIME=[78E15770:01C6B01A] X-Spam-Score: -4.9 (----) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Summarizing, you think hop-by-hop security (TLS) is acceptable when the location is sent for the purposes of location based routing, but you are not in favor of defining "retransmission=3Dno" to permit sending the location to the routing database (e.g. LoST). You want a more explicit permission. I don't think a cid: with a ruleset is acceptable, as it would not permit location by reference added by a proxy to specify this. If this is the consensus, I think we would have to add a bit to the PIDF to explicitly control this behavior. Why do you think we must specify an HTTP dereference procedure in this document? What is the purpose when the SIP based method is available? We had believed we had to have SOME method of dereferencing to make location-by-reference meaningful in the document. If we have one sip based method, we meet the requirement. Having more options, especially completely new HTTP based protocols IN THIS DOCUMENT seems unnecessary and unwise. For example, if we define such a protocol, it becomes a geopriv "using protocol" and needs an explicit analysis against the geopriv criteria. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Tuesday, July 25, 2006 2:19 PM > To: Rosen, Brian; sip@ietf.org > Cc: geopriv@ietf.org > Subject: Re: [Geopriv] Consensus on changes to location-conveyance >=20 > At 1:38 PM -0400 7/25/06, Rosen, Brian wrote: > >4. We proposed to explicitly allow hop-by-hop TLS security for location > >when the endpoint wished to allow routing based on location. We further > >proposed to interpret "Do not Distribute" flags as allowing sending of > >the location to the routing database (LoST for example). Hannes pointed > >out that there was a proposal to allow two Location headers, one of > >which could be used for routing and another for onward forwarding to the > >recipient. Hannes' message seemed to agree that "Do not distribute" > >would allow sending of the location to the routing-by-location database, > >but would obligate the proxy that did that to remove the location before > >it forwarded the message. There were no other messages on this thread. >=20 > Actually, I commented on the same problem, though it may have been > connected to one of the related threads; here's the text of that message: >=20 > >At 5:23 PM -0400 7/19/06, Brian Rosen wrote: > >>NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU REPLY, SEND IT > ONLY TO > >>GEOPRIV > >>However, this opens up the issue of geopriv privacy concerns because the > >>sender does not know the identity of the element (proxy) that will route > the > >>call using LoST. It may be that the UAC itself does this, but it may be > >>some other intermediary. > >> > >>If the identity of the intermediary is not known, then protecting the > >>location information becomes more difficult, because we cannot encrypt > using > >>keying material from the intended recipient. > > > >Just to mention this, it appears to also rule out the idea of encrypting > >with the user's key, since there is no way of knowing whether the > "intended > >recipient" has that key material either. Intended recipient is actually > >a bit of a problematic term here, since it's really the on-path network > elements > >which consume the information. They aren't the intended recipient of > >the communication, they are the recipients of the signaling (of which > location > >is now a part). > > > >This is a bit confusing because it seems to be possible to include a > >"re-transmission allowed" rule with a value of "no" (intended to be > >consumed by the "intended recipient" of the underlying communication), > >while still wanting to allow the location to be passed along the path. > > > >>In fact, we would need to use > >>hop-by-hop security, with transitive trust. This is what the emergency > case > >>does, but it also allows no channel security if necessary (usually > meaning, > >>try it with TLS and if that fails, try again without TLS). > > > >While I certainly encourage hop-by-hop security, I don't think it really > >meets the geopriv privacy concerns. I think you have to have some way > of > >expressing "re-transmission for routing permitted" (and likely retention > >limited), since that is a separate statement. > > > >Just typing aloud here, but could we come up with a way to use an > >external ruleset to express this? With an embedded cid, that would > >not actually require dereferencing. > > Ted > > >=20 >=20 >=20 > >We conclude that allowing hop-by-hop security for location based routing > >is acceptable, and Do Not Distribute DOES allow forwarding to a routing > >database, but requires that the proxy doing the location based route to > >remove the location it uses for that purpose. >=20 > To reiterate this, I do not believe that this is sufficient; I think you > have to > have some way of saying "re-transmission for routing permitted" before > you meet the geopriv privacy concerns. >=20 > >5. We proposed to create a parameter and a registry to distinguish > >multiple ways to dereference a location where HTTP(S) was the transport. > >Resolution of this issue depends on resolution of issue 6. >=20 > I believe that an HTTP GET of a PIDF-LO object is a reasonable baseline. > Saying that other mechanisms should update this document with their > dereferencing mechanisms if they could be confused with the baseline > seems to me to be sufficient. I'm not sure a registry is needed. In > practice, > I don't think we would hit the interoperability problems often. These > days, > extensions to HTTP commonly use different mime types to indicate the > special > handling, and I expect anyone creating a more feature-rich dereferencing > mechanism built on HTTP would not end up using pidf-lo. >=20 > That means the "uri confusion" aspects of the discussion are probably not > that severe. The only issue is if someone supports only the more feature- > rich > alternative and not a baseline GET of the pidf-lo. I think we should > discourage that, by establishing a real baseline. >=20 > Note also that HTTP URIs don't indicate the HTTP Method directly; often > they > support multiple methods (e.g. HEAD and GET). >=20 > >6. We proposed to allow sip/sips and pres: in the location header. I > >later speculated that if we allow this, it forms a simple way to do > >location-by-reference, and we could eliminate the raw HTTP(S) Get > >proposal, with the parameter and registry entirely. There was some list > >traffic in favor of this. Martin Thompson is skeptical that SIP > >Presence Subscribe/Notify is actually allowed as a geopriv "using > >protocol". Several of think that it is. If we don't get any more > >comments on this proposal, we will allow sip/sips and pres, not have any > >http(s) resolution text, and not propose a parameter and accompanying > >registry. >=20 > I share some of Martin's skepticism here, but I won't fall on my sword > if the WG goes in this direction. >=20 > Thanks for the clear set of issues and opportunity to comment, >=20 > Ted Hardie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 18:40:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VYV-0002NZ-37; Tue, 25 Jul 2006 18:39:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VYS-0002NR-SK; Tue, 25 Jul 2006 18:39:08 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5VYS-0005ka-Cb; Tue, 25 Jul 2006 18:39:08 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 17:39:08 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 25 Jul 2006 17:39:07 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 17:39:06 -0500 Message-ID: From: "Thomson, Martin" To: "Peterson, Jon" , "Andrew Newton" , "Rosen, Brian" Date: Tue, 25 Jul 2006 17:37:12 -0500 Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 25 Jul 2006 22:39:06.0364 (UTC) FILETIME=[2303ABC0:01C6B03B] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597054F4511@stntexch03.cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcawJZpkqbGyCVnSTue1IO2WT/AgKAAAR94gAATcdrA= X-Spam-Score: 0.5 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: sip@ietf.org, geopriv@ietf.org, Marc Linsner X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0748706261==" Errors-To: sip-bounces@ietf.org --===============0748706261== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message VGhpcyBtYWtlcyBzZW5zZS4gIEkgdGhpbmsgdGhhdCB0aGlzIHN1cHBvcnRzIEJyaWFuJ3Mgc3Vn Z2VzdGlvbi4gIEkgd2FzIGFnYWluc3QgYW55IHN5bnRhY3RpYyBjb25zdHJhaW50cywgYnV0IHdp bGwgYWNxdWllc2NlIGluIHRoZSBpbnRlcmVzdHMgb2YgcHJvZ3Jlc3MuDQoNCkxldCBpdCBiZSBz aXAvc2lwcy9wcmVzL2NpZC4NCg0KQ2hlZXJzLA0KTWFydGluDQoNCnAucy4gSSByZWdyZXQgdGhl IHBvc3NpYmlsaXR5IHRoYXQgdGhlIGNvbmNlcHQgb2YgYSByZWZlcmVuY2UgY291bGQgaGF2ZSBi ZWVuIHRhaW50ZWQgYnkgYXNzb2NpYXRpb24gLSBjZXJ0YWlubHksIHdlIGRpZCBub3QgdGhpbmsg dGhhdCB3ZSBoYWQgaW52ZW50ZWQgYW55dGhpbmcgbmV3Lg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IFBldGVyc29uLCBKb24gW21haWx0bzpqb24ucGV0ZXJzb25AbmV1 c3Rhci5iaXpdDQo+IFNlbnQ6IFdlZG5lc2RheSwgMjYgSnVseSAyMDA2IDY6NDIgQU0NCj4gVG86 IEFuZHJldyBOZXd0b247IFJvc2VuLCBCcmlhbg0KPiBDYzogc2lwQGlldGYub3JnOyBnZW9wcml2 QGlldGYub3JnOyBNYXJjIExpbnNuZXINCj4gU3ViamVjdDogUkU6IFtTaXBdIFJFOiBbR2VvcHJp dl0gQ29uc2Vuc3VzIG9uIGNoYW5nZXMgdG8gbG9jYXRpb24tDQo+IGNvbnZleWFuY2UNCj4gDQo+ IA0KPiBBcyBCcmlhbiBwb2ludHMgb3V0LCB0aGUgd2hvbGUgcG9pbnQgb2YgdXNpbmcgUElERiBm b3IgbG9jYXRpb24NCj4gaW5mb3JtYXRpb24gd2FzIHRoZSBzaW1pbGFyaXR5IG9mIHRoZSBlYXJs eSBkZWZpbmVkIHVzZSBjYXNlcyB0byB0aGUNCj4gcHJlc2VuY2UgYXJjaGl0ZWN0dXJlLiBUaGlz IGNlcnRhaW5seSBpbmNsdWRlZCB1c2UgY2FzZXMgaW4gd2hpY2ggb25lDQo+IHdhbnRlZCB0byBm ZXRjaCBvciBzdWJzY3JpYmUgdG8gbG9jYXRpb24gaW5mb3JtYXRpb24uIFRob3NlIG9wZXJhdGlv bnMNCj4gcmVxdWlyZSB0aGUgZXhpc3RlbmNlIG9mIGEgcmVmZXJlbmNlLCBhbmQgdGhhdCByZWZl cmVuY2Ugd2FzIGNvbW1vbmx5DQo+IGRlc2NyaWJlZCBhcyBhIFVSSSwgYXQgdGhlIHRpbWUuIExh dGVseSwgSSB0aGluayB0aGUgaWRlYSBvZiBoYXZpbmcgYSBVUkkNCj4gcG9pbnRpbmcgdG8gbG9j YXRpb24gaW5mb3JtYXRpb24gaGFzIGJlY29tZSBhc3NvY2lhdGVkIHdpdGggYSBzcGVjaWZpYw0K PiBwcm9wb3NhbCAoaS5lLiBIRUxEKSwgYnV0IGNsZWFybHkgUkZDNDA3OSBza2V0Y2hlZCBvdXQg YW4gYXJjaGl0ZWN0dXJlIGZvcg0KPiB1c2luZyBwcmVzZW5jZSB0byBhY3F1aXJlIGxvY2F0aW9u IGluZm9ybWF0aW9uIGFuZCBpdCBzcGVjaWZpY2FsbHkNCj4gbWVudGlvbnMgVVJJcyBhcyBhIHdh eSB0byByZWZlciB0byBwcmVzZW5jZS4NCj4gDQo+IFRoZXJlIGlzIG5vICJoaWRkZW4gbWFnaWMi IGluIGFueSBvZiB0aGlzLiBTdWJzY3JpYmluZyB0byBwcmVzZW5jZSwgYW5kDQo+IHVzaW5nIFVS SXMgdG8gaW5kaWNhdGUgcHJlc2VuY2UgaW5mb3JtYXRpb24sIGlzIGV4aGF1c3RpdmVseSBzcGVj aWZpZWQgZm9yDQo+IFNJUC4gUElERi1MTyB3YXMgZGVzaWduZWQgdG8gcmV1c2UgYWxsIG9mIHRo YXQgd29yayBhbmQgc3BlY2lmaWNhbGx5IG5vdA0KPiB0byByZXF1aXJlIHVzIHRvIGdvIG91dCBh bmQgcmVpbnZlbnQgZXZlcnl0aGluZyBpbiBvcmRlciB0byBiZSBhYmxlIHRvDQo+IHJlZmVyIHRv IGxvY2F0aW9uIGluZm9ybWF0aW9uIG91dCBpbiB0aGUgbmV0d29yay4NCj4gDQo+IEJhc2ljYWxs eSwgSSBzdXBwb3J0IHRoZSBkaXJlY3Rpb24gcmU6IGJ1bGxldCA2LiBJIG1pZ2h0IGZ1cnRoZXIg c3VnZ2VzdA0KPiB0aGF0IHRoZSBDSUQgVVJJIHNjaGVtZSBiZSBwZXJtaXR0ZWQgaW4gdGhlIExv Y2F0aW9uIGhlYWRlciwgaW4gb3JkZXIgdG8NCj4gYmUgYWJsZSB0byByZWZlciB0byBNSU1FIGJv ZGllcyBpbmNsdWRlZCBpbiBTSVAgbWVzc2FnZXMuIEknbSBhbHNvDQo+IG5ldXRyYWwvZmF2b3Jh YmxlIG9uIHVzaW5nIEhUVFAgR0VULiBCdXQgSSB0aGluayBlaXRoZXIgb2YgdGhlc2UgVVJJDQo+ IHNjaGVtZXMgYW5kIHRoZWlyIHVzYWdlIGluIHRoZSBMb2NhdGlvbiBoZWFkZXIgY291bGQganVz dCBhcyB3ZWxsIGJlDQo+IGRlc2NyaWJlZCBpbiBzdWJzZXF1ZW50IGRvY3VtZW50cy4NCj4gDQo+ IEpvbiBQZXRlcnNvbg0KPiBOZXVTdGFyLCBJbmMsDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gRnJvbTogQW5kcmV3IE5ld3RvbiBbbWFpbHRvOmFuZHlAaHhyLnVzXQ0K PiA+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMjUsIDIwMDYgMTowNSBQTQ0KPiA+IFRvOiBSb3Nlbiwg QnJpYW4NCj4gPiBDYzogc2lwQGlldGYub3JnOyBnZW9wcml2QGlldGYub3JnOyBNYXJjIExpbnNu ZXINCj4gPiBTdWJqZWN0OiBSZTogW1NpcF0gUkU6IFtHZW9wcml2XSBDb25zZW5zdXMgb24gY2hh bmdlcyB0bw0KPiA+IGxvY2F0aW9uLWNvbnZleWFuY2UNCj4gPg0KPiA+DQo+ID4gRm9yIHRoZSBy ZWNvcmQsIEkgYWdyZWUgd2l0aCBCcmlhbi4NCj4gPg0KPiA+IC1hbmR5DQo+ID4NCj4gPiBPbiBK dWwgMjUsIDIwMDYsIGF0IDM6NTAgUE0sIFJvc2VuLCBCcmlhbiB3cm90ZToNCj4gPg0KPiA+ID4g V2hlbiB0aGUgb3JpZ2luYWwgUElERi1MTyBSRkMgY2FtZSBvdXQsIGxvY2F0aW9uLWJ5LXJlZmVy ZW5jZSB3YXMNCj4gPiA+IGRlZmluZWQuDQo+ID4gPg0KPiA+ID4gWW91IGhhdmUgYSBVUkkuICBZ b3UgY2FuIGV4Y2hhbmdlIHRoZSBVUkkgZm9yIGxvY2F0aW9uLiAgVGhlcmUgaXMgYQ0KPiA+ID4g cHJvdG9jb2wgZGVmaW5lZCBmb3IgdGhhdCBwdXJwb3NlIChTSVAgU1VCU0NSSUJFKS4gIFRoYXQg aXMNCj4gPiA+IGxvY2F0aW9uIGJ5DQo+ID4gPiByZWZlcmVuY2UuICBJdCBhbHNvIHNlcnZlcyBh cyB0aGUgbG9jYXRpb24gdXBkYXRlIG1lY2hhbmlzbSwgY2xlYXJseQ0KPiA+ID4gc29tZXRoaW5n IHdlIG5lZWQuDQo+ID4gPg0KPiA+ID4gU29tZSBkYXksIHRoZXJlIG1heSBiZSBvdGhlciBsb2Nh dGlvbiBVUkkgcmVmZXJlbmNlcy4gIFdlIGRvbid0DQo+ID4gPiBuZWVkIHRvDQo+ID4gPiBjb3Zl ciB0aGVtIGluIHRoaXMgZHJhZnQuICBUaGUgYmFzaWMgbG9jYXRpb24gYnkgcmVmZXJlbmNlIGhv cnNlIGhhcw0KPiA+ID4gbGVmdCB0aGUgYmFybi4gIFdlcmUgeW91IHBsYW5uaW5nIG9uIGNyZWF0 aW5nIGFuIFJGQyB0aGF0DQo+ID4gc3BlY2lmaWNhbGx5DQo+ID4gPiBkaXNhbGxvd3MgYSBTdWJz Y3JpYmUgb24gYSBzaXAvc2lwcy9wcmVzIFVSSSB0byBnZXQgbG9jYXRpb24/DQo+ID4gPiBUSEFU IFdBUw0KPiA+ID4gVEhFIFBPSU5UIE9GIE1BS0lORyBJVCBQQVJUIE9GIEEgUElERi4NCj4gPiA+ DQo+ID4gPiBJIGRvIHRoaW5rIHRoZXJlIGlzIHNvbWUgdmFsdWUgaW4gZGVmaW5pbmcgYSB3YXkg dG8gZXhwcmVzcyBhDQo+ID4gPiBsb2NhdGlvbi1ieS1yZWZlcmVuY2UgYWthIHByZXNlbmNlIFVS SSB3aGljaCBpcyBub3QganVzdCB0aGUgQW9SLg0KPiA+ID4gVGhhdA0KPiA+ID4gaXMgb25lIHJl YXNvbiB3aHkgSSB3YW50IHRvIGRlZmluZSB0aGUgTG9jYXRpb24gVVJJIGFzIGJlaW5nIGFibGUg dG8NCj4gPiA+IGNvbnRhaW4gYSBzaXAvc2lwcy9wcmVzIFVSSS4gIFRoZSBwdXJwb3NlIGlzIHRv IGFsbG93IGEgVUEgb3IgYQ0KPiA+ID4gcHJveHkgdG8NCj4gPiA+IGluc2VydCBsb2NhdGlvbiB3 aGVyZSB0aGVyZSBpcyBubyBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZQ0KPiA+IGlkZW50aXR5IG9m DQo+ID4gPiB0aGUgU0lQIHVzZXIgYW5kIHRoZSBsb2NhdGlvbi4NCj4gPiA+DQo+ID4gPiBCdXQg dGhhdCBpcyBhbGwgSSB0aGluayB3ZSBuZWVkLg0KPiA+ID4NCj4gPiA+IFdlIGhhdmUgYSByZXF1 aXJlbWVudCBmb3IgcHJveHkgaW5zZXJ0aW9uIG9mIGxvY2F0aW9uLiAgSWYNCj4gPiB3ZSBkaXNh bGxvdw0KPiA+ID4gbG9jYXRpb24tYnktcmVmZXJlbmNlICh3aGljaCBJIHRoaW5rIGlzIGEgZ29v ZCBpZGVhIGluIGdlbmVyYWwsIGJ1dA0KPiA+ID4gZnV0aWxlIGluIHByYWN0aWNlKSwgdGhlbiB3 ZSB3b3VsZCBuZWVkIHNvbWV0aGluZyBsaWtlIHRoZQ0KPiA+IERhdGEgVVJJIHRvDQo+ID4gPiBz dXBwb3J0IGxvY2F0aW9uIGluc2VydGlvbiBieSBwcm94eS4gIElmIHdlIERPIGFsbG93DQo+ID4g PiBsb2NhdGlvbi1ieS1yZWZlcmVuY2UsIHRoZW4gaXQgYWxzbyBzZXJ2ZXMgdG8gbWVldCB0aGUg bG9jYXRpb24NCj4gPiA+IGluc2VydGlvbiBieSBwcm94eSByZXF1aXJlbWVudCwgYW5kIHdlIGRv bid0IG5lZWQgdGhlIERhdGENCj4gPiBVUkkuICBXZSdyZQ0KPiA+ID4gbG9va2luZyBmb3IgYSB1 c2UgY2FzZSB3aGljaCByZXF1aXJlcyBwcm94eSBpbnNlcnRpb24gYnkgdmFsdWUsIGJ1dA0KPiA+ ID4gaGF2ZW4ndCBoZWFyZCBvbmUgeWV0Lg0KPiA+ID4NCj4gPiA+IFlvdSBjYW4gbWFrZSBhbiBh cmd1bWVudCB0aGF0IHlvdSBjYW4gdGFrZSB0aGUgRnJvbTosIGFzc3VtZSBpdCdzIGFuDQo+ID4g PiBBb1IsIGFuZCBTVUJTQ1JJQkUgdG8gdGhlIHByZXNlbmNlIG9mIHRoYXQgQW9SIHRvIGdldCBs b2NhdGlvbiwNCj4gPiA+IHRodXMgbm90DQo+ID4gPiBuZWVkaW5nIGEgTG9jYXRpb24gaGVhZGVy LiAgSSByZWFsbHkgdGhpbmsgbGV0dGluZyB0aGUNCj4gPiBMb2NhdGlvbiBoZWFkZXINCj4gPiA+ IHNwZWNpZnkgYW4gYWx0ZXJuYXRlIHByZXNlbmNlIFVSSSBpcyBhIGdvb2QgaWRlYS4NCj4gPiA+ DQo+ID4gPiBCcmlhbg0KPiA+ID4NCj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+ID4+IEZyb206IE1hcmMgTGluc25lciBbbWFpbHRvOm1saW5zbmVyQGNpc2NvLmNvbV0NCj4g PiA+PiBTZW50OiBUdWVzZGF5LCBKdWx5IDI1LCAyMDA2IDM6MjkgUE0NCj4gPiA+PiBUbzogUm9z ZW4sIEJyaWFuOyBzaXBAaWV0Zi5vcmcNCj4gPiA+PiBDYzogZ2VvcHJpdkBpZXRmLm9yZw0KPiA+ ID4+IFN1YmplY3Q6IFJFOiBbR2VvcHJpdl0gQ29uc2Vuc3VzIG9uIGNoYW5nZXMgdG8gbG9jYXRp b24tY29udmV5YW5jZQ0KPiA+ID4+DQo+ID4gPj4gSW4tbGluZS4uLi4uDQo+ID4gPj4NCj4gPiA+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+Pj4gRnJvbTogUm9zZW4sIEJyaWFu IFttYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXpdDQo+ID4gPj4+IFNlbnQ6IFR1ZXNkYXks IEp1bHkgMjUsIDIwMDYgMTozOCBQTQ0KPiA+ID4+PiBUbzogc2lwQGlldGYub3JnDQo+ID4gPj4+ IENjOiBnZW9wcml2QGlldGYub3JnDQo+ID4gPj4+IFN1YmplY3Q6IFtHZW9wcml2XSBDb25zZW5z dXMgb24gY2hhbmdlcyB0byBsb2NhdGlvbi1jb252ZXlhbmNlDQo+ID4gPj4+DQo+ID4gPj4+IEkg aGF2ZSBwdXQgb3V0IGEgbnVtYmVyIG9mIGVtYWlscyBvbiBwcm9wb3NlZCBjaGFuZ2VzIHRvDQo+ ID4gPj4+IGxvY2F0aW9uIGNvbnZleWFuY2UuICBTb21lIG9mIHRoZW0gaGF2ZSBzcGFya2VkIGEg bnVtYmVyIG9mDQo+ID4gPj4+IGNvbW1lbnRzLiAgTXkgc3VtbWFyeSBvZiBjb25zZW5zdXMgb24g dGhlc2UgaXNzdWVzIGlzOg0KPiA+ID4+Pg0KPiA+ID4+PiAxLiBXZSBwcm9wb3NlZCB0byBleHBs aWNpdGx5IGRpc2FsbG93IHVzZSBvZiBhIERhdGEgVVJJLA0KPiA+ID4+PiB3aGljaCB3b3VsZCBh bGxvdyBzcGVjaWZpY2F0aW9uIG9mIGEgTG9jYXRpb24tYnktdmFsdWUgaW4gYQ0KPiA+ID4+PiBo ZWFkZXIuICBUaGVyZSB3YXMgYSBsb3Qgb2YgbGlzdCB0cmFmZmljIG9uIHRoaXMsIGN1cnJlbnRs eQ0KPiA+ID4+PiBpbiB0aGUgc3RhdGUgd2hlcmUgS2VpdGggYXNrZWQgZm9yIGEgcmVhbCB1c2Ug Y2FzZSBmb3IgaXQuDQo+ID4gPj4+IFNvIGZhciwgd2UgZG9uJ3Qgc2VlIGEgdXNlIGNhc2UgdGhh dCBjYW5ub3QgYmUgcHJvdmlkZWQgYnkNCj4gPiA+Pj4gbG9jYXRpb24tYnktcmVmZXJlbmNlIGlu IGEgaGVhZGVyLiAgSWYgd2UgZG9uJ3QgZ2V0IGEgZ29vZA0KPiA+ID4+PiB1c2UgY2FzZSwgSSB0 aGluayBjb25zZW5zdXMgaXMgdG8gZGlzYWxsb3cgbG9jYXRpb24tYnktdmFsdWUNCj4gPiA+Pj4g aW4gYSBoZWFkZXIuDQo+ID4gPj4+DQo+ID4gPj4NCj4gPiA+PiBJIHNlZSBhIHByb2JsZW0gaGVy ZS4gIExvY2F0aW9uLWJ5LXJlZmVyZW5jZSBpcyBub3RoaW5nIG1vcmUgdGhhbg0KPiA+ID4gJ21h Z2ljDQo+ID4gPj4gaGFwcGVucyBoZXJlJyEgIFBsZWFzZSBwb2ludCB0byBhIHdnIGl0ZW0gZG9j dW1lbnRpbmcgdGhlDQo+ID4gPj4gbG9jYXRpb24tYnktcmVmZXJlbmNlIG1lY2hhbmlzbS4gIEhv dyBjYW4geW91IHN0YXRlIHRoZQ0KPiA+ID4+IGxvY2F0aW9uLWJ5LXJlZmVyZW5jZSB3aWxsIGNv dmVyIGFsbCB0aGUgdXNlIGNhc2VzIHRoYXQNCj4gPiB0aGUgRGF0YSBVUkkNCj4gPiA+IHdvdWxk DQo+ID4gPj4gd2hlbiBsb2NhdGlvbi1ieS1yZWZlcmVuY2UgaGFzbid0IGV2ZW4gYmVlbiBkZWZp bmVkDQo+ID4gYW55d2hlcmU/ICBZb3UncmUNCj4gPiA+PiBsb2FkaW5nIHVwIHRoZSBtYWdpYyB3 aXRoIGEgbG90IG9mIGFzc3VtcHRpb25zLiAgTG9jYXRpb24tYnktDQo+ID4gPj4gcmVmZXJlbmNl DQo+ID4gPiBpcw0KPiA+ID4+IGFuDQo+ID4gPj4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uIGFzIGEg c29sdXRpb24gdG8gYSBzZXQgb2YgcmVxdWlyZW1lbnRzIHRoYXQNCj4gPiA+IGhhdmVuJ3QNCj4g PiA+PiBiZWVuIGZsZXNoZWQtb3V0IGluIGdlb3ByaXYuDQo+ID4gPj4NCj4gPiA+PiBJIGJlbGll dmUgdGhhdCBIZW5uaW5nL0hhbm5lcyBhbHNvIHJlY29nbml6ZWQgdGhpcyBpc3N1ZSwgaGVuY2Ug dGhlDQo+ID4gPj4gc3VnZ2VzdGlvbiBvZiBhIERhdGEgVVJJLiAgRGlzbWlzc2luZyB0aGlzIHN1 Z2dlc3Rpb24gYmFzZWQgb24gYW4NCj4gPiA+IGFscmVhZHkNCj4gPiA+PiBhY2NlcHRlZCBub24t ZXhpc3RlbnQgbWVjaGFuaXNtIHNlZW1zIGxpa2UgZ2V0dGluZyB0aGUNCj4gPiBjYXJ0IGJlZm9y ZQ0KPiA+ID4+IHRoZQ0KPiA+ID4+IGhvcnNlLg0KPiA+ID4+DQo+ID4gPj4gLi4uLi4uLi4uLnNu aXANCj4gPiA+Pg0KPiA+ID4+PiA2LiBXZSBwcm9wb3NlZCB0byBhbGxvdyBzaXAvc2lwcyBhbmQg cHJlczogaW4gdGhlIGxvY2F0aW9uDQo+ID4gPj4+IGhlYWRlci4gIEkgbGF0ZXIgc3BlY3VsYXRl ZCB0aGF0IGlmIHdlIGFsbG93IHRoaXMsIGl0IGZvcm1zIGENCj4gPiA+Pj4gc2ltcGxlIHdheSB0 byBkbyBsb2NhdGlvbi1ieS1yZWZlcmVuY2UsIGFuZCB3ZSBjb3VsZA0KPiA+ID4+PiBlbGltaW5h dGUgdGhlIHJhdyBIVFRQKFMpIEdldCBwcm9wb3NhbCwgd2l0aCB0aGUgcGFyYW1ldGVyDQo+ID4g Pj4+IGFuZCByZWdpc3RyeSBlbnRpcmVseS4gIFRoZXJlIHdhcyBzb21lIGxpc3QgdHJhZmZpYyBp biBmYXZvcg0KPiA+ID4+PiBvZiB0aGlzLiAgTWFydGluIFRob21wc29uIGlzIHNrZXB0aWNhbCB0 aGF0IFNJUCBQcmVzZW5jZQ0KPiA+ID4+PiBTdWJzY3JpYmUvTm90aWZ5IGlzIGFjdHVhbGx5IGFs bG93ZWQgYXMgYSBnZW9wcml2ICJ1c2luZw0KPiA+ID4+PiBwcm90b2NvbCIuICBTZXZlcmFsIG9m IHRoaW5rIHRoYXQgaXQgaXMuICBJZiB3ZSBkb24ndCBnZXQgYW55DQo+ID4gPj4+IG1vcmUgY29t bWVudHMgb24gdGhpcyBwcm9wb3NhbCwgd2Ugd2lsbCBhbGxvdyBzaXAvc2lwcyBhbmQNCj4gPiA+ Pj4gcHJlcywgbm90IGhhdmUgYW55DQo+ID4gPj4+IGh0dHAocykgcmVzb2x1dGlvbiB0ZXh0LCBh bmQgbm90IHByb3Bvc2UgYSBwYXJhbWV0ZXIgYW5kDQo+ID4gPj4+IGFjY29tcGFueWluZyByZWdp c3RyeS4NCj4gPiA+Pg0KPiA+ID4+IEkgY2VydGFpbmx5IHRoaW5rIGl0J3MgbW9yZSBwcnVkZW50 IHRvIGRlZmluZSB0aGUgZGVyZWZlcmVuY2luZw0KPiA+ID4gbWVjaGFuaXNtDQo+ID4gPj4gcHJp b3IgdG8gbWFraW5nIGNsYWltcyBhYm91dCB0aGUgcHJvdG9jb2wuDQo+ID4gPj4NCj4gPiA+PiBE byBJIGJlbGlldmUgbG9jYXRpb24tYnktcmVmZXJlbmNlIHdpbGwgaGFwcGVuPyAgUHJvYmFibHks DQo+ID4gYnV0IG1ha2luZw0KPiA+ID4+IGFzc3VtcHRpb25zIGFib3V0IHRoZSBtZWNoYW5pc20g bm93IGlzIHF1aXRlIHByZW1hdHVyZS4NCj4gPiA+Pg0KPiA+ID4+IC1NYXJjLQ0KPiA+ID4+DQo+ ID4gPj4+DQo+ID4gPj4+IElmIHRoaXMgZG9lcyBub3QgcmVmbGVjdCB5b3VyIHBvc2l0aW9uLCBw bGVhc2Ugc3BlYWsgdXAgbm93Lg0KPiA+ID4+Pg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBTaXAgbWFpbGluZyBsaXN0 ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXANCj4gPiA+IFRoaXMg bGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbA0KPiA+ ID4gVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24g Y3VycmVudCBzaXANCj4gPiA+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1l bnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBHZW9wcml2IG1haWxpbmcg bGlzdA0KPiA+IEdlb3ByaXZAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9nZW9wcml2DQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+IEdlb3By aXZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2Vv cHJpdg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVz c2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFp biBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRp b24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0 aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0= --===============0748706261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0748706261==-- From sip-bounces@ietf.org Tue Jul 25 18:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VkR-0003eb-LF; Tue, 25 Jul 2006 18:51:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VkQ-0003eD-Fz; Tue, 25 Jul 2006 18:51:30 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5VkP-0001O4-SW; Tue, 25 Jul 2006 18:51:30 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G5VkD-00009Z-2F; Tue, 25 Jul 2006 17:51:18 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "Peterson, Jon" , "'Andrew Newton'" , "Rosen, Brian" Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 18:51:21 -0400 Message-ID: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawJZpkqbGyCVnSTue1IO2WT/AgKAAAR94gAAFPWjAAA+Kk4A== In-Reply-To: <00fa01c6b038$1e37fa40$1f0d0d0a@amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So, you are arguing against proxy insertion of a location-by-reference? You don't have a problem with UA insertion of location-by-reference in a Location header? Agree that Location insertion by proxy could assume an INVITE arriving at a proxy without any location. I've always had a problem with proxy insertion of location because I am worried that proxies will do this without regard to user's wishes. In an emergency case, however, there are no such worries. I don't see any difference between by-value and by-reference. Proxies may disregard advice we supply, but Location URIs in Location headers probably should not have any user identification information in either the URI itself, or the resulting PIDF. If such information is desired, use the AoR. De-referencing should always be subject to user rulesets, and would not be any different than by-value except the obvious issue that the owners of the proxy may not provide the user with the facilities to control the ruleset, my original worry. Would you not agree that if a proxy is allowed to insert location-by-value, the concerns would be the same? Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Tuesday, July 25, 2006 6:17 PM > To: 'Peterson, Jon'; 'Andrew Newton'; 'Rosen, Brian' > Cc: sip@ietf.org; geopriv@ietf.org > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location- > conveyance > > I have no problem with pidf/pidf-lo/presence. > > I have no problem with a ua placing a uri pointing to their presence > service > in a header of a sip invite. > > Context check: We're discussing a sip invite (assumed pointed to > emergency > service) that arrives at a proxy with zero location information. > > I'm the only one that has a problem with any (visited) proxy/LIS creating > a > uri that can be de-referenced by anyone without regard to user > security/privacy rules? > > -Marc- > > > > > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Tuesday, July 25, 2006 4:42 PM > > To: Andrew Newton; Rosen, Brian > > Cc: sip@ietf.org; geopriv@ietf.org; Marc Linsner > > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to > > location-conveyance > > > > > > As Brian points out, the whole point of using PIDF for > > location information was the similarity of the early defined > > use cases to the presence architecture. This certainly > > included use cases in which one wanted to fetch or subscribe > > to location information. Those operations require the > > existence of a reference, and that reference was commonly > > described as a URI, at the time. Lately, I think the idea of > > having a URI pointing to location information has become > > associated with a specific proposal (i.e. HELD), but clearly > > RFC4079 sketched out an architecture for using presence to > > acquire location information and it specifically mentions > > URIs as a way to refer to presence. > > > > There is no "hidden magic" in any of this. Subscribing to > > presence, and using URIs to indicate presence information, is > > exhaustively specified for SIP. PIDF-LO was designed to reuse > > all of that work and specifically not to require us to go out > > and reinvent everything in order to be able to refer to > > location information out in the network. > > > > Basically, I support the direction re: bullet 6. I might > > further suggest that the CID URI scheme be permitted in the > > Location header, in order to be able to refer to MIME bodies > > included in SIP messages. I'm also neutral/favorable on using > > HTTP GET. But I think either of these URI schemes and their > > usage in the Location header could just as well be described > > in subsequent documents. > > > > Jon Peterson > > NeuStar, Inc, > > > > > -----Original Message----- > > > From: Andrew Newton [mailto:andy@hxr.us] > > > Sent: Tuesday, July 25, 2006 1:05 PM > > > To: Rosen, Brian > > > Cc: sip@ietf.org; geopriv@ietf.org; Marc Linsner > > > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to > > > location-conveyance > > > > > > > > > For the record, I agree with Brian. > > > > > > -andy > > > > > > On Jul 25, 2006, at 3:50 PM, Rosen, Brian wrote: > > > > > > > When the original PIDF-LO RFC came out, location-by-reference was > > > > defined. > > > > > > > > You have a URI. You can exchange the URI for location. > > There is a > > > > protocol defined for that purpose (SIP SUBSCRIBE). That > > is location > > > > by reference. It also serves as the location update mechanism, > > > > clearly something we need. > > > > > > > > Some day, there may be other location URI references. We > > don't need > > > > to cover them in this draft. The basic location by > > reference horse > > > > has left the barn. Were you planning on creating an RFC that > > > specifically > > > > disallows a Subscribe on a sip/sips/pres URI to get location? > > > > THAT WAS > > > > THE POINT OF MAKING IT PART OF A PIDF. > > > > > > > > I do think there is some value in defining a way to express a > > > > location-by-reference aka presence URI which is not just > > the AoR. > > > > That > > > > is one reason why I want to define the Location URI as > > being able to > > > > contain a sip/sips/pres URI. The purpose is to allow a UA or a > > > > proxy to insert location where there is no association between the > > > identity of > > > > the SIP user and the location. > > > > > > > > But that is all I think we need. > > > > > > > > We have a requirement for proxy insertion of location. If > > > we disallow > > > > location-by-reference (which I think is a good idea in > > general, but > > > > futile in practice), then we would need something like the > > > Data URI to > > > > support location insertion by proxy. If we DO allow > > > > location-by-reference, then it also serves to meet the location > > > > insertion by proxy requirement, and we don't need the Data > > > URI. We're > > > > looking for a use case which requires proxy insertion by > > value, but > > > > haven't heard one yet. > > > > > > > > You can make an argument that you can take the From:, > > assume it's an > > > > AoR, and SUBSCRIBE to the presence of that AoR to get > > location, thus > > > > not needing a Location header. I really think letting the > > > Location header > > > > specify an alternate presence URI is a good idea. > > > > > > > > Brian > > > > > > > >> -----Original Message----- > > > >> From: Marc Linsner [mailto:mlinsner@cisco.com] > > > >> Sent: Tuesday, July 25, 2006 3:29 PM > > > >> To: Rosen, Brian; sip@ietf.org > > > >> Cc: geopriv@ietf.org > > > >> Subject: RE: [Geopriv] Consensus on changes to > > location-conveyance > > > >> > > > >> In-line..... > > > >> > > > >>> -----Original Message----- > > > >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > >>> Sent: Tuesday, July 25, 2006 1:38 PM > > > >>> To: sip@ietf.org > > > >>> Cc: geopriv@ietf.org > > > >>> Subject: [Geopriv] Consensus on changes to location-conveyance > > > >>> > > > >>> I have put out a number of emails on proposed changes > > to location > > > >>> conveyance. Some of them have sparked a number of > > comments. My > > > >>> summary of consensus on these issues is: > > > >>> > > > >>> 1. We proposed to explicitly disallow use of a Data URI, which > > > >>> would allow specification of a Location-by-value in a header. > > > >>> There was a lot of list traffic on this, currently in the state > > > >>> where Keith asked for a real use case for it. > > > >>> So far, we don't see a use case that cannot be provided by > > > >>> location-by-reference in a header. If we don't get a good use > > > >>> case, I think consensus is to disallow location-by-value in a > > > >>> header. > > > >>> > > > >> > > > >> I see a problem here. Location-by-reference is nothing more than > > > > 'magic > > > >> happens here'! Please point to a wg item documenting the > > > >> location-by-reference mechanism. How can you state the > > > >> location-by-reference will cover all the use cases that > > > the Data URI > > > > would > > > >> when location-by-reference hasn't even been defined > > > anywhere? You're > > > >> loading up the magic with a lot of assumptions. Location-by- > > > >> reference > > > > is > > > >> an > > > >> individual submission as a solution to a set of requirements that > > > > haven't > > > >> been fleshed-out in geopriv. > > > >> > > > >> I believe that Henning/Hannes also recognized this > > issue, hence the > > > >> suggestion of a Data URI. Dismissing this suggestion based on an > > > > already > > > >> accepted non-existent mechanism seems like getting the > > > cart before > > > >> the > > > >> horse. > > > >> > > > >> ..........snip > > > >> > > > >>> 6. We proposed to allow sip/sips and pres: in the > > location header. > > > >>> I later speculated that if we allow this, it forms a > > simple way to > > > >>> do location-by-reference, and we could eliminate the > > raw HTTP(S) > > > >>> Get proposal, with the parameter and registry entirely. > > There was > > > >>> some list traffic in favor of this. Martin Thompson is > > skeptical > > > >>> that SIP Presence Subscribe/Notify is actually allowed as a > > > >>> geopriv "using protocol". Several of think that it is. If we > > > >>> don't get any more comments on this proposal, we will allow > > > >>> sip/sips and pres, not have any > > > >>> http(s) resolution text, and not propose a parameter and > > > >>> accompanying registry. > > > >> > > > >> I certainly think it's more prudent to define the dereferencing > > > > mechanism > > > >> prior to making claims about the protocol. > > > >> > > > >> Do I believe location-by-reference will happen? Probably, > > > but making > > > >> assumptions about the mechanism now is quite premature. > > > >> > > > >> -Marc- > > > >> > > > >>> > > > >>> If this does not reflect your position, please speak up now. > > > >>> > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use > > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 18:58:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Vpe-0006I2-UW; Tue, 25 Jul 2006 18:56:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Vpc-00060d-CL; Tue, 25 Jul 2006 18:56:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5UDX-0005ju-B5; Tue, 25 Jul 2006 17:13:27 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5U9x-0006pJ-6C; Tue, 25 Jul 2006 17:09:47 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns3.neustar.com (Postfix) with ESMTP id EB81517599; Tue, 25 Jul 2006 21:09:14 +0000 (GMT) Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 17:09:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jul 2006 17:09:14 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F4512@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcawFslQZEnmjq5oTha1drXGXdgmHQAE50eQ From: "Peterson, Jon" To: "Ted Hardie" , "Rosen, Brian" , X-OriginalArrivalTime: 25 Jul 2006 21:09:14.0538 (UTC) FILETIME=[953C50A0:01C6B02E] X-Spam-Score: -5.9 (-----) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A couple notes on the whole "Do not Distribute" flag and its meaning in = a SIP context. Firstly, I think it's obligatory to flex the muscles of location = by-reference in response to this. When you send only a reference to = location information in an INVITE, that INVITE is not sharing the = location information with routing entities, is not a using protocol, and = is not "distributing" location information in any sense. Any routing = entity that dereferences the URI, and attempts to acquire location = information, can be individually authorized by the Location Server, and = the protocol over which location information is transmitted to those = entities (be it SIP NOTIFYs or whatever) is the using protocol, and is = distributing presence information. The entities that receive PIDF-LO = through that mechanism are bound not to retransmit it by the "Do not = Distribute" flag, but can use it for their personal consumption to make = decisions. In short, my contention would be that nothing is broken in = this case. So, what if you're using location by-value? Well, if you can use = encryption, then "Do not Distribute" still has some plausible = applicability. Of course, encrypting the PIDF-LO object is cumbersome, = and you have to be certain to whom you are encrypting it, but I don't = think the PIDF-LO can be said to have been "distributed" to anyone that = can't even inspect it. They're just relaying a closed envelope to the = entity that can open it. That entity would be bound by any "Do not = Distribute" flag. Without speaking to the details of the LoST protocol, = or making any specific proposal to modify it, I can imagine an approach = where the PIDF-LO object could only be decrypted by the LoST server, and = even the proxy that sends the query to LoST could not decrypt the = object. And supposing you can't or won't encrypt? Well, in that case I agree = that sending location information by-value in an INVITE is ambiguous = with regards to the "Do not Distribute" flag. Many, if not most, SIP = proxies don't inspect MIME bodies by default, and probably wouldn't even = be aware that they are distributing location information - we can't = reasonably hold automata responsible for violating the flag in the = course of their conventional behavior, anyway. I think back in the day, = we roughly concluded that if you need to send location information = by-value in cleartext in something like a SIP INVITE, you should set the = flag off. There was much talk back at the time that in emergency = services cases, you had to sacrifice a certain expectation of privacy = that you might want to retain for other location-based services. I also would like to stress something that I've said a couple of times = in the history of this draft - that location conveyance does not exist = solely for the purposes of ECRIT's use cases. Don't forget that there = are other location-based services that we want to enable in a SIP = context, and that even if some approaches wouldn't make sense for ECRIT, = that doesn't mean that they shouldn't be specified. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Tuesday, July 25, 2006 11:19 AM > To: Rosen, Brian; sip@ietf.org > Cc: geopriv@ietf.org > Subject: Re: [Geopriv] Consensus on changes to location-conveyance >=20 >=20 > At 1:38 PM -0400 7/25/06, Rosen, Brian wrote: > >4. We proposed to explicitly allow hop-by-hop TLS security=20 > for location > >when the endpoint wished to allow routing based on location.=20 > We further > >proposed to interpret "Do not Distribute" flags as allowing=20 > sending of > >the location to the routing database (LoST for example). =20 > Hannes pointed > >out that there was a proposal to allow two Location headers, one of > >which could be used for routing and another for onward=20 > forwarding to the > >recipient. Hannes' message seemed to agree that "Do not distribute" > >would allow sending of the location to the=20 > routing-by-location database, > >but would obligate the proxy that did that to remove the=20 > location before > >it forwarded the message. There were no other messages on=20 > this thread. >=20 > Actually, I commented on the same problem, though it may have been > connected to one of the related threads; here's the text of=20 > that message: >=20 > >At 5:23 PM -0400 7/19/06, Brian Rosen wrote: > >>NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU=20 > REPLY, SEND IT ONLY TO > >>GEOPRIV > >>However, this opens up the issue of geopriv privacy=20 > concerns because the > >>sender does not know the identity of the element (proxy)=20 > that will route the > >>call using LoST. It may be that the UAC itself does this,=20 > but it may be > >>some other intermediary. > >> > >>If the identity of the intermediary is not known, then=20 > protecting the > >>location information becomes more difficult, because we=20 > cannot encrypt using > >>keying material from the intended recipient. > > > >Just to mention this, it appears to also rule out the idea=20 > of encrypting > >with the user's key, since there is no way of knowing=20 > whether the "intended > >recipient" has that key material either. Intended recipient=20 > is actually > >a bit of a problematic term here, since it's really the=20 > on-path network elements > >which consume the information. They aren't the intended recipient of > >the communication, they are the recipients of the signaling=20 > (of which location > >is now a part). > > > >This is a bit confusing because it seems to be possible to include a > >"re-transmission allowed" rule with a value of "no" (intended to be > >consumed by the "intended recipient" of the underlying=20 > communication), > >while still wanting to allow the location to be passed along=20 > the path. > > > >>In fact, we would need to use > >>hop-by-hop security, with transitive trust. This is what=20 > the emergency case > >>does, but it also allows no channel security if necessary=20 > (usually meaning, > >>try it with TLS and if that fails, try again without TLS). > > > >While I certainly encourage hop-by-hop security, I don't=20 > think it really > >meets the geopriv privacy concerns. I think you have to=20 > have some way of > >expressing "re-transmission for routing permitted" (and=20 > likely retention > >limited), since that is a separate statement. > > > >Just typing aloud here, but could we come up with a way to use an > >external ruleset to express this? With an embedded cid, that would > >not actually require dereferencing. > > Ted > > >=20 >=20 >=20 > >We conclude that allowing hop-by-hop security for location=20 > based routing > >is acceptable, and Do Not Distribute DOES allow forwarding=20 > to a routing > >database, but requires that the proxy doing the location=20 > based route to > >remove the location it uses for that purpose. >=20 > To reiterate this, I do not believe that this is sufficient;=20 > I think you have to > have some way of saying "re-transmission for routing permitted" before > you meet the geopriv privacy concerns. >=20 > >5. We proposed to create a parameter and a registry to distinguish > >multiple ways to dereference a location where HTTP(S) was=20 > the transport. > >Resolution of this issue depends on resolution of issue 6. >=20 > I believe that an HTTP GET of a PIDF-LO object is a=20 > reasonable baseline. > Saying that other mechanisms should update this document with their > dereferencing mechanisms if they could be confused with the baseline > seems to me to be sufficient. I'm not sure a registry is=20 > needed. In practice, > I don't think we would hit the interoperability problems=20 > often. These days, > extensions to HTTP commonly use different mime types to=20 > indicate the special > handling, and I expect anyone creating a more feature-rich=20 > dereferencing > mechanism built on HTTP would not end up using pidf-lo. =20 >=20 > That means the "uri confusion" aspects of the discussion are=20 > probably not > that severe. The only issue is if someone supports only the=20 > more feature-rich > alternative and not a baseline GET of the pidf-lo. I think we should > discourage that, by establishing a real baseline. >=20 > Note also that HTTP URIs don't indicate the HTTP Method=20 > directly; often they > support multiple methods (e.g. HEAD and GET). >=20 > >6. We proposed to allow sip/sips and pres: in the location header. I > >later speculated that if we allow this, it forms a simple way to do > >location-by-reference, and we could eliminate the raw HTTP(S) Get > >proposal, with the parameter and registry entirely. There=20 > was some list > >traffic in favor of this. Martin Thompson is skeptical that SIP > >Presence Subscribe/Notify is actually allowed as a geopriv "using > >protocol". Several of think that it is. If we don't get any more > >comments on this proposal, we will allow sip/sips and pres,=20 > not have any > >http(s) resolution text, and not propose a parameter and accompanying > >registry. >=20 > I share some of Martin's skepticism here, but I won't fall on my sword > if the WG goes in this direction. >=20 > Thanks for the clear set of issues and opportunity to comment, > =09 > Ted Hardie >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 19:23:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5WDj-0004QR-HV; Tue, 25 Jul 2006 19:21:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5WDi-0004QI-Nw for sip@ietf.org; Tue, 25 Jul 2006 19:21:46 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5WDh-0008Th-BB for sip@ietf.org; Tue, 25 Jul 2006 19:21:46 -0400 Received: (qmail 17067 invoked by uid 0); 25 Jul 2006 23:21:37 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 25 Jul 2006 23:21:37 -0000 Message-ID: <001101c6b041$171edfe0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Brian Rosen" , "'Marc Linsner'" , "Peterson, Jon" , "'Andrew Newton'" , "Rosen, Brian" References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 01:21:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, > Would you not agree that if a proxy is allowed to insert > location-by-value, > the concerns would be the same? That would depend whether the URL dereferences the current location, or the location at a particular moment in time. The value of a URI with up2date location info is much higher and much more privacy invading than a one-time snapshot of a user's location. So perhaps same concerns, but much stronger For location-by-reference, you'd probably want some additional requirements: - URL must be valid for a limited amount of time - URL must be cryptographically hard to guess - URL must not contain any information that identifies the user / device / AoR - for whatever transport protocol is used: response must be marked as 'no cache' - user must be able to remove the information at the URL, ie explicit invalidation - user must be able to verify correctness of the issued information (ie user can access the URL himself) - user must be able to control who accesses the URL, both upfront and history of accesses (for a reasonable period) - there must be explicit consent before a proxy would insert user location For the latter point: except for emergency scenario's, the UAC should include some flag in the INVITE saying "proxy: please append location". You'd probably also want some feedback (eg proxy or UAS adding a header to the response saying 'this is the URL that I appended/got' Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 20:03:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5WqZ-000554-U2; Tue, 25 Jul 2006 20:01:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5WqY-000548-3v; Tue, 25 Jul 2006 20:01:54 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5WqX-0002Px-O2; Tue, 25 Jul 2006 20:01:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G5WqL-0003jq-9w; Tue, 25 Jul 2006 19:01:41 -0500 From: "Brian Rosen" To: "'Jeroen van Bemmel'" , "'Marc Linsner'" , "Peterson, Jon" , "'Andrew Newton'" , "Rosen, Brian" Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 20:01:45 -0400 Message-ID: <024e01c6b046$b1b36080$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawQRZKniS+GqM4SySc3QCd/gSJZwAAvwHg In-Reply-To: <001101c6b041$171edfe0$31713b51@BEMBUSTER> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't really understand why you think location by reference is so much of a concern. If you look at the discussion in context, PIDF-LO defines location as part of presence. All of these concerns are relevant there, and I think they have been adequately covered there. We even have some work on anonymization of the identity (and thus of the URI) in presence. Generally, a presence uri: Is not valid for a limited amount of time Is not hard to guess, if it uses an AoR and could be with anonymous URI. Identifies the user if it uses an AoR and doesn't with anonymous URI The protocol (SIP) for retrieving presence, and thus location has the location ruleset as we defined for PIDF-LO, but otherwise does not have "no cache" semantics (albeit caching headers is not very interesting in SIP). Generally, presence systems do have user control of who is allowed to access information, including location and identifying information, so I think that is covered fairly well. Proxy insertion of location, whether by value or by reference has the threat of not being as subject to user control, but I think in every case you have to trust your provider to do as you wish, whether it is your presence provider or your location provider independent of your presence provider, and proxy insertion doesn't fundamentally alter that. I worry more about it, but I don't objectively think it's much different. Now, if there are other location dereferencing systems, they may need an analysis like what you are suggesting, but with respect to SIP Presence, as a form of location by reference, I think we have been over the ground sufficiently, and we have RFCs that permit it. Adding restrictions on the Location header, which I propose is useful precisely to allow an anonymous presence uri that does not reveal identity is not so great I think. If you don't allow that, you would kind of have to use an AoR, which may be appropriate in some cases, but would not in others. I think the proponents of proxy insertion argue that providing it means endpoints don't have to do anything, so I would think they would object to explicit permission to do so. You might get away with a flag that says "don't do it" in the IETF process, but whether such a flag would be deployed is another matter. I think we all agree that the emergency case is different here; laws govern behavior, and in most cases compel location assertion. I kind of like the idea that the proxy inserts the header in the response so the UAC can see it. What do others think of that? Brian > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Tuesday, July 25, 2006 7:22 PM > To: Brian Rosen; 'Marc Linsner'; Peterson, Jon; 'Andrew Newton'; Rosen, > Brian > Cc: sip@ietf.org; geopriv@ietf.org > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- > conveyance > > Brian, > > > Would you not agree that if a proxy is allowed to insert > > location-by-value, > > the concerns would be the same? > > That would depend whether the URL dereferences the current location, or > the > location at a particular moment in time. The value of a URI with up2date > location info is much higher and much more privacy invading than a one- > time > snapshot of a user's location. So perhaps same concerns, but much stronger > > For location-by-reference, you'd probably want some additional > requirements: > - URL must be valid for a limited amount of time > - URL must be cryptographically hard to guess > - URL must not contain any information that identifies the user / device / > AoR > - for whatever transport protocol is used: response must be marked as 'no > cache' > - user must be able to remove the information at the URL, ie explicit > invalidation > - user must be able to verify correctness of the issued information (ie > user > can access the URL himself) > - user must be able to control who accesses the URL, both upfront and > history of accesses (for a reasonable period) > - there must be explicit consent before a proxy would insert user location > > For the latter point: except for emergency scenario's, the UAC should > include some flag in the INVITE saying "proxy: please append location". > You'd probably also want some feedback (eg proxy or UAS adding a header to > the response saying 'this is the URL that I appended/got' > > Regards, > > Jeroen > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 20:19:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5X5u-0006wQ-HQ; Tue, 25 Jul 2006 20:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5X5s-0006nx-IL; Tue, 25 Jul 2006 20:17:44 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5X5q-0005RF-Ag; Tue, 25 Jul 2006 20:17:44 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 25 Jul 2006 20:17:48 -0400 id 01588130.44C6B4AC.00001432 In-Reply-To: <001101c6b041$171edfe0$31713b51@BEMBUSTER> References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 20:17:37 -0400 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: geopriv@ietf.org, "Peterson, Jon" , sip@ietf.org, 'Marc Linsner' , "Rosen, Brian" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 25, 2006, at 7:21 PM, Jeroen van Bemmel wrote: > For location-by-reference, you'd probably want some additional > requirements: > - URL must be valid for a limited amount of time > - URL must be cryptographically hard to guess > - URL must not contain any information that identifies the user / > device / AoR > - for whatever transport protocol is used: response must be marked > as 'no cache' > - user must be able to remove the information at the URL, ie > explicit invalidation > - user must be able to verify correctness of the issued information > (ie user can access the URL himself) > - user must be able to control who accesses the URL, both upfront > and history of accesses (for a reasonable period) > - there must be explicit consent before a proxy would insert user > location Please tell me that you are merely suggesting guidelines and considerations by operators and are not suggesting 2119 language for these? Because just like you'd never get agreement on the intended duration or accuracy or confidence of location-by-value, you'd never get agreement on these. > For the latter point: except for emergency scenario's, the UAC > should include some flag in the INVITE saying "proxy: please append > location". You'd probably also want some feedback (eg proxy or UAS > adding a header to the response saying 'this is the URL that I > appended/got' Just thinking out loud here, but maybe the rule should be that proxies never append a Location header except for emergencies. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 20:41:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5XR6-0003AZ-NE; Tue, 25 Jul 2006 20:39:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5XR5-0003AF-8b; Tue, 25 Jul 2006 20:39:39 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5XR4-00076z-0v; Tue, 25 Jul 2006 20:39:39 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G5XQs-0005gD-4N; Tue, 25 Jul 2006 19:39:26 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Jeroen van Bemmel'" Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 20:39:31 -0400 Message-ID: <025b01c6b04b$f7d05820$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawSOTV0O/FrJrOQoqi9Rv+8CBAZwAAnZKg In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, "Rosen, Brian" , 'Marc Linsner' , geopriv@ietf.org, "Peterson, Jon" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Please tell me that you are merely suggesting guidelines and > considerations by operators and are not suggesting 2119 language for > these? Because just like you'd never get agreement on the intended > duration or accuracy or confidence of location-by-value, you'd never > get agreement on these. I agree here > > > For the latter point: except for emergency scenario's, the UAC > > should include some flag in the INVITE saying "proxy: please append > > location". You'd probably also want some feedback (eg proxy or UAS > > adding a header to the response saying 'this is the URL that I > > appended/got' > > Just thinking out loud here, but maybe the rule should be that > proxies never append a Location header except for emergencies. Works for me. Probably wouldn't work for those carriers who do not intend to support location acquisition by endpoints and do plan to support commercial location based routing. They plan to make mucho dineros charging for location used for location based routing, and don't want those pesky users to get in the way of their plans. Of course, they can overcome all manner of protocol machinery with "As a condition of providing service, user agrees ...." Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 20:47:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5XWr-0000ze-BX; Tue, 25 Jul 2006 20:45:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5XWp-0000zW-Py; Tue, 25 Jul 2006 20:45:35 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5XWo-0008Ke-H4; Tue, 25 Jul 2006 20:45:35 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 19:45:34 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 25 Jul 2006 19:45:33 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 19:45:33 -0500 Message-ID: From: "Winterbottom, James" To: "Brian Rosen" , "Andrew Newton" , "Jeroen van Bemmel" Date: Tue, 25 Jul 2006 19:45:30 -0500 Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 26 Jul 2006 00:45:33.0130 (UTC) FILETIME=[CD144AA0:01C6B04C] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <025b01c6b04b$f7d05820$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcawSOTV0O/FrJrOQoqi9Rv+8CBAZwAAnZKgAAA7GfA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, "Rosen, Brian" , Marc Linsner , geopriv@ietf.org, "Peterson, Jon" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, The fact that people can make money out of a solution scarcely seems a good reason not to permit it! > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 26 July 2006 10:40 AM > To: 'Andrew Newton'; 'Jeroen van Bemmel' > Cc: sip@ietf.org; Rosen, Brian; 'Marc Linsner'; geopriv@ietf.org; > Peterson,Jon > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location- > conveyance >=20 > > Please tell me that you are merely suggesting guidelines and > > considerations by operators and are not suggesting 2119 language for > > these? Because just like you'd never get agreement on the intended > > duration or accuracy or confidence of location-by-value, you'd never > > get agreement on these. > I agree here >=20 > > > > > For the latter point: except for emergency scenario's, the UAC > > > should include some flag in the INVITE saying "proxy: please append > > > location". You'd probably also want some feedback (eg proxy or UAS > > > adding a header to the response saying 'this is the URL that I > > > appended/got' > > > > Just thinking out loud here, but maybe the rule should be that > > proxies never append a Location header except for emergencies. > Works for me. Probably wouldn't work for those carriers who do not intend > to support location acquisition by endpoints and do plan to support > commercial location based routing. They plan to make mucho dineros > charging > for location used for location based routing, and don't want those pesky > users to get in the way of their plans. Of course, they can overcome all > manner of protocol machinery with "As a condition of providing service, > user > agrees ...." >=20 > Brian >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 20:58:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Xhk-0000kz-5I; Tue, 25 Jul 2006 20:56:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Xhi-0000hn-70; Tue, 25 Jul 2006 20:56:50 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Xhh-00024H-Ut; Tue, 25 Jul 2006 20:56:50 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns1.neustar.com (Postfix) with ESMTP id D7DAD26E22; Wed, 26 Jul 2006 00:56:49 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 20:56:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 20:56:48 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcawSOTV0O/FrJrOQoqi9Rv+8CBAZwAAnZKgAAA7GfAAACxu0A== From: "Rosen, Brian" To: "Winterbottom, James" , "Brian Rosen" , "Andrew Newton" , "Jeroen van Bemmel" X-OriginalArrivalTime: 26 Jul 2006 00:56:49.0722 (UTC) FILETIME=[605C09A0:01C6B04E] X-Spam-Score: -2.8 (--) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip@ietf.org, geopriv@ietf.org, Marc Linsner , "Peterson, Jon" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ah, yes, but they can do the same with endpoint assertion of location, except that the user has more control over it. Don't object to carriers, or other service providers, making money off of location based routing. I just want the user to decide when it is, and isn't, okay to do that with his location. Controlling when the location header is attached to the message is a really hard stop on not-so-nice folks. When you let them assert location, then it's harder. Now, reiterating what I have said several times, I think location assertion by proxy is a done deal, whether I like it or not, just as I think location by reference is a done deal. There is one use case I like -- emergency call during transition, when the network knows, in some circumstances, where you are, but the endpoint and/or the access network is not yet upgraded. I just hate opening a big loophole for that one case though. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, July 25, 2006 8:46 PM > To: Brian Rosen; Andrew Newton; Jeroen van Bemmel > Cc: sip@ietf.org; Rosen, Brian; Marc Linsner; geopriv@ietf.org; Peterson, > Jon > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location- > conveyance >=20 > Brian, >=20 > The fact that people can make money out of a solution scarcely seems a > good reason not to permit it! >=20 >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, 26 July 2006 10:40 AM > > To: 'Andrew Newton'; 'Jeroen van Bemmel' > > Cc: sip@ietf.org; Rosen, Brian; 'Marc Linsner'; geopriv@ietf.org; > > Peterson,Jon > > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location- > > conveyance > > > > > Please tell me that you are merely suggesting guidelines and > > > considerations by operators and are not suggesting 2119 language for > > > these? Because just like you'd never get agreement on the intended > > > duration or accuracy or confidence of location-by-value, you'd never > > > get agreement on these. > > I agree here > > > > > > > > > For the latter point: except for emergency scenario's, the UAC > > > > should include some flag in the INVITE saying "proxy: please > append > > > > location". You'd probably also want some feedback (eg proxy or UAS > > > > adding a header to the response saying 'this is the URL that I > > > > appended/got' > > > > > > Just thinking out loud here, but maybe the rule should be that > > > proxies never append a Location header except for emergencies. > > Works for me. Probably wouldn't work for those carriers who do not > intend > > to support location acquisition by endpoints and do plan to support > > commercial location based routing. They plan to make mucho dineros > > charging > > for location used for location based routing, and don't want those > pesky > > users to get in the way of their plans. Of course, they can overcome > all > > manner of protocol machinery with "As a condition of providing > service, > > user > > agrees ...." > > > > Brian > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 21:02:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Xlj-00034C-B6; Tue, 25 Jul 2006 21:00:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Xlh-000344-6k; Tue, 25 Jul 2006 21:00:57 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Xlf-0002RM-W5; Tue, 25 Jul 2006 21:00:57 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 25 Jul 2006 21:01:05 -0400 id 0158801A.44C6BED1.00001CA2 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 21:00:54 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: geopriv@ietf.org, "Peterson, Jon" , sip@ietf.org, Marc Linsner , "Rosen, Brian" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Now, now. Before this degenerates, for non-emergency situations having the location flow from the acquisition protocol through the UAC on to the call path is completely acceptable and gives the user control. We recognize that emergency cases are different, users often are concerned about the emergency and don't need to be bothered by interfaces asking "should I include your location". -andy On Jul 25, 2006, at 8:45 PM, Winterbottom, James wrote: > Brian, > > The fact that people can make money out of a solution scarcely seems a > good reason not to permit it! > > > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Works for me. Probably wouldn't work for those carriers who do not > intend >> to support location acquisition by endpoints and do plan to support >> commercial location based routing. They plan to make mucho dineros >> charging >> for location used for location based routing, and don't want those > pesky >> users to get in the way of their plans. Of course, they can overcome > all >> manner of protocol machinery with "As a condition of providing > service, >> user >> agrees ...." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 25 21:30:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5YCK-0004At-3J; Tue, 25 Jul 2006 21:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5YCI-0004Ao-Kn for sip@ietf.org; Tue, 25 Jul 2006 21:28:26 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5YCD-0007lU-OC for sip@ietf.org; Tue, 25 Jul 2006 21:28:26 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Z006VALNF34@szxga03-in.huawei.com> for sip@ietf.org; Wed, 26 Jul 2006 09:33:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Z00FFXLNFKV@szxga03-in.huawei.com> for sip@ietf.org; Wed, 26 Jul 2006 09:33:15 +0800 (CST) Received: from z53160 ([10.164.5.15]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2Z00MA3LQ1MP@szxml04-in.huawei.com> for sip@ietf.org; Wed, 26 Jul 2006 09:34:52 +0800 (CST) Date: Wed, 26 Jul 2006 09:23:18 +0800 From: Stephen Zhou Subject: RE: [Sip] RE: [Sip-implementors] Regarding non-INVITE servertransaction In-reply-to: To: Kingston.Smiler@flextronicssoftware.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acav6WfHrmnbSL2cShuJjT2ALs+XzAAaGJIQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 4aebf168d9e8ffd581566781707b1a5b Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2043974946==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2043974946== Content-type: multipart/alternative; boundary="Boundary_(ID_wpAHCI0it+YJ5Ui0ybsKUg)" This is a multi-part message in MIME format. --Boundary_(ID_wpAHCI0it+YJ5Ui0ybsKUg) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi Kingston, Timer C. See section 16.8 of rfc3261. BR, Stephen _____ From: Kingston.Smiler@flextronicssoftware.com [mailto:Kingston.Smiler@flextronicssoftware.com] Sent: Tuesday, July 25, 2006 8:50 PM To: Stephen Zhou Cc: 'Manjunath Warad'; netch@portaone.com; sip@ietf.org; sip-implementors@cs.columbia.edu Subject: RE: [Sip] RE: [Sip-implementors] Regarding non-INVITE servertransaction Hi, I agree with Stephen because it is not a problem in non - IST; This is generic to non-IST as well as IST. But consider a scenario like this UAC of UAS of UAS of UE2 UE1 proxy | | | | | non-INV | | non-INV | |--------------------->| |---------------------------->| | | | 2xx | | | | *<---------------| | | | | UAC of Proxy Here UAS of UE2 is re-transmitting the 2xx message toward proxy. But the message that has been sent by UAS of UE2 hasn't reached UAC of proxy (due to network breakage or some other means). So the proxy core (TU) doesn't send the response to UAS of proxy. In this case how will UAS txn of proxy can be released. Regards, S.Kingston Smiler. Stephen Zhou 07/25/2006 03:21 PM To "'Manjunath Warad'" , netch@portaone.com, Kingston Smiler/BLR/HSS@HSS cc sip@ietf.org, sip-implementors@cs.columbia.edu Subject RE: [Sip] RE: [Sip-implementors] Regarding non-INVITE servertransaction Hi, Manjunath is right. We MUST assume the communication between TU layer and transation lay in a sip stack is reliable. If there have problems, I thinks this is program problem rather than protocol(transaction layer) problem. Additionally, the same issue exist in IST, if the IST cann't receive the responses from TU. BR, Stephen -----Original Message----- From: Manjunath Warad [mailto:manjunathwarad@huawei.com] Sent: Tuesday, July 25, 2006 5:08 PM To: netch@portaone.com; Kingston.Smiler@flextronicssoftware.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip] RE: [Sip-implementors] Regarding non-INVITE server transaction Hi, Below mentioned behaviour is for client transaction, not for server transaction. Rgds, Manju -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Valentin Nechayev Sent: Tuesday, July 25, 2006 4:55 PM To: Kingston.Smiler@flextronicssoftware.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Regarding non-INVITE server transaction Mon, Jul 24, 2006 at 20:08:13, Kingston.Smiler wrote about "[Sip-implementors] Regarding non-INVITE server transaction": > If the non-IST doesn't receive any RESPONSE message then what will > happen? > RFC 3261 (in Figure 8: non-INVITE server transaction ) doesn't mention > properly > what will happen if the non-IST doesn't receive any provisional > response/final response. ==={{{ 8.1.3.1 Transaction Layer Errors In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code. ===}}} -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:netch@portaone.com _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip *********************** FSS-Unclassified *********************** --Boundary_(ID_wpAHCI0it+YJ5Ui0ybsKUg) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT

Hi Kingston,

 

Timer C. See section 16.8 of rfc3261.

 

BR,

Stephen

From: Kingston.Smiler@flextronicssoftware.com [mailto:Kingston.Smiler@flextronicssoftware.com]
Sent: Tuesday, July 25, 2006 8:50 PM
To: Stephen Zhou
Cc: 'Manjunath Warad'; netch@portaone.com; sip@ietf.org; sip-implementors@cs.columbia.edu
Subject: RE: [Sip] RE: [Sip-implementors] Regarding non-INVITE servertransaction

 


Hi,
       I agree with Stephen because it is not a problem in non - IST;
This is generic to non-IST as well as IST.

But consider a scenario like this

UAC of        UAS of                     UAS of UE2
      UE1                 proxy                
 |                |      |                        |
 |         non-INV        |      |     non-INV                |
 |--------------------->|      |---------------------------->|
 |                |      |                2xx        |
 |                |      |                *<---------------|
 |                |      |                        |
                    UAC of
                                     Proxy
       

         Here UAS of UE2 is re-transmitting the 2xx message toward proxy.
But the message that has been sent by UAS of UE2 hasn't reached UAC of proxy
(due to network breakage or some other means). So the proxy core (TU) doesn't
send the response to UAS of proxy.  In this case how will UAS txn of proxy can be released.

Regards,
S.Kingston Smiler.



Stephen Zhou <zhouhong@huawei.com>

07/25/2006 03:21 PM

To

"'Manjunath Warad'" <manjunathwarad@huawei.com>, netch@portaone.com, Kingston Smiler/BLR/HSS@HSS

cc

sip@ietf.org, sip-implementors@cs.columbia.edu

Subject

RE: [Sip] RE: [Sip-implementors] Regarding non-INVITE         servertransaction

 

 

 




Hi,

Manjunath is right.

We MUST assume the communication between TU layer and transation lay in a
sip stack  is reliable. If there have problems, I thinks this is program
problem rather than protocol(transaction layer) problem.
Additionally, the same issue exist in IST, if the IST cann't receive the
responses from TU.

BR,
Stephen
-----Original Message-----
From: Manjunath Warad [mailto:manjunathwarad@huawei.com]
Sent: Tuesday, July 25, 2006 5:08 PM
To: netch@portaone.com; Kingston.Smiler@flextronicssoftware.com
Cc: sip@ietf.org; sip-implementors@cs.columbia.edu
Subject: [Sip] RE: [Sip-implementors] Regarding non-INVITE server
transaction

Hi,
                Below mentioned behaviour is for client transaction, not for
server transaction.

Rgds,
Manju

-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Valentin
Nechayev
Sent: Tuesday, July 25, 2006 4:55 PM
To: Kingston.Smiler@flextronicssoftware.com
Cc: sip@ietf.org; sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] Regarding non-INVITE server transaction

Mon, Jul 24, 2006 at 20:08:13, Kingston.Smiler wrote about
"[Sip-implementors] Regarding non-INVITE server transaction":

>         If the non-IST doesn't receive any RESPONSE message then what
will
> happen?
> RFC 3261 (in Figure 8: non-INVITE server transaction ) doesn't mention

> properly
> what will happen if the  non-IST doesn't receive any provisional
> response/final response.

==={{{
8.1.3.1 Transaction Layer Errors

  In some cases, the response returned by the transaction layer will
  not be a SIP message, but rather a transaction layer error.  When a
  timeout error is received from the transaction layer, it MUST be
  treated as if a 408 (Request Timeout) status code has been received.
  If a fatal transport error is reported by the transport layer
  (generally, due to fatal ICMP errors in UDP or connection failures in
  TCP), the condition MUST be treated as a 503 (Service Unavailable)
  status code.
===}}}

--
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:netch@portaone.com
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip





***********************  FSS-Unclassified   ***********************

--Boundary_(ID_wpAHCI0it+YJ5Ui0ybsKUg)-- --===============2043974946== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2043974946==-- From sip-bounces@ietf.org Tue Jul 25 22:59:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ZaE-0006Ps-1N; Tue, 25 Jul 2006 22:57:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ZaD-0006Pk-6v for sip@ietf.org; Tue, 25 Jul 2006 22:57:13 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ZaB-0007bt-T8 for sip@ietf.org; Tue, 25 Jul 2006 22:57:13 -0400 Received: from [64.101.149.124] (mikwils2-w2k.cisco.com [64.101.149.124]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6Q2xA7Y006222 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 25 Jul 2006 21:59:11 -0500 In-Reply-To: <44C6906F.40802@lucent.com> References: <44C65B13.5040803@cisco.com> <44C6906F.40802@lucent.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <702E1C74-33EA-4E8A-9DAB-214155D3A469@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Hitchhikers guide - when is it done? Date: Tue, 25 Jul 2006 21:57:04 -0500 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 25, 2006, at 4:43 PM, Vijay K. Gurbani wrote: > > Plus there is some poetic justice in the SIP WG closing doors > when the last RFC issued is one that (partially) summarizes what > we have done as a WG. Too bad RFC number 4242 is already taken. > I'm aiming for RFC 5060. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 02:50:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5dCc-0007St-Ge; Wed, 26 Jul 2006 02:49:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5dCb-0007So-HK for sip@ietf.org; Wed, 26 Jul 2006 02:49:05 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5dCY-0005a5-Op for sip@ietf.org; Wed, 26 Jul 2006 02:49:05 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k6Q6mvIm031006; Wed, 26 Jul 2006 08:48:57 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k6Q6mvip016605; Wed, 26 Jul 2006 08:48:57 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 08:47:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Security mechanism? Date: Wed, 26 Jul 2006 08:47:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Security mechanism? thread-index: AcatMmukCdx5SMIER4mb/PLhMfYesgDTC3Pw From: "Fries, Steffen" To: , "Cullen Jennings" X-OriginalArrivalTime: 26 Jul 2006 06:47:59.0978 (UTC) FILETIME=[6F35F4A0:01C6B07F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Frank, the method you are describing at least requires the usage of TLS to protect the key exchange between Alice and Bob. Moreover, you do need to trust the proxies in between, as they have access to the keys (assumed you send the key from Alice to Bob in the SDP). You may combine the SIP_CERTS approach with draft-ono-sipping-smime-keyreuse-01.txt to have one S/MIME encryption based on certificates and use the key-reuse for the rest of the session. But as I wrote last time, the draft regarding key-usage has expired and I'm not sure if it will be updated. Ciao Steffen > -----Original Message----- > From: Frank W. Miller [mailto:fwmiller@cornfed.com]=20 > Sent: Saturday, July 22, 2006 3:58 AM > To: Cullen Jennings > Cc: sip@ietf.org > Subject: Re: [Sip] SIP Security mechanism? >=20 >=20 > Thanks for the pointer. I have scanned this draft over. >=20 > The goal of your draft is similar to what I'm targeting but=20 > slightly different. Please correct me if I am=20 > misunderstanding something. The draft (which is now=20 > draft-ietf-sip-certs-01 I believe) has the goal is to provide=20 > a way to make the distribution of certificates more automated=20 > by providing specific infrastructure that is based on simple=20 > user actions. The draft specifies publication and an event=20 > package that allows for notification to interested User=20 > Agents of certificates. >=20 > The great benefit to this approach is its preservation of=20 > user authentication. >=20 > My thought was much simpler. Let me drop in a quote from the=20 > ZRTP draft, draft-zimmermann-avt-zrtp-01.txt: >=20 > ZRTP is key agreement protocol which performs Diffie-Hellman key > exchange during call setup in-band in the Real-time Transport > Protocol (RTP) [1] media stream which has been established=20 > using some > other signaling protocol such as Session Initiation Protocol (SIP) > [11]. This generates a shared secret which is then used=20 > to generate > keys and salt for a Secure RTP (SRTP) [2] session. >=20 > Although it uses > a public key algorithm, it does not rely on a public key > infrastructure (PKI). >=20 > Were we to put in place some sort of simple transaction that=20 > did this key exchange before any other signaling, we could=20 > use the keys to do encryption of the message bodies (similar=20 > to what S/MIME is doing) without having to deal with PKI at=20 > all. Since the main problem with the use of S/MIME to date=20 > has been the certificate management, this approach is also=20 > targeting the problem that your draft is. >=20 > However, there are a couple of differences. First, your=20 > draft approach preserves full S/MIME certificate based=20 > authentication, this approach would likely not do that, it=20 > would be to allow for encryption only. The ZRTP draft=20 > proposes prompting the user with a short authentication=20 > string for the media but I don't know if that would be useful=20 > for the signaling. Second, this approach would be much=20 > simpler, likely requiring only a couple of messages between=20 > the UA endpoints. It would not require the centralized=20 > server elements that would be necessary for the=20 > PUBLISH/SUBSCRIBE/NOTIFY components of your draft. >=20 > Consider the messages used to do key exchange in ZRTP (again=20 > from the ZRTP draft): >=20 > Alice Bob > | | > | Alice and Bob establish a media session.| > | | > | RTP | > = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > | | > | Hello (ver,cid,hash,cipher,pkt,sas,Alice's ZID) F1 > |---------------------------------------->| > | HelloACK F2 | > |<----------------------------------------| > | Hello (ver,cid,hash,cipher,pkt,sas,Bob's ZID) F3 > |<----------------------------------------| > | HelloACK F4 | > |---------------------------------------->| > | | > | Bob acts as the initiator | > | | > | Commit (Bob's ZID,hash,cipher,pkt,hvi) F5 > |<----------------------------------------| > | DHPart1 (pvr,rs1IDr,rs2IDr,sigsIDr,srtpsIDr,other_secretIDr) F6 > |---------------------------------------->| > | DHPart2 (pvi,rs1IDi,rs2IDi,sigsIDi,ssrtpIDi,other_secretIDi) F7 > |<----------------------------------------| > | | > | Alice and Bob generate SRTP session key.| > | | > | SRTP begins | > = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > | | > | Confirm1 (plaintext,sasflag,hmac) F8 | > |---------------------------------------->| > | Confirm2 (plaintext,sasflag,hmac) F9 | > |<----------------------------------------| > | Confirm2AK F10 | > |---------------------------------------->| >=20 >=20 > They are generating keys for each of media streams here, i.e.=20 > an inband message exchange is happening in each direction. =20 > Something like this could probably be simplified to just two=20 > messages for the signaling, something like: >=20 > Bob Alice > | HELLO | > |------------------------------->| > | 200 OK | > |<-------------------------------| > | | >=20 > This example uses a new method I made up called HELLO but I=20 > suppose this could be folded into the INVITE transaction too,=20 > using a mechanism similar to the 407. The key that Alice is=20 > supposed to use to encrypt the bodies sent to Bob would be in=20 > the HELLO and the key that Bob is supposed to use encrypt the=20 > bodies sent to Alice would be in the 200 OK. >=20 > Is this clearer? Does it make sense? Its simpler but the=20 > authentication may not be there. That works for the media=20 > because you can possibly recognize someone's voice. In the=20 > signaling the authentication thing may be a bigger issue. >=20 > FM >=20 >=20 > On Fri, 2006-07-21 at 00:17 -0700, Cullen Jennings wrote: > > you might want to have a read of=20 > draft-ietf-sipping-certs-04 if your=20 > > goal is to make sure that users can find the keys of other=20 > users for=20 > > use with S/MIME > >=20 > > On Jul 19, 2006, at 12:17 PM, fwmiller@cornfed.com wrote: > >=20 > > > > > > > > > I've been reading about the ZRTP lately. I read=20 > Henning's comment=20 > > > at the IETF meeting about how S/MIME relies on the=20 > receiver's public=20 > > > key to be available to allow for encryption/decryption to work. > > > > > > Why couldnt we put in place a mechanism that did a key=20 > exchange for=20 > > > SIP signaling similar to whats done in ZRTP (i.e. modified Diffie- > > > Hellman) prior to any signaling traffic, then use the=20 > exchanged keys=20 > > > as the basis for S/MIME encryption of the bodies? Or we=20 > could even=20 > > > get really carried away and use it to do encryption of the entire=20 > > > SIP message if the signaling did not traverse proxies? =20 > This could=20 > > > be useful for encrypting UDP signaling, again if no proxy were=20 > > > involved. > > > > > > Thoughts? > > > FM > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 02:54:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5dGY-00016p-5Q; Wed, 26 Jul 2006 02:53:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5dGV-00016a-Rr for sip@ietf.org; Wed, 26 Jul 2006 02:53:07 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5dGU-0007Vx-Dt for sip@ietf.org; Wed, 26 Jul 2006 02:53:07 -0400 Received: (qmail 4433 invoked by uid 0); 26 Jul 2006 06:46:24 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 Jul 2006 06:46:24 -0000 Message-ID: <004601c6b07f$355c3b90$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Brian Rosen" , "'Marc Linsner'" , "Peterson, Jon" , "'Andrew Newton'" , "Rosen, Brian" References: <024e01c6b046$b1b36080$640fa8c0@cis.neustar.com> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 08:46:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >I don't really understand why you think location by reference is so much of > a concern. Because location by reference involves storage of personal information on a server. That suddenly makes all sorts of regulations apply, the points I mentioned address only a small part of that. Having an anonymous URL for example often makes a difference, because then the information is no longer directly linked to a particular person. When an endpoint inserts location by value, you can reasonably argue that opt-in consent requirements (which many countries have) are fulfilled, provided the endpoint gives the user control over whether or not location is inserted. Same holds for the endpoint inserting a flag asking a proxy to fill in the location (by value). For location-by-reference this is much more fuzzy. You probably don't need a lecture on privacy regulations, but e.g. http://www.isoc.org/briefings/015/index.shtml (from 2003 but still applicable IMO) illustrates the mess. A while ago I submitted a draft on Temporarily Routable User Agent URIs (http://www.ietf.org/internet-drafts/draft-jbemmel-sip-truu-02.txt), which provides anonymous, temporary URIs that can be explicitly invalidated. You may want to consider something similar for location-by-reference Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 04:19:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5eZ2-0005FN-Iw; Wed, 26 Jul 2006 04:16:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5eZ0-0005E3-8C for sip@ietf.org; Wed, 26 Jul 2006 04:16:18 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5eYw-00056r-RG for sip@ietf.org; Wed, 26 Jul 2006 04:16:18 -0400 Received: (qmail 23745 invoked by uid 0); 26 Jul 2006 08:16:07 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 Jul 2006 08:16:07 -0000 Message-ID: <009001c6b08b$c14e3a70$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "IETF SIP List" , "Robert Sparks" References: Subject: Re: [Sip] Update to fork-loop-fix submitted Date: Wed, 26 Jul 2006 10:16:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-02.txt > Robert, With respect to Open Issue 3 (Proxy-Authorization and Proxy-Require) it is worth noting (restating actually, this has been pointed out before somewhere) that including them means that loop detection cannot be used when forwarding CANCEL or ACK to non-2xx: - for both, branch must match the INVITE, so outcome of loop hash must match - Proxy-Require/Proxy-Authorization won't appear in CANCEL or ACK to non-2xx (since these are generated hop-by-hop, and also because both are not allowed in CANCEL) So whatever the reasons were for including them, there are reasons for *not* including them Personally, I would like to separate the loop detection hash from the branch parameter. Can we not introduce a separate via parameter for this? Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 04:20:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5eaF-0006F6-Hp; Wed, 26 Jul 2006 04:17:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5eaD-0006Et-Qv for sip@ietf.org; Wed, 26 Jul 2006 04:17:33 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5eaB-0005Tu-Ex for sip@ietf.org; Wed, 26 Jul 2006 04:17:33 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6Q8CmUt026485 for ; Wed, 26 Jul 2006 04:12:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Hitchhikers guide - when is it done? Date: Wed, 26 Jul 2006 11:17:28 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Hitchhikers guide - when is it done? Thread-Index: AcawE6wDvcSKNOmWSgGebPyGwIbwsgAd8Caw From: "Romascanu, Dan \(Dan\)" To: "Jonathan Rosenberg" , "IETF SIP List" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Because of the overhead and clerical delays involved in the publication of RFCs I would suggest a refinement to option 2. Provide a reference in the RFC to a Web page maintained and refreshed by the SIP WG or the RAI Area including the 'to-the-best-of-our-knowledge' updates in-between two versions of the RFC.=20 Dan =20 =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Tuesday, July 25, 2006 8:56 PM > To: IETF SIP List > Subject: [Sip] Hitchhikers guide - when is it done? >=20 > During the IETF meeting, I discussed the one current open=20 > issue in the Hitchhikers guide. The issue is: when does the=20 > document finish? When do we send to IESG to issue an RFC? >=20 > There were two approaches: >=20 > 1. split the document in two. One part contains only the core=20 > specs, and issues relatively soon. The other part has=20 > everything else, and basically ends up being the last RFC=20 > produced by the SIP WG before it shuts its doors (which has=20 > always been 1.5 years from now for the last 5 years). >=20 > 2. keep it as one document. Issue an RFC at some point, and=20 > then revise it a few times as needed. We need to decide when=20 > to issue it. >=20 >=20 > I'd like to propose option 2. I think people get more value=20 > from it as a=20 > consolidated document. Furthermore, I'd propose that we send the=20 > document to IESG for consideration as informational at the=20 > instant all=20 > of the documents listed as 'core' have RFC numbers issued by RFC-ed. >=20 > Comments? >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 08:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5i5y-00029g-9R; Wed, 26 Jul 2006 08:02:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VDi-0004Mh-Hm; Tue, 25 Jul 2006 18:17:42 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5VDf-0006tj-SY; Tue, 25 Jul 2006 18:17:42 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 25 Jul 2006 15:17:39 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PMHdDK029300; Tue, 25 Jul 2006 15:17:39 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6PMHS2L015892; Tue, 25 Jul 2006 15:17:39 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Jul 2006 15:17:33 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 15:17:32 -0700 From: "Marc Linsner" To: "'Peterson, Jon'" , "'Andrew Newton'" , "'Rosen, Brian'" Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 18:17:23 -0400 Message-ID: <00fa01c6b038$1e37fa40$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawJZpkqbGyCVnSTue1IO2WT/AgKAAAR94gAAFPWjA= In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597054F4511@stntexch03.cis.neustar.com> X-OriginalArrivalTime: 25 Jul 2006 22:17:32.0971 (UTC) FILETIME=[20178FB0:01C6B038] DKIM-Signature: a=rsa-sha1; q=dns; l=8929; t=1153865859; x=1154729859; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Sip]=20RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=20loca tion-conveyance; X=v=3Dcisco.com=3B=20h=3DuQx2+C6hzLub85HC/MIjXZBl+x0=3D; b=DUe37+hh0cPljtXCP23kiDrzzR3rtw98SP4zPACNHrnyqtnCcL2vWlULHnDOG+Yek1ieRiFY Ya5/44Xi5ulm5ceQFgTj2rmUSWIfrEX324vdQoJ9+eiZGEF7oB3KMbwt; Authentication-Results: sj-dkim-1.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af X-Mailman-Approved-At: Wed, 26 Jul 2006 08:02:30 -0400 Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have no problem with pidf/pidf-lo/presence. I have no problem with a ua placing a uri pointing to their presence service in a header of a sip invite. Context check: We're discussing a sip invite (assumed pointed to emergency service) that arrives at a proxy with zero location information. I'm the only one that has a problem with any (visited) proxy/LIS creating a uri that can be de-referenced by anyone without regard to user security/privacy rules? -Marc- > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Tuesday, July 25, 2006 4:42 PM > To: Andrew Newton; Rosen, Brian > Cc: sip@ietf.org; geopriv@ietf.org; From sip-bounces@ietf.org Wed Jul 26 08:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5i5y-00029g-9R; Wed, 26 Jul 2006 08:02:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VDi-0004Mh-Hm; Tue, 25 Jul 2006 18:17:42 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5VDf-0006tj-SY; Tue, 25 Jul 2006 18:17:42 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 25 Jul 2006 15:17:39 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PMHdDK029300; Tue, 25 Jul 2006 15:17:39 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6PMHS2L015892; Tue, 25 Jul 2006 15:17:39 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Jul 2006 15:17:33 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 15:17:32 -0700 From: "Marc Linsner" To: "'Peterson, Jon'" , "'Andrew Newton'" , "'Rosen, Brian'" Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 18:17:23 -0400 Message-ID: <00fa01c6b038$1e37fa40$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawJZpkqbGyCVnSTue1IO2WT/AgKAAAR94gAAFPWjA= In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597054F4511@stntexch03.cis.neustar.com> X-OriginalArrivalTime: 25 Jul 2006 22:17:32.0971 (UTC) FILETIME=[20178FB0:01C6B038] DKIM-Signature: a=rsa-sha1; q=dns; l=8929; t=1153865859; x=1154729859; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Sip]=20RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=20loca tion-conveyance; X=v=3Dcisco.com=3B=20h=3DuQx2+C6hzLub85HC/MIjXZBl+x0=3D; b=DUe37+hh0cPljtXCP23kiDrzzR3rtw98SP4zPACNHrnyqtnCcL2vWlULHnDOG+Yek1ieRiFY Ya5/44Xi5ulm5ceQFgTj2rmUSWIfrEX324vdQoJ9+eiZGEF7oB3KMbwt; Authentication-Results: sj-dkim-1.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af X-Mailman-Approved-At: Wed, 26 Jul 2006 08:02:30 -0400 Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have no problem with pidf/pidf-lo/presence. I have no problem with a ua placing a uri pointing to their presence service in a header of a sip invite. Context check: We're discussing a sip invite (assumed pointed to emergency service) that arrives at a proxy with zero location information. I'm the only one that has a problem with any (visited) proxy/LIS creating a uri that can be de-referenced by anyone without regard to user security/privacy rules? -Marc- > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Tuesday, July 25, 2006 4:42 PM > To: Andrew Newton; Rosen, Brian > Cc: sip@ietf.org; geopriv@ietf.org; Marc Linsner > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to > location-conveyance > > > As Brian points out, the whole point of using PIDF for > location information was the similarity of the early defined > use cases to the presence architecture. This certainly > included use cases in which one wanted to fetch or subscribe > to location information. Those operations require the > existence of a reference, and that reference was commonly > described as a URI, at the time. Lately, I think the idea of > having a URI pointing to location information has become > associated with a specific proposal (i.e. HELD), but clearly > RFC4079 sketched out an architecture for using presence to > acquire location information and it specifically mentions > URIs as a way to refer to presence. > > There is no "hidden magic" in any of this. Subscribing to > presence, and using URIs to indicate presence information, is > exhaustively specified for SIP. PIDF-LO was designed to reuse > all of that work and specifically not to require us to go out > and reinvent everything in order to be able to refer to > location information out in the network. > > Basically, I support the direction re: bullet 6. I might > further suggest that the CID URI scheme be permitted in the > Location header, in order to be able to refer to MIME bodies > included in SIP messages. I'm also neutral/favorable on using > HTTP GET. But I think either of these URI schemes and their > usage in the Location header could just as well be described > in subsequent documents. > > Jon Peterson > NeuStar, Inc, > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Tuesday, July 25, 2006 1:05 PM > > To: Rosen, Brian > > Cc: sip@ietf.org; geopriv@ietf.org; Marc Linsner > > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to > > location-conveyance > > > > > > For the record, I agree with Brian. > > > > -andy > > > > On Jul 25, 2006, at 3:50 PM, Rosen, Brian wrote: > > > > > When the original PIDF-LO RFC came out, location-by-reference was > > > defined. > > > > > > You have a URI. You can exchange the URI for location. > There is a > > > protocol defined for that purpose (SIP SUBSCRIBE). That > is location > > > by reference. It also serves as the location update mechanism, > > > clearly something we need. > > > > > > Some day, there may be other location URI references. We > don't need > > > to cover them in this draft. The basic location by > reference horse > > > has left the barn. Were you planning on creating an RFC that > > specifically > > > disallows a Subscribe on a sip/sips/pres URI to get location? > > > THAT WAS > > > THE POINT OF MAKING IT PART OF A PIDF. > > > > > > I do think there is some value in defining a way to express a > > > location-by-reference aka presence URI which is not just > the AoR. > > > That > > > is one reason why I want to define the Location URI as > being able to > > > contain a sip/sips/pres URI. The purpose is to allow a UA or a > > > proxy to insert location where there is no association between the > > identity of > > > the SIP user and the location. > > > > > > But that is all I think we need. > > > > > > We have a requirement for proxy insertion of location. If > > we disallow > > > location-by-reference (which I think is a good idea in > general, but > > > futile in practice), then we would need something like the > > Data URI to > > > support location insertion by proxy. If we DO allow > > > location-by-reference, then it also serves to meet the location > > > insertion by proxy requirement, and we don't need the Data > > URI. We're > > > looking for a use case which requires proxy insertion by > value, but > > > haven't heard one yet. > > > > > > You can make an argument that you can take the From:, > assume it's an > > > AoR, and SUBSCRIBE to the presence of that AoR to get > location, thus > > > not needing a Location header. I really think letting the > > Location header > > > specify an alternate presence URMarc Linsner > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to > location-conveyance > > > As Brian points out, the whole point of using PIDF for > location information was the similarity of the early defined > use cases to the presence architecture. This certainly > included use cases in which one wanted to fetch or subscribe > to location information. Those operations require the > existence of a reference, and that reference was commonly > described as a URI, at the time. Lately, I think the idea of > having a URI pointing to location information has become > associated with a specific proposal (i.e. HELD), but clearly > RFC4079 sketched out an architecture for using presence to > acquire location information and it specifically mentions > URIs as a way to refer to presence. > > There is no "hidden magic" in any of this. Subscribing to > presence, and using URIs to indicate presence information, is > exhaustively specified for SIP. PIDF-LO was designed to reuse > all of that work and specifically not to require us to go out > and reinvent everything in order to be able to refer to > location information out in the network. > > Basically, I support the direction re: bullet 6. I might > further suggest that the CID URI scheme be permitted in the > Location header, in order to be able to refer to MIME bodies > included in SIP messages. I'm also neutral/favorable on using > HTTP GET. But I think either of these URI schemes and their > usage in the Location header could just as well be described > in subsequent documents. > > Jon Peterson > NeuStar, Inc, > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Tuesday, July 25, 2006 1:05 PM > > To: Rosen, Brian > > Cc: sip@ietf.org; geopriv@ietf.org; Marc Linsner > > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to > > location-conveyance > > > > > > For the record, I agree with Brian. > > > > -andy > > > > On Jul 25, 2006, at 3:50 PM, Rosen, Brian wrote: > > > > > When the original PIDF-LO RFC came out, location-by-reference was > > > defined. > > > > > > You have a URI. You can exchange the URI for location. > There is a > > > protocol defined for that purpose (SIP SUBSCRIBE). That > is location > > > by reference. It also serves as the location update mechanism, > > > clearly something we need. > > > > > > Some day, there may be other location URI references. We > don't need > > > to cover them in this draft. The basic location by > reference horse > > > has left the barn. Were you planning on creating an RFC that > > specifically > > > disallows a Subscribe on a sip/sips/pres URI to get location? > > > THAT WAS > > > THE POINT OF MAKING IT PART OF A PIDF. > > > > > > I do think there is some value in defining a way to express a > > > location-by-reference aka presence URI which is not just > the AoR. > > > That > > > is one reason why I want to define the Location URI as > being able to > > > contain a sip/sips/pres URI. The purpose is to allow a UA or a > > > proxy to insert location where there is no association between the > > identity of > > > the SIP user and the location. > > > > > > But that is all I think we need. > > > > > > We have a requirement for proxy insertion of location. If > > we disallow > > > location-by-reference (which I think is a good idea in > general, but > > > futile in practice), then we would need something like the > > Data URI to > > > support location insertion by proxy. If we DO allow > > > location-by-reference, then it also serves to meet the location > > > insertion by proxy requirement, and we don't need the Data > > URI. We're > > > looking for a use case which requires proxy insertion by > value, but > > > haven't heard one yet. > > > > > > You can make an argument that you can take the From:, > assume it's an > > > AoR, and SUBSCRIBE to the presence of that AoR to get > location, thus > > > not needing a Location header. I really think letting the > > Location header > > > specify an alternate presence URI is a good idea. > > > > > > Brian > > > > > >> -----Original Message----- > > >> From: Marc Linsner [mailto:mlinsner@cisco.com] > > >> Sent: Tuesday, July 25, 2006 3:29 PM > > >> To: Rosen, Brian; sip@ietf.org > > >> Cc: geopriv@ietf.org > > >> Subject: RE: [Geopriv] Consensus on changes to > location-conveyance > > >> > > >> In-line..... > > >> > > >>> -----Original Message----- > > >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > >>> Sent: Tuesday, July 25, 2006 1:38 PM > > >>> To: sip@ietf.org > > >>> Cc: geopriv@ietf.org > > >>> Subject: [Geopriv] Consensus on changes to location-conveyance > > >>> > > >>> I have put out a number of emails on proposed changes > to location > > >>> conveyance. Some of them have sparked a number of > comments. My > > >>> summary of consensus on these issues is: > > >>> > > >>> 1. We proposed to explicitly disallow use of a Data URI, which > > >>> would allow specification of a Location-by-value in a header. > > >>> There was a lot of list traffic on this, currently in the state > > >>> where Keith asked for a real use case for it. > > >>> So far, we don't see a use case that cannot be provided by > > >>> location-by-reference in a header. If we don't get a good use > > >>> case, I think consensus is to disallow location-by-value in a > > >>> header. > > >>> > > >> > > >> I see a problem here. Location-by-reference is nothing more than > > > 'magic > > >> happens here'! Please point to a wg item documenting the > > >> location-by-reference mechanism. How can you state the > > >> location-by-reference will cover all the use cases that > > the Data URI > > > would > > >> when location-by-reference hasn't even been defined > > anywhere? You're > > >> loading up the magic with a lot of assumptions. Location-by- > > >> reference > > > is > > >> an > > >> individual submission as a solution to a set of requirements that > > > haven't > > >> been fleshed-out in geopriv. > > >> > > >> I believe that Henning/Hannes also recognized this > issue, hence the > > >> suggestion of a Data URI. Dismissing this suggestion based on an > > > already > > >> accepted non-existent mechanism seems like getting the > > cart before > > >> the > > >> horse. > > >> > > >> ..........snip > > >> > > >>> 6. We proposed to allow sip/sips and pres: in the > location header. > > >>> I later speculated that if we allow this, it forms a > simple way to > > >>> do location-by-reference, and we could eliminate the > raw HTTP(S) > > >>> Get proposal, with the parameter and registry entirely. > There was > > >>> some list traffic in favor of this. Martin Thompson is > skeptical > > >>> that SIP Presence Subscribe/Notify is actually allowed as a > > >>> geopriv "using protocol". Several of think that it is. If we > > >>> don't get any more comments on this proposal, we will allow > > >>> sip/sips and pres, not have any > > >>> http(s) resolution text, and not propose a parameter and > > >>> accompanying registry. > > >> > > >> I certainly think it's more prudent to define the dereferencing > > > mechanism > > >> prior to making claims about the protocol. > > >> > > >> Do I believe location-by-reference will happen? Probably, > > but making > > >> assumptions about the mechanism now is quite premature. > > >> > > >> -Marc- > > >> > > >>> > > >>> If this does not reflect your position, please speak up now. > > >>> > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP ProtocoI is a good idea. > > > > > > Brian > > > > > >> -----Original Message----- > > >> From: Marc Linsner [mailto:mlinsner@cisco.com] > > >> Sent: Tuesday, July 25, 2006 3:29 PM > > >> To: Rosen, Brian; sip@ietf.org > > >> Cc: geopriv@ietf.org > > >> Subject: RE: [Geopriv] Consensus on changes to > location-conveyance > > >> > > >> In-line..... > > >> > > >>> -----Original Message----- > > >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > >>> Sent: Tuesday, July 25, 2006 1:38 PM > > >>> To: sip@ietf.org > > >>> Cc: geopriv@ietf.org > > >>> Subject: [Geopriv] Consensus on changes to location-conveyance > > >>> > > >>> I have put out a number of emails on proposed changes > to location > > >>> conveyance. Some of them have sparked a number of > comments. My > > >>> summary of consensus on these issues is: > > >>> > > >>> 1. We proposed to explicitly disallow use of a Data URI, which > > >>> would allow specification of a Location-by-value in a header. > > >>> There was a lot of list traffic on this, currently in the state > > >>> where Keith asked for a real use case for it. > > >>> So far, we don't see a use case that cannot be provided by > > >>> location-by-reference in a header. If we don't get a good use > > >>> case, I think consensus is to disallow location-by-value in a > > >>> header. > > >>> > > >> > > >> I see a problem here. Location-by-reference is nothing more than > > > 'magic > > >> happens here'! Please point to a wg item documenting the > > >> location-by-reference mechanism. How can you state the > > >> location-by-reference will cover all the use cases that > > the Data URI > > > would > > >> when location-by-reference hasn't even been defined > > anywhere? You're > > >> loading up the magic with a lot of assumptions. Location-by- > > >> reference > > > is > > >> an > > >> individual submission as a solution to a set of requirements that > > > haven't > > >> been fleshed-out in geopriv. > > >> > > >> I believe that Henning/Hannes also recognized this > issue, hence the > > >> suggestion of a Data URI. Dismissing this suggestion based on an > > > already > > >> accepted non-existent mechanism seems like getting the > > cart before > > >> the > > >> horse. > > >> > > >> ..........snip > > >> > > >>> 6. We proposed to allow sip/sips and pres: in the > location header. > > >>> I later speculated that if we allow this, it forms a > simple way to > > >>> do location-by-reference, and we could eliminate the > raw HTTP(S) > > >>> Get proposal, with the parameter and registry entirely. > There was > > >>> some list traffic in favor of this. Martin Thompson is > skeptical > > >>> that SIP Presence Subscribe/Notify is actually allowed as a > > >>> geopriv "using protocol". Several of think that it is. If we > > >>> don't get any more comments on this proposal, we will allow > > >>> sip/sips and pres, not have any > > >>> http(s) resolution text, and not propose a parameter and > > >>> accompanying registry. > > >> > > >> I certainly think it's more prudent to define the dereferencing > > > mechanism > > >> prior to making claims about the protocol. > > >> > > >> Do I believe location-by-reference will happen? Probably, > > but making > > >> assumptions about the mechanism now is quite premature. > > >> > > >> -Marc- > > >> > > >>> > > >>> If this does not reflect your position, please speak up now. > > >>> > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 08:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5i5w-000281-JA; Wed, 26 Jul 2006 08:02:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Sar-0004kl-Cx; Tue, 25 Jul 2006 15:29:25 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Sao-00015g-0d; Tue, 25 Jul 2006 15:29:25 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 25 Jul 2006 12:29:22 -0700 X-IronPort-AV: i="4.07,180,1151910000"; d="scan'208"; a="331358653:sNHT26570312" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PJTLBl008095; Tue, 25 Jul 2006 12:29:21 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6PJTLiB000606; Tue, 25 Jul 2006 12:29:21 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Jul 2006 12:29:21 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 12:29:19 -0700 From: "Marc Linsner" To: "'Rosen, Brian'" , Date: Tue, 25 Jul 2006 15:29:13 -0400 Message-ID: <00be01c6b020$9e9eb100$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawERldoiEvROTuT2KasGKrfOW37QABTfWw In-Reply-To: X-OriginalArrivalTime: 25 Jul 2006 19:29:20.0264 (UTC) FILETIME=[A05EB080:01C6B020] DKIM-Signature: a=rsa-sha1; q=dns; l=2687; t=1153855761; x=1154719761; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=20location-conveyance; X=v=3Dcisco.com=3B=20h=3DzUlXEwcSIR4t8KE8x01CdqIw4As=3D; b=bByzoMKj/mgTX4eqC/8y9VHIGLZaEQyOGTtJ7YvItVF5cKdReC6RLT9HdXKBY3WMZRhQMFep SW50sHHhhUQXObGv+ZxaPQVqFJidX14yUJ90cWl8ENAGAfmCg5Pki3P4; Authentication-Results: sj-dkim-1.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-Mailman-Approved-At: Wed, 26 Jul 2006 08:02:30 -0400 Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In-line..... > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Tuesday, July 25, 2006 1:38 PM > To: sip@ietf.org > Cc: geopriv@ietf.org > Subject: [Geopriv] Consensus on changes to location-conveyance > > I have put out a number of emails on proposed changes to > location conveyance. Some of them have sparked a number of > comments. My summary of consensus on these issues is: > > 1. We proposed to explicitly disallow use of a Data URI, > which would allow specification of a Location-by-value in a >l Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 08:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5i5w-000281-JA; Wed, 26 Jul 2006 08:02:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Sar-0004kl-Cx; Tue, 25 Jul 2006 15:29:25 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Sao-00015g-0d; Tue, 25 Jul 2006 15:29:25 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 25 Jul 2006 12:29:22 -0700 X-IronPort-AV: i="4.07,180,1151910000"; d="scan'208"; a="331358653:sNHT26570312" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PJTLBl008095; Tue, 25 Jul 2006 12:29:21 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6PJTLiB000606; Tue, 25 Jul 2006 12:29:21 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Jul 2006 12:29:21 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 12:29:19 -0700 From: "Marc Linsner" To: "'Rosen, Brian'" , Date: Tue, 25 Jul 2006 15:29:13 -0400 Message-ID: <00be01c6b020$9e9eb100$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawERldoiEvROTuT2KasGKrfOW37QABTfWw In-Reply-To: X-OriginalArrivalTime: 25 Jul 2006 19:29:20.0264 (UTC) FILETIME=[A05EB080:01C6B020] DKIM-Signature: a=rsa-sha1; q=dns; l=2687; t=1153855761; x=1154719761; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=20location-conveyance; X=v=3Dcisco.com=3B=20h=3DzUlXEwcSIR4t8KE8x01CdqIw4As=3D; b=bByzoMKj/mgTX4eqC/8y9VHIGLZaEQyOGTtJ7YvItVF5cKdReC6RLT9HdXKBY3WMZRhQMFep SW50sHHhhUQXObGv+ZxaPQVqFJidX14yUJ90cWl8ENAGAfmCg5Pki3P4; Authentication-Results: sj-dkim-1.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-Mailman-Approved-At: Wed, 26 Jul 2006 08:02:30 -0400 Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In-line..... > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Tuesday, July 25, 2006 1:38 PM > To: sip@ietf.org > Cc: geopriv@ietf.org > Subject: [Geopriv] Consensus on changes to location-conveyance > > I have put out a number of emails on proposed changes to > location conveyance. Some of them have sparked a number of > comments. My summary of consensus on these issues is: > > 1. We proposed to explicitly disallow use of a Data URI, > which would allow specification of a Location-by-value in a > header. There was a lot of list traffic on this, currently > in the state where Keith asked for a real use case for it. > So far, we don't see a use case that cannot be provided by > location-by-reference in a header. If we don't get a good > use case, I think consensus is to disallow location-by-value > in a header. > I see a problem here. Location-by-reference is nothing more than 'magic happens here'! Please point to a wg item documenting the location-by-reference mechanism. How can you state the location-by-reference will cover all the use cases that the Data URI would when location-by-reference hasn't even been defined anywhere? You're loading up the magic with a lot of assumptions. Location-by-reference is an individual submission as a solution to a set of requirements that haven't been fleshed-out in geopriv. I believe that Henning/Hannes also recognized this issue, hence the suggestion of a Data URI. Dismissing this suggestion based on an already accepted non-existent mechanism seems like getting the cart before the horse. ..........snip > 6. We proposed to allow sip/sips and pres: in the location > header. I later speculated that if we allow this, it forms a > simple way to do location-by-reference, and we could > eliminate the raw HTTP(S) Get proposal, with the parameter > and registry entirely. There was some list traffic in favor > of this. Martin Thompson is skeptical that SIP Presence > Subscribe/Notify is actually allowed as a geopriv "using > protocol". Several of think that it is. If we don't get any > more comments on this proposal, we will allow sip/sips and > pres, not have any > http(s) resolution text, and not propose a parameter and > accompanying registry. I certainly think it's more prudent to define the dereferencing mechanism prior to making claims about the protocol. Do I believe location-by-reference will happen? Probably, but making assumptions about the mechanism now is quite premature. -Marc- > > If this does not reflect your position, please speak up now. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip header. There was a lot of list traffic on this, currently > in the state where Keith asked for a real use case for it. > So far, we don't see a use case that cannot be provided by > location-by-reference in a header. If we don't get a good > use case, I think consensus is to disallow location-by-value > in a header. > I see a problem here. Location-by-reference is nothing more than 'magic happens here'! Please point to a wg item documenting the location-by-reference mechanism. How can you state the location-by-reference will cover all the use cases that the Data URI would when location-by-reference hasn't even been defined anywhere? You're loading up the magic with a lot of assumptions. Location-by-reference is an individual submission as a solution to a set of requirements that haven't been fleshed-out in geopriv. I believe that Henning/Hannes also recognized this issue, hence the suggestion of a Data URI. Dismissing this suggestion based on an already accepted non-existent mechanism seems like getting the cart before the horse. ..........snip > 6. We proposed to allow sip/sips and pres: in the location > header. I later speculated that if we allow this, it forms a > simple way to do location-by-reference, and we could > eliminate the raw HTTP(S) Get proposal, with the parameter > and registry entirely. There was some list traffic in favor > of this. Martin Thompson is skeptical that SIP Presence > Subscribe/Notify is actually allowed as a geopriv "using > protocol". Several of think that it is. If we don't get any > more comments on this proposal, we will allow sip/sips and > pres, not have any > http(s) resolution text, and not propose a parameter and > accompanying registry. I certainly think it's more prudent to define the dereferencing mechanism prior to making claims about the protocol. Do I believe location-by-reference will happen? Probably, but making assumptions about the mechanism now is quite premature. -Marc- > > If this does not reflect your position, please speak up now. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 08:04:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5i5v-00027u-T3; Wed, 26 Jul 2006 08:02:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RUX-0004ui-2V; Tue, 25 Jul 2006 14:18:49 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5RUW-0002Qy-Jv; Tue, 25 Jul 2006 14:18:49 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6PIIkQw017106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Jul 2006 11:18:47 -0700 Received: from [10.0.1.3] (vpn-10-50-16-122.qualcomm.com [10.50.16.122]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6PIIiT2013595; Tue, 25 Jul 2006 11:18:45 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 25 Jul 2006 11:18:43 -0700 To: "Rosen, Brian" , From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-Mailman-Approved-At: Wed, 26 Jul 2006 08:02:30 -0400 Cc: geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 1:38 PM -0400 7/25/06, Rosen, Brian wrote: >4. We proposed to explicitly allow hop-by-hop TLS security for location >when the endpoint wished to allow routing based on location. We further >proposed to interpret "Do not Distribute" flags as allowing sending of >the location to the routing database (LoST for example). Hannes pointed >out that there was a proposal to allow two Location headers, one of >which could be used for routing and another for onward forwarding to the >recipient. Hannes' message seemed to agree that "Do not distribute" >would allow sending of the location to the routing-by-location database, >but would obligate the proxy that did that to remove the location before >it forwarded the message. There were no other messages on this thread. Actually, I commented on the same problem, though it may have been connected to one of the related threads; here's the text of that message: >At 5:23 PM -0400 7/19/06, Brian Rosen wrote: >>NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU REPLY, SEND IT ONLY TO >>GEOPRIV >>However, this opens up the issue of geopriv privacy concerns because the >>sender does not know the identity of the element (proxy) that will route the >>call using LoST. It may be that the UAC itself does this, but it may be >>some other intermediary. >> >>If the identity of the intermediary is not known, then protecting the >>location information becomes more difficult, because we cannot encrypt using >>keying material from the intended recipient. > >Just to mention this, it appears to also rule out the idea of encrypting >with the user's key, since there is no way of knowing whether the "intended >recipient" has that key material either. Intended recipient is actually >a bit of a problematic term here, since it's really the on-path network elements >which consume the information. They aren't the intended recipient of >the communication, they are the recipients of the signaling (of which location >is now a part). > >This is a bit confusing because it seems to be possible to include a >"re-transmission allowed" rule with a value of "no" (intended to be >consumed by the "intended recipient" of the underlying communication), >while still wanting to allow the location to be passed along the path. > >>In fact, we would need to use >>hop-by-hop security, with transitive trust. This is what the emergency case >>does, but it also allows no channel security if necessary (usually meaning, >>try it with TLS and if that fails, try again without TLS). > >While I certainly encourage hop-by-hop security, I don't think it really >meets the geopriv privacy concerns. I think you have to have some way of >expressing "re-transmission for routing permitted" (and likely retention >limited), since that is a separate statement. > >Just typing aloud here, but could we come up with a way to use an >external ruleset to express this? With an embedded cid, that would >not actually require dereferencing. > Ted > >We conclude that allowing hop-by-hop security for location based routing >is acceptable, and Do Not Distribute DOES allow forwarding to a routing >database, but requires that the proxy doing the location based route to >remove the location it uses for that purpose. To reiterate this, I do not believe that this is sufficient; I think you have to have some way of saying "re-transmission for routing permitted" before you meet the geopriv privacy concerns. >5. We proposed to create a parameter and a registry to distinguish >multiple ways to dereference a location where HTTP(S) was the transport. >Resolution of this issue depends on resolution of issue 6. I believe that an HTTP GET of a PIDF-LO object is a reasonable baseline. Saying that other mechanisms should update this document with their dereferencing mechanisms if they could be confused with the baseline seems to me to be sufficient. I'm not sure a registry is needed. In practice, I don't think we would hit the interoperability problems often. These days, extensions to HTTP commonly use different mime types to indicate the special handling, and I expect anyone creating a more feature-rich dereferencing mechanism built on HTTP would not end up using pidf-lo. That means the "uri confusion" aspects of the discussion are probably not that severe. The only issue is if someone supports only the more feature-rich alternative and not a baseline GET of the pidf-lo. I think we should discourage that, by establishing a real baseline. Note also that HTTP URIs don't indicate the HTTP Method directly; often they support multiple methods (e.g. HEAD and GET). >6. We proposed to allow sip/sips and pres: in the location header. I >later speculated that if we allow this, it forms a simple way to do >location-by-reference, and we could eliminate the raw HTTP(S) Get >proposal, with the parameter and registry entirely. There was some list >traffic in favor of this. Martin Thompson is skeptical that SIP >Presence Subscribe/Notify is actually allowed as a geopriv "using >protocol". Several of think that it is. If we don't get any more >comments on this proposal, we will allow sip/sips and pres, not have any >http(s) resolution text, and not propose a parameter and accompanying >registry. I share some of Martin's skepticism here, but I won't fall on my sword if the WG goes in this direction. Thanks for the clear set of issues and opportunity to comment, Ted Hardie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 08:04:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5i5x-000295-Cd; Wed, 26 Jul 2006 08:02:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Taz-0002uH-7E; Tue, 25 Jul 2006 16:33:37 -0400 Received: from ithiFrom sip-bounces@ietf.org Wed Jul 26 08:04:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5i5v-00027u-T3; Wed, 26 Jul 2006 08:02:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RUX-0004ui-2V; Tue, 25 Jul 2006 14:18:49 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5RUW-0002Qy-Jv; Tue, 25 Jul 2006 14:18:49 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6PIIkQw017106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Jul 2006 11:18:47 -0700 Received: from [10.0.1.3] (vpn-10-50-16-122.qualcomm.com [10.50.16.122]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6PIIiT2013595; Tue, 25 Jul 2006 11:18:45 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 25 Jul 2006 11:18:43 -0700 To: "Rosen, Brian" , From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-Mailman-Approved-At: Wed, 26 Jul 2006 08:02:30 -0400 Cc: geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 1:38 PM -0400 7/25/06, Rosen, Brian wrote: >4. We proposed to explicitly allow hop-by-hop TLS security for location >when the endpoint wished to allow routing based on location. We further >proposed to interpret "Do not Distribute" flags as allowing sending of >the location to the routing database (LoST for example). Hannes pointed >out that there was a proposal to allow two Location headers, one of >which could be used for routing and another for onward forwarding to the >recipient. Hannes' message seemed to agree that "Do not distribute" >would allow sending of the location to the routing-by-location database, >but would obligate the proxy that did that to remove the location before >it forwarded the message. There were no other messages on this thread. Actually, I commented on the same problem, though it may have been connected to one of the related threads; here's the text of that message: >At 5:23 PM -0400 7/19/06, Brian Rosen wrote: >>NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU REPLY, SEND IT ONLY TO >>GEOPRIV >>However, this opens up the issue of geopriv privacy concerns because the >>sender does not know the identity of the element (proxy) that will route the >>call using LoST. It may be that the UAC itself does this, but it may be >>some other intermediary. >> >>If the identity of the intermediary is not known, then protecting the >>location information becomes more difficult, because we cannot encrypt using >>keying material from the intended recipient. > >Just to mention this, it appears to also rule out the idea of encrypting >with the user's key, since there is no way of knowing whether the "intended >recipient" has that key material either. Intended recipient is actually >a bit of a problematic term here, since it's really the on-path network elements >which consume the information. They aren't the intended recipient of >the communication, they are the recipients of the signaling (of which location >is now a part). > >This is a bit confusing because it seems to be possibllien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Tax-0000Jo-Lj; Tue, 25 Jul 2006 16:33:37 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6PKXX8X006897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Jul 2006 13:33:34 -0700 Received: from [10.0.1.3] (vpn-10-50-16-122.qualcomm.com [10.50.16.122]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6PKXWYl005768; Tue, 25 Jul 2006 13:33:33 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 25 Jul 2006 13:33:31 -0700 To: "Rosen, Brian" , From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c X-Mailman-Approved-At: Wed, 26 Jul 2006 08:02:30 -0400 Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 2:45 PM -0400 7/25/06, Rosen, Brian wrote: >Summarizing, you think hop-by-hop security (TLS) is acceptable when the >location is sent for the purposes of location based routing, but you are >not in favor of defining "retransmission=no" to permit sending the >location to the routing database (e.g. LoST). You want a more explicit >permission. Yes. >I don't think a cid: with a ruleset is acceptable, as it would not >permit location by reference added by a proxy to specify this. Fair enough. >If this is the consensus, I think we would have to add a bit to the PIDF >to explicitly control this behavior. I think an extension that says "retransmission for routing=yes" is the cleanest way to go. >Why do you think we must specify an HTTP dereference procedure in this >document? What is the purpose when the SIP based method is available? >We had believed we had to have SOME method of dereferencing to make >location-by-reference meaningful in the document. If we have one sip >based method, we meet the requirement. Having more options, especially >completely new HTTP based protocols IN THIS DOCUMENT seems unnecessary >and unwise. For example, if we define such a protocol, it becomes a >geopriv "using protocol" and needs an explicit analysis against the >geopriv criteria. I don't think we have to do it in this document, but I read your previous message as a statement of consensus about the HTTP dereference mechanisms that have been discussed. I don't agree with that statement, since I think the HTTP discussions somewhat over-thought the potential problems. In particular, a lot of the discussion was around the idea that http://dereference.example.org/foo-pidf-lo might mean lots of different things, depending on what http meant. There are already ways to deal with that; none of them are perfect (see, for example, the discussion in draft-reschke-webdav-mount-05.txt and its appendix A for a similar problem in a different context), but they can work, especially if you set a baseline approach. regards, Ted Hardie >Brian > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Tuesday, July 25, 2006 2:19 PM >> To: Rosen, Brian; sip@ietf.org >> Cc: geopriv@ietf.org >> Subject: Re: [Geopriv] Consensus on changes to location-conveyance >> >> At 1:38 PM -0400 7/25/06, Rosen, Brian wrote: >> >4. We proposed to explicitly allow hop-by-hoe to include a >"re-transmission allowed" rule with a value of "no" (intended to be >consumed by the "intended recipient" of the underlying communication), >while still wanting to allow the location to be passed along the path. > >>In fact, we would need to use >>hop-by-hop security, with transitive trust. This is what the emergency case >>does, but it also allows no channel security if necessary (usually meaning, >>try it with TLS and if that fails, try again without TLS). > >While I certainly encourage hop-by-hop security, I don't think it really >meets the geopriv privacy concerns. I think you have to have some way of >expressing "re-transmission for routing permitted" (and likely retention >limited), since that is a separate statement. > >Just typing aloud here, but could we come up with a way to use an >external ruleset to express this? With an embedded cid, that would >not actually require dereferencing. > Ted > >We conclude that allowing hop-by-hop security for location based routing >is acceptable, and Do Not Distribute DOES allow forwarding to a routing >database, but requires that the proxy doing the location based route to >remove the location it uses for that purpose. To reiterate this, I do not believe that this is sufficient; I think you have to have some way of saying "re-transmission for routing permitted" before you meet the geopriv privacy concerns. >5. We proposed to create a parameter and a registry to distinguish >multiple ways to dereference a location where HTTP(S) was the transport. >Resolution of this issue depends on resolution of issue 6. I believe that an HTTP GET of a PIDF-LO object is a reasonable baseline. Saying that other mechanisms should update this document with their dereferencing mechanisms if they could be confused with the baseline seems to me to be sufficient. I'm not sure a registry is needed. In practice, I don't think we would hit the interoperability problems often. These days, extensions to HTTP commonly use different mime types to indicate the special handling, and I expect anyone creating a more feature-rich dereferencing mechanism built on HTTP would not end up using pidf-lo. That means the "uri confusion" aspects of the discussion are probably not that severe. The only issue is if someone supports only the more feature-rich alternative and not a baseline GET of the pidf-lo. I think we should discourage that, by establishing a real baseline. Note also that HTTP URIs don't indicate the HTTP Method directly; often they support multiple methods (e.g. HEAD and GET). >6. We proposed to allow sip/sips and pres: in the location header. I >later speculated that if we allow this, it forms a simple way to do >location-by-reference, and we could eliminate the raw HTTP(S) Get >proposal, with the parameter and registry entirely. There was some list >traffic in favor of this. Martin Thompson is skeptical that SIP >Presence Subscribe/Notify is actually allowed as a geopriv "using >protocol". Several of think that it is. If we don't get any more >comments on this proposal, we will allow sip/sips and pres, not have any >http(s) resolution text, and not propose a parameter and accompanying >registry. I share some of Martin's skepticism here, but I won't fall on my sword if the WG goes in this direction. Thanks for the clear set of issues and opportunity to comment, Ted Hardie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 08:04:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5i5x-000295-Cd; Wed, 26 Jul 2006 08:02:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Taz-0002uH-7E; Tue, 25 Jul 2006 16:33:37 -0400 Received: from ithip TLS security for by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Tax-0000Jo-Lj; Tue, 25 Jul 2006 16:33:37 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6PKXX8X006897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Jul 2006 13:33:34 -0700 Received: from [10.0.1.3] (vpn-10-50-16-122.qualcomm.com [10.50.16.122]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6PKXWYl005768; Tue, 25 Jul 2006 13:33:33 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 25 Jul 2006 13:33:31 -0700 To: "Rosen, Brian" , From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c X-Mailman-Approved-At: Wed, 26 Jul 2006 08:02:30 -0400 Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 2:45 PM -0400 7/25/06, Rosen, Brian wrote: >Summarizing, you think hop-by-hop security (TLS) is acceptable when the >location is sent for the purposes of location based routing, but you are >not in favor of defining "retransmission=no" to permit sending the >location to the routing database (e.g. LoST). You want a more explicit >permission. Yes. >I don't think a cid: with a ruleset is acceptable, as it would not >permit location by reference added by a proxy to specify this. Fair enough. >If this is the consensus, I think we would have to add a bit to the PIDF >to explicitly control this behavior. I think an extension that says "retransmission for routing=yes" is the cleanest way to go. >Why do you think we must specify an HTTP dereference procedure in this >document? What is the purpose when the SIP based method is available? >We had believed we had to have SOME method of dereferencing to make >location-by-reference meaningful in the document. If we have one sip >based method, we meet the requirement. Having more options, especially >completely new HTTP based protocols IN THIS DOCUMENT seems unnecessary >and unwise. For example, if we define such a protocol, it becomes a >geopriv "using protocol" and needs an explicit analysis against the >geopriv criteria. I don't think we have to do it in this document, but I read your previous message as a statement of consensus about the HTTP dereference mechanisms that have been discussed. I don't agree with that statement, since I think the HTTP discussions somewhat over-thought the potential problems. In particular, a lot of the discussion was around the idea that http://dereference.example.org/foo-pidf-lo might mean lots of different things, depending on what http meant. There are already ways to deal with that; none of them are perfect (see, for example, the discussion in draft-reschke-webdav-mount-05.txt and its appendix A for a similar problem in a different context), but they can work, especially if you set a baseline approach. regards, Ted Hardie >Brian > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Tuesday, July 25, 2006 2:19 PM >> To: Rosen, Brian; sip@ietf.org >> Cc: geopriv@ietf.org >> Subject: Re: [Geopriv] Consensus on changes to location-conveyance >> >> At 1:38 PM -0400 7/25/06, Rosen, Brian wrote: >> >4. We proposed to explicitly allow hop-by-honeeded. In >> practice, >> I don't think we would hit the interoperability problems often. These >> days, >> extensions to HTTP commonly use different mime types to indicate the >> special >> handling, and I expect anyone creating a more feature-rich >dereferencing >> mechanism built on HTTP would not end up using pidf-lo. >> >> That means the "uri confusion" aspects of the discussion are probably >not >> that severe. The only issue is if someone supports only the more >feature- >> rich >> alternative and not a baseline GET of the pidf-lo. I think we should >> discourage that, by establishing a real baseline. >> >> Note also that HTTP URIs don't indicate the HTTP Method directly; >often >> they >> support multiple methods (e.g. HEAD and GET). >> >> >6. We proposed to allow sip/sips and pres: in the location header. I >> >later speculated that if we allow this, it forms a simple way to do >> >location-by-reference, and we could eliminate the raw HTTP(S) Get >> >proposal, with the parameter and registry entirely. There was some >list >> >traffic in favor of this. Martin Thompson is skeptical that SIP >> >Presence Subscribe/Notify is actually allowed as a geopriv "using >> >protocol". Several of think that it is. If we don't get any more >> >comments on this proposal, we will allow sip/sips and pres, not have >any >> >http(s) resolution text, and not propose a parameter and accompanying >> >registry. >> >> I share some of Martin's skepticism here, but I won't fall on my sword >> if the WG goes in this direction. >> >> Thanks for the clear set of issues and opportunity to comment, >> >> Ted Hardie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip p TLS security for >location >> >when the endpoint wished to allow routing based on location. We >further >> >proposed to interpret "Do not Distribute" flags as allowing sending >of >> >the location to the routing database (LoST for example). Hannes >pointed >> >out that there was a proposal to allow two Location headers, one of >> >which could be used for routing and another for onward forwarding to >the >> >recipient. Hannes' message seemed to agree that "Do not distribute" >> >would allow sending of the location to the routing-by-location >database, >> >but would obligate the proxy that did that to remove the location >before >> >it forwarded the message. There were no other messages on this >thread. >> >> Actually, I commented on the same problem, though it may have been >> connected to one of the related threads; here's the text of that >message: >> >> >At 5:23 PM -0400 7/19/06, Brian Rosen wrote: >> >>NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU REPLY, SEND IT >> ONLY TO >> >>GEOPRIV >> >>However, this opens up the issue of geopriv privacy concerns because >the >> >>sender does not know the identity of the element (proxy) that will >route >> the >> >>call using LoST. It may be that the UAC itself does this, but it >may be >> >>some other intermediary. >> >> >> >>If the identity of the intermediary is not known, then protecting >the >> >>location information becomes more difficult, because we cannot >encrypt >> using >> >>keying material from the intended recipient. >> > >> >Just to mention this, it appears to also rule out the idea of >encrypting >> >with the user's key, since there is no way of knowing whether the >> "intended >> >recipient" has that key material either. Intended recipient is >actually >> >a bit of a problematic term here, since it's really the on-path >network >> elements >> >which consume the information. They aren't the intended recipient of >> >the communication, they are the recipients of the signaling (of which >> location >> >is now a part). >> > >> >This is a bit confusing because it seems to be possible to include a >> >"re-transmission allowed" rule with a value of "no" (intended to be >> >consumed by the "intended recipient" of the underlying >communication), >> >while still wanting to allow the location to be passed along the >path. >> > >> >>In fact, we would need to use >> >>hop-by-hop security, with transitive trust. This is what the >emergency >> case >> >>does, but it also allows no channel security if necessary (usually >> meaning, >> >>try it with TLS and if that fails, try again without TLS). >> > >> >While I certainly encourage hop-by-hop security, I don't think it >really >> >meets the geopriv privacy concerns. I think you have to have some >way >> of >> >expressing "re-transmission for routing permitted" (and likely >retention >> >limited), since that is a separate statement. >> > >> >Just typing aloud here, but could we come up with a way to use an >> >external ruleset to express this? With an embedded cid, that would >> >not actually require dereferencing. >> > Ted >> > >> >> >> >> >We conclude that allowing hop-by-hop security for location based >routing >> >is acceptable, and Do Not Distribute DOES allow forwarding to a >routing >> >database, but requires that the proxy doing the location based route >to >> >remove the location it uses for that purpose. >> >> To reiterate this, I do not believe that this is sufficient; I think >you >> have to >> have some way of saying "re-transmission for routing permitted" before >> you meet the geopriv privacy concerns. >> >> >5. We proposed to create a parameter and a registry to distinguish >> >multiple ways to dereference a location where HTTP(S) was the >transport. >> >Resolution of this issue depends on resolution of issue 6. >> >> I believe that an HTTP GET of a PIDF-LO object is a reasonable >baseline. >> Saying that other mechanisms should update this document with their >> dereferencing mechanisms if they could be confused with the baseline >> seems to me to be sufficient. I'm not sure a registry is needed. In >> practice, >> I don't think we would hit the interoperability problems often. These >> days, >> extensions to HTTP commonly use different mime types to indicate the >> special >> handling, and I expect anyone creating a more feature-rich >dereferencing >> mechanism built on HTTP would not end up using pidf-lo. >> >> That means the "uri confusion" aspects of the discussion are probably >not >> that severe. The only issue is if someone supports only the more >feature- >> rich >> alternative and not a baseline GET of the pidf-lo. I think we should >> discourage that, by establishing a real baseline. >> >> Note also that HTTP URIs don't indicate the HTTP Method directly; >often >> they >> support multiple methods (e.g. HEAD and GET). >> >> >6. We proposed to allow sip/sips and pres: in the location header. I >> >later speculated that if we allow this, it forms a simple way to do >> >location-by-reference, and we could eliminate the raw HTTP(S) Get >> >proposal, with the parameter and registry entirely. There was some >list >> >traffic in favor of this. Martin Thompson is skeptical that SIP >> >Presence Subscribe/Notify is actually allowed as a geopriv "using >> >protocol". Several of think that it is. If we don't get any more >> >comments on this proposal, we will allow sip/sips and pres, not have >any >> >http(s) resolution text, and not propose a parameter and accompanying >> >registry. >> >> I share some of Martin's skepticism here, but I won't fall on my sword >> if the WG goes in this direction. >> >> Thanks for the clear set of issues and opportunity to comment, >> >> Ted Hardie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 08:14:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5iFY-0007UX-Qu; Wed, 26 Jul 2006 08:12:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5iFX-0007TE-F5; Wed, 26 Jul 2006 08:12:27 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5iFW-0007Ql-7v; Wed, 26 Jul 2006 08:12:27 -0400 Received: from [192.168.0.48] (pool-141-153-188-67.mad.east.verizon.net [141.153.188.67]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6QCBesF008540 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 26 Jul 2006 08:12:21 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2575EBB6-C2D6-4073-B44D-F4BC6254AD23@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Tue, 25 Jul 2006 21:39:57 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org, geopriv@ietf.org, Marc Linsner Subject: [Sip] Re: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > I do think there is some value in defining a way to express a > location-by-reference aka presence URI which is not just the AoR. > That > is one reason why I want to define the Location URI as being able to > contain a sip/sips/pres URI. The purpose is to allow a UA or a > proxy to > insert location where there is no association between the identity of > the SIP user and the location. I believe that you have to allow non-AOR SUBSCRIBEs if you want the system to be practical. AOR SUBSCRIBEs will require authentication of the watcher and we seem to agree that this is a no-go. Thus, the only reasonable approach is to have a random-user-ID URL that serves as an authenticator. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 08:14:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5iFT-0007QQ-JZ; Wed, 26 Jul 2006 08:12:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5iFS-0007PJ-4y for sip@ietf.org; Wed, 26 Jul 2006 08:12:22 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5iFQ-0007QY-SI for sip@ietf.org; Wed, 26 Jul 2006 08:12:22 -0400 Received: from [192.168.0.48] (pool-141-153-188-67.mad.east.verizon.net [141.153.188.67]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6QCBesE008540 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 26 Jul 2006 08:12:19 -0400 (EDT) In-Reply-To: <013501c6b011$98b8d360$640fa8c0@cis.neustar.com> References: <013501c6b011$98b8d360$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] Consensus on changes to location-conveyance Date: Tue, 25 Jul 2006 21:36:57 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > 1. We proposed to explicitly disallow use of a Data URI, which > would allow > specification of a Location-by-value in a header. There was a lot > of list > traffic on this, currently in the state where Keith asked for a > real use > case for it. So far, we don't see a use case that cannot be > provided by > location-by-reference in a header. If we don't get a good use > case, I think > consensus is to disallow location-by-value in a header. > I repeat what I said before: There is a clear advantage to this method in terms of simplicity of operation and reliability. Thus, prohibiting it has no technical justification. In addition, when outbound proxies are behind NATs, deploying a reference-based mechanism is far more painful and certainly less reliable since that proxy now has to put a LIS outside the firewall/ proxy. This is likely to be common in small and medium enterprise scenarios, where the enterprise, behind a NAT, has a nailed-up connection to some SIP service provider. This also happens to be the scenario where proxy-based location insertion is most likely since it works reasonably well with network-in-box solutions that combine access router, DHCP server and SIP server. > other messages on this thread. We conclude that allowing hop-by-hop > security for location based routing is acceptable, and Do Not > Distribute > DOES allow forwarding to a routing database, but requires that the > proxy > doing the location based route to remove the location it uses for that > purpose. > This only applies if there are two locations or a single DND location? > 6. We proposed to allow sip/sips and pres: in the location header. > I later > speculated that if we allow this, it forms a simple way to do > location-by-reference, and we could eliminate the raw HTTP(S) Get > proposal, > with the parameter and registry entirely. There was some list > traffic in > favor of this. Martin Thompson is skeptical that SIP Presence > Subscribe/Notify is actually allowed as a geopriv "using > protocol". Several > of think that it is. If we don't get any more comments on this > proposal, we > will allow sip/sips and pres, not have any http(s) resolution text, > and not > propose a parameter and accompanying registry. > I'm concerned about the implementation complexity of this approach in proxies. A SUBSCRIBE/NOTIFY adds another asynchronous operation to the time-critical forwarding path. This is also significantly more complex for proxies to implement than any of the other mechanisms, since they have to correlate incoming NOTIFY arrivals with pending messages, maintain multiple timers and worry about denial-of-service attacks. (A state exhaustion attack in a proxy would simply have the NOTIFY for the SUBSCRIBE take a few minutes, thus requiring the proxy to keep state for that duration. An attacker in an HTTP-based system can pull a similar trick, but it is somewhat easier to bound the permissible delay since it is a one-step operation.) Needless to say, I believe that the security considerations section needs to discuss this. Based on our measurements, the NOTIFY and SUBSCRIBE probably will each take as much effort as handling the INVITE, so that the call routing throughput of an emergency service routing proxy will be reduced by about 2/3. The same is true, to a somewhat lesser extent, for HTTP retrievals and to a larger extent for HTTPS retrievals. Thus, either solution is likely to be much more expensive than a data URL for the proxy-inserted case. > If this does not reflect your position, please speak up now. > > Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 09:03:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5j1b-0000BN-JJ; Wed, 26 Jul 2006 09:02:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5j1Z-0000B3-Pj; Wed, 26 Jul 2006 09:02:05 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5j1Z-0006Vl-08; Wed, 26 Jul 2006 09:02:05 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 26 Jul 2006 06:02:05 -0700 X-IronPort-AV: i="4.07,184,1151910000"; d="scan'208"; a="308105533:sNHT30646260" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6QD241m017628; Wed, 26 Jul 2006 06:02:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6QD23HS029215; Wed, 26 Jul 2006 06:02:03 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Jul 2006 06:02:03 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 06:02:03 -0700 From: "Marc Linsner" To: "'Brian Rosen'" , "'Peterson, Jon'" , "'Andrew Newton'" , "'Rosen, Brian'" Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 09:01:57 -0400 Message-ID: <017501c6b0b3$ae83ddf0$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawJZpkqbGyCVnSTue1IO2WT/AgKAAAR94gAAFPWjAAA+Kk4AAcdB/g In-Reply-To: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 26 Jul 2006 13:02:03.0300 (UTC) FILETIME=[B0791E40:01C6B0B3] DKIM-Signature: a=rsa-sha1; q=dns; l=12883; t=1153918924; x=1154782924; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Sip]=20RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=20loca tion-conveyance; X=v=3Dcisco.com=3B=20h=3DuQx2+C6hzLub85HC/MIjXZBl+x0=3D; b=UGdPowIejg9tr2VsPBl5sVQTGNfjdIyuR4cDtNhN8MoaFozcs9PSEDp7clF/GkWAfKwf0J5/ zvAl6NKHo9TWQS25mVMLtOxOK0vGvOs5NrpsBnfCQMPPJAORVxC1sZ9X; Authentication-Results: sj-dkim-7.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In-line... > > So, you are arguing against proxy insertion of a > location-by-reference? No, if done properly....but reading the latest threads, I get the feeling that www.whereintheworldisbrianrosen.com is an acceptable reference. > > You don't have a problem with UA insertion of > location-by-reference in a Location header? This assumes the user's presence service (contracted by the user) will do the right things to protect the privacy/security of the location information. > > Agree that Location insertion by proxy could assume an INVITE > arriving at a proxy without any location. I suspect there will be many cases where proxy will supplant whatever is supplied by the user with proxy derived data. > > I've always had a problem with proxy insertion of location > because I am worried that proxies will do this without regard > to user's wishes. In an emergency case, however, there are > no such worries. I don't see any difference between by-value > and by-reference. Simplicity? Call/dispatching failures from dereferencing problems? Since emergency calling is the use case driving this, why not opt for less complexity with a better chance of actually working? What seems odd is to dismiss L-by-V in the header simply because the L-by-R has been in this draft for so long. That is the way I read Keith's message. Yes, if the stars and moon are all aligned, L-by-R will work, hence obviating the need for an 'overlapping' L-by-V. But, if it's a cloudy day, the complexity associated with dereferencing WILL cause failures. > > Proxies may disregard advice we supply, but Location URIs in > Location headers probably should not have any user > identification information in either the URI itself, or the > resulting PIDF. If such information is desired, use the AoR. > > De-referencing should always be subject to user rulesets, and > would not be any different than by-value except the obvious > issue that the owners of the proxy may not provide the user > with the facilities to control the ruleset, my original worry. My worry also. > > Would you not agree that if a proxy is allowed to insert > location-by-value, the concerns would be the same? As pointed out by others, by-value is a moment in time, by-reference makes current information available for a yet-to-be-specified period. -Marc- > > Brian > > > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Tuesday, July 25, 2006 6:17 PM > > To: 'Peterson, Jon'; 'Andrew Newton'; 'Rosen, Brian' > > Cc: sip@ietf.org; geopriv@ietf.org > > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location- > > conveyance > > > > I have no problem with pidf/pidf-lo/presence. > > > > I have no problem with a ua placing a uri pointing to their > presence > > service in a header of a sip invite. > > > > Context check: We're discussing a sip invite (assumed pointed to > > emergency > > service) that arrives at a proxy with zero location information. > > > > I'm the only one that has a problem with any (visited) proxy/LIS > > creating a uri that can be de-referenced by anyone without > regard to > > user security/privacy rules? > > > > -Marc- > > > > > > > > > > > > > -----Original Message----- > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > Sent: Tuesday, July 25, 2006 4:42 PM > > > To: Andrew Newton; Rosen, Brian > > > Cc: sip@ietf.org; geopriv@ietf.org; Marc Linsner > > > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to > > > location-conveyance > > > > > > > > > As Brian points out, the whole point of using PIDF for location > > > information was the similarity of the early defined use > cases to the > > > presence architecture. This certainly included use cases in which > > > one wanted to fetch or subscribe to location information. Those > > > operations require the existence of a reference, and that > reference > > > was commonly described as a URI, at the time. Lately, I think the > > > idea of having a URI pointing to location information has become > > > associated with a specific proposal (i.e. HELD), but clearly > > > RFC4079 sketched out an architecture for using presence > to acquire > > > location information and it specifically mentions URIs as > a way to > > > refer to presence. > > > > > > There is no "hidden magic" in any of this. Subscribing to > presence, > > > and using URIs to indicate presence information, is exhaustively > > > specified for SIP. PIDF-LO was designed to reuse all of that work > > > and specifically not to require us to go out and reinvent > everything > > > in order to be able to refer to location information out in the > > > network. > > > > > > Basically, I support the direction re: bullet 6. I might further > > > suggest that the CID URI scheme be permitted in the > Location header, > > > in order to be able to refer to MIME bodies included in SIP > > > messages. I'm also neutral/favorable on using HTTP GET. > But I think > > > either of these URI schemes and their usage in the > Location header > > > could just as well be described in subsequent documents. > > > > > > Jon Peterson > > > NeuStar, Inc, > > > > > > > -----Original Message----- > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > Sent: Tuesday, July 25, 2006 1:05 PM > > > > To: Rosen, Brian > > > > Cc: sip@ietf.org; geopriv@ietf.org; Marc Linsner > > > > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to > > > > location-conveyance > > > > > > > > > > > > For the record, I agree with Brian. > > > > > > > > -andy > > > > > > > > On Jul 25, 2006, at 3:50 PM, Rosen, Brian wrote: > > > > > > > > > When the original PIDF-LO RFC came out, location-by-reference > > > > > was defined. > > > > > > > > > > You have a URI. You can exchange the URI for location. > > > There is a > > > > > protocol defined for that purpose (SIP SUBSCRIBE). That > > > is location > > > > > by reference. It also serves as the location update > mechanism, > > > > > clearly something we need. > > > > > > > > > > Some day, there may be other location URI references. We > > > don't need > > > > > to cover them in this draft. The basic location by > > > reference horse > > > > > has left the barn. Were you planning on creating an RFC that > > > > specifically > > > > > disallows a Subscribe on a sip/sips/pres URI to get location? > > > > > THAT WAS > > > > > THE POINT OF MAKING IT PART OF A PIDF. > > > > > > > > > > I do think there is some value in defining a way to express a > > > > > location-by-reference aka presence URI which is not just > > > the AoR. > > > > > That > > > > > is one reason why I want to define the Location URI as > > > being able to > > > > > contain a sip/sips/pres URI. The purpose is to allow > a UA or a > > > > > proxy to insert location where there is no > association between > > > > > the > > > > identity of > > > > > the SIP user and the location. > > > > > > > > > > But that is all I think we need. > > > > > > > > > > We have a requirement for proxy insertion of location. If > > > > we disallow > > > > > location-by-reference (which I think is a good idea in > > > general, but > > > > > futile in practice), then we would need something like the > > > > Data URI to > > > > > support location insertion by proxy. If we DO allow > > > > > location-by-reference, then it also serves to meet > the location > > > > > insertion by proxy requirement, and we don't need the Data > > > > URI. We're > > > > > looking for a use case which requires proxy insertion by > > > value, but > > > > > haven't heard one yet. > > > > > > > > > > You can make an argument that you can take the From:, > > > assume it's an > > > > > AoR, and SUBSCRIBE to the presence of that AoR to get > > > location, thus > > > > > not needing a Location header. I really think letting the > > > > Location header > > > > > specify an alternate presence URI is a good idea. > > > > > > > > > > Brian > > > > > > > > > >> -----Original Message----- > > > > >> From: Marc Linsner [mailto:mlinsner@cisco.com] > > > > >> Sent: Tuesday, July 25, 2006 3:29 PM > > > > >> To: Rosen, Brian; sip@ietf.org > > > > >> Cc: geopriv@ietf.org > > > > >> Subject: RE: [Geopriv] Consensus on changes to > > > location-conveyance > > > > >> > > > > >> In-line..... > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > >>> Sent: Tuesday, July 25, 2006 1:38 PM > > > > >>> To: sip@ietf.org > > > > >>> Cc: geopriv@ietf.org > > > > >>> Subject: [Geopriv] Consensus on changes to > location-conveyance > > > > >>> > > > > >>> I have put out a number of emails on proposed changes > > > to location > > > > >>> conveyance. Some of them have sparked a number of > > > comments. My > > > > >>> summary of consensus on these issues is: > > > > >>> > > > > >>> 1. We proposed to explicitly disallow use of a Data > URI, which > > > > >>> would allow specification of a Location-by-value in > a header. > > > > >>> There was a lot of list traffic on this, currently in the > > > > >>> state where Keith asked for a real use case for it. > > > > >>> So far, we don't see a use case that cannot be provided by > > > > >>> location-by-reference in a header. If we don't get > a good use > > > > >>> case, I think consensus is to disallow > location-by-value in a > > > > >>> header. > > > > >>> > > > > >> > > > > >> I see a problem here. Location-by-reference is nothing more > > > > >> than > > > > > 'magic > > > > >> happens here'! Please point to a wg item documenting the > > > > >> location-by-reference mechanism. How can you state the > > > > >> location-by-reference will cover all the use cases that > > > > the Data URI > > > > > would > > > > >> when location-by-reference hasn't even been defined > > > > anywhere? You're > > > > >> loading up the magic with a lot of assumptions. > Location-by- > > > > >> reference > > > > > is > > > > >> an > > > > >> individual submission as a solution to a set of requirements > > > > >> that > > > > > haven't > > > > >> been fleshed-out in geopriv. > > > > >> > > > > >> I believe that Henning/Hannes also recognized this > > > issue, hence the > > > > >> suggestion of a Data URI. Dismissing this > suggestion based on > > > > >> an > > > > > already > > > > >> accepted non-existent mechanism seems like getting the > > > > cart before > > > > >> the > > > > >> horse. > > > > >> > > > > >> ..........snip > > > > >> > > > > >>> 6. We proposed to allow sip/sips and pres: in the > > > location header. > > > > >>> I later speculated that if we allow this, it forms a > > > simple way to > > > > >>> do location-by-reference, and we could eliminate the > > > raw HTTP(S) > > > > >>> Get proposal, with the parameter and registry entirely. > > > There was > > > > >>> some list traffic in favor of this. Martin Thompson is > > > skeptical > > > > >>> that SIP Presence Subscribe/Notify is actually allowed as a > > > > >>> geopriv "using protocol". Several of think that it > is. If we > > > > >>> don't get any more comments on this proposal, we will allow > > > > >>> sip/sips and pres, not have any > > > > >>> http(s) resolution text, and not propose a parameter and > > > > >>> accompanying registry. > > > > >> > > > > >> I certainly think it's more prudent to define the > dereferencing > > > > > mechanism > > > > >> prior to making claims about the protocol. > > > > >> > > > > >> Do I believe location-by-reference will happen? Probably, > > > > but making > > > > >> assumptions about the mechanism now is quite premature. > > > > >> > > > > >> -Marc- > > > > >> > > > > >>> > > > > >>> If this does not reflect your position, please speak up now. > > > > >>> > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use > > > > > sip-implementors@cs.columbia.edu for questions on current sip > > > > > Use sipping@ietf.org for new developments on the > application of > > > > > sip > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 09:13:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jAQ-0004TU-35; Wed, 26 Jul 2006 09:11:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jAP-0004TL-7P; Wed, 26 Jul 2006 09:11:13 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5jAM-0000AL-TB; Wed, 26 Jul 2006 09:11:13 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Jul 2006 06:11:11 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,184,1151910000"; d="scan'208"; a="33425462:sNHT21326452" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6QDBAWa024389; Wed, 26 Jul 2006 09:11:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6QDBAYh019587; Wed, 26 Jul 2006 09:11:10 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 09:11:10 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 09:11:09 -0400 Message-ID: <44C769ED.3030000@cisco.com> Date: Wed, 26 Jul 2006 09:11:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <017501c6b0b3$ae83ddf0$1f0d0d0a@amer.cisco.com> In-Reply-To: <017501c6b0b3$ae83ddf0$1f0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2006 13:11:09.0774 (UTC) FILETIME=[F6326EE0:01C6B0B4] DKIM-Signature: a=rsa-sha1; q=dns; l=390; t=1153919470; x=1154783470; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=20loca tion-conveyance |To:Marc=20Linsner=20; X=v=3Dcisco.com=3B=20h=3DWqQNef9hL0KxzZFFo+VrZdN23VU=3D; b=WbPCXZXI77Piw3NAxp60JgjdHE+L9xiolE54nlw/oa7WXdLcsZ8OXwW/sn2LcT26wjVrnwg+ KnL/Wt6GA9gVHGiFZKw43tT5Nk09wtlhFI68FZtN+D+zew1XRdu3Fbuf; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: geopriv@ietf.org, "'Peterson, Jon'" , sip@ietf.org, "'Rosen, Brian'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Marc Linsner wrote: > In-line... > >> So, you are arguing against proxy insertion of a >> location-by-reference? > > No, if done properly....but reading the latest threads, I get the feeling > that www.whereintheworldisbrianrosen.com is an acceptable reference. Damn! I was hoping, but www.whereintheworldisbrianrosen.com doesn't seem to be working today. :-( Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 09:14:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jBr-0004vz-Fh; Wed, 26 Jul 2006 09:12:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jBp-0004v2-Ur; Wed, 26 Jul 2006 09:12:41 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5jBo-0000Lx-Os; Wed, 26 Jul 2006 09:12:41 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6QDCWox017270; Wed, 26 Jul 2006 13:12:32 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 09:12:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 09:12:30 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcawtPdBJwNlqPhKQj+Rp5O/wrDqdAAAB3ow From: "Rosen, Brian" To: "Paul Kyzivat" , "Marc Linsner" X-OriginalArrivalTime: 26 Jul 2006 13:12:32.0268 (UTC) FILETIME=[275E04C0:01C6B0B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip@ietf.org, geopriv@ietf.org, "Peterson, Jon" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm in (on?) Mars today, but the ISP doesn't seem to be responding > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, July 26, 2006 9:11 AM > To: Marc Linsner > Cc: 'Brian Rosen'; Peterson, Jon; 'Andrew Newton'; Rosen, Brian; > sip@ietf.org; geopriv@ietf.org > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- > conveyance >=20 >=20 >=20 > Marc Linsner wrote: > > In-line... > > > >> So, you are arguing against proxy insertion of a > >> location-by-reference? > > > > No, if done properly....but reading the latest threads, I get the > feeling > > that www.whereintheworldisbrianrosen.com is an acceptable reference. >=20 > Damn! I was hoping, but www.whereintheworldisbrianrosen.com doesn't seem > to be working today. :-( >=20 > Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 10:01:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jum-0004Px-TL; Wed, 26 Jul 2006 09:59:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jum-0004Pa-1b; Wed, 26 Jul 2006 09:59:08 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5juk-0000XR-Pq; Wed, 26 Jul 2006 09:59:08 -0400 Received: from lion.cs.columbia.edu (IDENT:0iSPikb5xVUwIt5xG04TbrPVLa2miCyu@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6QDuf4F004907 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 26 Jul 2006 09:58:53 -0400 (EDT) Received: from [192.168.0.41] (pool-141-153-188-67.mad.east.verizon.net [141.153.188.67]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6QDuWor026363 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 26 Jul 2006 09:56:39 -0400 In-Reply-To: References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 09:56:14 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.26.62932 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='RCVD_IN_NJABL_ORG 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: geopriv@ietf.org, "Peterson, Jon" , sip@ietf.org, 'Marc Linsner' , "Rosen, Brian" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think these are reasonable guidelines unless we're suddenly very selective about when privacy applies (or limit l-by-r to emergency calling in certain no-consent-required jurisdictions). Specifying the precise 'limited amount of time' is probably something that local regulations need to address. On Jul 25, 2006, at 8:17 PM, Andrew Newton wrote: > > On Jul 25, 2006, at 7:21 PM, Jeroen van Bemmel wrote: >> For location-by-reference, you'd probably want some additional >> requirements: >> - URL must be valid for a limited amount of time >> - URL must be cryptographically hard to guess >> - URL must not contain any information that identifies the user / >> device / AoR >> - for whatever transport protocol is used: response must be marked >> as 'no cache' >> - user must be able to remove the information at the URL, ie >> explicit invalidation >> - user must be able to verify correctness of the issued >> information (ie user can access the URL himself) >> - user must be able to control who accesses the URL, both upfront >> and history of accesses (for a reasonable period) >> - there must be explicit consent before a proxy would insert user >> location > > > > Just thinking out loud here, but maybe the rule should be that > proxies never append a Location header except for emergencies. I think that's desirable unless there's a clear indication by the caller to do otherwise, by some consent mechanism. However, by the time you implement the consent mechanism, you've probably already implemented the better UAC-based mechanism, so it seems hard to argue for that complexity. The only technical argument I've heard for proxy insertion is legacy equipment, where requiring adding consent flags is clearly a non-starter. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 10:03:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jx7-00062k-Ve; Wed, 26 Jul 2006 10:01:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jx7-00062c-4p; Wed, 26 Jul 2006 10:01:33 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5jx5-0001Lb-Sq; Wed, 26 Jul 2006 10:01:33 -0400 Received: from lion.cs.columbia.edu (IDENT:u0WeBH/QWApRNsIbDqFcoOfFWNAacT7x@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6QDxt4F005804 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 26 Jul 2006 10:01:26 -0400 (EDT) Received: from [192.168.0.41] (pool-141-153-188-67.mad.east.verizon.net [141.153.188.67]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6QDxqoq026673 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 26 Jul 2006 09:59:54 -0400 In-Reply-To: <024e01c6b046$b1b36080$640fa8c0@cis.neustar.com> References: <024e01c6b046$b1b36080$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <640F9ED9-0217-4407-A25C-54381D2520A2@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 09:59:42 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.26.64432 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='RCVD_IN_NJABL_ORG 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: geopriv@ietf.org, "Peterson, Jon" , sip@ietf.org, 'Marc Linsner' , "Rosen, Brian" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Proxy insertion of location, whether by value or by reference has > the threat > of not being as subject to user control, but I think in every case > you have > to trust your provider to do as you wish, whether it is your presence > provider or your location provider independent of your presence > provider, > and proxy insertion doesn't fundamentally alter that. I worry more > about > it, but I don't objectively think it's much different. It is slightly different: For the presence provider, I can fairly easily verify whether the presence provider does what I tell him to do (unless the presence provider is clearly violating my privacy rules, which is probably subject to legal breach-of-contract recourse in most jurisdictions). This is much harder to do with proxy insertion. > sufficiently, and we have RFCs that permit it. Adding restrictions > on the > The only one that permits is the presence subscription model, which gives the target/rule maker a lot of control of who can do what with my location data. I can, on a person-by-person basis, restrict access to that data. If my proxy inserts some location object or reference to it that it made up, I don't even control the privacy rules in the object returned. > > I kind of like the idea that the proxy inserts the header in the > response so > the UAC can see it. What do others think of that? > This is probably a good idea, but imposes additional restrictions on the longevity of the reference. How long should I be able to "see" it? We don't want LIS to keep the location data around any longer than is needed, but there are no expectations set of what's reasonable. By-value doesn't suffer from these problems. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 10:08:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5k1z-0008Oa-Nh; Wed, 26 Jul 2006 10:06:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5k1y-0008OV-Ea for sip@ietf.org; Wed, 26 Jul 2006 10:06:34 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5k1x-00031Z-6E for sip@ietf.org; Wed, 26 Jul 2006 10:06:34 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k6QE6WhV006853; Wed, 26 Jul 2006 09:06:32 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k6QE6WT04524; Wed, 26 Jul 2006 09:06:32 -0500 (CDT) Message-ID: <44C776E7.3040800@lucent.com> Date: Wed, 26 Jul 2006 09:06:31 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Update to fork-loop-fix submitted References: <009001c6b08b$c14e3a70$31713b51@BEMBUSTER> In-Reply-To: <009001c6b08b$c14e3a70$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Robert, > > With respect to Open Issue 3 (Proxy-Authorization and Proxy-Require) > it is worth noting (restating actually, this has been pointed out > before somewhere) that including them means that loop detection > cannot be used when forwarding CANCEL or ACK to non-2xx: > > - for both, branch must match the INVITE, so outcome of loop hash > must match > > - Proxy-Require/Proxy-Authorization won't appear in CANCEL or ACK to > non-2xx (since these are generated hop-by-hop, and also because both > are not allowed in CANCEL) Why would you want to do a loop detection for CANCELs and ACKs to non-2xx? In the latter case, you can't send a response anyway. As long as the branch parameter for CANCELs and ACKs to non-2xx matches a pending INVITE transaction, the state machines can be updated accordingly. > So whatever the reasons were for including them, there are reasons > for *not* including them Looking at the notes from the WG, it is not apparent we know now why we had incldued these in the first place. FWIW, in our loop detection code, we do not include these and the interop that we have done with loop detection has worked without any problems. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 10:12:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5k61-0002e6-7L; Wed, 26 Jul 2006 10:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5k5z-0002dm-Jz; Wed, 26 Jul 2006 10:10:43 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5k5y-0003pS-DK; Wed, 26 Jul 2006 10:10:43 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Wed, 26 Jul 2006 10:10:51 -0400 id 01588179.44C777EC.00003713 Message-ID: <44C777D8.9030008@hxr.us> Date: Wed, 26 Jul 2006 10:10:32 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu> In-Reply-To: <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: geopriv@ietf.org, "Peterson, Jon" , sip@ietf.org, 'Marc Linsner' , "Rosen, Brian" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Henning Schulzrinne wrote: > On Jul 25, 2006, at 8:17 PM, Andrew Newton wrote: >> Just thinking out loud here, but maybe the rule should be that proxies >> never append a Location header except for emergencies. > > I think that's desirable unless there's a clear indication by the caller > to do otherwise, by some consent mechanism. However, by the time you > implement the consent mechanism, you've probably already implemented the > better UAC-based mechanism, so it seems hard to argue for that > complexity. The only technical argument I've heard for proxy insertion > is legacy equipment, where requiring adding consent flags is clearly a > non-starter. I believe there are two technical arguments: one is legacy equipment (the issue that I'll be facing for quite some time), and environments where the location is generated by the network. For the latter, insertion of the Location header only in emergency situations still puts the user in control for non-emergency situations. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 11:06:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5kw6-0003Tn-SC; Wed, 26 Jul 2006 11:04:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5kw5-0003TT-A8; Wed, 26 Jul 2006 11:04:33 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5kw3-00012o-TY; Wed, 26 Jul 2006 11:04:33 -0400 Received: from lion.cs.columbia.edu (IDENT:vjF5fRmzzuqVGNQF4VO+a820rVyL4lEp@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6QF4S4F028898 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 26 Jul 2006 11:04:28 -0400 (EDT) Received: from [192.168.0.41] (pool-141-153-188-67.mad.east.verizon.net [141.153.188.67]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6QF4Qoq030859 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 26 Jul 2006 11:04:28 -0400 In-Reply-To: <44C777D8.9030008@hxr.us> References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu> <44C777D8.9030008@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 11:04:20 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.26.74432 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='RCVD_IN_NJABL_ORG 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: geopriv@ietf.org, IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > I believe there are two technical arguments: one is legacy > equipment (the issue that I'll be facing for quite some time), and > environments where the location is generated by the network. For > the latter, insertion of the Location header only in emergency > situations still puts the user in control for non-emergency > situations. > > For the latter, the combination of the in-progress L7 protocols, DHCP and LLDP should presumably allow the UAC to obtain location and insert it by value. Is there a use case not covered by that? > -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 11:09:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5kzF-00064k-Vk; Wed, 26 Jul 2006 11:07:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5kzF-00061f-8V; Wed, 26 Jul 2006 11:07:49 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5kzE-0001tp-1W; Wed, 26 Jul 2006 11:07:49 -0400 Received: from lion.cs.columbia.edu (IDENT:BI9ZvKkIdvRZkeV0oHplMoqnGIteadsb@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6QF7k4F029795 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 26 Jul 2006 11:07:47 -0400 (EDT) Received: from [192.168.0.41] (pool-141-153-188-67.mad.east.verizon.net [141.153.188.67]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6QF7joq030878 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 26 Jul 2006 11:07:46 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <675A6DE0-E197-4954-A060-7AFACF9EDD76@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Wed, 26 Jul 2006 11:07:39 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.26.74432 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='RCVD_IN_NJABL_ORG 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: IETF SIP List , geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Why do you think we must specify an HTTP dereference procedure in this > document? What is the purpose when the SIP based method is available? Unless you care about performance. I suspect that the SIP approach will take at least twice as many server resources as the HTTP approach (which will, in turn, take twice as much server capacity as the by-value approach). Strangely, ease of implementation and speed don't seem to matter in this discussion, so maybe that's a non-issue. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 11:16:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5l5a-0001Xe-7z; Wed, 26 Jul 2006 11:14:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5l5Y-0001XA-L0; Wed, 26 Jul 2006 11:14:20 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5l5X-0002Kw-Dr; Wed, 26 Jul 2006 11:14:20 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Wed, 26 Jul 2006 11:14:28 -0400 id 01588177.44C786D5.00004318 Message-ID: <44C786C2.4000206@hxr.us> Date: Wed, 26 Jul 2006 11:14:10 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu> <44C777D8.9030008@hxr.us> <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> In-Reply-To: <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: geopriv@ietf.org, IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Henning Schulzrinne wrote: >> I believe there are two technical arguments: one is legacy equipment >> (the issue that I'll be facing for quite some time), and environments >> where the location is generated by the network. For the latter, >> insertion of the Location header only in emergency situations still >> puts the user in control for non-emergency situations. >> >> > > For the latter, the combination of the in-progress L7 protocols, DHCP > and LLDP should presumably allow the UAC to obtain location and insert > it by value. Is there a use case not covered by that? As I said, where location comes from the network. In this scenario, there are two possibilities, both up to the user: 1) the UAC subscribes to the location from the network and puts it by value in the call flow... meaning all location updates go through the UAC, or 2) the UAC hands out a reference so updates can be independent of the UAC or updates based on subscription come from the UAC but are independent of the call. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 11:35:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lNu-0003tC-Ha; Wed, 26 Jul 2006 11:33:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lNt-0003rq-RJ for sip@ietf.org; Wed, 26 Jul 2006 11:33:17 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5lNs-0004AE-Cs for sip@ietf.org; Wed, 26 Jul 2006 11:33:17 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 26 Jul 2006 08:33:15 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6QFXF3A022954; Wed, 26 Jul 2006 08:33:15 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6QFXFHS008616; Wed, 26 Jul 2006 08:33:15 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 11:33:14 -0400 Received: from [161.44.55.123] ([161.44.55.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 11:33:14 -0400 Message-ID: <44C78B3A.3070903@cisco.com> Date: Wed, 26 Jul 2006 11:33:14 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" Subject: Re: [Sip] Hitchhikers guide - when is it done? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2006 15:33:14.0556 (UTC) FILETIME=[CF5CEFC0:01C6B0C8] DKIM-Signature: a=rsa-sha1; q=dns; l=2876; t=1153927995; x=1154791995; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Hitchhikers=20guide=20-=20when=20is=20it=20done?; X=v=3Dcisco.com=3B=20h=3DDpAaA9rWoxuoASPdrDDBO7lqI1E=3D; b=vHDjj303IHyVi7nZWCWDj/twL77yPCnk+x1cvXgyewe8u/hvo4yPamlV/ngE+jVB63JP4HQf jOlKWlINpyTiEKhVjnV9RiOJ9HVaskFGOdy0F5vAssgF7dhELJwTmXRu; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The problem with any kind of website reference is that they are never 'official'. There are countless web sites enumerating SIP related documents. What makes something an official output of the IETF is that its an RFC. -Jonathan R. Romascanu, Dan (Dan) wrote: > Because of the overhead and clerical delays involved in the publication > of RFCs I would suggest a refinement to option 2. Provide a reference in > the RFC to a Web page maintained and refreshed by the SIP WG or the RAI > Area including the 'to-the-best-of-our-knowledge' updates in-between two > versions of the RFC. > > Dan > > > > > > > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: Tuesday, July 25, 2006 8:56 PM >>To: IETF SIP List >>Subject: [Sip] Hitchhikers guide - when is it done? >> >>During the IETF meeting, I discussed the one current open >>issue in the Hitchhikers guide. The issue is: when does the >>document finish? When do we send to IESG to issue an RFC? >> >>There were two approaches: >> >>1. split the document in two. One part contains only the core >>specs, and issues relatively soon. The other part has >>everything else, and basically ends up being the last RFC >>produced by the SIP WG before it shuts its doors (which has >>always been 1.5 years from now for the last 5 years). >> >>2. keep it as one document. Issue an RFC at some point, and >>then revise it a few times as needed. We need to decide when >>to issue it. >> >> >>I'd like to propose option 2. I think people get more value >>from it as a >>consolidated document. Furthermore, I'd propose that we send the >>document to IESG for consideration as informational at the >>instant all >>of the documents listed as 'core' have RFC numbers issued by RFC-ed. >> >>Comments? >> >>-Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Cisco Fellow Parsippany, NJ >>07054-2711 >>Cisco Systems >>jdrosen@cisco.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.cisco.com >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 11:36:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lPU-0004dp-W4; Wed, 26 Jul 2006 11:34:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lPU-0004dk-8x for sip@ietf.org; Wed, 26 Jul 2006 11:34:56 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5lPS-0004In-R7 for sip@ietf.org; Wed, 26 Jul 2006 11:34:56 -0400 Received: (qmail 12204 invoked by uid 0); 26 Jul 2006 15:34:53 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 Jul 2006 15:34:53 -0000 Message-ID: <011501c6b0c9$09681910$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Henning Schulzrinne" , "Andrew Newton" References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu><44C777D8.9030008@hxr.us> <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 17:34:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: geopriv@ietf.org, IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> I believe there are two technical arguments: one is legacy >> equipment (the issue that I'll be facing for quite some time), and >> environments where the location is generated by the network. For the >> latter, insertion of the Location header only in emergency situations >> still puts the user in control for non-emergency situations. >> >> > > For the latter, the combination of the in-progress L7 protocols, DHCP and > LLDP should presumably allow the UAC to obtain location and insert it by > value. Is there a use case not covered by that? With the current proposals (location by value in body): the use case for a location based routing service, where my location does not get passed to the selected targets It is possible to do a redirect-based callflow, but that has several drawbacks: - more complex, requires extensions beyond basic RFC3261 - inefficient signalling - adds delay - no parallel forking possible (though some would call this a benefit) The data: URI in combination with a 'Proxy-Require: remove-location' flag would solve all these nicely Regards, Jeroen PS I suppose one could put PIDF-LO in a SAML artifact. At the very least, http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-00.txt section 7.1 and http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf may provide some ideas for a HTTP-based location-by-reference profile _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 12:02:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5loP-0004ga-JO; Wed, 26 Jul 2006 12:00:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5loO-0004fS-In; Wed, 26 Jul 2006 12:00:40 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5loM-0006GM-BZ; Wed, 26 Jul 2006 12:00:40 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Wed, 26 Jul 2006 12:00:47 -0400 id 01588179.44C791B0.00004DF5 Message-ID: <44C7919D.1010203@hxr.us> Date: Wed, 26 Jul 2006 12:00:29 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu><44C777D8.9030008@hxr.us> <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> <011501c6b0c9$09681910$31713b51@BEMBUSTER> In-Reply-To: <011501c6b0c9$09681910$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: geopriv@ietf.org, IETF SIP List , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > >>> I believe there are two technical arguments: one is legacy >>> equipment (the issue that I'll be facing for quite some time), and >>> environments where the location is generated by the network. For >>> the latter, insertion of the Location header only in emergency >>> situations still puts the user in control for non-emergency situations. >>> >>> >> >> For the latter, the combination of the in-progress L7 protocols, DHCP >> and LLDP should presumably allow the UAC to obtain location and >> insert it by value. Is there a use case not covered by that? > > With the current proposals (location by value in body): the use case for > a location based routing service, where my location does not get passed > to the selected targets > > It is possible to do a redirect-based callflow, but that has several > drawbacks: > - more complex, requires extensions beyond basic RFC3261 > - inefficient signalling > - adds delay > - no parallel forking possible (though some would call this a benefit) > > The data: URI in combination with a 'Proxy-Require: remove-location' > flag would solve all these nicely So now we are talking about the data: URI being used in non-emergency cases? Certainly if a UAC can put a data: URI in an INVITE, it can also put a PIDF-LO in a MIME part. With regard to the data: URI, how does that work with a CID URI in the ruleset-reference? I would guess that in the emergency case, there wouldn't be one. But in the non-emergency case.... -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 12:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5mY0-0005PW-Kh; Wed, 26 Jul 2006 12:47:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5mXz-0005Ot-BI; Wed, 26 Jul 2006 12:47:47 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5mXw-00015T-3W; Wed, 26 Jul 2006 12:47:47 -0400 Received: from lion.cs.columbia.edu (IDENT:XDkFGDm0NQEMJhG43pYbnsEOWfc6kjMe@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6QGle4F024684 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 26 Jul 2006 12:47:40 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6QGldoq004605 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Jul 2006 12:47:40 -0400 Message-ID: <44C79CA6.5040604@cs.columbia.edu> Date: Wed, 26 Jul 2006 12:47:34 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu><44C777D8.9030008@hxr.us> <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> <011501c6b0c9$09681910$31713b51@BEMBUSTER> <44C7919D.1010203@hxr.us> In-Reply-To: <44C7919D.1010203@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.26.92432 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: geopriv@ietf.org, IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > With regard to the data: URI, how does that work with a CID URI in the > ruleset-reference? I would guess that in the emergency case, there > wouldn't be one. But in the non-emergency case.... I'm afraid I don't understand the issue. The ruleset reference wouldn't seem to be affected by where and how it is carried. Can you explain? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 13:47:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5nSG-0005jL-1o; Wed, 26 Jul 2006 13:45:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5nSE-0005j0-Jc; Wed, 26 Jul 2006 13:45:54 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5nSC-00077F-Ch; Wed, 26 Jul 2006 13:45:54 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Wed, 26 Jul 2006 13:46:01 -0400 id 0158817A.44C7AA5A.000061D6 Message-ID: <44C7AA47.4080104@hxr.us> Date: Wed, 26 Jul 2006 13:45:43 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu><44C777D8.9030008@hxr.us> <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> <011501c6b0c9$09681910$31713b51@BEMBUSTER> <44C7919D.1010203@hxr.us> <44C79CA6.5040604@cs.columbia.edu> In-Reply-To: <44C79CA6.5040604@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: geopriv@ietf.org, IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Henning Schulzrinne wrote: > >> With regard to the data: URI, how does that work with a CID URI in the >> ruleset-reference? I would guess that in the emergency case, there >> wouldn't be one. But in the non-emergency case.... > > I'm afraid I don't understand the issue. The ruleset reference wouldn't > seem to be affected by where and how it is carried. Can you explain? So are saying there will be a likely scenario where a ruleset-reference in a PIDF-LO encoded into a data: URI and inserted by a proxy will reference a MIME part that already exists? -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 14:23:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5o18-0007bA-IL; Wed, 26 Jul 2006 14:21:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5o17-0007aq-EY; Wed, 26 Jul 2006 14:21:57 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5o16-00011x-51; Wed, 26 Jul 2006 14:21:57 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Jul 2006 11:21:56 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6QILtR1003422; Wed, 26 Jul 2006 11:21:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6QILt2F010880; Wed, 26 Jul 2006 11:21:55 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 11:21:55 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.87]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 11:21:54 -0700 Message-Id: <4.3.2.7.2.20060726131930.03b5def8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2006 13:21:51 -0500 To: "Drage, Keith \(Keith\)" , "John Schnizlein" , "Drage, Keith \(Keith\)" From: "James M. Polk" In-Reply-To: <5D1A7985295922448D5550C94DE2918013B316@DEEXC1U01.de.lucent .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Jul 2006 18:21:54.0930 (UTC) FILETIME=[5F937520:01C6B0E0] DKIM-Signature: a=rsa-sha1; q=dns; l=549; t=1153938115; x=1154802115; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Geopriv]=20Location-by-value=20in=20a=20SIP=20Location=20Header; X=v=3Dcisco.com=3B=20h=3D9Ow8o0pSEUCW2kexDkZy6zUVk10=3D; b=R/RiDHedTeaSb16gwoOT/f5ieln6Jy3bspgk6EL9BvwvfdYheWtkVCkh+qNVubhPO32ufCXc BDZCda1H+rVyXxOdntvh+ZiAN2jSQw69gARQF0s86TYZIora12zyut5A; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: geopriv@ietf.org, sip@ietf.org Subject: [Sip] RE: [Geopriv] Location-by-value in a SIP Location Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 10:34 PM 7/24/2006 +0200, Drage, Keith \(Keith\) wrote: >Well all I can say is that it has been there from the >draft-ietf-sip-location-conveyance-01 version (dated July 17th 2005) >which was explicitly presented in the Paris IETF#63 SIP WG meeting in >August 2005. > >Unfortunately the minutes are not particularly helpful in terms of WG >discussion at that time. this is because there was a multi-mike free-for-all in the suggestions, comments and attacks on the presenter :-/ I'm not surprised the note taker didn't keep up _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 16:00:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5pWu-0006lC-LX; Wed, 26 Jul 2006 15:58:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5pWt-0006kD-RX; Wed, 26 Jul 2006 15:58:51 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5pWs-0003Dr-Jh; Wed, 26 Jul 2006 15:58:51 -0400 Received: from lion.cs.columbia.edu (IDENT:vHlrZwQGt3h+Keosz9euX/RYEqPSrsHF@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6QJtp4F004253 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 26 Jul 2006 15:58:44 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6QJtmoq016257 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Jul 2006 15:55:50 -0400 Message-ID: <44C7C8BF.4010103@cs.columbia.edu> Date: Wed, 26 Jul 2006 15:55:43 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu><44C777D8.9030008@hxr.us> <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> <011501c6b0c9$09681910$31713b51@BEMBUSTER> <44C7919D.1010203@hxr.us> <44C79CA6.5040604@cs.columbia.edu> <44C7AA47.4080104@hxr.us> In-Reply-To: <44C7AA47.4080104@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.26.123933 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: geopriv@ietf.org, IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > So are saying there will be a likely scenario where a ruleset-reference > in a PIDF-LO encoded into a data: URI and inserted by a proxy will > reference a MIME part that already exists? We may be talking past each other. Currently, RFC 4119 has I assume you're talking about the external-ruleset element. Regardless of how the rest of the GEOPRIV object is carried, this can point anywhere, including some static web object, a cid, or even be another data URL if you want to carry the policy along with the actual location information. Clearly, a cid would be rather implausible if the URL was inserted by the proxy. If this is location by reference, the options for the URL would be the same, except for cid. If this is a location object carried in the body, it could be any of the things I mentioned above. The same is true for the Location-by-value option. As you can probably tell, I'm a bit confused as to why this is an issue, so I'm probably belaboring what's obvious to you. > > -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 16:14:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5pjq-0000PM-Lm; Wed, 26 Jul 2006 16:12:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ntU-00043R-7m; Wed, 26 Jul 2006 14:14:04 -0400 Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ntS-0000Z6-SW; Wed, 26 Jul 2006 14:14:04 -0400 Received: from rrc-dte-ieg01.cc.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k6QIE1D26559; Wed, 26 Jul 2006 14:14:01 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006072614140027395 ; Wed, 26 Jul 2006 14:14:00 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 Jul 2006 14:12:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jul 2006 14:14:00 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Consensus on changes to location-conveyance thread-index: AcawERldoiEvROTuT2KasGKrfOW37QAzWneQ From: "Abbott, Nadine B" To: X-OriginalArrivalTime: 26 Jul 2006 18:12:03.0381 (UTC) FILETIME=[FEFC3E50:01C6B0DE] X-Spam-Score: 0.5 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Wed, 26 Jul 2006 16:12:12 -0400 Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 I don't agree that there is a consensus to preclude the use of HTTP.=20 I would favor not placing your proposed restriction on the URI scheme for expressing a location reference in the SIP location conveyance draft; or at least including HTTP as a valid location-reference URI type. Regards, Nadine Abbott -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Tuesday, July 25, 2006 1:38 PM To: sip@ietf.org Cc: geopriv@ietf.org Subject: [Geopriv] Consensus on changes to location-conveyance I have put out a number of emails on proposed changes to location conveyance. Some of them have sparked a number of comments. My summary of consensus on these issues is: 1. We proposed to explicitly disallow use of a Data URI, which would allow specification of a Location-by-value in a header. There was a lot of list traffic on this, currently in the state where Keith asked for a real use case for it. So far, we don't see a use case that cannot be provided by location-by-reference in a header. If we don't get a good use case, I think consensus is to disallow location-by-value in a header. 2. Dereferencing location-by-reference. We had initially proposed to document a process to use a raw HTTP(S) Get to dereference. There was a lot of discussion, and then I made a new proposal, see item 6.=20 3. We proposed to allow a Reason header with a 424 Bad Location response. This seems to be acceptable to the WG. Geopriv will create and populate the registry in a separate draft. 4. We proposed to explicitly allow hop-by-hop TLS security for location when the endpoint wished to allow routing based on location. We further proposed to interpret "Do not Distribute" flags as allowing sending of the location to the routing database (LoST for example). Hannes pointed out that there was a proposal to allow two Location headers, one of which could be used for routing and another for onward forwarding to the recipient. Hannes' message seemed to agree that "Do not distribute" would allow sending of the location to the routing-by-location database, but would obligate the proxy that did that to remove the location before it forwarded the message. There were no other messages on this thread. We conclude that allowing hop-by-hop security for location based routing is acceptable, and Do Not Distribute DOES allow forwarding to a routing database, but requires that the proxy doing the location based route to remove the location it uses for that purpose. 5. We proposed to create a parameter and a registry to distinguish multiple ways to dereference a location where HTTP(S) was the transport. Resolution of this issue depends on resolution of issue 6. 6. We proposed to allow sip/sips and pres: in the location header. I later speculated that if we allow this, it forms a simple way to do location-by-reference, and we could eliminate the raw HTTP(S) Get proposal, with the parameter and registry entirely. There was some list traffic in favor of this. Martin Thompson is skeptical that SIP Presence Subscribe/Notify is actually allowed as a geopriv "using protocol". Several of think that it is. If we don't get any more comments on this proposal, we will allow sip/sips and pres, not have any http(s) resolution text, and not propose a parameter and accompanying registry. If this does not reflect your position, please speak up now. Brian _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 16:51:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5qJc-0005WL-66; Wed, 26 Jul 2006 16:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5qJa-0005W1-Mz; Wed, 26 Jul 2006 16:49:10 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5qJZ-0002o2-FH; Wed, 26 Jul 2006 16:49:10 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Wed, 26 Jul 2006 16:49:18 -0400 id 01588025.44C7D54F.00000856 Message-ID: <44C7D53C.3020205@hxr.us> Date: Wed, 26 Jul 2006 16:49:00 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu><44C777D8.9030008@hxr.us> <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> <011501c6b0c9$09681910$31713b51@BEMBUSTER> <44C7919D.1010203@hxr.us> <44C79CA6.5040604@cs.columbia.edu> <44C7AA47.4080104@hxr.us> <44C7C8BF.4010103@cs.columbia.edu> In-Reply-To: <44C7C8BF.4010103@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: geopriv@ietf.org, IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Henning Schulzrinne wrote: > We may be talking past each other. Currently, RFC 4119 has > > > > minOccurs="0" maxOccurs="1"/> > minOccurs="0" maxOccurs="1"/> > minOccurs="0" maxOccurs="1"/> > minOccurs="0" maxOccurs="1"/> > maxOccurs="unbounded"/> > > > > I assume you're talking about the external-ruleset element. Regardless > of how the rest of the GEOPRIV object is carried, this can point > anywhere, including some static web object, a cid, or even be another > data URL if you want to carry the policy along with the actual location > information. Hmmm... we seem to have caught a bug in 4119. Because the descriptive text calls that element 'ruleset-reference' and not 'external-ruleset'. Anyway, from the text (page 8): This URI SHOULD use the HTTPS URI scheme; and if it does, the server that holds these rules MUST authenticate any attempt to access these rules. Usage rules themselves may divulge private information about a Target or Rule Maker. The URI MAY, alternatively, use the CID URI scheme [7], in which case it MUST denote a MIME body carried with the Location Object by the using protocol. In other words, it would appear that the list of URIs allowed is HTTPS or CID (though this doc SHOULD be more explicit). data: is not mentioned. This means that a PIDF-LO with a CID reference cannot be converted to a data: URI. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 17:45:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5rAJ-0004wx-27; Wed, 26 Jul 2006 17:43:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5rAH-0004wk-6d; Wed, 26 Jul 2006 17:43:37 -0400 Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5rAE-0001XY-OO; Wed, 26 Jul 2006 17:43:37 -0400 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k6QLhXb08558; Wed, 26 Jul 2006 17:43:33 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006072617433228561 ; Wed, 26 Jul 2006 17:43:32 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 Jul 2006 17:41:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jul 2006 17:43:32 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Consensus on changes to location-conveyance thread-index: AcawERldoiEvROTuT2KasGKrfOW37QAzWneQAAHSzSAABUfloA== From: "Abbott, Nadine B" To: "Brian Rosen" , X-OriginalArrivalTime: 26 Jul 2006 21:41:07.0026 (UTC) FILETIME=[33949320:01C6B0FC] X-Spam-Score: 0.5 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, Actually, I was thinking that in other industry work which is trying to leverage and provide transitional strategies to migrate to using SIP to support emergency services, the and long-term solutions that we have defined assume a capabity to provide location-by-reference. I think it would be very useful to have this defined in a standard SIP header mechanism in such a way that we need not redefine migratory solutions that have begun to be implemented. If an HTTPS URI can be used as the location-by-reference, this will be helpful, I think. =20 I don't understand your urgency to make location-by-reference only an all-sip-all-the-time thing. And from all the other emails on this topic, it didn't seem to me that there is a consensus to do this. Nadine=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, July 26, 2006 3:15 PM To: Abbott, Nadine B; sip@ietf.org Cc: geopriv@ietf.org Subject: RE: [Geopriv] Consensus on changes to location-conveyance Nadine Are you saying that it's your opinion sip-location-conveyance MUST define an HTTP dereference procedure? If you do, why? What is the use-case or requirement? Would it not be pretty reasonable to require a separate document that defines a location-by-reference mechanism, protocol, and geopriv "using protocol" analysis? If that document specifically extended what was allowed in the location header, would that not be reasonable? I think we have to include "A" dereference mechanism in the location-conveyance document. It seems just including sip/sips/prez is a reasonable, all-sip-all-the-time approach IN THIS DOCUMENT. That certainly does not preclude another document describing another way. Doesn't it seem just a little weird to have a sip-location-conveyance document describing any kind of http based location conveyance (de-reference) protocol, especially one created whole cloth without any other parts? Doesn't it seem in keeping with the geopriv approach that in order to have another "using protocol" it has to have a geopriv review? That is what leads to restricting the URI schemes. Would you prefer to let it be wide open, so any protocol anyone thinks about can be used with the location header? I can't see geopriv going along with that. We're going to make it a one line ABNF to add a new scheme to the list of allowed schemes. It seems to me that if it's desired to define some bare-bones HTTP location by reference protocol, then that should be a separate document, which can easily extend the allowable schemes in the Location header. I'm not sure it might be better to define ALL of that in the L7 protocol, but I wouldn't be opposed to a simple "raw GET" RFC as long as it got a full geopriv review. I just don't see where it makes any sense to force that into a sip document. Brian > -----Original Message----- > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > Sent: Wednesday, July 26, 2006 2:14 PM > To: sip@ietf.org > Cc: geopriv@ietf.org > Subject: RE: [Geopriv] Consensus on changes to location-conveyance >=20 >=20 > I don't agree that there is a consensus to preclude the use of HTTP. > I would favor not placing your proposed restriction on the URI scheme=20 > for expressing a location reference in the SIP location conveyance=20 > draft; or at least including HTTP as a valid location-reference URI=20 > type. >=20 > Regards, > Nadine Abbott >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Tuesday, July 25, 2006 1:38 PM > To: sip@ietf.org > Cc: geopriv@ietf.org > Subject: [Geopriv] Consensus on changes to location-conveyance >=20 > I have put out a number of emails on proposed changes to location=20 > conveyance. Some of them have sparked a number of comments. My=20 > summary of consensus on these issues is: >=20 > 1. We proposed to explicitly disallow use of a Data URI, which would=20 > allow specification of a Location-by-value in a header. There was a=20 > lot of list traffic on this, currently in the state where Keith asked=20 > for a real use case for it. So far, we don't see a use case that=20 > cannot be provided by location-by-reference in a header. If we don't=20 > get a good use case, I think consensus is to disallow=20 > location-by-value in a header. >=20 > 2. Dereferencing location-by-reference. We had initially proposed to=20 > document a process to use a raw HTTP(S) Get to dereference. There was > a lot of discussion, and then I made a new proposal, see item 6. >=20 > 3. We proposed to allow a Reason header with a 424 Bad Location=20 > response. This seems to be acceptable to the WG. Geopriv will create > and populate the registry in a separate draft. >=20 > 4. We proposed to explicitly allow hop-by-hop TLS security for=20 > location when the endpoint wished to allow routing based on location. > We further proposed to interpret "Do not Distribute" flags as allowing > sending of the location to the routing database (LoST for example). =20 > Hannes pointed out that there was a proposal to allow two Location=20 > headers, one of which could be used for routing and another for onward > forwarding to the recipient. Hannes' message seemed to agree that "Do not distribute" > would allow sending of the location to the routing-by-location=20 > database, but would obligate the proxy that did that to remove the=20 > location before it forwarded the message. There were no other messages on this thread. > We conclude that allowing hop-by-hop security for location based=20 > routing is acceptable, and Do Not Distribute DOES allow forwarding to=20 > a routing database, but requires that the proxy doing the location=20 > based route to remove the location it uses for that purpose. >=20 > 5. We proposed to create a parameter and a registry to distinguish=20 > multiple ways to dereference a location where HTTP(S) was the transport. > Resolution of this issue depends on resolution of issue 6. >=20 > 6. We proposed to allow sip/sips and pres: in the location header. I=20 > later speculated that if we allow this, it forms a simple way to do=20 > location-by-reference, and we could eliminate the raw HTTP(S) Get=20 > proposal, with the parameter and registry entirely. There was some=20 > list traffic in favor of this. Martin Thompson is skeptical that SIP=20 > Presence Subscribe/Notify is actually allowed as a geopriv "using=20 > protocol". Several of think that it is. If we don't get any more=20 > comments on this proposal, we will allow sip/sips and pres, not have=20 > any > http(s) resolution text, and not propose a parameter and accompanying=20 > registry. >=20 > If this does not reflect your position, please speak up now. >=20 > Brian >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 17:52:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5rHH-0000eb-BF; Wed, 26 Jul 2006 17:50:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5rHF-0000dO-UX; Wed, 26 Jul 2006 17:50:49 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5rHE-0003I6-M3; Wed, 26 Jul 2006 17:50:49 -0400 Received: from lion.cs.columbia.edu (IDENT:YoKTQCaXNXyi1Hy6XjqVMq/UOUSFPr2V@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6QLoh4F027498 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 26 Jul 2006 17:50:43 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6QLohoq023362 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Jul 2006 17:50:43 -0400 Message-ID: <44C7E3AE.6070103@cs.columbia.edu> Date: Wed, 26 Jul 2006 17:50:38 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu><44C777D8.9030008@hxr.us> <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> <011501c6b0c9$09681910$31713b51@BEMBUSTER> <44C7919D.1010203@hxr.us> <44C79CA6.5040604@cs.columbia.edu> <44C7AA47.4080104@hxr.us> <44C7C8BF.4010103@cs.columbia.edu> <44C7D53C.3020205@hxr.us> In-Reply-To: <44C7D53C.3020205@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.26.142932 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: geopriv@ietf.org, IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > In other words, it would appear that the list of URIs allowed is HTTPS > or CID (though this doc SHOULD be more explicit). data: is not mentioned. > > This means that a PIDF-LO with a CID reference cannot be converted to a > data: URI. At best, SHOULD NOT. This issue was never discussed during the 4119 discussion, as far as I can tell, and there doesn't seem to be technical reason why it couldn't be. In any event, for the case at hand, namely proxy insertion, the problem is exactly the same: both both (only) use HTTPS. I'm unclear what ruleset we can usefully specify today. The common policy set is not particularly useful for routing, for example, and not really meant for recipients of location information in any event. Thus, at least today, this is, at best, some free-text legalese. > > -andy > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 18:04:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5rSp-0000rs-H9; Wed, 26 Jul 2006 18:02:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5rSn-0000rf-Io; Wed, 26 Jul 2006 18:02:45 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5rSm-0005Ns-7r; Wed, 26 Jul 2006 18:02:45 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 26 Jul 2006 14:56:17 -0700 X-IronPort-AV: i="4.07,185,1151910000"; d="scan'208"; a="331715048:sNHT3392579746" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6QLuGU7003778; Wed, 26 Jul 2006 14:56:16 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6QLuG2J002127; Wed, 26 Jul 2006 14:56:16 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 14:56:14 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.87]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 14:56:14 -0700 Message-Id: <4.3.2.7.2.20060726165223.032c6c40@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2006 16:56:12 -0500 To: "Rosen, Brian" , "Marc Linsner" , From: "James M. Polk" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Jul 2006 21:56:14.0418 (UTC) FILETIME=[506D9B20:01C6B0FE] DKIM-Signature: a=rsa-sha1; q=dns; l=736; t=1153950977; x=1154814977; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=20location-conveyance; X=v=3Dcisco.com=3B=20h=3Dd2eKI5QTWoMcL+zkOR4JOEOnsw4=3D; b=MxfKV9PWznLO7JMLmU46wGipVzRzYf72Qnf7tLvJaSf8MZsGsx973Wb/wCr3yUVTdu3JuXGl HWpLvMZrjU7VkST5x77oY4aZmimh5PQ79NjFkRxFGQJBxcCaLcMiyIDq; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 03:50 PM 7/25/2006 -0400, Rosen, Brian wrote: >When the original PIDF-LO RFC came out, location-by-reference was >defined. > >You have a URI. You can exchange the URI for location. There is a >protocol defined for that purpose (SIP SUBSCRIBE). That is location by >reference. It also serves as the location update mechanism, clearly >something we need. Actually, UPDATE serves as the update mechanism for the UAC detecting it has changed locations. This has been in the ID from day 1, and clarified in WG meetings over the years. How a UAC determines/d it has moved obviously not defined in the IETF. SUBSCRIBE was thought of a a good pull retreaval protocol action for updating the location of a target. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 19:24:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sia-0001F8-Ei; Wed, 26 Jul 2006 19:23:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5siY-0001A2-Om; Wed, 26 Jul 2006 19:23:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5p21-0007gi-OE; Wed, 26 Jul 2006 15:26:57 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5oqR-0007gL-UH; Wed, 26 Jul 2006 15:15:01 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G5oqJ-00082z-1p; Wed, 26 Jul 2006 14:14:51 -0500 From: "Brian Rosen" To: "'Abbott, Nadine B'" , Date: Wed, 26 Jul 2006 15:14:52 -0400 Message-ID: <035a01c6b0e7$c9250ba0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawERldoiEvROTuT2KasGKrfOW37QAzWneQAAHSzSA= In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -1.4 (-) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Nadine Are you saying that it's your opinion sip-location-conveyance MUST define an HTTP dereference procedure? If you do, why? What is the use-case or requirement? Would it not be pretty reasonable to require a separate document that defines a location-by-reference mechanism, protocol, and geopriv "using protocol" analysis? If that document specifically extended what was allowed in the location header, would that not be reasonable? I think we have to include "A" dereference mechanism in the location-conveyance document. It seems just including sip/sips/prez is a reasonable, all-sip-all-the-time approach IN THIS DOCUMENT. That certainly does not preclude another document describing another way. Doesn't it seem just a little weird to have a sip-location-conveyance document describing any kind of http based location conveyance (de-reference) protocol, especially one created whole cloth without any other parts? Doesn't it seem in keeping with the geopriv approach that in order to have another "using protocol" it has to have a geopriv review? That is what leads to restricting the URI schemes. Would you prefer to let it be wide open, so any protocol anyone thinks about can be used with the location header? I can't see geopriv going along with that. We're going to make it a one line ABNF to add a new scheme to the list of allowed schemes. It seems to me that if it's desired to define some bare-bones HTTP location by reference protocol, then that should be a separate document, which can easily extend the allowable schemes in the Location header. I'm not sure it might be better to define ALL of that in the L7 protocol, but I wouldn't be opposed to a simple "raw GET" RFC as long as it got a full geopriv review. I just don't see where it makes any sense to force that into a sip document. Brian > -----Original Message----- > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > Sent: Wednesday, July 26, 2006 2:14 PM > To: sip@ietf.org > Cc: geopriv@ietf.org > Subject: RE: [Geopriv] Consensus on changes to location-conveyance > > > I don't agree that there is a consensus to preclude the use of HTTP. > I would favor not placing your proposed restriction on the URI scheme > for expressing a location reference in the SIP location conveyance > draft; or at least including HTTP as a valid location-reference URI > type. > > Regards, > Nadine Abbott > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Tuesday, July 25, 2006 1:38 PM > To: sip@ietf.org > Cc: geopriv@ietf.org > Subject: [Geopriv] Consensus on changes to location-conveyance > > I have put out a number of emails on proposed changes to location > conveyance. Some of them have sparked a number of comments. My summary > of consensus on these issues is: > > 1. We proposed to explicitly disallow use of a Data URI, which would > allow specification of a Location-by-value in a header. There was a lot > of list traffic on this, currently in the state where Keith asked for a > real use case for it. So far, we don't see a use case that cannot be > provided by location-by-reference in a header. If we don't get a good > use case, I think consensus is to disallow location-by-value in a > header. > > 2. Dereferencing location-by-reference. We had initially proposed to > document a process to use a raw HTTP(S) Get to dereference. There was a > lot of discussion, and then I made a new proposal, see item 6. > > 3. We proposed to allow a Reason header with a 424 Bad Location > response. This seems to be acceptable to the WG. Geopriv will create > and populate the registry in a separate draft. > > 4. We proposed to explicitly allow hop-by-hop TLS security for location > when the endpoint wished to allow routing based on location. We further > proposed to interpret "Do not Distribute" flags as allowing sending of > the location to the routing database (LoST for example). Hannes pointed > out that there was a proposal to allow two Location headers, one of > which could be used for routing and another for onward forwarding to the > recipient. Hannes' message seemed to agree that "Do not distribute" > would allow sending of the location to the routing-by-location database, > but would obligate the proxy that did that to remove the location before > it forwarded the message. There were no other messages on this thread. > We conclude that allowing hop-by-hop security for location based routing > is acceptable, and Do Not Distribute DOES allow forwarding to a routing > database, but requires that the proxy doing the location based route to > remove the location it uses for that purpose. > > 5. We proposed to create a parameter and a registry to distinguish > multiple ways to dereference a location where HTTP(S) was the transport. > Resolution of this issue depends on resolution of issue 6. > > 6. We proposed to allow sip/sips and pres: in the location header. I > later speculated that if we allow this, it forms a simple way to do > location-by-reference, and we could eliminate the raw HTTP(S) Get > proposal, with the parameter and registry entirely. There was some list > traffic in favor of this. Martin Thompson is skeptical that SIP > Presence Subscribe/Notify is actually allowed as a geopriv "using > protocol". Several of think that it is. If we don't get any more > comments on this proposal, we will allow sip/sips and pres, not have any > http(s) resolution text, and not propose a parameter and accompanying > registry. > > If this does not reflect your position, please speak up now. > > Brian > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 19:33:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sqq-0006fP-3r; Wed, 26 Jul 2006 19:31:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sqo-0006fE-Lo; Wed, 26 Jul 2006 19:31:38 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5sqo-0005eu-7v; Wed, 26 Jul 2006 19:31:38 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 18:31:37 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 26 Jul 2006 18:31:37 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 18:31:18 -0500 Message-ID: From: "Winterbottom, James" To: "Abbott, Nadine B" , "Brian Rosen" , Date: Wed, 26 Jul 2006 18:31:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 26 Jul 2006 23:31:18.0791 (UTC) FILETIME=[987FD970:01C6B10B] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcawERldoiEvROTuT2KasGKrfOW37QAzWneQAAHSzSAABUfloAAD4wbg X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, I don't care if you don't mention how to de-reference URI types other than sip/sips/cid/pres in the document or not. But I do not want the schema artificially constrained to exclude URI types such as HTTP. There is clearly not consensus to justify this exclusion, so please leave schema unchanged and make your recommendations in the text. Cheers James =20 -----Original Message----- From: Abbott, Nadine B [mailto:nabbott@telcordia.com]=20 Sent: Thursday, 27 July 2006 7:44 AM To: Brian Rosen; sip@ietf.org Cc: geopriv@ietf.org Subject: RE: [Geopriv] Consensus on changes to location-conveyance Brian, Actually, I was thinking that in other industry work which is trying to leverage and provide transitional strategies to migrate to using SIP to support emergency services, the and long-term solutions that we have defined assume a capabity to provide location-by-reference. I think it would be very useful to have this defined in a standard SIP header mechanism in such a way that we need not redefine migratory solutions that have begun to be implemented. If an HTTPS URI can be used as the location-by-reference, this will be helpful, I think. =20 I don't understand your urgency to make location-by-reference only an all-sip-all-the-time thing. And from all the other emails on this topic, it didn't seem to me that there is a consensus to do this. Nadine=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, July 26, 2006 3:15 PM To: Abbott, Nadine B; sip@ietf.org Cc: geopriv@ietf.org Subject: RE: [Geopriv] Consensus on changes to location-conveyance Nadine Are you saying that it's your opinion sip-location-conveyance MUST define an HTTP dereference procedure? If you do, why? What is the use-case or requirement? Would it not be pretty reasonable to require a separate document that defines a location-by-reference mechanism, protocol, and geopriv "using protocol" analysis? If that document specifically extended what was allowed in the location header, would that not be reasonable? I think we have to include "A" dereference mechanism in the location-conveyance document. It seems just including sip/sips/prez is a reasonable, all-sip-all-the-time approach IN THIS DOCUMENT. That certainly does not preclude another document describing another way. Doesn't it seem just a little weird to have a sip-location-conveyance document describing any kind of http based location conveyance (de-reference) protocol, especially one created whole cloth without any other parts? Doesn't it seem in keeping with the geopriv approach that in order to have another "using protocol" it has to have a geopriv review? That is what leads to restricting the URI schemes. Would you prefer to let it be wide open, so any protocol anyone thinks about can be used with the location header? I can't see geopriv going along with that. We're going to make it a one line ABNF to add a new scheme to the list of allowed schemes. It seems to me that if it's desired to define some bare-bones HTTP location by reference protocol, then that should be a separate document, which can easily extend the allowable schemes in the Location header. I'm not sure it might be better to define ALL of that in the L7 protocol, but I wouldn't be opposed to a simple "raw GET" RFC as long as it got a full geopriv review. I just don't see where it makes any sense to force that into a sip document. Brian > -----Original Message----- > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > Sent: Wednesday, July 26, 2006 2:14 PM > To: sip@ietf.org > Cc: geopriv@ietf.org > Subject: RE: [Geopriv] Consensus on changes to location-conveyance >=20 >=20 > I don't agree that there is a consensus to preclude the use of HTTP. > I would favor not placing your proposed restriction on the URI scheme=20 > for expressing a location reference in the SIP location conveyance=20 > draft; or at least including HTTP as a valid location-reference URI=20 > type. >=20 > Regards, > Nadine Abbott >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Tuesday, July 25, 2006 1:38 PM > To: sip@ietf.org > Cc: geopriv@ietf.org > Subject: [Geopriv] Consensus on changes to location-conveyance >=20 > I have put out a number of emails on proposed changes to location=20 > conveyance. Some of them have sparked a number of comments. My=20 > summary of consensus on these issues is: >=20 > 1. We proposed to explicitly disallow use of a Data URI, which would=20 > allow specification of a Location-by-value in a header. There was a=20 > lot of list traffic on this, currently in the state where Keith asked=20 > for a real use case for it. So far, we don't see a use case that=20 > cannot be provided by location-by-reference in a header. If we don't=20 > get a good use case, I think consensus is to disallow=20 > location-by-value in a header. >=20 > 2. Dereferencing location-by-reference. We had initially proposed to=20 > document a process to use a raw HTTP(S) Get to dereference. There was > a lot of discussion, and then I made a new proposal, see item 6. >=20 > 3. We proposed to allow a Reason header with a 424 Bad Location=20 > response. This seems to be acceptable to the WG. Geopriv will create > and populate the registry in a separate draft. >=20 > 4. We proposed to explicitly allow hop-by-hop TLS security for=20 > location when the endpoint wished to allow routing based on location. > We further proposed to interpret "Do not Distribute" flags as allowing > sending of the location to the routing database (LoST for example). =20 > Hannes pointed out that there was a proposal to allow two Location=20 > headers, one of which could be used for routing and another for onward > forwarding to the recipient. Hannes' message seemed to agree that "Do not distribute" > would allow sending of the location to the routing-by-location=20 > database, but would obligate the proxy that did that to remove the=20 > location before it forwarded the message. There were no other messages on this thread. > We conclude that allowing hop-by-hop security for location based=20 > routing is acceptable, and Do Not Distribute DOES allow forwarding to=20 > a routing database, but requires that the proxy doing the location=20 > based route to remove the location it uses for that purpose. >=20 > 5. We proposed to create a parameter and a registry to distinguish=20 > multiple ways to dereference a location where HTTP(S) was the transport. > Resolution of this issue depends on resolution of issue 6. >=20 > 6. We proposed to allow sip/sips and pres: in the location header. I=20 > later speculated that if we allow this, it forms a simple way to do=20 > location-by-reference, and we could eliminate the raw HTTP(S) Get=20 > proposal, with the parameter and registry entirely. There was some=20 > list traffic in favor of this. Martin Thompson is skeptical that SIP=20 > Presence Subscribe/Notify is actually allowed as a geopriv "using=20 > protocol". Several of think that it is. If we don't get any more=20 > comments on this proposal, we will allow sip/sips and pres, not have=20 > any > http(s) resolution text, and not propose a parameter and accompanying=20 > registry. >=20 > If this does not reflect your position, please speak up now. >=20 > Brian >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 19:35:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ssO-0007Ag-Ln; Wed, 26 Jul 2006 19:33:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ssM-00077a-LX; Wed, 26 Jul 2006 19:33:14 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ssL-0005kP-Al; Wed, 26 Jul 2006 19:33:14 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Jul 2006 16:33:12 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6QNXCjU018146; Wed, 26 Jul 2006 16:33:12 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6QNXC2D027953; Wed, 26 Jul 2006 16:33:12 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Jul 2006 16:33:12 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.87]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 16:33:11 -0700 Message-Id: <4.3.2.7.2.20060726183246.02a491a0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2006 18:33:10 -0500 To: Paul Kyzivat , Marc Linsner From: "James M. Polk" Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance In-Reply-To: <44C769ED.3030000@cisco.com> References: <017501c6b0b3$ae83ddf0$1f0d0d0a@amer.cisco.com> <017501c6b0b3$ae83ddf0$1f0d0d0a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Jul 2006 23:33:12.0019 (UTC) FILETIME=[DBFD1230:01C6B10B] DKIM-Signature: a=rsa-sha1; q=dns; l=619; t=1153956792; x=1154820792; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=0A=20= 20location-conveyance; X=v=3Dcisco.com=3B=20h=3D6MjbpL8IiYLdDIsKBDAd+QlIgwA=3D; b=Ri0eOcrIVaoH2Kg3kkUF1l220QMltYBiX28y8dTbOgLzaZok06WgLpb2kW4ZAJhhTpga+A5V l9d3fTzPuS+ZCNsDj4Se92LJulByzT7Uo7Nv+JWmNn92kb0Cf2EbfHDA; Authentication-Results: sj-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: geopriv@ietf.org, sip@ietf.org, "'Peterson, Jon'" , "'Rosen, Brian'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 09:11 AM 7/26/2006 -0400, Paul Kyzivat wrote: >Marc Linsner wrote: >>In-line... >>>So, you are arguing against proxy insertion of a location-by-reference? >>No, if done properly....but reading the latest threads, I get the feeling >>that www.whereintheworldisbrianrosen.com is an acceptable reference. > >Damn! I was hoping, but www.whereintheworldisbrianrosen.com doesn't seem >to be working today. :-( I think he's .biz now... ;-) > Paul > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 20:35:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ton-00042y-FO; Wed, 26 Jul 2006 20:33:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tol-00042e-AZ; Wed, 26 Jul 2006 20:33:35 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5tok-0006Xo-3R; Wed, 26 Jul 2006 20:33:35 -0400 Received: from [192.168.0.41] (pool-141-153-188-67.mad.east.verizon.net [141.153.188.67]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6R0XMMp000226 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 26 Jul 2006 20:33:24 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 20:33:16 -0400 To: "Abbott, Nadine B" X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.26.171432 X-PerlMx-Spam: Gauge=XXII, Probability=22%, Report='RELAY_IN_NJABL_DYNABLOCK 2.5, RCVD_IN_NJABL_ORG 0, RELAY_IN_NJABL_ORG 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RELAY_IN_NJABL_DYNABLOCK 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On a general note and generalizing a bit on Nadine's message below, I find the nanny tone of this discussion a bit peculiar ("No, I don't want you to play with that!"). I can see the technical rationale for requiring implementation of a limited set of choices for interoperability, but proactively ruling out other choices seems highly unusual for an IETF protocol spec. It is clear that only a relatively small number of people are participating in this discussion, so declaring consensus to rule out one URL scheme or another as 'evil bits' seems a bit peculiar. On Jul 26, 2006, at 2:14 PM, Abbott, Nadine B wrote: > > I don't agree that there is a consensus to preclude the use of HTTP. > I would favor not placing your proposed restriction on the URI scheme > for expressing a location reference in the SIP location conveyance > draft; or at least including HTTP as a valid location-reference URI > type. > > Regards, > Nadine Abbott > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 21:26:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ubi-0005UQ-W3; Wed, 26 Jul 2006 21:24:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ubh-0005U4-81; Wed, 26 Jul 2006 21:24:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5n0O-0003m1-79; Wed, 26 Jul 2006 13:17:08 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5mxh-0004ro-4m; Wed, 26 Jul 2006 13:14:21 -0400 Received: from lion.cs.columbia.edu (IDENT:rRzlYNb/9V0JnpelbGFgG/zPTS8flluR@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6QHED4F000080 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 26 Jul 2006 13:14:14 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6QHEDoq006437 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Jul 2006 13:14:13 -0400 Message-ID: <44C7A2E0.2000303@cs.columbia.edu> Date: Wed, 26 Jul 2006 13:14:08 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu> <44C777D8.9030008@hxr.us> <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> <44C786C2.4000206@hxr.us> In-Reply-To: <44C786C2.4000206@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.26.94932 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -2.4 (--) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: geopriv@ietf.org, IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org For location-based routing case, the likelihood of significant updates in the roughly one second that a call might take from caller to callee seems unlikely. UAS subscription and polling is clearly more valuable, so maybe we need to distinguish these cases. (As discussed earlier, mid-routing updates may lead to bad outcomes since the call might have been sent to a place A that doesn't know what to do with location update n+1 since that new location is really handled by place B.) Andrew Newton wrote: > Henning Schulzrinne wrote: >>> I believe there are two technical arguments: one is legacy equipment >>> (the issue that I'll be facing for quite some time), and environments >>> where the location is generated by the network. For the latter, >>> insertion of the Location header only in emergency situations still >>> puts the user in control for non-emergency situations. >>> >>> >> >> For the latter, the combination of the in-progress L7 protocols, DHCP >> and LLDP should presumably allow the UAC to obtain location and insert >> it by value. Is there a use case not covered by that? > > As I said, where location comes from the network. In this scenario, > there are two possibilities, both up to the user: 1) the UAC subscribes > to the location from the network and puts it by value in the call > flow... meaning all location updates go through the UAC, or 2) the UAC > hands out a reference so updates can be independent of the UAC or > updates based on subscription come from the UAC but are independent of > the call. > > -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 21:29:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ufX-0000dy-Ox; Wed, 26 Jul 2006 21:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ufV-0000UK-Oe; Wed, 26 Jul 2006 21:28:05 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ufU-0001nq-F0; Wed, 26 Jul 2006 21:28:05 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:28:04 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 26 Jul 2006 20:28:03 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:28:02 -0500 Message-ID: From: "Winterbottom, James" To: "Henning Schulzrinne" , "Andrew Newton" Date: Wed, 26 Jul 2006 20:28:00 -0500 Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 27 Jul 2006 01:28:02.0592 (UTC) FILETIME=[E7171200:01C6B11B] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <44C7A2E0.2000303@cs.columbia.edu> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcaxG1/vDk5hj3tGSOy4tniG+1RdrwAACFAg X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: geopriv@ietf.org, IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In the case you mention below the reality is that if the target has moved during the course of routing, the target will either be at place B by the time dispatch occurs, or at point C which may be further away still.=20 At least in the case of a reference you have the possibility of getting the current location, which is not possible through any of the "by-value" means described thus far unless the caller is stationary! -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Thursday, 27 July 2006 3:14 AM To: Andrew Newton Cc: geopriv@ietf.org; IETF SIP List Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance For location-based routing case, the likelihood of significant updates=20 in the roughly one second that a call might take from caller to callee=20 seems unlikely. UAS subscription and polling is clearly more valuable,=20 so maybe we need to distinguish these cases. (As discussed earlier,=20 mid-routing updates may lead to bad outcomes since the call might have=20 been sent to a place A that doesn't know what to do with location update n+1 since that new location is really handled by place B.) Andrew Newton wrote: > Henning Schulzrinne wrote: >>> I believe there are two technical arguments: one is legacy equipment >>> (the issue that I'll be facing for quite some time), and environments=20 >>> where the location is generated by the network. For the latter,=20 >>> insertion of the Location header only in emergency situations still=20 >>> puts the user in control for non-emergency situations. >>> >>> >> >> For the latter, the combination of the in-progress L7 protocols, DHCP >> and LLDP should presumably allow the UAC to obtain location and insert=20 >> it by value. Is there a use case not covered by that? >=20 > As I said, where location comes from the network. In this scenario,=20 > there are two possibilities, both up to the user: 1) the UAC subscribes=20 > to the location from the network and puts it by value in the call=20 > flow... meaning all location updates go through the UAC, or 2) the UAC > hands out a reference so updates can be independent of the UAC or=20 > updates based on subscription come from the UAC but are independent of > the call. >=20 > -andy _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 21:38:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5una-0005gH-Bi; Wed, 26 Jul 2006 21:36:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5unY-0005g3-7j; Wed, 26 Jul 2006 21:36:24 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5unV-0003Nt-Ue; Wed, 26 Jul 2006 21:36:24 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Jul 2006 21:36:29 -0400 id 0158817D.44C8189D.000035C4 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <714DC628-F4A0-4682-8010-01669D301299@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 21:36:16 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org, geopriv@ietf.org, "Abbott, Nadine B" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't think Brian ever proposed ruling out URI schemes. What he proposed was restricting what can go in it now and a mechanism for defining future URI schemes that will be allowed. We certainly do want using protocols passing around PIDF-LOs getting review by GEOPRIV. -andy On Jul 26, 2006, at 8:33 PM, Henning Schulzrinne wrote: > On a general note and generalizing a bit on Nadine's message below, > I find the nanny tone of this discussion a bit peculiar ("No, I > don't want you to play with that!"). I can see the technical > rationale for requiring implementation of a limited set of choices > for interoperability, but proactively ruling out other choices > seems highly unusual for an IETF protocol spec. It is clear that > only a relatively small number of people are participating in this > discussion, so declaring consensus to rule out one URL scheme or > another as 'evil bits' seems a bit peculiar. > > On Jul 26, 2006, at 2:14 PM, Abbott, Nadine B wrote: > >> >> I don't agree that there is a consensus to preclude the use of HTTP. >> I would favor not placing your proposed restriction on the URI scheme >> for expressing a location reference in the SIP location conveyance >> draft; or at least including HTTP as a valid location-reference URI >> type. >> >> Regards, >> Nadine Abbott >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 21:44:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5utG-0002XB-Sf; Wed, 26 Jul 2006 21:42:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5utE-0002WP-E0; Wed, 26 Jul 2006 21:42:16 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5utD-0004Hw-3z; Wed, 26 Jul 2006 21:42:16 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Jul 2006 21:42:24 -0400 id 0158817D.44C81A00.000036AB In-Reply-To: <44C7E3AE.6070103@cs.columbia.edu> References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu><44C777D8.9030008@hxr.us> <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> <011501c6b0c9$09681910$31713b51@BEMBUSTER> <44C7919D.1010203@hxr.us> <44C79CA6.5040604@cs.columbia.edu> <44C7AA47.4080104@hxr.us> <44C7C8BF.4010103@cs.columbia.edu> <44C7D53C.3020205@hxr.us> <44C7E3AE.6070103@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 21:42:14 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: geopriv@ietf.org, IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 26, 2006, at 5:50 PM, Henning Schulzrinne wrote: >> In other words, it would appear that the list of URIs allowed is >> HTTPS or CID (though this doc SHOULD be more explicit). data: is >> not mentioned. >> This means that a PIDF-LO with a CID reference cannot be converted >> to a data: URI. > > At best, SHOULD NOT. This issue was never discussed during the 4119 > discussion, as far as I can tell, and there doesn't seem to be > technical reason why it couldn't be. It was discussed at length at our interim meeting in DC, and nobody ever mentioned anything but HTTPS and CID. > In any event, for the case at hand, namely proxy insertion, the > problem is exactly the same: both both (only) use HTTPS. I'm > unclear what ruleset we can usefully specify today. The common > policy set is not particularly useful for routing, for example, and > not really meant for recipients of location information in any > event. Thus, at least today, this is, at best, some free-text > legalese. This is yet another rule, adding more complexity. You can pass by value either via MIME or data: URI. If you pass by value using the data: URI, you have to restrict ruleset references. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 21:45:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5uuP-0003cY-Jf; Wed, 26 Jul 2006 21:43:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5uuO-0003cN-3G; Wed, 26 Jul 2006 21:43:28 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5uuL-0004fb-Pp; Wed, 26 Jul 2006 21:43:28 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:43:25 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 26 Jul 2006 20:43:25 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:43:24 -0500 Message-ID: From: "Winterbottom, James" To: "Andrew Newton" , "Henning Schulzrinne" Date: Wed, 26 Jul 2006 20:43:23 -0500 Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 27 Jul 2006 01:43:24.0706 (UTC) FILETIME=[0CB68020:01C6B11E] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <714DC628-F4A0-4682-8010-01669D301299@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcaxHRbZmL0IbMgAQhGb1qTFwoMMMwAAMn9Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org, geopriv@ietf.org, "Abbott, Nadine B" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Andy, RFC-4119 says "However, the usage of this location object format is not limited to presence-using protocols-- any protocol that can carry XML or MIME types can carry PIDF." It seems to me that restricting the allowed schema in what is supposed to be a location conveyance specification is in opposition to this statement. -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Thursday, 27 July 2006 11:36 AM To: Henning Schulzrinne Cc: sip@ietf.org; geopriv@ietf.org; Abbott, Nadine B Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance I don't think Brian ever proposed ruling out URI schemes. What he =20 proposed was restricting what can go in it now and a mechanism for =20 defining future URI schemes that will be allowed. We certainly do =20 want using protocols passing around PIDF-LOs getting review by GEOPRIV. -andy On Jul 26, 2006, at 8:33 PM, Henning Schulzrinne wrote: > On a general note and generalizing a bit on Nadine's message below, =20 > I find the nanny tone of this discussion a bit peculiar ("No, I =20 > don't want you to play with that!"). I can see the technical =20 > rationale for requiring implementation of a limited set of choices =20 > for interoperability, but proactively ruling out other choices =20 > seems highly unusual for an IETF protocol spec. It is clear that =20 > only a relatively small number of people are participating in this =20 > discussion, so declaring consensus to rule out one URL scheme or =20 > another as 'evil bits' seems a bit peculiar. > > On Jul 26, 2006, at 2:14 PM, Abbott, Nadine B wrote: > >> >> I don't agree that there is a consensus to preclude the use of HTTP. >> I would favor not placing your proposed restriction on the URI scheme >> for expressing a location reference in the SIP location conveyance >> draft; or at least including HTTP as a valid location-reference URI >> type. >> >> Regards, >> Nadine Abbott >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 21:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5uy0-0006AB-1D; Wed, 26 Jul 2006 21:47:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5uxy-00064B-Ia; Wed, 26 Jul 2006 21:47:10 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5uxw-0005t4-Bu; Wed, 26 Jul 2006 21:47:10 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Jul 2006 21:47:17 -0400 id 0158817D.44C81B25.000037AE In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3AE00FE1-2B2E-44D8-8A02-D4D0457AF4DA@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 21:47:04 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: geopriv@ietf.org, IETF SIP List , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 26, 2006, at 9:28 PM, Winterbottom, James wrote: > In the case you mention below the reality is that if the target has > moved during the course of routing, the target will either be at > place B > by the time dispatch occurs, or at point C which may be further away > still. > At least in the case of a reference you have the possibility of > getting > the current location, which is not possible through any of the > "by-value" means described thus far unless the caller is stationary! > What about a SIP UPDATE? Section 5.3 of the draft. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 21:49:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5uyy-0007oZ-BO; Wed, 26 Jul 2006 21:48:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5uyw-0007hO-7i; Wed, 26 Jul 2006 21:48:10 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5uyu-0006As-PW; Wed, 26 Jul 2006 21:48:10 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:48:08 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 26 Jul 2006 20:48:07 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:48:07 -0500 Message-ID: From: "Winterbottom, James" To: "Andrew Newton" Date: Wed, 26 Jul 2006 20:48:05 -0500 Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 27 Jul 2006 01:48:07.0233 (UTC) FILETIME=[B51CB310:01C6B11E] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <3AE00FE1-2B2E-44D8-8A02-D4D0457AF4DA@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcaxHpMp8cdIWVAVRyO4w2Fl8DYT6AAABOsg X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: geopriv@ietf.org, IETF SIP List , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org To what do you send the SIP update and for what do you request the update? -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Thursday, 27 July 2006 11:47 AM To: Winterbottom, James Cc: Henning Schulzrinne; geopriv@ietf.org; IETF SIP List Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance On Jul 26, 2006, at 9:28 PM, Winterbottom, James wrote: > In the case you mention below the reality is that if the target has > moved during the course of routing, the target will either be at =20 > place B > by the time dispatch occurs, or at point C which may be further away > still. > At least in the case of a reference you have the possibility of =20 > getting > the current location, which is not possible through any of the > "by-value" means described thus far unless the caller is stationary! > What about a SIP UPDATE? Section 5.3 of the draft. -andy ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 22:00:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5v8l-0003LT-IX; Wed, 26 Jul 2006 21:58:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5v8j-0003LJ-Ni; Wed, 26 Jul 2006 21:58:17 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5v8g-0001sk-60; Wed, 26 Jul 2006 21:58:17 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Jul 2006 21:58:23 -0400 id 0158817D.44C81DBF.00003A08 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <285A5146-ABFF-4281-8599-8EBE3891E03B@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 21:58:10 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, geopriv@ietf.org, "Abbott, Nadine B" , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 26, 2006, at 9:43 PM, Winterbottom, James wrote: > Andy, > > RFC-4119 says "However, the usage of this location object format is > not > limited to presence-using protocols-- any protocol that can > carry XML > or MIME types can carry PIDF." > > It seems to me that restricting the allowed schema in what is supposed > to be a location conveyance specification is in opposition to this > statement. Did somebody say that HTTP was a presence-using protocol? -andy ps. you can find my location with the following reference URIs: gopher://fatchance.hxr.us/you-still-have-a-gopher-client news:alt.locations.people.secretly-being-watched telnet://screen-scrapers.are.us/ dns:cached-publicly-around-the-world.com?type=HOST _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 23:10:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wEb-0001oS-Jh; Wed, 26 Jul 2006 23:08:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wEZ-0001nU-U7; Wed, 26 Jul 2006 23:08:23 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wEY-0003KN-Jh; Wed, 26 Jul 2006 23:08:23 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G5wEF-0001cq-O5; Wed, 26 Jul 2006 22:08:04 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Winterbottom, James'" Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 23:08:11 -0400 Message-ID: <043701c6b129$e662d4d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaxICHAtAENJESpR8Gsjx7TZM9AsgACIPEA In-Reply-To: <285A5146-ABFF-4281-8599-8EBE3891E03B@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org, geopriv@ietf.org, 'Henning Schulzrinne' , "'Abbott, Nadine B'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At this point, I think we need some chair guidance and by that I think it's a combo of geopriv and sip chairs. We seem to have a couple of significant open questions. I think most of the other stuff (like the "allow sending to router") will converge. There seems to be some opposition to allowing sip/sips/pres: in a Location Header. The opposition seems to be that despite 4119, somehow, SIP (presence subscription) is not a "using protocol". I "think" a ruling from the bench on that would work. There is also opposition to defining the allowed schemes as a specific list, with a defined (easy) extension mechanism. Related to that, there are some who want location-conveyance to define an HTTP based location dereference mechanism, and on the opposite end, we have people saying we haven't even agreed to support any form of location-by-reference. The authors would like to know what to do now. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, July 26, 2006 9:58 PM > To: Winterbottom, James > Cc: sip@ietf.org; geopriv@ietf.org; Abbott, Nadine B; Henning Schulzrinne > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- > conveyance > > > On Jul 26, 2006, at 9:43 PM, Winterbottom, James wrote: > > > Andy, > > > > RFC-4119 says "However, the usage of this location object format is > > not > > limited to presence-using protocols-- any protocol that can > > carry XML > > or MIME types can carry PIDF." > > > > It seems to me that restricting the allowed schema in what is supposed > > to be a location conveyance specification is in opposition to this > > statement. > > Did somebody say that HTTP was a presence-using protocol? > > -andy > > ps. you can find my location with the following reference URIs: > > gopher://fatchance.hxr.us/you-still-have-a-gopher-client > news:alt.locations.people.secretly-being-watched > telnet://screen-scrapers.are.us/ > dns:cached-publicly-around-the-world.com?type=HOST > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 23:27:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wV4-0007uC-EA; Wed, 26 Jul 2006 23:25:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wV2-0007qe-Uc; Wed, 26 Jul 2006 23:25:24 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wV2-0004vK-KF; Wed, 26 Jul 2006 23:25:24 -0400 Received: from [192.168.0.41] (pool-141-153-188-67.mad.east.verizon.net [141.153.188.67]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6R3PLMp003617 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 26 Jul 2006 23:25:22 -0400 (EDT) In-Reply-To: <043701c6b129$e662d4d0$640fa8c0@cis.neustar.com> References: <043701c6b129$e662d4d0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26AE42F5-3170-434B-8E4F-4D7F22FA2E7C@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 23:25:15 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.26.195932 X-PerlMx-Spam: Gauge=XXII, Probability=22%, Report='RELAY_IN_NJABL_DYNABLOCK 2.5, RCVD_IN_NJABL_ORG 0, RELAY_IN_NJABL_ORG 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RELAY_IN_NJABL_DYNABLOCK 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: IETF SIP List , geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My suggestion would be - to focus the draft on just defining the Location header syntax, without ruling out any particular mechanism or scheme; this would make the draft really short (which I would find helpful). - and then add one section to the draft that prototypically defines what a particular scheme that wants to appear in the Location header needs to define, using the non-controversial cid mechanism as the example. Other, separate, drafts can then define other modes, following the same template. Documents such as the phone-bcp can then pick some suitable must-implement subset and make emergency-call- specific recommendations, rather than sprinkling these throughout the conveyance document and repeating some in the phone-bcp. Most of these are, in any event, operational recommendations, not for ensuring protocol-level interoperability. That way, the conveyance draft can be extremely short (even shorter if the requirements are omitted...) and can get done, and we avoid engineering operational requirements on the fly, commingling emergency and non-emergency cases, as seems to be happening now. I think protocol documents should define what's needed for interoperability; BCPs can make more specific, situation-specific recommendations. Commingling the two seems to be a recipe for deadlock or arbitrary, non-technically-grounded decisions that are more lawyer-like than engineering-like ("you did not mention technique X in some meeting N years ago and thus you can't bring it up now!") Henning On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote: > At this point, I think we need some chair guidance and by that I > think it's > a combo of geopriv and sip chairs. > > We seem to have a couple of significant open questions. I think > most of the > other stuff (like the "allow sending to router") will converge. > > There seems to be some opposition to allowing sip/sips/pres: in a > Location > Header. The opposition seems to be that despite 4119, somehow, SIP > (presence subscription) is not a "using protocol". I "think" a > ruling from > the bench on that would work. > > There is also opposition to defining the allowed schemes as a > specific list, > with a defined (easy) extension mechanism. > > Related to that, there are some who want location-conveyance to > define an > HTTP based location dereference mechanism, and on the opposite end, > we have > people saying we haven't even agreed to support any form of > location-by-reference. > > The authors would like to know what to do now. > > Brian > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Wednesday, July 26, 2006 9:58 PM >> To: Winterbottom, James >> Cc: sip@ietf.org; geopriv@ietf.org; Abbott, Nadine B; Henning >> Schulzrinne >> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- >> conveyance >> >> >> On Jul 26, 2006, at 9:43 PM, Winterbottom, James wrote: >> >>> Andy, >>> >>> RFC-4119 says "However, the usage of this location object format is >>> not >>> limited to presence-using protocols-- any protocol that can >>> carry XML >>> or MIME types can carry PIDF." >>> >>> It seems to me that restricting the allowed schema in what is >>> supposed >>> to be a location conveyance specification is in opposition to this >>> statement. >> >> Did somebody say that HTTP was a presence-using protocol? >> >> -andy >> >> ps. you can find my location with the following reference URIs: >> >> gopher://fatchance.hxr.us/you-still-have-a-gopher-client >> news:alt.locations.people.secretly-being-watched >> telnet://screen-scrapers.are.us/ >> dns:cached-publicly-around-the-world.com?type=HOST >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 23:27:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wV2-0007pu-4W; Wed, 26 Jul 2006 23:25:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wV0-0007pj-Eq; Wed, 26 Jul 2006 23:25:22 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wUz-0004v3-4d; Wed, 26 Jul 2006 23:25:22 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 22:25:20 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 26 Jul 2006 22:25:19 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 22:25:19 -0500 Message-ID: From: "Winterbottom, James" To: "Brian Rosen" , "Andrew Newton" Date: Wed, 26 Jul 2006 22:25:17 -0500 Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 27 Jul 2006 03:25:19.0373 (UTC) FILETIME=[4956A3D0:01C6B12C] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <043701c6b129$e662d4d0$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcaxICHAtAENJESpR8Gsjx7TZM9AsgACIPEAAADacwA= X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: sip@ietf.org, geopriv@ietf.org, Henning Schulzrinne , "Abbott, Nadine B" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Let's clarify this further Brian. I do not want the schema to put a constraint on the URI type. This is not the same as saying that I expect the document to describe how to dereference all URI types. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, 27 July 2006 1:08 PM To: 'Andrew Newton'; Winterbottom, James Cc: sip@ietf.org; geopriv@ietf.org; 'Abbott, Nadine B'; 'Henning Schulzrinne' Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance At this point, I think we need some chair guidance and by that I think it's a combo of geopriv and sip chairs. We seem to have a couple of significant open questions. I think most of the other stuff (like the "allow sending to router") will converge. There seems to be some opposition to allowing sip/sips/pres: in a Location Header. The opposition seems to be that despite 4119, somehow, SIP (presence subscription) is not a "using protocol". I "think" a ruling from the bench on that would work. There is also opposition to defining the allowed schemes as a specific list, with a defined (easy) extension mechanism. =20 Related to that, there are some who want location-conveyance to define an HTTP based location dereference mechanism, and on the opposite end, we have people saying we haven't even agreed to support any form of location-by-reference. =20 The authors would like to know what to do now. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, July 26, 2006 9:58 PM > To: Winterbottom, James > Cc: sip@ietf.org; geopriv@ietf.org; Abbott, Nadine B; Henning Schulzrinne > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- > conveyance >=20 >=20 > On Jul 26, 2006, at 9:43 PM, Winterbottom, James wrote: >=20 > > Andy, > > > > RFC-4119 says "However, the usage of this location object format is > > not > > limited to presence-using protocols-- any protocol that can > > carry XML > > or MIME types can carry PIDF." > > > > It seems to me that restricting the allowed schema in what is supposed > > to be a location conveyance specification is in opposition to this > > statement. >=20 > Did somebody say that HTTP was a presence-using protocol? >=20 > -andy >=20 > ps. you can find my location with the following reference URIs: >=20 > gopher://fatchance.hxr.us/you-still-have-a-gopher-client > news:alt.locations.people.secretly-being-watched > telnet://screen-scrapers.are.us/ > dns:cached-publicly-around-the-world.com?type=3DHOST >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 23:30:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wY2-00030V-RC; Wed, 26 Jul 2006 23:28:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wY1-0002xk-1f; Wed, 26 Jul 2006 23:28:29 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wXy-0005H8-CM; Wed, 26 Jul 2006 23:28:29 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Jul 2006 20:28:26 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6R3SMSL004261; Wed, 26 Jul 2006 20:28:22 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6R3SMJi007198; Wed, 26 Jul 2006 20:28:22 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:27:38 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.87]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:27:37 -0700 Message-Id: <4.3.2.7.2.20060726222133.03bb4518@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2006 22:27:36 -0500 To: "Winterbottom, James" , "Abbott, Nadine B" , "Brian Rosen" , From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 03:27:37.0875 (UTC) FILETIME=[9BE45E30:01C6B12C] DKIM-Signature: a=rsa-sha1; q=dns; l=9405; t=1153970902; x=1154834902; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=20location-conveyance; X=v=3Dcisco.com=3B=20h=3Dd2eKI5QTWoMcL+zkOR4JOEOnsw4=3D; b=BlXcG27pRNTHJm3DZlJPcky7fNuGb6Mako99KGqP44UONx/ovcZdEcxCACZ8DAyk5HhL1vzu uhsnd0hCnm2bRDUBuJeItp+Ji3IVLsK3R0L31DSHOiKfwN4Gc/l/MYMP; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James We won't say anything like "MUST only use sip/sips/pres/cid, and MUST NOT ...". I don't believe we will take a negative tone with what isn't allowed in this respect, but we will state explicitly what is defined for use. We will likely state something like this: ' this document defines usage of the sip, sips, pres and cid schemas for location conveyance, and here's how...' I think Geopriv really needs to look at HTTP as a RFC 3693 "using protocol" to tease out any unique characteristics with that protocol. That discussion and review shouldn't bog this document down. Does this sound fair? At 06:31 PM 7/26/2006 -0500, Winterbottom, James wrote: >Brian, > >I don't care if you don't mention how to de-reference URI types other >than sip/sips/cid/pres in the document or not. But I do not want the >schema artificially constrained to exclude URI types such as HTTP. There >is clearly not consensus to justify this exclusion, so please leave >schema unchanged and make your recommendations in the text. > >Cheers >James > > > >-----Original Message----- >From: Abbott, Nadine B [mailto:nabbott@telcordia.com] >Sent: Thursday, 27 July 2006 7:44 AM >To: Brian Rosen; sip@ietf.org >Cc: geopriv@ietf.org >Subject: RE: [Geopriv] Consensus on changes to location-conveyance > >Brian, > >Actually, I was thinking that in other industry work which is trying to >leverage and provide transitional strategies to migrate to using SIP to >support emergency services, the and long-term solutions that we have >defined assume a capabity to provide location-by-reference. I think it >would be very useful to have this defined in a standard SIP header >mechanism in such a way that we need not redefine migratory solutions >that have begun to be implemented. If an HTTPS URI can be used as the >location-by-reference, this will be helpful, I think. > >I don't understand your urgency to make location-by-reference only an >all-sip-all-the-time thing. >And from all the other emails on this topic, it didn't seem to me that >there is a consensus to do this. > >Nadine > >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: Wednesday, July 26, 2006 3:15 PM >To: Abbott, Nadine B; sip@ietf.org >Cc: geopriv@ietf.org >Subject: RE: [Geopriv] Consensus on changes to location-conveyance > >Nadine > >Are you saying that it's your opinion sip-location-conveyance MUST >define an HTTP dereference procedure? > >If you do, why? What is the use-case or requirement? > >Would it not be pretty reasonable to require a separate document that >defines a location-by-reference mechanism, protocol, and geopriv "using >protocol" analysis? If that document specifically extended what was >allowed in the location header, would that not be reasonable? > >I think we have to include "A" dereference mechanism in the >location-conveyance document. It seems just including sip/sips/prez is >a reasonable, all-sip-all-the-time approach IN THIS DOCUMENT. That >certainly does not preclude another document describing another way. > >Doesn't it seem just a little weird to have a sip-location-conveyance >document describing any kind of http based location conveyance >(de-reference) protocol, especially one created whole cloth without any >other parts? > >Doesn't it seem in keeping with the geopriv approach that in order to >have another "using protocol" it has to have a geopriv review? That is >what leads to restricting the URI schemes. Would you prefer to let it >be wide open, so any protocol anyone thinks about can be used with the >location header? I can't see geopriv going along with that. We're >going to make it a one line ABNF to add a new scheme to the list of >allowed schemes. > >It seems to me that if it's desired to define some bare-bones HTTP >location by reference protocol, then that should be a separate document, >which can easily extend the allowable schemes in the Location header. >I'm not sure it might be better to define ALL of that in the L7 >protocol, but I wouldn't be opposed to a simple "raw GET" RFC as long as >it got a full geopriv review. >I just don't see where it makes any sense to force that into a sip >document. > >Brian > > > -----Original Message----- > > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > > Sent: Wednesday, July 26, 2006 2:14 PM > > To: sip@ietf.org > > Cc: geopriv@ietf.org > > Subject: RE: [Geopriv] Consensus on changes to location-conveyance > > > > > > I don't agree that there is a consensus to preclude the use of HTTP. > > I would favor not placing your proposed restriction on the URI scheme > > for expressing a location reference in the SIP location conveyance > > draft; or at least including HTTP as a valid location-reference URI > > type. > > > > Regards, > > Nadine Abbott > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Tuesday, July 25, 2006 1:38 PM > > To: sip@ietf.org > > Cc: geopriv@ietf.org > > Subject: [Geopriv] Consensus on changes to location-conveyance > > > > I have put out a number of emails on proposed changes to location > > conveyance. Some of them have sparked a number of comments. My > > summary of consensus on these issues is: > > > > 1. We proposed to explicitly disallow use of a Data URI, which would > > allow specification of a Location-by-value in a header. There was a > > lot of list traffic on this, currently in the state where Keith asked > > for a real use case for it. So far, we don't see a use case that > > cannot be provided by location-by-reference in a header. If we don't > > get a good use case, I think consensus is to disallow > > location-by-value in a header. > > > > 2. Dereferencing location-by-reference. We had initially proposed to > > document a process to use a raw HTTP(S) Get to dereference. There was > > > a lot of discussion, and then I made a new proposal, see item 6. > > > > 3. We proposed to allow a Reason header with a 424 Bad Location > > response. This seems to be acceptable to the WG. Geopriv will create > > > and populate the registry in a separate draft. > > > > 4. We proposed to explicitly allow hop-by-hop TLS security for > > location when the endpoint wished to allow routing based on location. > > > We further proposed to interpret "Do not Distribute" flags as allowing > > > sending of the location to the routing database (LoST for example). > > Hannes pointed out that there was a proposal to allow two Location > > headers, one of which could be used for routing and another for onward > > > forwarding to the recipient. Hannes' message seemed to agree that "Do >not distribute" > > would allow sending of the location to the routing-by-location > > database, but would obligate the proxy that did that to remove the > > location before it forwarded the message. There were no other >messages on this thread. > > We conclude that allowing hop-by-hop security for location based > > routing is acceptable, and Do Not Distribute DOES allow forwarding to > > a routing database, but requires that the proxy doing the location > > based route to remove the location it uses for that purpose. > > > > 5. We proposed to create a parameter and a registry to distinguish > > multiple ways to dereference a location where HTTP(S) was the >transport. > > Resolution of this issue depends on resolution of issue 6. > > > > 6. We proposed to allow sip/sips and pres: in the location header. I > > later speculated that if we allow this, it forms a simple way to do > > location-by-reference, and we could eliminate the raw HTTP(S) Get > > proposal, with the parameter and registry entirely. There was some > > list traffic in favor of this. Martin Thompson is skeptical that SIP > > Presence Subscribe/Notify is actually allowed as a geopriv "using > > protocol". Several of think that it is. If we don't get any more > > comments on this proposal, we will allow sip/sips and pres, not have > > any > > http(s) resolution text, and not propose a parameter and accompanying > > registry. > > > > If this does not reflect your position, please speak up now. > > > > Brian > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 23:35:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wdS-0007ag-CI; Wed, 26 Jul 2006 23:34:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wdQ-0007U8-PX; Wed, 26 Jul 2006 23:34:04 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wdP-0005is-EB; Wed, 26 Jul 2006 23:34:04 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 26 Jul 2006 20:34:03 -0700 X-IronPort-AV: i="4.07,186,1151910000"; d="scan'208"; a="1842217614:sNHT27547652" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6R3Y2Dm001932; Wed, 26 Jul 2006 20:34:02 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6R3Y279028802; Wed, 26 Jul 2006 20:34:02 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:34:02 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.87]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:34:02 -0700 Message-Id: <4.3.2.7.2.20060726222835.029fc600@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2006 22:34:00 -0500 To: Henning Schulzrinne , "Abbott, Nadine B" From: "James M. Polk" Subject: Re: [Sip] RE: [Geopriv] Consensus on HTTP(S) in SIP location-conveyance In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 03:34:02.0216 (UTC) FILETIME=[80FA2680:01C6B12D] DKIM-Signature: a=rsa-sha1; q=dns; l=1680; t=1153971242; x=1154835242; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20RE=3A=20[Geopriv]=20Consensus=20on=20HTTP(S)=20in=20SIP= 0A=20=20location-conveyance; X=v=3Dcisco.com=3B=20h=3D294X/7IFPotqxJ6tHbyyffK/9jk=3D; b=bCFcL0mJSsHg77NYPmpEI1MzwP6dcdTc5tnSmmYYpSkF4OQkntmA1ATz4Em1/XuDGe/2vOez tRJsc7DfRCIDO+JfdcrhQyQwC14vjMMLW/dSAKK7ltEg8sfBi4qmC1Fa; Authentication-Results: sj-dkim-8.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 08:33 PM 7/26/2006 -0400, Henning Schulzrinne wrote: >On a general note and generalizing a bit on Nadine's message below, I >find the nanny tone of this discussion a bit peculiar ("No, I don't >want you to play with that!"). I can see the technical rationale for >requiring implementation of a limited set of choices for >interoperability, but proactively ruling out other choices seems >highly unusual for an IETF protocol spec. It is clear that only a >relatively small number of people are participating in this >discussion, so declaring consensus to rule out one URL scheme or >another as 'evil bits' seems a bit peculiar. A few folks have pointed out unique issues with HTTP and HTTPS wrt privacy issues. If those are true, do they need to be addressed in this document to satisfy Geopriv? If yes, should a SIP doc discuss the uniqueness of HTTP's security stuff? Or should that discussion be in an HTTP document? Brian is suggesting that be in a HTTP focused document (likely in Geopriv), with the fairly unique ability to extend this document without going through the SIP Change process (and that's a bonus). >On Jul 26, 2006, at 2:14 PM, Abbott, Nadine B wrote: > >> >>I don't agree that there is a consensus to preclude the use of HTTP. >>I would favor not placing your proposed restriction on the URI scheme >>for expressing a location reference in the SIP location conveyance >>draft; or at least including HTTP as a valid location-reference URI >>type. >> >>Regards, >>Nadine Abbott > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 23:36:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5weM-0008BI-QO; Wed, 26 Jul 2006 23:35:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5weK-0008B5-RP for sip@ietf.org; Wed, 26 Jul 2006 23:35:00 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5weJ-0005oP-DH for sip@ietf.org; Wed, 26 Jul 2006 23:35:00 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Jul 2006 20:34:58 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,186,1151910000"; d="scan'208"; a="33526674:sNHT25590632" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6R3YwQk032146 for ; Wed, 26 Jul 2006 23:34:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6R3YwYh012857 for ; Wed, 26 Jul 2006 23:34:58 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 23:34:58 -0400 Received: from [10.255.255.157] ([10.86.242.187]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 23:34:58 -0400 Message-ID: <44C83461.4020806@cisco.com> Date: Wed, 26 Jul 2006 23:34:57 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings References: <720BC7A4-8BFF-412E-A6BC-FAC41FA1289B@cisco.com> In-Reply-To: <720BC7A4-8BFF-412E-A6BC-FAC41FA1289B@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 03:34:58.0192 (UTC) FILETIME=[A2576900:01C6B12D] DKIM-Signature: a=rsa-sha1; q=dns; l=5897; t=1153971298; x=1154835298; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20draft-ietf-sip-gruu-09 |To:Cullen=20Jennings=20; X=v=3Dcisco.com=3B=20h=3D7kWnmlADlYzAX5LalCr02cAZX1E=3D; b=n2Ai9ZMbhO3aLDT5NSeia9GGd+52Oe/A4FaehgOSPfvtrkCXgm5d025rq6O5Kp2Bgf1QrZtA zj4KNZktyrsiZua4Ok6/9HIQfr0XFU8swz1HVhXubFtB5bBfpOjq/9rQ; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: IETF SIP List Subject: [Sip] Re: draft-ietf-sip-gruu-09 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for the comments, Cullen. Responses below. Cullen Jennings wrote: > > This looks good - a few comments - all very trivial > > Does this update 3261? If so, nice if header on first page had that I got asked that privately by others as well. I don't think it does. It uses the defined extension behaviors in RFC 3261 to add new functionality. Its not required functionality either; if a client can construct a contact that has the gruu property this spec is not needed (and indeed in a world without nat and firewalls, it could construct one). > > Section 3 - Long lived definition. I'm really not sure what it means to > say that a GRUU has a long life than any of the registrations or that > it is viable for every. I'm not sure it changes behavior of anything. > Is the important property that if the same AOR/Instance registers two > different times it gets the same AOR? Anyways, I can live with the text > exactly as is but I was not getting why it was important. Its important so implementors know that they shouldn't hand out a different gruu on each registration. If I turn on my softphone today, register, and then log out, and tomorrow do the same thing, I should get back the same gruu. This property is important in applications where people store the contact and use it later for a callback or something. > > Figure 1: On the diagonal arrow between GRUU and contact, I think the > end near contact should have "0..1" and the end near the GRUU should > have "0..n" - right now this is swapped. Hmm, I think it is correct as written. A GRUU has 0..n contacts and a contact is bound to a single gruu. > > Section 6, page 12, 4th para or so ... you are talking about mid- dialog > requests. Might be nice to mention how a transaction stateful proxy > knows if something is a middialog request or not. These days I recommend topmost route URI over tags, since its easy to fool a proxy into thinking something is a mid-dialog request by faking a tag. Its harder to fake a route URI. Text now reads: Mid-dialog requests will also be sent to GRUUs, as they are included as the remote-target in dialog-forming and target refresh requests and responses. However, in those cases, a proxy SHOULD only apply services that are meaningful for mid-dialog requests, generally speaking. This excludes screening functions, as well as forwarding ones. A proxy can determine that a request is a mid-dialog request based on the Route header field in the request it receives. If the topmost URI matches one that the proxy placed into the Record-Route header field of a dialog-forming request, then the request is a mid-dialog request. > > Section 6, last para before section 7. I'm not sure I get how anything > behaves differently from an unbound GRUU that exists vs the GRUU does > not exist. Again, i don't have some huge problem with current text but > when I read it, it makes me wonder if there is some difference which I > should understand. 404 vs. 480. 404 if the GRUU simply doesn't exist; 480 if no contacts are bound to it. This is described later on. > > Section 7.1.1.1 - There has been some problems with the way 3261 > allowed a user to install forwarding rules using a REGISTER request. > Part of the problem is that it allows an amplification attack on > someone else that did not provide any consent. It makes me wonder if > now that we have the consent framework moving forward, do we really > want to continue down this path. I realize this is pretty orthogonal > problem to GRUU. Yes, it is. I tend to agree that third party registrations are generally a bad idea these days. However, they exist in rfc3261 and we've not outlawed them. Thus I don't think this is an issue for GRUU to tackle. GRUU merely specifies how they interact. > > Section 8.1.1 - 2nd para. You have "However, that AOR will be rewritten > ..." - I found this hard to follow. Is it the request URI? I'm not sure > how to fix but you might want to have a read of the end of that para > and see if it is all clear to you. Yes. The text is confusing. Hopefully this is clearer: If the UA instance has obtained multiple GRUUs for different AORs as a result of a registration, it SHOULD use one corresponding to the AOR used to send or receive the request. For sending a request, this means that the GRUU corresponds to the AOR present in the From header field. Furthermore, this means that the credentials used for authentication of the request correspond to the ones associated with that AOR. When a peer sends a request to a UA, that request will arrive at the home proxy, and be forwarded to the UA. The GRUU placed into the Contact header field of the response SHOULD correspond to the AOR to which the request was targeted by the peer. Unfortunately, this AOR is not directly present in the request when it is received by the UA. It would have been placed into the Request-URI of the request when sent by the peer. However, upon reaching the home proxy of the UA, the Request-URI is rewritten with the registered contact. It is for this reason that different contacts are needed for each AOR that an instance registers against. When an incoming request arrives, the Request URI can be examined. It will be equal to a registered contact. That contact can be used to map directly to the AOR, and from there, the correct GRUU can be selected. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 23:37:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wef-0000Fs-RA; Wed, 26 Jul 2006 23:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wed-0000E3-QF for sip@ietf.org; Wed, 26 Jul 2006 23:35:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5web-0005pE-Fo for sip@ietf.org; Wed, 26 Jul 2006 23:35:19 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 26 Jul 2006 20:35:17 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,186,1151910000"; d="scan'208"; a="33526698:sNHT23641560" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6R3ZGsG001048; Wed, 26 Jul 2006 23:35:16 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6R3ZGdU029999; Wed, 26 Jul 2006 23:35:16 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 23:35:16 -0400 Received: from [10.255.255.157] ([10.86.242.187]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 23:35:15 -0400 Message-ID: <44C82028.4050102@cisco.com> Date: Wed, 26 Jul 2006 22:08:40 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Relationship between GRUU and callee capabilities References: <002401c69ff6$f8c09660$31713b51@BEMBUSTER> In-Reply-To: <002401c69ff6$f8c09660$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 03:35:15.0969 (UTC) FILETIME=[ACEFF710:01C6B12D] DKIM-Signature: a=rsa-sha1; q=dns; l=2975; t=1153971316; x=1154835316; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Relationship=20between=20GRUU=20and=20callee=20capabilit ies |To:Jeroen=20van=20Bemmel=20; X=v=3Dcisco.com=3B=20h=3DYLZBqNezxJBkjW/QpVaIZELeHMQ=3D; b=DQCBRpCYHO4AyM/kQXqj3W0mqaLDPAVah9fSgLElTcxgTD48eSCcUhjYHBm8mMd6WP6ShKmh HtK1P++nKFwk49pmRNCwNY+grQd97nniOVP+CTafcK9u6W/Bv5FOwHgc; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > In http://www.jdrosen.net/papers/draft-ietf-sip-gruu-09.txt section 6 > figure 1, a GRUU is shown to be associated with 0..n Contacts. Does this > include callee capabilities that were indicated in the registration of > that contact? Yes. > In other words, should the GRUU proxy be able to > reconstruct those capabilities, e.g. for caller preference processing > purposes? Yes. Here is what I have done to clarify. In the section on register processing: Registration processing then continues as defined in RFC 3261. If, after that processing, that contact is bound to the AOR, it also becomes bound to the GRUU associated with that instance ID/AOR pair. In addition, if that contact had callee capabilities associated with it , those capabilities continue to be associated with the contact as it is bound to the GRUU. If, after that processing, the contact was not bound to the AOR (due, for example, to an expiration of zero), the contact is not bound to the GRUU either. and in the section on proxy processing: Otherwise, handling of the GRUU proceeds as specified in RFC 3261 Section 16. For GRUUs, the abstract location service described in Section 16.5 is utilized, producing a set of zero or more contacts, each of which is associated with the same instance ID. If the proxy supports the caller preferences specification , and the request contained Accept-Contact or Reject-Contact header fields, caller preferences are applied to the contact set. If there are more than one contact with the same instance ID, and those contact were registered using the procedures of , those procedures are used to select one. Otherwise, the most recently updated contact is used. This produces zero or one contacts. The server MUST copy the "grid" parameter from the Request-URI (if present) into the new target URI obtained from the registered contact. If there was no "grid" parameter in the Request-URI, the proxy MUST insert a "grid" parameter into the new target URI obtained from the registered contact, and MUST omit a value for the parameter. Note that the "gruu" URI parameter is not copied. If the grid was already present in the contact bound to the GRUU, it is overwritten in this process. If no contacts were bound to the GRUU, the lookup of the GRUU in the abstract location service will result in zero target URIs, eventually causing the proxy to reject the request with a 480 (Temporarily Unavailable) response. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 23:41:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5win-0002Ty-8Q; Wed, 26 Jul 2006 23:39:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wil-0002Tb-LY; Wed, 26 Jul 2006 23:39:35 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wil-0005z4-65; Wed, 26 Jul 2006 23:39:35 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 26 Jul 2006 20:39:35 -0700 X-IronPort-AV: i="4.07,186,1151910000"; d="scan'208"; a="1842218792:sNHT37178866" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6R3dYsF004060; Wed, 26 Jul 2006 20:39:34 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6R3dY79001425; Wed, 26 Jul 2006 20:39:34 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:39:34 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.87]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:39:33 -0700 Message-Id: <4.3.2.7.2.20060726223445.03483818@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2006 22:39:32 -0500 To: "Winterbottom, James" , "Henning Schulzrinne" , "Andrew Newton" From: "James M. Polk" Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance In-Reply-To: References: <44C7A2E0.2000303@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 03:39:33.0738 (UTC) FILETIME=[469464A0:01C6B12E] DKIM-Signature: a=rsa-sha1; q=dns; l=3933; t=1153971574; x=1154835574; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Sip]=20RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=0A=20= 20location-conveyance; X=v=3Dcisco.com=3B=20h=3DhAmRgS99GzbG2OeEQWgu7RKPjS4=3D; b=GwazXRRcXJlVlN69yTz9fvk35yb3hVpXQqSqC5WFHsADMs3p4voSPOf04QieWKZKQh+DNOB+ ooLs0y2BY6iefQgA/xjJo9HsXkOQZOFS0P2H8wo7vXxjLky+ffAZ8scI; Authentication-Results: sj-dkim-8.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: geopriv@ietf.org, IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 08:28 PM 7/26/2006 -0500, Winterbottom, James wrote: >In the case you mention below the reality is that if the target has >moved during the course of routing, the target will either be at place B >by the time dispatch occurs, or at point C which may be further away >still. Henning mentioned above that this is a routing timeframe (of maybe 1 second), not a dispatch timeframe - and that it seems unlikely that routing would be different during that one second. Regardless, the call get completed where the request was sent. >At least in the case of a reference you have the possibility of getting >the current location, which is not possible through any of the >"by-value" means described thus far unless the caller is stationary! Henning and Brian have discussed this already, and that is where SUB/NOT are useful for the ability to subscribe to that calling endpoint to find out where they are at any time during the call. I mentioned that if the UA detects it has moved, it should send a SIP agreed upon UPDATE request (with a new l-by-v) to the PSAP informing it that the caller has moved. This is something that belongs in the ECRIT phonebcp, and perhaps a more general non-emergency sipping doc. >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: Thursday, 27 July 2006 3:14 AM >To: Andrew Newton >Cc: geopriv@ietf.org; IETF SIP List >Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to >location-conveyance > >For location-based routing case, the likelihood of significant updates >in the roughly one second that a call might take from caller to callee >seems unlikely. UAS subscription and polling is clearly more valuable, >so maybe we need to distinguish these cases. (As discussed earlier, >mid-routing updates may lead to bad outcomes since the call might have >been sent to a place A that doesn't know what to do with location update > >n+1 since that new location is really handled by place B.) > >Andrew Newton wrote: > > Henning Schulzrinne wrote: > >>> I believe there are two technical arguments: one is legacy equipment > > >>> (the issue that I'll be facing for quite some time), and >environments > >>> where the location is generated by the network. For the latter, > >>> insertion of the Location header only in emergency situations still > >>> puts the user in control for non-emergency situations. > >>> > >>> > >> > >> For the latter, the combination of the in-progress L7 protocols, DHCP > > >> and LLDP should presumably allow the UAC to obtain location and >insert > >> it by value. Is there a use case not covered by that? > > > > As I said, where location comes from the network. In this scenario, > > there are two possibilities, both up to the user: 1) the UAC >subscribes > > to the location from the network and puts it by value in the call > > flow... meaning all location updates go through the UAC, or 2) the UAC > > > hands out a reference so updates can be independent of the UAC or > > updates based on subscription come from the UAC but are independent of > > > the call. > > > > -andy > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 23:44:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wlW-0006aX-UV; Wed, 26 Jul 2006 23:42:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wlV-0006aP-Jk; Wed, 26 Jul 2006 23:42:25 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wlU-0006S7-Da; Wed, 26 Jul 2006 23:42:25 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Jul 2006 23:37:23 -0400 id 0158818E.44C834F3.00004B59 In-Reply-To: <4.3.2.7.2.20060726222133.03bb4518@email.cisco.com> References: <4.3.2.7.2.20060726222133.03bb4518@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3F49C258-6B35-49AA-ADBD-EB19DE64EF62@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Wed, 26 Jul 2006 23:37:12 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org, geopriv@ietf.org, "Abbott, Nadine B" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 26, 2006, at 11:27 PM, James M. Polk wrote: > I think Geopriv really needs to look at HTTP as a RFC 3693 "using > protocol" to tease out any unique characteristics with that > protocol. That discussion and review shouldn't bog this document > down. Does this sound fair? Most definitely. We've had discussions on HTTP as a using protocol for 3 years in GEOPRIV, HELD being the latest incarnation. The first proposals ran into serious privacy concerns. Anything that simply says "use HTTP" is an attempt to work around answering the serious privacy concerns raised in GEOPRIV. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 23:45:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wmV-0007YP-FP; Wed, 26 Jul 2006 23:43:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wmT-0007YC-Ug; Wed, 26 Jul 2006 23:43:25 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wmT-0006ds-J7; Wed, 26 Jul 2006 23:43:25 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 22:43:25 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 26 Jul 2006 22:43:24 -0500 Received: from AOPEX4.andrew.com ([10.3.20.127]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 22:43:23 -0500 Message-ID: From: "Dawson, Martin" To: "Henning Schulzrinne" , "Brian Rosen" Date: Wed, 26 Jul 2006 22:43:20 -0500 Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 27 Jul 2006 03:43:23.0988 (UTC) FILETIME=[CFD1C140:01C6B12E] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <26AE42F5-3170-434B-8E4F-4D7F22FA2E7C@cs.columbia.edu> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcaxLE33h2O6juuxR2SXzGN9/AFz+AAAm3+g X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: IETF SIP List , geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sounds like a very pragmatic approach Henning - I agree. Cheers, Martin > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, 27 July 2006 1:25 PM > To: Brian Rosen > Cc: IETF SIP List; geopriv@ietf.org > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- > conveyance >=20 > My suggestion would be >=20 > - to focus the draft on just defining the Location header syntax, > without ruling out any particular mechanism or scheme; this would > make the draft really short (which I would find helpful). >=20 > - and then add one section to the draft that prototypically defines > what a particular scheme that wants to appear in the Location header > needs to define, using the non-controversial cid mechanism as the > example. Other, separate, drafts can then define other modes, > following the same template. Documents such as the phone-bcp can then > pick some suitable must-implement subset and make emergency-call- > specific recommendations, rather than sprinkling these throughout the > conveyance document and repeating some in the phone-bcp. Most of > these are, in any event, operational recommendations, not for > ensuring protocol-level interoperability. >=20 > That way, the conveyance draft can be extremely short (even shorter > if the requirements are omitted...) and can get done, and we avoid > engineering operational requirements on the fly, commingling > emergency and non-emergency cases, as seems to be happening now. >=20 > I think protocol documents should define what's needed for > interoperability; BCPs can make more specific, situation-specific > recommendations. Commingling the two seems to be a recipe for > deadlock or arbitrary, non-technically-grounded decisions that are > more lawyer-like than engineering-like ("you did not mention > technique X in some meeting N years ago and thus you can't bring it > up now!") >=20 > Henning >=20 > On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote: >=20 > > At this point, I think we need some chair guidance and by that I > > think it's > > a combo of geopriv and sip chairs. > > > > We seem to have a couple of significant open questions. I think > > most of the > > other stuff (like the "allow sending to router") will converge. > > > > There seems to be some opposition to allowing sip/sips/pres: in a > > Location > > Header. The opposition seems to be that despite 4119, somehow, SIP > > (presence subscription) is not a "using protocol". I "think" a > > ruling from > > the bench on that would work. > > > > There is also opposition to defining the allowed schemes as a > > specific list, > > with a defined (easy) extension mechanism. > > > > Related to that, there are some who want location-conveyance to > > define an > > HTTP based location dereference mechanism, and on the opposite end, > > we have > > people saying we haven't even agreed to support any form of > > location-by-reference. > > > > The authors would like to know what to do now. > > > > Brian > > > >> -----Original Message----- > >> From: Andrew Newton [mailto:andy@hxr.us] > >> Sent: Wednesday, July 26, 2006 9:58 PM > >> To: Winterbottom, James > >> Cc: sip@ietf.org; geopriv@ietf.org; Abbott, Nadine B; Henning > >> Schulzrinne > >> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- > >> conveyance > >> > >> > >> On Jul 26, 2006, at 9:43 PM, Winterbottom, James wrote: > >> > >>> Andy, > >>> > >>> RFC-4119 says "However, the usage of this location object format is > >>> not > >>> limited to presence-using protocols-- any protocol that can > >>> carry XML > >>> or MIME types can carry PIDF." > >>> > >>> It seems to me that restricting the allowed schema in what is > >>> supposed > >>> to be a location conveyance specification is in opposition to this > >>> statement. > >> > >> Did somebody say that HTTP was a presence-using protocol? > >> > >> -andy > >> > >> ps. you can find my location with the following reference URIs: > >> > >> gopher://fatchance.hxr.us/you-still-have-a-gopher-client > >> news:alt.locations.people.secretly-being-watched > >> telnet://screen-scrapers.are.us/ > >> dns:cached-publicly-around-the-world.com?type=3DHOST > >> > >> > >> > >> _______________________________________________ > >> Geopriv mailing list > >> Geopriv@ietf.org > >> https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 23:48:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wpU-0002C1-Ua; Wed, 26 Jul 2006 23:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wpT-0002Bh-V7; Wed, 26 Jul 2006 23:46:31 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wpR-0006zA-KM; Wed, 26 Jul 2006 23:46:31 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Jul 2006 20:46:29 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6R3kSVa018298; Wed, 26 Jul 2006 20:46:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6R3kS2D023762; Wed, 26 Jul 2006 20:46:28 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:44:00 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.87]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:44:00 -0700 Message-Id: <4.3.2.7.2.20060726224314.0198b090@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2006 22:43:59 -0500 To: Andrew Newton , Henning Schulzrinne From: "James M. Polk" Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance In-Reply-To: References: <44C7E3AE.6070103@cs.columbia.edu> <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu> <44C777D8.9030008@hxr.us> <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> <011501c6b0c9$09681910$31713b51@BEMBUSTER> <44C7919D.1010203@hxr.us> <44C79CA6.5040604@cs.columbia.edu> <44C7AA47.4080104@hxr.us> <44C7C8BF.4010103@cs.columbia.edu> <44C7D53C.3020205@hxr.us> <44C7E3AE.6070103@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 03:44:00.0336 (UTC) FILETIME=[E57C0500:01C6B12E] DKIM-Signature: a=rsa-sha1; q=dns; l=442; t=1153971988; x=1154835988; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=0A=20= 20location-conveyance; X=v=3Dcisco.com=3B=20h=3D6MjbpL8IiYLdDIsKBDAd+QlIgwA=3D; b=Sg07xKGWBsjQlxXLr3JYjt9zSO8d8kXtg/B0jVI+kLkC0uDhCceHCdc8k23rsoGqBGSpY+G3 utaDkEVD7ESE+DzVe67FlkRmTcCwWwv+Z3kUmUVsrDxqt4UywjDJXj1q; Authentication-Results: sj-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: geopriv@ietf.org, IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 09:42 PM 7/26/2006 -0400, Andrew Newton wrote: >This is yet another rule, that is if data URI is mentioned... >adding more complexity. You can pass by >value either via MIME or data: URI. If you pass by value using the >data: URI, you have to restrict ruleset references. > >-andy > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 23:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wxt-0001KH-VP; Wed, 26 Jul 2006 23:55:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wxs-0001FB-OL; Wed, 26 Jul 2006 23:55:12 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wxr-0007fG-HS; Wed, 26 Jul 2006 23:55:12 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Jul 2006 23:55:20 -0400 id 0158818A.44C83929.00004FCC Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <043701c6b129$e662d4d0$640fa8c0@cis.neustar.com> References: <043701c6b129$e662d4d0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <408E156E-51BC-4E20-8154-9CCBDD262474@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Teasing apart positions (was Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance) Date: Wed, 26 Jul 2006 23:55:08 -0400 To: IETF SIP List , GEOPRIV X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote: > The authors would like to know what to do now. Let's start by trying to tease apart certain positions. Given Jon Peterson's message: http://www1.ietf.org/mail-archive/web/sip/current/msg15537.html Does anybody still believe that subscriptions to PIDF-LOs with pres: requires more definition? -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 26 23:59:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wzw-0004Qd-02; Wed, 26 Jul 2006 23:57:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wzu-0004P0-HG; Wed, 26 Jul 2006 23:57:18 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wzt-0007rH-4j; Wed, 26 Jul 2006 23:57:18 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 26 Jul 2006 20:57:13 -0700 X-IronPort-AV: i="4.07,186,1151910000"; d="scan'208"; a="1842222048:sNHT675014066" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6R3vCEV005238; Wed, 26 Jul 2006 20:57:12 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6R3vC79006199; Wed, 26 Jul 2006 20:57:12 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:57:12 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.87]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:57:12 -0700 Message-Id: <4.3.2.7.2.20060726224552.028bbef8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2006 22:57:09 -0500 To: "Winterbottom, James" , "Andrew Newton" From: "James M. Polk" Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance In-Reply-To: References: <3AE00FE1-2B2E-44D8-8A02-D4D0457AF4DA@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 03:57:12.0230 (UTC) FILETIME=[BD7D7460:01C6B130] DKIM-Signature: a=rsa-sha1; q=dns; l=3407; t=1153972632; x=1154836632; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Sip]=20RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=0A=20= 20location-conveyance; X=v=3Dcisco.com=3B=20h=3DhAmRgS99GzbG2OeEQWgu7RKPjS4=3D; b=hGawmnm/Atqd0aqrOck+chxOPVApmPtzTd2IlUnWrKZjjZPUttuHAqTQEP2MZzud56rw3/2+ fXORh1hg54rR7aGXAN9XmrWNhk4ZPUH5sEF+xShOU89lvwybOTHHeK4z; Authentication-Results: sj-dkim-5.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: geopriv@ietf.org, IETF SIP List , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 08:48 PM 7/26/2006 -0500, Winterbottom, James wrote: >To what do you send the SIP update and for what do you request the >update? to the latter first: UPDATE is not requested, it is a request message just like INVITE. If the PSAP wants to subscribe to the caller, that's a separate transaction in SIP. to the former, are you asking what's the destination address the UPDATE goes to, or what triggers the UPDATE message? Your phrasing could be to either the way I read it. I'll answer both below as best I can: To a destination address, if before the UAC receives a 200 OK with a Contact header (indicating the PSAP URI), the UPDATE needs to be built just like the original INVITE (with the new location) and sent to the urn:service:sos and get routed to the PSAP. If this results in a new PSAP due to movement, the INVITE times out and the new INVITE is to the urn:service:sos with a new location and the call goes through. We can't build this to the corner case of someone moving that fast, as much as that won't make some happy. If the 200 OK has been received by the UAC, the UPDATE will go at the PSAP URI in the Contact header of that 200 OK, and therefore go straight at the PSAP, the fastest way there (barring any route headers that are forced into the request). Due to a trigger, this is UAC device specific as it is the device that senses a sufficient change in its location to send a new location. This will in all likelihood be after the 200 OK has been received, even after the call has been established, and should follow what is in the paragraph above this one to the PSAP. It has been suggested that a reINVITE can be sent with the new location *after* the call is eestablished, and that's fine, but not what the SIP WG agreed to several IETFs ago, but it would work in either case. >-----Original Message----- >From: Andrew Newton [mailto:andy@hxr.us] >Sent: Thursday, 27 July 2006 11:47 AM >To: Winterbottom, James >Cc: Henning Schulzrinne; geopriv@ietf.org; IETF SIP List >Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to >location-conveyance > > >On Jul 26, 2006, at 9:28 PM, Winterbottom, James wrote: > > > In the case you mention below the reality is that if the target has > > moved during the course of routing, the target will either be at > > place B > > by the time dispatch occurs, or at point C which may be further away > > still. > > At least in the case of a reference you have the possibility of > > getting > > the current location, which is not possible through any of the > > "by-value" means described thus far unless the caller is stationary! > > > >What about a SIP UPDATE? Section 5.3 of the draft. > >-andy > > > > > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 00:10:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5xAq-0003F8-K2; Thu, 27 Jul 2006 00:08:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5xAp-0003Ex-9y; Thu, 27 Jul 2006 00:08:35 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5xAn-0000l4-Vl; Thu, 27 Jul 2006 00:08:35 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 26 Jul 2006 21:08:34 -0700 X-IronPort-AV: i="4.07,186,1151910000"; d="scan'208"; a="308346964:sNHT26145756" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6R48Xwq006915; Wed, 26 Jul 2006 21:08:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6R48XHW028363; Wed, 26 Jul 2006 21:08:33 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 21:08:32 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.87]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 21:08:32 -0700 Message-Id: <4.3.2.7.2.20060726230723.03693008@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2006 23:08:31 -0500 To: Andrew Newton From: "James M. Polk" Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance In-Reply-To: <3F49C258-6B35-49AA-ADBD-EB19DE64EF62@hxr.us> References: <4.3.2.7.2.20060726222133.03bb4518@email.cisco.com> <4.3.2.7.2.20060726222133.03bb4518@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 04:08:32.0484 (UTC) FILETIME=[52F3FA40:01C6B132] DKIM-Signature: a=rsa-sha1; q=dns; l=1080; t=1153973313; x=1154837313; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=0A=20= 20location-conveyance; X=v=3Dcisco.com=3B=20h=3D6MjbpL8IiYLdDIsKBDAd+QlIgwA=3D; b=JCwJC2ie+byCiOQXhV85vprYDkEcDVwq0UjWsxlYWrtihAP2rZcOGCuJeb8D0Tl8ruyC4fpe +nRnLTDHqa73z1dZiNPYozmMYiVTrQXw0SbdDky6Bwon+KgBe+rQlOjH; Authentication-Results: sj-dkim-6.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, geopriv@ietf.org, "Abbott, Nadine B" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 11:37 PM 7/26/2006 -0400, Andrew Newton wrote: >On Jul 26, 2006, at 11:27 PM, James M. Polk wrote: > >>I think Geopriv really needs to look at HTTP as a RFC 3693 "using >>protocol" to tease out any unique characteristics with that >>protocol. That discussion and review shouldn't bog this document >>down. Does this sound fair? > >Most definitely. We've had discussions on HTTP as a using protocol >for 3 years in GEOPRIV, HELD being the latest incarnation. The first >proposals ran into serious privacy concerns. Anything that simply >says "use HTTP" is an attempt to work around answering the serious >privacy concerns raised in GEOPRIV. is this said with your WG chair hat on? It sounds pretty definitive to these ears... >-andy > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 00:33:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5xXW-0003Aq-5Z; Thu, 27 Jul 2006 00:32:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5xXU-0003Af-Tz; Thu, 27 Jul 2006 00:32:00 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5xXS-00031h-CW; Thu, 27 Jul 2006 00:32:00 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 23:31:57 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 26 Jul 2006 23:31:57 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 23:31:57 -0500 Message-ID: From: "Winterbottom, James" To: "James M. Polk" , "Abbott, Nadine B" , "Brian Rosen" , Date: Wed, 26 Jul 2006 23:31:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 27 Jul 2006 04:31:57.0171 (UTC) FILETIME=[98363430:01C6B135] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <4.3.2.7.2.20060726222133.03bb4518@email.cisco.com> Content-class: urn:content-classes:message Thread-Topic: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcaxLLlZxvA3TJ1/Q+aMLV2RtdpWBAABAXeg X-Spam-Score: 0.5 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James, By the restricting of the schema you are saying MUST NOT as that is what is defined in the ABNF, so if I implement the specification anything else is invalid. I agree wholeheartedly with Henning's last suggestion, leave the schema open but only describe the methods you are going to specifically recommend. Cheers The other James -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Thursday, 27 July 2006 1:28 PM To: Winterbottom, James; Abbott, Nadine B; Brian Rosen; sip@ietf.org Cc: geopriv@ietf.org Subject: RE: [Geopriv] Consensus on changes to location-conveyance James We won't say anything like "MUST only use sip/sips/pres/cid, and MUST NOT=20 =2E..". I don't believe we will take a negative tone with what isn't allowed=20 in this respect, but we will state explicitly what is defined for use. We will likely state something like this: ' this document defines usage of=20 the sip, sips, pres and cid schemas for location conveyance, and here's how...' I think Geopriv really needs to look at HTTP as a RFC 3693 "using protocol"=20 to tease out any unique characteristics with that protocol. That=20 discussion and review shouldn't bog this document down. Does this sound fair? At 06:31 PM 7/26/2006 -0500, Winterbottom, James wrote: >Brian, > >I don't care if you don't mention how to de-reference URI types other >than sip/sips/cid/pres in the document or not. But I do not want the >schema artificially constrained to exclude URI types such as HTTP. There >is clearly not consensus to justify this exclusion, so please leave >schema unchanged and make your recommendations in the text. > >Cheers >James > > > >-----Original Message----- >From: Abbott, Nadine B [mailto:nabbott@telcordia.com] >Sent: Thursday, 27 July 2006 7:44 AM >To: Brian Rosen; sip@ietf.org >Cc: geopriv@ietf.org >Subject: RE: [Geopriv] Consensus on changes to location-conveyance > >Brian, > >Actually, I was thinking that in other industry work which is trying to >leverage and provide transitional strategies to migrate to using SIP to >support emergency services, the and long-term solutions that we have >defined assume a capabity to provide location-by-reference. I think it >would be very useful to have this defined in a standard SIP header >mechanism in such a way that we need not redefine migratory solutions >that have begun to be implemented. If an HTTPS URI can be used as the >location-by-reference, this will be helpful, I think. > >I don't understand your urgency to make location-by-reference only an >all-sip-all-the-time thing. >And from all the other emails on this topic, it didn't seem to me that >there is a consensus to do this. > >Nadine > >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: Wednesday, July 26, 2006 3:15 PM >To: Abbott, Nadine B; sip@ietf.org >Cc: geopriv@ietf.org >Subject: RE: [Geopriv] Consensus on changes to location-conveyance > >Nadine > >Are you saying that it's your opinion sip-location-conveyance MUST >define an HTTP dereference procedure? > >If you do, why? What is the use-case or requirement? > >Would it not be pretty reasonable to require a separate document that >defines a location-by-reference mechanism, protocol, and geopriv "using >protocol" analysis? If that document specifically extended what was >allowed in the location header, would that not be reasonable? > >I think we have to include "A" dereference mechanism in the >location-conveyance document. It seems just including sip/sips/prez is >a reasonable, all-sip-all-the-time approach IN THIS DOCUMENT. That >certainly does not preclude another document describing another way. > >Doesn't it seem just a little weird to have a sip-location-conveyance >document describing any kind of http based location conveyance >(de-reference) protocol, especially one created whole cloth without any >other parts? > >Doesn't it seem in keeping with the geopriv approach that in order to >have another "using protocol" it has to have a geopriv review? That is >what leads to restricting the URI schemes. Would you prefer to let it >be wide open, so any protocol anyone thinks about can be used with the >location header? I can't see geopriv going along with that. We're >going to make it a one line ABNF to add a new scheme to the list of >allowed schemes. > >It seems to me that if it's desired to define some bare-bones HTTP >location by reference protocol, then that should be a separate document, >which can easily extend the allowable schemes in the Location header. >I'm not sure it might be better to define ALL of that in the L7 >protocol, but I wouldn't be opposed to a simple "raw GET" RFC as long as >it got a full geopriv review. >I just don't see where it makes any sense to force that into a sip >document. > >Brian > > > -----Original Message----- > > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > > Sent: Wednesday, July 26, 2006 2:14 PM > > To: sip@ietf.org > > Cc: geopriv@ietf.org > > Subject: RE: [Geopriv] Consensus on changes to location-conveyance > > > > > > I don't agree that there is a consensus to preclude the use of HTTP. > > I would favor not placing your proposed restriction on the URI scheme > > for expressing a location reference in the SIP location conveyance > > draft; or at least including HTTP as a valid location-reference URI > > type. > > > > Regards, > > Nadine Abbott > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Tuesday, July 25, 2006 1:38 PM > > To: sip@ietf.org > > Cc: geopriv@ietf.org > > Subject: [Geopriv] Consensus on changes to location-conveyance > > > > I have put out a number of emails on proposed changes to location > > conveyance. Some of them have sparked a number of comments. My > > summary of consensus on these issues is: > > > > 1. We proposed to explicitly disallow use of a Data URI, which would > > allow specification of a Location-by-value in a header. There was a > > lot of list traffic on this, currently in the state where Keith asked > > for a real use case for it. So far, we don't see a use case that > > cannot be provided by location-by-reference in a header. If we don't > > get a good use case, I think consensus is to disallow > > location-by-value in a header. > > > > 2. Dereferencing location-by-reference. We had initially proposed to > > document a process to use a raw HTTP(S) Get to dereference. There was > > > a lot of discussion, and then I made a new proposal, see item 6. > > > > 3. We proposed to allow a Reason header with a 424 Bad Location > > response. This seems to be acceptable to the WG. Geopriv will create > > > and populate the registry in a separate draft. > > > > 4. We proposed to explicitly allow hop-by-hop TLS security for > > location when the endpoint wished to allow routing based on location. > > > We further proposed to interpret "Do not Distribute" flags as allowing > > > sending of the location to the routing database (LoST for example). > > Hannes pointed out that there was a proposal to allow two Location > > headers, one of which could be used for routing and another for onward > > > forwarding to the recipient. Hannes' message seemed to agree that "Do >not distribute" > > would allow sending of the location to the routing-by-location > > database, but would obligate the proxy that did that to remove the > > location before it forwarded the message. There were no other >messages on this thread. > > We conclude that allowing hop-by-hop security for location based > > routing is acceptable, and Do Not Distribute DOES allow forwarding to > > a routing database, but requires that the proxy doing the location > > based route to remove the location it uses for that purpose. > > > > 5. We proposed to create a parameter and a registry to distinguish > > multiple ways to dereference a location where HTTP(S) was the >transport. > > Resolution of this issue depends on resolution of issue 6. > > > > 6. We proposed to allow sip/sips and pres: in the location header. I > > later speculated that if we allow this, it forms a simple way to do > > location-by-reference, and we could eliminate the raw HTTP(S) Get > > proposal, with the parameter and registry entirely. There was some > > list traffic in favor of this. Martin Thompson is skeptical that SIP > > Presence Subscribe/Notify is actually allowed as a geopriv "using > > protocol". Several of think that it is. If we don't get any more > > comments on this proposal, we will allow sip/sips and pres, not have > > any > > http(s) resolution text, and not propose a parameter and accompanying > > registry. > > > > If this does not reflect your position, please speak up now. > > > > Brian > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv > >----------------------------------------------------------------------- ------------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >----------------------------------------------------------------------- ------------------------- >[mf2] > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 01:02:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5xz9-0001Gx-Gf; Thu, 27 Jul 2006 01:00:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5xz7-0001Gp-6T; Thu, 27 Jul 2006 01:00:33 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5xz5-0005mC-Tv; Thu, 27 Jul 2006 01:00:33 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 00:00:31 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 27 Jul 2006 00:00:31 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 00:00:30 -0500 Message-ID: From: "Thomson, Martin" To: "Andrew Newton" Date: Thu, 27 Jul 2006 00:00:29 -0500 Subject: RE: Teasing apart positions (was Re: [Sip] RE: [Geopriv] Consensus onchanges to location-conveyance) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 27 Jul 2006 05:00:30.0648 (UTC) FILETIME=[95860B80:01C6B139] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <408E156E-51BC-4E20-8154-9CCBDD262474@hxr.us> Content-class: urn:content-classes:message Thread-Topic: Teasing apart positions (was Re: [Sip] RE: [Geopriv] Consensus onchanges to location-conveyance) Thread-Index: AcaxMHmw6hxTqparSMiNsLAsa89MsQABbbzQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1045454383==" Errors-To: sip-bounces@ietf.org --===============1045454383== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message U2luY2UgSSByYWlzZWQgdGhlIHF1ZXN0aW9uLCBJJ2xsIGFuc3dlci4NCg0KV2UgaGF2ZSBhIHNl dCBvZiByZXF1aXJlbWVudHMgb24gYSB1c2luZyBwcm90b2NvbCBpbiBSRkMgMzY5My4NCg0KSSBi ZWxpZXZlIHRoYXQgSFRUUCB3aXRoIHByb3BlciBjb25zdHJhaW50cyAoVExTLCBldGMuLi4pIGNh biBtZWV0LCBvciBhbHJlYWR5IG1lZXRzLCB0aG9zZSByZXF1aXJlbWVudHMuICBUaGF0IGlzIGly cmVzcGVjdGl2ZSBvZiBhbnkgZGVjaXNpb25zIHRoYXQgbmVlZCB0byBiZSBtYWRlIGFib3V0IHNl Y29uZGFyeSBjb25jZXJucyBsaWtlIHdoZXRoZXIgSFRUUCBpcyBkZXNpcmFibGUsIG9wdGltYWws IGRlcGxveWFibGUgZXRjLi4uICBIb3dldmVyLCBpdCBpcyBjbGVhciB0aGF0IHBlb3BsZSBhcmVu J3QgaGFwcHkgd2l0aCB0aGlzIHBvc2l0aW9uIGFuZCBhcmUgcmVxdWVzdGluZyB0aGF0IHRoaXMg YmUgZG9jdW1lbnRlZCwgYXMgYW4gUkZDLiAgSnVzdCB0byBnZXQgaXQgYWxsIG91dCBpbiB0aGUg b3Blbi4gIFByZXN1bWFibHkgdGhpcyB3b3VsZCBiZSBhIHN0YW5kYXJkcyB0cmFjayBSRkMgdGhh dCwgbGlrZSBsb2NhdGlvbi1jb252ZXlhbmNlLCBoaWdobGlnaHRzIGhvdyB0aGUgUkZDIDM2OTMg cmVxdWlyZW1lbnRzIGFyZSBhZGRyZXNzZWQuDQoNClRoYXQncyBhIHNvdW5kIGFyZ3VtZW50LCBh bmQgb2J2aW91c2x5IGxvY2F0aW9uLWNvbnZleWFuY2UgaGFkIHRvIG1lZXQgdGhhdCBzdGFuZGFy ZCBmb3IgdXMgdG8gYmUgaGFwcHkuICBOb3csIEkgYXNrIHRoYXQgeW91IGdvIGJhY2ssIHRha2Ug dGhlIGFib3ZlIHBhcmFncmFwaCBhbmQgcGVyZm9ybSBvbmUgc2ltcGxlIG9wZXJhdGlvbiBhbmQg cmVhZCBpdCBhZ2Fpbjogcy9IVFRQL1NJUC9nLiAgSXMgdGhlIGFyZ3VtZW50IGFueSBkaWZmZXJl bnQgaW4gdGhlIHByZXNlbmNlIG9mIFJGQyA0MDc5PyAgSXMgYW4gaW5mb3JtYXRpb25hbCBSRkMg dGhhdCBkb2Vzbid0IGFkZHJlc3Mgc3BlY2lmaWMgcmVxdWlyZW1lbnRzIGFkZXF1YXRlPyAgSSdk IHN1Z2dlc3QgdGhhdCBpdCB3b3VsZG4ndCBtYWtlIHRoZSBncmFkZSBmb3IgSFRUUC4NCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmRyZXcgTmV3dG9uIFttYWlsdG86 YW5keUBoeHIudXNdDQo+IFNlbnQ6IFRodXJzZGF5LCAyNyBKdWx5IDIwMDYgMTo1NSBQTQ0KPiBU bzogSUVURiBTSVAgTGlzdDsgR0VPUFJJVg0KPiBTdWJqZWN0OiBUZWFzaW5nIGFwYXJ0IHBvc2l0 aW9ucyAod2FzIFJlOiBbU2lwXSBSRTogW0dlb3ByaXZdIENvbnNlbnN1cw0KPiBvbmNoYW5nZXMg dG8gbG9jYXRpb24tY29udmV5YW5jZSkNCj4gDQo+IA0KPiBPbiBKdWwgMjYsIDIwMDYsIGF0IDEx OjA4IFBNLCBCcmlhbiBSb3NlbiB3cm90ZToNCj4gPiBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRv IGtub3cgd2hhdCB0byBkbyBub3cuDQo+IA0KPiBMZXQncyBzdGFydCBieSB0cnlpbmcgdG8gdGVh c2UgYXBhcnQgY2VydGFpbiBwb3NpdGlvbnMuDQo+IA0KPiBHaXZlbiBKb24gUGV0ZXJzb24ncyBt ZXNzYWdlOg0KPiBodHRwOi8vd3d3MS5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcC9jdXJy ZW50L21zZzE1NTM3Lmh0bWwNCj4gDQo+IERvZXMgYW55Ym9keSBzdGlsbCBiZWxpZXZlIHRoYXQg c3Vic2NyaXB0aW9ucyB0byBQSURGLUxPcyB3aXRoIHByZXM6DQo+IHJlcXVpcmVzIG1vcmUgZGVm aW5pdGlvbj8NCj4gDQo+IC1hbmR5DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBHZW9wcml2IG1haWxpbmcgbGlzdA0KPiBHZW9wcml2QGll dGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2Ug aXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJp dmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAg DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6 ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============1045454383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1045454383==-- From sip-bounces@ietf.org Thu Jul 27 02:21:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5zDC-0004nr-L3; Thu, 27 Jul 2006 02:19:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5zDA-0004gf-Tg for sip@ietf.org; Thu, 27 Jul 2006 02:19:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wiP-0005xG-0e for sip@ietf.org; Wed, 26 Jul 2006 23:39:13 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5wec-0007oF-8F for sip@ietf.org; Wed, 26 Jul 2006 23:35:20 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 26 Jul 2006 20:35:18 -0700 X-IronPort-AV: i="4.07,186,1151910000"; d="scan'208"; a="1842217992:sNHT26877812" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6R3ZHHs002631; Wed, 26 Jul 2006 20:35:17 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6R3ZDHW011519; Wed, 26 Jul 2006 20:35:16 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 23:35:15 -0400 Received: from [10.255.255.157] ([10.86.242.187]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 23:35:14 -0400 Message-ID: <44C81E22.50508@cisco.com> Date: Wed, 26 Jul 2006 22:00:02 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG? References: <475FF955A05DD411980D00508B6D5FB01369D329@en0033exch001u.uk.lucent.com> <200607060155.k661ttcT018150@dragon.ariadne.com> In-Reply-To: <200607060155.k661ttcT018150@dragon.ariadne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 03:35:14.0973 (UTC) FILETIME=[AC57FCD0:01C6B12D] DKIM-Signature: a=rsa-sha1; q=dns; l=2954; t=1153971317; x=1154835317; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-gruu-09.txt=20ready=20for=20IESG?; X=v=3Dcisco.com=3B=20h=3Dq4GVT5SdtVNY0j7w9/+FC6EIpzA=3D; b=hjaOKBhML3k9F7bBVj3Bua2VBRu2S0Jbyv2bO/0aCJeUbw9Cb5fAClqGNiMQns0OkE2BC9Hv 6+z9sKnd9xWsPpcL/cC3dCCKgs7lo1m6D564xL6znj4bG5NKxQ86bFoX; Authentication-Results: sj-dkim-8.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: sip@ietf.org, drage@lucent.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Dale.Worley@comcast.net wrote: > I fear this is an issue that was disposed of before and I don't > realize it: > > I think the I-D needs to make clearer that when sending a request with > a GRUU that the request must be sent via an outbound proxy for the > GRUU's domain. This is needed to make the machinery work, but isn't > stated explicitly as a UA requirement, it's implied in a section of > the I-D that appears to be a proxy requirement. Actually, GRUU works just fine if there is NO outbound proxy at all. Consider the case of a call between Alice and Bob. Alice sends the INVITE directly to Bob's proxy, which record-routes and forwards to Bob. Now, when Bob sends a mid-dialog request, the r-uri has the gruu and the Route points to the proxy in Bob's domain. The request goes to that proxy. From there, as there are no more route headers, the r-uri is looked up, which goes to the home proxy in Alice's domain. The gruu is translated by the home proxy to the registered contact and the request is routed there. What doesn't work so well is if a user has multiple outbound proxies for multiple providers, and it ends up sending a request to provider X with a Contact whose GRUU is from provider Y. In this case we will end up with the nasty spiral that was in early versions of GRUU. It might still work, but there are issues. I consider this a pretty far fetched corner case. However, the assumptions here are worth mentioning. I've added the following text in the section on using GRUU: In addition, if the UA is making use of an outbound proxy, the GRUU that is placed into the Contact header field of a request MUST be one that was obtained from the same domain as the outbound proxy. This assumes that a user agent is aware of the domain associated with each outbound proxy. This specification does not require the use of an outbound proxy; it merely introduces a requirement in cases where one is used. > > There's also the question of how the UA discovers the correct outbound > proxy address. Strictly speaking, without a standardized mechanism, > different vendors could have incompatible implementations. I admit > that this isn't much worse than the UA configuration problem as it now > stands. Perhaps a good dodge is to allow (absent other configuration) > the UA to use the proxy for GRUU's domain as an outgoing proxy for > requests using that GRUU as a Contact? Per above, you don't need an outbound proxy. There is still this issue of, if you use one, how did you discover it. Thats a recognized open issue right now with sip-outbound, and not one that I think we need to address in this specification. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 02:33:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5zPf-0007fZ-1Z; Thu, 27 Jul 2006 02:32:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5zPd-0007ZD-0j for sip@ietf.org; Thu, 27 Jul 2006 02:32:01 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5zPb-0002jd-MI for sip@ietf.org; Thu, 27 Jul 2006 02:32:00 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 45BADAC2B3; Thu, 27 Jul 2006 09:31:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17608.24030.174463.937832@harjus.tutpro.com> Date: Thu, 27 Jul 2006 09:31:58 +0300 To: Jonathan Rosenberg Subject: [Sip] Re: draft-ietf-sip-gruu-09 In-Reply-To: <44C83461.4020806@cisco.com> References: <720BC7A4-8BFF-412E-A6BC-FAC41FA1289B@cisco.com> <44C83461.4020806@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Cullen Jennings , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg writes: > If the > topmost URI matches one that the proxy placed into the Record-Route > header field of a dialog-forming request, then the request is a > mid-dialog request. jonathan, how can proxy tell apart a pre-loaded Route header from proxy placed? -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 02:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5zia-0004dy-JQ; Thu, 27 Jul 2006 02:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ziZ-0004ds-GC for sip@ietf.org; Thu, 27 Jul 2006 02:51:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5y2c-0006BW-TG for sip@ietf.org; Thu, 27 Jul 2006 01:04:10 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5xYV-0000g3-Os for sip@ietf.org; Thu, 27 Jul 2006 00:33:07 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Jul 2006 00:33:01 -0400 X-IronPort-AV: i="4.07,186,1151899200"; d="scan'208"; a="94067863:sNHT29268724" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6R4X1lj011826; Thu, 27 Jul 2006 00:33:01 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6R4X1dU009126; Thu, 27 Jul 2006 00:33:01 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 00:33:01 -0400 Received: from [10.255.255.157] ([10.86.242.187]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 00:33:00 -0400 Message-ID: <44C841FB.7010601@cisco.com> Date: Thu, 27 Jul 2006 00:32:59 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] draft-ietf-sip-gruu-09 References: <200606262132.k5QLWVZQ023989@dragon.ariadne.com> In-Reply-To: <200606262132.k5QLWVZQ023989@dragon.ariadne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 04:33:00.0732 (UTC) FILETIME=[BE18D7C0:01C6B135] DKIM-Signature: a=rsa-sha1; q=dns; l=7205; t=1153974781; x=1154838781; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-gruu-09 |To:Dale.Worley@comcast.net; X=v=3Dcisco.com=3B=20h=3DO8HByhcMbAZHwIycqLttf1ne5yk=3D; b=RpceY8k/iRSehbLiv20mkI/Ip4T/flb6VRT0pCf9idz3Yja+mCBza/cNjuI8gdSXgtF5FgHm N48n7jsspiIcE5ZS9cjD7wBlysJRAUmnCkhMNySvnImagcTB5u2QDW3H; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Dale.Worley@comcast.net wrote: > I've gone over draft-ietf-sip-gruu-09, and it's a fine piece of work, > I must say. As far as I can tell, every doubt I've had about the GRUU > machinery has been resolved (except for the "edge router" problem, > which has been dealt with via sip-outbound). Thanks! > I've written up some > editorial changes to the I-D. I don't think that any of these change > the protocol, but this is such an important I-D that it ought to be > described as rigorously as possible. > > ---------------------------------------------------------------------- > > There seems to be disagreement as to what the plural of GRUU is -- > GRUU or GRUUs. E.g., section 13, page 31 uses both "Furthermore, > GRUUs do not address" and "These GRUU will be passed". There is a > similar inconsistency regarding the plural of AOR. Well, this topic has come up for the term URI, which is the last U in GRUU. So it would stand to reason that if the plural of URI is URIs, then the plural of GRUU is GRUUs. I found some email threads on this topic, for example: http://lists.w3.org/Archives/Public/www-tag/2002Aug/0124.html and apparently this was an open issue in the preparation of the revision to 2396: http://www.gbiv.com/protocols/uri/rev-2002/issues.html#023-URI-plural the conclusion appears to be that the plural of URI is URIs. So, I suggest we follow suit and have the plural of GRUU be GRUUs. > > Section 3, page 5: "the following is true" should be "the following > three properties are true", in order to ensure there is no ambiguity > about the definition. fixed. > > Section 4.3, page 7: "Each tuple also has" s.b. "Each tuple has", as > there is no preceding discussion of anything that "each tuple has". > (This actually caused me some confusion the first time I read it!) fixed. > > Section 5, page 9: ", and to easily recognize that the URI has the > GRUU property" s.b. omitted, as it is the "gruu" parameter that does > that, not the "opaque" parameter. Well, thats debatable. The owner of the domain could key off just the opaque parameter in fact. However, I just deleted this bit as you suggest since it can be misinterpreted. > > Section 5, page 9: "that results from stripping out the "opaque" URI > parameter" s.b. "that results from stripping out the "opaque" and > "gruu" URI parameters". good catch. > > But that isn't really the statement we want either, since URI > "equivalence" is not affected by a URI parameter present in one URI > and not in the other. See RFC 3261, section 19.1.4. That is, > > sip:carol@chicago.com > sip:carol@chicago.com;opaque="dRfHgbHjGhImBv";gruu > > are equivalent already. But unfortunately so are: > > sip:carol@chicago.com > sip:carol@chicago.com;opaque="dRfHgbHjGhImBv";gruu;hop-sip-and-jump > > and we want to rule out the latter pair. Interesting. What this means is that, based on URI equivalence, a GRUU will in fact equal its AOR. Hmm. Its not obvious to me that this is a bug or a feature. It really depends on what is a reasonable basis for URI equality. One reasonable definition is that two URI should be equivalent only if requests targeted towards them would reach the same user, where 'same' refers to the ability to authenticate with a specific credential. With that definition, the GRUU should be equal to the AOR based on URI equality. Since I don't see any real issue with the AOR and GRUU being equal, I think all we need to do is state that this is the fact. I changed the paragraph we're talking about to read: If the GRUU contains an "opaque" URI parameter, the URI that results from stripping out the "opaque" and "gruu" URI parameters MUST be equivalent to the AOR associated with the GRUU. Indeed, the GRUU itself will also be equivalent to the AOR based on URI comparison, since the "gruu" and "opaque" parameters will be ignored during comparison, being present in one URI (the GRUU) and not the other (the AOR). > > Section 7.1.1.1, page 13: "characteristic [8]. The instance ID MUST > identify the UA that is performing the registration." > s.b. "characteristic [8], whose value MUST be the instance ID that > identifies the UA being registered." This is needed to explicitly > state what the value of the feature tag is, as well as to be correct > for third-party registrations. fixed. > > Section 8.1.1, page 18: "the grammar for the parameter" s.b. "the > grammar for the parameter given in section 10". fixed. > > Section 8.1.1, page 18: "(which is the case for administratively > constructed GRUUs)" s.b. omitted -- as far as I can tell, this isn't > always true. I'd like to give an example of what I'm talking about here. I'll say, "which can be the case for administratively constructed GRUUs, for example) > > Section 8.2.2, page 21: "location service for that user" > s.b. "location service for that AOR", since "user" is not used > elsewhere in that paragraph. ok. > > Section 10, page 23: "The grammar for string-value is obtained from > [8]." s.b. omitted, since "string-value" is not mentioned elsewhere. Good catch. Leftovers for when the instance ID was defined here. > > Section 10, page 23: ""gruu" EQUAL LDQUOT (SIP-URI / SIPS-URI) > RDQUOT" is not what we want, I think. I think the semantics we are > looking for is ""gruu" EQUAL quoted-string, where the value > represented by the quoted-string is a SIP-URI or SIPS-URI". (That > latter could be represented in BNF, but that would make it less > clear.) Thats what the grammar says now. I don't see why its not clear. > > Due to the details of the grammar, the new formulation differs from > the original only in some unusual cases, such as allowing: > > Contact: <...>;gruu="sip:gruu\~123456789@example.com;gruu" > > (The GRUU is .) > > But it seems to me that it is non-orthogonal (and inviting trouble) to > have the grammar for c-p-gruu forbid backslash-escapes of characters > that do not require them, when the grammar for generic-param allows > them. Egads. I disagree here. The SIP URI itself cannot contain a quote, so there is no need to ever use backslash escaping. I think folks might get confused by backslash escaping here. If you just put the unescaped URI in, you'll never have a problem. Why allow escaping? > > Section 12, page 29: Messages 13, 14, 15, and 16 (from figure 2, page > 26) are not shown. This may be intentional, but probably should be > noted explicitly, as the other requests seem to be shown. Its intentional. Not all messages are shown, but most are at least mentioned. I now mention these. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 02:58:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5znn-0000bz-W9; Thu, 27 Jul 2006 02:57:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5znm-0000br-2k; Thu, 27 Jul 2006 02:56:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5xFd-0001BW-6U; Thu, 27 Jul 2006 00:13:33 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5x16-0008PZ-FS; Wed, 26 Jul 2006 23:58:34 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 22:58:23 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 26 Jul 2006 22:58:22 -0500 Received: from AOPEX4.andrew.com ([10.3.20.127]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 22:58:22 -0500 Message-ID: From: "Dawson, Martin" To: "Jeroen van Bemmel" , "Brian Rosen" , "Marc Linsner" , "Peterson, Jon" , "Andrew Newton" , "Rosen, Brian" Date: Wed, 26 Jul 2006 22:58:18 -0500 Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 27 Jul 2006 03:58:22.0473 (UTC) FILETIME=[E75BAF90:01C6B130] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <004601c6b07f$355c3b90$31713b51@BEMBUSTER> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcaxLtjrYHdPp9ekR1aWP5pEZlGE3gAAaZlw X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That's right - and those mechanisms by which the URI remains anonymous and temporary and access rights to the anonymous form of the location are controlled are quite extensive considerations. I understand the conveyance draft just says how to get the location object and/or reference from one signaling peer to another. It's asking to much of this specification to anticipate all the possible mechanisms for applying security to privacy in the by-reference form and thereby restricting the form of the reference to a particular protocol. This should be out of scope for the conveyance protocol. Cheers, Martin > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Wednesday, 26 July 2006 4:46 PM > To: Brian Rosen; 'Marc Linsner'; Peterson, Jon; 'Andrew Newton'; Rosen, > Brian > Cc: sip@ietf.org; geopriv@ietf.org > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- > conveyance >=20 > >I don't really understand why you think location by reference is so much > of > > a concern. >=20 > Because location by reference involves storage of personal information on > a > server. That suddenly makes all sorts of regulations apply, the points I > mentioned address only a small part of that. Having an anonymous URL for > example often makes a difference, because then the information is no > longer > directly linked to a particular person. >=20 > When an endpoint inserts location by value, you can reasonably argue that > opt-in consent requirements (which many countries have) are fulfilled, > provided the endpoint gives the user control over whether or not location > is > inserted. Same holds for the endpoint inserting a flag asking a proxy to > fill in the location (by value). > For location-by-reference this is much more fuzzy. You probably don't need > a > lecture on privacy regulations, but e.g. > http://www.isoc.org/briefings/015/index.shtml (from 2003 but still > applicable IMO) illustrates the mess. >=20 > A while ago I submitted a draft on Temporarily Routable User Agent URIs > (http://www.ietf.org/internet-drafts/draft-jbemmel-sip-truu-02.txt), which > provides anonymous, temporary URIs that can be explicitly invalidated. You > may want to consider something similar for location-by-reference >=20 > Regards, >=20 > Jeroen >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 03:33:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G60LI-00012Y-53; Thu, 27 Jul 2006 03:31:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G60LG-00012Q-8O for sip@ietf.org; Thu, 27 Jul 2006 03:31:34 -0400 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G60LD-0005j2-TA for sip@ietf.org; Thu, 27 Jul 2006 03:31:34 -0400 Received: from Inbox ([84.241.210.173]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J310056HZGQ1M40@jes-fe1.zx.nl> for sip@ietf.org; Thu, 27 Jul 2006 09:26:56 +0100 (WEST) Date: Thu, 27 Jul 2006 09:31:56 +0200 From: Jeroen Van Bemmel To: sip@ietf.org Message-id: <0J310056IZGR1M40@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] The "localhost attack" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Would be interested to know how proxies treat the following request: CANCEL sip:user@example.com Via: {valid data};branch=3D{cookie}random Route: {rest valid data} Same for "localhost", "[::1]" and other IPv6 local addresses, and other req= uests than CANCEL Regards, Jeroen= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 04:07:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G60sC-0002wf-26; Thu, 27 Jul 2006 04:05:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G60sA-0002wQ-Jw for sip@ietf.org; Thu, 27 Jul 2006 04:05:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5zZj-0004ei-Nc for sip@ietf.org; Thu, 27 Jul 2006 02:42:27 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5zSv-0002jJ-44 for sip@ietf.org; Thu, 27 Jul 2006 02:35:28 -0400 Received: (qmail 10934 invoked by uid 0); 27 Jul 2006 06:35:24 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 27 Jul 2006 06:35:24 -0000 Message-ID: <002801c6b146$d4b4e5d0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Vijay K. Gurbani" References: <009001c6b08b$c14e3a70$31713b51@BEMBUSTER> <44C776E7.3040800@lucent.com> Subject: Re: [Sip] Update to fork-loop-fix submitted Date: Thu, 27 Jul 2006 08:35:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: -2.4 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> - Proxy-Require/Proxy-Authorization won't appear in CANCEL or ACK to >> non-2xx (since these are generated hop-by-hop, and also because both >> are not allowed in CANCEL) > > Why would you want to do a loop detection for CANCELs and ACKs > to non-2xx? In the latter case, you can't send a response anyway. > As long as the branch parameter for CANCELs and ACKs to non-2xx > matches a pending INVITE transaction, the state machines can be > updated accordingly. Because CANCEL and ACK can loop like any other request. The concern mostly applies to *stateless* proxies (stateful proxies mostly dont "forward" but "generate" CANCEL and ACK to non-2xx), but it matters also to a stateful proxy that receives a CANCEL with no matching INVITE ST (RFC3261 says "MUST forward statelessly"). For the latter case, I think it might be a good idea to create a servertransaction for the CANCEL, and forward statefully (using the same branch parameter as received) to catch any loops in an easy way For the fork-loop-fix case I guess most concern goes to INVITEs, since they are the only requests that fork and thus cause amplification. But given that also a forking (=>stateful) proxy can receive an ACK to non-2xx or CANCEL with no matching INVITE servertransaction, it should be mentioned. A looping ACK should obviously not be responded to, but it should be dropped. Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 05:11:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G61sO-0006Dz-JW; Thu, 27 Jul 2006 05:09:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G61sM-0006Du-Ul for sip@ietf.org; Thu, 27 Jul 2006 05:09:50 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G61sL-0003Yp-FC for sip@ietf.org; Thu, 27 Jul 2006 05:09:50 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 8101220A0F7; Thu, 27 Jul 2006 08:52:37 +0000 (UTC) Message-Id: <7.0.1.0.0.20060727095302.04cf8bc0@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 27 Jul 2006 10:26:21 +0200 To: Jonathan Rosenberg , Cullen Jennings From: Jiri Kuthan Subject: Re: [Sip] Re: draft-ietf-sip-gruu-09 In-Reply-To: <44C83461.4020806@cisco.com> References: <720BC7A4-8BFF-412E-A6BC-FAC41FA1289B@cisco.com> <44C83461.4020806@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 05:34 27/07/2006, Jonathan Rosenberg wrote: >>Section 6, page 12, 4th para or so ... you are talking about mid- dialog requests. Might be nice to mention how a transaction stateful proxy knows if something is a middialog request or not. > >These days I recommend topmost route URI over tags, since its easy to fool a proxy into thinking something is a mid-dialog request by faking a tag. Its harder to fake a route URI. Faking tags is easy, but is there a way to exploit that? I mean a UAS that received a request with to-tag which matches no dialog just discards it. Faking Routes may not be that difficult either, unless implementors choose to append some cryptographically secured "this-was-me" tags to it. Anyway, I think there can be quite some ways to do the same thing (some folks I am sure will prefer a dialog state silo too), and if we show a way to do this test, it should be properly labeled as an example. [...] >>Section 7.1.1.1 - There has been some problems with the way 3261 >>allowed a user to install forwarding rules using a REGISTER request. >>Part of the problem is that it allows an amplification attack on >>someone else that did not provide any consent. It makes me wonder if >>now that we have the consent framework moving forward, do we really >>want to continue down this path. I realize this is pretty orthogonal >>problem to GRUU. > >Yes, it is. I tend to agree that third party registrations are generally a bad idea these days. I think there are actually three orthogonal things: a) uploading forwarding rules using REGISTER. (which is not IMO 3rd-party registration, as long as identity of the registering party equals that of URI owner). I don't know if this is worth documenting. IMO, this is an aspect to be addressed by registrar's policy. A registrar may for example decide to deny domain names in contacts, it may deny contact addresses that are IP-wise different from transport addresses from which REGISTER came from, etc. It could also accept contacts in REGISTER that includes P-ISwearThisIsNotForwarding: Yes :-)) There are subscribers and consequently provides who consider this a feature. We specify protocols and not policies, don't we. b) 3rd-party registration, which is IMO the case, when the identity of registering party (i.e., username as in digest) is not the same as owner of URI. E.g., if jiri@iptel.org with valid credentials puts jdr@iptel.org in From/To. This is IMO a policy issue too, and thus I think it is appropriate to leave it as is. Already the fact that there is no SIP data model as part of the standard would make possible fixes kind of difficult; i.e., there is actually no clear definition for 3rd party registration without precise notion of URI ownership. c) GRUU. (no particular comments on this other than it is different from a and b) -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 05:28:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G628V-0000qo-TZ; Thu, 27 Jul 2006 05:26:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G628U-0000qh-Bb for sip@ietf.org; Thu, 27 Jul 2006 05:26:30 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G628S-00061s-WD for sip@ietf.org; Thu, 27 Jul 2006 05:26:30 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 01C5520A0A4; Thu, 27 Jul 2006 08:52:37 +0000 (UTC) Message-Id: <7.0.1.0.0.20060727103133.04d0f2d8@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 27 Jul 2006 10:33:45 +0200 To: Jeroen Van Bemmel , sip@ietf.org From: Jiri Kuthan Subject: Re: [Sip] The "localhost attack" In-Reply-To: <0J310056IZGR1M40@jes-fe1.zx.nl> References: <0J310056IZGR1M40@jes-fe1.zx.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That's not a protocol aspect. That's an aspect of server's policy. That's because use of localhost in Route may be perfectly valid in some cases. My suggestion for users of SIP servers is then to ask their favorite vendors about what types of policies they can set to deal with this case, if it is not desired. -jiri At 09:31 27/07/2006, Jeroen Van Bemmel wrote: >Would be interested to know how proxies treat the following request: > >CANCEL sip:user@example.com >Via: {valid data};branch={cookie}random >Route: >{rest valid data} > >Same for "localhost", "[::1]" and other IPv6 local addresses, and other requests than CANCEL > >Regards, > >Jeroen > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 07:06:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G63fu-00066n-P1; Thu, 27 Jul 2006 07:05:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G63ft-00061J-DG for sip@ietf.org; Thu, 27 Jul 2006 07:05:05 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G63fs-0004ye-2G for sip@ietf.org; Thu, 27 Jul 2006 07:05:05 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 477F320A0F5; Thu, 27 Jul 2006 11:05:00 +0000 (UTC) Message-Id: <7.0.1.0.0.20060727125123.0501f930@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 27 Jul 2006 12:57:33 +0200 To: jh@tutpro.com (Juha Heinanen), Jonathan Rosenberg From: Jiri Kuthan Subject: Re: [Sip] Re: draft-ietf-sip-gruu-09 In-Reply-To: <17608.24030.174463.937832@harjus.tutpro.com> References: <720BC7A4-8BFF-412E-A6BC-FAC41FA1289B@cisco.com> <44C83461.4020806@cisco.com> <17608.24030.174463.937832@harjus.tutpro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Cullen Jennings , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 08:31 27/07/2006, Juha Heinanen wrote: >Jonathan Rosenberg writes: > > > If the > > topmost URI matches one that the proxy placed into the Record-Route > > header field of a dialog-forming request, then the request is a > > mid-dialog request. > >jonathan, > >how can proxy tell apart a pre-loaded Route header from proxy placed? I would say there are far too many ways to do it. One of those is the proxy puts in the Record-Route header-fields its signature "I put it here". This can have many various forms, up to proxy vendor or configurator to choose one. We typically configure what we call "avp-cookies" in Record-route header field to capture some fragments of dialog state. If such a piece of information appears later in Route, we know it is our "own" route. If not, it is not (or there is a crappy UA which strips some parts of the HF :-)) This is more robust than looking at hostname/IP, because that may be too amibguous (it is hard to differentiate between preloaded/record-routed, if IP address is used in multidomain environments it is difficult to assigne the request to a domain, etc.) Sometimes for similar cases, you don't actually the signature to be an IP address -- you may have a server farm, and all you want to know is whether any of farm members did record-route or not. The record-routing information may include various things to provide better value: name of initially "dialed" domain, cryptographic checksum to avoid forged record-routing information, and once that begins to bee all too much, just index referring to database full of call state. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 08:34:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G652w-0003mw-50; Thu, 27 Jul 2006 08:32:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G652u-0003mo-F3; Thu, 27 Jul 2006 08:32:56 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G652t-0002H0-8N; Thu, 27 Jul 2006 08:32:56 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 27 Jul 2006 08:33:04 -0400 id 01588194.44C8B280.00003639 In-Reply-To: <4.3.2.7.2.20060726230723.03693008@email.cisco.com> References: <4.3.2.7.2.20060726222133.03bb4518@email.cisco.com> <4.3.2.7.2.20060726222133.03bb4518@email.cisco.com> <4.3.2.7.2.20060726230723.03693008@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <50D29DA3-55B4-467A-A24C-AB6C78DCBA5A@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Thu, 27 Jul 2006 08:32:54 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org, geopriv@ietf.org, "Abbott, Nadine B" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 27, 2006, at 12:08 AM, James M. Polk wrote: > At 11:37 PM 7/26/2006 -0400, Andrew Newton wrote: > >> On Jul 26, 2006, at 11:27 PM, James M. Polk wrote: >> >>> I think Geopriv really needs to look at HTTP as a RFC 3693 "using >>> protocol" to tease out any unique characteristics with that >>> protocol. That discussion and review shouldn't bog this document >>> down. Does this sound fair? >> >> Most definitely. We've had discussions on HTTP as a using protocol >> for 3 years in GEOPRIV, HELD being the latest incarnation. The first >> proposals ran into serious privacy concerns. Anything that simply >> says "use HTTP" is an attempt to work around answering the serious >> privacy concerns raised in GEOPRIV. > > is this said with your WG chair hat on? > > It sounds pretty definitive to these ears... I don't believe working group chairs are given any special powers that such a decision is in their hands. Any individual participant can approach an AD or the IESG either informally or via appeal about attempts to work around working group consensus. Such things are taken seriously by the IESG, to the point that they can stop the publication of an RFC sent directly to the RFC Editor on this basis. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 08:38:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G656N-0007vK-52; Thu, 27 Jul 2006 08:36:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G656L-0007ug-7u; Thu, 27 Jul 2006 08:36:29 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G656J-0002cY-VQ; Thu, 27 Jul 2006 08:36:29 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 27 Jul 2006 08:36:37 -0400 id 01588194.44C8B355.00003703 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9F1514D3-275E-4C4F-82C8-57DEF3860AC9@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: Teasing apart positions (was Re: [Sip] RE: [Geopriv] Consensus onchanges to location-conveyance) Date: Thu, 27 Jul 2006 08:36:27 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Martin, you did not answer my question. You are right that HTTP as a using protocol is a separate question, one which I will ask about. -andy On Jul 27, 2006, at 1:00 AM, Thomson, Martin wrote: > Since I raised the question, I'll answer. > > We have a set of requirements on a using protocol in RFC 3693. > > I believe that HTTP with proper constraints (TLS, etc...) can meet, > or already meets, those requirements. That is irrespective of any > decisions that need to be made about secondary concerns like > whether HTTP is desirable, optimal, deployable etc... However, it > is clear that people aren't happy with this position and are > requesting that this be documented, as an RFC. Just to get it all > out in the open. Presumably this would be a standards track RFC > that, like location-conveyance, highlights how the RFC 3693 > requirements are addressed. > > That's a sound argument, and obviously location-conveyance had to > meet that standard for us to be happy. Now, I ask that you go > back, take the above paragraph and perform one simple operation and > read it again: s/HTTP/SIP/g. Is the argument any different in the > presence of RFC 4079? Is an informational RFC that doesn't address > specific requirements adequate? I'd suggest that it wouldn't make > the grade for HTTP. > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Thursday, 27 July 2006 1:55 PM >> To: IETF SIP List; GEOPRIV >> Subject: Teasing apart positions (was Re: [Sip] RE: [Geopriv] >> Consensus >> onchanges to location-conveyance) >> >> >> On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote: >>> The authors would like to know what to do now. >> >> Let's start by trying to tease apart certain positions. >> >> Given Jon Peterson's message: >> http://www1.ietf.org/mail-archive/web/sip/current/msg15537.html >> >> Does anybody still believe that subscriptions to PIDF-LOs with pres: >> requires more definition? >> >> -andy >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 08:46:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65ED-0003ZV-5t; Thu, 27 Jul 2006 08:44:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65EA-0003ZK-U6; Thu, 27 Jul 2006 08:44:34 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G65E9-0003Tj-Np; Thu, 27 Jul 2006 08:44:34 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 27 Jul 2006 08:44:43 -0400 id 01588194.44C8B53B.00003869 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <37E9EDFD-EA9E-40A3-8885-996A8558958D@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List , GEOPRIV From: Andrew Newton Date: Thu, 27 Jul 2006 08:44:33 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Sip] teasing apart: http as a GEOPRIV using protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There have been a number of opinions regarding HTTP as a using protocol. I'd like to know, how many people believe that HTTP requires no or very little specification to meet the requirements in RFC 3693 and RFC 3694. If you believe this, what basis do you have for this conclusion? Or do you believe more specification needs to be done, but it is possible for HTTP to be a GEOPRIV using protocol? Finally, how many people believe that HTTP should not be a using protocol? -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 08:46:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65EZ-00041j-RT; Thu, 27 Jul 2006 08:44:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65EX-0003w5-Mq; Thu, 27 Jul 2006 08:44:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G65EX-0003VR-K2; Thu, 27 Jul 2006 08:44:57 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G658Y-0002DY-Jv; Thu, 27 Jul 2006 08:38:50 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 27 Jul 2006 05:38:46 -0700 X-IronPort-AV: i="4.07,187,1151910000"; d="scan'208"; a="1842354987:sNHT63674032" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RCcjZr027502; Thu, 27 Jul 2006 05:38:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6RCcj79010696; Thu, 27 Jul 2006 05:38:45 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jul 2006 05:38:45 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 05:38:44 -0700 From: "Marc Linsner" To: "'Henning Schulzrinne'" , "'Brian Rosen'" Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Thu, 27 Jul 2006 08:38:39 -0400 Message-ID: <005a01c6b179$96dd1bf0$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaxMUZxDEnh1z9yR6GGv4wJPfRYrgAR/dAQ In-Reply-To: <26AE42F5-3170-434B-8E4F-4D7F22FA2E7C@cs.columbia.edu> X-OriginalArrivalTime: 27 Jul 2006 12:38:44.0816 (UTC) FILETIME=[99532500:01C6B179] DKIM-Signature: a=rsa-sha1; q=dns; l=4784; t=1154003925; x=1154867925; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20[Sip]=20RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=20loca tion-conveyance; X=v=3Dcisco.com=3B=20h=3DuQx2+C6hzLub85HC/MIjXZBl+x0=3D; b=OnqoAmCMYfXpbeLFPKtcotIDIBSuzNULwHdXfHJoi42N5awjGyTJNaqqvqV45Ei+tj5Jhb+R B920+vQKFM2Il7YMVpqR3DFdFQ1WZ9PiZ5Rg+EsTn4aIkgY4RBb4ktKE; Authentication-Results: sj-dkim-7.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: 'IETF SIP List' , geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Works for me... -Marc- > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, July 26, 2006 11:25 PM > To: Brian Rosen > Cc: IETF SIP List; geopriv@ietf.org > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to > location-conveyance > > My suggestion would be > > - to focus the draft on just defining the Location header > syntax, without ruling out any particular mechanism or > scheme; this would make the draft really short (which I would > find helpful). > > - and then add one section to the draft that prototypically > defines what a particular scheme that wants to appear in the > Location header needs to define, using the non-controversial > cid mechanism as the example. Other, separate, drafts can > then define other modes, following the same template. > Documents such as the phone-bcp can then pick some suitable > must-implement subset and make emergency-call- specific > recommendations, rather than sprinkling these throughout the > conveyance document and repeating some in the phone-bcp. Most > of these are, in any event, operational recommendations, not > for ensuring protocol-level interoperability. > > That way, the conveyance draft can be extremely short (even > shorter if the requirements are omitted...) and can get done, > and we avoid engineering operational requirements on the fly, > commingling emergency and non-emergency cases, as seems to be > happening now. > > I think protocol documents should define what's needed for > interoperability; BCPs can make more specific, > situation-specific recommendations. Commingling the two seems > to be a recipe for deadlock or arbitrary, > non-technically-grounded decisions that are more lawyer-like > than engineering-like ("you did not mention technique X in > some meeting N years ago and thus you can't bring it up now!") > > Henning > > On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote: > > > At this point, I think we need some chair guidance and by > that I think > > it's a combo of geopriv and sip chairs. > > > > We seem to have a couple of significant open questions. I > think most > > of the other stuff (like the "allow sending to router") > will converge. > > > > There seems to be some opposition to allowing sip/sips/pres: in a > > Location Header. The opposition seems to be that despite 4119, > > somehow, SIP (presence subscription) is not a "using protocol". I > > "think" a ruling from the bench on that would work. > > > > There is also opposition to defining the allowed schemes as > a specific > > list, with a defined (easy) extension mechanism. > > > > Related to that, there are some who want > location-conveyance to define > > an HTTP based location dereference mechanism, and on the > opposite end, > > we have people saying we haven't even agreed to support any form of > > location-by-reference. > > > > The authors would like to know what to do now. > > > > Brian > > > >> -----Original Message----- > >> From: Andrew Newton [mailto:andy@hxr.us] > >> Sent: Wednesday, July 26, 2006 9:58 PM > >> To: Winterbottom, James > >> Cc: sip@ietf.org; geopriv@ietf.org; Abbott, Nadine B; Henning > >> Schulzrinne > >> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- > >> conveyance > >> > >> > >> On Jul 26, 2006, at 9:43 PM, Winterbottom, James wrote: > >> > >>> Andy, > >>> > >>> RFC-4119 says "However, the usage of this location object > format is > >>> not > >>> limited to presence-using protocols-- any protocol > that can carry > >>> XML > >>> or MIME types can carry PIDF." > >>> > >>> It seems to me that restricting the allowed schema in what is > >>> supposed to be a location conveyance specification is in > opposition > >>> to this statement. > >> > >> Did somebody say that HTTP was a presence-using protocol? > >> > >> -andy > >> > >> ps. you can find my location with the following reference URIs: > >> > >> gopher://fatchance.hxr.us/you-still-have-a-gopher-client > >> news:alt.locations.people.secretly-being-watched > >> telnet://screen-scrapers.are.us/ > >> dns:cached-publicly-around-the-world.com?type=HOST > >> > >> > >> > >> _______________________________________________ > >> Geopriv mailing list > >> Geopriv@ietf.org > >> https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 09:15:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65gR-0008TC-5l; Thu, 27 Jul 2006 09:13:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65gQ-0008Ss-4B; Thu, 27 Jul 2006 09:13:46 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G65gO-0006Mn-JM; Thu, 27 Jul 2006 09:13:46 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k6RDDhKg018581; Thu, 27 Jul 2006 08:13:43 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 08:13:42 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 15:13:41 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 27 Jul 2006 15:13:40 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180194F04@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcawERldoiEvROTuT2KasGKrfOW37QAzWneQAAHSzSAABUfloAAD4wbgABzUo3A= From: "Drage, Keith \(Keith\)" To: "Winterbottom, James" , "Abbott, Nadine B" , "Brian Rosen" , X-OriginalArrivalTime: 27 Jul 2006 13:13:41.0000 (UTC) FILETIME=[7ABF7080:01C6B17E] X-Spam-Score: 0.5 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (as individual) I am not sure I understand your argument here. As far as I understand, and in addition to any other constraints, any protocol used as a result of the reference to carrt location must be a location using protocol in and pass the IETF (as policed by GEOPRIV) privacy provisions on location. In the absence of any other normative document by GEOPRIV that normatively lists those protocols, the dereferencing protocol specification (currently specified in sip-location-conveyance) must normatively indicate that list. Whether it does it by ABNF or text is academic - they are both normative specifications, and they both need an RFC to update them.=20 I believe we do have a requirement that the dereferencing protocol entity MUST NOT use a protocol that is not a location using protocol. Regards Keith > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 > Sent: 27 July 2006 00:31 > To: Abbott, Nadine B; Brian Rosen; sip@ietf.org > Cc: geopriv@ietf.org > Subject: RE: [Geopriv] Consensus on changes to location-conveyance >=20 > Brian, >=20 > I don't care if you don't mention how to de-reference URI=20 > types other than sip/sips/cid/pres in the document or not.=20 > But I do not want the schema artificially constrained to=20 > exclude URI types such as HTTP. There is clearly not=20 > consensus to justify this exclusion, so please leave schema=20 > unchanged and make your recommendations in the text. >=20 > Cheers > James >=20 > =20 >=20 > -----Original Message----- > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > Sent: Thursday, 27 July 2006 7:44 AM > To: Brian Rosen; sip@ietf.org > Cc: geopriv@ietf.org > Subject: RE: [Geopriv] Consensus on changes to location-conveyance >=20 > Brian, >=20 > Actually, I was thinking that in other industry work which is=20 > trying to leverage and provide transitional strategies to=20 > migrate to using SIP to support emergency services, the and=20 > long-term solutions that we have defined assume a capabity to=20 > provide location-by-reference. I think it would be very=20 > useful to have this defined in a standard SIP header=20 > mechanism in such a way that we need not redefine migratory=20 > solutions that have begun to be implemented. If an HTTPS URI=20 > can be used as the location-by-reference, this will be=20 > helpful, I think. =20 >=20 > I don't understand your urgency to make location-by-reference=20 > only an all-sip-all-the-time thing. > And from all the other emails on this topic, it didn't seem=20 > to me that there is a consensus to do this. >=20 > Nadine=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, July 26, 2006 3:15 PM > To: Abbott, Nadine B; sip@ietf.org > Cc: geopriv@ietf.org > Subject: RE: [Geopriv] Consensus on changes to location-conveyance >=20 > Nadine >=20 > Are you saying that it's your opinion sip-location-conveyance=20 > MUST define an HTTP dereference procedure? >=20 > If you do, why? What is the use-case or requirement? >=20 > Would it not be pretty reasonable to require a separate=20 > document that defines a location-by-reference mechanism,=20 > protocol, and geopriv "using protocol" analysis? If that=20 > document specifically extended what was allowed in the=20 > location header, would that not be reasonable? >=20 > I think we have to include "A" dereference mechanism in the=20 > location-conveyance document. It seems just including=20 > sip/sips/prez is a reasonable, all-sip-all-the-time approach=20 > IN THIS DOCUMENT. That certainly does not preclude another=20 > document describing another way. >=20 > Doesn't it seem just a little weird to have a=20 > sip-location-conveyance document describing any kind of http=20 > based location conveyance > (de-reference) protocol, especially one created whole cloth=20 > without any other parts? >=20 > Doesn't it seem in keeping with the geopriv approach that in=20 > order to have another "using protocol" it has to have a=20 > geopriv review? That is what leads to restricting the URI=20 > schemes. Would you prefer to let it be wide open, so any=20 > protocol anyone thinks about can be used with the location=20 > header? I can't see geopriv going along with that. We're=20 > going to make it a one line ABNF to add a new scheme to the=20 > list of allowed schemes. >=20 > It seems to me that if it's desired to define some bare-bones=20 > HTTP location by reference protocol, then that should be a=20 > separate document, which can easily extend the allowable=20 > schemes in the Location header. > I'm not sure it might be better to define ALL of that in the=20 > L7 protocol, but I wouldn't be opposed to a simple "raw GET"=20 > RFC as long as it got a full geopriv review. > I just don't see where it makes any sense to force that into=20 > a sip document. >=20 > Brian >=20 > > -----Original Message----- > > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > > Sent: Wednesday, July 26, 2006 2:14 PM > > To: sip@ietf.org > > Cc: geopriv@ietf.org > > Subject: RE: [Geopriv] Consensus on changes to location-conveyance > >=20 > >=20 > > I don't agree that there is a consensus to preclude the use of HTTP. > > I would favor not placing your proposed restriction on the=20 > URI scheme=20 > > for expressing a location reference in the SIP location conveyance=20 > > draft; or at least including HTTP as a valid location-reference URI=20 > > type. > >=20 > > Regards, > > Nadine Abbott > >=20 > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Tuesday, July 25, 2006 1:38 PM > > To: sip@ietf.org > > Cc: geopriv@ietf.org > > Subject: [Geopriv] Consensus on changes to location-conveyance > >=20 > > I have put out a number of emails on proposed changes to location=20 > > conveyance. Some of them have sparked a number of comments. My=20 > > summary of consensus on these issues is: > >=20 > > 1. We proposed to explicitly disallow use of a Data URI,=20 > which would=20 > > allow specification of a Location-by-value in a header. =20 > There was a=20 > > lot of list traffic on this, currently in the state where=20 > Keith asked=20 > > for a real use case for it. So far, we don't see a use case that=20 > > cannot be provided by location-by-reference in a header. =20 > If we don't=20 > > get a good use case, I think consensus is to disallow=20 > > location-by-value in a header. > >=20 > > 2. Dereferencing location-by-reference. We had initially=20 > proposed to=20 > > document a process to use a raw HTTP(S) Get to dereference.=20 > There was >=20 > > a lot of discussion, and then I made a new proposal, see item 6. > >=20 > > 3. We proposed to allow a Reason header with a 424 Bad Location=20 > > response. This seems to be acceptable to the WG. Geopriv=20 > will create >=20 > > and populate the registry in a separate draft. > >=20 > > 4. We proposed to explicitly allow hop-by-hop TLS security for=20 > > location when the endpoint wished to allow routing based on=20 > location. >=20 > > We further proposed to interpret "Do not Distribute" flags=20 > as allowing >=20 > > sending of the location to the routing database (LoST for=20 > example). =20 > > Hannes pointed out that there was a proposal to allow two Location=20 > > headers, one of which could be used for routing and another=20 > for onward >=20 > > forwarding to the recipient. Hannes' message seemed to=20 > agree that "Do > not distribute" > > would allow sending of the location to the routing-by-location=20 > > database, but would obligate the proxy that did that to remove the=20 > > location before it forwarded the message. There were no other > messages on this thread. > > We conclude that allowing hop-by-hop security for location based=20 > > routing is acceptable, and Do Not Distribute DOES allow=20 > forwarding to=20 > > a routing database, but requires that the proxy doing the location=20 > > based route to remove the location it uses for that purpose. > >=20 > > 5. We proposed to create a parameter and a registry to distinguish=20 > > multiple ways to dereference a location where HTTP(S) was the > transport. > > Resolution of this issue depends on resolution of issue 6. > >=20 > > 6. We proposed to allow sip/sips and pres: in the location=20 > header. I=20 > > later speculated that if we allow this, it forms a simple way to do=20 > > location-by-reference, and we could eliminate the raw HTTP(S) Get=20 > > proposal, with the parameter and registry entirely. There was some=20 > > list traffic in favor of this. Martin Thompson is=20 > skeptical that SIP=20 > > Presence Subscribe/Notify is actually allowed as a geopriv "using=20 > > protocol". Several of think that it is. If we don't get any more=20 > > comments on this proposal, we will allow sip/sips and pres,=20 > not have=20 > > any > > http(s) resolution text, and not propose a parameter and=20 > accompanying=20 > > registry. > >=20 > > If this does not reflect your position, please speak up now. > >=20 > > Brian > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 09:16:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65h6-0000GL-9n; Thu, 27 Jul 2006 09:14:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65h4-0000GG-Um for sip@ietf.org; Thu, 27 Jul 2006 09:14:26 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G65h2-0006R1-Kl for sip@ietf.org; Thu, 27 Jul 2006 09:14:26 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2006 06:14:24 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,187,1151910000"; d="scan'208"; a="33571164:sNHT23032792" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RDEOYP031093 for ; Thu, 27 Jul 2006 09:14:24 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6RDENdU020217 for ; Thu, 27 Jul 2006 09:14:23 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 09:14:23 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 09:14:23 -0400 Message-ID: <44C8BC2F.1000406@cisco.com> Date: Thu, 27 Jul 2006 09:14:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Re: draft-ietf-sip-gruu-09 References: <720BC7A4-8BFF-412E-A6BC-FAC41FA1289B@cisco.com> <44C83461.4020806@cisco.com> In-Reply-To: <44C83461.4020806@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 13:14:23.0569 (UTC) FILETIME=[941EF410:01C6B17E] DKIM-Signature: a=rsa-sha1; q=dns; l=1659; t=1154006064; x=1154870064; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Re=3A=20draft-ietf-sip-gruu-09 |To:Jonathan=20Rosenberg=20; X=v=3Dcisco.com=3B=20h=3DDdl47GubvF6uOC1GO+DkIQwpfTE=3D; b=pMr1Y5LuCGi2+OQdiTfHXYlp6eq5o7FnkKYiIn7bPIvvu6lH1XIBoiID4UgWGwvAXRsZXpaV PzkhIDbzEslXBUQo5n/z4sCP00fxWJ3tSibmBhihWzm4v0jpejZpbKOi; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Cullen Jennings , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > Cullen Jennings wrote: >> Section 6, page 12, 4th para or so ... you are talking about mid- >> dialog requests. Might be nice to mention how a transaction stateful >> proxy knows if something is a middialog request or not. > > These days I recommend topmost route URI over tags, since its easy to > fool a proxy into thinking something is a mid-dialog request by faking a > tag. Its harder to fake a route URI. > > Text now reads: > > Mid-dialog requests will also be sent to GRUUs, as they are > included as the remote-target in dialog-forming and target refresh > requests and responses. However, in those cases, a proxy SHOULD only > apply services that are meaningful for mid-dialog requests, generally > speaking. This excludes screening functions, as well as forwarding > ones. A proxy can determine that a request is a mid-dialog request > based on the Route header field in the request it receives. If the > topmost URI matches one that the proxy placed into the Record-Route > header field of a dialog-forming request, then the request is a > mid-dialog request. Is it really harder to fake? Suppose Alice is permitted to call Bob, but not to subscribe to the reg event package. So Alice first calls Bob, and notes the Record-Route that results. Then in a separate dialog, Alice sends a SUBSCRIBE to the reg event package, including a Route header with a URI of Bob's home proxy extracted from the old R-R. Seems like this strategy also requires some protection against a "replay attack" like this. But that isn't really an issue for this draft. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 09:26:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65qh-0006K2-AY; Thu, 27 Jul 2006 09:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65qg-0006Jx-7o for sip@ietf.org; Thu, 27 Jul 2006 09:24:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G65qe-0007MO-TU for sip@ietf.org; Thu, 27 Jul 2006 09:24:22 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2006 06:24:20 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,187,1151910000"; d="scan'208"; a="33572570:sNHT23178568" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RDOKAh001495; Thu, 27 Jul 2006 09:24:20 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6RDNOdw022847; Thu, 27 Jul 2006 09:24:19 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 09:24:17 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 09:24:17 -0400 Message-ID: <44C8BE81.6090207@cisco.com> Date: Thu, 27 Jul 2006 09:24:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] draft-ietf-sip-gruu-09 References: <200606262132.k5QLWVZQ023989@dragon.ariadne.com> <44C841FB.7010601@cisco.com> In-Reply-To: <44C841FB.7010601@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 13:24:17.0557 (UTC) FILETIME=[F62A5450:01C6B17F] DKIM-Signature: a=rsa-sha1; q=dns; l=1338; t=1154006660; x=1154870660; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-gruu-09 |To:Jonathan=20Rosenberg=20; X=v=3Dcisco.com=3B=20h=3D82hxRVmdQQoeFaFU+rgtE6JdLIo=3D; b=m+kZW7pK1hqb8NBULoQC0hd1pttoE37bVxQm5LJIg+EoQx5E2ddDCxQUQ3BW52gcNw75brq2 PLNlco47kdGN271V1hljQDvi5IbfEjqC9Z8Pgf16Kj6Dzwmn7R8OLGCS; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > Dale.Worley@comcast.net wrote: >> There seems to be disagreement as to what the plural of GRUU is -- >> GRUU or GRUUs. E.g., section 13, page 31 uses both "Furthermore, >> GRUUs do not address" and "These GRUU will be passed". There is a >> similar inconsistency regarding the plural of AOR. > > Well, this topic has come up for the term URI, which is the last U in > GRUU. So it would stand to reason that if the plural of URI is URIs, > then the plural of GRUU is GRUUs. I found some email threads on this > topic, for example: > > http://lists.w3.org/Archives/Public/www-tag/2002Aug/0124.html > > and apparently this was an open issue in the preparation of the revision > to 2396: > > http://www.gbiv.com/protocols/uri/rev-2002/issues.html#023-URI-plural > > the conclusion appears to be that the plural of URI is URIs. So, I > suggest we follow suit and have the plural of GRUU be GRUUs. Hey, that's not fair! I was looking for a precedent when cleaning up draft-ietf-sipping-gruu-reg-event-06, and noticed there was inconsistency in draft-ietf-sip-gruu. We discussed this, and I thought we decided that the plural is GRUU. I made my draft consistent with that. If you decide this way then I should respin draft-ietf-sipping-gruu-reg-event. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 09:29:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65tv-0000PA-Qx; Thu, 27 Jul 2006 09:27:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65tu-0000K1-NV; Thu, 27 Jul 2006 09:27:42 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G65ts-00085y-EU; Thu, 27 Jul 2006 09:27:42 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G65to-0007LM-2G; Thu, 27 Jul 2006 08:27:36 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'IETF SIP List'" , "'GEOPRIV'" Subject: RE: [Sip] teasing apart: http as a GEOPRIV using protocol Date: Thu, 27 Jul 2006 09:27:35 -0400 Message-ID: <04d501c6b180$6e39f4a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acaxeqpsb7EE6nNlS12MU3t7qnUQEgABWzuw In-Reply-To: <37E9EDFD-EA9E-40A3-8885-996A8558958D@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think HTTP requires some specification. A raw GET based retrieval of a PIDF would be a fairly short RFC, but I think we need that RFC. While I don't think it's necessary (SIP SUBSCRIBE is sufficient), I don't object to defining HTTP as a using protocol in a suitable RFC. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, July 27, 2006 8:45 AM > To: IETF SIP List; GEOPRIV > Subject: [Sip] teasing apart: http as a GEOPRIV using protocol > > There have been a number of opinions regarding HTTP as a using protocol. > > I'd like to know, how many people believe that HTTP requires no or > very little specification to meet the requirements in RFC 3693 and > RFC 3694. If you believe this, what basis do you have for this > conclusion? Or do you believe more specification needs to be done, > but it is possible for HTTP to be a GEOPRIV using protocol? > > Finally, how many people believe that HTTP should not be a using > protocol? > > -andy > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 09:35:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6602-0005YY-HS; Thu, 27 Jul 2006 09:34:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6600-0005YD-Ad; Thu, 27 Jul 2006 09:34:00 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G65zz-0000YF-0n; Thu, 27 Jul 2006 09:34:00 -0400 Received: from [192.168.0.41] (pool-141-153-188-67.mad.east.verizon.net [141.153.188.67]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6RDXtMp029215 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 27 Jul 2006 09:33:56 -0400 (EDT) In-Reply-To: <04d501c6b180$6e39f4a0$640fa8c0@cis.neustar.com> References: <04d501c6b180$6e39f4a0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A8FBA4E-DD34-4C89-80B6-BE2913101258@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] teasing apart: http as a GEOPRIV using protocol Date: Thu, 27 Jul 2006 09:33:48 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.27.60932 X-PerlMx-Spam: Gauge=XXII, Probability=22%, Report='RELAY_IN_NJABL_DYNABLOCK 2.5, RCVD_IN_NJABL_ORG 0, RELAY_IN_NJABL_ORG 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RELAY_IN_NJABL_DYNABLOCK 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org For all protocols, the hardest part is specifying how authentication works in conjunction with the privacy rules. This is far from obvious for HTTP, for example. (Is it the Digest user identifier? Can Basic over TLS be used instead? What about crypto-random request URIs? Is HTTP ok in that case or is HTTPS needed - the answer isn't obvious since an observer would only see a location, not a location-identity pair.) For SIP, this is largely done, except for the crypto-random request URI case and variations, such as user + password. On Jul 27, 2006, at 9:27 AM, Brian Rosen wrote: > I think HTTP requires some specification. A raw GET based > retrieval of a > PIDF would be a fairly short RFC, but I think we need that RFC. > > While I don't think it's necessary (SIP SUBSCRIBE is sufficient), I > don't > object to defining HTTP as a using protocol in a suitable RFC. > > Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 10:24:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66l8-0004pM-T7; Thu, 27 Jul 2006 10:22:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66l7-0004p2-FJ; Thu, 27 Jul 2006 10:22:41 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G66l6-0008Qc-VL; Thu, 27 Jul 2006 10:22:41 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k6REMZCj017826; Thu, 27 Jul 2006 09:22:35 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 09:22:35 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 16:22:33 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Thu, 27 Jul 2006 16:22:32 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180194F8C@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcaxICHAtAENJESpR8Gsjx7TZM9AsgACIPEAABaR/2A= From: "Drage, Keith \(Keith\)" To: "Brian Rosen" X-OriginalArrivalTime: 27 Jul 2006 14:22:33.0797 (UTC) FILETIME=[1A163750:01C6B188] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: sip@ietf.org, geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (as SIP WG chair) (Warning - degree of rant is directly proportional to the value of the item number, I decided that 6 through 10 were not publishable) 1) I think we do have a significant amount of discussion and agreement already that does need to be reflected in a revised draft. You promised that revised draft in early August, and whatever the state of the open issues, you should still provide that revised draft, and merely indicate in the text that open issues exist in particular areas if they do not get resolved before you hit the send button. We are certainly getting repeats of comments that relate to stuff that will already be addressed in the revised version. 2) This document is making SIP a "using protocol" for location. Any normative requirements in this document must be consistent with GEOPRIV documentation in RFC 3693, RFC 3694, RFC 4079 and RFC 4119. Therefore if comments are being made that are inconsistent with any of these documents, then the commentors should in the first instance be addressing their comments to GEOPRIV in terms of corrections to these RFCs. I don't want a SIP document held hostage because someone either refused to read a GEOPRIV document before it was approved, or at the very least failed to understand what was written at that time. If it is a question of interpretation of the GEOPRIV documents, then I guess there is room for some discussion, but at least Jon Peterson, who played a key role in this work in GEOPRIV, has indicated that the presence work is a GEOPRIV using protocol. On that basis, I would allow him to hum directly into the microphone if a hum was in progress on this one. 3) Using protocols are sanctioned by GEOPRIV. If GEOPRIV has not made a decision, then it does not exist as a using protocol! 4) We are past the design stage on this document. The document has had its current technical content for 12 months. In my view that raises the bar somewhat. If something new is required in this document, then we are not in the process of just adding it as yet another variant - if only because that hits interoperability. I want to see clear statements about why the current stuff does not work, and what is improved by the new addition. In many cases, I am failing to see reasoned arguments based on the GEOPRIV documents, or other IETF work, as to why something is right or wrong - I do not want to see proposals based on general feelings, or, "that is what I want to implement therefore it has got to be included".=20 5) We still have to make decisions by concensus. We need consensus to take something out, we need consensus to put something in. While the editors do need to represent that consensus, they are also entitled to their views on the discussion as individuals. At the end of the day, if we fail to reach consensus about the document, then we kill either the charter item, or the SIP WG itself. Regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 27 July 2006 04:08 > To: 'Andrew Newton'; 'Winterbottom, James' > Cc: sip@ietf.org; geopriv@ietf.org; 'Henning Schulzrinne';=20 > 'Abbott, Nadine B' > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to=20 > location-conveyance >=20 > At this point, I think we need some chair guidance and by=20 > that I think it's a combo of geopriv and sip chairs. >=20 > We seem to have a couple of significant open questions. I=20 > think most of the other stuff (like the "allow sending to=20 > router") will converge. >=20 > There seems to be some opposition to allowing sip/sips/pres:=20 > in a Location Header. The opposition seems to be that=20 > despite 4119, somehow, SIP (presence subscription) is not a=20 > "using protocol". I "think" a ruling from the bench on that=20 > would work. >=20 > There is also opposition to defining the allowed schemes as a=20 > specific list, with a defined (easy) extension mechanism. =20 >=20 > Related to that, there are some who want location-conveyance=20 > to define an HTTP based location dereference mechanism, and=20 > on the opposite end, we have people saying we haven't even=20 > agreed to support any form of location-by-reference. =20 >=20 > The authors would like to know what to do now. >=20 > Brian >=20 > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Wednesday, July 26, 2006 9:58 PM > > To: Winterbottom, James > > Cc: sip@ietf.org; geopriv@ietf.org; Abbott, Nadine B; Henning=20 > > Schulzrinne > > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-=20 > > conveyance > >=20 > >=20 > > On Jul 26, 2006, at 9:43 PM, Winterbottom, James wrote: > >=20 > > > Andy, > > > > > > RFC-4119 says "However, the usage of this location object=20 > format is=20 > > > not > > > limited to presence-using protocols-- any protocol=20 > that can carry=20 > > > XML > > > or MIME types can carry PIDF." > > > > > > It seems to me that restricting the allowed schema in what is=20 > > > supposed to be a location conveyance specification is in=20 > opposition=20 > > > to this statement. > >=20 > > Did somebody say that HTTP was a presence-using protocol? > >=20 > > -andy > >=20 > > ps. you can find my location with the following reference URIs: > >=20 > > gopher://fatchance.hxr.us/you-still-have-a-gopher-client > > news:alt.locations.people.secretly-being-watched > > telnet://screen-scrapers.are.us/ > > dns:cached-publicly-around-the-world.com?type=3DHOST > >=20 > >=20 > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 10:27:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66oR-0005vB-Sp; Thu, 27 Jul 2006 10:26:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66oQ-0005v3-64; Thu, 27 Jul 2006 10:26:06 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G66oO-0000Al-Ux; Thu, 27 Jul 2006 10:26:06 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 27 Jul 2006 10:26:14 -0400 id 01588194.44C8CD06.00004B8D Message-ID: <44C8CCF3.2030506@hxr.us> Date: Thu, 27 Jul 2006 10:25:55 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: IETF SIP List , GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Sip] Teasing apart: constraints on dereference URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There have been many conversations regarding constraining the URI in the Location header. There have been many positions taken on this subject, and this email is intended to understand the various opinions. Is there anybody who believes that the type of URI in the Location header should not be constrained in any way? In other words, any URI scheme may be valid and there should be no attempt to specify the URI scheme or associated protocol for dereferencing location. And if so, do you believe location will only be dereferenced via a user clicking on a link or by automatic software action? If the latter, how do you see software adapting to multiple URI schemes and their associated protocols? Is there anybody who believes that the dereference URI should be restricted to a specific set of schemes, enforced via ABNF, XML Schema, or other grammar specification and re-enforced with MUST/SHOULD language? The intent here being that the set would be definitive or at the very least require major effort to update. Finally, how many people desire a middle ground? Perhaps where the ABNF, XML Schema or other grammar specification allows for any URI scheme but there is an IANA registry listing the allowed dereference URI schemes and associated protocols? -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 10:35:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66vY-00048I-Rj; Thu, 27 Jul 2006 10:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66vX-000488-Ln for sip@ietf.org; Thu, 27 Jul 2006 10:33:27 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G66vW-0000kR-7N for sip@ietf.org; Thu, 27 Jul 2006 10:33:27 -0400 Received: (qmail invoked by alias); 27 Jul 2006 14:33:22 -0000 Received: from ip-80-226-252-80.vodafone-net.de (EHLO [10.226.214.60]) [80.226.252.80] by mail.gmx.net (mp042) with SMTP; 27 Jul 2006 16:33:22 +0200 X-Authenticated: #29516787 Message-ID: <44C8CEAE.2040903@gmx.net> Date: Thu, 27 Jul 2006 16:33:18 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> <8FF48E53-9E83-40AB-B1DC-B159931233F6@cs.columbia.edu><44C777D8.9030008@hxr.us> <46C30BB8-1D03-44D4-BF50-3C38FE0C23A3@cs.columbia.edu> <011501c6b0c9$09681910$31713b51@BEMBUSTER> <44C7919D.1010203@hxr.us> <44C79CA6.5040604@cs.columbia.edu> <44C7AA47.4080104@hxr.us> <44C7C8BF.4010103@cs.columbia.edu> <44C7D53C.3020205@hxr.us> In-Reply-To: <44C7D53C.3020205@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: geopriv@ietf.org, IETF SIP List , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Andy, in the use case where the proxy either adds a location-by-value or location-by-reference where would the proxy get the privacy policies from in the first place? If it has the rule and wants to convey location-by-value then why wouldn't it just include the rules instead of putting a reference to the ruleset in there that has to be retrieved first. In the Geopriv-L7 design team we were puzzled about the case where a LIS adds privacy rules to the PIDF-LO before signing it. In this case the LIS is the SIP proxy and the challenges remain the same. Ciao Hannes Andrew Newton wrote: > Henning Schulzrinne wrote: > >> We may be talking past each other. Currently, RFC 4119 has >> >> >> >> > minOccurs="0" maxOccurs="1"/> >> > minOccurs="0" maxOccurs="1"/> >> > minOccurs="0" maxOccurs="1"/> >> > minOccurs="0" maxOccurs="1"/> >> > maxOccurs="unbounded"/> >> >> >> >> I assume you're talking about the external-ruleset element. Regardless >> of how the rest of the GEOPRIV object is carried, this can point >> anywhere, including some static web object, a cid, or even be another >> data URL if you want to carry the policy along with the actual >> location information. > > > Hmmm... we seem to have caught a bug in 4119. Because the descriptive > text calls that element 'ruleset-reference' and not 'external-ruleset'. > Anyway, from the text (page 8): > > This URI SHOULD use the HTTPS URI scheme; and if it does, the > server that holds these rules MUST authenticate any attempt to > access these rules. Usage rules themselves may divulge private > information about a Target or Rule Maker. The URI MAY, > alternatively, use the CID URI scheme [7], in which case it MUST > denote a MIME body carried with the Location Object by the using > protocol. > > In other words, it would appear that the list of URIs allowed is HTTPS > or CID (though this doc SHOULD be more explicit). data: is not mentioned. > > This means that a PIDF-LO with a CID reference cannot be converted to a > data: URI. > > -andy > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 10:35:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66vt-0004NW-SZ; Thu, 27 Jul 2006 10:33:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66vs-0004NK-V3 for sip@ietf.org; Thu, 27 Jul 2006 10:33:48 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G66vs-0000lY-B4 for sip@ietf.org; Thu, 27 Jul 2006 10:33:48 -0400 Received: (qmail invoked by alias); 27 Jul 2006 14:33:39 -0000 Received: from ip-80-226-252-80.vodafone-net.de (EHLO [10.226.214.60]) [80.226.252.80] by mail.gmx.net (mp029) with SMTP; 27 Jul 2006 16:33:39 +0200 X-Authenticated: #29516787 Message-ID: <44C8CEBD.2030108@gmx.net> Date: Thu, 27 Jul 2006 16:33:33 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <035a01c6b0e7$c9250ba0$640fa8c0@cis.neustar.com> In-Reply-To: <035a01c6b0e7$c9250ba0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.6 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: sip@ietf.org, geopriv@ietf.org, "'Abbott, Nadine B'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Brian, are you talking about the end host adding a location-by-reference into the SIP header or a proxy doing so? In any case I don't understand your objection against the usage of HTTP and your preference for SIP/SIPS/PREZ? Ciao Hannes Brian Rosen wrote: > Nadine > > Are you saying that it's your opinion sip-location-conveyance MUST > define an HTTP dereference procedure? > > If you do, why? What is the use-case or requirement? > > Would it not be pretty reasonable to require a separate document that > defines a location-by-reference mechanism, protocol, and geopriv > "using protocol" analysis? If that document specifically extended > what was allowed in the location header, would that not be > reasonable? > > I think we have to include "A" dereference mechanism in the > location-conveyance document. It seems just including sip/sips/prez > is a reasonable, all-sip-all-the-time approach IN THIS DOCUMENT. > That certainly does not preclude another document describing another > way. > > Doesn't it seem just a little weird to have a sip-location-conveyance > document describing any kind of http based location conveyance > (de-reference) protocol, especially one created whole cloth without > any other parts? > > Doesn't it seem in keeping with the geopriv approach that in order to > have another "using protocol" it has to have a geopriv review? That > is what leads to restricting the URI schemes. Would you prefer to > let it be wide open, so any protocol anyone thinks about can be used > with the location header? I can't see geopriv going along with that. > We're going to make it a one line ABNF to add a new scheme to the > list of allowed schemes. > > It seems to me that if it's desired to define some bare-bones HTTP > location by reference protocol, then that should be a separate > document, which can easily extend the allowable schemes in the > Location header. I'm not sure it might be better to define ALL of > that in the L7 protocol, but I wouldn't be opposed to a simple "raw > GET" RFC as long as it got a full geopriv review. I just don't see > where it makes any sense to force that into a sip document. > > Brian > > >> -----Original Message----- From: Abbott, Nadine B >> [mailto:nabbott@telcordia.com] Sent: Wednesday, July 26, 2006 2:14 >> PM To: sip@ietf.org Cc: geopriv@ietf.org Subject: RE: [Geopriv] >> Consensus on changes to location-conveyance >> >> >> I don't agree that there is a consensus to preclude the use of >> HTTP. I would favor not placing your proposed restriction on the >> URI scheme for expressing a location reference in the SIP location >> conveyance draft; or at least including HTTP as a valid >> location-reference URI type. >> >> Regards, Nadine Abbott >> >> -----Original Message----- From: Rosen, Brian >> [mailto:Brian.Rosen@neustar.biz] Sent: Tuesday, July 25, 2006 1:38 >> PM To: sip@ietf.org Cc: geopriv@ietf.org Subject: [Geopriv] >> Consensus on changes to location-conveyance >> >> I have put out a number of emails on proposed changes to location >> conveyance. Some of them have sparked a number of comments. My >> summary of consensus on these issues is: >> >> 1. We proposed to explicitly disallow use of a Data URI, which >> would allow specification of a Location-by-value in a header. >> There was a lot of list traffic on this, currently in the state >> where Keith asked for a real use case for it. So far, we don't see >> a use case that cannot be provided by location-by-reference in a >> header. If we don't get a good use case, I think consensus is to >> disallow location-by-value in a header. >> >> 2. Dereferencing location-by-reference. We had initially proposed >> to document a process to use a raw HTTP(S) Get to dereference. >> There was a lot of discussion, and then I made a new proposal, see >> item 6. >> >> 3. We proposed to allow a Reason header with a 424 Bad Location >> response. This seems to be acceptable to the WG. Geopriv will >> create and populate the registry in a separate draft. >> >> 4. We proposed to explicitly allow hop-by-hop TLS security for >> location when the endpoint wished to allow routing based on >> location. We further proposed to interpret "Do not Distribute" >> flags as allowing sending of the location to the routing database >> (LoST for example). Hannes pointed out that there was a proposal >> to allow two Location headers, one of which could be used for >> routing and another for onward forwarding to the recipient. >> Hannes' message seemed to agree that "Do not distribute" would >> allow sending of the location to the routing-by-location database, >> but would obligate the proxy that did that to remove the location >> before it forwarded the message. There were no other messages on >> this thread. We conclude that allowing hop-by-hop security for >> location based routing is acceptable, and Do Not Distribute DOES >> allow forwarding to a routing database, but requires that the proxy >> doing the location based route to remove the location it uses for >> that purpose. >> >> 5. We proposed to create a parameter and a registry to distinguish >> multiple ways to dereference a location where HTTP(S) was the >> transport. Resolution of this issue depends on resolution of issue >> 6. >> >> 6. We proposed to allow sip/sips and pres: in the location header. >> I later speculated that if we allow this, it forms a simple way to >> do location-by-reference, and we could eliminate the raw HTTP(S) >> Get proposal, with the parameter and registry entirely. There was >> some list traffic in favor of this. Martin Thompson is skeptical >> that SIP Presence Subscribe/Notify is actually allowed as a geopriv >> "using protocol". Several of think that it is. If we don't get >> any more comments on this proposal, we will allow sip/sips and >> pres, not have any http(s) resolution text, and not propose a >> parameter and accompanying registry. >> >> If this does not reflect your position, please speak up now. >> >> Brian >> >> _______________________________________________ Geopriv mailing >> list Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> _______________________________________________ Geopriv mailing >> list Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 10:36:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66wN-0004o0-Fg; Thu, 27 Jul 2006 10:34:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66wM-0004m5-8M for sip@ietf.org; Thu, 27 Jul 2006 10:34:18 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G66wL-0000pj-Ih for sip@ietf.org; Thu, 27 Jul 2006 10:34:18 -0400 Received: (qmail invoked by alias); 27 Jul 2006 14:34:08 -0000 Received: from ip-80-226-252-80.vodafone-net.de (EHLO [10.226.214.60]) [80.226.252.80] by mail.gmx.net (mp032) with SMTP; 27 Jul 2006 16:34:08 +0200 X-Authenticated: #29516787 Message-ID: <44C8CED0.7000003@gmx.net> Date: Thu, 27 Jul 2006 16:33:52 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <00fa01c6b038$1e37fa40$1f0d0d0a@amer.cisco.com> In-Reply-To: <00fa01c6b038$1e37fa40$1f0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Cc: sip@ietf.org, "'Rosen, Brian'" , geopriv@ietf.org, "'Peterson, Jon'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Marc, I agree with you. I also think we should split the work into two parts as Henning suggested: One document covers the end host adds location-by-value (and potentially location-by-referenc) and another one that deals with the proxy doing something. The proxy case is far less understood as we know. Ciao Hannes Marc Linsner wrote: > I have no problem with pidf/pidf-lo/presence. > > I have no problem with a ua placing a uri pointing to their presence service > in a header of a sip invite. > > Context check: We're discussing a sip invite (assumed pointed to emergency > service) that arrives at a proxy with zero location information. > > I'm the only one that has a problem with any (visited) proxy/LIS creating a > uri that can be de-referenced by anyone without regard to user > security/privacy rules? > > -Marc- > > > > > > >>-----Original Message----- >>From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>Sent: Tuesday, July 25, 2006 4:42 PM >>To: Andrew Newton; Rosen, Brian >>Cc: sip@ietf.org; geopriv@ietf.org; Marc Linsner >>Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to >>location-conveyance >> >> >>As Brian points out, the whole point of using PIDF for >>location information was the similarity of the early defined >>use cases to the presence architecture. This certainly >>included use cases in which one wanted to fetch or subscribe >>to location information. Those operations require the >>existence of a reference, and that reference was commonly >>described as a URI, at the time. Lately, I think the idea of >>having a URI pointing to location information has become >>associated with a specific proposal (i.e. HELD), but clearly >>RFC4079 sketched out an architecture for using presence to >>acquire location information and it specifically mentions >>URIs as a way to refer to presence. >> >>There is no "hidden magic" in any of this. Subscribing to >>presence, and using URIs to indicate presence information, is >>exhaustively specified for SIP. PIDF-LO was designed to reuse >>all of that work and specifically not to require us to go out >>and reinvent everything in order to be able to refer to >>location information out in the network. >> >>Basically, I support the direction re: bullet 6. I might >>further suggest that the CID URI scheme be permitted in the >>Location header, in order to be able to refer to MIME bodies >>included in SIP messages. I'm also neutral/favorable on using >>HTTP GET. But I think either of these URI schemes and their >>usage in the Location header could just as well be described >>in subsequent documents. >> >>Jon Peterson >>NeuStar, Inc, >> >> >>>-----Original Message----- >>>From: Andrew Newton [mailto:andy@hxr.us] >>>Sent: Tuesday, July 25, 2006 1:05 PM >>>To: Rosen, Brian >>>Cc: sip@ietf.org; geopriv@ietf.org; Marc Linsner >>>Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to >>>location-conveyance >>> >>> >>>For the record, I agree with Brian. >>> >>>-andy >>> >>>On Jul 25, 2006, at 3:50 PM, Rosen, Brian wrote: >>> >>> >>>>When the original PIDF-LO RFC came out, location-by-reference was >>>>defined. >>>> >>>>You have a URI. You can exchange the URI for location. >> >>There is a >> >>>>protocol defined for that purpose (SIP SUBSCRIBE). That >> >>is location >> >>>>by reference. It also serves as the location update mechanism, >>>>clearly something we need. >>>> >>>>Some day, there may be other location URI references. We >> >>don't need >> >>>>to cover them in this draft. The basic location by >> >>reference horse >> >>>>has left the barn. Were you planning on creating an RFC that >>> >>>specifically >>> >>>>disallows a Subscribe on a sip/sips/pres URI to get location? >>>>THAT WAS >>>>THE POINT OF MAKING IT PART OF A PIDF. >>>> >>>>I do think there is some value in defining a way to express a >>>>location-by-reference aka presence URI which is not just >> >>the AoR. >> >>>>That >>>>is one reason why I want to define the Location URI as >> >>being able to >> >>>>contain a sip/sips/pres URI. The purpose is to allow a UA or a >>>>proxy to insert location where there is no association between the >>> >>>identity of >>> >>>>the SIP user and the location. >>>> >>>>But that is all I think we need. >>>> >>>>We have a requirement for proxy insertion of location. If >>> >>>we disallow >>> >>>>location-by-reference (which I think is a good idea in >> >>general, but >> >>>>futile in practice), then we would need something like the >>> >>>Data URI to >>> >>>>support location insertion by proxy. If we DO allow >>>>location-by-reference, then it also serves to meet the location >>>>insertion by proxy requirement, and we don't need the Data >>> >>>URI. We're >>> >>>>looking for a use case which requires proxy insertion by >> >>value, but >> >>>>haven't heard one yet. >>>> >>>>You can make an argument that you can take the From:, >> >>assume it's an >> >>>>AoR, and SUBSCRIBE to the presence of that AoR to get >> >>location, thus >> >>>>not needing a Location header. I really think letting the >>> >>>Location header >>> >>>>specify an alternate presence URI is a good idea. >>>> >>>>Brian >>>> >>>> >>>>>-----Original Message----- >>>>>From: Marc Linsner [mailto:mlinsner@cisco.com] >>>>>Sent: Tuesday, July 25, 2006 3:29 PM >>>>>To: Rosen, Brian; sip@ietf.org >>>>>Cc: geopriv@ietf.org >>>>>Subject: RE: [Geopriv] Consensus on changes to >> >>location-conveyance >> >>>>>In-line..... >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>Sent: Tuesday, July 25, 2006 1:38 PM >>>>>>To: sip@ietf.org >>>>>>Cc: geopriv@ietf.org >>>>>>Subject: [Geopriv] Consensus on changes to location-conveyance >>>>>> >>>>>>I have put out a number of emails on proposed changes >> >>to location >> >>>>>>conveyance. Some of them have sparked a number of >> >>comments. My >> >>>>>>summary of consensus on these issues is: >>>>>> >>>>>>1. We proposed to explicitly disallow use of a Data URI, which >>>>>>would allow specification of a Location-by-value in a header. >>>>>>There was a lot of list traffic on this, currently in the state >>>>>>where Keith asked for a real use case for it. >>>>>>So far, we don't see a use case that cannot be provided by >>>>>>location-by-reference in a header. If we don't get a good use >>>>>>case, I think consensus is to disallow location-by-value in a >>>>>>header. >>>>>> >>>>> >>>>>I see a problem here. Location-by-reference is nothing more than >>>> >>>>'magic >>>> >>>>>happens here'! Please point to a wg item documenting the >>>>>location-by-reference mechanism. How can you state the >>>>>location-by-reference will cover all the use cases that >>> >>>the Data URI >>> >>>>would >>>> >>>>>when location-by-reference hasn't even been defined >>> >>>anywhere? You're >>> >>>>>loading up the magic with a lot of assumptions. Location-by- >>>>>reference >>>> >>>>is >>>> >>>>>an >>>>>individual submission as a solution to a set of requirements that >>>> >>>>haven't >>>> >>>>>been fleshed-out in geopriv. >>>>> >>>>>I believe that Henning/Hannes also recognized this >> >>issue, hence the >> >>>>>suggestion of a Data URI. Dismissing this suggestion based on an >>>> >>>>already >>>> >>>>>accepted non-existent mechanism seems like getting the >>> >>>cart before >>> >>>>>the >>>>>horse. >>>>> >>>>>..........snip >>>>> >>>>> >>>>>>6. We proposed to allow sip/sips and pres: in the >> >>location header. >> >>>>>>I later speculated that if we allow this, it forms a >> >>simple way to >> >>>>>>do location-by-reference, and we could eliminate the >> >>raw HTTP(S) >> >>>>>>Get proposal, with the parameter and registry entirely. >> >> There was >> >>>>>>some list traffic in favor of this. Martin Thompson is >> >>skeptical >> >>>>>>that SIP Presence Subscribe/Notify is actually allowed as a >>>>>>geopriv "using protocol". Several of think that it is. If we >>>>>>don't get any more comments on this proposal, we will allow >>>>>>sip/sips and pres, not have any >>>>>>http(s) resolution text, and not propose a parameter and >>>>>>accompanying registry. >>>>> >>>>>I certainly think it's more prudent to define the dereferencing >>>> >>>>mechanism >>>> >>>>>prior to making claims about the protocol. >>>>> >>>>>Do I believe location-by-reference will happen? Probably, >>> >>>but making >>> >>>>>assumptions about the mechanism now is quite premature. >>>>> >>>>>-Marc- >>>>> >>>>> >>>>>>If this does not reflect your position, please speak up now. >>>>>> >>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol Use >>>>sip-implementors@cs.columbia.edu for questions on current sip Use >>>>sipping@ietf.org for new developments on the application of sip >>> >>> >>>_______________________________________________ >>>Geopriv mailing list >>>Geopriv@ietf.org >>>https://www1.ietf.org/mailman/listinfo/geopriv >>> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 10:36:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66wP-0004qh-AR; Thu, 27 Jul 2006 10:34:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66wO-0004pF-5x for sip@ietf.org; Thu, 27 Jul 2006 10:34:20 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G66wM-0000pt-MI for sip@ietf.org; Thu, 27 Jul 2006 10:34:20 -0400 Received: (qmail invoked by alias); 27 Jul 2006 14:34:08 -0000 Received: from ip-80-226-252-80.vodafone-net.de (EHLO [10.226.214.60]) [80.226.252.80] by mail.gmx.net (mp020) with SMTP; 27 Jul 2006 16:34:08 +0200 X-Authenticated: #29516787 Message-ID: <44C8CED7.1030305@gmx.net> Date: Thu, 27 Jul 2006 16:33:59 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Consensus on changes to location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Brian, I guess you are only talking about the current Location Conveyance document. Rosen, Brian wrote: > I have put out a number of emails on proposed changes to location > conveyance. Some of them have sparked a number of comments. My summary > of consensus on these issues is: > > 1. We proposed to explicitly disallow use of a Data URI, which would > allow specification of a Location-by-value in a header. There was a lot > of list traffic on this, currently in the state where Keith asked for a > real use case for it. So far, we don't see a use case that cannot be > provided by location-by-reference in a header. If we don't get a good > use case, I think consensus is to disallow location-by-value in a > header. I don't agree with your statements but I am (in the meanwhile) convinced that we need to cover this in a separate document. > > 2. Dereferencing location-by-reference. We had initially proposed to > document a process to use a raw HTTP(S) Get to dereference. There was a > lot of discussion, and then I made a new proposal, see item 6. > > 3. We proposed to allow a Reason header with a 424 Bad Location > response. This seems to be acceptable to the WG. Geopriv will create > and populate the registry in a separate draft. > > 4. We proposed to explicitly allow hop-by-hop TLS security for location > when the endpoint wished to allow routing based on location. We further > proposed to interpret "Do not Distribute" flags as allowing sending of > the location to the routing database (LoST for example). Hannes pointed > out that there was a proposal to allow two Location headers, one of > which could be used for routing and another for onward forwarding to the > recipient. Hannes' message seemed to agree that "Do not distribute" > would allow sending of the location to the routing-by-location database, > but would obligate the proxy that did that to remove the location before > it forwarded the message. There were no other messages on this thread. > We conclude that allowing hop-by-hop security for location based routing > is acceptable, and Do Not Distribute DOES allow forwarding to a routing > database, but requires that the proxy doing the location based route to > remove the location it uses for that purpose. Ok. > > 5. We proposed to create a parameter and a registry to distinguish > multiple ways to dereference a location where HTTP(S) was the transport. > Resolution of this issue depends on resolution of issue 6. > > 6. We proposed to allow sip/sips and pres: in the location header. I > later speculated that if we allow this, it forms a simple way to do > location-by-reference, and we could eliminate the raw HTTP(S) Get > proposal, with the parameter and registry entirely. There was some list > traffic in favor of this. Martin Thompson is skeptical that SIP > Presence Subscribe/Notify is actually allowed as a geopriv "using > protocol". Several of think that it is. If we don't get any more > comments on this proposal, we will allow sip/sips and pres, not have any > http(s) resolution text, and not propose a parameter and accompanying > registry. I disagree with location-by-reference being added to the document (or suggest to get it removed from the document). Ciao Hannes > > If this does not reflect your position, please speak up now. > > Brian > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 10:36:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66wZ-0004vm-Vk; Thu, 27 Jul 2006 10:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66wY-0004vc-AQ for sip@ietf.org; Thu, 27 Jul 2006 10:34:30 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G66wX-0000qU-Lq for sip@ietf.org; Thu, 27 Jul 2006 10:34:30 -0400 Received: (qmail invoked by alias); 27 Jul 2006 14:34:24 -0000 Received: from ip-80-226-252-80.vodafone-net.de (EHLO [10.226.214.60]) [80.226.252.80] by mail.gmx.net (mp038) with SMTP; 27 Jul 2006 16:34:24 +0200 X-Authenticated: #29516787 Message-ID: <44C8CEDF.3010502@gmx.net> Date: Thu, 27 Jul 2006 16:34:07 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <024e01c6b046$b1b36080$640fa8c0@cis.neustar.com> In-Reply-To: <024e01c6b046$b1b36080$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: geopriv@ietf.org, "Peterson, Jon" , sip@ietf.org, 'Marc Linsner' , "Rosen, Brian" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Brian, Brian Rosen wrote: > I don't really understand why you think location by reference is so much of > a concern. It is interesting that you say that. In the Geopriv L7 design team you are the only person that wants to see an applicability statement being written. Having a SIP proxy adding something (either location-by-value or location-by-reference) is not different to the stuff we discuss in the design team. There, you see a lot of privacy, security, etc. problems. Here you don't. How come? If you go through my mail with the large number of scenarios then you find a number of open issues that need to be answered. Alternatively, you can also go through draft-tschofenig-geopriv-l7-lcp-ps-00.txt If you look at the discussion in context, PIDF-LO defines > location as part of presence. All of these concerns are relevant there, and > I think they have been adequately covered there. We even have some work on > anonymization of the identity (and thus of the URI) in presence. Generally, > a presence uri: > > Is not valid for a limited amount of time > Is not hard to guess, if it uses an AoR and could be with anonymous URI. > Identifies the user if it uses an AoR and doesn't with anonymous URI > > The protocol (SIP) for retrieving presence, and thus location has the > location ruleset as we defined for PIDF-LO, but otherwise does not have "no > cache" semantics (albeit caching headers is not very interesting in SIP). You cannot compare presence witht he location-by-reference solution since the deployment case is different. > > Generally, presence systems do have user control of who is allowed to access > information, including location and identifying information, so I think that > is covered fairly well. Not true in this case. Here we have a SIP proxy in the access network doing all the work. You can compare it with a SIP-based LIS from the Geopriv-L7 work. This node has no clue about your privacy preferrences and does not know your identity. This is what we discussed in the past and several proposals where made, namely: * end host provides privacy preferences (see HELD) * end host does not provide privacy preferences since there is no PIDF-LO (see RELO). > > Proxy insertion of location, whether by value or by reference has the threat > of not being as subject to user control, but I think in every case you have > to trust your provider to do as you wish, whether it is your presence > provider or your location provider independent of your presence provider, > and proxy insertion doesn't fundamentally alter that. I worry more about > it, but I don't objectively think it's much different. In this case you don't really know the provider and it might not be your provider. > > Now, if there are other location dereferencing systems, they may need an > analysis like what you are suggesting, but with respect to SIP Presence, as > a form of location by reference, I think we have been over the ground > sufficiently, and we have RFCs that permit it. Adding restrictions on the > Location header, which I propose is useful precisely to allow an anonymous > presence uri that does not reveal identity is not so great I think. If you > don't allow that, you would kind of have to use an AoR, which may be > appropriate in some cases, but would not in others. The reference might not reveal the identity but what about the identity in the PIDF-LO. If you argue that there does not need to be one (or it is a faked one) then I am puzzled why it has been a source of major confusion in the Geopriv-L7 design team work (and in previous discussions about the same subject in Geopriv). > > I think the proponents of proxy insertion argue that providing it means > endpoints don't have to do anything, so I would think they would object to > explicit permission to do so. You might get away with a flag that says > "don't do it" in the IETF process, but whether such a flag would be deployed > is another matter. I think we all agree that the emergency case is > different here; laws govern behavior, and in most cases compel location > assertion. This is indeed an interesting case where the end host indicates something whether it wants the proxy to add location (by reference). > > I kind of like the idea that the proxy inserts the header in the response so > the UAC can see it. What do others think of that? > Ciao Hannes > Brian > > > >>-----Original Message----- >>From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>Sent: Tuesday, July 25, 2006 7:22 PM >>To: Brian Rosen; 'Marc Linsner'; Peterson, Jon; 'Andrew Newton'; Rosen, >>Brian >>Cc: sip@ietf.org; geopriv@ietf.org >>Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- >>conveyance >> >>Brian, >> >> >>>Would you not agree that if a proxy is allowed to insert >>>location-by-value, >>>the concerns would be the same? >> >>That would depend whether the URL dereferences the current location, or >>the >>location at a particular moment in time. The value of a URI with up2date >>location info is much higher and much more privacy invading than a one- >>time >>snapshot of a user's location. So perhaps same concerns, but much stronger >> >>For location-by-reference, you'd probably want some additional >>requirements: >>- URL must be valid for a limited amount of time >>- URL must be cryptographically hard to guess >>- URL must not contain any information that identifies the user / device / >>AoR >>- for whatever transport protocol is used: response must be marked as 'no >>cache' >>- user must be able to remove the information at the URL, ie explicit >>invalidation >>- user must be able to verify correctness of the issued information (ie >>user >>can access the URL himself) >>- user must be able to control who accesses the URL, both upfront and >>history of accesses (for a reasonable period) >>- there must be explicit consent before a proxy would insert user location >> >>For the latter point: except for emergency scenario's, the UAC should >>include some flag in the INVITE saying "proxy: please append location". >>You'd probably also want some feedback (eg proxy or UAS adding a header to >>the response saying 'this is the URL that I appended/got' >> >>Regards, >> >>Jeroen >> > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 10:36:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66wv-0005eJ-Iz; Thu, 27 Jul 2006 10:34:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66wt-0005c3-Uv for sip@ietf.org; Thu, 27 Jul 2006 10:34:51 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G66wq-0000rY-Q3 for sip@ietf.org; Thu, 27 Jul 2006 10:34:51 -0400 Received: (qmail invoked by alias); 27 Jul 2006 14:34:42 -0000 Received: from ip-80-226-252-80.vodafone-net.de (EHLO [10.226.214.60]) [80.226.252.80] by mail.gmx.net (mp029) with SMTP; 27 Jul 2006 16:34:42 +0200 X-Authenticated: #29516787 Message-ID: <44C8CEFF.205@gmx.net> Date: Thu, 27 Jul 2006 16:34:39 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dawson, Martin" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: IETF SIP List , geopriv@ietf.org, Henning Schulzrinne Subject: [Sip] Henning's Suggestion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Henning, I like your suggestion. In fact I would even go a step further. The SIP Location Conveyance document just defines a mechanism to carry a PIDF-LO in the body of the SIP message. Done. Adding location-by-reference to the SIP header by the end host sounds OK but there are still some loose ends where this reference comes from. The other stuff can be dealt with once we concluded our Geopriv-L7 work where all the architectural pieces should are created. The subscription-URI is an example where we recently proposed something and haven't finished our technical discussions. I think the draft got fuzzy when it came to the area where a SIP proxy adds a location-by-reference. I must admit that I proposed to add location-by-value into the SIP header as well but in the meanwhile I don't think that any of the SIP proxy stories belong in there. Ciao Hannes >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Thursday, 27 July 2006 1:25 PM >>To: Brian Rosen >>Cc: IETF SIP List; geopriv@ietf.org >>Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- >>conveyance >> >>My suggestion would be >> >>- to focus the draft on just defining the Location header syntax, >>without ruling out any particular mechanism or scheme; this would >>make the draft really short (which I would find helpful). >> >>- and then add one section to the draft that prototypically defines >>what a particular scheme that wants to appear in the Location header >>needs to define, using the non-controversial cid mechanism as the >>example. Other, separate, drafts can then define other modes, >>following the same template. Documents such as the phone-bcp can then >>pick some suitable must-implement subset and make emergency-call- >>specific recommendations, rather than sprinkling these throughout the >>conveyance document and repeating some in the phone-bcp. Most of >>these are, in any event, operational recommendations, not for >>ensuring protocol-level interoperability. >> >>That way, the conveyance draft can be extremely short (even shorter >>if the requirements are omitted...) and can get done, and we avoid >>engineering operational requirements on the fly, commingling >>emergency and non-emergency cases, as seems to be happening now. >> >>I think protocol documents should define what's needed for >>interoperability; BCPs can make more specific, situation-specific >>recommendations. Commingling the two seems to be a recipe for >>deadlock or arbitrary, non-technically-grounded decisions that are >>more lawyer-like than engineering-like ("you did not mention >>technique X in some meeting N years ago and thus you can't bring it >>up now!") >> >>Henning >> >>On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote: >> >> >>>At this point, I think we need some chair guidance and by that I >>>think it's >>>a combo of geopriv and sip chairs. >>> >>>We seem to have a couple of significant open questions. I think >>>most of the >>>other stuff (like the "allow sending to router") will converge. >>> >>>There seems to be some opposition to allowing sip/sips/pres: in a >>>Location >>>Header. The opposition seems to be that despite 4119, somehow, SIP >>>(presence subscription) is not a "using protocol". I "think" a >>>ruling from >>>the bench on that would work. >>> >>>There is also opposition to defining the allowed schemes as a >>>specific list, >>>with a defined (easy) extension mechanism. >>> >>>Related to that, there are some who want location-conveyance to >>>define an >>>HTTP based location dereference mechanism, and on the opposite end, >>>we have >>>people saying we haven't even agreed to support any form of >>>location-by-reference. >>> >>>The authors would like to know what to do now. >>> >>>Brian >>> >>> >>>>-----Original Message----- >>>>From: Andrew Newton [mailto:andy@hxr.us] >>>>Sent: Wednesday, July 26, 2006 9:58 PM >>>>To: Winterbottom, James >>>>Cc: sip@ietf.org; geopriv@ietf.org; Abbott, Nadine B; Henning >>>>Schulzrinne >>>>Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- >>>>conveyance >>>> >>>> >>>>On Jul 26, 2006, at 9:43 PM, Winterbottom, James wrote: >>>> >>>> >>>>>Andy, >>>>> >>>>>RFC-4119 says "However, the usage of this location object format > > is > >>>>>not >>>>> limited to presence-using protocols-- any protocol that can >>>>>carry XML >>>>> or MIME types can carry PIDF." >>>>> >>>>>It seems to me that restricting the allowed schema in what is >>>>>supposed >>>>>to be a location conveyance specification is in opposition to this >>>>>statement. >>>> >>>>Did somebody say that HTTP was a presence-using protocol? >>>> >>>>-andy >>>> >>>>ps. you can find my location with the following reference URIs: >>>> >>>>gopher://fatchance.hxr.us/you-still-have-a-gopher-client >>>>news:alt.locations.people.secretly-being-watched >>>>telnet://screen-scrapers.are.us/ >>>>dns:cached-publicly-around-the-world.com?type=HOST >>>> >>>> >>>> >>>>_______________________________________________ >>>>Geopriv mailing list >>>>Geopriv@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/geopriv >>> >>> >>>_______________________________________________ >>>Geopriv mailing list >>>Geopriv@ietf.org >>>https://www1.ietf.org/mailman/listinfo/geopriv >> >> >>_______________________________________________ >>Geopriv mailing list >>Geopriv@ietf.org >>https://www1.ietf.org/mailman/listinfo/geopriv > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 10:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G672a-0003dM-HP; Thu, 27 Jul 2006 10:40:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G672Y-0003bb-EI; Thu, 27 Jul 2006 10:40:42 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G672X-0001Aj-0K; Thu, 27 Jul 2006 10:40:42 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k6REdZT8015158; Thu, 27 Jul 2006 09:39:39 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 09:39:37 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 16:39:35 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Teasing apart positions (was Re: [Sip] RE: [Geopriv] Consensusonchanges to location-conveyance) Date: Thu, 27 Jul 2006 16:39:34 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180194FAA@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Teasing apart positions (was Re: [Sip] RE: [Geopriv] Consensusonchanges to location-conveyance) Thread-Index: AcaxMHmw6hxTqparSMiNsLAsa89MsQABbbzQABTa0sA= From: "Drage, Keith \(Keith\)" To: "Thomson, Martin" , "Andrew Newton" X-OriginalArrivalTime: 27 Jul 2006 14:39:35.0656 (UTC) FILETIME=[7B298680:01C6B18A] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (as individual) It's a GEOPRIV problem to identify what height the bar is. At least my understanding is that Presence was a location using protocol and the level of documentation was agreed by GEOPRIV. That makes the bar around at least informational RFC required. For use in location by reference I believe we have two criteria to meet: i) the dereferencing protocol must be a geopriv using protocol ii) if we have more than one option, we either need some means of determining that the dereferencer supports the one the client chooses to use, or require support of all options. As we seem to be lacking any mechanism for the former, then it would imply that all options have to be supported at the dereferencer, and therefore that the list needs to be a small list. Regards Keith > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20 > Sent: 27 July 2006 06:00 > To: Andrew Newton > Cc: IETF SIP List; GEOPRIV > Subject: RE: Teasing apart positions (was Re: [Sip] RE:=20 > [Geopriv] Consensusonchanges to location-conveyance) >=20 > Since I raised the question, I'll answer. >=20 > We have a set of requirements on a using protocol in RFC 3693. >=20 > I believe that HTTP with proper constraints (TLS, etc...) can=20 > meet, or already meets, those requirements. That is=20 > irrespective of any decisions that need to be made about=20 > secondary concerns like whether HTTP is desirable, optimal,=20 > deployable etc... However, it is clear that people aren't=20 > happy with this position and are requesting that this be=20 > documented, as an RFC. Just to get it all out in the open. =20 > Presumably this would be a standards track RFC that, like=20 > location-conveyance, highlights how the RFC 3693 requirements=20 > are addressed. >=20 > That's a sound argument, and obviously location-conveyance=20 > had to meet that standard for us to be happy. Now, I ask=20 > that you go back, take the above paragraph and perform one=20 > simple operation and read it again: s/HTTP/SIP/g. Is the=20 > argument any different in the presence of RFC 4079? Is an=20 > informational RFC that doesn't address specific requirements=20 > adequate? I'd suggest that it wouldn't make the grade for HTTP. >=20 > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Thursday, 27 July 2006 1:55 PM > > To: IETF SIP List; GEOPRIV > > Subject: Teasing apart positions (was Re: [Sip] RE: [Geopriv]=20 > > Consensus onchanges to location-conveyance) > >=20 > >=20 > > On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote: > > > The authors would like to know what to do now. > >=20 > > Let's start by trying to tease apart certain positions. > >=20 > > Given Jon Peterson's message: > > http://www1.ietf.org/mail-archive/web/sip/current/msg15537.html > >=20 > > Does anybody still believe that subscriptions to PIDF-LOs with pres: > > requires more definition? > >=20 > > -andy > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 10:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G672e-0003m2-7f; Thu, 27 Jul 2006 10:40:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G672c-0003g0-6j for sip@ietf.org; Thu, 27 Jul 2006 10:40:46 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G672a-0001Au-Mh for sip@ietf.org; Thu, 27 Jul 2006 10:40:46 -0400 Received: (qmail invoked by alias); 27 Jul 2006 14:34:00 -0000 Received: from ip-80-226-252-80.vodafone-net.de (EHLO [10.226.214.60]) [80.226.252.80] by mail.gmx.net (mp019) with SMTP; 27 Jul 2006 16:34:00 +0200 X-Authenticated: #29516787 Message-ID: <44C8CEC9.4030009@gmx.net> Date: Thu, 27 Jul 2006 16:33:45 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton References: <022b01c6b03c$dbc169d0$640fa8c0@cis.neustar.com> <001101c6b041$171edfe0$31713b51@BEMBUSTER> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: geopriv@ietf.org, "Peterson, Jon" , sip@ietf.org, 'Marc Linsner' , "Rosen, Brian" Subject: [Sip] Location by Reference Requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Andy, Hi Jeroen, Andrew Newton wrote: > > On Jul 25, 2006, at 7:21 PM, Jeroen van Bemmel wrote: > >> For location-by-reference, you'd probably want some additional >> requirements: >> - URL must be valid for a limited amount of time Ok. Should it be end point controlled or should the end point be informed about the lifetime? >> - URL must be cryptographically hard to guess must contain a random,non-guessable component. >> - URL must not contain any information that identifies the user / >> device / AoR more difficult if you consider that a PIDF-LO contains identity information. >> - for whatever transport protocol is used: response must be marked as >> 'no cache' Sounds reasonble. >> - user must be able to remove the information at the URL, ie explicit >> invalidation Difficult with the SIP based approach we are discussing. Simpler with the Geopriv-L7 approach being discussed. >> - user must be able to verify correctness of the issued information >> (ie user can access the URL himself) Difficult with the discussed SIP-based mechanism since the user does not ever see the URI. >> - user must be able to control who accesses the URL, both upfront and >> history of accesses (for a reasonable period) This has been subject for a long discussion with no conclusion. >> - there must be explicit consent before a proxy would insert user >> location That's not what some of the use cases indicate. Nice requirements; maybe something for the Geopriv L7 design team. > > > Please tell me that you are merely suggesting guidelines and > considerations by operators and are not suggesting 2119 language for > these? Because just like you'd never get agreement on the intended > duration or accuracy or confidence of location-by-value, you'd never > get agreement on these. Well, some of these requirements are actually protocol capabilities. With some other stuff I agree with you, Andy. > >> For the latter point: except for emergency scenario's, the UAC should >> include some flag in the INVITE saying "proxy: please append >> location". You'd probably also want some feedback (eg proxy or UAS >> adding a header to the response saying 'this is the URL that I >> appended/got' This is in fact interesting. I haven't seen these requirements so far. > > > Just thinking out loud here, but maybe the rule should be that proxies > never append a Location header except for emergencies. The problem is that the IETF cannot enforce this. Once you have a solution for adding location-by-reference by a proxy it can do it. Ciao Hannes > > -andy > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 10:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G672f-0003qs-II; Thu, 27 Jul 2006 10:40:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G672d-0003kY-Ol for sip@ietf.org; Thu, 27 Jul 2006 10:40:47 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G672c-0001B1-AA for sip@ietf.org; Thu, 27 Jul 2006 10:40:47 -0400 Received: (qmail invoked by alias); 27 Jul 2006 14:34:01 -0000 Received: from ip-80-226-252-80.vodafone-net.de (EHLO [10.226.214.60]) [80.226.252.80] by mail.gmx.net (mp003) with SMTP; 27 Jul 2006 16:34:01 +0200 X-Authenticated: #29516787 Message-ID: <44C8CEC2.5040801@gmx.net> Date: Thu, 27 Jul 2006 16:33:38 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <024e01c6b046$b1b36080$640fa8c0@cis.neustar.com> <004601c6b07f$355c3b90$31713b51@BEMBUSTER> In-Reply-To: <004601c6b07f$355c3b90$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: geopriv@ietf.org, "Peterson, Jon" , sip@ietf.org, 'Marc Linsner' , "Rosen, Brian" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all, I would really appreciate if you guys make a difference between an end host adding a location-by-reference and a proxy adding a location-by-reference to a SIP message. If the end host adds something you can further differentiate whether it is added to the header or the body. This differentiation is really important and that was the reason why I wrote a long mail (and it took some time) to elaborate on the different scenarios and the challenges. Jeroen van Bemmel wrote: >> I don't really understand why you think location by reference is so >> much of >> a concern. > > > Because location by reference involves storage of personal information > on a server. In general it does not. That suddenly makes all sorts of regulations apply, the > points I mentioned address only a small part of that. Having an > anonymous URL for example often makes a difference, because then the > information is no longer directly linked to a particular person. > > When an endpoint inserts location by value, you can reasonably argue > that opt-in consent requirements (which many countries have) are > fulfilled, provided the endpoint gives the user control over whether or > not location is inserted. Same holds for the endpoint inserting a flag > asking a proxy to fill in the location (by value). One of the use cases I have been told regarding the location-by-reference addition by the SIP proxy is that providers want to deal with legacy devices that do not learn location information from the network. > For location-by-reference this is much more fuzzy. You probably don't > need a lecture on privacy regulations, but e.g. > http://www.isoc.org/briefings/015/index.shtml (from 2003 but still > applicable IMO) illustrates the mess. > > A while ago I submitted a draft on Temporarily Routable User Agent URIs > (http://www.ietf.org/internet-drafts/draft-jbemmel-sip-truu-02.txt), > which provides anonymous, temporary URIs that can be explicitly > invalidated. You may want to consider something similar for > location-by-reference Ciao Hannes > > Regards, > > Jeroen > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 10:45:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G675i-00063C-Lg; Thu, 27 Jul 2006 10:43:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G675h-00062D-Im; Thu, 27 Jul 2006 10:43:57 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G675g-0001fV-8m; Thu, 27 Jul 2006 10:43:57 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k6REhtZW009509; Thu, 27 Jul 2006 09:43:55 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 09:43:55 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 16:43:53 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 27 Jul 2006 16:43:52 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180194FBC@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] teasing apart: http as a GEOPRIV using protocol Thread-Index: AcaxenIqMB17/2vKReC5QO+fEWmFGAAEISbw From: "Drage, Keith \(Keith\)" To: "Andrew Newton" , "IETF SIP List" , "GEOPRIV" X-OriginalArrivalTime: 27 Jul 2006 14:43:53.0383 (UTC) FILETIME=[14C78B70:01C6B18B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (as individual) I am not supporting or objecting, but I do believe that if it is to be a using protocol, then there must be some form of RFC that specifies how it meets the GEOPRIV requirements. Regards Keith=20 > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: 27 July 2006 13:45 > To: IETF SIP List; GEOPRIV > Subject: [Geopriv] teasing apart: http as a GEOPRIV using protocol >=20 > There have been a number of opinions regarding HTTP as a=20 > using protocol. >=20 > I'd like to know, how many people believe that HTTP requires=20 > no or very little specification to meet the requirements in=20 > RFC 3693 and RFC 3694. If you believe this, what basis do=20 > you have for this conclusion? Or do you believe more=20 > specification needs to be done, but it is possible for HTTP=20 > to be a GEOPRIV using protocol? >=20 > Finally, how many people believe that HTTP should not be a=20 > using protocol? >=20 > -andy >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 11:35:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67s1-0002Br-9p; Thu, 27 Jul 2006 11:33:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67rz-0002Bj-Ln; Thu, 27 Jul 2006 11:33:51 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G67rx-0005Zh-EJ; Thu, 27 Jul 2006 11:33:51 -0400 Received: from lion.cs.columbia.edu (IDENT:ExnNVYo94uo2idlubDB3YlQq2HTKZ5MN@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6RFXl4F013465 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 27 Jul 2006 11:33:48 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6RFXirh004768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Jul 2006 11:33:45 -0400 Message-ID: <44C8DCD3.6090109@cs.columbia.edu> Date: Thu, 27 Jul 2006 11:33:39 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: Teasing apart positions (was Re: [Sip] RE: [Geopriv] Consensusonchanges to location-conveyance) References: <5D1A7985295922448D5550C94DE29180194FAA@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180194FAA@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.27.80932 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > ii) if we have more than one option, we either need some means of > determining that the dereferencer supports the one the client chooses to > use, or require support of all options. As we seem to be lacking any > mechanism for the former, then it would imply that all options have to > be supported at the dereferencer, and therefore that the list needs to > be a small list. This isn't quite true. It is quite possible to include multiple options, as long as one of them is universally supported. For example, you can support a "universal & slow" and a "sometimes & fast" solution, and everybody wins. This approach is not new: MIME email does exactly that, where messages with HTML or rich text often also contain an alternate plain text rendering. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 11:37:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67tx-0002fY-Qg; Thu, 27 Jul 2006 11:35:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67tw-0002eZ-4L for sip@ietf.org; Thu, 27 Jul 2006 11:35:52 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G67tu-00067q-LD for sip@ietf.org; Thu, 27 Jul 2006 11:35:52 -0400 Received: (qmail invoked by alias); 27 Jul 2006 15:35:47 -0000 Received: from ip-80-226-231-156.vodafone-net.de (EHLO [10.226.128.7]) [80.226.231.156] by mail.gmx.net (mp022) with SMTP; 27 Jul 2006 17:35:47 +0200 X-Authenticated: #29516787 Message-ID: <44C8DD4D.10003@gmx.net> Date: Thu, 27 Jul 2006 17:35:41 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Sip] Teasing apart: constraints on dereference URI References: <44C8CCF3.2030506@hxr.us> In-Reply-To: <44C8CCF3.2030506@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Andy, I would like to see the architectural questions being solved first. I don't think that it should go into the location conveyance document if there is interest to get it done soon. Finally, I would like to see some strawman proposals first. I don't want to sign a blank check. Ciao Hannes Andrew Newton wrote: > There have been many conversations regarding constraining the URI in the > Location header. There have been many positions taken on this subject, > and this email is intended to understand the various opinions. > > Is there anybody who believes that the type of URI in the Location > header should not be constrained in any way? In other words, any URI > scheme may be valid and there should be no attempt to specify the URI > scheme or associated protocol for dereferencing location. And if so, do > you believe location will only be dereferenced via a user clicking on a > link or by automatic software action? If the latter, how do you see > software adapting to multiple URI schemes and their associated protocols? > > Is there anybody who believes that the dereference URI should be > restricted to a specific set of schemes, enforced via ABNF, XML Schema, > or other grammar specification and re-enforced with MUST/SHOULD > language? The intent here being that the set would be definitive or at > the very least require major effort to update. > > Finally, how many people desire a middle ground? Perhaps where the > ABNF, XML Schema or other grammar specification allows for any URI > scheme but there is an IANA registry listing the allowed dereference URI > schemes and associated protocols? > > -andy > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 11:37:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67u9-0002qj-VU; Thu, 27 Jul 2006 11:36:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67u8-0002ni-91 for sip@ietf.org; Thu, 27 Jul 2006 11:36:04 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G67u5-00068V-Og for sip@ietf.org; Thu, 27 Jul 2006 11:36:04 -0400 Received: (qmail invoked by alias); 27 Jul 2006 15:35:55 -0000 Received: from ip-80-226-231-156.vodafone-net.de (EHLO [10.226.128.7]) [80.226.231.156] by mail.gmx.net (mp018) with SMTP; 27 Jul 2006 17:35:55 +0200 X-Authenticated: #29516787 Message-ID: <44C8DD55.3090306@gmx.net> Date: Thu, 27 Jul 2006 17:35:49 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: Teasing apart positions (was Re: [Sip] RE: [Geopriv] Consensusonchanges to location-conveyance) References: <5D1A7985295922448D5550C94DE29180194FAA@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180194FAA@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: IETF SIP List , GEOPRIV , "Thomson, Martin" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Keith, Drage, Keith (Keith) wrote: > (as individual) > > It's a GEOPRIV problem to identify what height the bar is. At least my > understanding is that Presence was a location using protocol and the > level of documentation was agreed by GEOPRIV. That makes the bar around > at least informational RFC required. The presence based using protocol we did was meant to be used in a different environment. Let me point you to one main difference: The Rule Maker had a relationship with the Location Server. The Rule Maker might, in many cases, be the Target. In the discussions about a location-by-reference being added by a SIP proxy this is not the case. I strongly believe that there is not a single 1-to-1 translation between the presence work and the work we do here when it concerns location-based routing as argued in other mails. You can convince me that this is not true (and you would probably also solve our Geopriv-L7 challenge as a side effect). > > For use in location by reference I believe we have two criteria to meet: Where do these requirements come from? > > i) the dereferencing protocol must be a geopriv using protocol I think that there is a terminology problem here. > > ii) if we have more than one option, we either need some means of > determining that the dereferencer supports the one the client chooses to > use, or require support of all options. As we seem to be lacking any > mechanism for the former, then it would imply that all options have to > be supported at the dereferencer, and therefore that the list needs to > be a small list. This is indeed an issue but seems to be similar to the topics we deal with in the phone BCP. In fact we already have this problem today if I understood draft-hdesinen-geopriv-pidflo-extn-00.txt correctly. Ciao Hannes > > Regards > > Keith > > >>-----Original Message----- >>From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] >>Sent: 27 July 2006 06:00 >>To: Andrew Newton >>Cc: IETF SIP List; GEOPRIV >>Subject: RE: Teasing apart positions (was Re: [Sip] RE: >>[Geopriv] Consensusonchanges to location-conveyance) >> >>Since I raised the question, I'll answer. >> >>We have a set of requirements on a using protocol in RFC 3693. >> >>I believe that HTTP with proper constraints (TLS, etc...) can >>meet, or already meets, those requirements. That is >>irrespective of any decisions that need to be made about >>secondary concerns like whether HTTP is desirable, optimal, >>deployable etc... However, it is clear that people aren't >>happy with this position and are requesting that this be >>documented, as an RFC. Just to get it all out in the open. >>Presumably this would be a standards track RFC that, like >>location-conveyance, highlights how the RFC 3693 requirements >>are addressed. >> >>That's a sound argument, and obviously location-conveyance >>had to meet that standard for us to be happy. Now, I ask >>that you go back, take the above paragraph and perform one >>simple operation and read it again: s/HTTP/SIP/g. Is the >>argument any different in the presence of RFC 4079? Is an >>informational RFC that doesn't address specific requirements >>adequate? I'd suggest that it wouldn't make the grade for HTTP. >> >> >>>-----Original Message----- >>>From: Andrew Newton [mailto:andy@hxr.us] >>>Sent: Thursday, 27 July 2006 1:55 PM >>>To: IETF SIP List; GEOPRIV >>>Subject: Teasing apart positions (was Re: [Sip] RE: [Geopriv] >>>Consensus onchanges to location-conveyance) >>> >>> >>>On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote: >>> >>>>The authors would like to know what to do now. >>> >>>Let's start by trying to tease apart certain positions. >>> >>>Given Jon Peterson's message: >>>http://www1.ietf.org/mail-archive/web/sip/current/msg15537.html >>> >>>Does anybody still believe that subscriptions to PIDF-LOs with pres: >>>requires more definition? >>> >>>-andy >>> >>>_______________________________________________ >>>Geopriv mailing list >>>Geopriv@ietf.org >>>https://www1.ietf.org/mailman/listinfo/geopriv >> >>-------------------------------------------------------------- >>---------------------------------- >>This message is for the designated recipient only and may >>contain privileged, proprietary, or otherwise private information. >>If you have received it in error, please notify the sender >>immediately and delete the original. Any unauthorized use of >>this email is prohibited. >>-------------------------------------------------------------- >>---------------------------------- >>[mf2] >> > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 11:38:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67uZ-0003V1-7I; Thu, 27 Jul 2006 11:36:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67uX-0003Rl-7s for sip@ietf.org; Thu, 27 Jul 2006 11:36:29 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G67uV-0006Iq-PL for sip@ietf.org; Thu, 27 Jul 2006 11:36:29 -0400 Received: (qmail invoked by alias); 27 Jul 2006 15:36:21 -0000 Received: from ip-80-226-231-156.vodafone-net.de (EHLO [10.226.128.7]) [80.226.231.156] by mail.gmx.net (mp026) with SMTP; 27 Jul 2006 17:36:21 +0200 X-Authenticated: #29516787 Message-ID: <44C8DD67.6090908@gmx.net> Date: Thu, 27 Jul 2006 17:36:07 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Sip] teasing apart: http as a GEOPRIV using protocol References: <04d501c6b180$6e39f4a0$640fa8c0@cis.neustar.com> <7A8FBA4E-DD34-4C89-80B6-BE2913101258@cs.columbia.edu> In-Reply-To: <7A8FBA4E-DD34-4C89-80B6-BE2913101258@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Henning, here is the reason why I think we are not talking about a 'using protocol' here: All we want is to perform dereferencing. We don't want something that does all the fancy features of a presence solution. I am not even sure where the privacy rules should come from. In the Geopriv L7 discussion we had at least a proposal that some of us didn't like (namely the end host provides the privacy rules to the LIS). I haven't seen such a proposal here. Here is my question (I raised it already with my scenario list): Where does the SIP proxy get the information to construct a PIDF-LO? * We assume that it gets the location information somehow. Not further specified and might depend on the deployment environment. * What is the "entity" attribute of the 'presence' element? * Where does the content for the usage-rules (e.g, 'retransmission-allowed', 'retention-expires', 'ruleset-reference', 'note-well') come from? Note that these questions are independent of HTTP. They also apply to SIP. You might also recall the discussion regarding the difference between RELO and HELD when it comes to the threat model. In RELO you assume that the entity that learns the reference is allowed to resolve it. In HELD there is the assumption that the end host additionally uploads the Geopriv authorization policies to control the access. We never came to a conclusion about the threat model that is applicable in the Geopriv L7 case. I strongly believe that the questions are similar here and there are no answers to them. We are just exchanging one protocol (HTTP of RELO and HELD) with another one: SIP and route the call via this entity in the access network. If the SIP proxy that adds location information (by reference or value) is not in the access network then it cannot know the location information of the end host.... Ciao Hannes Henning Schulzrinne wrote: > For all protocols, the hardest part is specifying how authentication > works in conjunction with the privacy rules. This is far from obvious > for HTTP, for example. (Is it the Digest user identifier? Can Basic > over TLS be used instead? What about crypto-random request URIs? Is > HTTP ok in that case or is HTTPS needed - the answer isn't obvious > since an observer would only see a location, not a location-identity > pair.) > > For SIP, this is largely done, except for the crypto-random request URI > case and variations, such as user + password. > > On Jul 27, 2006, at 9:27 AM, Brian Rosen wrote: > >> I think HTTP requires some specification. A raw GET based retrieval >> of a >> PIDF would be a fairly short RFC, but I think we need that RFC. >> >> While I don't think it's necessary (SIP SUBSCRIBE is sufficient), I >> don't >> object to defining HTTP as a using protocol in a suitable RFC. >> >> Brian > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 11:44:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G680r-00031b-HC; Thu, 27 Jul 2006 11:43:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G680p-00031R-8n for sip@ietf.org; Thu, 27 Jul 2006 11:42:59 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G680n-0001Jd-QK for sip@ietf.org; Thu, 27 Jul 2006 11:42:59 -0400 Received: (qmail invoked by alias); 27 Jul 2006 15:36:14 -0000 Received: from ip-80-226-231-156.vodafone-net.de (EHLO [10.226.128.7]) [80.226.231.156] by mail.gmx.net (mp034) with SMTP; 27 Jul 2006 17:36:14 +0200 X-Authenticated: #29516787 Message-ID: <44C8DD62.7090806@gmx.net> Date: Thu, 27 Jul 2006 17:36:02 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton References: <37E9EDFD-EA9E-40A3-8885-996A8558958D@hxr.us> In-Reply-To: <37E9EDFD-EA9E-40A3-8885-996A8558958D@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF SIP List , GEOPRIV Subject: [Sip] Re: [Geopriv] teasing apart: http as a GEOPRIV using protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Andy, if we talk about location-by-reference then I think all solutions need more specification work. If we talk about end host adding a reference then we need to have a story about the source of the reference. This is subject to the current Geopriv-L7 DT work that is not yet finished. If we are talking about the case where the SIP proxy adds a reference (no matter what type of reference it is) then also further work is needed. I think we should develop an HTTP based solution since it is very simple. Btw, I am not sure that the name 'using protocol' is actually appropriate in this case. We haven't used the term using protocol for the Geopriv L7 work either. Terminology is hell in this area. Ciao Hannes Andrew Newton wrote: > There have been a number of opinions regarding HTTP as a using protocol. > > I'd like to know, how many people believe that HTTP requires no or very > little specification to meet the requirements in RFC 3693 and RFC > 3694. If you believe this, what basis do you have for this > conclusion? Or do you believe more specification needs to be done, but > it is possible for HTTP to be a GEOPRIV using protocol? > > Finally, how many people believe that HTTP should not be a using protocol? > > -andy > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 12:19:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68YT-0000bQ-Qz; Thu, 27 Jul 2006 12:17:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68YR-0000b6-Un; Thu, 27 Jul 2006 12:17:43 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G68YR-0005Hi-FT; Thu, 27 Jul 2006 12:17:43 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G68YF-0006rm-MW; Thu, 27 Jul 2006 11:17:32 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Thu, 27 Jul 2006 12:17:30 -0400 Message-ID: <002301c6b198$2c0861d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acaxia0ijw1xbrCAQwOZM6wYMycbxAADfMQg In-Reply-To: <44C8CEBD.2030108@gmx.net> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: sip@ietf.org, geopriv@ietf.org, "'Abbott, Nadine B'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Either. I object to HTTP because there is no RFC I can reference that describes an HTTP based geopriv using protocol. I prefer SIP/SIPS/PRES because I can. I don't think sip-location-conveyance should define an HTTP based geopriv using protocol. I don't object to a separate document that defines one. I expect to see the L7 protocol do that, for example. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, July 27, 2006 10:34 AM > To: Brian Rosen > Cc: 'Abbott, Nadine B'; sip@ietf.org; geopriv@ietf.org > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- > conveyance > > Hi Brian, > > are you talking about the end host adding a location-by-reference into > the SIP header or a proxy doing so? > > In any case I don't understand your objection against the usage of HTTP > and your preference for SIP/SIPS/PREZ? > > Ciao > Hannes > > Brian Rosen wrote: > > Nadine > > > > Are you saying that it's your opinion sip-location-conveyance MUST > > define an HTTP dereference procedure? > > > > If you do, why? What is the use-case or requirement? > > > > Would it not be pretty reasonable to require a separate document that > > defines a location-by-reference mechanism, protocol, and geopriv > > "using protocol" analysis? If that document specifically extended > > what was allowed in the location header, would that not be > > reasonable? > > > > I think we have to include "A" dereference mechanism in the > > location-conveyance document. It seems just including sip/sips/prez > > is a reasonable, all-sip-all-the-time approach IN THIS DOCUMENT. > > That certainly does not preclude another document describing another > > way. > > > > Doesn't it seem just a little weird to have a sip-location-conveyance > > document describing any kind of http based location conveyance > > (de-reference) protocol, especially one created whole cloth without > > any other parts? > > > > Doesn't it seem in keeping with the geopriv approach that in order to > > have another "using protocol" it has to have a geopriv review? That > > is what leads to restricting the URI schemes. Would you prefer to > > let it be wide open, so any protocol anyone thinks about can be used > > with the location header? I can't see geopriv going along with that. > > We're going to make it a one line ABNF to add a new scheme to the > > list of allowed schemes. > > > > It seems to me that if it's desired to define some bare-bones HTTP > > location by reference protocol, then that should be a separate > > document, which can easily extend the allowable schemes in the > > Location header. I'm not sure it might be better to define ALL of > > that in the L7 protocol, but I wouldn't be opposed to a simple "raw > > GET" RFC as long as it got a full geopriv review. I just don't see > > where it makes any sense to force that into a sip document. > > > > Brian > > > > > >> -----Original Message----- From: Abbott, Nadine B > >> [mailto:nabbott@telcordia.com] Sent: Wednesday, July 26, 2006 2:14 > >> PM To: sip@ietf.org Cc: geopriv@ietf.org Subject: RE: [Geopriv] > >> Consensus on changes to location-conveyance > >> > >> > >> I don't agree that there is a consensus to preclude the use of > >> HTTP. I would favor not placing your proposed restriction on the > >> URI scheme for expressing a location reference in the SIP location > >> conveyance draft; or at least including HTTP as a valid > >> location-reference URI type. > >> > >> Regards, Nadine Abbott > >> > >> -----Original Message----- From: Rosen, Brian > >> [mailto:Brian.Rosen@neustar.biz] Sent: Tuesday, July 25, 2006 1:38 > >> PM To: sip@ietf.org Cc: geopriv@ietf.org Subject: [Geopriv] > >> Consensus on changes to location-conveyance > >> > >> I have put out a number of emails on proposed changes to location > >> conveyance. Some of them have sparked a number of comments. My > >> summary of consensus on these issues is: > >> > >> 1. We proposed to explicitly disallow use of a Data URI, which > >> would allow specification of a Location-by-value in a header. > >> There was a lot of list traffic on this, currently in the state > >> where Keith asked for a real use case for it. So far, we don't see > >> a use case that cannot be provided by location-by-reference in a > >> header. If we don't get a good use case, I think consensus is to > >> disallow location-by-value in a header. > >> > >> 2. Dereferencing location-by-reference. We had initially proposed > >> to document a process to use a raw HTTP(S) Get to dereference. > >> There was a lot of discussion, and then I made a new proposal, see > >> item 6. > >> > >> 3. We proposed to allow a Reason header with a 424 Bad Location > >> response. This seems to be acceptable to the WG. Geopriv will > >> create and populate the registry in a separate draft. > >> > >> 4. We proposed to explicitly allow hop-by-hop TLS security for > >> location when the endpoint wished to allow routing based on > >> location. We further proposed to interpret "Do not Distribute" > >> flags as allowing sending of the location to the routing database > >> (LoST for example). Hannes pointed out that there was a proposal > >> to allow two Location headers, one of which could be used for > >> routing and another for onward forwarding to the recipient. > >> Hannes' message seemed to agree that "Do not distribute" would > >> allow sending of the location to the routing-by-location database, > >> but would obligate the proxy that did that to remove the location > >> before it forwarded the message. There were no other messages on > >> this thread. We conclude that allowing hop-by-hop security for > >> location based routing is acceptable, and Do Not Distribute DOES > >> allow forwarding to a routing database, but requires that the proxy > >> doing the location based route to remove the location it uses for > >> that purpose. > >> > >> 5. We proposed to create a parameter and a registry to distinguish > >> multiple ways to dereference a location where HTTP(S) was the > >> transport. Resolution of this issue depends on resolution of issue > >> 6. > >> > >> 6. We proposed to allow sip/sips and pres: in the location header. > >> I later speculated that if we allow this, it forms a simple way to > >> do location-by-reference, and we could eliminate the raw HTTP(S) > >> Get proposal, with the parameter and registry entirely. There was > >> some list traffic in favor of this. Martin Thompson is skeptical > >> that SIP Presence Subscribe/Notify is actually allowed as a geopriv > >> "using protocol". Several of think that it is. If we don't get > >> any more comments on this proposal, we will allow sip/sips and > >> pres, not have any http(s) resolution text, and not propose a > >> parameter and accompanying registry. > >> > >> If this does not reflect your position, please speak up now. > >> > >> Brian > >> > >> _______________________________________________ Geopriv mailing > >> list Geopriv@ietf.org > >> https://www1.ietf.org/mailman/listinfo/geopriv > >> > >> _______________________________________________ Geopriv mailing > >> list Geopriv@ietf.org > >> https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > _______________________________________________ Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > > development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 13:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69QJ-0000mH-Nm; Thu, 27 Jul 2006 13:13:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69QH-0000ln-VZ; Thu, 27 Jul 2006 13:13:21 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G69QF-0001N1-ET; Thu, 27 Jul 2006 13:13:21 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k6RHD9Cv004613; Thu, 27 Jul 2006 12:13:09 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 12:13:09 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 19:12:50 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 27 Jul 2006 19:12:49 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180195057@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] teasing apart: http as a GEOPRIV using protocol Thread-Index: Acaxkm2bEBBYuhtiSFagoOMzIBL7FQAB2B1w From: "Drage, Keith \(Keith\)" To: "Hannes Tschofenig" , "Andrew Newton" X-OriginalArrivalTime: 27 Jul 2006 17:12:50.0547 (UTC) FILETIME=[E3BE8C30:01C6B19F] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: IETF SIP List , GEOPRIV Subject: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As individual) At the moment I'm afraid I don't buy the argument. Starting from RFC 3693, section 3 defines: Using Protocol: A protocol that carries a Location Object. For which we also have: Location Object (LO): An object conveying location information (and possibly privacy rules) to which Geopriv security mechanisms and privacy rules are to be applied. Section 4 defines the primary GEOPRIV entities and=20 this defines a model: (Now for SIP location by value, the using protocol is SIP, and the SIP UAC is the location server, and the SIP UAS (or possibly proxy) is the location recipient.) For SIP location by reference, the using protocol is the dereferencing protocol, i.e. the reader of the Location header is the location recipient, and the server referenced by the URI is the location server. The SIP protocol is this case is not a using protocol, because it does not contain a location object. Therefore it falls outside the rules of using protocols specified by GEOPRIV. I see nothing in RFC 3693 that prevents a third party entity holding location on behalf of a user, and in fact some of the examples seem to show exactly that. Now presumably all the security and privacy constraints relating to the user are covered by the using protocol. The fact that I tell you that X has my location doesn't mean you are entitled to receive it. Further, while there may be some other protocol (or bilateral agreement or whatever) that covers the relationship between X and the user, I do not see any requirement in RFC 3963 that mandates that. At the moment you seem to be arguing that information about who has my location is subject to some form of consent framework over and above that required by the using protocol itself. I'm afraid I do not see that argument at all. Agreed the URI of the server may say something about the user's location, but to me this is covered by the following statement in RFC 3693: Excluded from this definition is the determination of location information wholly without the knowledge or consent of the Target (or the Target's network or access service provider), based on generally available information such as an IP or e-mail address. In some cases, information like IP address can enable someone to estimate (at least roughly) a location. Commercial services exist that provide rough location information based on IP addresses. Currently, this type of location information is typically less precise than the type of location information addressed in this document. Although this type of location computation still raises significant potential privacy and public privacy concerns, such scenarios are generally outside the scope of this document. We have specified lots of things in SIP and many other protocols that need lots more rules if this is going to become an issue. Furthermore, if I follow your argument to its logical conclusion, then I would seem to need lots more work before I can put a URI that points at a location server in an ordinary email, yet I seem to be able to do that today. So in conclusion, I see location by reference as two independent protocols: - a location using protocol which is the deferencing protocol, and which obviously has to meet the using protocol requirements. - a URI carried by SIP which is subject to no normative constraints about who can read or whatever, which identifies the location server. I agree that there may be arguments for giving more information to the location recipient so that the location recipient knows how to populate the dereferencing protocol. Some of this may however already be covered by other SIP protocol work, and to me is not directly necessary to make the protocol work. If we agree any information in time, we can include it, otherwise it can be added at a later stage.=20 Regards Keith > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 27 July 2006 16:36 > To: Andrew Newton > Cc: IETF SIP List; GEOPRIV > Subject: Re: [Geopriv] teasing apart: http as a GEOPRIV using protocol >=20 > Hi Andy, >=20 > if we talk about location-by-reference then I think all=20 > solutions need more specification work. >=20 > If we talk about end host adding a reference then we need to=20 > have a story about the source of the reference. This is=20 > subject to the current > Geopriv-L7 DT work that is not yet finished. >=20 > If we are talking about the case where the SIP proxy adds a=20 > reference (no matter what type of reference it is) then also=20 > further work is needed. >=20 > I think we should develop an HTTP based solution since it is=20 > very simple. >=20 > Btw, I am not sure that the name 'using protocol' is actually=20 > appropriate in this case. We haven't used the term using=20 > protocol for the Geopriv L7 work either. Terminology is hell=20 > in this area. >=20 > Ciao > Hannes >=20 > Andrew Newton wrote: > > There have been a number of opinions regarding HTTP as a=20 > using protocol. > >=20 > > I'd like to know, how many people believe that HTTP requires no or =20 > > very little specification to meet the requirements in RFC 3693 and =20 > > RFC 3694. If you believe this, what basis do you have for this=20 > > conclusion? Or do you believe more specification needs to=20 > be done, =20 > > but it is possible for HTTP to be a GEOPRIV using protocol? > >=20 > > Finally, how many people believe that HTTP should not be a=20 > using protocol? > >=20 > > -andy > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 > >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 13:27:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69cS-0002O7-1F; Thu, 27 Jul 2006 13:25:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69cP-0002Ja-ML; Thu, 27 Jul 2006 13:25:53 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G69cO-0002uG-Eg; Thu, 27 Jul 2006 13:25:53 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 27 Jul 2006 13:26:01 -0400 id 0158819D.44C8F729.000076F6 Message-ID: <44C8F716.3030401@hxr.us> Date: Thu, 27 Jul 2006 13:25:42 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Geopriv] Re: [Sip] teasing apart: http as a GEOPRIV using protocol References: <04d501c6b180$6e39f4a0$640fa8c0@cis.neustar.com> <7A8FBA4E-DD34-4C89-80B6-BE2913101258@cs.columbia.edu> <44C8DD67.6090908@gmx.net> In-Reply-To: <44C8DD67.6090908@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: IETF SIP List , GEOPRIV , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline... Hannes Tschofenig wrote: > Hi Henning, > > here is the reason why I think we are not talking about a 'using > protocol' here: All we want is to perform dereferencing. Since the place where the reference is made also includes an identity, it is very easy to get the location of a user... and hence the line is crossed with regard to privacy. > We don't want something that does all the fancy features of a presence > solution. So why did GEOPRIV use PIDF as its basis? Has as been quoted on this list recently, 4119 does not require the use of presence solution, but presence solutions were very much a target platform. > I am not even sure where the privacy rules should come from. In the > Geopriv L7 discussion we had at least a proposal that some of us didn't > like (namely the end host provides the privacy rules to the LIS). I > haven't seen such a proposal here. An L7-LCP does not have to be a using protocol primarily because the usage is for a much narrower purpose. It can be a GEOPRIV using protocol, but I believe one of the complaints against HELD (which attempted to be an L7-LCP and GEOPRIV using protocol) is that it was doing too much. > Here is my question (I raised it already with my scenario list): Where > does the SIP proxy get the information to construct a PIDF-LO? > > * We assume that it gets the location information somehow. Not further > specified and might depend on the deployment environment. > > * What is the "entity" attribute of the 'presence' element? > > * Where does the content for the usage-rules (e.g, > 'retransmission-allowed', 'retention-expires', 'ruleset-reference', > 'note-well') come from? It is possible that a network operator does have enough information to formulate a PIDF-LO, at least what is necessary for emergencies. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 13:31:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69ff-0004ip-6E; Thu, 27 Jul 2006 13:29:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69fd-0004gp-AC for sip@ietf.org; Thu, 27 Jul 2006 13:29:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G69fd-00038h-8O for sip@ietf.org; Thu, 27 Jul 2006 13:29:13 -0400 Received: from jes-fe1.zx.nl ([194.187.76.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G69fZ-0000ap-Oo for sip@ietf.org; Thu, 27 Jul 2006 13:29:13 -0400 Received: from Inbox ([84.241.195.14]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J3200C43R4MGU30@jes-fe1.zx.nl> for sip@ietf.org; Thu, 27 Jul 2006 19:24:32 +0100 (WEST) Date: Thu, 27 Jul 2006 19:29:34 +0200 From: Jeroen Van Bemmel To: rjsparks@estacado.net Message-id: <0J3200C45R4PGU30@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: -1.5 (-) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org Subject: [Sip] RFC4320 and 408 to non-INVITE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Robert, RFC4320 bans 408 responses to NIT, but I think there are situations in whic= h it is still useful and needed. In particular, consider when the UAC is us= ing T1=3D2000 and the proxy uses T1=3D500 (eg because the client is on a sl= ow wireless link) The CT at the proxy times out after 64*T1=3D32 sec, while the client is sti= ll retransmitting. In this case, 408 does help Regards, Jeroen= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 13:38:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69my-00028S-Dm; Thu, 27 Jul 2006 13:36:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67AI-0000jo-RQ; Thu, 27 Jul 2006 10:48:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G67AI-0002ES-OY; Thu, 27 Jul 2006 10:48:42 -0400 Received: from adsl-65-67-130-186.911.org ([65.67.130.186] helo=911.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G676d-00056K-HM; Thu, 27 Jul 2006 10:44:57 -0400 X-SEF-Processed: 5_0_0_816__2006_07_27_09_46_03 Received: from Unknown [192.168.6.230] by mail1.911.org - SurfControl E-mail Filter (5.0.1); Thu, 27 Jul 2006 09:46:03 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 27 Jul 2006 09:44:46 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Henning's Suggestion thread-index: AcaxidNwoqBTFSOKRYG4BlBoXtIR0AAAQ9Gw From: "Marc Berryman" To: "Hannes Tschofenig" , "Dawson, Martin" X-Spam-Score: -0.6 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 X-Mailman-Approved-At: Thu, 27 Jul 2006 13:36:47 -0400 Cc: IETF SIP List , geopriv@ietf.org, Henning Schulzrinne Subject: [Sip] RE: [Geopriv] Henning's Suggestion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sounds like Hannes and Henning are moving down the right track. Focusing on the location header syntax for the draft. Marc B -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Thursday, July 27, 2006 9:35 AM To: Dawson, Martin Cc: IETF SIP List; geopriv@ietf.org; Henning Schulzrinne Subject: [Geopriv] Henning's Suggestion Hi Henning, I like your suggestion. In fact I would even go a step further. The SIP Location Conveyance=20 document just defines a mechanism to carry a PIDF-LO in the body of the=20 SIP message. Done. Adding location-by-reference to the SIP header by the end host sounds OK but there are still some loose ends where this reference comes from. The other stuff can be dealt with once we concluded our Geopriv-L7 work=20 where all the architectural pieces should are created. The=20 subscription-URI is an example where we recently proposed something and=20 haven't finished our technical discussions. I think the draft got fuzzy when it came to the area where a SIP proxy=20 adds a location-by-reference. I must admit that I proposed to add=20 location-by-value into the SIP header as well but in the meanwhile I=20 don't think that any of the SIP proxy stories belong in there. Ciao Hannes >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Thursday, 27 July 2006 1:25 PM >>To: Brian Rosen >>Cc: IETF SIP List; geopriv@ietf.org >>Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- >>conveyance >> >>My suggestion would be >> >>- to focus the draft on just defining the Location header syntax, >>without ruling out any particular mechanism or scheme; this would >>make the draft really short (which I would find helpful). >> >>- and then add one section to the draft that prototypically defines >>what a particular scheme that wants to appear in the Location header >>needs to define, using the non-controversial cid mechanism as the >>example. Other, separate, drafts can then define other modes, >>following the same template. Documents such as the phone-bcp can then >>pick some suitable must-implement subset and make emergency-call- >>specific recommendations, rather than sprinkling these throughout the >>conveyance document and repeating some in the phone-bcp. Most of >>these are, in any event, operational recommendations, not for >>ensuring protocol-level interoperability. >> >>That way, the conveyance draft can be extremely short (even shorter >>if the requirements are omitted...) and can get done, and we avoid >>engineering operational requirements on the fly, commingling >>emergency and non-emergency cases, as seems to be happening now. >> >>I think protocol documents should define what's needed for >>interoperability; BCPs can make more specific, situation-specific >>recommendations. Commingling the two seems to be a recipe for >>deadlock or arbitrary, non-technically-grounded decisions that are >>more lawyer-like than engineering-like ("you did not mention >>technique X in some meeting N years ago and thus you can't bring it >>up now!") >> >>Henning >> >>On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote: >> >> >>>At this point, I think we need some chair guidance and by that I >>>think it's >>>a combo of geopriv and sip chairs. >>> >>>We seem to have a couple of significant open questions. I think >>>most of the >>>other stuff (like the "allow sending to router") will converge. >>> >>>There seems to be some opposition to allowing sip/sips/pres: in a >>>Location >>>Header. The opposition seems to be that despite 4119, somehow, SIP >>>(presence subscription) is not a "using protocol". I "think" a >>>ruling from >>>the bench on that would work. >>> >>>There is also opposition to defining the allowed schemes as a >>>specific list, >>>with a defined (easy) extension mechanism. >>> >>>Related to that, there are some who want location-conveyance to >>>define an >>>HTTP based location dereference mechanism, and on the opposite end, >>>we have >>>people saying we haven't even agreed to support any form of >>>location-by-reference. >>> >>>The authors would like to know what to do now. >>> >>>Brian >>> >>> >>>>-----Original Message----- >>>>From: Andrew Newton [mailto:andy@hxr.us] >>>>Sent: Wednesday, July 26, 2006 9:58 PM >>>>To: Winterbottom, James >>>>Cc: sip@ietf.org; geopriv@ietf.org; Abbott, Nadine B; Henning >>>>Schulzrinne >>>>Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- >>>>conveyance >>>> >>>> >>>>On Jul 26, 2006, at 9:43 PM, Winterbottom, James wrote: >>>> >>>> >>>>>Andy, >>>>> >>>>>RFC-4119 says "However, the usage of this location object format >=20 > is >=20 >>>>>not >>>>> limited to presence-using protocols-- any protocol that can >>>>>carry XML >>>>> or MIME types can carry PIDF." >>>>> >>>>>It seems to me that restricting the allowed schema in what is >>>>>supposed >>>>>to be a location conveyance specification is in opposition to this >>>>>statement. >>>> >>>>Did somebody say that HTTP was a presence-using protocol? >>>> >>>>-andy >>>> >>>>ps. you can find my location with the following reference URIs: >>>> >>>>gopher://fatchance.hxr.us/you-still-have-a-gopher-client >>>>news:alt.locations.people.secretly-being-watched >>>>telnet://screen-scrapers.are.us/ >>>>dns:cached-publicly-around-the-world.com?type=3DHOST >>>> >>>> >>>> >>>>_______________________________________________ >>>>Geopriv mailing list >>>>Geopriv@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/geopriv >>> >>> >>>_______________________________________________ >>>Geopriv mailing list >>>Geopriv@ietf.org >>>https://www1.ietf.org/mailman/listinfo/geopriv >> >> >>_______________________________________________ >>Geopriv mailing list >>Geopriv@ietf.org >>https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 > ------------------------------------------------------------------------ ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ ------------------------ > [mf2] >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 13:40:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69pF-0003oQ-2s; Thu, 27 Jul 2006 13:39:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69pD-0003ku-PQ for sip@ietf.org; Thu, 27 Jul 2006 13:39:07 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G69pC-0003mU-BS for sip@ietf.org; Thu, 27 Jul 2006 13:39:07 -0400 Received: (qmail invoked by alias); 27 Jul 2006 17:38:58 -0000 Received: from ip-80-226-247-29.vodafone-net.de (EHLO [10.226.174.161]) [80.226.247.29] by mail.gmx.net (mp036) with SMTP; 27 Jul 2006 19:38:58 +0200 X-Authenticated: #29516787 Message-ID: <44C8FA2B.3070301@gmx.net> Date: Thu, 27 Jul 2006 19:38:51 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Geopriv] Re: [Sip] teasing apart: http as a GEOPRIV using protocol References: <04d501c6b180$6e39f4a0$640fa8c0@cis.neustar.com> <7A8FBA4E-DD34-4C89-80B6-BE2913101258@cs.columbia.edu> <44C8DD67.6090908@gmx.net> <44C8F716.3030401@hxr.us> In-Reply-To: <44C8F716.3030401@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: IETF SIP List , GEOPRIV , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Andy, Andrew Newton wrote: > Inline... > > Hannes Tschofenig wrote: > >> Hi Henning, >> >> here is the reason why I think we are not talking about a 'using >> protocol' here: All we want is to perform dereferencing. > > > Since the place where the reference is made also includes an identity, > it is very easy to get the location of a user... and hence the line is > crossed with regard to privacy. What identity is used where? > >> We don't want something that does all the fancy features of a presence >> solution. > > > So why did GEOPRIV use PIDF as its basis? You misunderstood my statement. For dereferencing a location-by-reference (not a subscription URI) we don't need a lot of functionality. Has as been quoted on this > list recently, 4119 does not require the use of presence solution, but > presence solutions were very much a target platform. > >> I am not even sure where the privacy rules should come from. In the >> Geopriv L7 discussion we had at least a proposal that some of us >> didn't like (namely the end host provides the privacy rules to the >> LIS). I haven't seen such a proposal here. > > > An L7-LCP does not have to be a using protocol primarily because the > usage is for a much narrower purpose. It can be a GEOPRIV using > protocol, but I believe one of the complaints against HELD (which > attempted to be an L7-LCP and GEOPRIV using protocol) is that it was > doing too much. I like to discuss about requirements and functionality rather than terminology. I think that statements like "has to be a using protocol" help to make a lot of progress. That's my only objection. I am the last one to say that we do not need to deal with privacy aspects. > >> Here is my question (I raised it already with my scenario list): Where >> does the SIP proxy get the information to construct a PIDF-LO? >> >> * We assume that it gets the location information somehow. Not further >> specified and might depend on the deployment environment. >> >> * What is the "entity" attribute of the 'presence' element? >> >> * Where does the content for the usage-rules (e.g, >> 'retransmission-allowed', 'retention-expires', 'ruleset-reference', >> 'note-well') come from? > > > It is possible that a network operator does have enough information to > formulate a PIDF-LO, at least what is necessary for emergencies. Would you be happy with this level of detail? ... and: We are not only focusing on emergency services. Ciao Hannes > > -andy > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 13:48:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69x1-0003T1-Ia; Thu, 27 Jul 2006 13:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69wz-0003Sp-Uc; Thu, 27 Jul 2006 13:47:09 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G69wx-0004cI-M2; Thu, 27 Jul 2006 13:47:09 -0400 Received: from lion.cs.columbia.edu (IDENT:5ipxuXF468gAmS95RxUEyOgbD8vurkE+@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6RHl14F012569 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 27 Jul 2006 13:47:02 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6RHl0rh012935 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Jul 2006 13:47:01 -0400 Message-ID: <44C8FC0F.5070907@cs.columbia.edu> Date: Thu, 27 Jul 2006 13:46:55 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Geopriv] Re: [Sip] teasing apart: http as a GEOPRIV using protocol References: <04d501c6b180$6e39f4a0$640fa8c0@cis.neustar.com> <7A8FBA4E-DD34-4C89-80B6-BE2913101258@cs.columbia.edu> <44C8DD67.6090908@gmx.net> <44C8F716.3030401@hxr.us> In-Reply-To: <44C8F716.3030401@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.27.102933 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org With hindsight, I think the term 'using protocol' has been the source of more word-lawyering than engineering insight. I personally find the distinctions - first person vs. third person (i.e., find out location about myself vs. find out location about some third party) - location vs. location + identity - token-based authorization vs. identity-based authorization more helpful. Token-based authorization hands the recipient a key that allows him to get a location object, without caring as to who is retrieving the object. ("Anybody seeing this SIP request can convert the token into an LO.") Identity-based naturally uses some authenticated identity to release that information. Strictly speaking, this is only a question of a level of indirection, since proving identity usually involves proving possession of a secret. We've been trying to get at some of these distinctions with the sighting vs. using protocol terminology, but that distinction also seems to degenerate into discussions more suited for a law school or theology department than an engineering organization. For example, by strict definition, LoST would be a 'Using Protocol' since it "carries a Location Object", but I hope we all agree that this is silly. We had earlier agreed that the location-by-DHCP also were not Using Protocol, even though they obviously carry a location object of some form. Privacy issues apply iff - third person - location + identity (not just location) The L7 discussion was about 'first person' and 'location only' (although the latter is subject to debate, depending on whether one considers an IP address of identifying an individual or not). Depending on the circumstances, SIP-based retrieval can either involve privacy concerns (subscribe to alice@example.com) or not (subscribe to location of one-time random unlinkable identifier jdfa8f9348@example.com). There can also be different privacy concerns depending on the perspective. For example, if a SIP request contains both an identity and the location retrieval reference, this raises privacy concerns for the proxy, but the LIS may not have any such concerns since it may only be the repository of these randomly-named objects, without tie to an identity. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 13:54:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6A2T-00088M-NO; Thu, 27 Jul 2006 13:52:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6A2R-00080i-Oi for sip@ietf.org; Thu, 27 Jul 2006 13:52:47 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6A2Q-0005On-D2 for sip@ietf.org; Thu, 27 Jul 2006 13:52:47 -0400 Received: from [172.17.2.252] ([172.17.2.252]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6RHpUkw041404 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Jul 2006 12:51:30 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <0J3200C45R4PGU30@jes-fe1.zx.nl> References: <0J3200C45R4PGU30@jes-fe1.zx.nl> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Thu, 27 Jul 2006 12:51:28 -0500 To: Jeroen Van Bemmel X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org Subject: [Sip] Re: RFC4320 and 408 to non-INVITE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is not the way the timers are meant to be changed. Both of the transaction-stateful things on either end of a given transaction must share the same values for the transaction timers or the results are not defined. What you describe is not unlike throwing away the timing belt in an engine and spinning the head at some rate unrelated to the crankshaft. You might get lucky, but usually very bad things are going to happen. RjS On Jul 27, 2006, at 12:29 PM, Jeroen Van Bemmel wrote: > Robert, > > RFC4320 bans 408 responses to NIT, but I think there are situations > in which it is still useful and needed. In particular, consider > when the UAC is using T1=2000 and the proxy uses T1=500 (eg because > the client is on a slow wireless link) > > The CT at the proxy times out after 64*T1=32 sec, while the client > is still retransmitting. In this case, 408 does help > > Regards, > Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 13:56:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6A4M-00028k-50; Thu, 27 Jul 2006 13:54:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6A4J-00028I-P6; Thu, 27 Jul 2006 13:54:43 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6A4H-0005W4-8m; Thu, 27 Jul 2006 13:54:43 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G6A48-00065M-Ea; Thu, 27 Jul 2006 12:54:33 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Thu, 27 Jul 2006 13:54:33 -0400 Message-ID: <004201c6b1a5$ba31e4b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaxicRhhTyVVFuORxK4xdt//Gu3swADuBwg In-Reply-To: <44C8CEDF.3010502@gmx.net> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: geopriv@ietf.org, "Peterson, Jon" , sip@ietf.org, 'Marc Linsner' , "Rosen, Brian" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > I don't really understand why you think location by reference is so much > of > > a concern. > > It is interesting that you say that. In the Geopriv L7 design team you > are the only person that wants to see an applicability statement being > written. We haven't gotten to that yet, but it's a problem of proxy assertion, not location-by-reference. Basically, coming up with an identifier to determine what location to assert (by value or by reference) is much worse than the L7 case, because the SIP signaling plane definitely is subject to being carried over VPNs and other IP address obscuring things. You can't possibly use the IP address as the identifier. You have to use something else. What else? I have no idea. I can imagine some kinds of wireless systems being able to know that the device is on their own network, and have some id that works on that network. In case I have not been clear enough, I personally DO NOT LIKE proxy assertion of location. I do not really like location by reference, although a SIP presence URI is location-by-reference no matter how you slice and dice it. However, I consider both to be requirements in location-conveyance, and think limiting proxy insertion to be by reference only to be the least objectionable answer. > > Having a SIP proxy adding something (either location-by-value or > location-by-reference) is not different to the stuff we discuss in the > design team. There, you see a lot of privacy, security, etc. problems. > Here you don't. How come? I see plenty of problems, but in a protocol sense I don't think anything is different other than this identifier problem. > > If you go through my mail with the large number of scenarios then you > find a number of open issues that need to be answered. Alternatively, > you can also go through draft-tschofenig-geopriv-l7-lcp-ps-00.txt > > If you look at the discussion in context, PIDF-LO defines > > location as part of presence. All of these concerns are relevant there, > and > > I think they have been adequately covered there. We even have some work > on > > anonymization of the identity (and thus of the URI) in presence. > Generally, > > a presence uri: > > > > Is not valid for a limited amount of time > > Is not hard to guess, if it uses an AoR and could be with anonymous URI. > > Identifies the user if it uses an AoR and doesn't with anonymous URI > > > > The protocol (SIP) for retrieving presence, and thus location has the > > location ruleset as we defined for PIDF-LO, but otherwise does not have > "no > > cache" semantics (albeit caching headers is not very interesting in > SIP). > > You cannot compare presence witht he location-by-reference solution > since the deployment case is different. I believe this to be false on its face. If I give you a sip URI and tell you a presence server will respond to it including location, then you can exchange the URI for location, and that is location-by-reference. You cannot put that cat back in the bag. A presence URI that reports location in the PIDF results in location-by-reference. The idea that you could have a presence URI where the only information returned in the PIDF that was interesting was location does not need an RFC. It's obvious, it's allowed, and the anonymized user stuff was created for this purpose. Presence is location by reference (it can be identification-by-reference, it can be happiness-by-reference). You have a URI, you exchange it for a PIDF. You are done, stop arguing. > > > > > Generally, presence systems do have user control of who is allowed to > access > > information, including location and identifying information, so I think > that > > is covered fairly well. > > Not true in this case. > > Here we have a SIP proxy in the access network doing all the work. You > can compare it with a SIP-based LIS from the Geopriv-L7 work. This node > has no clue about your privacy preferrences and does not know your > identity. This is what we discussed in the past and several proposals > where made, namely: > > * end host provides privacy preferences (see HELD) > * end host does not provide privacy preferences since there is no > PIDF-LO (see RELO). I don't agree. A proxy can assert a presence URI in a number of places. I'm pretty sure, for example, that many carriers intend the P-A-I to be a presence URI, or (if a tel uri) convertible trivially to a presence URI. I don't like it, but whether a proxy asserts your presence URI or your endpoint does, there is no functional difference. I worry about the issue of whether the proxy's URI resolves to a PIDF that has the policies you want asserted. But that is not a protocol issue. That is a contract and local law issue. The URI and the PIDF have the same capacity to express the users wishes with respect to identity, location and all the other parts of the PIDF. Your carrier's outgoing proxy is perfectly capable of asserting a presence URI that resolves to a PIDF that represents your policies on your location. I prefer the endpoint to be the one doing this, because I think there is a better chance it will get it done right, but that's a pretty soft thing, having nothing to do with protocols. The proxy is in the same domain as the user, and is being trusted by the user to correctly handle its calls. Putting his location (via presence) is one of the things it is reasonable to trust the proxy to do. You could look at this a different way. If the network determines the user location, that information belongs to the network. It would be up to the network to tell the user, if it wants to. The user doesn't own the data, even if it represents his location. If I take a picture of you, I own the picture. Some laws may limit what I can do with it, but it's my data. Proxy assertion of location is the network telling someone the data it owns. It's not yours unless the network decides to give it to you, or gives you control over it. Again, laws may limit what it can do with the data. > > > > > Proxy insertion of location, whether by value or by reference has the > threat > > of not being as subject to user control, but I think in every case you > have > > to trust your provider to do as you wish, whether it is your presence > > provider or your location provider independent of your presence > provider, > > and proxy insertion doesn't fundamentally alter that. I worry more > about > > it, but I don't objectively think it's much different. > > In this case you don't really know the provider and it might not be your > provider. Actually, it has to be (or it wouldn't know your location). You have the case of the visited network not being your carrier, but effectively, if you are roaming on their network, they are your carrier of choice. > > > > > Now, if there are other location dereferencing systems, they may need an > > analysis like what you are suggesting, but with respect to SIP Presence, > as > > a form of location by reference, I think we have been over the ground > > sufficiently, and we have RFCs that permit it. Adding restrictions on > the > > Location header, which I propose is useful precisely to allow an > anonymous > > presence uri that does not reveal identity is not so great I think. If > you > > don't allow that, you would kind of have to use an AoR, which may be > > appropriate in some cases, but would not in others. > > The reference might not reveal the identity but what about the identity > in the PIDF-LO. If you argue that there does not need to be one (or it > is a faked one) then I am puzzled why it has been a source of major > confusion in the Geopriv-L7 design team work (and in previous > discussions about the same subject in Geopriv). See above. It's easy to generate a completely random identity. The difficulty in the L7 case is how the endpoint identifies itself to the LIS in order to receive the right location or reference. Proxy insertion has the same problem of how it knows which location to assert. You can't do proxy insertion of location unless you know FOR SURE where the device is. We do need text on that, as above. > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 13:59:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6A7e-0002fM-FA; Thu, 27 Jul 2006 13:58:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6A7c-0002f1-OE; Thu, 27 Jul 2006 13:58:08 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6A7b-0005jv-CB; Thu, 27 Jul 2006 13:58:08 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6RHvwV2000249; Thu, 27 Jul 2006 12:58:00 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 12:57:59 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 19:57:40 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Teasing apart positions (was Re: [Sip] RE: [Geopriv] Consensusonchanges to location-conveyance) Date: Thu, 27 Jul 2006 19:57:39 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918019506B@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Teasing apart positions (was Re: [Sip] RE: [Geopriv] Consensusonchanges to location-conveyance) Thread-Index: AcaxkhhTZHNAqMtcTGeBsG4QPu7+QgAE+j3Q From: "Drage, Keith \(Keith\)" To: "Henning Schulzrinne" X-OriginalArrivalTime: 27 Jul 2006 17:57:40.0165 (UTC) FILETIME=[26E1AF50:01C6B1A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org True, but I haven't yet seen any proposals to do that. That would presumably require two URIs in the Location header or some other means of identifying the two protocols with the same URI. Keith=20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: 27 July 2006 16:34 > To: Drage, Keith (Keith) > Cc: IETF SIP List; GEOPRIV > Subject: Re: Teasing apart positions (was Re: [Sip] RE:=20 > [Geopriv] Consensusonchanges to location-conveyance) >=20 > > ii) if we have more than one option, we either need some means of > > determining that the dereferencer supports the one the=20 > client chooses=20 > > to use, or require support of all options. As we seem to be lacking=20 > > any mechanism for the former, then it would imply that all options=20 > > have to be supported at the dereferencer, and therefore=20 > that the list=20 > > needs to be a small list. >=20 > This isn't quite true. It is quite possible to include=20 > multiple options, as long as one of them is universally=20 > supported. For example, you can support a "universal & slow"=20 > and a "sometimes & fast" solution, and everybody wins. >=20 > This approach is not new: MIME email does exactly that, where=20 > messages with HTML or rich text often also contain an=20 > alternate plain text rendering. >=20 > Henning >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 14:04:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ABf-0003pR-S6; Thu, 27 Jul 2006 14:02:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ABd-0003hg-SD for sip@ietf.org; Thu, 27 Jul 2006 14:02:17 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6ABd-0005yf-6Z for sip@ietf.org; Thu, 27 Jul 2006 14:02:17 -0400 Received: (qmail invoked by alias); 27 Jul 2006 18:02:08 -0000 Received: from ip-80-226-247-29.vodafone-net.de (EHLO [10.226.174.161]) [80.226.247.29] by mail.gmx.net (mp006) with SMTP; 27 Jul 2006 20:02:08 +0200 X-Authenticated: #29516787 Message-ID: <44C8FF96.2070104@gmx.net> Date: Thu, 27 Jul 2006 20:01:58 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" References: <5D1A7985295922448D5550C94DE29180195057@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180195057@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: IETF SIP List , GEOPRIV Subject: [Sip] Re: [Geopriv] teasing apart: http as a GEOPRIV using protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Keith, please find my response below: Drage, Keith (Keith) wrote: > (As individual) > > At the moment I'm afraid I don't buy the argument. > > Starting from RFC 3693, section 3 defines: > > Using Protocol: A protocol that carries a Location Object. > > For which we also have: > > Location Object (LO): An object conveying location information > (and possibly privacy rules) to which Geopriv security > mechanisms and privacy rules are to be applied. > > Section 4 defines the primary GEOPRIV entities and > this defines a model: > > (Now for SIP location by value, the using protocol is SIP, and the SIP > UAC is the location server, and the SIP UAS (or possibly proxy) is the > location recipient.) > > For SIP location by reference, the using protocol is the dereferencing > protocol, i.e. the reader of the Location header is the location > recipient, and the server referenced by the URI is the location server. > The SIP protocol is this case is not a using protocol, because it does > not contain a location object. Therefore it falls outside the rules of > using protocols specified by GEOPRIV. The problem is that this document was written some time ago. We haven't thought about many things at that time. Hence, it is fine to say that it has to be a using protocol but what does this tell us exactly? Nothing since we have to worry about privacy/security aspects with every document we develop. The entire mailing list thread started with a few security related questions that Henning and myself raised. I do not recall that we made progress with any of these security questions. Instead we go along the road of terminology discussions. > > I see nothing in RFC 3693 that prevents a third party entity holding > location on behalf of a user, and in fact some of the examples seem to > show exactly that. That's explicitly supported. > > Now presumably all the security and privacy constraints relating to the > user are covered by the using protocol. The fact that I tell you that X > has my location doesn't mean you are entitled to receive it. Further, > while there may be some other protocol (or bilateral agreement or > whatever) that covers the relationship between X and the user, I do not > see any requirement in RFC 3963 that mandates that. I believe that security is part of the architecture and in this case several protocols play together. I don't want to get the security work being pushed to the HTTP using protocol. > > At the moment you seem to be arguing that information about who has my > location is subject to some form of consent framework over and above > that required by the using protocol itself. I'm afraid I do not see that > argument at all. Agreed the URI of the server may say something about > the user's location, but to me this is covered by the following > statement in RFC 3693: I don't think I said that. > > Excluded from this definition is the determination of location > information wholly without the knowledge or consent of the Target (or > the Target's network or access service provider), based on generally > available information such as an IP or e-mail address. In some > cases, information like IP address can enable someone to estimate (at > least roughly) a location. Commercial services exist that provide > rough location information based on IP addresses. Currently, this > type of location information is typically less precise than the type > of location information addressed in this document. Although this > type of location computation still raises significant potential > privacy and public privacy concerns, such scenarios are generally > outside the scope of this document. > > We have specified lots of things in SIP and many other protocols that > need lots more rules if this is going to become an issue. > > Furthermore, if I follow your argument to its logical conclusion, then I > would seem to need lots more work before I can put a URI that points at > a location server in an ordinary email, yet I seem to be able to do that > today. If I just put a location server URI into the mail then there is still the question how you would obtain my location information. If my email address is used for this purpose then you would have just created a very nice privacy leaking system. Everyone that knows the location server and my email address could learn my location. Furthermore, mail relays would be able to see that information and could happily use it. Btw, you can also put location information into a mail today and without signing and privacy rules it would be bad as well. > > So in conclusion, I see location by reference as two independent > protocols: > > - a location using protocol which is the deferencing protocol, and > which obviously has to meet the using protocol requirements. > > - a URI carried by SIP which is subject to no normative > constraints about who can read or whatever, which identifies the > location server. I would particuarly like to make anyone aware that these are not just two independent protocols. I strongly believe that you can make the security/privacy independent for each of them. You have to consider the big picture. We do this all the time. Take for example, the SAML work. Two "independent things": SAML and SIP Still, there are many aspects to consider. The SAML community calls these interworking between two (or more protocols) 'profile'. What we do here is essentially the same. A recent comment that the end host should indicate whether it wants the SIP proxy to add something is also a topic for SIP-SAML. If an entity acts on behalf of the end host then it needs to be aware of the context this entity is in (Henning would call it sphere). > I agree that there may be arguments for giving more information to the > location recipient so that the location recipient knows how to populate > the dereferencing protocol. Some of this may however already be covered > by other SIP protocol work, and to me is not directly necessary to make > the protocol work. If we agree any information in time, we can include > it, otherwise it can be added at a later stage. Ciao Hannes > > > Regards > > Keith > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: 27 July 2006 16:36 >>To: Andrew Newton >>Cc: IETF SIP List; GEOPRIV >>Subject: Re: [Geopriv] teasing apart: http as a GEOPRIV using protocol >> >>Hi Andy, >> >>if we talk about location-by-reference then I think all >>solutions need more specification work. >> >>If we talk about end host adding a reference then we need to >>have a story about the source of the reference. This is >>subject to the current >>Geopriv-L7 DT work that is not yet finished. >> >>If we are talking about the case where the SIP proxy adds a >>reference (no matter what type of reference it is) then also >>further work is needed. >> >>I think we should develop an HTTP based solution since it is >>very simple. >> >>Btw, I am not sure that the name 'using protocol' is actually >>appropriate in this case. We haven't used the term using >>protocol for the Geopriv L7 work either. Terminology is hell >>in this area. >> >>Ciao >>Hannes >> >>Andrew Newton wrote: >> >>>There have been a number of opinions regarding HTTP as a >> >>using protocol. >> >>>I'd like to know, how many people believe that HTTP requires no or >>>very little specification to meet the requirements in RFC 3693 and >>>RFC 3694. If you believe this, what basis do you have for this >>>conclusion? Or do you believe more specification needs to >> >>be done, >> >>>but it is possible for HTTP to be a GEOPRIV using protocol? >>> >>>Finally, how many people believe that HTTP should not be a >> >>using protocol? >> >>>-andy >>> >>>_______________________________________________ >>>Geopriv mailing list >>>Geopriv@ietf.org >>>https://www1.ietf.org/mailman/listinfo/geopriv >>> >>> >> >> >>_______________________________________________ >>Geopriv mailing list >>Geopriv@ietf.org >>https://www1.ietf.org/mailman/listinfo/geopriv >> > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 14:07:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AEa-0002E7-BN; Thu, 27 Jul 2006 14:05:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AEZ-0002E2-Qi for sip@ietf.org; Thu, 27 Jul 2006 14:05:19 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6AEX-0006jl-FN for sip@ietf.org; Thu, 27 Jul 2006 14:05:19 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6RHwv06032067 for ; Thu, 27 Jul 2006 13:58:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Hitchhikers guide - when is it done? Date: Thu, 27 Jul 2006 21:05:14 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Hitchhikers guide - when is it done? Thread-Index: AcawyNH+hU2m+pDpSRymEf9zkXPaQAA3bcSg From: "Romascanu, Dan \(Dan\)" To: "Jonathan Rosenberg" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I am aware about this. On the other hand, the problem with RFCs is that they tend to be updated at a slow pace. How often will the Hitchhiker Guide be updated? - every two, three years? I am looking at a semi-official solution to be used in-between, maintained at a known well place by a registrar nominated by the SIP WG or RAI Area.=20 Dan =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, July 26, 2006 6:33 PM > To: Romascanu, Dan (Dan) > Cc: IETF SIP List > Subject: Re: [Sip] Hitchhikers guide - when is it done? >=20 > The problem with any kind of website reference is that they=20 > are never 'official'. There are countless web sites=20 > enumerating SIP related documents. What makes something an=20 > official output of the IETF is that its an RFC. >=20 > -Jonathan R. >=20 > Romascanu, Dan (Dan) wrote: >=20 > > Because of the overhead and clerical delays involved in the=20 > > publication of RFCs I would suggest a refinement to option=20 > 2. Provide=20 > > a reference in the RFC to a Web page maintained and=20 > refreshed by the=20 > > SIP WG or the RAI Area including the 'to-the-best-of-our-knowledge'=20 > > updates in-between two versions of the RFC. > >=20 > > Dan > >=20 > >=20 > >=20 > >=20 > > =20 > > =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >>Sent: Tuesday, July 25, 2006 8:56 PM > >>To: IETF SIP List > >>Subject: [Sip] Hitchhikers guide - when is it done? > >> > >>During the IETF meeting, I discussed the one current open=20 > issue in the=20 > >>Hitchhikers guide. The issue is: when does the document=20 > finish? When=20 > >>do we send to IESG to issue an RFC? > >> > >>There were two approaches: > >> > >>1. split the document in two. One part contains only the=20 > core specs,=20 > >>and issues relatively soon. The other part has everything else, and=20 > >>basically ends up being the last RFC produced by the SIP WG=20 > before it=20 > >>shuts its doors (which has always been 1.5 years from now=20 > for the last=20 > >>5 years). > >> > >>2. keep it as one document. Issue an RFC at some point, and then=20 > >>revise it a few times as needed. We need to decide when to issue it. > >> > >> > >>I'd like to propose option 2. I think people get more value=20 > >>from it as a=20 > >>consolidated document. Furthermore, I'd propose that we send the=20 > >>document to IESG for consideration as informational at the=20 > >>instant all=20 > >>of the documents listed as 'core' have RFC numbers issued by RFC-ed. > >> > >>Comments? > >> > >>-Jonathan R. > >>--=20 > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>Cisco Fellow Parsippany, NJ=20 > >>07054-2711 > >>Cisco Systems > >>jdrosen@cisco.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.cisco.com > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 14:08:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AFa-0003kX-JP; Thu, 27 Jul 2006 14:06:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AFY-0003gu-8F; Thu, 27 Jul 2006 14:06:20 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6AFV-0006nJ-Tr; Thu, 27 Jul 2006 14:06:20 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 27 Jul 2006 11:06:17 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RI6HRT002300; Thu, 27 Jul 2006 11:06:17 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6RI6HJi003585; Thu, 27 Jul 2006 11:06:17 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 11:06:16 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 11:06:16 -0700 Message-Id: <4.3.2.7.2.20060727130437.03453ed0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2006 13:06:15 -0500 To: Andrew Newton From: "James M. Polk" Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance In-Reply-To: <50D29DA3-55B4-467A-A24C-AB6C78DCBA5A@hxr.us> References: <4.3.2.7.2.20060726230723.03693008@email.cisco.com> <4.3.2.7.2.20060726222133.03bb4518@email.cisco.com> <4.3.2.7.2.20060726222133.03bb4518@email.cisco.com> <4.3.2.7.2.20060726230723.03693008@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 18:06:16.0580 (UTC) FILETIME=[5AB05C40:01C6B1A7] DKIM-Signature: a=rsa-sha1; q=dns; l=1541; t=1154023577; x=1154887577; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=0A=20= 20location-conveyance; X=v=3Dcisco.com=3B=20h=3D6MjbpL8IiYLdDIsKBDAd+QlIgwA=3D; b=hUwu/P7GxyU0oOTVM37llmJOGnIQe016gcjIkxfsML1KKKwujwaSWQkuB1TjKcJlLQlRMDs9 Ka6vzh8xtYudOj1eQZT/YRi1XmVsCWssgsD4s7Zr+aQ8NNEhCe1p8aEn; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, geopriv@ietf.org, "Abbott, Nadine B" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 08:32 AM 7/27/2006 -0400, Andrew Newton wrote: >On Jul 27, 2006, at 12:08 AM, James M. Polk wrote: > >>At 11:37 PM 7/26/2006 -0400, Andrew Newton wrote: >> >>>On Jul 26, 2006, at 11:27 PM, James M. Polk wrote: >>> >>>>I think Geopriv really needs to look at HTTP as a RFC 3693 "using >>>>protocol" to tease out any unique characteristics with that >>>>protocol. That discussion and review shouldn't bog this document >>>>down. Does this sound fair? >>> >>>Most definitely. We've had discussions on HTTP as a using protocol >>>for 3 years in GEOPRIV, HELD being the latest incarnation. The first >>>proposals ran into serious privacy concerns. Anything that simply >>>says "use HTTP" is an attempt to work around answering the serious >>>privacy concerns raised in GEOPRIV. >> >>is this said with your WG chair hat on? >> >>It sounds pretty definitive to these ears... > >I don't believe working group chairs are given any special powers >that such a decision is in their hands. fair - but Brian asked for WG chair guidance because several points were churning over and over again (perhaps at Layer 8 - Religious), and I was asking if this view could be taken as WG chair guidance? >Any individual participant >can approach an AD or the IESG either informally or via appeal about >attempts to work around working group consensus. Such things are >taken seriously by the IESG, to the point that they can stop the >publication of an RFC sent directly to the RFC Editor on this basis. > >-andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 14:14:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AM5-0007dd-EF; Thu, 27 Jul 2006 14:13:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AM4-0007dV-3p; Thu, 27 Jul 2006 14:13:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6AM1-0007Yv-OF; Thu, 27 Jul 2006 14:13:04 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 27 Jul 2006 11:13:02 -0700 X-IronPort-AV: i="4.07,189,1151910000"; d="scan'208"; a="308543042:sNHT52392862" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RID1Ux021043; Thu, 27 Jul 2006 11:13:01 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6RID0HS017755; Thu, 27 Jul 2006 11:13:00 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jul 2006 11:13:00 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 11:12:57 -0700 Message-Id: <4.3.2.7.2.20060727131155.03961e20@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2006 13:12:56 -0500 To: "Brian Rosen" , "'Andrew Newton'" , "'IETF SIP List'" , "'GEOPRIV'" From: "James M. Polk" Subject: Re: [Geopriv] RE: [Sip] teasing apart: http as a GEOPRIV using protocol In-Reply-To: <04d501c6b180$6e39f4a0$640fa8c0@cis.neustar.com> References: <37E9EDFD-EA9E-40A3-8885-996A8558958D@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 18:12:57.0540 (UTC) FILETIME=[49AE0040:01C6B1A8] DKIM-Signature: a=rsa-sha1; q=dns; l=1719; t=1154023981; x=1154887981; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Geopriv]=20RE=3A=20[Sip]=20teasing=20apart=3A=20http=20as=20a=2 0GEOPRIV=20using=0A=20=20protocol; X=v=3Dcisco.com=3B=20h=3DQDsWiRYzI/Knh49khsbOG5Pn1Go=3D; b=J+CZsKGsf3AMREee/Id0kmpaSrVUs5KtvvMvyvUn85bTp+wMYWKcoPAajgkh7+6u9PwMjh4P Cus3geItzPcJfyG3RTo9eTlc5zPY6qGcrDy6V3Cuhnhqoaweddf1aF5X; Authentication-Results: sj-dkim-7.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 09:27 AM 7/27/2006 -0400, Brian Rosen wrote: >I think HTTP requires some specification. A raw GET based retrieval of a >PIDF would be a fairly short RFC, but I think we need that RFC. I agree with the above now, based on the comments that HTTP has privacy concerns raised, and not addressed, in Geopriv. >While I don't think it's necessary (SIP SUBSCRIBE is sufficient), I don't >object to defining HTTP as a using protocol in a suitable RFC. > >Brian > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Thursday, July 27, 2006 8:45 AM > > To: IETF SIP List; GEOPRIV > > Subject: [Sip] teasing apart: http as a GEOPRIV using protocol > > > > There have been a number of opinions regarding HTTP as a using protocol. > > > > I'd like to know, how many people believe that HTTP requires no or > > very little specification to meet the requirements in RFC 3693 and > > RFC 3694. If you believe this, what basis do you have for this > > conclusion? Or do you believe more specification needs to be done, > > but it is possible for HTTP to be a GEOPRIV using protocol? > > > > Finally, how many people believe that HTTP should not be a using > > protocol? > > > > -andy > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 14:15:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AMb-0007wy-Pk; Thu, 27 Jul 2006 14:13:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AMa-0007wn-Ag for sip@ietf.org; Thu, 27 Jul 2006 14:13:36 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6AMZ-0007fA-1d for sip@ietf.org; Thu, 27 Jul 2006 14:13:36 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6RIDWgS010293; Thu, 27 Jul 2006 13:13:32 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k6RIDLu20369; Thu, 27 Jul 2006 13:13:32 -0500 (CDT) Message-ID: <44C90241.9070806@lucent.com> Date: Thu, 27 Jul 2006 13:13:21 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" Subject: Re: [Sip] Hitchhikers guide - when is it done? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Romascanu, Dan (Dan) wrote: > I am aware about this. On the other hand, the problem with RFCs is that > they tend to be updated at a slow pace. How often will the Hitchhiker > Guide be updated? - every two, three years? That is one reason why I was partial towards (1) from Jonathan's original email. If we could get the core specification guide out now as an RFC, we could tackle the extensions as an I-D, which is much easier to rev than a RFC would be. Plus, the I-D would be a WG agenda item, so that gives it some semblance of permanence (as opposed to an individual I-D). Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 14:17:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AOR-00014m-Hw; Thu, 27 Jul 2006 14:15:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AOQ-00013j-3D; Thu, 27 Jul 2006 14:15:30 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6AOO-0007xZ-Rp; Thu, 27 Jul 2006 14:15:30 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G6AOG-00020l-6z; Thu, 27 Jul 2006 13:15:20 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Henning Schulzrinne'" Subject: RE: [Geopriv] Re: [Sip] teasing apart: http as a GEOPRIV using protocol Date: Thu, 27 Jul 2006 14:15:21 -0400 Message-ID: <004501c6b1a8$a1b2a7a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acaxkmvi4NLy2+d5SHCM8xlVR9bUjAABwS6w In-Reply-To: <44C8DD67.6090908@gmx.net> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'IETF SIP List' , 'GEOPRIV' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A using protocol carries location between a server and a watcher. That is PRECISELY what a dereference is. Dereferencing protocols MUST be using protocols. However, I think that if the reference is a presence URI (sip/sips/pres) then these issues are addressed. If there is to be some other protocol used to dereference, then it has to be a using protocol, and these issues must be addressed. If the protocol always returns a PIDF, many of these issues can be answered by using the PIDF mechanisms to express user rules. Now, for Presence (asserted by a proxy): > > * We assume that it gets the location information somehow. Not further > specified and might depend on the deployment environment. Yeah, with the identifier mess > > * What is the "entity" attribute of the 'presence' element? The user, just as it would be if the endpoint asserted it, possibly anonymized as we discussed. I think the latter is more appropriate when used in a Location header. > > * Where does the content for the usage-rules (e.g, > 'retransmission-allowed', 'retention-expires', 'ruleset-reference', > 'note-well') come from? >From the user, just as it would be if the user asserted it. It's just a different mechanism for sending the same data. Probably actually has the same user interface, it's just the difference between whether the prototype PIDF that the location is laid into gets sent to the phone or the proxy. The UI to do this is a probably a web browser. > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 14:29:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AaR-0005KP-IF; Thu, 27 Jul 2006 14:27:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AaQ-0005KH-R7; Thu, 27 Jul 2006 14:27:54 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6AaP-00018x-Eq; Thu, 27 Jul 2006 14:27:54 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 27 Jul 2006 11:27:52 -0700 X-IronPort-AV: i="4.07,189,1151910000"; d="scan'208"; a="308548800:sNHT27243800" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RIRqIq031750; Thu, 27 Jul 2006 11:27:52 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6RIRq79000944; Thu, 27 Jul 2006 11:27:52 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jul 2006 11:27:52 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 11:27:51 -0700 Message-Id: <4.3.2.7.2.20060727132217.034381d8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2006 13:27:50 -0500 To: Andrew Newton , IETF SIP List , GEOPRIV From: "James M. Polk" In-Reply-To: <44C8CCF3.2030506@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 18:27:51.0964 (UTC) FILETIME=[5ECC45C0:01C6B1AA] DKIM-Signature: a=rsa-sha1; q=dns; l=2241; t=1154024872; x=1154888872; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Geopriv]=20Teasing=20apart=3A=20constraints=20on=20dereference= 20URI; X=v=3Dcisco.com=3B=20h=3Djw9kbesGWvpHcSxeePkvNu0wsfY=3D; b=EydXGS9qjfBrKDP5J5ArEXe1gDwOi7LpZ0t4PK/82Sq/MHYykmTap0n3yWe7PXWugRsPRy+P ulymCkdIXlkOy7ZvNmnkbPMqUc0uaYsK0Yd7iMT5LPS5AZDHUjlyXEIl; Authentication-Results: sj-dkim-8.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [Sip] Re: [Geopriv] Teasing apart: constraints on dereference URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 10:25 AM 7/27/2006 -0400, Andrew Newton wrote: >There have been many conversations regarding constraining the URI in the >Location header. There have been many positions taken on this subject, >and this email is intended to understand the various opinions. > >Is there anybody who believes that the type of URI in the Location header >should not be constrained in any way? In other words, any URI scheme may >be valid and there should be no attempt to specify the URI scheme or >associated protocol for dereferencing location. And if so, do you believe >location will only be dereferenced via a user clicking on a link or by >automatic software action? If the latter, how do you see software >adapting to multiple URI schemes and their associated protocols? > >Is there anybody who believes that the dereference URI should be >restricted to a specific set of schemes, enforced via ABNF, XML Schema, or >other grammar specification and re-enforced with MUST/SHOULD >language? The intent here being that the set would be definitive or at >the very least require major effort to update. Andy - I vote for the scheme be defined within the using protocol's (general) area. For example, if a SIP document defines SIP and a Geopriv using protocol, then it should define one or more schemas near SIP (SIP, SIMPLE, MMUSIC). This does result in sip/sips/pres/cid being in the SIP using protocol doc. If there were an HTTP document promoting HTTP being a Geopriv using protocol, that document should be the one defining HTTP area schemas, meaning http/https. and so on for other protocols >Finally, how many people desire a middle ground? Perhaps where the ABNF, >XML Schema or other grammar specification allows for any URI scheme but >there is an IANA registry listing the allowed dereference URI schemes and >associated protocols? I think any IANA Registry here will point back to a Standards Track RFC that defined the usage and semantics, which your question is not allowing. Therefore, for what you have immediately above, I disagree. >-andy > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 14:34:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Aep-0000Gn-Vw; Thu, 27 Jul 2006 14:32:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Aeo-0000Gf-Ov; Thu, 27 Jul 2006 14:32:26 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Aeo-0001ZW-3K; Thu, 27 Jul 2006 14:32:26 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 27 Jul 2006 11:32:25 -0700 X-IronPort-AV: i="4.07,189,1151910000"; d="scan'208"; a="331901943:sNHT30762428" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RIWP43010669; Thu, 27 Jul 2006 11:32:25 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6RIWPJk019033; Thu, 27 Jul 2006 11:32:25 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jul 2006 11:32:25 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.35]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 11:32:24 -0700 Message-Id: <4.3.2.7.2.20060727133016.0331eef8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2006 13:32:23 -0500 To: Hannes Tschofenig , Brian Rosen From: "James M. Polk" Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance In-Reply-To: <44C8CEBD.2030108@gmx.net> References: <035a01c6b0e7$c9250ba0$640fa8c0@cis.neustar.com> <035a01c6b0e7$c9250ba0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 18:32:24.0570 (UTC) FILETIME=[0148A5A0:01C6B1AB] DKIM-Signature: a=rsa-sha1; q=dns; l=7448; t=1154025145; x=1154889145; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20RE=3A=20[Geopriv]=20Consensus=20on=20changes=20to=0A=20= 20location-conveyance; X=v=3Dcisco.com=3B=20h=3D6MjbpL8IiYLdDIsKBDAd+QlIgwA=3D; b=BInuBzK33OANPj1/FB/UeZb/z0OhBFouPt54cqV62fXb4BYEQRwH7YPG5wVIkJfOs7Gh9C/w JJshLQf3UR0UgKupvPVS/Fg6rBXTE7Nr4qrBaP3AQtX1n8Ts93rBcRhM; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: sip@ietf.org, geopriv@ietf.org, "'Abbott, Nadine B'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 04:33 PM 7/27/2006 +0200, Hannes Tschofenig wrote: >Hi Brian, > >are you talking about the end host adding a location-by-reference into the >SIP header or a proxy doing so? > >In any case I don't understand your objection against the usage of HTTP >and your preference for SIP/SIPS/PREZ? Hannes - I think Brian has a problem with a SIP doc defining how HTTP works. He has stated an HTTP doc should do this. We think this HTTP doc should be very, very short. This SIP doc is allowing an extension to the URI schemes without going though the SIP WG as a SIP WG item (which is normally required - and takes a lot of time, because it must first start in SIPPING). >Ciao >Hannes > >Brian Rosen wrote: >>Nadine >>Are you saying that it's your opinion sip-location-conveyance MUST >>define an HTTP dereference procedure? >>If you do, why? What is the use-case or requirement? >>Would it not be pretty reasonable to require a separate document that >> defines a location-by-reference mechanism, protocol, and geopriv >>"using protocol" analysis? If that document specifically extended >>what was allowed in the location header, would that not be >>reasonable? >>I think we have to include "A" dereference mechanism in the >>location-conveyance document. It seems just including sip/sips/prez >>is a reasonable, all-sip-all-the-time approach IN THIS DOCUMENT. >>That certainly does not preclude another document describing another >>way. >>Doesn't it seem just a little weird to have a sip-location-conveyance >> document describing any kind of http based location conveyance >> (de-reference) protocol, especially one created whole cloth without >>any other parts? >>Doesn't it seem in keeping with the geopriv approach that in order to >>have another "using protocol" it has to have a geopriv review? That >>is what leads to restricting the URI schemes. Would you prefer to >>let it be wide open, so any protocol anyone thinks about can be used >>with the location header? I can't see geopriv going along with that. >>We're going to make it a one line ABNF to add a new scheme to the >>list of allowed schemes. >>It seems to me that if it's desired to define some bare-bones HTTP >>location by reference protocol, then that should be a separate >>document, which can easily extend the allowable schemes in the >>Location header. I'm not sure it might be better to define ALL of >>that in the L7 protocol, but I wouldn't be opposed to a simple "raw >>GET" RFC as long as it got a full geopriv review. I just don't see >>where it makes any sense to force that into a sip document. >>Brian >> >>>-----Original Message----- From: Abbott, Nadine B >>>[mailto:nabbott@telcordia.com] Sent: Wednesday, July 26, 2006 2:14 >>>PM To: sip@ietf.org Cc: geopriv@ietf.org Subject: RE: [Geopriv] >>>Consensus on changes to location-conveyance >>> >>>I don't agree that there is a consensus to preclude the use of >>>HTTP. I would favor not placing your proposed restriction on the >>>URI scheme for expressing a location reference in the SIP location >>>conveyance draft; or at least including HTTP as a valid >>>location-reference URI type. >>>Regards, Nadine Abbott >>>-----Original Message----- From: Rosen, Brian >>>[mailto:Brian.Rosen@neustar.biz] Sent: Tuesday, July 25, 2006 1:38 >>>PM To: sip@ietf.org Cc: geopriv@ietf.org Subject: [Geopriv] >>>Consensus on changes to location-conveyance >>>I have put out a number of emails on proposed changes to location >>>conveyance. Some of them have sparked a number of comments. My >>>summary of consensus on these issues is: >>>1. We proposed to explicitly disallow use of a Data URI, which >>>would allow specification of a Location-by-value in a header. >>>There was a lot of list traffic on this, currently in the state >>>where Keith asked for a real use case for it. So far, we don't see >>>a use case that cannot be provided by location-by-reference in a >>>header. If we don't get a good use case, I think consensus is to >>>disallow location-by-value in a header. >>>2. Dereferencing location-by-reference. We had initially proposed >>>to document a process to use a raw HTTP(S) Get to dereference. >>>There was a lot of discussion, and then I made a new proposal, see >>>item 6. >>>3. We proposed to allow a Reason header with a 424 Bad Location >>>response. This seems to be acceptable to the WG. Geopriv will >>>create and populate the registry in a separate draft. >>>4. We proposed to explicitly allow hop-by-hop TLS security for >>>location when the endpoint wished to allow routing based on >>>location. We further proposed to interpret "Do not Distribute" >>>flags as allowing sending of the location to the routing database >>>(LoST for example). Hannes pointed out that there was a proposal >>>to allow two Location headers, one of which could be used for >>>routing and another for onward forwarding to the recipient. >>>Hannes' message seemed to agree that "Do not distribute" would >>>allow sending of the location to the routing-by-location database, but >>>would obligate the proxy that did that to remove the location >>>before it forwarded the message. There were no other messages on >>>this thread. We conclude that allowing hop-by-hop security for >>>location based routing is acceptable, and Do Not Distribute DOES >>>allow forwarding to a routing database, but requires that the proxy >>>doing the location based route to remove the location it uses for >>>that purpose. >>>5. We proposed to create a parameter and a registry to distinguish >>>multiple ways to dereference a location where HTTP(S) was the >>>transport. Resolution of this issue depends on resolution of issue >>>6. >>>6. We proposed to allow sip/sips and pres: in the location header. >>>I later speculated that if we allow this, it forms a simple way to >>>do location-by-reference, and we could eliminate the raw HTTP(S) >>>Get proposal, with the parameter and registry entirely. There was >>>some list traffic in favor of this. Martin Thompson is skeptical >>>that SIP Presence Subscribe/Notify is actually allowed as a geopriv >>>"using protocol". Several of think that it is. If we don't get >>>any more comments on this proposal, we will allow sip/sips and >>>pres, not have any http(s) resolution text, and not propose a >>>parameter and accompanying registry. >>>If this does not reflect your position, please speak up now. >>>Brian >>>_______________________________________________ Geopriv mailing >>>list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv >>>_______________________________________________ Geopriv mailing >>>list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv >> >>_______________________________________________ Sip mailing list >>https://www1.ietf.org/mailman/listinfo/sip This list is for NEW >>development of the core SIP Protocol Use >>sip-implementors@cs.columbia.edu for questions on current sip Use >>sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 14:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AoL-0000cW-5W; Thu, 27 Jul 2006 14:42:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AoJ-0000cJ-Vu; Thu, 27 Jul 2006 14:42:15 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6AoH-0002lP-Ov; Thu, 27 Jul 2006 14:42:15 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 27 Jul 2006 14:42:22 -0400 id 015881AB.44C9090F.00000C47 Message-ID: <44C908FC.2050303@hxr.us> Date: Thu, 27 Jul 2006 14:42:04 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "James M. Polk" References: <4.3.2.7.2.20060727132217.034381d8@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060727132217.034381d8@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF SIP List , GEOPRIV Subject: [Sip] Re: [Geopriv] Teasing apart: constraints on dereference URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James M. Polk wrote: >> Finally, how many people desire a middle ground? Perhaps where the >> ABNF, XML Schema or other grammar specification allows for any URI >> scheme but there is an IANA registry listing the allowed dereference >> URI schemes and associated protocols? > > I think any IANA Registry here will point back to a Standards Track RFC > that defined the usage and semantics, which your question is not > allowing. Therefore, for what you have immediately above, I disagree. I guess that may have been too much hand waving on my part. So let me ask you this question: if the grammar were to only specify "URI" and no particular kind of URI, yet the kinds of URIs allowed must have to pass some sort of review before their use in the Location header is considered acceptable, would you find favor in this approach? And if so, how would you implement it? -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 14:55:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AzF-0007mJ-1W; Thu, 27 Jul 2006 14:53:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6AzC-0007lS-L0; Thu, 27 Jul 2006 14:53:30 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6AzB-0003Y2-UC; Thu, 27 Jul 2006 14:53:30 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Jul 2006 11:53:29 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RIrSXq021070; Thu, 27 Jul 2006 11:53:28 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6RIrQJk004876; Thu, 27 Jul 2006 11:53:26 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 11:53:26 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.35]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 11:53:25 -0700 Message-Id: <4.3.2.7.2.20060727134912.031bda70@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2006 13:53:24 -0500 To: "Marc Berryman" , "Hannes Tschofenig" , "Dawson, Martin" From: "James M. Polk" Subject: Re: [Sip] RE: [Geopriv] Henning's Suggestion In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 18:53:25.0578 (UTC) FILETIME=[F0E732A0:01C6B1AD] DKIM-Signature: a=rsa-sha1; q=dns; l=8080; t=1154026409; x=1154890409; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20RE=3A=20[Geopriv]=20Henning's=20Suggestion; X=v=3Dcisco.com=3B=20h=3D7nLCc1b9wSDZfSwXe0OE6yU9JGA=3D; b=skK5GpTag5Zapubo/bRvrQlL/BWQOCI6tfH0w1l7htcMxtrFT6cz3N2Qjkt0JTMANMAPGIzU jagS73yk5PBr0+NpfMGFGN/tJq3cTDfSGWtvJ2SROqcsT5ILnfPcocfE; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: IETF SIP List , geopriv@ietf.org, Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 09:44 AM 7/27/2006 -0500, Marc Berryman wrote: >Sounds like Hannes and Henning are moving down the right track. Focusing >on the location header syntax for the draft. Mark Defining syntax alone doesn't satisfy the SIP requirements for any SIP extension within RFC 4485, which require per element behaviors be described too (section 4.7 I believe), which are not exactly the same per SIP request type, or per call intent type (e2e vs. proxy-routing) which gets use back to a better version of the -03 ID we have, that the authors have committed to submitting in the first half of August. >Marc B > >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >Sent: Thursday, July 27, 2006 9:35 AM >To: Dawson, Martin >Cc: IETF SIP List; geopriv@ietf.org; Henning Schulzrinne >Subject: [Geopriv] Henning's Suggestion > >Hi Henning, > >I like your suggestion. > >In fact I would even go a step further. The SIP Location Conveyance >document just defines a mechanism to carry a PIDF-LO in the body of the >SIP message. Done. >Adding location-by-reference to the SIP header by the end host sounds OK > >but there are still some loose ends where this reference comes from. > >The other stuff can be dealt with once we concluded our Geopriv-L7 work >where all the architectural pieces should are created. The >subscription-URI is an example where we recently proposed something and >haven't finished our technical discussions. > >I think the draft got fuzzy when it came to the area where a SIP proxy >adds a location-by-reference. I must admit that I proposed to add >location-by-value into the SIP header as well but in the meanwhile I >don't think that any of the SIP proxy stories belong in there. > >Ciao >Hannes > > >>-----Original Message----- > >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>Sent: Thursday, 27 July 2006 1:25 PM > >>To: Brian Rosen > >>Cc: IETF SIP List; geopriv@ietf.org > >>Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- > >>conveyance > >> > >>My suggestion would be > >> > >>- to focus the draft on just defining the Location header syntax, > >>without ruling out any particular mechanism or scheme; this would > >>make the draft really short (which I would find helpful). > >> > >>- and then add one section to the draft that prototypically defines > >>what a particular scheme that wants to appear in the Location header > >>needs to define, using the non-controversial cid mechanism as the > >>example. Other, separate, drafts can then define other modes, > >>following the same template. Documents such as the phone-bcp can then > >>pick some suitable must-implement subset and make emergency-call- > >>specific recommendations, rather than sprinkling these throughout the > >>conveyance document and repeating some in the phone-bcp. Most of > >>these are, in any event, operational recommendations, not for > >>ensuring protocol-level interoperability. > >> > >>That way, the conveyance draft can be extremely short (even shorter > >>if the requirements are omitted...) and can get done, and we avoid > >>engineering operational requirements on the fly, commingling > >>emergency and non-emergency cases, as seems to be happening now. > >> > >>I think protocol documents should define what's needed for > >>interoperability; BCPs can make more specific, situation-specific > >>recommendations. Commingling the two seems to be a recipe for > >>deadlock or arbitrary, non-technically-grounded decisions that are > >>more lawyer-like than engineering-like ("you did not mention > >>technique X in some meeting N years ago and thus you can't bring it > >>up now!") > >> > >>Henning > >> > >>On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote: > >> > >> > >>>At this point, I think we need some chair guidance and by that I > >>>think it's > >>>a combo of geopriv and sip chairs. > >>> > >>>We seem to have a couple of significant open questions. I think > >>>most of the > >>>other stuff (like the "allow sending to router") will converge. > >>> > >>>There seems to be some opposition to allowing sip/sips/pres: in a > >>>Location > >>>Header. The opposition seems to be that despite 4119, somehow, SIP > >>>(presence subscription) is not a "using protocol". I "think" a > >>>ruling from > >>>the bench on that would work. > >>> > >>>There is also opposition to defining the allowed schemes as a > >>>specific list, > >>>with a defined (easy) extension mechanism. > >>> > >>>Related to that, there are some who want location-conveyance to > >>>define an > >>>HTTP based location dereference mechanism, and on the opposite end, > >>>we have > >>>people saying we haven't even agreed to support any form of > >>>location-by-reference. > >>> > >>>The authors would like to know what to do now. > >>> > >>>Brian > >>> > >>> > >>>>-----Original Message----- > >>>>From: Andrew Newton [mailto:andy@hxr.us] > >>>>Sent: Wednesday, July 26, 2006 9:58 PM > >>>>To: Winterbottom, James > >>>>Cc: sip@ietf.org; geopriv@ietf.org; Abbott, Nadine B; Henning > >>>>Schulzrinne > >>>>Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- > >>>>conveyance > >>>> > >>>> > >>>>On Jul 26, 2006, at 9:43 PM, Winterbottom, James wrote: > >>>> > >>>> > >>>>>Andy, > >>>>> > >>>>>RFC-4119 says "However, the usage of this location object format > > > > is > > > >>>>>not > >>>>> limited to presence-using protocols-- any protocol that can > >>>>>carry XML > >>>>> or MIME types can carry PIDF." > >>>>> > >>>>>It seems to me that restricting the allowed schema in what is > >>>>>supposed > >>>>>to be a location conveyance specification is in opposition to this > >>>>>statement. > >>>> > >>>>Did somebody say that HTTP was a presence-using protocol? > >>>> > >>>>-andy > >>>> > >>>>ps. you can find my location with the following reference URIs: > >>>> > >>>>gopher://fatchance.hxr.us/you-still-have-a-gopher-client > >>>>news:alt.locations.people.secretly-being-watched > >>>>telnet://screen-scrapers.are.us/ > >>>>dns:cached-publicly-around-the-world.com?type=HOST > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>Geopriv mailing list > >>>>Geopriv@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/geopriv > >>> > >>> > >>>_______________________________________________ > >>>Geopriv mailing list > >>>Geopriv@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/geopriv > >> > >> > >>_______________________________________________ > >>Geopriv mailing list > >>Geopriv@ietf.org > >>https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > >------------------------------------------------------------------------ >------------------------ > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > >------------------------------------------------------------------------ >------------------------ > > [mf2] > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 14:58:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6B2J-0001FV-Qk; Thu, 27 Jul 2006 14:56:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6B2I-0001FN-IE; Thu, 27 Jul 2006 14:56:42 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6B2H-0003i3-71; Thu, 27 Jul 2006 14:56:42 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 27 Jul 2006 11:56:40 -0700 X-IronPort-AV: i="4.07,189,1151910000"; d="scan'208"; a="331910255:sNHT27059868" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RIuep7024983; Thu, 27 Jul 2006 11:56:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6RIue2D022590; Thu, 27 Jul 2006 11:56:40 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 11:56:40 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 11:56:39 -0700 Message-Id: <4.3.2.7.2.20060727135547.03adf008@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2006 13:56:38 -0500 To: Henning Schulzrinne , "Drage, Keith \(Keith\)" From: "James M. Polk" Subject: Re: Teasing apart positions (was Re: [Sip] RE: [Geopriv] Consensusonchanges to location-conveyance) In-Reply-To: <44C8DCD3.6090109@cs.columbia.edu> References: <5D1A7985295922448D5550C94DE29180194FAA@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE29180194FAA@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 18:56:40.0046 (UTC) FILETIME=[64D0A8E0:01C6B1AE] DKIM-Signature: a=rsa-sha1; q=dns; l=1130; t=1154026600; x=1154890600; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20Teasing=20apart=20positions=20(was=20Re=3A=20[Sip]=20RE=3A=0A=20 =20[Geopriv]=09Consensusonchanges=20to=20location-conveyance); X=v=3Dcisco.com=3B=20h=3D2x/kz6qLFtYS66dIf9QRqHFL8dw=3D; b=IUfE4y/vYnlCWET6poP65BGEgS/tBoMW7CejMYseTnSUXZnSnNATRR4lNQMMkNlrBs6AfBMi r8NvN+FMv1PBHXouwPSngvcKr+qWJ2yHhY/UclW0YSJzNTz7Hp+w/hZG; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 11:33 AM 7/27/2006 -0400, Henning Schulzrinne wrote: >>ii) if we have more than one option, we either need some means of >>determining that the dereferencer supports the one the client chooses to >>use, or require support of all options. As we seem to be lacking any >>mechanism for the former, then it would imply that all options have to >>be supported at the dereferencer, and therefore that the list needs to >>be a small list. > >This isn't quite true. It is quite possible to include multiple options, >as long as one of them is universally supported. For example, you can >support a "universal & slow" and a "sometimes & fast" solution, and >everybody wins. Are you saying that the doc now has to state that more than one schema has to be supported within the same Location header? >This approach is not new: MIME email does exactly that, where messages >with HTML or rich text often also contain an alternate plain text rendering. > >Henning > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 15:14:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BHT-0001wB-VD; Thu, 27 Jul 2006 15:12:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BHS-0001w3-7w for sip@ietf.org; Thu, 27 Jul 2006 15:12:22 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6BHR-0005j9-Qb for sip@ietf.org; Thu, 27 Jul 2006 15:12:22 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k6RJCFHw019169; Thu, 27 Jul 2006 14:12:15 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 14:12:15 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 Jul 2006 21:12:13 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Hitchhikers guide - when is it done? Date: Thu, 27 Jul 2006 21:12:12 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918019507C@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Hitchhikers guide - when is it done? Thread-Index: AcawyNH+hU2m+pDpSRymEf9zkXPaQAA3bcSgAAJ0jbA= From: "Drage, Keith \(Keith\)" To: "Romascanu, Dan \(Dan\)" , "Jonathan Rosenberg" X-OriginalArrivalTime: 27 Jul 2006 19:12:13.0207 (UTC) FILETIME=[9105BA70:01C6B1B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Lets indicate an expectation of once every 12 months. Within that period there ought to be at least 10/20 references to either add or change. Regards Keith=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: 27 July 2006 19:05 > To: Jonathan Rosenberg > Cc: IETF SIP List > Subject: RE: [Sip] Hitchhikers guide - when is it done? >=20 > I am aware about this. On the other hand, the problem with=20 > RFCs is that they tend to be updated at a slow pace. How=20 > often will the Hitchhiker Guide be updated? - every two,=20 > three years? I am looking at a semi-official solution to be=20 > used in-between, maintained at a known well place by a=20 > registrar nominated by the SIP WG or RAI Area.=20 >=20 > Dan >=20 > =20 >=20 > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Wednesday, July 26, 2006 6:33 PM > > To: Romascanu, Dan (Dan) > > Cc: IETF SIP List > > Subject: Re: [Sip] Hitchhikers guide - when is it done? > >=20 > > The problem with any kind of website reference is that they=20 > are never=20 > > 'official'. There are countless web sites enumerating SIP related=20 > > documents. What makes something an official output of the=20 > IETF is that=20 > > its an RFC. > >=20 > > -Jonathan R. > >=20 > > Romascanu, Dan (Dan) wrote: > >=20 > > > Because of the overhead and clerical delays involved in the=20 > > > publication of RFCs I would suggest a refinement to option > > 2. Provide > > > a reference in the RFC to a Web page maintained and > > refreshed by the > > > SIP WG or the RAI Area including the=20 > 'to-the-best-of-our-knowledge'=20 > > > updates in-between two versions of the RFC. > > >=20 > > > Dan > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > =20 > > >=20 > > >=20 > > >>-----Original Message----- > > >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > >>Sent: Tuesday, July 25, 2006 8:56 PM > > >>To: IETF SIP List > > >>Subject: [Sip] Hitchhikers guide - when is it done? > > >> > > >>During the IETF meeting, I discussed the one current open > > issue in the > > >>Hitchhikers guide. The issue is: when does the document > > finish? When > > >>do we send to IESG to issue an RFC? > > >> > > >>There were two approaches: > > >> > > >>1. split the document in two. One part contains only the > > core specs, > > >>and issues relatively soon. The other part has everything=20 > else, and=20 > > >>basically ends up being the last RFC produced by the SIP WG > > before it > > >>shuts its doors (which has always been 1.5 years from now > > for the last > > >>5 years). > > >> > > >>2. keep it as one document. Issue an RFC at some point, and then=20 > > >>revise it a few times as needed. We need to decide when=20 > to issue it. > > >> > > >> > > >>I'd like to propose option 2. I think people get more=20 > value from it=20 > > >>as a consolidated document. Furthermore, I'd propose that we send=20 > > >>the document to IESG for consideration as informational at the=20 > > >>instant all of the documents listed as 'core' have RFC numbers=20 > > >>issued by RFC-ed. > > >> > > >>Comments? > > >> > > >>-Jonathan R. > > >>--=20 > > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > >>Cisco Fellow Parsippany, NJ=20 > > >>07054-2711 > > >>Cisco Systems > > >>jdrosen@cisco.com FAX: =20 > (973) 952-5050 > > >>http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > > >>http://www.cisco.com > > >> > > >>_______________________________________________ > > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >>This list is for NEW development of the core SIP Protocol Use=20 > > >>sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > >>sipping@ietf.org for new developments on the application of sip > > >> > > >=20 > > >=20 > >=20 > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ=20 > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 15:23:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BQh-0005to-F4; Thu, 27 Jul 2006 15:21:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BQg-0005tg-8z for sip@ietf.org; Thu, 27 Jul 2006 15:21:54 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6BQd-0006rk-SY for sip@ietf.org; Thu, 27 Jul 2006 15:21:54 -0400 Received: (qmail 17425 invoked by uid 0); 27 Jul 2006 19:21:48 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 27 Jul 2006 19:21:48 -0000 Message-ID: <003001c6b1b1$e52f7c20$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Robert Sparks" References: <0J3200C45R4PGU30@jes-fe1.zx.nl> Date: Thu, 27 Jul 2006 21:21:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip@ietf.org Subject: [Sip] Re: RFC4320 and 408 to non-INVITE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > This is not the way the timers are meant to be changed. > > Both of the transaction-stateful things on either end of a given > transaction must share the same > values for the transaction timers or the results are not defined. > > What you describe is not unlike throwing away the timing belt in an > engine and spinning > the head at some rate unrelated to the crankshaft. You might get lucky, > but usually very bad things > are going to happen. That's interesting, because it is exactly what is prescribed for IMS Refer to TS 24.229 release 7 table 7.8 "SIP Timers" (http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-740.zip, page 132 for me) It says: Value to be applied at the UE: T1 = 2s default Value to be applied between IM CN subsystem elements: T1=500ms default So you are saying that in IMS configured this way, very bad things will happen? Regards, jeroen > > RjS > > On Jul 27, 2006, at 12:29 PM, Jeroen Van Bemmel wrote: > >> Robert, >> >> RFC4320 bans 408 responses to NIT, but I think there are situations in >> which it is still useful and needed. In particular, consider when the >> UAC is using T1=2000 and the proxy uses T1=500 (eg because the client is >> on a slow wireless link) >> >> The CT at the proxy times out after 64*T1=32 sec, while the client is >> still retransmitting. In this case, 408 does help >> >> Regards, >> Jeroen > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 15:35:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BcZ-0004QL-5W; Thu, 27 Jul 2006 15:34:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BcY-0004QB-6o for sip@ietf.org; Thu, 27 Jul 2006 15:34:10 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6BcX-0008MG-OF for sip@ietf.org; Thu, 27 Jul 2006 15:34:10 -0400 Received: (qmail invoked by alias); 27 Jul 2006 19:27:24 -0000 Received: from ip-80-226-176-59.vodafone-net.de (EHLO [10.226.0.63]) [80.226.176.59] by mail.gmx.net (mp038) with SMTP; 27 Jul 2006 21:27:24 +0200 X-Authenticated: #29516787 Message-ID: <44C9139B.7030109@gmx.net> Date: Thu, 27 Jul 2006 21:27:23 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Sip] teasing apart: http as a GEOPRIV using protocol References: <04d501c6b180$6e39f4a0$640fa8c0@cis.neustar.com> <7A8FBA4E-DD34-4C89-80B6-BE2913101258@cs.columbia.edu> <44C8DD67.6090908@gmx.net> <44C8F716.3030401@hxr.us> <44C8FC0F.5070907@cs.columbia.edu> In-Reply-To: <44C8FC0F.5070907@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Henning, I would very much appreciate to treat this topic in the way you proposed it below. A few minor comments: Henning Schulzrinne wrote: > With hindsight, I think the term 'using protocol' has been the source of > more word-lawyering than engineering insight. I personally find the > distinctions > > - first person vs. third person (i.e., find out location about myself > vs. find out location about some third party) > > - location vs. location + identity > > - token-based authorization vs. identity-based authorization > > more helpful. > > Token-based authorization hands the recipient a key that allows him to > get a location object, without caring as to who is retrieving the > object. ("Anybody seeing this SIP request can convert the token into an > LO.") Identity-based naturally uses some authenticated identity to > release that information. In past common policy discussions we also differentiated between limited use addresses and trait-based authorization. A token would match the latter. In some sense we seem to be using limited use addresses in most of the cases when we talk about the location-by-references. The difference between limited use addresses and trait-based authorization is small in this particular usage environment. Strictly speaking, this is only a question of > a level of indirection, since proving identity usually involves proving > possession of a secret. I guess there are some further differences with regard to the lifetime of the different identifiers, the ability to revoke rights, the number of entities that one can hide behind these identifiers and the storage implications. > We've been trying to get at some of these distinctions with the sighting > vs. using protocol terminology, but that distinction also seems to > degenerate into discussions more suited for a law school or theology > department than an engineering organization. > > For example, by strict definition, LoST would be a 'Using Protocol' > since it "carries a Location Object", but I hope we all agree that this > is silly. We had earlier agreed that the location-by-DHCP also were not > Using Protocol, even though they obviously carry a location object of > some form. Currently LoST is not a using protocol since it does not carry a PIDF-LO although some folks would like to use a PIDF-LO; HELD was a using protocol before we turned the problem into a Location Configuration problem; RELO never was a using protocol; Isn't this confusing? > > Privacy issues apply iff > - third person > - location + identity (not just location) > > The L7 discussion was about 'first person' and 'location only' (although > the latter is subject to debate, depending on whether one considers an > IP address of identifying an individual or not). That was before we added the Location-by-Reference and subscription-URI concept .... > > Depending on the circumstances, SIP-based retrieval can either involve > privacy concerns (subscribe to alice@example.com) or not (subscribe to > location of one-time random unlinkable identifier > jdfa8f9348@example.com). There can also be different privacy concerns > depending on the perspective. For example, if a SIP request contains > both an identity and the location retrieval reference, this raises > privacy concerns for the proxy, but the LIS may not have any such > concerns since it may only be the repository of these randomly-named > objects, without tie to an identity. Ciao Hannes > Henning > > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 15:44:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BlD-0002qp-V7; Thu, 27 Jul 2006 15:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BlD-0002qh-0B; Thu, 27 Jul 2006 15:43:07 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6BlB-0000gK-KZ; Thu, 27 Jul 2006 15:43:06 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 27 Jul 2006 12:43:05 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RJh4qs032568; Thu, 27 Jul 2006 12:43:04 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6RJh1Yv001950; Thu, 27 Jul 2006 12:43:04 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 12:43:01 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 12:43:00 -0700 Message-Id: <4.3.2.7.2.20060727144240.03463dd0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2006 14:42:59 -0500 To: Andrew Newton , IETF SIP List , GEOPRIV From: "James M. Polk" In-Reply-To: <4.3.2.7.2.20060727132217.034381d8@email.cisco.com> References: <44C8CCF3.2030506@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 19:43:00.0727 (UTC) FILETIME=[DE3AE870:01C6B1B4] DKIM-Signature: a=rsa-sha1; q=dns; l=2561; t=1154029384; x=1154893384; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Geopriv]=20Teasing=20apart=3A=20constraints=20on=20dereference= 20URI; X=v=3Dcisco.com=3B=20h=3Djw9kbesGWvpHcSxeePkvNu0wsfY=3D; b=ZtvcrvjHu5LD5uckhJITqKMV3m2YtKmkdV6ZwPIfa1UnADPUYDaR3LQ7aShWFQuUV3yIxJdq sCgkUBHjA0qLStm3vB85MyjR01gADUKNWYx1X1PukAUheSHzACwNOYb9; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Subject: [Sip] Re: [Geopriv] Teasing apart: constraints on dereference URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 01:27 PM 7/27/2006 -0500, James M. Polk wrote: >At 10:25 AM 7/27/2006 -0400, Andrew Newton wrote: >>There have been many conversations regarding constraining the URI in the >>Location header. There have been many positions taken on this subject, >>and this email is intended to understand the various opinions. >> >>Is there anybody who believes that the type of URI in the Location header >>should not be constrained in any way? In other words, any URI scheme may >>be valid and there should be no attempt to specify the URI scheme or >>associated protocol for dereferencing location. And if so, do you >>believe location will only be dereferenced via a user clicking on a link >>or by automatic software action? If the latter, how do you see software >>adapting to multiple URI schemes and their associated protocols? >> >>Is there anybody who believes that the dereference URI should be >>restricted to a specific set of schemes, enforced via ABNF, XML Schema, >>or other grammar specification and re-enforced with MUST/SHOULD >>language? The intent here being that the set would be definitive or at >>the very least require major effort to update. > >Andy - I vote for the scheme be defined within the using protocol's >(general) area. > >For example, if a SIP document defines SIP and I meant "as" here instead of "and" > a Geopriv using protocol, then it should define one or more schemas near > SIP (SIP, SIMPLE, MMUSIC). This does result in sip/sips/pres/cid being > in the SIP using protocol doc. > >If there were an HTTP document promoting HTTP being a Geopriv using >protocol, that document should be the one defining HTTP area schemas, >meaning http/https. > >and so on for other protocols > > >>Finally, how many people desire a middle ground? Perhaps where the ABNF, >>XML Schema or other grammar specification allows for any URI scheme but >>there is an IANA registry listing the allowed dereference URI schemes and >>associated protocols? > >I think any IANA Registry here will point back to a Standards Track RFC >that defined the usage and semantics, which your question is not >allowing. Therefore, for what you have immediately above, I disagree. > > >>-andy >> >> >>_______________________________________________ >>Geopriv mailing list >>Geopriv@ietf.org >>https://www1.ietf.org/mailman/listinfo/geopriv > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 15:51:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Br9-0004qt-54; Thu, 27 Jul 2006 15:49:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Br7-0004ql-Pe; Thu, 27 Jul 2006 15:49:13 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Br5-00018i-Hh; Thu, 27 Jul 2006 15:49:13 -0400 Received: from lion.cs.columbia.edu (IDENT:zLjCpJ9AiQ2KaerwbVsM9ZCWgsNWjiD1@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6RJn84F008508 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 27 Jul 2006 15:49:09 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6RJn8rh020514 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Jul 2006 15:49:08 -0400 Message-ID: <44C918AF.1070206@cs.columbia.edu> Date: Thu, 27 Jul 2006 15:49:03 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Geopriv] Re: [Sip] teasing apart: http as a GEOPRIV using protocol References: <04d501c6b180$6e39f4a0$640fa8c0@cis.neustar.com> <7A8FBA4E-DD34-4C89-80B6-BE2913101258@cs.columbia.edu> <44C8DD67.6090908@gmx.net> <44C8F716.3030401@hxr.us> <44C8FC0F.5070907@cs.columbia.edu> <44C9139B.7030109@gmx.net> In-Reply-To: <44C9139B.7030109@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.27.122432 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > In past common policy discussions we also differentiated between limited > use addresses and trait-based authorization. A token would match the > latter. I'm not so sure. I see this as another level of indirection: secret -> access and secret -> identity ("alice") -> access and secret -> trait ("contractor") -> access > > I guess there are some further differences with regard to the lifetime > of the different identifiers, the ability to revoke rights, the number > of entities that one can hide behind these identifiers and the storage > implications. Right - the more layers of indirections, the more means to revoke. However, I don't see a fundamental difference between the three mechanisms in this case. In each case, you can revoke access. > Isn't this confusing? Unless you spent three years in Advanced GEOPRIV Language & Philosophy class, yes. >> >> The L7 discussion was about 'first person' and 'location only' >> (although the latter is subject to debate, depending on whether one >> considers an IP address of identifying an individual or not). > > That was before we added the Location-by-Reference and subscription-URI > concept .... As long as the recipient of the reference and the URI is the target, it doesn't much matter. We get into trouble if we use the same mechanism for first-person and third-person retrieval. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 15:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Brj-0005Ck-CQ; Thu, 27 Jul 2006 15:49:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Bri-0005Cb-2t for sip@ietf.org; Thu, 27 Jul 2006 15:49:50 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Brg-0001Cv-Ao for sip@ietf.org; Thu, 27 Jul 2006 15:49:50 -0400 Received: from [172.17.2.252] ([172.17.2.252]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6RJmW9W053345 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Jul 2006 14:48:32 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <003001c6b1b1$e52f7c20$31713b51@BEMBUSTER> References: <0J3200C45R4PGU30@jes-fe1.zx.nl> <003001c6b1b1$e52f7c20$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: <5CC1ED2B-7867-418F-8B7A-04FA9E80531F@estacado.net> From: Robert Sparks Date: Thu, 27 Jul 2006 14:48:31 -0500 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.3 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: sip@ietf.org Subject: [Sip] Re: RFC4320 and 408 to non-INVITE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1215654034==" Errors-To: sip-bounces@ietf.org --===============1215654034== Content-Type: multipart/alternative; boundary=Apple-Mail-15--371147492 --Apple-Mail-15--371147492 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed So, specifically, that table says: SIP Timer Value to be applied between IM CN subsystem elements Value to be applied at the UE Value to be applied at the P-CSCF toward a UE Meaning T1 500ms default 2s default 2s default RTT estimate So the P-CSCF and the UE are both using 2s for T1. When the P-CSCF talks to other things (that are not the UE), it uses 500ms for T1. What you were describing would be the P-CSCF using 500ms on its side of a transaction it was in with a UA that was using 2s, which is not what this table says to do. In that case, yes, undefined things can happen. RjS On Jul 27, 2006, at 2:21 PM, Jeroen van Bemmel wrote: >> This is not the way the timers are meant to be changed. >> >> Both of the transaction-stateful things on either end of a given >> transaction must share the same >> values for the transaction timers or the results are not defined. >> >> What you describe is not unlike throwing away the timing belt in >> an engine and spinning >> the head at some rate unrelated to the crankshaft. You might get >> lucky, but usually very bad things >> are going to happen. > > That's interesting, because it is exactly what is prescribed for IMS > > Refer to TS 24.229 release 7 table 7.8 "SIP Timers" (http://www. > 3gpp.org/ftp/Specs/archive/24_series/24.229/24229-740.zip, page 132 > for me) > > It says: > Value to be applied at the UE: T1 = 2s default > Value to be applied between IM CN subsystem elements: T1=500ms default > > So you are saying that in IMS configured this way, very bad things > will happen? > > Regards, > > jeroen > >> >> RjS >> >> On Jul 27, 2006, at 12:29 PM, Jeroen Van Bemmel wrote: >> >>> Robert, >>> >>> RFC4320 bans 408 responses to NIT, but I think there are >>> situations in which it is still useful and needed. In >>> particular, consider when the UAC is using T1=2000 and the proxy >>> uses T1=500 (eg because the client is on a slow wireless link) >>> >>> The CT at the proxy times out after 64*T1=32 sec, while the >>> client is still retransmitting. In this case, 408 does help >>> >>> Regards, >>> Jeroen > --Apple-Mail-15--371147492 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 So, specifically, that table = says:
SIP Timer
Value to = be applied between IM CN subsystem elements
Value to = be applied at the UE
Value to = be applied at the P-CSCF toward a UE
Meaning
T1
500ms default
2s = default
2s = default
RTT = estimate


So the P-CSCF and the UE are = both using 2s for T1.
When the P-CSCF talks to other = things (that are not the UE), it uses 500ms for T1.

What you were describing = would be the P-CSCF using 500ms on its side of a transaction it was in = with a
UA that was using 2s, which is not what this table says = to do. In that case, yes, undefined things can happen.

RjS

On = Jul 27, 2006, at 2:21 PM, Jeroen van Bemmel wrote:

This is not the way the timers = are meant to be changed.

Both of the transaction-stateful = things on either end of a given transaction must share the = same
values for the transaction = timers or the results are not defined.

What you = describe is not unlike throwing away the timing belt in an engine and = spinning
the head at some rate unrelated = to the crankshaft. You might get=A0 = lucky, but usually very bad things
are = going to happen.

That's interesting, because it = is exactly what is prescribed for IMS






RjS

On Jul 27, 2006, at 12:29 PM, = Jeroen Van Bemmel wrote:


RFC4320 bans 408 responses to NIT, but I think there = are situations=A0 in which = it is still useful and needed. In particular, consider=A0 when the UAC is using T1=3D2000= and the proxy uses T1=3D500 (eg because=A0 the client is on a slow = wireless link)

The CT at the proxy times out after 64*T1=3D32 sec, = while the client=A0 is = still retransmitting. In this case, 408 does help

Jeroen
=
X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2006 14:52:15 -0500 To: Andrew Newton From: "James M. Polk" In-Reply-To: <44C908FC.2050303@hxr.us> References: <4.3.2.7.2.20060727132217.034381d8@email.cisco.com> <4.3.2.7.2.20060727132217.034381d8@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 19:52:17.0085 (UTC) FILETIME=[29D866D0:01C6B1B6] DKIM-Signature: a=rsa-sha1; q=dns; l=1379; t=1154029937; x=1154893937; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Geopriv]=20Teasing=20apart=3A=20constraints=20on=20dereference= 20URI; X=v=3Dcisco.com=3B=20h=3Djw9kbesGWvpHcSxeePkvNu0wsfY=3D; b=IFV/GHCigpANhPKNGhlxPo2xW9SKtvqL0JR45iw8X2ObdiRvpMFjvgEf8jABhNHXnICz2VF7 kiU3rLhpidkahP8Af0gvGUv49oWqjhASDS+aXRkfPIOO0Td+17QWu5T9; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IETF SIP List , GEOPRIV Subject: [Sip] Re: [Geopriv] Teasing apart: constraints on dereference URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 02:42 PM 7/27/2006 -0400, Andrew Newton wrote: >James M. Polk wrote: >>>Finally, how many people desire a middle ground? Perhaps where the >>>ABNF, XML Schema or other grammar specification allows for any URI >>>scheme but there is an IANA registry listing the allowed dereference URI >>>schemes and associated protocols? >>I think any IANA Registry here will point back to a Standards Track RFC >>that defined the usage and semantics, which your question is not >>allowing. Therefore, for what you have immediately above, I disagree. > >I guess that may have been too much hand waving on my part. So let me ask >you this question: if the grammar were to only specify "URI" and no >particular kind of URI, yet the kinds of URIs allowed must have to pass >some sort of review before their use in the Location header is considered >acceptable, would you find favor in this approach? This is generally what the authors here are proposing, with Geopriv being the reviewers. In SIP Location Conveyance, since it is a SIP doc (and SIP is the transport protocol of the Location header where the URIs will go), this doc will define SIP-based schemas (sip/sips/pres/cid). Extensions to this RFC (if it ever gets there) can ADD schemas, once those specifications pass Geopriv consensus. >And if so, how would you implement it? > >-andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 15:56:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Bwn-000408-0P; Thu, 27 Jul 2006 15:55:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Bwl-0003zl-EC for sip@ietf.org; Thu, 27 Jul 2006 15:55:03 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Bwk-0002ad-IF for sip@ietf.org; Thu, 27 Jul 2006 15:55:03 -0400 Received: (qmail 31625 invoked by uid 0); 27 Jul 2006 19:55:00 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 27 Jul 2006 19:55:00 -0000 Message-ID: <005e01c6b1b6$88e91a20$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Robert Sparks" References: <0J3200C45R4PGU30@jes-fe1.zx.nl> <003001c6b1b1$e52f7c20$31713b51@BEMBUSTER> <5CC1ED2B-7867-418F-8B7A-04FA9E80531F@estacado.net> Date: Thu, 27 Jul 2006 21:54:56 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.2 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Cc: sip@ietf.org Subject: [Sip] Re: RFC4320 and 408 to non-INVITE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1744111120==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1744111120== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C6B1C7.4C46E280" This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C6B1C7.4C46E280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable inline ----- Original Message -----=20 From: Robert Sparks=20 To: Jeroen van Bemmel=20 Cc: sip@ietf.org=20 Sent: Thursday, July 27, 2006 9:48 PM Subject: Re: RFC4320 and 408 to non-INVITE So, specifically, that table says: SIP Timer Value to be applied between IM CN subsystem elements = Value to be applied at the UE Value to be applied at the P-CSCF toward a = UE Meaning=20 T1 500ms default 2s default 2s default RTT estimate=20 So the P-CSCF and the UE are both using 2s for T1. When the P-CSCF talks to other things (that are not the UE), it uses = 500ms for T1. What you were describing would be the P-CSCF using 500ms on its side = of a transaction it was in with a UA that was using 2s, which is not what this table says to do. In that = case, yes, undefined things can happen. Then perhaps I was not clear enough. What I meant was the UA using = T1=3D2000 towards the P-CSCF, and the P-CSCF using T1=3D500 towards the = S-CSCF. If the latter transaction times out (after 64*500=3D32 seconds), = it seems to me that the P-CSCF should send a 408 response towards the = UA. If not, it will keep retransmitting until 64*2000 =3D 128 seconds = (all assuming UDP of course) Regards, Jeroen RjS On Jul 27, 2006, at 2:21 PM, Jeroen van Bemmel wrote: This is not the way the timers are meant to be changed. Both of the transaction-stateful things on either end of a given = transaction must share the same values for the transaction timers or the results are not defined. What you describe is not unlike throwing away the timing belt in = an engine and spinning the head at some rate unrelated to the crankshaft. You might get = lucky, but usually very bad things are going to happen. That's interesting, because it is exactly what is prescribed for IMS Refer to TS 24.229 release 7 table 7.8 "SIP Timers" = (http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-740.zip, = page 132 for me) It says: Value to be applied at the UE: T1 =3D 2s default Value to be applied between IM CN subsystem elements: T1=3D500ms = default So you are saying that in IMS configured this way, very bad things = will happen? Regards, jeroen RjS On Jul 27, 2006, at 12:29 PM, Jeroen Van Bemmel wrote: Robert, RFC4320 bans 408 responses to NIT, but I think there are = situations in which it is still useful and needed. In particular, = consider when the UAC is using T1=3D2000 and the proxy uses T1=3D500 = (eg because the client is on a slow wireless link) The CT at the proxy times out after 64*T1=3D32 sec, while the = client is still retransmitting. In this case, 408 does help Regards, Jeroen ------=_NextPart_000_005B_01C6B1C7.4C46E280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
inline
----- Original Message -----
From:=20 Robert=20 Sparks
Sent: Thursday, July 27, 2006 = 9:48=20 PM
Subject: Re: RFC4320 and 408 to = non-INVITE

So, specifically, that table says:
SIP Timer
Value to be applied between = IM CN=20 subsystem elements
Value to be applied at the=20 UE
Value to be applied at the = P-CSCF=20 toward a UE
Meaning
T1
500ms default
2s default
2s default
RTT estimate

So the P-CSCF and the = UE are both=20 using 2s for T1.
When the P-CSCF talks to other things (that are not the UE), it = uses=20 500ms for T1.

What you were describing would be the P-CSCF using 500ms on its = side of a=20 transaction it was in with a
UA that was using 2s, which is not what this table says to do. In = that=20 case, yes, undefined things can happen.
 
Then perhaps I was not clear=20 enough. What I meant was the UA using T1=3D2000 towards the P-CSCF, = and the=20 P-CSCF using T1=3D500 towards the S-CSCF. If the latter transaction = times out=20 (after 64*500=3D32 seconds), it seems to me that the P-CSCF should send = a 408=20 response towards the UA. If not, it will keep retransmitting until = 64*2000 =3D 128=20 seconds (all assuming UDP of course)
 
Regards,
 
Jeroen
 

RjS

On Jul 27, 2006, at 2:21 PM, Jeroen van Bemmel wrote:
This is not the way the timers are = meant to be=20 changed.

Both of the transaction-stateful things = on either=20 end of a given transaction must share the same
values for the transaction timers or = the results=20 are not defined.

What you describe is not unlike = throwing away the=20 timing belt in an engine and spinning
the head at some rate unrelated to the=20 crankshaft. You might get =20 lucky, but usually very bad things
are going to happen.

That's interesting, because it is exactly = what is=20 prescribed for IMS

Refer to TS 24.229 release 7 table 7.8 = "SIP Timers"=20 (http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-740.zip= ,=20 page 132 for me)

It says:
Value to be applied at the UE: T1 =3D 2s=20 default
Value to be applied between IM CN = subsystem=20 elements: T1=3D500ms default

So you are saying that in IMS configured = this way,=20 very bad things will happen?

Regards,

jeroen


RjS

On Jul 27, 2006, at 12:29 PM, Jeroen = Van Bemmel=20 wrote:

Robert,

RFC4320 bans 408 responses to NIT, = but I think=20 there are situations  = in=20 which it is still useful and needed. In particular, = consider  when the UAC is = using T1=3D2000=20 and the proxy uses T1=3D500 (eg because  the client is on a = slow=20 wireless link)

The CT at the proxy times out after = 64*T1=3D32=20 sec, while the client  = is=20 still retransmitting. In this case, 408 does help

Regards,
Jeroen


------=_NextPart_000_005B_01C6B1C7.4C46E280-- --===============1744111120== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1744111120==-- From sip-bounces@ietf.org Thu Jul 27 16:03:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6C2w-0006DX-FK; Thu, 27 Jul 2006 16:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6C2v-0006DP-C3; Thu, 27 Jul 2006 16:01:25 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6C2q-0003OM-HS; Thu, 27 Jul 2006 16:01:25 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Jul 2006 13:01:20 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RK1Jdv023356; Thu, 27 Jul 2006 13:01:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6RK1E2N010143; Thu, 27 Jul 2006 13:01:19 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 13:01:15 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.35]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 13:01:15 -0700 Message-Id: <4.3.2.7.2.20060727145900.03a78f70@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2006 15:01:13 -0500 To: "Brian Rosen" , "'Andrew Newton'" From: "James M. Polk" In-Reply-To: <005701c6b1ae$7a54ee10$640fa8c0@cis.neustar.com> References: <44C908FC.2050303@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 20:01:15.0182 (UTC) FILETIME=[6A937CE0:01C6B1B7] DKIM-Signature: a=rsa-sha1; q=dns; l=2019; t=1154030479; x=1154894479; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Geopriv]=20Teasing=20apart=3A=20constraints=20on=20dereference= 20URI; X=v=3Dcisco.com=3B=20h=3D2ZXvxTPHx5E5TqwDVEGu6mXgGN4=3D; b=Rlb30PNBdBY0dFDh5S8m4SlQpYHZ/uKalwF7V5qm0skey7EvBPPSd21ybzn+tuMCt4As3kDi ZNzDjqU94eHgwhA/Jl+/E6/aQnidpauxjDtvWB8Bu/F1JeuWJZ1kuvB/; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 'IETF SIP List' , 'GEOPRIV' Subject: [Sip] RE: [Geopriv] Teasing apart: constraints on dereference URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 02:57 PM 7/27/2006 -0400, Brian Rosen wrote: >It just seems so unlikely to me that geopriv would sanction any URI >dereference mechanism that didn't have an RFC it could inject its review >into. It's got to be limited to things that are RFCs. We can argue about >whether it has to be standards track, we can argue about if the limit is >enforced with ABNF, IANA registration or normative wording, but it's gotta >be an RFC. I vote for Standards Track, with Geopriv review, this takes care of all of the above. If extensions to this doc are in the Geopriv WG, it really takes care of all of it. >Brian > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Thursday, July 27, 2006 2:42 PM > > To: James M. Polk > > Cc: IETF SIP List; GEOPRIV > > Subject: Re: [Geopriv] Teasing apart: constraints on dereference URI > > > > James M. Polk wrote: > > >> Finally, how many people desire a middle ground? Perhaps where the > > >> ABNF, XML Schema or other grammar specification allows for any URI > > >> scheme but there is an IANA registry listing the allowed dereference > > >> URI schemes and associated protocols? > > > > > > I think any IANA Registry here will point back to a Standards Track RFC > > > that defined the usage and semantics, which your question is not > > > allowing. Therefore, for what you have immediately above, I disagree. > > > > I guess that may have been too much hand waving on my part. So let me > > ask you this question: if the grammar were to only specify "URI" and no > > particular kind of URI, yet the kinds of URIs allowed must have to pass > > some sort of review before their use in the Location header is > > considered acceptable, would you find favor in this approach? > > > > And if so, how would you implement it? > > > > -andy > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 16:07:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6C6j-0001zK-6i; Thu, 27 Jul 2006 16:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6C6i-0001z9-4o for sip@ietf.org; Thu, 27 Jul 2006 16:05:20 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6C6g-0004le-Po for sip@ietf.org; Thu, 27 Jul 2006 16:05:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2006 13:05:18 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,189,1151910000"; d="scan'208"; a="33629908:sNHT24948336" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RK5Iw6001659; Thu, 27 Jul 2006 16:05:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6RK5HdU017528; Thu, 27 Jul 2006 16:05:18 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 16:05:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Hitchhikers guide - when is it done? Date: Thu, 27 Jul 2006 16:05:13 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301BF857F@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Hitchhikers guide - when is it done? Thread-Index: AcawM2bN59vArd7vSNO+jdmqjdyVYgBhG2kg From: "Michael Hammer \(mhammer\)" To: "Vijay K. Gurbani" , "Jonathan Rosenberg \(jdrosen\)" X-OriginalArrivalTime: 27 Jul 2006 20:05:14.0519 (UTC) FILETIME=[F93B6A70:01C6B1B7] DKIM-Signature: a=rsa-sha1; q=dns; l=3140; t=1154030718; x=1154894718; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Hitchhikers=20guide=20-=20when=20is=20it=20done? |To:=22Vijay=20K.=20Gurbani=22=20, =0A=20=20=20=20=20=20=20=2 0=22Jonathan=20Rosenberg=20\(jdrosen\)=22=20; X=v=3Dcisco.com=3B=20h=3DMv7yj3PuEbZ8msTThY0bXHMVaJU=3D; b=kMfgNiLeBDRSfiQVe+CxMv2msMKW6qUCChCt4VhF19BmWarMSz8kh/B+ytm1MbMhUe6aQZj6 rMpRJI4xhH6Uk6w1xG1MZRGlq6DI2Hq8hwb99MPieHhOCc4xtTu7wTsE; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Then we will need an RFC to point to the index RFCs that point to the base RFCs? A single RFC pointing document would be best. Mike =20 > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com]=20 > Sent: Tuesday, July 25, 2006 5:43 PM > To: Jonathan Rosenberg (jdrosen) > Cc: IETF SIP List > Subject: Re: [Sip] Hitchhikers guide - when is it done? >=20 > Sorry for being the voice out on the left field, but I think=20 > 1 is better. Once the 'core' documents have RFC numbers, it=20 > makes sense to go ahed and publish that as an Informational=20 > (maybe name it "A Hitchhikers Guide to SIP - Part 1: Core=20 > Specification"). >=20 > Then deal with the current I-Ds and other work as a separate=20 > Informational, probably named "A Hitchhikers Guide to SIP -=20 > Part 2: Extensions". The first RFC will have an informative=20 > reference to the second to-be RFC, so readers can be warned=20 > that the document is split into to (plus the naming=20 > convention of the title is a clue). >=20 > With Part 2 being in flux for a while, I would presume that=20 > it would be easier from a process point of view to rev a I-D=20 > than it is to obsolete or update a RFC. >=20 > Plus there is some poetic justice in the SIP WG closing doors=20 > when the last RFC issued is one that (partially) summarizes=20 > what we have done as a WG. Too bad RFC number 4242 is already taken. >=20 > Thanks. >=20 > Jonathan Rosenberg wrote: > > During the IETF meeting, I discussed the one current open=20 > issue in the=20 > > Hitchhikers guide. The issue is: when does the document=20 > finish? When=20 > > do we send to IESG to issue an RFC? > >=20 > > There were two approaches: > >=20 > > 1. split the document in two. One part contains only the=20 > core specs,=20 > > and issues relatively soon. The other part has everything else, and=20 > > basically ends up being the last RFC produced by the SIP WG=20 > before it=20 > > shuts its doors (which has always been 1.5 years from now=20 > for the last=20 > > 5 years). > >=20 > > 2. keep it as one document. Issue an RFC at some point, and then=20 > > revise it a few times as needed. We need to decide when to issue it. > >=20 > >=20 > > I'd like to propose option 2. I think people get more value=20 > from it as=20 > > a consolidated document. Furthermore, I'd propose that we send the=20 > > document to IESG for consideration as informational at the=20 > instant all=20 > > of the documents listed as 'core' have RFC numbers issued by RFC-ed. > >=20 > > Comments? >=20 > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Bell Laboratories, Lucent Technologies, Inc. > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 16:18:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CHv-0001L8-SJ; Thu, 27 Jul 2006 16:16:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CHu-0001K6-OK; Thu, 27 Jul 2006 16:16:54 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6CHu-0006pr-Dp; Thu, 27 Jul 2006 16:16:54 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6RKGsox003763; Thu, 27 Jul 2006 20:16:54 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 16:16:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jul 2006 16:16:53 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F4518@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Sip] teasing apart: http asa GEOPRIV using protocol Thread-Index: Acaxs6cwsDyyueYlTP2XFz05IyoN/AAAB2ug From: "Peterson, Jon" To: "IETF SIP List" , "GEOPRIV" X-OriginalArrivalTime: 27 Jul 2006 20:16:54.0083 (UTC) FILETIME=[9A346930:01C6B1B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: Subject: [Sip] using protocols X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org While I tend to agree with the sentiment that the term "using protocol" = has been lawyered into obsolence in this discussion, I do think the term = remains material to the scope of the location conveyance draft, and the = question of how restrictive or permissive the URI schemes defined for = the Location header might be. Strictly speaking, when a SIP message carries only a reference to = location information, it isn't really "conveying" location at all - the = protocol that is used to follow that reference and retrieve location = information is the "using protocol" as understood in RFC3693. Placing a = CID, or SIP/SIPS, and for the most part PRES URI scheme in the Location = header are all cases where SIP does or will do the work of conveyance, = and will serve as a using protocol. That seems to me to be as good a = reason as any to draw a line in the sand and say that these schemes are = what the baseline SIP location conveyance draft will cover. I.e., When a = SIP/SIPS URI appears in the Location header, the location will end up = being conveyed by SIP; it seems pretty reasonable for the SIP location = conveyance draft to cover this case. I don't think that the syntax of the Location header should forbid the = use of any particular URI schemes. Moving forward there's no obstacle to = a separate draft defining HTTP conveyance or whatever else. The early = failures of the GEOPRIV working group to arrive at a consensus on an = approach to HTTP were mostly caused by the use cases which were being = proposed, which were out of parity with much of what the rest of the = group was trying to accomplish (and by "early" here I mean pre-HELD by a = long shot). Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, July 27, 2006 12:27 PM > To: Henning Schulzrinne > Cc: IETF SIP List; GEOPRIV; Andrew Newton > Subject: Re: [Geopriv] Re: [Sip] teasing apart: http asa GEOPRIV using > protocol >=20 >=20 > Hi Henning, >=20 > I would very much appreciate to treat this topic in the way=20 > you proposed=20 > it below. >=20 > A few minor comments: >=20 > Henning Schulzrinne wrote: > > With hindsight, I think the term 'using protocol' has been=20 > the source of=20 > > more word-lawyering than engineering insight. I personally=20 > find the=20 > > distinctions > >=20 > > - first person vs. third person (i.e., find out location=20 > about myself=20 > > vs. find out location about some third party) > >=20 > > - location vs. location + identity > >=20 > > - token-based authorization vs. identity-based authorization > >=20 > > more helpful. > >=20 > > Token-based authorization hands the recipient a key that=20 > allows him to=20 > > get a location object, without caring as to who is retrieving the=20 > > object. ("Anybody seeing this SIP request can convert the=20 > token into an=20 > > LO.") Identity-based naturally uses some authenticated identity to=20 > > release that information. >=20 >=20 > In past common policy discussions we also differentiated between=20 > limited use addresses and trait-based authorization. A token=20 > would match=20 > the latter. >=20 > In some sense we seem to be using limited use addresses in=20 > most of the=20 > cases when we talk about the location-by-references. The difference=20 > between limited use addresses and trait-based authorization=20 > is small in=20 > this particular usage environment. >=20 >=20 > Strictly speaking, this is only a question of > > a level of indirection, since proving identity usually=20 > involves proving=20 > > possession of a secret. >=20 > I guess there are some further differences with regard to the=20 > lifetime=20 > of the different identifiers, the ability to revoke rights,=20 > the number=20 > of entities that one can hide behind these identifiers and=20 > the storage=20 > implications. >=20 > > We've been trying to get at some of these distinctions with=20 > the sighting=20 > > vs. using protocol terminology, but that distinction also seems to=20 > > degenerate into discussions more suited for a law school or=20 > theology=20 > > department than an engineering organization. > >=20 > > For example, by strict definition, LoST would be a 'Using Protocol'=20 > > since it "carries a Location Object", but I hope we all=20 > agree that this=20 > > is silly. We had earlier agreed that the location-by-DHCP=20 > also were not=20 > > Using Protocol, even though they obviously carry a location=20 > object of=20 > > some form. >=20 > Currently LoST is not a using protocol since it does not=20 > carry a PIDF-LO=20 > although some folks would like to use a PIDF-LO; HELD was a using=20 > protocol before we turned the problem into a Location Configuration=20 > problem; RELO never was a using protocol; >=20 > Isn't this confusing? >=20 > >=20 > > Privacy issues apply iff > > - third person > > - location + identity (not just location) > >=20 > > The L7 discussion was about 'first person' and 'location=20 > only' (although=20 > > the latter is subject to debate, depending on whether one=20 > considers an=20 > > IP address of identifying an individual or not). >=20 > That was before we added the Location-by-Reference and=20 > subscription-URI=20 > concept .... >=20 > >=20 > > Depending on the circumstances, SIP-based retrieval can=20 > either involve=20 > > privacy concerns (subscribe to alice@example.com) or not=20 > (subscribe to=20 > > location of one-time random unlinkable identifier=20 > > jdfa8f9348@example.com). There can also be different=20 > privacy concerns=20 > > depending on the perspective. For example, if a SIP request=20 > contains=20 > > both an identity and the location retrieval reference, this raises=20 > > privacy concerns for the proxy, but the LIS may not have any such=20 > > concerns since it may only be the repository of these=20 > randomly-named=20 > > objects, without tie to an identity. >=20 > Ciao > Hannes >=20 > > Henning > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 > >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 16:46:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CiG-0002VD-08; Thu, 27 Jul 2006 16:44:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CiD-0002QK-S0 for sip@ietf.org; Thu, 27 Jul 2006 16:44:05 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6CiB-0005Pl-Bo for sip@ietf.org; Thu, 27 Jul 2006 16:44:05 -0400 Received: from [172.17.2.252] ([172.17.2.252]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k6RKgla3058818 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Jul 2006 15:42:47 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <005e01c6b1b6$88e91a20$31713b51@BEMBUSTER> References: <0J3200C45R4PGU30@jes-fe1.zx.nl> <003001c6b1b1$e52f7c20$31713b51@BEMBUSTER> <5CC1ED2B-7867-418F-8B7A-04FA9E80531F@estacado.net> <005e01c6b1b6$88e91a20$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: <490FFFB3-97EB-4B0D-A9C0-756DD7E0319A@estacado.net> From: Robert Sparks Date: Thu, 27 Jul 2006 15:42:46 -0500 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.3 (/) X-Scan-Signature: d2bb8c7db26f2d12109e0cd8e454db52 Cc: sip@ietf.org Subject: [Sip] Re: RFC4320 and 408 to non-INVITE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2045205308==" Errors-To: sip-bounces@ietf.org --===============2045205308== Content-Type: multipart/alternative; boundary=Apple-Mail-16--367892713 --Apple-Mail-16--367892713 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Yeah - I definitely needed that clarification for the problem you are describing. What you are describing now is a special case of something that is not timer specific. The general case is that of a proxy where all possible downstream legs have failed before the original request times out, but none of those legs provided a SIP response that was suitable for forwarding as the "best" response. For instance, each of the downstream legs could have produced an ICMP error immediately. The response to send in this situation is 480. RjS On Jul 27, 2006, at 2:54 PM, Jeroen van Bemmel wrote: > inline > ----- Original Message ----- > From: Robert Sparks > To: Jeroen van Bemmel > Cc: sip@ietf.org > Sent: Thursday, July 27, 2006 9:48 PM > Subject: Re: RFC4320 and 408 to non-INVITE > > So, specifically, that table says: > SIP Timer > Value to be applied between IM CN subsystem elements > Value to be applied at the UE > Value to be applied at the P-CSCF toward a UE > Meaning > T1 > 500ms default > 2s default > 2s default > RTT estimate > > > So the P-CSCF and the UE are both using 2s for T1. > When the P-CSCF talks to other things (that are not the UE), it > uses 500ms for T1. > > What you were describing would be the P-CSCF using 500ms on its > side of a transaction it was in with a > UA that was using 2s, which is not what this table says to do. In > that case, yes, undefined things can happen. > > Then perhaps I was not clear enough. What I meant was the UA using > T1=2000 towards the P-CSCF, and the P-CSCF using T1=500 towards the > S-CSCF. If the latter transaction times out (after 64*500=32 > seconds), it seems to me that the P-CSCF should send a 408 response > towards the UA. If not, it will keep retransmitting until 64*2000 = > 128 seconds (all assuming UDP of course) > > Regards, > > Jeroen > > > RjS > > On Jul 27, 2006, at 2:21 PM, Jeroen van Bemmel wrote: > >>> This is not the way the timers are meant to be changed. >>> >>> Both of the transaction-stateful things on either end of a given >>> transaction must share the same >>> values for the transaction timers or the results are not defined. >>> >>> What you describe is not unlike throwing away the timing belt in >>> an engine and spinning >>> the head at some rate unrelated to the crankshaft. You might get >>> lucky, but usually very bad things >>> are going to happen. >> >> That's interesting, because it is exactly what is prescribed for IMS >> >> Refer to TS 24.229 release 7 table 7.8 "SIP Timers" (http://www. >> 3gpp.org/ftp/Specs/archive/24_series/24.229/24229-740.zip, page >> 132 for me) >> >> It says: >> Value to be applied at the UE: T1 = 2s default >> Value to be applied between IM CN subsystem elements: T1=500ms >> default >> >> So you are saying that in IMS configured this way, very bad things >> will happen? >> >> Regards, >> >> jeroen >> >>> >>> RjS >>> >>> On Jul 27, 2006, at 12:29 PM, Jeroen Van Bemmel wrote: >>> >>>> Robert, >>>> >>>> RFC4320 bans 408 responses to NIT, but I think there are >>>> situations in which it is still useful and needed. In >>>> particular, consider when the UAC is using T1=2000 and the >>>> proxy uses T1=500 (eg because the client is on a slow wireless >>>> link) >>>> >>>> The CT at the proxy times out after 64*T1=32 sec, while the >>>> client is still retransmitting. In this case, 408 does help >>>> >>>> Regards, >>>> Jeroen >> > > --Apple-Mail-16--367892713 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Yeah - I definitely needed that = clarification for the problem you are describing.

What you are describing now = is a special case of something that is not timer
specific. The = general case is that of a proxy where all possible = downstream
legs have failed before the original request times = out, but none of those legs
provided a SIP response that was = suitable for forwarding as the "best" response.

For instance, each of the = downstream legs could have produced an ICMP = error
immediately.

The response to send in = this situation is 480.

RjS


On Jul 27, 2006, = at 2:54 PM, Jeroen van Bemmel wrote:

----- Original Message -----
Cc:

So, specifically, that table = says:
SIP Timer
Value to be applied between IM CN subsystem = elements
Value = to be applied at the UE
Value = to be applied at the P-CSCF toward a UE
Meaning
500ms default
2s default
2s default
RTT estimate

So the P-CSCF and the UE are both = using 2s for T1.
When the P-CSCF talks to other = things (that are not the UE), it uses 500ms for T1.

What you were describing = would be the P-CSCF using 500ms on its side of a transaction it was in = with a
UA that was using 2s, which is not what this table says = to do. In that case, yes, undefined things can happen.
=A0
=A0
=A0
Jeroen
=A0

RjS

On = Jul 27, 2006, at 2:21 PM, Jeroen van Bemmel wrote:

This is not = the way the timers are meant to be changed.

Both of the transaction-stateful things on either end = of a given transaction must share the same
values for = the transaction timers or the results are not defined.

What you describe is not unlike throwing away the = timing belt in an engine and spinning
the head at some rate unrelated to the = crankshaft. You might get=A0 lucky, but = usually very bad things
are going to happen.

That's interesting, because it is exactly what is = prescribed for IMS

Refer to TS = 24.229 release 7 table 7.8 "SIP Timers" (
It = says:




= --Apple-Mail-16--367892713-- --===============2045205308== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2045205308==-- From sip-bounces@ietf.org Thu Jul 27 17:06:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6D26-00016N-Bu; Thu, 27 Jul 2006 17:04:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6D24-00015P-Kg; Thu, 27 Jul 2006 17:04:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6D24-0007Ng-Hq; Thu, 27 Jul 2006 17:04:36 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G6D23-0004DG-Nq; Thu, 27 Jul 2006 17:04:36 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns3.neustar.com (Postfix) with ESMTP id 84639175B0; Thu, 27 Jul 2006 21:04:05 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 17:04:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jul 2006 17:04:03 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How Location Conveyance specifies the allowed URI Thread-Index: AcaxwDDgZTB/z9TcSxir+nsBrJBJzg== From: "Rosen, Brian" To: "IETF SIP List" , "GEOPRIV" X-OriginalArrivalTime: 27 Jul 2006 21:04:05.0205 (UTC) FILETIME=[31AF5850:01C6B1C0] X-Spam-Score: -5.0 (-----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Sip] How Location Conveyance specifies the allowed URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Trying, trying, .... It seems we have a very rough consensus that there will be some normative text that specifies the allowable URI schemes for what can be in the location header. There are still some voices in opposition to it, but I think we've heard all the relevant points we're going to get. I had made a specific proposal on this: location-param =3D LAQUOT allowed-URI RAQUOT *( SEMI loc-param )=20 ;cid-url from RFC2111, http_URL from RFC2616, SIP/SIPS-URI from RFC3261, PRES-URI from RFC3859=20 allowed-URI =3D cid-uri / http_URL / https_URL / SIP-URI / SIPS-URI / PRES-URI As we seem to be developing another rough consensus on NOT defining an HTTP dereference mechanism IN THE LOCATION-CONVEYANCE DOCUMENT, this would now be: location-param =3D LAQUOT allowed-URI RAQUOT *( SEMI loc-param )=20 ;cid-url from RFC2111, SIP/SIPS-URI from RFC3261, PRES-URI from RFC3859=20 allowed-URI =3D cid-uri / SIP-URI / SIPS-URI / PRES-URI The text would say extensions to this list is by (?standards-track?) RFC requiring geopriv review as a "using" protocol, but is not a SIP change. A hypothetical http dereference RFC would have the following ABNF: ;allowed-URI from , http_URL from RFC2616 allowed-URI =3D/ http_URL / https_URL The alternative is to use "AbsoluteURI", and to say roughly the same thing about RFCs and geopriv review. I prefer being explicit. The = "=3D/" construction is very simple and very explicit.=20 Can we accept this "allowed-URI" proposal and move on? Does it have to be standards track, or is Informational okay? I would think informational is okay, provided geopriv reviews. For example, if some other organization came along and defined a protocol that worked, and met the geopriv requirements, an informational saying that the way you use this with SIP Location is blah, blah, blah, I would think, provided geopriv agreed it met their concerns, that would be okay (even with the ABNF extension to allowed-URI in the Informational)=20 Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 17:11:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6D7W-00050g-N4; Thu, 27 Jul 2006 17:10:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6D7U-00050W-Lg; Thu, 27 Jul 2006 17:10:12 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6D7T-00016q-Ca; Thu, 27 Jul 2006 17:10:12 -0400 Received: from lion.cs.columbia.edu (IDENT:E+U9aNfI1DAikkiQW08Hc/Ett/NJV+wR@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6RLA64F024232 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 27 Jul 2006 17:10:07 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6RLA5rh025458 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Jul 2006 17:10:06 -0400 Message-ID: <44C92BA8.8000300@cs.columbia.edu> Date: Thu, 27 Jul 2006 17:10:00 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Rosen, Brian" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.27.134932 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IETF SIP List , GEOPRIV Subject: [Sip] Re: [Geopriv] How Location Conveyance specifies the allowed URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If HTTP and other mechanisms are not defined in the draft (with which I agree), I see no technical reason not to allow other URI schemes in the draft ABNF. At least from the voices I heard, my proposal of not restricting the URI scheme has received at least as much support as countervailing proposals, so I don't know now how you're counting rough consensus. Or are there supervotes? Rosen, Brian wrote: > Trying, trying, .... > > It seems we have a very rough consensus that there will be some > normative text that specifies the allowable URI schemes for what can be > in the location header. There are still some voices in opposition to > it, but I think we've heard all the relevant points we're going to get. > I had made a specific proposal on this: > > location-param = LAQUOT allowed-URI RAQUOT *( SEMI loc-param ) > ;cid-url from RFC2111, http_URL from RFC2616, SIP/SIPS-URI from RFC3261, > PRES-URI from RFC3859 > allowed-URI = cid-uri / http_URL / https_URL / SIP-URI / SIPS-URI > / PRES-URI > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 17:21:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6DGs-0000w7-28; Thu, 27 Jul 2006 17:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6DGp-0000tv-Lw for sip@ietf.org; Thu, 27 Jul 2006 17:19:51 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6DGn-0002zE-Qg for sip@ietf.org; Thu, 27 Jul 2006 17:19:51 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Jul 2006 14:19:49 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RLJnY1012118 for ; Thu, 27 Jul 2006 14:19:49 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6RLJm2D005495 for ; Thu, 27 Jul 2006 14:19:49 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 17:19:48 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 17:19:48 -0400 Message-ID: <44C92DF3.9000602@cisco.com> Date: Thu, 27 Jul 2006 17:19:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: SIP IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 21:19:48.0265 (UTC) FILETIME=[63CAE190:01C6B1C2] DKIM-Signature: a=rsa-sha1; q=dns; l=10857; t=1154035189; x=1154899189; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Review=20of=20draft-ietf-sip-gruu-09; X=v=3Dcisco.com=3B=20h=3Dtjb/Z70e6YDg5R18TWbW2/rkEac=3D; b=dC5qXLgSAcdxh/6tpy0WBWSF2MJIpLUWQDaktJER/f2AptrZNbSmWX3ZL9Bm5y0G3kKlr6oT LSYjEN9N+Z18nAZHpESVI5VliAfsVNxoZVPdHuGRohS5iug4hxpC7g9l; Authentication-Results: sj-dkim-4.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: Subject: [Sip] Review of draft-ietf-sip-gruu-09 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I did a reasonably careful review of draft-ietf-sip-gruu-09. I was mostly looking for remaining technical issues rather than formatting nits. For awhile now I have mostly be looking at diffs as new versions come out and reading selected sections at need. It was good to read the whole thing again to see how it all hangs together. I found nothing really major, but some stuff that is more than editorial. Some of it is a judgment call about whether something is clear or not. I won't feel bad to have a number of these comments rejected. Paul General comment: SIPS is mentioned in many places in this draft. Given the current ongoing issues wrt SIPS, the language here for dealing with it may prove to be prescient, or may turn out to just be wrong. Can this be dodged somehow? Maybe this whole draft should only be defined for SIP, with SIPS left for a separate draft. (I will still comment on some places containing SIPS, when there are other points than the above.) Section 5: ... The "opaque" parameter is added by the owner of the domain to correlate the GRUU to its instance ID, and to easily recognize that the URI has the GRUU property. I think this isn't quite right. The "gruu" parameter may be used to recognize the GRUU property. How about: ... The "opaque" parameter is added by the owner of the domain to correlate the GRUU to its instance ID, and potentially to help verify that the GRUU has not been forged. Figure 1: Its unfortunate that pictures such as this lead to many questions, often irrelevant ones. I know we have discussed nuances of this one before. - as shown, a contact is bound to 1 AOR, at most one Instance ID and at most one GRUU. In practice is is possible to bind the same contact to multiple AORs if one doesn't need to distinguish between them or has some other means to do so. (And section 7.1.1.1 allows it, since restriction to a single AOR is only RECOMMENDED.) It is also possible that the same contact will be associated with more than one Instance ID. (Ideally there is only one such association at any one time, but over time it may change.} - the figure doesn't show what is in the text: A GRUU is associated, in a many-to-one fashion, with the combination of an instance ID and an AOR. This combination is referred to as an instance ID/AOR pair. For each GRUU, there is one instance ID/AOR pair, and for each instance ID/AOR pair, there can be one or more GRUU. (The picture doesn't show anything associated with an AOR/Instance ID pair.) I think it is too hard to make a picture that expresses these relationships accurately, and this should be done with text, without the figure. Section 6: o For each GRUU, both the SIP and Session Initiation Protocol Secure (SIPS) versions MUST exist. The SIPS URI may not always work, particularly if the proxy cannot establish a secure connection to the client. However, the SIPS URI always exists. The use of "always" seems problematic. The lifetime of the gruu itself is not "always". It is no longer than the associated AOR. Also, this goes into the previous discussion of relationships. Are the SIP and SIPS forms *separate* AORs, or the same AOR? I'm struggling here to come up with something that threads the needle. How about: o When both SIP and SIPS AORs identify the same resource, and the AORs differ only in the scheme name, then when a GRUU is assigned to the resource, both SIP and SIPS GRUUs will be assigned. Only one will be returned, but both will exist. The SIPS URI may not always work, particularly if the proxy cannot establish a secure connection to the client. Section 7.1.1.1: Specifically, the contact in the REGISTER request SHOULD NOT contain the gruu Contact header field parameter, and the contact URI itself SHOULD NOT contain the "grid" URI parameter defined below. Any such parameters are ignored by the registrar, as the UA cannot propose a GRUU for usage with the contact. Nit: the last sentence is a little weird, because the "as" clause only applies to gruu, not grid. Perhaps: Any such parameters are ignored by the registrar and not stored. (The UA cannot propose a GRUU for usage with the contact, and the grid parameter is populated from the GRUU, not the registered contact.) BUT, later I instead suggest treating the presence of grid as an error rather than ignoring it. That requires different wording here. Later in the section: ... However, it is permitted for a UA to register any kind of contact it wishes, including a GRUU. A typical use case for registering a GRUU is if a user wanted calls to one AOR to be delivered to a specific UA instance associated with another AOR. I just realized this presents a problem wrt grid processing. If the contact is a gruu associated with a different AOR, then it could also contain a grid parameter, and if so, that parameter might be important. One wouldn't want to lose it, or override it. Perhaps it should be an *error* to register a contact that contains a grid URI parameter. That would prevent any confusion. Section 7.1.1.2: ... The URI will be a SIP URI if the To header field in the REGISTER request contained a SIP URI, else (if the To header field in the REGISTER request contained a SIPS URI) it will be a SIPS URI. (more sips stuff) ... Normally, the GRUU will not change in subsequent 2xx responses to REGISTER. Indeed, even if the UA lets the contact expire, when it re-registers it at any later time, the registrar will normally provide the same GRUU for the same address-of-record and instance ID. However, as discussed above, this property cannot be completely guaranteed, as network failures may make it impossible to provide an identifier that persists for all time. As a result, a UA MUST be prepared to receive a different GRUU for the same instance ID/AOR pair in a subsequent registration response. As written, this puts a burden on a UA. Any time it refreshes a registration a previously assigned gruu may change. That gruu may be in use in a dialog. Then the UA would have to to a target refresh to fix it. That is a lot to ask, and has potential race conditions if the prior gruu has become invalid. IMO it would be better to put the burden on the registrar to keep the gruu the same for as long as a registration remains active. I think it might also be good to insert a note into this section: NOTE: the 2xx response to REGISTER returns all the contacts bound to the AOR. This may include contacts bound by other UAs. Any or all of these may include a "gruu" Contact header field parameter. The UA is responsible for extracting and saving the GRUU assigned to the contact(s) it has registered. Section 7.1.2: A registrar MUST create both the SIP and SIPS versions of the GRUU, such that if the GRUU exists, both URI exist. (more sips stuff) Section 7.1.2.1: Nothing is mentioned in this section about handling of a "grid" URI parameter in the contact. If this is present it can screw things up in a variety of ways. This is sufficiently severe that it probably isn't wise to just ignore it if present. Instead, should probably reject the request. (403 again?) The problems that can result: - regular calls to the AOR will look (to the UE) like calls to a gruu - if the contact was itself a GRUU, and had a particular grid value for some purpose, then when calls are made to the gruu assigned as part of this registration, the grid value will be messed up. (Note that forbidding grid values here doesn't fully solve the problem. Using a gruu as a contact in another registration has unresolvable problems about the namespace for grid values. It can only work right if the two share a common namespace for the values.) Same section: ... If the To header field in the REGISTER request contains a SIP URI, the SIP version of the GRUU is returned. If the To header field in the REGISTER request contains a SIPS URI, the SIPS version of the GRUU is returned. (more sips stuff) Section 8.1.1: When using a GRUU as a remote target, a UA MAY add the "grid" URI Maybe its just me, but here and elsewhere I am confused by use of the term "remote target". In a dialog, I think of the "remote target" as the R-URI I use to reference the *other* end of the dialog. I would then expect the term "local target" to refer to the URI I expect the other end to use in the R-URI of requests addressed to me. But I think you are using it differently. In the above, I am left wondering if others who receive my GRUU will be filling in the grid parameter. Of course this is wrong, but I can read it that way. If you agree this is an issue, I guess it will require a careful laundering of all the places that use the term "remote target". Section 8.2.1: First, I think it would be worthwhile to add a statement at the beginning of this section stating that this only applies when there are no Route headers. Maybe this is obvious, but maybe not. Stating this removes any ambiguity about how a Path header interacts with existing Route headers. The first paragraph could be interpreted as an *alternative* to the cases mentioned in the 2nd and 3rd paragraphs. I believe it is not intended that way, and is instead just a modifier that applies regardless of which of the other cases are followed. I'm not sure that this paragraph even needs to be here. It places a dependency from this draft on -outbound behavior over and above the definition of instance id. The third paragraph already has language that covers the interaction case when both drafts are mucking with the same behavior. Later in the section ... If the grid was already present in the contact bound to the GRUU, it is overwritten in this process. As I noted earlier, this seems dangerous to me, so I think it should be prevented earlier. Section 8.2.2: The proxy that accesses the location service (called the home proxy here) MUST record-route under two circumstances. Firstly, if the home proxy receives a dialog forming request from a UA in its own domain (an originating request) whose Contact header field contains a GRUU (indicated by the presence of the "gruu" URI parameter), the proxy MUST record-route. This really only applies if the proxy is responsible for the GRUU. ================ That's all! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 17:22:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6DHr-0004FM-Sl; Thu, 27 Jul 2006 17:20:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6DHq-0004Ep-0v; Thu, 27 Jul 2006 17:20:54 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6DHo-0003DF-Be; Thu, 27 Jul 2006 17:20:53 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Jul 2006 14:20:51 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RLKplq014084; Thu, 27 Jul 2006 14:20:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6RLKgKC010537; Thu, 27 Jul 2006 14:20:51 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jul 2006 14:20:46 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.35]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 14:20:46 -0700 Message-Id: <4.3.2.7.2.20060727161611.036d62e8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2006 16:20:44 -0500 To: "Rosen, Brian" , "IETF SIP List" , "GEOPRIV" From: "James M. Polk" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 21:20:46.0307 (UTC) FILETIME=[86636330:01C6B1C2] DKIM-Signature: a=rsa-sha1; q=dns; l=2621; t=1154035251; x=1154899251; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Geopriv]=20How=20Location=20Conveyance=20specifies=20the=20allo wed=20URI; X=v=3Dcisco.com=3B=20h=3D2HzShWXzkTxt9ZRlb4AheXxzJNQ=3D; b=pOwK7mN31rVsr7N08GmS9gkHi+V7KlDinNa5UXgavwxBHrwzG18yxJ7jbwS5ScP+zrKt/H6/ iIBRjO3DX1/Gqdd2r6TMShet3PTws58Ujo9qk3g35M6qTaco0CjhHTAJ; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Subject: [Sip] Re: [Geopriv] How Location Conveyance specifies the allowed URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 05:04 PM 7/27/2006 -0400, Rosen, Brian wrote: >Trying, trying, .... > >It seems we have a very rough consensus that there will be some >normative text that specifies the allowable URI schemes for what can be >in the location header. There are still some voices in opposition to >it, but I think we've heard all the relevant points we're going to get. >I had made a specific proposal on this: > >location-param = LAQUOT allowed-URI RAQUOT *( SEMI loc-param ) >;cid-url from RFC2111, http_URL from RFC2616, SIP/SIPS-URI from RFC3261, >PRES-URI from RFC3859 >allowed-URI = cid-uri / http_URL / https_URL / SIP-URI / SIPS-URI > / PRES-URI > >As we seem to be developing another rough consensus on NOT defining an >HTTP dereference mechanism IN THE LOCATION-CONVEYANCE DOCUMENT, this >would now be: >location-param = LAQUOT allowed-URI RAQUOT *( SEMI loc-param ) >;cid-url from RFC2111, SIP/SIPS-URI from RFC3261, PRES-URI from RFC3859 >allowed-URI = cid-uri / SIP-URI / SIPS-URI / PRES-URI I think the proper cid reference is RFC 2392 >The text would say extensions to this list is by (?standards-track?) RFC >requiring geopriv review as a "using" protocol, but is not a SIP change. > >A hypothetical http dereference RFC would have the following ABNF: >;allowed-URI from , http_URL from RFC2616 >allowed-URI =/ http_URL / https_URL > >The alternative is to use "AbsoluteURI", and to say roughly the same >thing about RFCs and geopriv review. I prefer being explicit. The "=/" >construction is very simple and very explicit. > >Can we accept this "allowed-URI" proposal and move on? Does it have to >be standards track, or is Informational okay? A vote for Standards Track, as this ensures IETF LC for everyone's chance at a proposal., also so some other WG doesn't attempt to slip something by anyone (meaning "by Geopriv") >I would think >informational is okay, provided geopriv reviews. But I don't believe we can state who the reviewers are, we're limited to the type of RFC (if one is required) >For example, if some >other organization came along and defined a protocol that worked, and >met the geopriv requirements, an informational saying that the way you >use this with SIP Location is blah, blah, blah, I would think, provided >geopriv agreed it met their concerns, that would be okay (even with the >ABNF extension to allowed-URI in the Informational) > >Brian > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 17:29:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6DOW-0000d7-O0; Thu, 27 Jul 2006 17:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6DOV-0000cz-He; Thu, 27 Jul 2006 17:27:47 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6DOT-0003lV-3S; Thu, 27 Jul 2006 17:27:47 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 27 Jul 2006 14:27:45 -0700 X-IronPort-AV: i="4.07,189,1151910000"; d="scan'208"; a="331969749:sNHT25993148" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RLRiZT007270; Thu, 27 Jul 2006 14:27:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6RLRi2D013202; Thu, 27 Jul 2006 14:27:44 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jul 2006 14:27:44 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 14:27:43 -0700 Message-Id: <4.3.2.7.2.20060727162316.03493008@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2006 16:27:42 -0500 To: "Rosen, Brian" , "IETF SIP List" , "GEOPRIV" From: "James M. Polk" Subject: Re: [Sip] Re: [Geopriv] How Location Conveyance specifies the allowed URI In-Reply-To: <4.3.2.7.2.20060727161611.036d62e8@email.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 21:27:43.0976 (UTC) FILETIME=[7F569E80:01C6B1C3] DKIM-Signature: a=rsa-sha1; q=dns; l=917; t=1154035664; x=1154899664; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20Re=3A=20[Geopriv]=20How=20Location=20Conveyance=20specif ies=20the=0A=20=20allowed=20URI; X=v=3Dcisco.com=3B=20h=3DWmsYNVxkDJptwWA3lIW4E+l54jo=3D; b=Ta4Jb/cB+jCDFS6GfGJB8FqgtFUOwXotluCh1rYTwml72Ti6lgTMtxp5u4ndndr27O9kcowl YQ8f+02FBtfUH4Rx8vEm6VJ+30mJ0Ul0j6qbc4n+m41auTcTEo2mWheN; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 04:20 PM 7/27/2006 -0500, James M. Polk wrote: >>Can we accept this "allowed-URI" proposal and move on? Does it have to >>be standards track, or is Informational okay? > >A vote for Standards Track, as this ensures IETF LC for everyone's chance >at a proposal., also so some other WG doesn't attempt to slip something by >anyone (meaning "by Geopriv") As a WG chair, I should know this off the top of my head, but I'm bewildered by some of the comments here (and in another area), therefore confused... I believe that each subsequent schema proposed would be an official 'update' to this SIP RFC (to be), which is Standards Track, meaning I don't believe an INFO RFC can officially 'update' a Standards Track RFC. This would mean updating this RFC (to be) would take a Standards Track RFC, if my math is right... >>I would think >>informational is okay, provided geopriv reviews. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 17:47:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Dfh-0003wH-IV; Thu, 27 Jul 2006 17:45:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Dff-0003w4-Sj; Thu, 27 Jul 2006 17:45:31 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Dfd-0005we-HS; Thu, 27 Jul 2006 17:45:31 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G6DfS-0002e4-QW; Thu, 27 Jul 2006 16:45:19 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "Rosen, Brian" Subject: RE: [Sip] Re: [Geopriv] How Location Conveyance specifies the allowedURI Date: Thu, 27 Jul 2006 17:45:19 -0400 Message-ID: <00ca01c6b1c5$f808fc90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaxwUpMz47CCyFOSYOlkZ/aPlEtdwAAzhag In-Reply-To: <44C92BA8.8000300@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 'IETF SIP List' , 'GEOPRIV' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't claim there is a consensus on how the protocols are limited, only that they are. I don't think you are arguing that to put a URI in the Location Header makes it a protocol needing geopriv review ("using protocol" notwithstanding the wording problems). The text would have to say that, wouldn't you agree? The net effect is the same, you can't use any URI in the header, it has to be a protocol that has had geopriv review as a using protocol in an RFC. I stated why I think the allowed-URI construction is better; it makes the grammar precise and explicit. AbsoluteURI makes the grammar imprecise and implicit. What is wrong with what I proposed, and what makes no ABNF restrictions (absoluteURI) better? Using absoluteURI means that the using protocol RFC wouldn't have to have the one line ABNF extension to allowed-URI. Is that a benefit? Is there any other difference? Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, July 27, 2006 5:10 PM > To: Rosen, Brian > Cc: IETF SIP List; GEOPRIV > Subject: [Sip] Re: [Geopriv] How Location Conveyance specifies the > allowedURI > > If HTTP and other mechanisms are not defined in the draft (with which I > agree), I see no technical reason not to allow other URI schemes in the > draft ABNF. > > At least from the voices I heard, my proposal of not restricting the URI > scheme has received at least as much support as countervailing > proposals, so I don't know now how you're counting rough consensus. Or > are there supervotes? > > Rosen, Brian wrote: > > Trying, trying, .... > > > > It seems we have a very rough consensus that there will be some > > normative text that specifies the allowable URI schemes for what can be > > in the location header. There are still some voices in opposition to > > it, but I think we've heard all the relevant points we're going to get. > > I had made a specific proposal on this: > > > > location-param = LAQUOT allowed-URI RAQUOT *( SEMI loc-param ) > > ;cid-url from RFC2111, http_URL from RFC2616, SIP/SIPS-URI from RFC3261, > > PRES-URI from RFC3859 > > allowed-URI = cid-uri / http_URL / https_URL / SIP-URI / SIPS-URI > > / PRES-URI > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 17:47:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Dfk-0003yv-1g; Thu, 27 Jul 2006 17:45:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Dfi-0003xh-Lb; Thu, 27 Jul 2006 17:45:34 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Dfh-0005we-CO; Thu, 27 Jul 2006 17:45:34 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G6B2k-0008KE-RE; Thu, 27 Jul 2006 13:57:11 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'James M. Polk'" Date: Thu, 27 Jul 2006 14:57:12 -0400 Message-ID: <005701c6b1ae$7a54ee10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaxrGE1da+X72ceSdWL0dGYR1vohwAAbefQ In-Reply-To: <44C908FC.2050303@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'IETF SIP List' , 'GEOPRIV' Subject: [Sip] RE: [Geopriv] Teasing apart: constraints on dereference URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It just seems so unlikely to me that geopriv would sanction any URI dereference mechanism that didn't have an RFC it could inject its review into. It's got to be limited to things that are RFCs. We can argue about whether it has to be standards track, we can argue about if the limit is enforced with ABNF, IANA registration or normative wording, but it's gotta be an RFC. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, July 27, 2006 2:42 PM > To: James M. Polk > Cc: IETF SIP List; GEOPRIV > Subject: Re: [Geopriv] Teasing apart: constraints on dereference URI > > James M. Polk wrote: > >> Finally, how many people desire a middle ground? Perhaps where the > >> ABNF, XML Schema or other grammar specification allows for any URI > >> scheme but there is an IANA registry listing the allowed dereference > >> URI schemes and associated protocols? > > > > I think any IANA Registry here will point back to a Standards Track RFC > > that defined the usage and semantics, which your question is not > > allowing. Therefore, for what you have immediately above, I disagree. > > I guess that may have been too much hand waving on my part. So let me > ask you this question: if the grammar were to only specify "URI" and no > particular kind of URI, yet the kinds of URIs allowed must have to pass > some sort of review before their use in the Location header is > considered acceptable, would you find favor in this approach? > > And if so, how would you implement it? > > -andy > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 17:47:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Dfh-0003wH-IV; Thu, 27 Jul 2006 17:45:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Dff-0003w4-Sj; Thu, 27 Jul 2006 17:45:31 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Dfd-0005we-HS; Thu, 27 Jul 2006 17:45:31 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G6DfS-0002e4-QW; Thu, 27 Jul 2006 16:45:19 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "Rosen, Brian" Subject: RE: [Sip] Re: [Geopriv] How Location Conveyance specifies the allowedURI Date: Thu, 27 Jul 2006 17:45:19 -0400 Message-ID: <00ca01c6b1c5$f808fc90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaxwUpMz47CCyFOSYOlkZ/aPlEtdwAAzhag In-Reply-To: <44C92BA8.8000300@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 'IETF SIP List' , 'GEOPRIV' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't claim there is a consensus on how the protocols are limited, only that they are. I don't think you are arguing that to put a URI in the Location Header makes it a protocol needing geopriv review ("using protocol" notwithstanding the wording problems). The text would have to say that, wouldn't you agree? The net effect is the same, you can't use any URI in the header, it has to be a protocol that has had geopriv review as a using protocol in an RFC. I stated why I think the allowed-URI construction is better; it makes the grammar precise and explicit. AbsoluteURI makes the grammar imprecise and implicit. What is wrong with what I proposed, and what makes no ABNF restrictions (absoluteURI) better? Using absoluteURI means that the using protocol RFC wouldn't have to have the one line ABNF extension to allowed-URI. Is that a benefit? Is there any other difference? Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, July 27, 2006 5:10 PM > To: Rosen, Brian > Cc: IETF SIP List; GEOPRIV > Subject: [Sip] Re: [Geopriv] How Location Conveyance specifies the > allowedURI > > If HTTP and other mechanisms are not defined in the draft (with which I > agree), I see no technical reason not to allow other URI schemes in the > draft ABNF. > > At least from the voices I heard, my proposal of not restricting the URI > scheme has received at least as much support as countervailing > proposals, so I don't know now how you're counting rough consensus. Or > are there supervotes? > > Rosen, Brian wrote: > > Trying, trying, .... > > > > It seems we have a very rough consensus that there will be some > > normative text that specifies the allowable URI schemes for what can be > > in the location header. There are still some voices in opposition to > > it, but I think we've heard all the relevant points we're going to get. > > I had made a specific proposal on this: > > > > location-param = LAQUOT allowed-URI RAQUOT *( SEMI loc-param ) > > ;cid-url from RFC2111, http_URL from RFC2616, SIP/SIPS-URI from RFC3261, > > PRES-URI from RFC3859 > > allowed-URI = cid-uri / http_URL / https_URL / SIP-URI / SIPS-URI > > / PRES-URI > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 17:47:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Dfk-0003yv-1g; Thu, 27 Jul 2006 17:45:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Dfi-0003xh-Lb; Thu, 27 Jul 2006 17:45:34 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Dfh-0005we-CO; Thu, 27 Jul 2006 17:45:34 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G6B2k-0008KE-RE; Thu, 27 Jul 2006 13:57:11 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'James M. Polk'" Date: Thu, 27 Jul 2006 14:57:12 -0400 Message-ID: <005701c6b1ae$7a54ee10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaxrGE1da+X72ceSdWL0dGYR1vohwAAbefQ In-Reply-To: <44C908FC.2050303@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'IETF SIP List' , 'GEOPRIV' Subject: [Sip] RE: [Geopriv] Teasing apart: constraints on dereference URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It just seems so unlikely to me that geopriv would sanction any URI dereference mechanism that didn't have an RFC it could inject its review into. It's got to be limited to things that are RFCs. We can argue about whether it has to be standards track, we can argue about if the limit is enforced with ABNF, IANA registration or normative wording, but it's gotta be an RFC. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, July 27, 2006 2:42 PM > To: James M. Polk > Cc: IETF SIP List; GEOPRIV > Subject: Re: [Geopriv] Teasing apart: constraints on dereference URI > > James M. Polk wrote: > >> Finally, how many people desire a middle ground? Perhaps where the > >> ABNF, XML Schema or other grammar specification allows for any URI > >> scheme but there is an IANA registry listing the allowed dereference > >> URI schemes and associated protocols? > > > > I think any IANA Registry here will point back to a Standards Track RFC > > that defined the usage and semantics, which your question is not > > allowing. Therefore, for what you have immediately above, I disagree. > > I guess that may have been too much hand waving on my part. So let me > ask you this question: if the grammar were to only specify "URI" and no > particular kind of URI, yet the kinds of URIs allowed must have to pass > some sort of review before their use in the Location header is > considered acceptable, would you find favor in this approach? > > And if so, how would you implement it? > > -andy > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 17:50:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Dix-0005iE-2P; Thu, 27 Jul 2006 17:48:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Div-0005hB-LX; Thu, 27 Jul 2006 17:48:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Div-0006ap-FH; Thu, 27 Jul 2006 17:48:53 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G6Diu-0004rG-PD; Thu, 27 Jul 2006 17:48:53 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns3.neustar.com (Postfix) with ESMTP id 8ADE217599; Thu, 27 Jul 2006 21:48:22 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 17:48:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: [Geopriv] How Location Conveyance specifies the allowed URI Date: Thu, 27 Jul 2006 17:48:20 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: [Geopriv] How Location Conveyance specifies the allowed URI Thread-Index: Acaxw4COV66OdKXpSLq+QQoHL6ZfLQAAqB1Q From: "Rosen, Brian" To: "James M. Polk" , "IETF SIP List" , "GEOPRIV" X-OriginalArrivalTime: 27 Jul 2006 21:48:22.0204 (UTC) FILETIME=[616137C0:01C6B1C6] X-Spam-Score: -5.1 (-----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I could be wrong, but I think it is possible to define such an extension as not updating the original document. Nearly every SIP extension effectively modifies one or more ABNF lines in 3261, but none of them are considered updates to 3261. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Thursday, July 27, 2006 5:28 PM > To: Rosen, Brian; IETF SIP List; GEOPRIV > Subject: Re: [Sip] Re: [Geopriv] How Location Conveyance specifies the > allowed URI >=20 > At 04:20 PM 7/27/2006 -0500, James M. Polk wrote: > >>Can we accept this "allowed-URI" proposal and move on? Does it have to > >>be standards track, or is Informational okay? > > > >A vote for Standards Track, as this ensures IETF LC for everyone's chance > >at a proposal., also so some other WG doesn't attempt to slip something > by > >anyone (meaning "by Geopriv") >=20 > As a WG chair, I should know this off the top of my head, but I'm > bewildered by some of the comments here (and in another area), therefore > confused... >=20 > I believe that each subsequent schema proposed would be an official > 'update' to this SIP RFC (to be), which is Standards Track, meaning I > don't > believe an INFO RFC can officially 'update' a Standards Track RFC. This > would mean updating this RFC (to be) would take a Standards Track RFC, if > my math is right... >=20 >=20 > >>I would think > >>informational is okay, provided geopriv reviews. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 17:54:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6DmM-0006Rs-A1; Thu, 27 Jul 2006 17:52:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6DmJ-0006QH-Uu; Thu, 27 Jul 2006 17:52:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6DmJ-0007Id-St; Thu, 27 Jul 2006 17:52:23 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G6DmJ-0004tV-4Z; Thu, 27 Jul 2006 17:52:23 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns3.neustar.com (Postfix) with ESMTP id E473317599; Thu, 27 Jul 2006 21:51:52 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 17:51:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jul 2006 17:51:48 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] How Location Conveyance specifies the allowed URI Thread-Index: Acaxwo1MgUEq/hToQo2oDM5cwEZ8ZwAA/DGQ From: "Rosen, Brian" To: "James M. Polk" , "IETF SIP List" , "GEOPRIV" X-OriginalArrivalTime: 27 Jul 2006 21:51:49.0484 (UTC) FILETIME=[DCEDA2C0:01C6B1C6] X-Spam-Score: -5.2 (-----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Sip] RE: [Geopriv] How Location Conveyance specifies the allowed URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > >;cid-url from RFC2111, SIP/SIPS-URI from RFC3261, PRES-URI from RFC3859 > >allowed-URI =3D cid-uri / SIP-URI / SIPS-URI / PRES-URI >=20 > I think the proper cid reference is RFC 2392 Sorry, I'll fix it (if the idea is accepted) ..snip. > >I would think > >informational is okay, provided geopriv reviews. >=20 > But I don't believe we can state who the reviewers are, we're limited to > the type of RFC (if one is required) SIP Change states things like this. I think we can say it. BTW, I am not opposed to specifying standards track, I'm just don't think it's absolutely necessary. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 18:11:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6E2e-0001eg-F7; Thu, 27 Jul 2006 18:09:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6E2c-0001eU-Nu; Thu, 27 Jul 2006 18:09:14 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6E2a-00021h-E6; Thu, 27 Jul 2006 18:09:14 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Jul 2006 15:09:11 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RM9B36020909; Thu, 27 Jul 2006 15:09:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6RM9BYt029330; Thu, 27 Jul 2006 15:09:11 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 15:09:10 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 15:09:10 -0700 Message-Id: <4.3.2.7.2.20060727170730.034a4068@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2006 17:09:09 -0500 To: "Rosen, Brian" , "IETF SIP List" , "GEOPRIV" From: "James M. Polk" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Jul 2006 22:09:10.0757 (UTC) FILETIME=[49934950:01C6B1C9] DKIM-Signature: a=rsa-sha1; q=dns; l=383; t=1154038151; x=1154902151; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Geopriv]=20How=20Location=20Conveyance=20specifies=20the=20allo wed=20URI; X=v=3Dcisco.com=3B=20h=3D1Rol9nE1rhgdrxcy+N6LqUHp0PM=3D; b=ZKTMxf1ugLRMX398juvq0txtJm9ETLgYMDbDJmx8q8CB3xmC3TWqpemysk6ca6rlf+WbZj6A BCyRJ9eIR+9Tw3w+po8Qej3hXxVJDZFUCmNtrwYA+ExtaY6Mo9+d0VKV; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Sip] RE: [Geopriv] How Location Conveyance specifies the allowed URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 05:51 PM 7/27/2006 -0400, Rosen, Brian wrote: > > >;cid-url from RFC2111, SIP/SIPS-URI from RFC3261, PRES-URI from >RFC3859 > > >allowed-URI = cid-uri / SIP-URI / SIPS-URI / PRES-URI > > > > I think the proper cid reference is RFC 2392 >Sorry, I'll fix it (if the idea is accepted) 2392 is already in -03, so there needs to be a call to remove 2392 as being improper _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 18:15:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6E7H-0002TA-2W; Thu, 27 Jul 2006 18:14:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6E7F-0002Q7-Kh for sip@ietf.org; Thu, 27 Jul 2006 18:14:01 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6E7E-0003FE-5K for sip@ietf.org; Thu, 27 Jul 2006 18:14:01 -0400 Received: (qmail 21834 invoked by uid 0); 27 Jul 2006 22:13:58 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 27 Jul 2006 22:13:58 -0000 Message-ID: <00d001c6b1c9$f2bc7e20$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rosen, Brian" , "James M. Polk" , "IETF SIP List" , "GEOPRIV" References: Subject: Re: [Sip] Re: [Geopriv] How Location Conveyance specifies the allowedURI Date: Fri, 28 Jul 2006 00:13:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.5 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, Yes, but there is one big difference with what you are proposing: extensions to SIP specialize existing, clearly defined extension points in the RFC3261 ABNF. For example, "generic-param = token [ EQUAL gen-value ]" is often extended by giving a specific definition of 'token' and 'gen-value', for a specific header parameter Some headers currently don't allow parameters. That sometimes limits possible solutions, since extensions are not allowed to add parameters to such headers (since it would break backwards compatibility). In other words, modifications to the ABNF are not arbitrary. SIP elements are required to ignore headers that are not understood (RFC3261 section 8.2.2). However, early implementations of location conveyance will read the Location header. If there is no generic "AbsoluteURI" (the equivalent of generic-param) as part of the ABNF for the Location header, then additions to this field will give parsing errors for these early implementations. A typical implementation will then return "400 Bad Request", which does not help debugging. And what if the location is not critical to processing the request? then there should not be an error response, but the parser cannot make that distinction Regards, Jeroen ----- Original Message ----- From: "Rosen, Brian" To: "James M. Polk" ; "IETF SIP List" ; "GEOPRIV" Sent: Thursday, July 27, 2006 11:48 PM Subject: RE: [Sip] Re: [Geopriv] How Location Conveyance specifies the allowedURI I could be wrong, but I think it is possible to define such an extension as not updating the original document. Nearly every SIP extension effectively modifies one or more ABNF lines in 3261, but none of them are considered updates to 3261. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Thursday, July 27, 2006 5:28 PM > To: Rosen, Brian; IETF SIP List; GEOPRIV > Subject: Re: [Sip] Re: [Geopriv] How Location Conveyance specifies the > allowed URI > > At 04:20 PM 7/27/2006 -0500, James M. Polk wrote: > >>Can we accept this "allowed-URI" proposal and move on? Does it have to > >>be standards track, or is Informational okay? > > > >A vote for Standards Track, as this ensures IETF LC for everyone's chance > >at a proposal., also so some other WG doesn't attempt to slip something > by > >anyone (meaning "by Geopriv") > > As a WG chair, I should know this off the top of my head, but I'm > bewildered by some of the comments here (and in another area), therefore > confused... > > I believe that each subsequent schema proposed would be an official > 'update' to this SIP RFC (to be), which is Standards Track, meaning I > don't > believe an INFO RFC can officially 'update' a Standards Track RFC. This > would mean updating this RFC (to be) would take a Standards Track RFC, if > my math is right... > > > >>I would think > >>informational is okay, provided geopriv reviews. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 18:30:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6EL5-0004Q0-34; Thu, 27 Jul 2006 18:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6EL2-0004N9-K0 for sip@ietf.org; Thu, 27 Jul 2006 18:28:16 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6EL0-0005qb-Ac for sip@ietf.org; Thu, 27 Jul 2006 18:28:16 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k6RMSA7M003821; Thu, 27 Jul 2006 17:28:13 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k6RMS9u02699; Thu, 27 Jul 2006 17:28:09 -0500 (CDT) Message-ID: <44C93DF8.3080908@lucent.com> Date: Thu, 27 Jul 2006 17:28:08 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Update to fork-loop-fix submitted References: <009001c6b08b$c14e3a70$31713b51@BEMBUSTER> <44C776E7.3040800@lucent.com> <002801c6b146$d4b4e5d0$31713b51@BEMBUSTER> In-Reply-To: <002801c6b146$d4b4e5d0$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Because CANCEL and ACK can loop like any other request. The concern > mostly applies to *stateless* proxies Ah, ok; I forgot about stateless proxies. If you want to keep stateless proxies simple, then just don't worry about loop detection there. The loop will be detected in the next stateful proxy anyway. > (stateful proxies mostly dont "forward" but "generate" CANCEL and ACK > to non-2xx), but it matters also to a stateful proxy that receives a > CANCEL with no matching INVITE ST (RFC3261 says "MUST forward > statelessly"). Yes, I see where it says that, but my interpretation of the phrase "MUST forward statelessly" is colored by what it says next (see end of Section 16.10). RFC3261 says that CANCELs MUST be forwarded statelessly because the proxy may have statelessly proxied the preceeding INVITE. Assume you are a stateful proxy and never proxy an INVITE statelessly. When you get a CANCEL, you know for a fact that you handle all INVITEs statefully so forwarding the CANCEL statelessly causes needless network traffic. Case 1: Consider the case where a stateful proxy receives a CANCEL after just having proxied a 2xx response. The 2xx will put the ST in Terminated state at the proxy, whereupon it may delete the ST, or keep it in memory for a few seconds longer. But regardless, the proxy knows that it never sends any INVITE transactions statelessly, so proxying a CANCEL is pointless. Case 2: A proxy receives a CANCEL request out of the blue. Since it knows that it always sends INVITE statefully, proxying the CANCEL is pointless. Better to 481 it right there. Ultimately, it is an implementation decision; if you ever proxied a INV statelessly, then you must do the same for a CANCEL. Otherwise, statelessly proxying a CANCEL just adds to network traffic. Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 18:38:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ESs-000634-6F; Thu, 27 Jul 2006 18:36:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ESq-00060Y-Qp for sip@ietf.org; Thu, 27 Jul 2006 18:36:20 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6ESk-0006Pe-Ng for sip@ietf.org; Thu, 27 Jul 2006 18:36:20 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k6RMaCHI008790; Thu, 27 Jul 2006 17:36:12 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k6RMaCu07853; Thu, 27 Jul 2006 17:36:12 -0500 (CDT) Message-ID: <44C93FDC.5030209@lucent.com> Date: Thu, 27 Jul 2006 17:36:12 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] Hitchhikers guide - when is it done? References: <072C5B76F7CEAB488172C6F64B30B5E301BF857F@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301BF857F@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1101229096==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1101229096== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010007040302050300050208" This is a cryptographically signed message in MIME format. --------------ms010007040302050300050208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Michael Hammer (mhammer) wrote: > Then we will need an RFC to point to the index RFCs that point to the > base RFCs? Nah, it's not as bad as that. We are talking about 2 RFCs at most, really. > A single RFC pointing document would be best. If we go the single RFC route, then that means obsoleting that RFC at least once, or maybe twice. Now, while you and I are adept at making our way through how IETF numbers their RFCs and what happens when one RFC is obsoleted, and so on ... I think the majority of the people using our specifications may not have this context. They grab an RFC -- obsolete or not -- and run with it. To take this to the absurd, I am aware of products based on *expired* I-Ds, not to mention obsolete RFCs! In summary, my preference is for (1), with two RFCs produced at most. But, if the WG decides to go with (2), then that is fine... Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms010007040302050300050208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIlPjCC Ch4wggkGoAMCAQICCh6WhFwAAAAACpUwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA2MDYyNjE2MTI1M1oXDTA4MDYyNjE2MjI1M1owQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsCokOtoH/zOzgQOoH5wBSXpXbUvvzpuM4u5y pSGFeBeTKuTzew3EvxcAB7r1gHMNTgMXvCaLs6o9VUkoQQKaWGNXXZqLkkkCbHr+KD82IAmO OXqKJtYvNOlraQahXTKlrG6+oT6VFa9BIza/uSZ2DKPcscoVSBBEmbC8Zoh7lH7/sl6BveFg j1e0rTrC4ml90zVnxFnz2ARTExawUx7hyVKLmWy84egc6yDh7sc5B+6NbJv1GdSJOASJbNcL LvxihE2wgD71nhRtWzMAdzg4nsd8yI9bshUGqYbiiKC9GrV9NN7AJ0WsLQtLYs+1dcuMNXlL caEyIxTCcmZwnYNsowIDAQABo4IGpDCCBqAwHQYDVR0OBBYEFNNWvr2U2hSbKzlP8W4ih6m5 pjNMMIH+BgNVHSMEgfYwgfOAFISfQVWcEIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJ KoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UE CBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBU ZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1 Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPy LGQBAQQFFgN2a2cwFwYKCZImiZPyLGQBLAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIF oDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcD BzCCAncGCCsGAQUFBwEBBIICaTCCAmUwgc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNl YXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZp Y2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAx LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZp Y2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHM BggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRp ZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIIC gTCCAn0wgdaggdOggdCGgc1sZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2Nu PUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVy ZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0 aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDovL2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0 aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxp c3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB 0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRl Y2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRp b24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlz dDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqG SIb3DQEBBQUAA4IBAQCZpf5cNwck4S9qjuX6Hfo+FWFtWTIPMPGVwsMVYz97hmEPKzxA8zMP aO0Z9+FD75ZBc2GkZsHQVGbAjrqkeOSfdt5MF2Qex0Z6o4jw0U/w2/EzGLogdBp7jC1DJ6Tm TqBLqRnjPsPs2NGazbTKmEoJX2isQOBUZyfzM44uCyVEY6Sk6FGqR7RDDCvr7VZvo/28d6at U9ueIa6rtdk+AxlXyqsJ6GBUL+ZBNJQ58L9xqynzPmikjntfM1TEhvkOATXLJ7wqf6ao4lKk gg5cqOxHPVMAje5K9f8V9hdUOtc9MNCR9nyTo8qNzMNyh8FR+1/qxFDtiJG5l6EArgfl2OGr MIIKHjCCCQagAwIBAgIKHpaEXAAAAAAKlTANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3 DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5l dyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5v bG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZp Y2VzIDEwHhcNMDYwNjI2MTYxMjUzWhcNMDgwNjI2MTYyMjUzWjBBMR0wGwYJKoZIhvcNAQkB Fg52a2dAbHVjZW50LmNvbTEgMB4GA1UEAxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwKiQ62gf/M7OBA6gfnAFJeldtS+/Om4zi 7nKlIYV4F5Mq5PN7DcS/FwAHuvWAcw1OAxe8Jouzqj1VSShBAppYY1ddmouSSQJsev4oPzYg CY45eoom1i806WtpBqFdMqWsbr6hPpUVr0EjNr+5JnYMo9yxyhVIEESZsLxmiHuUfv+yXoG9 4WCPV7StOsLiaX3TNWfEWfPYBFMTFrBTHuHJUouZbLzh6BzrIOHuxzkH7o1sm/UZ1Ik4BIls 1wsu/GKETbCAPvWeFG1bMwB3ODiex3zIj1uyFQaphuKIoL0atX003sAnRawtC0tiz7V1y4w1 eUtxoTIjFMJyZnCdg2yjAgMBAAGjggakMIIGoDAdBgNVHQ4EFgQU01a+vZTaFJsrOU/xbiKH qbmmM0wwgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcswgcgxJTAj BgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYD VQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50 IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkGA1UEAxMi THVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTATBgoJkiaJ k/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4QgEBBAQD AgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQGCCsGAQUF BwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8vbGRhcC11 c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1Y2VudC5j b20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUy MDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRp ZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2Jp bmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKKBgNVHR8E ggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0 ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25B dXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmlj YXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9u bGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHU oIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIw VGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2VydGlmaWNh dGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25s aXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJ KoZIhvcNAQEFBQADggEBAJml/lw3ByThL2qO5fod+j4VYW1ZMg8w8ZXCwxVjP3uGYQ8rPEDz Mw9o7Rn34UPvlkFzYaRmwdBUZsCOuqR45J923kwXZB7HRnqjiPDRT/Db8TMYuiB0GnuMLUMn pOZOoEupGeM+w+zY0ZrNtMqYSglfaKxA4FRnJ/Mzji4LJURjpKToUapHtEMMK+vtVm+j/bx3 pq1T254hrqu12T4DGVfKqwnoYFQv5kE0lDnwv3GrKfM+aKSOe18zVMSG+Q4BNcsnvCp/pqji UqSCDlyo7Ec9UwCN7kr1/xX2F1Q61z0w0JH2fJOjyo3Mw3KHwVH7X+rEUO2IkbmXoQCuB+XY 4aswghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUwIwYJKoZI hvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMK TmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNo bm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2Vu dCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcNMTAxMjA2 MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNvbTELMAkG A1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBIaWxsMRww GgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVjaG5vbG9n aWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+JXW72361 5PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHEx5xRWAiO NeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJE3BGQTOX 0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46CZQsibysV efigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMBAAGjggz0 MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4hS09K38sw CwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/hK1C+quh9 NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNl bnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVy cmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRo b3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCBxoaBw2xk YXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9n aWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMs bz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2Jq ZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6Ly9sZGFw LXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9v dCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQu Y29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4dGVybmFs Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2 b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhv cml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlv biUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0 O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcqggceg gcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNo bm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/bGRhcDov L2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJv b3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50 LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNz PWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJpdHkubHVj ZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYBBQUHMAKG gbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hu b2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0 aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNz PWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xkYXAtdXN3 ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIw QXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/ Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0 aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZp Y2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5 P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYBBQUHMAKG gbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRl Y2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhv cml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNs YXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDovL2xkYXAt ZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUy MEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29t P2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1 dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNv bS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRp ZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggrBgEFBQcw AoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9s b2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGll cyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1j ZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNlY3VyaXR5 Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5UrdsB2nOxTre kCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82gm7eZee7 lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13h4tgCPG3 WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biRZr61dWmQ WajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb1QUPqg8/ g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCBEowggRGAgEBMIHBMIGyMSUwIwYJKoZI hvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMK TmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNo bm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2Vy dmljZXMgMQIKHpaEXAAAAAAKlTAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA3MjcyMjM2MTJaMCMGCSqGSIb3DQEJBDEWBBQg LQo3scuq0ur++9SSMeuqKZUouDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB0gYJ KwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQu Y29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5 IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBU ZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKHpaEXAAAAAAKlTCB1AYLKoZI hvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5j b20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkg SGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVjZW50IFRl Y2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoeloRcAAAAAAqVMA0GCSqGSIb3 DQEBAQUABIIBAA07qtIVCrNsPd0ic1KwFmrtmTqq3PF1A8ocxz2Gtba7/O904yg4EPVa3HMr 74n9/BB26/9jyZ1cdBlfFreW4LXA0dye2Thn7I9/TR+kdOnlprB7MCrxF607fudAkhbCf5sT MnIxGOktLRuXYR6XsSsw+vlPmRln/5c5YD8tGYGZLCOMwRRNBduLMAhXh5JbLfa1Di57mM09 Hy+ZUfofaMryrc0p8ir7eyGo7Ezw2zZkl8XnmKan2HM/VV8KRFL86QOcOBNjldpqAx40JG0J 8L5rQiO0UikW9+gVfzFPKNQ0A6DMpj5GTRY1ZHxn9j+kYLuu5JAILJsjRTa/sVXvpUUAAAAA AAA= --------------ms010007040302050300050208-- --===============1101229096== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1101229096==-- From sip-bounces@ietf.org Thu Jul 27 20:52:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6GYs-0002Z6-0W; Thu, 27 Jul 2006 20:50:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6GYp-0002Yy-Re; Thu, 27 Jul 2006 20:50:39 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6GYp-0002s9-Gf; Thu, 27 Jul 2006 20:50:39 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 19:50:35 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 27 Jul 2006 19:50:34 -0500 Received: from AOPEX4.andrew.com ([10.3.20.127]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 19:50:33 -0500 Message-ID: From: "Dawson, Martin" To: "Andrew Newton" , "IETF SIP List" , "GEOPRIV" Date: Thu, 27 Jul 2006 19:50:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 28 Jul 2006 00:50:33.0600 (UTC) FILETIME=[D4FFE000:01C6B1DF] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <37E9EDFD-EA9E-40A3-8885-996A8558958D@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Geopriv] teasing apart: http as a GEOPRIV using protocol Thread-Index: Acaxem5HdWhAlRChRpmAHuCCbx6CjQAZEkLA X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Subject: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Andy, I'll take a stab at it. Not that HTTP is a valid *using protocol* but, rather, that the location reference does not actually identify a using protocol and, in fact, HTTP would only be the transport protocol... 3693 states: The "using protocol" is the protocol that uses (reads or modifies) the Location Object. A protocol that just transports the LO as a string of bits, without looking at them (like an IP storage protocol could do), is not a using protocol, but only a transport protocol. Nevertheless, the entity or protocol that caused the transport protocol to move the LO is responsible for the appropriate distribution, protection, usage, retention, and storage of the LO based on the rules that apply to that LO. A location reference which provided an HTTP URI indicates that the entity that is going to be used to request the LO is to be communicated with using HTTP. Because of the rules associated with the PIDF-LO, it can be inferred that the entity and whatever semantics are associated with the HTTP communications with that entity will honor the requirements. That is, HTTP is only the transport protocol. An HTTP GET has to be interpreted by the receiving entity within the scope of a using protocol - with its associated set of rules and semantics - which go beyond HTTP and which do respect the geopriv requirements. Indeed, this is generally the case - sending an HTTP GET to an arbitrary IP node can yield any number of results depending what that node actually does. The client needs to understand the purpose of that server in the scope of some higher level protocol. To use another example, a location reference could be an IP address. There's nothing inherent in IP that honors the geopriv rules, but that doesn't stop the reference being valid nor say that the protocol used between a client and that IP address would not honor the rules. The purpose of the SIP conveyance specification is to say how a LO or reference can be transferred from one entity to another using SIP. It's out of scope for a SIP specification to mandate anything about the transport protocol or to infer anything about using protocol implied by that transport. As has been previously mentioned, this would be subject to separate specification and BCP - lest the SIP conveyance specification become overly rigid and subject to unnecessary maintenance and churn. Cheers, Martin > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, 27 July 2006 10:45 PM > To: IETF SIP List; GEOPRIV > Subject: [Geopriv] teasing apart: http as a GEOPRIV using protocol >=20 > There have been a number of opinions regarding HTTP as a using protocol. >=20 > I'd like to know, how many people believe that HTTP requires no or > very little specification to meet the requirements in RFC 3693 and > RFC 3694. If you believe this, what basis do you have for this > conclusion? Or do you believe more specification needs to be done, > but it is possible for HTTP to be a GEOPRIV using protocol? >=20 > Finally, how many people believe that HTTP should not be a using > protocol? >=20 > -andy >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 21:39:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6HHy-0007gc-3U; Thu, 27 Jul 2006 21:37:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6HHx-0007gU-7M; Thu, 27 Jul 2006 21:37:17 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6HHv-0007L0-PM; Thu, 27 Jul 2006 21:37:17 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6S1axqk031283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2006 18:37:00 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6S1apEa008645; Thu, 27 Jul 2006 18:36:57 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <7A8FBA4E-DD34-4C89-80B6-BE2913101258@cs.columbia.edu> References: <04d501c6b180$6e39f4a0$640fa8c0@cis.neustar.com> <7A8FBA4E-DD34-4C89-80B6-BE2913101258@cs.columbia.edu> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 27 Jul 2006 18:36:39 -0700 To: Henning Schulzrinne , "Brian Rosen" From: Randall Gellens Subject: [Geopriv] Re: [Sip] teasing apart: http as a GEOPRIV using protocol Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 9:33 AM -0400 7/27/06, Henning Schulzrinne wrote: > For all protocols, the hardest part is specifying how > authentication works in conjunction with the privacy rules. This is > far from obvious for HTTP, for example. (Is it the Digest user > identifier? Can Basic over TLS be used instead? What about > crypto-random request URIs? Is HTTP ok in that case or is HTTPS > needed - the answer isn't obvious since an observer would only see > a location, not a location-identity pair.) > > For SIP, this is largely done, except for the crypto-random request > URI case and variations, such as user + password. A while back there was some brief discussion in geopriv about using "pawn ticket" URIs for location information. That is, URLAUTH from RFC 4467, which is a URL that has been signed by the server and can be used by the holder to gain access to the information, subject to expiration time and/or role restrictions. Role restrictions limit the URL to being used by an entity that is known to the location server as performing a specified role. Additionally, RFC 4467 allows all currently-issued URLs to be revoked by changing the key. I wonder if there is any value in this? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It wasn't as easy to get programs right as we had thought. --Wilkes, 1949 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 21:43:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6HLy-0000BH-DX; Thu, 27 Jul 2006 21:41:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6HLw-0000B9-HY; Thu, 27 Jul 2006 21:41:24 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6HLv-0007gv-1e; Thu, 27 Jul 2006 21:41:24 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6S1f7eM013376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2006 18:41:07 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6S1eoMb009791; Thu, 27 Jul 2006 18:40:51 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44C8DD67.6090908@gmx.net> References: <04d501c6b180$6e39f4a0$640fa8c0@cis.neustar.com> <7A8FBA4E-DD34-4C89-80B6-BE2913101258@cs.columbia.edu> <44C8DD67.6090908@gmx.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Thu, 27 Jul 2006 18:39:37 -0700 To: Hannes Tschofenig , Henning Schulzrinne From: Randall Gellens Subject: Re: [Geopriv] Re: [Sip] teasing apart: http as a GEOPRIV using protocol Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 5:36 PM +0200 7/27/06, Hannes Tschofenig wrote: > here is the reason why I think we are not talking about a 'using > protocol' here: All we want is to perform dereferencing. > > We don't want something that does all the fancy features of a > presence solution. Perhaps it is a question of who is doing the dereferencing: if the location URI is given to the target, that seems to me to be provisioning, the same as the DHCP case; if instead the URI is given to anyone else, that looks like location disclosure (or at least the first half of it). In the disclosure case, dereferencing the URI is, I think, a using protocol. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- What is mind? No matter. What is matter? Never mind. --Thomas Hewitt Key, 1799-1875 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 21:55:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6HXk-0003DR-MQ; Thu, 27 Jul 2006 21:53:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6HXj-0003Ah-0m; Thu, 27 Jul 2006 21:53:35 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6HXi-0002u4-Eb; Thu, 27 Jul 2006 21:53:34 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6S1rUjY000697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2006 18:53:31 -0700 Received: from [10.0.1.3] (vpn-10-50-0-162.qualcomm.com [10.50.0.162]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6S1rSNA017026; Thu, 27 Jul 2006 18:53:29 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 27 Jul 2006 18:53:27 -0700 To: "Dawson, Martin" , "Andrew Newton" , "IETF SIP List" , "GEOPRIV" From: Ted Hardie Content-Type: multipart/mixed; boundary="============_-1058070887==_============" X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: Subject: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --============_-1058070887==_============ Content-Type: text/plain; charset="us-ascii" Hi Martin, Having not seen your note, I already took a stab it, along much the same lines you suggest. Clearly, the attached -00 (not yet in the drafts directories) is the barest of bare bones, but I thought it might be useful to sketch that out as a contrast to some of the real applications which might use HTTP as a using protocol. I believe this also differs from RELO in that it is focused on the transport of PIDF-LO, which is slightly different from RELO's remit. But clearly, there are strong connections there. And if the phrase "strawman" in the title doesn't signal that I don't think this is a done piece of work, allow this too. regards, Ted Hardie At 7:50 PM -0500 7/27/06, Dawson, Martin wrote: >Hi Andy, > >I'll take a stab at it. Not that HTTP is a valid *using protocol* but, >rather, that the location reference does not actually identify a using >protocol and, in fact, HTTP would only be the transport protocol... > >3693 states: > The "using protocol" is the protocol that uses (reads or modifies) > the Location Object. A protocol that just transports the LO as a > string of bits, without looking at them (like an IP storage protocol > could do), is not a using protocol, but only a transport protocol. > Nevertheless, the entity or protocol that caused the transport > protocol to move the LO is responsible for the appropriate > distribution, protection, usage, retention, and storage of the LO > based on the rules that apply to that LO. > >A location reference which provided an HTTP URI indicates that the >entity that is going to be used to request the LO is to be communicated >with using HTTP. Because of the rules associated with the PIDF-LO, it >can be inferred that the entity and whatever semantics are associated >with the HTTP communications with that entity will honor the >requirements. That is, HTTP is only the transport protocol. An HTTP GET >has to be interpreted by the receiving entity within the scope of a >using protocol - with its associated set of rules and semantics - which >go beyond HTTP and which do respect the geopriv requirements. Indeed, >this is generally the case - sending an HTTP GET to an arbitrary IP node >can yield any number of results depending what that node actually does. >The client needs to understand the purpose of that server in the scope >of some higher level protocol. > >To use another example, a location reference could be an IP address. >There's nothing inherent in IP that honors the geopriv rules, but that >doesn't stop the reference being valid nor say that the protocol used >between a client and that IP address would not honor the rules. > >The purpose of the SIP conveyance specification is to say how a LO or >reference can be transferred from one entity to another using SIP. It's >out of scope for a SIP specification to mandate anything about the >transport protocol or to infer anything about using protocol implied by >that transport. As has been previously mentioned, this would be subject >to separate specification and BCP - lest the SIP conveyance >specification become overly rigid and subject to unnecessary maintenance >and churn. > >Cheers, >Martin > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Thursday, 27 July 2006 10:45 PM >> To: IETF SIP List; GEOPRIV >> Subject: [Geopriv] teasing apart: http as a GEOPRIV using protocol >> >> There have been a number of opinions regarding HTTP as a using >protocol. >> >> I'd like to know, how many people believe that HTTP requires no or >> very little specification to meet the requirements in RFC 3693 and >> RFC 3694. If you believe this, what basis do you have for this >> conclusion? Or do you believe more specification needs to be done, >> but it is possible for HTTP to be a GEOPRIV using protocol? > > >> Finally, how many people believe that HTTP should not be a using >> protocol? >> >> -andy >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv --============_-1058070887==_============ Content-Id: Content-Type: application/octet-stream; name="draft-hardie-geopriv-https-strawman-00.txt" Content-Disposition: attachment; filename="draft-hardie-geopriv-https-strawman-00.txt" Content-Transfer-Encoding: base64 TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVC4gSGFyZGllCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBRdWFsY29tbSwgSW5jLgpFeHBpcmVz OiBKYW51YXJ5IDMwLCAyMDA3ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKCiAgICAgICAgICBBIFN0cmF3bWFuIHByb3Bvc2FsIGZvciBIVFRQUyBhcyBh IFBJREYtTE8gVHJhbnNwb3J0IFByb3RvY29sCiAgICAgICAgICAgICAgICAgZHJhZnQt aGFyZGllLWdlb3ByaXYtaHR0cHMtc3RyYXdtYW4tMDAudHh0CgpTdGF0dXMgb2YgdGhp cyBNZW1vCgogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2gg YXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkKICAgYXBwbGljYWJsZSBwYXRlbnQgb3Ig b3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUKICAgaGF2 ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9y IHNoZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRh bmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBh cmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAg IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91 cHMuICBOb3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUg d29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVy bmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0g b2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBv YnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQog ICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBw cm9ncmVzcy4iCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBj YW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1h YnN0cmFjdHMudHh0LgoKICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93 IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYu b3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGly ZSBvbiBKYW51YXJ5IDMwLCAyMDA3LgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJp Z2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuCgpBYnN0cmFjdAoKICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzdHJhd21hbiBhcHByb2FjaCB0byB1c2lu ZyBIVFRQIChIVFRQKQogICBvdmVyIFRMUyAoVExTKSB3aXRoIERpZ2VzdCBBdXRoZW50 aWNhdGlvbiB0byB0cmFuc3BvcnQgUElERi1MTwogICAoUkZDIDQxMTkpIG9iamVjdHMu ICBJdCBpcyBhIEdFT1BSSVYgdHJhbnNwb3J0IHByb3RvY29sIGFzIAogICBkZXNjcmli ZWQgaW4gc2VjdGlvbiA1LjIgb3IgUkZDIDM2OTMgKFJGQyAzNjkzKQoKMS4gIFJlcXVp cmVtZW50cyBub3RhdGlvbgoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5P VCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwg IlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIg aW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3Jp YmVkIGluIFtSRkMgMjExOV0uCgoKMi4gIEludHJvZHVjdGlvbgoKICAgVGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgYSBzdHJhd21hbiBhcHByb2FjaCBmb3IgSFRUUCB0byB0cmFu c3BvcnQKICAgUElERi1MTyBvYmplY3RzLiAgUkZDIDM2OTMsIFNlY3Rpb24gNS4yIHNh eXMgdGhlIGZvbGxvd2luZyBhYm91dCAKICAgR2VvcHJpdiB0cmFuc3BvcnQgcHJvdG9j b2xzOgoKICAgIkEgcHJvdG9jb2wgdGhhdCBqdXN0IHRyYW5zcG9ydHMgdGhlIExPIGFz IGEgc3RyaW5nIG9mIGJpdHMsIHdpdGhvdXQgCiAgIGxvb2tpbmcgYXQgdGhlbSAobGlr ZSBhbiBJUCBzdG9yYWdlIHByb3RvY29sIGNvdWxkIGRvKSwgaXMgbm90IGEgCiAgIHVz aW5nIHByb3RvY29sLCBidXQgb25seSBhIHRyYW5zcG9ydCBwcm90b2NvbC4gTmV2ZXJ0 aGVsZXNzLCB0aGUgCiAgIGVudGl0eSBvciBwcm90b2NvbCB0aGF0IGNhdXNlZCB0aGUg dHJhbnNwb3J0IHByb3RvY29sIHRvIG1vdmUgdGhlIAogICBMTyBpcyByZXNwb25zaWJs ZSBmb3IgdGhlIGFwcHJvcHJpYXRlIGRpc3RyaWJ1dGlvbiwgcHJvdGVjdGlvbiwgCiAg IHVzYWdlLCByZXRlbnRpb24sIGFuZCBzdG9yYWdlIG9mIHRoZSBMTyBiYXNlZCBvbiB0 aGUgcnVsZXMgdGhhdCAKICAgYXBwbHkgdG8gdGhhdCBMTy4iCgogICBXaGlsZSBpdCBt aWdodCBiZSBwb3NzaWJsZSB0byBkZXNjcmliZSBIVFRQIGFzIGEgdHJhbnNwb3J0IHBy b3RvY29sCiAgIGFuZCBwdW50IGFsbCBvZiB0aGUgcmVxdWlyZW1lbnRzIHRvIHRoZSBs YXllciBhYm92ZSBIVFRQLCB0aGlzCiAgIGRvY3VtZW50IGRlc2NyaWJlcyBhIGxheWVy aW5nIG9mIEhUVFAgb3ZlciBUTFMgd2l0aCBEaWdlc3QKICAgQXV0aGVudGljYXRpb24g aW4gdXNlIGJldHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXIsIHNvIHRoYXQgYQogICBjb21t b24gc2V0IG9mIG1lY2hhbmlzbXMgZm9yIHByaXZhY3kgYW5kIGF1dGhlbnRpY2F0aW9u IGFyZQogICBlc3RhYmxpc2hlZC4KCgozLiBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudAoK ICAgSFRUUCBjYW4gYmUgdXNlZCBhcyBhIHN1YnN0cmF0ZSB0byBhIG51bWJlciBvZiBk aWZmZXJlbnQgYXBwbGljYXRpb25zLAogICBhbmQgZGVmaW5pbmcgYSBzZXQgb2YgZ3Vp ZGVsaW5lcyBmb3IgdGhlIHRyYW5zcG9ydCBvZiBQSURGLUxPIGZvciAKICAgYW55IGFw cGxpY2F0aW9uIHdoaWNoIG1pZ2h0IHVzZSBIVFRQIHdvdWxkIGJlIGRpZmZpY3VsdCBv ciBpbXBvc3NpYmxlLgogICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGF0dGVtcHQgdGhh dCB0YXNrLiAgSW5zdGVhZCwgaXQgaXMgbGltaXRlZCBpbgogICBhcHBsaWNhYmlsaXR5 IHRvIHRoZSBjYXNlIHdoZXJlIGEgY2xpZW50IHVzZXMgYW4gSFRUUCBHRVQgcmVxdWVz dAogICB0byByZXRyaWV2ZSBhIFBJREYtTE8gb2JqZWN0IGZyb20gYSBzZXJ2ZXIgb3Ig dXNlcyBIVFRQIFBVVCB0bwogICBwdWJsaXNoIGEgUElERi1MTyBvYmplY3QgdG8gYSBz ZXJ2ZXIuICBObyBvdGhlciBmdW5jdGlvbmFsaXR5CiAgIGlzIGNvdmVyZWQuICBUaGlz IGRvY3VtZW50IGRvZXMgbm90IGRlc2NyaWJlIGhvdyB5b3Ugd291bGQgZGV0ZXJtaW5l CiAgIHRoZSBVUkkgb2YgdGhlIFBJREY9TE8gZG9jdW1lbnQgb3IgdGhlIGFwcHJvcHJp YXRlIHNlcnZlciB0byBxdWVyeS4KCiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgZGVz Y3JpYmUgSFRUUCBhcyBhICJ1c2luZyBwcm90b2NvbCIgd2hpY2gsIAogICBpbiBHZW9Q UklWIHRlcm1zLCBpcyBhIHByb3RvY29sIHdoaWNoICJ1c2VzIChyZWFkcyBvciBtb2Rp ZmllcykKICAgdGhlIExvY2F0aW9uIE9iamVjdCIuCgoKNC4gU3RlcHMgZm9yIHJldHJp ZXZhbAoKNC4xIFRoZSBjbGllbnQgdXNlcyBIVFRQUyB0byBjb25uZWN0IHRvIHRoZSBz ZXJ2ZXIuCgogIFRoZSBjbGllbnQgZXN0YWJsaXNoZXMgYW4gSFRUUFMgY29ubmVjdGlv biB0byB0aGUgc2VydmVyLCBhcyAKICBkZXNjcmliZWQgaW4gUkZDIDI4MTguICBBdCB0 aGUgVExTIGxheWVyLCB0aGUgdXNlIG9mCiAgVExTX05VTExfV0lUSF9OVUxMX05VTEwg TVVTVCBOT1QgYmUgdXNlZCBhcyB0aGUgQ2lwaGVyU3VpdGUuCgo0LjIgVGhlIGNsaWVu dCBhdXRoZW50aWNhdGVzIHRvIHRoZSBzZXJ2ZXIuCgogIFRoZSBjbGllbnQgYXV0aGVu dGljYXRlcyB0byB0aGUgc2VydmVyIHVzaW5nIEhUVFAncyBkaWdlc3QKICBhdXRoZW50 aWNhdGlvbiBtZWNoYW5pc20gYXMgZGVzY3JpYmVkIGluIFJGQyAyNjE3IGFuZCB1cGRh dGVkCiAgYnkgdGhlIGVycmF0YS4KCjQuMyAgVGhlIGNsaWVudCByZXRyaWV2ZXMgdGhl IHJlc291cmNlLgoKICBUaGUgY2xpZW50IHJldHJpZXZlcyB0aGUgUElERi1MTyByZXNv dXJjZSB1c2luZyBhbiBIVFRQIEdFVAogIHJlcXVlc3QuICAKCgo1LiBTdGVwcyBmb3Ig cHVibGljYXRpb24uCgo1LjEgVGhlIGNsaWVudCB1c2VzIEhUVFBTIHRvIGNvbm5lY3Qg dG8gdGhlIHNlcnZlci4KCiAgVGhlIGNsaWVudCBlc3RhYmxpc2hlcyBhbiBIVFRQUyBj b25uZWN0aW9uIHRvIHRoZSBzZXJ2ZXIsIGFzCiAgZGVzY3JpYmVkIGluIFJGQyAyODE4 LiAgQXQgdGhlIFRMUyBsYXllciwgdGhlIHVzZSBvZgogIFRMU19OVUxMX1dJVEhfTlVM TF9OVUxMIE1VU1QgTk9UIGJlIHVzZWQgYXMgdGhlIENpcGhlclN1aXRlLgoKNS4yIFRo ZSBjbGllbnQgYXV0aGVudGljYXRlcyB0byB0aGUgc2VydmVyLgoKICBUaGUgY2xpZW50 IGF1dGhlbnRpY2F0ZXMgdG8gdGhlIHNlcnZlciB1c2luZyBIVFRQJ3MgZGlnZXN0CiAg YXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjYxNyBh bmQgdXBkYXRlZAogIGJ5IHRoZSBlcnJhdGEuCgo1LjMgIFRoZSBjbGllbnQgcHVibGlz aGVzIHRoZSByZXNvdXJjZS4KCiAgVGhlIGNsaWVudCBwdWJsaXNoZXMgdGhlIFBJREYt TE8gcmVzb3VyY2UgdXNpbmcgYW4gSFRUUCBQVVQKICByZXF1ZXN0LgoKNi4gIElBTkEg Q29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgaW1wbHkgYW55 IGFjdGlvbnMgZm9yIElBTkEuCgo3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAg IFRoaXMgZG9jdW1lbnQgcHJlc3VtZXMgdGhhdCB0aGUgdXNlIG9mIFRMUyBhcyBzdWJz dHJhdGUgdG8gSFRUUAogICBpcyBzdWZmaWNpZW50IHRvIHByb3RlY3QgdGhlIHByaXZh Y3kgb2YgdGhlIFBJREYtTE8gY29udGVudCB3aGlsZQogICBpbiBmbGlnaHQuICBJdCBh bHNvIHByZXN1bWVzIHRoYXQgRGlnZXN0IEF1dGhlbnRpY2F0aW9uLCBjb21iaW5lZAog ICB3aXRoIHRoZSBUTFMtbGF5ZXIgYXV0aGVudGljYXRpb24sIGlzIHN1ZmZpY2llbnQg dG8gZW5hYmxlIGEgY2xpZW50IAogICBhbmQgc2VydmVyIHRvIGF1dGhlbnRpY2F0ZSB0 byBvbmUgYW5vdGhlci4gIFRoZXJlIGlzIG9uZ29pbmcgd29yayAKICAgdG8gdXBkYXRl IERpZ2VzdCBBdXRoZW50aWNhdGlvbiwgYW5kIHRob3NlIG1heSBldmVudHVhbGx5IHJl cXVpcmUgCiAgIGFuIHVwZGF0ZSB0byB0aGUgcmVjb21tZW5kZWQgYXV0aGVudGljYXRp b24gbWV0aG9kLgoKCgo4LiAgUmVmZXJlbmNlcwoKCihDaXRhdGlvbnMgaW5jb21wbGV0 ZTsgdG8gYmUgY29tcGxldGVkIGFzIGFib3ZlKQoKOS4xICBOb3JtYXRpdmUgUmVmZXJl bmNlcwoKICAgWzNdICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJG Q3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQKICAgICAgICBMZXZlbHMiLCBSRkMgMjEx OSwgQkNQIDE0LCBNYXJjaCAxOTk3LgoKCiAgIFs5XSAgUGV0ZXJzb24sIEouLCAiQSBQ cmVzZW5jZS1iYXNlZCBHRU9QUklWIExvY2F0aW9uIE9iamVjdCBGb3JtYXQiLAogICAg ICAgIFJGQyA0MTE5LCBEZWNlbWJlciAyMDA1LgoKOS4yICBJbmZvcm1hdGl2ZSBSZWZl cmVuY2VzCgoKQXV0aG9yJ3MgQWRkcmVzc2VzCgogICBUZWQgSGFyZGllCiAgIFF1YWxj b21tLCBJbmMuCiAgIEVtYWlsOiAgaGFyZGllQHF1YWxjb21tLmNvbQoKCgpJbnRlbGxl Y3R1YWwgUHJvcGVydHkgU3RhdGVtZW50CgogICBUaGUgSUVURiB0YWtlcyBubyBwb3Np dGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQogICBJbnRl bGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0 IGJlIGNsYWltZWQgdG8KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3Ig dXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbgogICB0aGlzIGRvY3VtZW50 IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdo dHMKICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQg cmVwcmVzZW50IHRoYXQgaXQgaGFzCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9y dCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbgogICBvbiB0 aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVu dHMgY2FuIGJlCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgQ29waWVz IG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFu ZCBhbnkKICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJs ZSwgb3IgdGhlIHJlc3VsdCBvZiBhbgogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEg Z2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YKICAgc3Vj aCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRo aXMKICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBv bi1saW5lIElQUiByZXBvc2l0b3J5IGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXBy LgoKICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmlu ZyB0byBpdHMgYXR0ZW50aW9uIGFueQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBh dGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5CiAgIHJpZ2h0cyB0 aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGlt cGxlbWVudAogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9y bWF0aW9uIHRvIHRoZSBJRVRGIGF0CiAgIGlldGYtaXByQGlldGYub3JnLgoKCkRpc2Ns YWltZXIgb2YgVmFsaWRpdHkKCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbgogICAiQVMgSVMi IGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hF IFJFUFJFU0VOVFMKICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5U RVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUCiAgIEVOR0lORUVSSU5HIFRBU0sg Rk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwK ICAgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBU SEUgVVNFIE9GIFRIRQogICBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklO R0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRAogICBXQVJSQU5USUVTIE9GIE1FUkNI QU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4KCgpD b3B5cmlnaHQgU3RhdGVtZW50CgogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBT b2NpZXR5ICgyMDA2KS4gIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdAogICB0byB0aGUg cmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1Ag NzgsIGFuZAogICBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3Jz IHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLgoKCkFja25vd2xlZGdtZW50CgogICBGdW5k aW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlk ZWQgYnkgdGhlCiAgIEludGVybmV0IFNvY2lldHkuCgoKCg== --============_-1058070887==_============ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --============_-1058070887==_============-- From 3465C3G7D3@mail.ru Thu Jul 27 22:07:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Hl7-0001Zi-IG for sip-archive@lists.ietf.org; Thu, 27 Jul 2006 22:07:25 -0400 Received: from [222.255.190.41] (helo=mxs.mail.ru) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Hl5-0005cu-Uh for sip-archive@lists.ietf.org; Thu, 27 Jul 2006 22:07:25 -0400 Message-ID: <662161c806049xar3eln5mw2gel53d5oqj0jkai7q1r9g1@mxs.mail.ru> Date: Fri, 28 Jul 2006 02:07:25 -0420 From: "Bridget Grady" To: sip-archive@lists.ietf.org Subject: :), mild-brewed MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 4.2 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Even if you have no erectin problems SOFT CIA7LIS would help you to make BETTER SE9X MORE OFTEN! and to bring unimagnable plesure to her. Just disolve half a pil under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medic ation were able to have PERFECT ERJECTION during 36 hours! VISIT US, AND GET OUR SPECIAL 70% DISCMOUNT OFER! http://iapdmh.allsamsite.net/?99283330 ========== elements of high-speed flying to a class of new students. He had just It was funny and sad. One! As though one would be enough! Oh, science. eating that mattered, but flight. More than anything else. Jonathan saying nothing. Suddenly he clapped his hands, rubbed his palms together, "The Pilman Radiant is simplicity itself. Imagine that you spin a huge too, but I was going to keep away from it. That's where I made my mistake. I fun," he said. bright sunlight. Just blackness. Then my eyes grew accustomed and I saw that From sip-bounces@ietf.org Thu Jul 27 23:10:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6IiH-0007nF-BV; Thu, 27 Jul 2006 23:08:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6IiF-0007nA-Oo for sip@ietf.org; Thu, 27 Jul 2006 23:08:31 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6IiE-00025I-AC for sip@ietf.org; Thu, 27 Jul 2006 23:08:31 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Jul 2006 23:08:30 -0400 X-IronPort-AV: i="4.07,190,1151899200"; d="scan'208"; a="94202366:sNHT28503504" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6S38Tl0016294; Thu, 27 Jul 2006 23:08:29 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6S38RYl021343; Thu, 27 Jul 2006 23:08:29 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 23:08:28 -0400 Received: from [10.255.255.157] ([10.86.243.26]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 23:08:27 -0400 Message-ID: <44C97FAB.9040204@cisco.com> Date: Thu, 27 Jul 2006 23:08:27 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [Sip] Hitchhikers guide - when is it done? References: <5D1A7985295922448D5550C94DE2918019507C@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918019507C@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2006 03:08:27.0916 (UTC) FILETIME=[18E04CC0:01C6B1F3] DKIM-Signature: a=rsa-sha1; q=dns; l=5219; t=1154056109; x=1154920109; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Hitchhikers=20guide=20-=20when=20is=20it=20done? |To:=22Drage,=20Keith=20\(Keith\)=22=20; X=v=3Dcisco.com=3B=20h=3DDpAaA9rWoxuoASPdrDDBO7lqI1E=3D; b=t74knLNViPSlDaiBbNaSplcSQ1+Cw5og0PiTUHpaBsQa5dNfzkHr3rWSdHAm9DkvBj+4kyzE 3TOSBOl/1SPgmRILyS51gYC1raklkGNpVtEOZaPdK+sVaXkMuQ4CByE5; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: IETF SIP List , "Romascanu, Dan \(Dan\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think once a year is reasonable. Hopefully this document itself is not controversial and there would be a relatively quick path through WGLC, review and IESG approval. -Jonathan R. Drage, Keith (Keith) wrote: > Lets indicate an expectation of once every 12 months. Within that period > there ought to be at least 10/20 references to either add or change. > > Regards > > Keith > > >>-----Original Message----- >>From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >>Sent: 27 July 2006 19:05 >>To: Jonathan Rosenberg >>Cc: IETF SIP List >>Subject: RE: [Sip] Hitchhikers guide - when is it done? >> >>I am aware about this. On the other hand, the problem with >>RFCs is that they tend to be updated at a slow pace. How >>often will the Hitchhiker Guide be updated? - every two, >>three years? I am looking at a semi-official solution to be >>used in-between, maintained at a known well place by a >>registrar nominated by the SIP WG or RAI Area. >> >> Dan >> >> >> >> >>>-----Original Message----- >>>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>>Sent: Wednesday, July 26, 2006 6:33 PM >>>To: Romascanu, Dan (Dan) >>>Cc: IETF SIP List >>>Subject: Re: [Sip] Hitchhikers guide - when is it done? >>> >>>The problem with any kind of website reference is that they >> >>are never >> >>>'official'. There are countless web sites enumerating SIP related >>>documents. What makes something an official output of the >> >>IETF is that >> >>>its an RFC. >>> >>>-Jonathan R. >>> >>>Romascanu, Dan (Dan) wrote: >>> >>> >>>>Because of the overhead and clerical delays involved in the >>>>publication of RFCs I would suggest a refinement to option >>> >>>2. Provide >>> >>>>a reference in the RFC to a Web page maintained and >>> >>>refreshed by the >>> >>>>SIP WG or the RAI Area including the >> >>'to-the-best-of-our-knowledge' >> >>>>updates in-between two versions of the RFC. >>>> >>>>Dan >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>>>>Sent: Tuesday, July 25, 2006 8:56 PM >>>>>To: IETF SIP List >>>>>Subject: [Sip] Hitchhikers guide - when is it done? >>>>> >>>>>During the IETF meeting, I discussed the one current open >>> >>>issue in the >>> >>>>>Hitchhikers guide. The issue is: when does the document >>> >>>finish? When >>> >>>>>do we send to IESG to issue an RFC? >>>>> >>>>>There were two approaches: >>>>> >>>>>1. split the document in two. One part contains only the >>> >>>core specs, >>> >>>>>and issues relatively soon. The other part has everything >> >>else, and >> >>>>>basically ends up being the last RFC produced by the SIP WG >>> >>>before it >>> >>>>>shuts its doors (which has always been 1.5 years from now >>> >>>for the last >>> >>>>>5 years). >>>>> >>>>>2. keep it as one document. Issue an RFC at some point, and then >>>>>revise it a few times as needed. We need to decide when >> >>to issue it. >> >>>>> >>>>>I'd like to propose option 2. I think people get more >> >>value from it >> >>>>>as a consolidated document. Furthermore, I'd propose that we send >>>>>the document to IESG for consideration as informational at the >>>>>instant all of the documents listed as 'core' have RFC numbers >>>>>issued by RFC-ed. >>>>> >>>>>Comments? >>>>> >>>>>-Jonathan R. >>>>>-- >>>>>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>>>Cisco Fellow Parsippany, NJ >>>>>07054-2711 >>>>>Cisco Systems >>>>>jdrosen@cisco.com FAX: >> >>(973) 952-5050 >> >>>>>http://www.jdrosen.net PHONE: >> >>(973) 952-5000 >> >>>>>http://www.cisco.com >>>>> >>>>>_______________________________________________ >>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>This list is for NEW development of the core SIP Protocol Use >>>>>sip-implementors@cs.columbia.edu for questions on current sip Use >>>>>sipping@ietf.org for new developments on the application of sip >>>>> >>>> >>>> >>>-- >>>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>Cisco Fellow Parsippany, NJ >>>07054-2711 >>>Cisco Systems >>>jdrosen@cisco.com FAX: (973) 952-5050 >>>http://www.jdrosen.net PHONE: (973) 952-5000 >>>http://www.cisco.com >>> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol Use >>sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 27 23:11:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Ijn-0000dp-M7; Thu, 27 Jul 2006 23:10:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Ijm-0000ZI-Hy for sip@ietf.org; Thu, 27 Jul 2006 23:10:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Ijl-00029p-7o for sip@ietf.org; Thu, 27 Jul 2006 23:10:06 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2006 20:10:05 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,190,1151910000"; d="scan'208"; a="33663228:sNHT23487660" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6S3A4jr016529; Thu, 27 Jul 2006 23:10:04 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6S3A4Yh021602; Thu, 27 Jul 2006 23:10:04 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 23:10:04 -0400 Received: from [10.255.255.157] ([10.86.243.26]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 23:10:04 -0400 Message-ID: <44C9800B.9000706@cisco.com> Date: Thu, 27 Jul 2006 23:10:03 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] draft-ietf-sip-gruu-09 References: <200606262132.k5QLWVZQ023989@dragon.ariadne.com> <44C841FB.7010601@cisco.com> <44C8BE81.6090207@cisco.com> In-Reply-To: <44C8BE81.6090207@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2006 03:10:04.0386 (UTC) FILETIME=[52607420:01C6B1F3] DKIM-Signature: a=rsa-sha1; q=dns; l=2201; t=1154056204; x=1154920204; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-gruu-09 |To:Paul=20Kyzivat=20; X=v=3Dcisco.com=3B=20h=3DO8HByhcMbAZHwIycqLttf1ne5yk=3D; b=0I/ueIwwd4D3JA6SJ+/aD2cBcxbXTX5VUtid7ptdYR0QoJO5cxvYMNf090xHaDsxEXz/VZJ9 8mNskCT7haKleXWPA9SHJP2bWCu7bDNBj4MWIBACCAid/IozNZ1C4EGD; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Oops - sorry to change my mind on this. I vaguely recall discussing this issue previously, but didn't remember that we concluded anything. There are some actual arguments in the threads and links I found arguing why URIs is better than URI (namely, its clear whether its plural or singular), that apply to GRUU too. So, I do think we should go with GRUUs and I've already made this edit in my working version of -10. -Jonathan R. Paul Kyzivat wrote: > > > Jonathan Rosenberg wrote: > >> Dale.Worley@comcast.net wrote: > > >>> There seems to be disagreement as to what the plural of GRUU is -- >>> GRUU or GRUUs. E.g., section 13, page 31 uses both "Furthermore, >>> GRUUs do not address" and "These GRUU will be passed". There is a >>> similar inconsistency regarding the plural of AOR. >> >> >> Well, this topic has come up for the term URI, which is the last U in >> GRUU. So it would stand to reason that if the plural of URI is URIs, >> then the plural of GRUU is GRUUs. I found some email threads on this >> topic, for example: >> >> http://lists.w3.org/Archives/Public/www-tag/2002Aug/0124.html >> >> and apparently this was an open issue in the preparation of the >> revision to 2396: >> >> http://www.gbiv.com/protocols/uri/rev-2002/issues.html#023-URI-plural >> >> the conclusion appears to be that the plural of URI is URIs. So, I >> suggest we follow suit and have the plural of GRUU be GRUUs. > > > Hey, that's not fair! > > I was looking for a precedent when cleaning up > draft-ietf-sipping-gruu-reg-event-06, and noticed there was > inconsistency in draft-ietf-sip-gruu. We discussed this, and I thought > we decided that the plural is GRUU. I made my draft consistent with that. > > If you decide this way then I should respin > draft-ietf-sipping-gruu-reg-event. > > Paul > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 28 00:18:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Jm4-0003AA-A9; Fri, 28 Jul 2006 00:16:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Jm2-00039r-Fb; Fri, 28 Jul 2006 00:16:30 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Jm2-0000g7-2w; Fri, 28 Jul 2006 00:16:30 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 23:16:29 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 27 Jul 2006 23:16:29 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 23:16:28 -0500 Message-ID: From: "Thomson, Martin" To: "Ted Hardie" , "Dawson, Martin" , "Andrew Newton" , "IETF SIP List" , "GEOPRIV" Date: Thu, 27 Jul 2006 23:14:35 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 28 Jul 2006 04:16:28.0483 (UTC) FILETIME=[99156930:01C6B1FC] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Geopriv] teasing apart: http as a GEOPRIV using protocol Thread-Index: Acax6Kqm1UPg2tFDS8mGk1J4pUxl+AAD8ISQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Subject: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0388470654==" Errors-To: sip-bounces@ietf.org --===============0388470654== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SXMgdGhpcyB0aGUgbG9vcGhvbGUgZXZlcnlvbmUgaGFzIGJlZW4gbG9va2luZyBmb3I/DQoNCiAg IFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgZGVzY3JpYmUgSFRUUCBhcyBhICJ1c2luZyBwcm90b2Nv bCIgd2hpY2gsIA0KICAgaW4gR2VvUFJJViB0ZXJtcywgaXMgYSBwcm90b2NvbCB3aGljaCAidXNl cyAocmVhZHMgb3IgbW9kaWZpZXMpDQogICB0aGUgTG9jYXRpb24gT2JqZWN0Ii4NCg0KT3IsIGFy ZSB3ZSBhYm92ZSB0aGUgc2NyYWJibGluZyBmb3IgbG9vcGhvbGVzIC0gYWZ0ZXIgYWxsIHdlWzFd IHdyb3RlIHRoZSBydWxlcywgd2Uga25vdyB0aGUgcmVhc29ucyBmb3IgdGhlIHJ1bGVzWzJdLCBz byB3aHkgYXJlIHdlIHBsYXlpbmcgZ2FtZXMgd2l0aCBkZWZpbml0aW9ucz8gIFRoaXMgaXMgYXZv aWRpbmcgUkZDIDM2OTMsIGFuZCBJJ20gZ3VpbHR5IG9mIHRoYXRbM10gKGlmIEkgcmVjYWxsLCB5 b3UgdG9sZCBtZSB0byBzdG9wKS4gIFdoeSBub3Qgc2ltcGx5IGFkZHJlc3MgdGhlIHJlcXVpcmVt ZW50cz8NCg0KVGhlIHBvaW50IHRoYXQgTWFydGluIChEKSB3YXMgbWFraW5nIGlzIHJlbGF0ZWQg dG8gdGhlIGZhY3QgdGhhdCBjb252ZXlhbmNlIGRvZXNuJ3QgaGF2ZSB0byBzcGVjaWZ5IGhvdyBh IHJlZmVyZW5jZSBpcyB1c2VkLiAgVGhhdCBkb2Vzbid0IG1lYW4gdGhhdCBpdCBkb2Vzbid0IGhh dmUgdG8gYmUgc3BlY2lmaWVkIGF0IGFsbCwgYnV0IFNJUCBjYW4gdHJlYXQgdGhpcyBhcyBvcGFx dWUgZGF0YSAoZXhjZXB0IGNpZDosIG9mIGNvdXJzZSkuICANCg0KQ2hlZXJzLA0KTWFydGluDQoN ClsxXSBUYWtpbmcgdGhpcyBpbiB0aGUgYnJvYWRlc3Qgc2Vuc2Ugb2YgdGhlIHRlcm0gIndlIi4N ClsyXSBUaGlzIGlzIHN0YXRlZCwgYnV0IGlzIG9mdGVuIGRlbW9uc3RyYWJseSB1bnRydWUuDQpb M10gVGhlIGNvbmNlcHQgb2YgInNpZ2h0aW5nIiB3YXMgc2VlbiBhcyBhIGNvbnZlbmllbnQgbG9v cGhvbGUuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVGVkIEhhcmRp ZSBbbWFpbHRvOmhhcmRpZUBxdWFsY29tbS5jb21dDQo+IFNlbnQ6IEZyaWRheSwgMjggSnVseSAy MDA2IDExOjUzIEFNDQo+IFRvOiBEYXdzb24sIE1hcnRpbjsgQW5kcmV3IE5ld3RvbjsgSUVURiBT SVAgTGlzdDsgR0VPUFJJVg0KPiBTdWJqZWN0OiBSRTogW0dlb3ByaXZdIHRlYXNpbmcgYXBhcnQ6 IGh0dHAgYXMgYSBHRU9QUklWIHVzaW5nIHByb3RvY29sDQo+IA0KPiBIaSBNYXJ0aW4sDQo+IAlI YXZpbmcgbm90IHNlZW4geW91ciBub3RlLCBJIGFscmVhZHkgdG9vayBhIHN0YWINCj4gaXQsIGFs b25nIG11Y2ggdGhlIHNhbWUgbGluZXMgeW91IHN1Z2dlc3QuICBDbGVhcmx5LCB0aGUgYXR0YWNo ZWQNCj4gLTAwIChub3QgeWV0IGluIHRoZSBkcmFmdHMgZGlyZWN0b3JpZXMpIGlzIHRoZSBiYXJl c3Qgb2YgYmFyZSBib25lcywNCj4gYnV0IEkgdGhvdWdodCBpdCBtaWdodCBiZSB1c2VmdWwgdG8g c2tldGNoIHRoYXQgb3V0IGFzIGEgY29udHJhc3QNCj4gdG8gc29tZSBvZiB0aGUgcmVhbCBhcHBs aWNhdGlvbnMgd2hpY2ggbWlnaHQgdXNlIEhUVFAgYXMgYQ0KPiB1c2luZyBwcm90b2NvbC4NCj4g CUkgYmVsaWV2ZSB0aGlzIGFsc28gZGlmZmVycyBmcm9tIFJFTE8gaW4gdGhhdCBpdCBpcw0KPiBm b2N1c2VkIG9uIHRoZSB0cmFuc3BvcnQgb2YgUElERi1MTywgd2hpY2ggaXMgc2xpZ2h0bHkgZGlm ZmVyZW50DQo+IGZyb20gUkVMTydzIHJlbWl0LiAgQnV0IGNsZWFybHksIHRoZXJlIGFyZSBzdHJv bmcgY29ubmVjdGlvbnMgdGhlcmUuDQo+IAlBbmQgaWYgdGhlIHBocmFzZSAic3RyYXdtYW4iIGlu IHRoZSB0aXRsZSBkb2Vzbid0DQo+IHNpZ25hbCB0aGF0IEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBh IGRvbmUgcGllY2Ugb2Ygd29yaywgYWxsb3cNCj4gdGhpcyB0b28uDQo+IAkJCXJlZ2FyZHMsDQo+ IAkJCQlUZWQgSGFyZGllDQo+IA0KPiANCj4gQXQgNzo1MCBQTSAtMDUwMCA3LzI3LzA2LCBEYXdz b24sIE1hcnRpbiB3cm90ZToNCj4gPkhpIEFuZHksDQo+ID4NCj4gPkknbGwgdGFrZSBhIHN0YWIg YXQgaXQuIE5vdCB0aGF0IEhUVFAgaXMgYSB2YWxpZCAqdXNpbmcgcHJvdG9jb2wqIGJ1dCwNCj4g PnJhdGhlciwgdGhhdCB0aGUgbG9jYXRpb24gcmVmZXJlbmNlIGRvZXMgbm90IGFjdHVhbGx5IGlk ZW50aWZ5IGEgdXNpbmcNCj4gPnByb3RvY29sIGFuZCwgaW4gZmFjdCwgSFRUUCB3b3VsZCBvbmx5 IGJlIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wuLi4NCj4gPg0KPiA+MzY5MyBzdGF0ZXM6DQo+ID4g ICBUaGUgInVzaW5nIHByb3RvY29sIiBpcyB0aGUgcHJvdG9jb2wgdGhhdCB1c2VzIChyZWFkcyBv ciBtb2RpZmllcykNCj4gPiAgIHRoZSBMb2NhdGlvbiBPYmplY3QuICBBIHByb3RvY29sIHRoYXQg anVzdCB0cmFuc3BvcnRzIHRoZSBMTyBhcyBhDQo+ID4gICBzdHJpbmcgb2YgYml0cywgd2l0aG91 dCBsb29raW5nIGF0IHRoZW0gKGxpa2UgYW4gSVAgc3RvcmFnZSBwcm90b2NvbA0KPiA+ICAgY291 bGQgZG8pLCBpcyBub3QgYSB1c2luZyBwcm90b2NvbCwgYnV0IG9ubHkgYSB0cmFuc3BvcnQgcHJv dG9jb2wuDQo+ID4gICBOZXZlcnRoZWxlc3MsIHRoZSBlbnRpdHkgb3IgcHJvdG9jb2wgdGhhdCBj YXVzZWQgdGhlIHRyYW5zcG9ydA0KPiA+ICAgcHJvdG9jb2wgdG8gbW92ZSB0aGUgTE8gaXMgcmVz cG9uc2libGUgZm9yIHRoZSBhcHByb3ByaWF0ZQ0KPiA+ICAgZGlzdHJpYnV0aW9uLCBwcm90ZWN0 aW9uLCB1c2FnZSwgcmV0ZW50aW9uLCBhbmQgc3RvcmFnZSBvZiB0aGUgTE8NCj4gPiAgIGJhc2Vk IG9uIHRoZSBydWxlcyB0aGF0IGFwcGx5IHRvIHRoYXQgTE8uDQo+ID4NCj4gPkEgbG9jYXRpb24g cmVmZXJlbmNlIHdoaWNoIHByb3ZpZGVkIGFuIEhUVFAgVVJJIGluZGljYXRlcyB0aGF0IHRoZQ0K PiA+ZW50aXR5IHRoYXQgaXMgZ29pbmcgdG8gYmUgdXNlZCB0byByZXF1ZXN0IHRoZSBMTyBpcyB0 byBiZSBjb21tdW5pY2F0ZWQNCj4gPndpdGggdXNpbmcgSFRUUC4gQmVjYXVzZSBvZiB0aGUgcnVs ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBQSURGLUxPLCBpdA0KPiA+Y2FuIGJlIGluZmVycmVkIHRo YXQgdGhlIGVudGl0eSBhbmQgd2hhdGV2ZXIgc2VtYW50aWNzIGFyZSBhc3NvY2lhdGVkDQo+ID53 aXRoIHRoZSBIVFRQIGNvbW11bmljYXRpb25zIHdpdGggdGhhdCBlbnRpdHkgd2lsbCBob25vciB0 aGUNCj4gPnJlcXVpcmVtZW50cy4gVGhhdCBpcywgSFRUUCBpcyBvbmx5IHRoZSB0cmFuc3BvcnQg cHJvdG9jb2wuIEFuIEhUVFAgR0VUDQo+ID5oYXMgdG8gYmUgaW50ZXJwcmV0ZWQgYnkgdGhlIHJl Y2VpdmluZyBlbnRpdHkgd2l0aGluIHRoZSBzY29wZSBvZiBhDQo+ID51c2luZyBwcm90b2NvbCAt IHdpdGggaXRzIGFzc29jaWF0ZWQgc2V0IG9mIHJ1bGVzIGFuZCBzZW1hbnRpY3MgLSB3aGljaA0K PiA+Z28gYmV5b25kIEhUVFAgYW5kIHdoaWNoIGRvIHJlc3BlY3QgdGhlIGdlb3ByaXYgcmVxdWly ZW1lbnRzLiBJbmRlZWQsDQo+ID50aGlzIGlzIGdlbmVyYWxseSB0aGUgY2FzZSAtIHNlbmRpbmcg YW4gSFRUUCBHRVQgdG8gYW4gYXJiaXRyYXJ5IElQIG5vZGUNCj4gPmNhbiB5aWVsZCBhbnkgbnVt YmVyIG9mIHJlc3VsdHMgZGVwZW5kaW5nIHdoYXQgdGhhdCBub2RlIGFjdHVhbGx5IGRvZXMuDQo+ ID5UaGUgY2xpZW50IG5lZWRzIHRvIHVuZGVyc3RhbmQgdGhlIHB1cnBvc2Ugb2YgdGhhdCBzZXJ2 ZXIgaW4gdGhlIHNjb3BlDQo+ID5vZiBzb21lIGhpZ2hlciBsZXZlbCBwcm90b2NvbC4NCj4gPg0K PiA+VG8gdXNlIGFub3RoZXIgZXhhbXBsZSwgYSBsb2NhdGlvbiByZWZlcmVuY2UgY291bGQgYmUg YW4gSVAgYWRkcmVzcy4NCj4gPlRoZXJlJ3Mgbm90aGluZyBpbmhlcmVudCBpbiBJUCB0aGF0IGhv bm9ycyB0aGUgZ2VvcHJpdiBydWxlcywgYnV0IHRoYXQNCj4gPmRvZXNuJ3Qgc3RvcCB0aGUgcmVm ZXJlbmNlIGJlaW5nIHZhbGlkIG5vciBzYXkgdGhhdCB0aGUgcHJvdG9jb2wgdXNlZA0KPiA+YmV0 d2VlbiBhIGNsaWVudCBhbmQgdGhhdCBJUCBhZGRyZXNzIHdvdWxkIG5vdCBob25vciB0aGUgcnVs ZXMuDQo+ID4NCj4gPlRoZSBwdXJwb3NlIG9mIHRoZSBTSVAgY29udmV5YW5jZSBzcGVjaWZpY2F0 aW9uIGlzIHRvIHNheSBob3cgYSBMTyBvcg0KPiA+cmVmZXJlbmNlIGNhbiBiZSB0cmFuc2ZlcnJl ZCBmcm9tIG9uZSBlbnRpdHkgdG8gYW5vdGhlciB1c2luZyBTSVAuIEl0J3MNCj4gPm91dCBvZiBz Y29wZSBmb3IgYSBTSVAgc3BlY2lmaWNhdGlvbiB0byBtYW5kYXRlIGFueXRoaW5nIGFib3V0IHRo ZQ0KPiA+dHJhbnNwb3J0IHByb3RvY29sIG9yIHRvIGluZmVyIGFueXRoaW5nIGFib3V0IHVzaW5n IHByb3RvY29sIGltcGxpZWQgYnkNCj4gPnRoYXQgdHJhbnNwb3J0LiBBcyBoYXMgYmVlbiBwcmV2 aW91c2x5IG1lbnRpb25lZCwgdGhpcyB3b3VsZCBiZSBzdWJqZWN0DQo+ID50byBzZXBhcmF0ZSBz cGVjaWZpY2F0aW9uIGFuZCBCQ1AgLSBsZXN0IHRoZSBTSVAgY29udmV5YW5jZQ0KPiA+c3BlY2lm aWNhdGlvbiBiZWNvbWUgb3Zlcmx5IHJpZ2lkIGFuZCBzdWJqZWN0IHRvIHVubmVjZXNzYXJ5IG1h aW50ZW5hbmNlDQo+ID5hbmQgY2h1cm4uDQo+ID4NCj4gPkNoZWVycywNCj4gPk1hcnRpbg0KPiA+ DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEFuZHJldyBOZXd0 b24gW21haWx0bzphbmR5QGh4ci51c10NCj4gPj4gU2VudDogVGh1cnNkYXksIDI3IEp1bHkgMjAw NiAxMDo0NSBQTQ0KPiA+PiBUbzogSUVURiBTSVAgTGlzdDsgR0VPUFJJVg0KPiA+PiBTdWJqZWN0 OiBbR2VvcHJpdl0gdGVhc2luZyBhcGFydDogaHR0cCBhcyBhIEdFT1BSSVYgdXNpbmcgcHJvdG9j b2wNCj4gPj4NCj4gPj4gVGhlcmUgaGF2ZSBiZWVuIGEgbnVtYmVyIG9mIG9waW5pb25zIHJlZ2Fy ZGluZyBIVFRQIGFzIGEgdXNpbmcNCj4gPnByb3RvY29sLg0KPiA+Pg0KPiA+PiBJJ2QgbGlrZSB0 byBrbm93LCBob3cgbWFueSBwZW9wbGUgYmVsaWV2ZSB0aGF0IEhUVFAgcmVxdWlyZXMgbm8gb3IN Cj4gPj4gdmVyeSBsaXR0bGUgc3BlY2lmaWNhdGlvbiB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMg aW4gUkZDIDM2OTMgYW5kDQo+ID4+IFJGQyAzNjk0LiAgSWYgeW91IGJlbGlldmUgdGhpcywgd2hh dCBiYXNpcyBkbyB5b3UgaGF2ZSBmb3IgdGhpcw0KPiA+PiBjb25jbHVzaW9uPyAgT3IgZG8geW91 IGJlbGlldmUgbW9yZSBzcGVjaWZpY2F0aW9uIG5lZWRzIHRvIGJlIGRvbmUsDQo+ID4+IGJ1dCBp dCBpcyBwb3NzaWJsZSBmb3IgSFRUUCB0byBiZSBhIEdFT1BSSVYgdXNpbmcgcHJvdG9jb2w/DQo+ ID4gPg0KPiA+PiBGaW5hbGx5LCBob3cgbWFueSBwZW9wbGUgYmVsaWV2ZSB0aGF0IEhUVFAgc2hv dWxkIG5vdCBiZSBhIHVzaW5nDQo+ID4+IHByb3RvY29sPw0KPiA+Pg0KPiA+PiAtYW5keQ0KPiA+ Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+PiBHZW9wcml2IG1haWxpbmcgbGlzdA0KPiA+PiBHZW9wcml2QGlldGYub3JnDQo+ID4+IGh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYNCj4gPg0KPiA+LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+VGhpcyBtZXNzYWdl IGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQo+ID5jb250YWlu IHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlv bi4NCj4gPklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXINCj4gPmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVu YXV0aG9yaXplZCB1c2Ugb2YNCj4gPnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCj4gPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPlttZjJdDQo+ID4NCj4g Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID5HZW9w cml2IG1haWxpbmcgbGlzdA0KPiA+R2VvcHJpdkBpZXRmLm9yZw0KPiA+aHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VvcHJpdg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lw aWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90 aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRl IHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHBy b2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============0388470654== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0388470654==-- From sip-bounces@ietf.org Fri Jul 28 01:26:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6KpV-0001u9-FM; Fri, 28 Jul 2006 01:24:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6KpU-0001u1-No; Fri, 28 Jul 2006 01:24:08 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6KpT-0001jA-BG; Fri, 28 Jul 2006 01:24:08 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 00:24:06 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 28 Jul 2006 00:24:06 -0500 Received: from AOPEX4.andrew.com ([10.3.20.127]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 00:24:06 -0500 Message-ID: From: "Dawson, Martin" To: "Ted Hardie" , "Andrew Newton" , "IETF SIP List" , "GEOPRIV" Date: Fri, 28 Jul 2006 00:24:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 28 Jul 2006 05:24:06.0054 (UTC) FILETIME=[0B959C60:01C6B206] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Geopriv] teasing apart: http as a GEOPRIV using protocol Thread-Index: Acax6KGdCqRlPfJfRWmicTwB7UV+kQAHGydA X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: Subject: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org G'day Ted, Strawman or not, I think what you've written is a good example of why the location reference does not need to say anything about whether the geopriv rules for a PIF-LO using protocol are honored or not. The point being that once the reference is used to establish a "using protocol session" it must be the case that these rules are then honored. The authentication and security steps that you have identified in your draft - where https is used first; and it could be any equivalent function - are an integral part of the semantics of the using protocol defined in this example. And they are independent of, and not explicit in, the reference itself. Thanks for that. Cheers, Martin > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Friday, 28 July 2006 11:53 AM > To: Dawson, Martin; Andrew Newton; IETF SIP List; GEOPRIV > Subject: RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol >=20 > Hi Martin, > Having not seen your note, I already took a stab > it, along much the same lines you suggest. Clearly, the attached > -00 (not yet in the drafts directories) is the barest of bare bones, > but I thought it might be useful to sketch that out as a contrast > to some of the real applications which might use HTTP as a > using protocol. > I believe this also differs from RELO in that it is > focused on the transport of PIDF-LO, which is slightly different > from RELO's remit. But clearly, there are strong connections there. > And if the phrase "strawman" in the title doesn't > signal that I don't think this is a done piece of work, allow > this too. > regards, > Ted Hardie >=20 >=20 > At 7:50 PM -0500 7/27/06, Dawson, Martin wrote: > >Hi Andy, > > > >I'll take a stab at it. Not that HTTP is a valid *using protocol* but, > >rather, that the location reference does not actually identify a using > >protocol and, in fact, HTTP would only be the transport protocol... > > > >3693 states: > > The "using protocol" is the protocol that uses (reads or modifies) > > the Location Object. A protocol that just transports the LO as a > > string of bits, without looking at them (like an IP storage protocol > > could do), is not a using protocol, but only a transport protocol. > > Nevertheless, the entity or protocol that caused the transport > > protocol to move the LO is responsible for the appropriate > > distribution, protection, usage, retention, and storage of the LO > > based on the rules that apply to that LO. > > > >A location reference which provided an HTTP URI indicates that the > >entity that is going to be used to request the LO is to be communicated > >with using HTTP. Because of the rules associated with the PIDF-LO, it > >can be inferred that the entity and whatever semantics are associated > >with the HTTP communications with that entity will honor the > >requirements. That is, HTTP is only the transport protocol. An HTTP GET > >has to be interpreted by the receiving entity within the scope of a > >using protocol - with its associated set of rules and semantics - which > >go beyond HTTP and which do respect the geopriv requirements. Indeed, > >this is generally the case - sending an HTTP GET to an arbitrary IP node > >can yield any number of results depending what that node actually does. > >The client needs to understand the purpose of that server in the scope > >of some higher level protocol. > > > >To use another example, a location reference could be an IP address. > >There's nothing inherent in IP that honors the geopriv rules, but that > >doesn't stop the reference being valid nor say that the protocol used > >between a client and that IP address would not honor the rules. > > > >The purpose of the SIP conveyance specification is to say how a LO or > >reference can be transferred from one entity to another using SIP. It's > >out of scope for a SIP specification to mandate anything about the > >transport protocol or to infer anything about using protocol implied by > >that transport. As has been previously mentioned, this would be subject > >to separate specification and BCP - lest the SIP conveyance > >specification become overly rigid and subject to unnecessary maintenance > >and churn. > > > >Cheers, > >Martin > > > >> -----Original Message----- > >> From: Andrew Newton [mailto:andy@hxr.us] > >> Sent: Thursday, 27 July 2006 10:45 PM > >> To: IETF SIP List; GEOPRIV > >> Subject: [Geopriv] teasing apart: http as a GEOPRIV using protocol > >> > >> There have been a number of opinions regarding HTTP as a using > >protocol. > >> > >> I'd like to know, how many people believe that HTTP requires no or > >> very little specification to meet the requirements in RFC 3693 and > >> RFC 3694. If you believe this, what basis do you have for this > >> conclusion? Or do you believe more specification needs to be done, > >> but it is possible for HTTP to be a GEOPRIV using protocol? > > > > >> Finally, how many people believe that HTTP should not be a using > >> protocol? > >> > >> -andy > >> > >> _______________________________________________ > >> Geopriv mailing list > >> Geopriv@ietf.org > >> https://www1.ietf.org/mailman/listinfo/geopriv > > > >----------------------------------------------------------------------- -- > ----------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >----------------------------------------------------------------------- -- > ----------------------- > >[mf2] > > > >_______________________________________________ > >Geopriv mailing list > >Geopriv@ietf.org > >https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 28 01:30:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6KuM-0000G5-Qb; Fri, 28 Jul 2006 01:29:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6KuL-0000Fw-IC; Fri, 28 Jul 2006 01:29:09 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6KuK-00038X-69; Fri, 28 Jul 2006 01:29:09 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6S5T42p026372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2006 22:29:04 -0700 Received: from [10.0.1.3] (vpn-10-50-16-137.qualcomm.com [10.50.16.137]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6S5Sw33008383; Thu, 27 Jul 2006 22:29:03 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 27 Jul 2006 22:28:57 -0700 To: "Thomson, Martin" , "Dawson, Martin" , "Andrew Newton" , "IETF SIP List" , "GEOPRIV" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 11:14 PM -0500 7/27/06, Thomson, Martin wrote: > >Or, are we above the scrabbling for loopholes - after all we[1] wrote the rules, we know the reasons for the rules[2], so why are we playing games with definitions? This is avoiding RFC 3693, and I'm guilty of that[3] (if I recall, you told me to stop). Why not simply address the requirements? > >The point that Martin (D) was making is related to the fact that conveyance doesn't have to specify how a reference is used. That doesn't mean that it doesn't have to be specified at all, but SIP can treat this as opaque data (except cid:, of course). > >Cheers, >Martin Going through 3693 again was what inspired me to put up a strawman. I hope setting it alight gets us some light and not too much heat. My own reading says that if you want to use HTTP as a transport of PIDF-LO, rather than as a using protocol, you have to use it in a way that protects the privacy of the object in flight (encrypting TLS in the strawman, but it could be mandating s/mime or something else), and you have to be sure that the parties transporting it are authenticated to each other (to protect against monkey-in-the-middle attacks as a start). More importantly, you have to use it in a protocol context where it is handed off after transport to some other protocol or application which then does the real work of reading or modifying the object and of obeying the rules. To me that means that it can't be used in this way loosely--just implementing this strawman and calling it a using protocol would be utterly bogus, since once it arrives at the client, you haven't said what to do with it all or how the geopriv requirements are met. But I think it *might* be valid in very specific protocol contexts where you have said what happens when the *using protocol* (SIP, in this example) does from there. It may be, of course, that I was thinking to hard and need to take a bit of a lie down to recover. But I thought about the URI schemes which encode data in the URI itself, and I thought: how can those be using protocols? Obviously, they aren't; they're just ways of carrying the data around for the benefit of real using protocols. If that is the case, we may be able to do something simple to specify how to use a suitably protected transport to dereference a URI rather than carrying the data inside the using protocol. But I think that this fundamentally requires that the transport/dereference occur in a very bounded protocol context inside the real using protocol. Otherwise, you are absolutely right that it is just an end-run. To re-iterate: this a strawman; feel free to rip up the innards and use as a pillow, flammable materials, or use as you see fit. I won't be offended if the response is any of the above. regards, Ted _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 28 01:34:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Ky6-0004p5-84; Fri, 28 Jul 2006 01:33:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Ky4-0004ok-8c for sip@ietf.org; Fri, 28 Jul 2006 01:33:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6IwU-0003G4-H8 for sip@ietf.org; Thu, 27 Jul 2006 23:23:14 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G6Iog-0001bI-9O for sip@ietf.org; Thu, 27 Jul 2006 23:15:12 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2006 20:15:03 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,190,1151910000"; d="scan'208"; a="33663503:sNHT23861880" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6S3F3tS017520 for ; Thu, 27 Jul 2006 23:15:03 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6S3F2dU016578 for ; Thu, 27 Jul 2006 23:15:02 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 23:15:02 -0400 Received: from [10.255.255.157] ([10.86.243.26]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 23:15:02 -0400 Message-ID: <44C98135.70705@cisco.com> Date: Thu, 27 Jul 2006 23:15:01 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Re: draft-ietf-sip-gruu-09 References: <720BC7A4-8BFF-412E-A6BC-FAC41FA1289B@cisco.com> <44C83461.4020806@cisco.com> <44C8BC2F.1000406@cisco.com> In-Reply-To: <44C8BC2F.1000406@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2006 03:15:02.0187 (UTC) FILETIME=[03E147B0:01C6B1F4] DKIM-Signature: a=rsa-sha1; q=dns; l=3347; t=1154056503; x=1154920503; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Re=3A=20draft-ietf-sip-gruu-09 |To:Paul=20Kyzivat=20; X=v=3Dcisco.com=3B=20h=3Dn/vq3M7BiyY/aKQt0tfUt668gig=3D; b=FSkInzdzz5KfFQ05cPEkjrMh7N/E7dWz/ZLpTcJYgVgbiKhpvy9mnU6VAK+tlMDJLVEnqcIj RDo8N1RFmGEq4r6xJ8oTyAE8gPFEBVBVKcqhxRfkkyc0/uwc4zVv8m+8; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Cullen Jennings , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Paul Kyzivat wrote: > > > Jonathan Rosenberg wrote: > >> Cullen Jennings wrote: > > >>> Section 6, page 12, 4th para or so ... you are talking about mid- >>> dialog requests. Might be nice to mention how a transaction stateful >>> proxy knows if something is a middialog request or not. >> >> >> These days I recommend topmost route URI over tags, since its easy to >> fool a proxy into thinking something is a mid-dialog request by faking >> a tag. Its harder to fake a route URI. >> >> Text now reads: >> >> Mid-dialog requests will also be sent to GRUUs, as they are >> included as the remote-target in dialog-forming and target refresh >> requests and responses. However, in those cases, a proxy SHOULD only >> apply services that are meaningful for mid-dialog requests, generally >> speaking. This excludes screening functions, as well as forwarding >> ones. A proxy can determine that a request is a mid-dialog request >> based on the Route header field in the request it receives. If the >> topmost URI matches one that the proxy placed into the Record-Route >> header field of a dialog-forming request, then the request is a >> mid-dialog request. > > > Is it really harder to fake? If the objective is to fool a *proxy* into thinking a request is a mid-dialog request, then yes. If a proxy uses the mere presence of the To tag as the indicator of a mid-dialog request, then a UA can simply send an initial request with any arbitrary tag in the To header field. If a proxy uses the value of Route header field, then the UA has to construct a Route header field value which the proxy will accept. If the proxy is halfway intelligent in construction of record-routes, it'll use random numbers, hashes, and otherwise proprietary techniques to construct the URI. The odds are pretty good that the UA would not be able to construct a Route URI that the proxy would recognize as one that it would have inserted into a Record-Route. Now, a request that contains a tag not matching any dialog at the UAS is rejected anyway. However, you might be able to work with a cooperating UAS to make something useful happen. For example if a proxy is generating call start and stop records based on *initial* INVITE and BYE, respectively, cooperating UA might be able to get free calls. > > Suppose Alice is permitted to call Bob, but not to subscribe to the reg > event package. So Alice first calls Bob, and notes the Record-Route that > results. Then in a separate dialog, Alice sends a SUBSCRIBE to the reg > event package, including a Route header with a URI of Bob's home proxy > extracted from the old R-R. If the RR is constructed using hashes of the tags this won't work. > > Seems like this strategy also requires some protection against a "replay > attack" like this. > > But that isn't really an issue for this draft. No; but it makes for interesting list discussion ;) -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 28 01:54:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6LGt-0002p4-0J; Fri, 28 Jul 2006 01:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6LGr-0002or-74; Fri, 28 Jul 2006 01:52:25 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6LGp-0006ay-Sk; Fri, 28 Jul 2006 01:52:25 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 00:52:23 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 28 Jul 2006 00:52:22 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 00:52:22 -0500 Message-ID: From: "Thomson, Martin" To: "Ted Hardie" , "Dawson, Martin" , "Andrew Newton" , "IETF SIP List" , "GEOPRIV" Date: Fri, 28 Jul 2006 00:52:20 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 28 Jul 2006 05:52:22.0054 (UTC) FILETIME=[FE7AAC60:01C6B209] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Geopriv] teasing apart: http as a GEOPRIV using protocol Thread-Index: AcayBr69OxHxwsvKRlSAHccec+/C3gAAJYZA X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Subject: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0789515576==" Errors-To: sip-bounces@ietf.org --===============0789515576== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSBndWVzcyB0aGF0IEkgd2FzIHRyeWluZyB0byBiZSBpbmZsYW1tYXRvcnkuIDspDQoNCldoYXQg d291bGQgYmUgbmljZSBvbiB5b3VyIHN0cmF3bWFuIGlzIGEgaGF0LCBhIHBpcGUsIGEgY2Fycm90 IG5vc2UgYW5kIHNvbWUgZXllcy4gIFRoYXQgaXMsIEkgZG9uJ3QgdGhpbmsgaXQncyBjb21wbGV0 ZSBhcyBhIHN0cmF3bWFuIHVudGlsIHlvdSBhZGRyZXNzIHRoZSBSRkMgMzY5MyByZXF1aXJlbWVu dHMuICBUaGUgbGF3eWVyaW5nIGhhcyBkZXZhbHVlZCB0aGUgdGVybSAidXNpbmcgcHJvdG9jb2wi IGJ1dCBJIHN0aWxsIHNlZSB2YWx1ZSBpbiB0aGUgdW5kZXJseWluZyByZXF1aXJlbWVudHMgLSBl dmlkZW50bHkgeW91IGRvIHRvby4gIElycmVzcGVjdGl2ZSBvZiB3aGV0aGVyIGl0J3MgYSAidXNp bmcgcHJvdG9jb2wiIG9yIG5vdCwgaXQgbmVlZHMgdG8gcHJvdmlkZSBzb21lIGxldmVsIG9mIHBy aXZhY3kgcHJvdGVjdGlvbi4NCg0KV2UgY2FuIHF1aWJibGUgb3ZlciB0ZXJtaW5vbG9neSwgYnV0 IEknZCBwcmVmZXIgdG8gc2VlIHRoaXMgYWRkcmVzcyB0aGUgcmVxdWlyZW1lbnRzLg0KDQpSZXEg MS4gU2VlIFJGQyA0MTE5DQouLi4NClJlcSA2LiBJbnRlcmVzdGluZyBvbmUuLi4gSSdkIHN1Z2dl c3QgdGhhdCB0aGlzIG1pZ2h0IG5vdCBiZSB2ZXJ5IGVhc3kgdG8gbWVldC4gDQpSZXEgNy4gLi4u DQoNClRoYXQgd291bGQgYmUgYSBiZXR0ZXIgc3RyYXdtYW4gZm9yIG1lLiAgQXNpZGUgZnJvbSBS ZXEucyA2IGFuZCBtYXliZSAxNS4zIEkgZG9uJ3QgdGhpbmsgeW91IHdpbGwgaGF2ZSB0byBlcXVp dm9jYXRlIHRvIG1lZXQgdGhlIHJlcXVpcmVtZW50cy4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBUZWQgSGFyZGllIFttYWlsdG86aGFyZGllQHF1YWxjb21tLmNvbV0N Cj4gU2VudDogRnJpZGF5LCAyOCBKdWx5IDIwMDYgMzoyOSBQTQ0KPiBUbzogVGhvbXNvbiwgTWFy dGluOyBEYXdzb24sIE1hcnRpbjsgQW5kcmV3IE5ld3RvbjsgSUVURiBTSVAgTGlzdDsgR0VPUFJJ Vg0KPiBTdWJqZWN0OiBSRTogW0dlb3ByaXZdIHRlYXNpbmcgYXBhcnQ6IGh0dHAgYXMgYSBHRU9Q UklWIHVzaW5nIHByb3RvY29sDQo+IA0KPiBBdCAxMToxNCBQTSAtMDUwMCA3LzI3LzA2LCBUaG9t c29uLCBNYXJ0aW4gd3JvdGU6DQo+ID4NCj4gPk9yLCBhcmUgd2UgYWJvdmUgdGhlIHNjcmFiYmxp bmcgZm9yIGxvb3Bob2xlcyAtIGFmdGVyIGFsbCB3ZVsxXSB3cm90ZSB0aGUNCj4gcnVsZXMsIHdl IGtub3cgdGhlIHJlYXNvbnMgZm9yIHRoZSBydWxlc1syXSwgc28gd2h5IGFyZSB3ZSBwbGF5aW5n IGdhbWVzDQo+IHdpdGggZGVmaW5pdGlvbnM/ICBUaGlzIGlzIGF2b2lkaW5nIFJGQyAzNjkzLCBh bmQgSSdtIGd1aWx0eSBvZiB0aGF0WzNdDQo+IChpZiBJIHJlY2FsbCwgeW91IHRvbGQgbWUgdG8g c3RvcCkuICBXaHkgbm90IHNpbXBseSBhZGRyZXNzIHRoZQ0KPiByZXF1aXJlbWVudHM/DQo+ID4N Cj4gPlRoZSBwb2ludCB0aGF0IE1hcnRpbiAoRCkgd2FzIG1ha2luZyBpcyByZWxhdGVkIHRvIHRo ZSBmYWN0IHRoYXQNCj4gY29udmV5YW5jZSBkb2Vzbid0IGhhdmUgdG8gc3BlY2lmeSBob3cgYSBy ZWZlcmVuY2UgaXMgdXNlZC4gIFRoYXQgZG9lc24ndA0KPiBtZWFuIHRoYXQgaXQgZG9lc24ndCBo YXZlIHRvIGJlIHNwZWNpZmllZCBhdCBhbGwsIGJ1dCBTSVAgY2FuIHRyZWF0IHRoaXMNCj4gYXMg b3BhcXVlIGRhdGEgKGV4Y2VwdCBjaWQ6LCBvZiBjb3Vyc2UpLg0KPiA+DQo+ID5DaGVlcnMsDQo+ ID5NYXJ0aW4NCj4gDQo+IEdvaW5nIHRocm91Z2ggMzY5MyBhZ2FpbiB3YXMgd2hhdCBpbnNwaXJl ZCBtZSB0byBwdXQgdXAgYSBzdHJhd21hbi4gIEkNCj4gaG9wZQ0KPiBzZXR0aW5nIGl0IGFsaWdo dCBnZXRzIHVzIHNvbWUgbGlnaHQgYW5kIG5vdCB0b28gbXVjaCBoZWF0Lg0KPiANCj4gTXkgb3du IHJlYWRpbmcgc2F5cyB0aGF0IGlmIHlvdSB3YW50IHRvIHVzZSBIVFRQIGFzIGEgdHJhbnNwb3J0 IG9mIFBJREYtDQo+IExPLCByYXRoZXINCj4gdGhhbiBhcyBhIHVzaW5nIHByb3RvY29sLCB5b3Ug aGF2ZSB0byB1c2UgaXQgaW4gYSB3YXkgdGhhdCBwcm90ZWN0cyB0aGUNCj4gcHJpdmFjeQ0KPiBv ZiB0aGUgb2JqZWN0IGluIGZsaWdodCAoZW5jcnlwdGluZyBUTFMgaW4gdGhlIHN0cmF3bWFuLCBi dXQgaXQgY291bGQgYmUNCj4gbWFuZGF0aW5nDQo+IHMvbWltZSBvciBzb21ldGhpbmcgZWxzZSks IGFuZCB5b3UgaGF2ZSB0byBiZSBzdXJlIHRoYXQgdGhlIHBhcnRpZXMNCj4gdHJhbnNwb3J0aW5n DQo+IGl0IGFyZSBhdXRoZW50aWNhdGVkIHRvIGVhY2ggb3RoZXIgKHRvIHByb3RlY3QgYWdhaW5z dCBtb25rZXktaW4tdGhlLQ0KPiBtaWRkbGUgYXR0YWNrcw0KPiBhcyBhIHN0YXJ0KS4NCj4gDQo+ IE1vcmUgaW1wb3J0YW50bHksIHlvdSBoYXZlIHRvIHVzZSBpdCBpbiBhIHByb3RvY29sIGNvbnRl eHQgd2hlcmUgaXQgaXMNCj4gaGFuZGVkIG9mZg0KPiBhZnRlciB0cmFuc3BvcnQgdG8gc29tZSBv dGhlciBwcm90b2NvbCBvciBhcHBsaWNhdGlvbiB3aGljaCB0aGVuIGRvZXMgdGhlDQo+IHJlYWwN Cj4gd29yayBvZiByZWFkaW5nIG9yIG1vZGlmeWluZyB0aGUgb2JqZWN0IGFuZCBvZiBvYmV5aW5n IHRoZSBydWxlcy4gIFRvIG1lDQo+IHRoYXQNCj4gbWVhbnMgdGhhdCBpdCBjYW4ndCBiZSB1c2Vk IGluIHRoaXMgd2F5IGxvb3NlbHktLWp1c3QgaW1wbGVtZW50aW5nIHRoaXMNCj4gc3RyYXdtYW4N Cj4gYW5kIGNhbGxpbmcgaXQgYSB1c2luZyBwcm90b2NvbCB3b3VsZCBiZSB1dHRlcmx5IGJvZ3Vz LCBzaW5jZSBvbmNlIGl0DQo+IGFycml2ZXMNCj4gYXQgdGhlIGNsaWVudCwgeW91IGhhdmVuJ3Qg c2FpZCB3aGF0IHRvIGRvIHdpdGggaXQgYWxsIG9yIGhvdyB0aGUgZ2VvcHJpdg0KPiByZXF1aXJl bWVudHMgYXJlIG1ldC4gIEJ1dCBJIHRoaW5rIGl0ICptaWdodCogYmUgdmFsaWQgaW4gdmVyeSBz cGVjaWZpYw0KPiBwcm90b2NvbA0KPiBjb250ZXh0cyB3aGVyZSB5b3UgaGF2ZSBzYWlkIHdoYXQg aGFwcGVucyB3aGVuIHRoZSAqdXNpbmcgcHJvdG9jb2wqDQo+IChTSVAsIGluIHRoaXMgZXhhbXBs ZSkgZG9lcyBmcm9tIHRoZXJlLg0KPiANCj4gSXQgbWF5IGJlLCBvZiBjb3Vyc2UsIHRoYXQgSSB3 YXMgdGhpbmtpbmcgdG8gaGFyZCBhbmQgbmVlZCB0byB0YWtlIGEgYml0DQo+IG9mDQo+IGEgbGll IGRvd24gdG8gcmVjb3Zlci4gIEJ1dCBJIHRob3VnaHQgYWJvdXQgdGhlIFVSSSBzY2hlbWVzIHdo aWNoIGVuY29kZQ0KPiBkYXRhIGluIHRoZSBVUkkgaXRzZWxmLCBhbmQgSSB0aG91Z2h0OiAgaG93 IGNhbiB0aG9zZSBiZSB1c2luZyBwcm90b2NvbHM/DQo+IE9idmlvdXNseSwgdGhleSBhcmVuJ3Q7 IHRoZXkncmUganVzdCB3YXlzIG9mIGNhcnJ5aW5nIHRoZSBkYXRhIGFyb3VuZCBmb3INCj4gdGhl IGJlbmVmaXQgb2YgcmVhbCB1c2luZyBwcm90b2NvbHMuICBJZiB0aGF0IGlzIHRoZSBjYXNlLCB3 ZSBtYXkgYmUgYWJsZQ0KPiB0byBkbyBzb21ldGhpbmcgc2ltcGxlIHRvIHNwZWNpZnkgaG93IHRv IHVzZSBhIHN1aXRhYmx5IHByb3RlY3RlZA0KPiB0cmFuc3BvcnQNCj4gdG8gZGVyZWZlcmVuY2Ug YSBVUkkgcmF0aGVyIHRoYW4gY2FycnlpbmcgdGhlIGRhdGEgaW5zaWRlIHRoZSB1c2luZw0KPiBw cm90b2NvbC4NCj4gQnV0IEkgdGhpbmsgdGhhdCB0aGlzIGZ1bmRhbWVudGFsbHkgcmVxdWlyZXMg dGhhdCB0aGUNCj4gdHJhbnNwb3J0L2RlcmVmZXJlbmNlDQo+IG9jY3VyIGluIGEgdmVyeSBib3Vu ZGVkIHByb3RvY29sIGNvbnRleHQgaW5zaWRlIHRoZSByZWFsIHVzaW5nIHByb3RvY29sLg0KPiBP dGhlcndpc2UsIHlvdSBhcmUgYWJzb2x1dGVseSByaWdodCB0aGF0IGl0IGlzIGp1c3QgYW4gZW5k LXJ1bi4NCj4gDQo+IFRvIHJlLWl0ZXJhdGU6ICB0aGlzIGEgc3RyYXdtYW47IGZlZWwgZnJlZSB0 byByaXAgdXAgdGhlIGlubmFyZHMgYW5kIHVzZQ0KPiBhcw0KPiBhIHBpbGxvdywgZmxhbW1hYmxl IG1hdGVyaWFscywgb3IgdXNlIGFzIHlvdSBzZWUgZml0LiAgSSB3b24ndCBiZSBvZmZlbmRlZA0K PiBpZg0KPiB0aGUgcmVzcG9uc2UgaXMgYW55IG9mIHRoZSBhYm92ZS4NCj4gCQkJcmVnYXJkcywN Cj4gCQkJCVRlZA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9y IHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdl ZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQpp bW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNl IG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClttZjJd --===============0789515576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0789515576==-- From sip-bounces@ietf.org Fri Jul 28 03:38:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6MtN-00053m-P2; Fri, 28 Jul 2006 03:36:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6MtL-00053g-OB for sip@ietf.org; Fri, 28 Jul 2006 03:36:15 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6MtK-0006df-Ak for sip@ietf.org; Fri, 28 Jul 2006 03:36:15 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6S7a9ro018739; Fri, 28 Jul 2006 10:36:10 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 10:35:58 +0300 Received: from esdhcp0358.research.nokia.com ([172.21.35.8]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Jul 2006 10:35:59 +0300 From: Aki Niemi To: "ext Vijay K. Gurbani" In-Reply-To: <44BEB632.9020006@lucent.com> References: <3ACC9A25264A684F82C71840111F979801EC5E54@carrera.eu.tieto.com> <44BE3426.3050502@alcatel.fr> <44BEB632.9020006@lucent.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Fri, 28 Jul 2006 10:35:52 +0300 Message-Id: <1154072153.21805.13.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2006 07:35:59.0273 (UTC) FILETIME=[783B0190:01C6B218] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org, Milan.Kunc@tietoenator.com Subject: [Sip] Re: [Simple] UDP - what if response is bigger than 1500 bytes (ethernet MTU)? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On ke, 2006-07-19 at 17:46 -0500, ext Vijay K. Gurbani wrote: > This remains a problem; I have had a quick chat with Scott > Lawrence on it and we'll be submitting a draft latter part > of next week on one way to deal with this. I'm curious, can that draft really suggest anything other than simply "MUST NOT use UDP"? Cheers, Aki -- Aki Niemi Nokia Research Center _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 28 04:04:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6NIc-0003Z4-G8; Fri, 28 Jul 2006 04:02:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6NIZ-0003Yu-Ti for sip@ietf.org; Fri, 28 Jul 2006 04:02:21 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6NIY-0007mr-Gv for sip@ietf.org; Fri, 28 Jul 2006 04:02:19 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6S82Dc02238 for ; Fri, 28 Jul 2006 04:02:13 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jul 2006 03:02:11 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D81CC8C@zrc2hxm2.corp.nortel.com> In-Reply-To: <1154072153.21805.13.camel@macbuster.research.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Over UDP thread-index: AcayGJcNlHshGJoCRyuWXiHGFZOerwAAjGWA From: "Samir Srivastava" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] SIP Over UDP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have been earlier proposing to deprecate the SIP over UDP and there have been arguments about the large SDP etc. It will be useful for Page Mode IM, where we will be sending short IM. Hence we might need DTLS too. Should we still deprecate it.. Rajnish was arguing that one can cut and paste long text in the body too. If it is so, then client can use TCP or TLS based on the size. Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 28 05:15:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6OPU-0000An-Vl; Fri, 28 Jul 2006 05:13:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6OPT-0000Ai-VA for sip@ietf.org; Fri, 28 Jul 2006 05:13:31 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6OPS-0002pt-Jh for sip@ietf.org; Fri, 28 Jul 2006 05:13:31 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 33B7720A0D5; Fri, 28 Jul 2006 09:13:25 +0000 (UTC) Message-Id: <7.0.1.0.0.20060728110423.04f7b190@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 28 Jul 2006 11:13:27 +0200 To: Jonathan Rosenberg , Paul Kyzivat From: Jiri Kuthan Subject: Re: [Sip] Re: draft-ietf-sip-gruu-09 In-Reply-To: <44C98135.70705@cisco.com> References: <720BC7A4-8BFF-412E-A6BC-FAC41FA1289B@cisco.com> <44C83461.4020806@cisco.com> <44C8BC2F.1000406@cisco.com> <44C98135.70705@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Cullen Jennings , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 05:15 28/07/2006, Jonathan Rosenberg wrote: > If the proxy is halfway intelligent in construction of record-routes, it'll use random numbers, hashes, and otherwise proprietary > techniques to construct the URI. The odds are pretty good that the UA would not be able to construct a Route URI that the proxy > would recognize as one that it would have inserted into a Record-Route. Well, in terms of interesting list discussion: I think this can be actually used to replace the hostname-based "is it myself" test in processing route header fields. That appears to me more robust because it removes ambiguities around multiple IP addresses, many names in hosted environments, having to configure all of that, failover scenarios with backup having different IP from primary servers, etc. >Now, a request that contains a tag not matching any dialog at the UAS is rejected anyway. However, you might be able to work with a cooperating UAS to make something useful happen. For example if a proxy is generating call start and stop records based on *initial* INVITE and BYE, respectively, cooperating UA might be able to get free calls. > >>Suppose Alice is permitted to call Bob, but not to subscribe to the reg event package. So Alice first calls Bob, and notes the Record-Route that results. Then in a separate dialog, Alice sends a SUBSCRIBE to the reg event package, including a Route header with a URI of Bob's home proxy extracted from the old R-R. > >If the RR is constructed using hashes of the tags this won't work. > >>Seems like this strategy also requires some protection against a "replay attack" like this. >>But that isn't really an issue for this draft. > >No; but it makes for interesting list discussion ;) :) Replay attack protection is not easy for protocols which rely on notion of piggy-backing without any more support from client than just mirroring a value from server. We would have to touch the client to provide for message integrity. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 28 07:48:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Qno-0007mC-96; Fri, 28 Jul 2006 07:46:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Qnm-0007m7-IQ for sip@ietf.org; Fri, 28 Jul 2006 07:46:46 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Qnl-00026d-2n for sip@ietf.org; Fri, 28 Jul 2006 07:46:46 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6SAkeEg024303; Fri, 28 Jul 2006 13:46:44 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 14:46:18 +0300 Received: from esdhcp0358.research.nokia.com ([172.21.35.8]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Jul 2006 14:46:18 +0300 Subject: Re: [Sip] draft-niemi-sip-subnot-etags-00.txt From: Aki Niemi To: "ext Drage, Keith (Keith)" In-Reply-To: <475FF955A05DD411980D00508B6D5FB0127491CA@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0127491CA@en0033exch001u.uk.lucent.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Fri, 28 Jul 2006 14:46:12 +0300 Message-Id: <1154087172.31773.7.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2006 11:46:18.0673 (UTC) FILETIME=[707D9210:01C6B23B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I care. ;) Anyway, I have updated the draft with the comments received so far. I think it's starting to shape up, so please take a look: http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-01.txt Cheers, Aki On su, 2006-03-26 at 17:24 +0100, ext Drage, Keith (Keith) wrote: > (As chair) > > http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-00.txt makes a proposal for: > > " The Session Initiation Protocol (SIP) events framework enables > receiving asynchronous notification of events related to SIP > systems. > This framework defines the procedures for creating, refreshing and > terminating subscriptions, as well as fetching and periodic polling > of resource state. These procedures have a serious deficiency in > that they do not allow state to persist over a subscription > refresh, > or between two consecutive polls. Another related but different > problem relates to the relative intolerance of the framework to > interferences in networking connectivity of subscribers in long- > lasting subscriptions. This document explains the problems in more > detail and discusses possible solutions." > > This draft was discussed at the face-to-face meeting at IETF #65 but > without conclusion. > > We seek views on whether the SIP WG should adopt a draft in this area > as a charter item, and if so, what scope that charter item should > have. > > regards > > Keith > > Keith Drage > drage@lucent.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 28 13:49:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6WQj-0007vG-N3; Fri, 28 Jul 2006 13:47:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6WQi-0007v7-Df for sip@ietf.org; Fri, 28 Jul 2006 13:47:20 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6WQh-0000rH-5K for sip@ietf.org; Fri, 28 Jul 2006 13:47:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 28 Jul 2006 10:47:08 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,193,1151910000"; d="scan'208"; a="33741254:sNHT29884576" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6SHl7ad014130; Fri, 28 Jul 2006 13:47:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6SHl7dU029436; Fri, 28 Jul 2006 13:47:07 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 13:47:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Hitchhikers guide - when is it done? Date: Fri, 28 Jul 2006 13:47:05 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301BF8807@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Hitchhikers guide - when is it done? Thread-Index: AcaxzReraHE/ygPiTwidqqWgDGaPzQAoHrfg From: "Michael Hammer \(mhammer\)" To: "Vijay K. Gurbani" X-OriginalArrivalTime: 28 Jul 2006 17:47:07.0512 (UTC) FILETIME=[D8343F80:01C6B26D] DKIM-Signature: a=rsa-sha1; q=dns; l=1671; t=1154108827; x=1154972827; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20Hitchhikers=20guide=20-=20when=20is=20it=20done? |To:=22Vijay=20K.=20Gurbani=22=20; X=v=3Dcisco.com=3B=20h=3DMv7yj3PuEbZ8msTThY0bXHMVaJU=3D; b=J773HJ1Ri9LgLRkVGw3KF0/6Om+EawQx0tnpLtpe8czIWvqV3ZQINR6I9I4REf3PIWaZ4U/c TKoGyY9mhY3V17he0xoqJDfWppKabap6LuYkm27zQqs1aeyej97D8lVH; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I am anticipating that this needs to be maintained for quite some time and that each year something new would be needed. So, I don't believe the "2 at most" IMHO. Cheers, Mike =20 > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com]=20 > Sent: Thursday, July 27, 2006 6:36 PM > To: Michael Hammer (mhammer) > Cc: Jonathan Rosenberg (jdrosen); IETF SIP List > Subject: Re: [Sip] Hitchhikers guide - when is it done? >=20 > Michael Hammer (mhammer) wrote: > > Then we will need an RFC to point to the index RFCs that=20 > point to the=20 > > base RFCs? >=20 > Nah, it's not as bad as that. We are talking about 2 RFCs at=20 > most, really. >=20 > > A single RFC pointing document would be best. >=20 > If we go the single RFC route, then that means obsoleting=20 > that RFC at least once, or maybe twice. Now, while you and I=20 > are adept at making our way through how IETF numbers their=20 > RFCs and what happens when one RFC is obsoleted, and so on=20 > ... I think the majority of the people using our=20 > specifications may not have this context. They grab an RFC=20 > -- obsolete or not -- and run with it. >=20 > To take this to the absurd, I am aware of products based on > *expired* I-Ds, not to mention obsolete RFCs! >=20 > In summary, my preference is for (1), with two RFCs produced=20 > at most. But, if the WG decides to go with (2), then that is fine... >=20 > Thanks, >=20 > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Bell Laboratories, Lucent Technologies, Inc. > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 28 15:21:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XrU-0006Dz-A2; Fri, 28 Jul 2006 15:19:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XrT-0006Dq-09; Fri, 28 Jul 2006 15:19:03 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6XrQ-00037v-M2; Fri, 28 Jul 2006 15:19:02 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6SJIuoW010769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2006 12:18:57 -0700 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6SJInIc014362; Fri, 28 Jul 2006 12:18:50 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 28 Jul 2006 12:18:27 -0700 To: Ted Hardie , "Dawson, Martin" , "Andrew Newton" , "IETF SIP List" , "GEOPRIV" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This does look to me to be a "using protocol". Presumably the HTTP server and the dereferencer have a relationship such that HTTP DIGEST can be used. Perhaps the DIGEST identity can be used when evaluating the policy rules. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- "press to test" "release to detonate" _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 28 18:03:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6aO8-0004nV-Mp; Fri, 28 Jul 2006 18:00:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6aO6-0004nB-Sf; Fri, 28 Jul 2006 18:00:54 -0400 Received: from jes-fe2.zx.nl ([194.187.76.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6aO4-0002hG-Bp; Fri, 28 Jul 2006 18:00:54 -0400 Received: from Inbox ([89.205.144.52]) by jes-fe2.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J3400JO3YSKLI40@jes-fe2.zx.nl>; Sat, 29 Jul 2006 00:05:25 +0100 (WEST) Date: Sat, 29 Jul 2006 00:01:26 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol To: Ted Hardie , "Dawson, Martin" , Andrew Newton , IETF SIP List , GEOPRIV Message-id: <0J3400JO4YSMLI40@jes-fe2.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Ted, At what scale do you expect this to work? If the location server is require= d to have a trust relation with everyone I might want to share my location = with, it won't work for the Internet.=20 For that, I think something like trait based authorization is needed: a URL= that encodes my consent for you to retrieve my location, for a limited per= iod Regards, Jeroen -Oorspronkelijk bericht ----- Van: "Ted Hardie" Aan: "Dawson, Martin" ; "Andrew Newton" ; "IETF SIP List" ; "GEOPRIV" Verzonden: 28-7-06 03:53 Onderwerp: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using proto= col Hi Martin, Having not seen your note, I already took a stab it, along much the same lines you suggest. Clearly, the attached -00 (not yet in the drafts directories) is the barest of bare bones, but I thought it might be useful to sketch that out as a contrast to some of the real applications which might use HTTP as a using protocol. I believe this also differs from RELO in that it is focused on the transport of PIDF-LO, which is slightly different from RELO's remit. But clearly, there are strong connections there. And if the phrase "strawman" in the title doesn't signal that I don't think this is a done piece of work, allow this too. regards, Ted Hardie At 7:50 PM -0500 7/27/06, Dawson, Martin wrote: >Hi Andy, > >I'll take a stab at it. Not that HTTP is a valid *using protocol* but, >rather, that the location reference does not actually identify a using >protocol and, in fact, HTTP would only be the transport protocol... > >3693 states: > The "using protocol" is the protocol that uses (reads or modifies) > the Location Object. A protocol that just transports the LO as a > string of bits, without looking at them (like an IP storage protocol > could do), is not a using protocol, but only a transport protocol. > Nevertheless, the entity or protocol that caused the transport > protocol to move the LO is responsible for the appropriate > distribution, protection, usage, retention, and storage of the LO > based on the rules that apply to that LO. > >A location reference which provided an HTTP URI indicates that the >entity that is going to be used to request the LO is to be communicated >with using HTTP. Because of the rules associated with the PIDF-LO, it >can be inferred that the entity and whatever semantics are associated >with the HTTP communications with that entity will honor the >requirements. That is, HTTP is only the transport protocol. An HTTP GET >has to be interpreted by the receiving entity within the scope of a >using protocol - with its associated set of rules and semantics - which >go beyond HTTP and which do respect the geopriv requirements. Indeed, >this is generally the case - sending an HTTP GET to an arbitrary IP node >can yield any number of results depending what that node actually does. >The client needs to understand the purpose of that server in the scope >of some higher level protocol. > >To use another example, a location reference could be an IP address. >There's nothing inherent in IP that honors the geopriv rules, but that >doesn't stop the reference being valid nor say that the protocol used >between a client and that IP address would not honor the rules. > >The purpose of the SIP conveyance specification is to say how a LO or >reference can be transferred from one entity to another using SIP. It's >out of scope for a SIP specification to mandate anything about the >transport protocol or to infer anything about using protocol implied by >that transport. As has been previously mentioned, this would be subject >to separate specification and BCP - lest the SIP conveyance >specification become overly rigid and subject to unnecessary maintenance >and churn. > >Cheers, >Martin > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Thursday, 27 July 2006 10:45 PM >> To: IETF SIP List; GEOPRIV >> Subject: [Geopriv] teasing apart: http as a GEOPRIV using protocol >> >> There have been a number of opinions regarding HTTP as a using >protocol. >> >> I'd like to know, how many people believe that HTTP requires no or >> very little specification to meet the requirements in RFC 3693 and >> RFC 3694. If you believe this, what basis do you have for this >> conclusion? Or do you believe more specification needs to be done, >> but it is possible for HTTP to be a GEOPRIV using protocol? > > >> Finally, how many people believe that HTTP should not be a using >> protocol? >> >> -andy >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > >--------------------------------------------------------------------------= ---------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information.=20 >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >--------------------------------------------------------------------------= ---------------------- >[mf2] > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 29 06:42:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6mFA-0001lz-7J; Sat, 29 Jul 2006 06:40:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6mF8-0001lr-74; Sat, 29 Jul 2006 06:40:26 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6mF7-0002eP-Qb; Sat, 29 Jul 2006 06:40:26 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Jul 2006 05:40:23 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sat, 29 Jul 2006 05:40:23 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Jul 2006 05:40:22 -0500 Message-ID: From: "Winterbottom, James" To: "Jeroen Van Bemmel" , "Ted Hardie" , "Dawson, Martin" , "Andrew Newton" , "IETF SIP List" , "GEOPRIV" Date: Sat, 29 Jul 2006 05:40:21 -0500 Subject: RE: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV usingprotocol MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 29 Jul 2006 10:40:22.0410 (UTC) FILETIME=[64C97EA0:01C6B2FB] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 References: <0J3400JO4YSMLI40@jes-fe2.zx.nl> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV usingprotocol Thread-Index: AcaykVBMSdqIp7bES5erT9I0FORgOwAaU+k4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Isn't the limited concent component covered by common policy in the form of= a rule validity period? =20 ________________________________ From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Fri 28/07/2006 5:01 PM To: Ted Hardie; Dawson, Martin; Andrew Newton; IETF SIP List; GEOPRIV Subject: RE: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV usingprot= ocol Hi Ted, At what scale do you expect this to work? If the location server is require= d to have a trust relation with everyone I might want to share my location = with, it won't work for the Internet. For that, I think something like trait based authorization is needed: a URL= that encodes my consent for you to retrieve my location, for a limited per= iod Regards, Jeroen -Oorspronkelijk bericht ----- Van: "Ted Hardie" Aan: "Dawson, Martin" ; "Andrew Newton" ; "IETF SIP List" ; "GEOPRIV" Verzonden: 28-7-06 03:53 Onderwerp: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using proto= col Hi Martin, Having not seen your note, I already took a stab it, along much the same lines you suggest. Clearly, the attached -00 (not yet in the drafts directories) is the barest of bare bones, but I thought it might be useful to sketch that out as a contrast to some of the real applications which might use HTTP as a using protocol. I believe this also differs from RELO in that it is focused on the transport of PIDF-LO, which is slightly different from RELO's remit. But clearly, there are strong connections there. And if the phrase "strawman" in the title doesn't signal that I don't think this is a done piece of work, allow this too. regards, Ted Hardie At 7:50 PM -0500 7/27/06, Dawson, Martin wrote: >Hi Andy, > >I'll take a stab at it. Not that HTTP is a valid *using protocol* but, >rather, that the location reference does not actually identify a using >protocol and, in fact, HTTP would only be the transport protocol... > >3693 states: > The "using protocol" is the protocol that uses (reads or modifies) > the Location Object. A protocol that just transports the LO as a > string of bits, without looking at them (like an IP storage protocol > could do), is not a using protocol, but only a transport protocol. > Nevertheless, the entity or protocol that caused the transport > protocol to move the LO is responsible for the appropriate > distribution, protection, usage, retention, and storage of the LO > based on the rules that apply to that LO. > >A location reference which provided an HTTP URI indicates that the >entity that is going to be used to request the LO is to be communicated >with using HTTP. Because of the rules associated with the PIDF-LO, it >can be inferred that the entity and whatever semantics are associated >with the HTTP communications with that entity will honor the >requirements. That is, HTTP is only the transport protocol. An HTTP GET >has to be interpreted by the receiving entity within the scope of a >using protocol - with its associated set of rules and semantics - which >go beyond HTTP and which do respect the geopriv requirements. Indeed, >this is generally the case - sending an HTTP GET to an arbitrary IP node >can yield any number of results depending what that node actually does. >The client needs to understand the purpose of that server in the scope >of some higher level protocol. > >To use another example, a location reference could be an IP address. >There's nothing inherent in IP that honors the geopriv rules, but that >doesn't stop the reference being valid nor say that the protocol used >between a client and that IP address would not honor the rules. > >The purpose of the SIP conveyance specification is to say how a LO or >reference can be transferred from one entity to another using SIP. It's >out of scope for a SIP specification to mandate anything about the >transport protocol or to infer anything about using protocol implied by >that transport. As has been previously mentioned, this would be subject >to separate specification and BCP - lest the SIP conveyance >specification become overly rigid and subject to unnecessary maintenance >and churn. > >Cheers, >Martin > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Thursday, 27 July 2006 10:45 PM >> To: IETF SIP List; GEOPRIV >> Subject: [Geopriv] teasing apart: http as a GEOPRIV using protocol >> >> There have been a number of opinions regarding HTTP as a using >protocol. >> >> I'd like to know, how many people believe that HTTP requires no or >> very little specification to meet the requirements in RFC 3693 and >> RFC 3694. If you believe this, what basis do you have for this >> conclusion? Or do you believe more specification needs to be done, >> but it is possible for HTTP to be a GEOPRIV using protocol? > > >> Finally, how many people believe that HTTP should not be a using >> protocol? >> >> -andy >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > >--------------------------------------------------------------------------= ---------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >--------------------------------------------------------------------------= ---------------------- >[mf2] > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 29 10:23:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6phA-0001y9-5U; Sat, 29 Jul 2006 10:21:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ph8-0001xp-O5; Sat, 29 Jul 2006 10:21:34 -0400 Received: from jes-fe2.zx.nl ([194.187.76.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6ph7-0002nU-BO; Sat, 29 Jul 2006 10:21:34 -0400 Received: from Inbox ([89.205.150.155]) by jes-fe2.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J3600IZP86XLL00@jes-fe2.zx.nl>; Sat, 29 Jul 2006 16:26:01 +0100 (WEST) Date: Sat, 29 Jul 2006 16:22:05 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV usingprotocol To: "Winterbottom, James" , Ted Hardie , "Dawson, Martin" , Andrew Newton , IETF SIP List , GEOPRIV Message-id: <0J3600IZQ86ZLL00@jes-fe2.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Could be, but that would mean the UA is forced to "publish" a location obje= ct to a server each time it wants to convey it By putting the expiration time in the URL, it can reuse the same object eac= h time, offering a different "view" on it to each conveyee. When the locati= on is constant or one of a set of common places (for example, "at home"), t= his can be more convenient The UA could even encrypt its actual location in the URL, and have the serv= er generate a PIDF-LO with that data. Then you have a snapshot by reference= , without being concerned about state on the server, but with additional ac= cess control possibilities Regards, Jeroen -----Oorspronkelijk bericht ----- Van: "Winterbottom, James" Aan: "Jeroen Van Bemmel" ; "Ted Hardie" ; "Dawson, Martin" ; "Andrew Newton" ; "IETF SIP List" ; "GEOPRIV" Verzonden: 29-7-06 12:40 Onderwerp: RE: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV usingpr= otocol Isn't the limited concent component covered by common policy in the form of= a rule validity period? =20 ________________________________ From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Fri 28/07/2006 5:01 PM To: Ted Hardie; Dawson, Martin; Andrew Newton; IETF SIP List; GEOPRIV Subject: RE: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV usingprot= ocol Hi Ted, At what scale do you expect this to work? If the location server is require= d to have a trust relation with everyone I might want to share my location = with, it won't work for the Internet. For that, I think something like trait based authorization is needed: a URL= that encodes my consent for you to retrieve my location, for a limited per= iod Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 29 11:25:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6qfM-0000Q4-2Q; Sat, 29 Jul 2006 11:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6qfK-0000M1-4l for sip@ietf.org; Sat, 29 Jul 2006 11:23:46 -0400 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6qfI-0003rN-KN for sip@ietf.org; Sat, 29 Jul 2006 11:23:46 -0400 Received: from dimension.cornfed.com (pool-141-157-85-154.balt.east.verizon.net [141.157.85.154]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k6TFNeh25404; Sat, 29 Jul 2006 10:23:40 -0500 Subject: RE: [Sip] SIP Security mechanism? From: "Frank W. Miller" To: "Fries, Steffen" In-Reply-To: References: Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Sat, 29 Jul 2006 11:23:37 -0400 Message-Id: <1154186617.2521.20.camel@dimension.cornfed.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: Cullen Jennings , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Actually, I don't think TLS would be required and I don't think you need to trust the proxies anymore than you do now. Diffie-Hellman (if I understand it correctly, which is not a certainty) essentially causes the endpoints to dynamically generate public keys that have corresponding private keys. The receiver sends the public key to the sender to be used for encryption and uses the private key for decryption. This mechanism would allow for the public keys to be passed in the clear in the initial exchange and that means it could be used with any type of transport. The proposal has weaknesses (i.e. difficulties with authentication, MitM attacks), but it does allow for simple key exchange that doesn't require ANY infrastructure which should facilitate encryption of bodies if proxies are present and entire messages if the UAs are B2B. The proposal is focused mainly on the difficulties associated with key and certificate management that have been observed operationally. By eliminating that part of the process, perhaps encryption would become more pervasive, which would be a good thing IMHO. Thanks, FM On Wed, 2006-07-26 at 08:47 +0200, Fries, Steffen wrote: > Hi Frank, > > the method you are describing at least requires the usage of TLS to > protect the key exchange between Alice and Bob. Moreover, you do need > to trust the proxies in between, as they have access to the keys > (assumed you send the key from Alice to Bob in the SDP). You may combine > the SIP_CERTS approach with draft-ono-sipping-smime-keyreuse-01.txt to > have one S/MIME encryption based on certificates and use the key-reuse > for the rest of the session. But as I wrote last time, the draft > regarding key-usage has expired and I'm not sure if it will be updated. > > Ciao > Steffen > > > -----Original Message----- > > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > > Sent: Saturday, July 22, 2006 3:58 AM > > To: Cullen Jennings > > Cc: sip@ietf.org > > Subject: Re: [Sip] SIP Security mechanism? > > > > > > Thanks for the pointer. I have scanned this draft over. > > > > The goal of your draft is similar to what I'm targeting but > > slightly different. Please correct me if I am > > misunderstanding something. The draft (which is now > > draft-ietf-sip-certs-01 I believe) has the goal is to provide > > a way to make the distribution of certificates more automated > > by providing specific infrastructure that is based on simple > > user actions. The draft specifies publication and an event > > package that allows for notification to interested User > > Agents of certificates. > > > > The great benefit to this approach is its preservation of > > user authentication. > > > > My thought was much simpler. Let me drop in a quote from the > > ZRTP draft, draft-zimmermann-avt-zrtp-01.txt: > > > > ZRTP is key agreement protocol which performs Diffie-Hellman key > > exchange during call setup in-band in the Real-time Transport > > Protocol (RTP) [1] media stream which has been established > > using some > > other signaling protocol such as Session Initiation Protocol (SIP) > > [11]. This generates a shared secret which is then used > > to generate > > keys and salt for a Secure RTP (SRTP) [2] session. > > > > Although it uses > > a public key algorithm, it does not rely on a public key > > infrastructure (PKI). > > > > Were we to put in place some sort of simple transaction that > > did this key exchange before any other signaling, we could > > use the keys to do encryption of the message bodies (similar > > to what S/MIME is doing) without having to deal with PKI at > > all. Since the main problem with the use of S/MIME to date > > has been the certificate management, this approach is also > > targeting the problem that your draft is. > > > > However, there are a couple of differences. First, your > > draft approach preserves full S/MIME certificate based > > authentication, this approach would likely not do that, it > > would be to allow for encryption only. The ZRTP draft > > proposes prompting the user with a short authentication > > string for the media but I don't know if that would be useful > > for the signaling. Second, this approach would be much > > simpler, likely requiring only a couple of messages between > > the UA endpoints. It would not require the centralized > > server elements that would be necessary for the > > PUBLISH/SUBSCRIBE/NOTIFY components of your draft. > > > > Consider the messages used to do key exchange in ZRTP (again > > from the ZRTP draft): > > > > Alice Bob > > | | > > | Alice and Bob establish a media session.| > > | | > > | RTP | > > |<=======================================>| > > | | > > | Hello (ver,cid,hash,cipher,pkt,sas,Alice's ZID) F1 > > |---------------------------------------->| > > | HelloACK F2 | > > |<----------------------------------------| > > | Hello (ver,cid,hash,cipher,pkt,sas,Bob's ZID) F3 > > |<----------------------------------------| > > | HelloACK F4 | > > |---------------------------------------->| > > | | > > | Bob acts as the initiator | > > | | > > | Commit (Bob's ZID,hash,cipher,pkt,hvi) F5 > > |<----------------------------------------| > > | DHPart1 (pvr,rs1IDr,rs2IDr,sigsIDr,srtpsIDr,other_secretIDr) F6 > > |---------------------------------------->| > > | DHPart2 (pvi,rs1IDi,rs2IDi,sigsIDi,ssrtpIDi,other_secretIDi) F7 > > |<----------------------------------------| > > | | > > | Alice and Bob generate SRTP session key.| > > | | > > | SRTP begins | > > |<=======================================>| > > | | > > | Confirm1 (plaintext,sasflag,hmac) F8 | > > |---------------------------------------->| > > | Confirm2 (plaintext,sasflag,hmac) F9 | > > |<----------------------------------------| > > | Confirm2AK F10 | > > |---------------------------------------->| > > > > > > They are generating keys for each of media streams here, i.e. > > an inband message exchange is happening in each direction. > > Something like this could probably be simplified to just two > > messages for the signaling, something like: > > > > Bob Alice > > | HELLO | > > |------------------------------->| > > | 200 OK | > > |<-------------------------------| > > | | > > > > This example uses a new method I made up called HELLO but I > > suppose this could be folded into the INVITE transaction too, > > using a mechanism similar to the 407. The key that Alice is > > supposed to use to encrypt the bodies sent to Bob would be in > > the HELLO and the key that Bob is supposed to use encrypt the > > bodies sent to Alice would be in the 200 OK. > > > > Is this clearer? Does it make sense? Its simpler but the > > authentication may not be there. That works for the media > > because you can possibly recognize someone's voice. In the > > signaling the authentication thing may be a bigger issue. > > > > FM > > > > > > On Fri, 2006-07-21 at 00:17 -0700, Cullen Jennings wrote: > > > you might want to have a read of > > draft-ietf-sipping-certs-04 if your > > > goal is to make sure that users can find the keys of other > > users for > > > use with S/MIME > > > > > > On Jul 19, 2006, at 12:17 PM, fwmiller@cornfed.com wrote: > > > > > > > > > > > > > > > I've been reading about the ZRTP lately. I read > > Henning's comment > > > > at the IETF meeting about how S/MIME relies on the > > receiver's public > > > > key to be available to allow for encryption/decryption to work. > > > > > > > > Why couldnt we put in place a mechanism that did a key > > exchange for > > > > SIP signaling similar to whats done in ZRTP (i.e. modified Diffie- > > > > Hellman) prior to any signaling traffic, then use the > > exchanged keys > > > > as the basis for S/MIME encryption of the bodies? Or we > > could even > > > > get really carried away and use it to do encryption of the entire > > > > SIP message if the signaling did not traverse proxies? > > This could > > > > be useful for encrypting UDP signaling, again if no proxy were > > > > involved. > > > > > > > > Thoughts? > > > > FM > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use > > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > > sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 29 13:33:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6sfF-0004cw-FU; Sat, 29 Jul 2006 13:31:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6sfE-0004cm-P0 for sip@ietf.org; Sat, 29 Jul 2006 13:31:48 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6sfD-0008B6-As for sip@ietf.org; Sat, 29 Jul 2006 13:31:48 -0400 Received: (qmail invoked by alias); 29 Jul 2006 17:31:45 -0000 Received: from p54987724.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.119.36] by mail.gmx.net (mp023) with SMTP; 29 Jul 2006 19:31:45 +0200 X-Authenticated: #29516787 Message-ID: <44CB9B8C.504@gmx.net> Date: Sat, 29 Jul 2006 19:31:56 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Gellens Subject: Re: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Ted Hardie , "Dawson, Martin" , IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Randy, Maybe there is such a relationship. I do, however, suspect that in the typical case there isn't since this places the deployment bar quite high: Every location recipient (e.g., PSAP, SIP user agent, Location Server, etc.) needs to have a relationship (or even a shared secret) with the access network provider (L3 provider) since this is the place where the HTTP server needs to be located. The identity used for digest authentication can indeed be used in combination with the common policy rules. You just need to define how the digest identity and the digest realm part are matched with the content of the 'id' and the 'domain' part to the common policy rules. With the Pawn Ticket URLs the solution would, however, be simpler (as simple as with URLs with a randomly create and unguessable component): If you know the URI then you are allowed to retrieve the PIDF-LO. (This assumes that I understood the Pawn Ticket approach properly.) Ciao Hannes Randall Gellens wrote: > This does look to me to be a "using protocol". > > Presumably the HTTP server and the dereferencer have a relationship such > that HTTP DIGEST can be used. > > Perhaps the DIGEST identity can be used when evaluating the policy rules. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 29 13:53:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6syB-0007m8-JE; Sat, 29 Jul 2006 13:51:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6C43-0008PK-7A; Thu, 27 Jul 2006 16:02:35 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6C41-0003ZF-Py; Thu, 27 Jul 2006 16:02:35 -0400 Received: from ([90.152.53.181]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.152712813; Thu, 27 Jul 2006 16:01:59 -0400 Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010162.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 27 Jul 2006 15:02:00 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Thu, 27 Jul 2006 15:02:00 -0500 Message-ID: <9888E1AA13C3A1459D122996A58C0E1109A9BE60@bre2k61p-55> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Thread-Index: AcaxLFihyXDgVBw7RHyfxMcDbLGkgQAixSNw From: "Stark, Barbara" To: "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 27 Jul 2006 20:02:00.0824 (UTC) FILETIME=[85C7E780:01C6B1B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc X-Mailman-Approved-At: Sat, 29 Jul 2006 13:51:22 -0400 Cc: IETF SIP List , geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This gets my vote. Barbara > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, July 26, 2006 11:25 PM > To: Brian Rosen > Cc: IETF SIP List; geopriv@ietf.org > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to > location-conveyance >=20 >=20 > My suggestion would be >=20 > - to focus the draft on just defining the Location header syntax, =20 > without ruling out any particular mechanism or scheme; this would =20 > make the draft really short (which I would find helpful). >=20 > - and then add one section to the draft that prototypically defines =20 > what a particular scheme that wants to appear in the Location header =20 > needs to define, using the non-controversial cid mechanism as the =20 > example. Other, separate, drafts can then define other modes, =20 > following the same template. Documents such as the phone-bcp=20 > can then =20 > pick some suitable must-implement subset and make emergency-call-=20 > specific recommendations, rather than sprinkling these=20 > throughout the =20 > conveyance document and repeating some in the phone-bcp. Most of =20 > these are, in any event, operational recommendations, not for =20 > ensuring protocol-level interoperability. >=20 > That way, the conveyance draft can be extremely short (even shorter =20 > if the requirements are omitted...) and can get done, and we avoid =20 > engineering operational requirements on the fly, commingling =20 > emergency and non-emergency cases, as seems to be happening now. >=20 > I think protocol documents should define what's needed for =20 > interoperability; BCPs can make more specific, situation-specific =20 > recommendations. Commingling the two seems to be a recipe for =20 > deadlock or arbitrary, non-technically-grounded decisions that are =20 > more lawyer-like than engineering-like ("you did not mention =20 > technique X in some meeting N years ago and thus you can't bring it =20 > up now!") >=20 > Henning >=20 > On Jul 26, 2006, at 11:08 PM, Brian Rosen wrote: >=20 > > At this point, I think we need some chair guidance and by that I =20 > > think it's > > a combo of geopriv and sip chairs. > > > > We seem to have a couple of significant open questions. I think =20 > > most of the > > other stuff (like the "allow sending to router") will converge. > > > > There seems to be some opposition to allowing sip/sips/pres: in a =20 > > Location > > Header. The opposition seems to be that despite 4119, somehow, SIP > > (presence subscription) is not a "using protocol". I "think" a =20 > > ruling from > > the bench on that would work. > > > > There is also opposition to defining the allowed schemes as a =20 > > specific list, > > with a defined (easy) extension mechanism. > > > > Related to that, there are some who want location-conveyance to =20 > > define an > > HTTP based location dereference mechanism, and on the=20 > opposite end, =20 > > we have > > people saying we haven't even agreed to support any form of > > location-by-reference. > > > > The authors would like to know what to do now. > > > > Brian > > > >> -----Original Message----- > >> From: Andrew Newton [mailto:andy@hxr.us] > >> Sent: Wednesday, July 26, 2006 9:58 PM > >> To: Winterbottom, James > >> Cc: sip@ietf.org; geopriv@ietf.org; Abbott, Nadine B; Henning =20 > >> Schulzrinne > >> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- > >> conveyance > >> > >> > >> On Jul 26, 2006, at 9:43 PM, Winterbottom, James wrote: > >> > >>> Andy, > >>> > >>> RFC-4119 says "However, the usage of this location object=20 > format is > >>> not > >>> limited to presence-using protocols-- any protocol that can > >>> carry XML > >>> or MIME types can carry PIDF." > >>> > >>> It seems to me that restricting the allowed schema in what is =20 > >>> supposed > >>> to be a location conveyance specification is in opposition to this > >>> statement. > >> > >> Did somebody say that HTTP was a presence-using protocol? > >> > >> -andy > >> > >> ps. you can find my location with the following reference URIs: > >> > >> gopher://fatchance.hxr.us/you-still-have-a-gopher-client > >> news:alt.locations.people.secretly-being-watched > >> telnet://screen-scrapers.are.us/ > >> dns:cached-publicly-around-the-world.com?type=3DHOST > >> > >> > >> > >> _______________________________________________ > >> Geopriv mailing list > >> Geopriv@ietf.org > >> https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 162 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 29 14:40:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6tiJ-0001FQ-GA; Sat, 29 Jul 2006 14:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6tiI-0001FE-2N; Sat, 29 Jul 2006 14:39:02 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6tiF-00053B-Mh; Sat, 29 Jul 2006 14:39:02 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6TIcrLH011943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 29 Jul 2006 11:38:53 -0700 Received: from [192.168.1.13] (vpn-10-50-16-64.qualcomm.com [10.50.16.64]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6TIcnts015855; Sat, 29 Jul 2006 11:38:51 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44CB9B8C.504@gmx.net> References: <44CB9B8C.504@gmx.net> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Sat, 29 Jul 2006 11:36:01 -0700 To: Hannes Tschofenig From: Randall Gellens Subject: Re: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.6 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Ted Hardie , "Dawson, Martin" , IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 7:31 PM +0200 7/29/06, Hannes Tschofenig wrote: > Hi Randy, > > Maybe there is such a relationship. I do, however, suspect that in > the typical case there isn't since this places the deployment bar > quite high: Every location recipient (e.g., PSAP, SIP user agent, > Location Server, etc.) needs to have a relationship (or even a > shared secret) with the access network provider (L3 provider) since > this is the place where the HTTP server needs to be located. I agree. That's the question I was raising: my reading of the draft suggests that, since it relies on HTTP DIGEST, there must be a relationship in order for there to be credentials. > > The identity used for digest authentication can indeed be used in > combination with the common policy rules. You just need to define > how the digest identity and the digest realm part are matched with > the content of the 'id' and the 'domain' part to the common policy > rules. > > With the Pawn Ticket URLs the solution would, however, be simpler > (as simple as with URLs with a randomly create and unguessable > component): If you know the URI then you are allowed to retrieve > the PIDF-LO. > > (This assumes that I understood the Pawn Ticket approach properly.) > > Ciao > Hannes > > Randall Gellens wrote: >> This does look to me to be a "using protocol". >> >> Presumably the HTTP server and the dereferencer have a >> relationship such that HTTP DIGEST can be used. >> >> Perhaps the DIGEST identity can be used when evaluating the policy rules. > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Language is a virus from outer space. --William S. Burroughs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 29 15:30:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6uUh-0005oo-Ao; Sat, 29 Jul 2006 15:29:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6uUg-0005oJ-5q for sip@ietf.org; Sat, 29 Jul 2006 15:29:02 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6uUe-0002vA-Nd for sip@ietf.org; Sat, 29 Jul 2006 15:29:02 -0400 Received: (qmail invoked by alias); 29 Jul 2006 19:28:59 -0000 Received: from p54987724.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.119.36] by mail.gmx.net (mp034) with SMTP; 29 Jul 2006 21:28:59 +0200 X-Authenticated: #29516787 Message-ID: <44CBB706.6020307@gmx.net> Date: Sat, 29 Jul 2006 21:29:10 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Gellens Subject: Re: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol References: <44CB9B8C.504@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Ted Hardie , "Dawson, Martin" , IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It seems I misunderstood your comment. In this case I agree with your observation. Randall Gellens wrote: > At 7:31 PM +0200 7/29/06, Hannes Tschofenig wrote: > >> Hi Randy, >> >> Maybe there is such a relationship. I do, however, suspect that in >> the typical case there isn't since this places the deployment bar >> quite high: Every location recipient (e.g., PSAP, SIP user agent, >> Location Server, etc.) needs to have a relationship (or even a shared >> secret) with the access network provider (L3 provider) since this is >> the place where the HTTP server needs to be located. > > > I agree. That's the question I was raising: my reading of the draft > suggests that, since it relies on HTTP DIGEST, there must be a > relationship in order for there to be credentials. > >> >> The identity used for digest authentication can indeed be used in >> combination with the common policy rules. You just need to define how >> the digest identity and the digest realm part are matched with the >> content of the 'id' and the 'domain' part to the common policy rules. >> >> With the Pawn Ticket URLs the solution would, however, be simpler (as >> simple as with URLs with a randomly create and unguessable component): >> If you know the URI then you are allowed to retrieve the PIDF-LO. >> >> (This assumes that I understood the Pawn Ticket approach properly.) >> >> Ciao >> Hannes >> >> Randall Gellens wrote: >> >>> This does look to me to be a "using protocol". >>> >>> Presumably the HTTP server and the dereferencer have a relationship >>> such that HTTP DIGEST can be used. >>> >>> Perhaps the DIGEST identity can be used when evaluating the policy >>> rules. >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 29 18:32:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6xKI-0005QB-K4; Sat, 29 Jul 2006 18:30:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6xKH-0005Q3-0Z; Sat, 29 Jul 2006 18:30:29 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6xKE-0000IB-JF; Sat, 29 Jul 2006 18:30:28 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Jul 2006 17:30:24 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sat, 29 Jul 2006 17:30:23 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Jul 2006 17:30:22 -0500 Message-ID: From: "Winterbottom, James" To: "Jeroen Van Bemmel" , "Ted Hardie" , "Dawson, Martin" , "Andrew Newton" , "IETF SIP List" , "GEOPRIV" Date: Sat, 29 Jul 2006 17:30:22 -0500 Subject: RE: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV usingprotocol MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 29 Jul 2006 22:30:22.0266 (UTC) FILETIME=[9447A9A0:01C6B35E] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 References: <0J3600IZQ86ZLL00@jes-fe2.zx.nl> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV usingprotocol Thread-Index: AcazGkriV64vKP3TTKi2npZLcn6rZwAQtJn9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen, =20 I think you are coming from a slightly different premise to me. I am not of= the opinion that the Target always knows where it is, sure it can ask, but= there are circumstances where A) it is not capable of asking, B) doesn't w= ant to ask it is happy for certain other entities just to know when they as= k. I don't believe that in either of these cases that the UA has to publish= a PIDF-LO at all. =20 It simply tells a local server (the thing that the URI points to) not to re= lease the location information to anyone but but X, and only if X asks for = it within Y. The local server is able to determine location, and it is my v= iew that the server can generate a PIDF-LO using an unlinked pseudonym as t= he entity identifier, RFC-4119 gives us defaults for all other parts we nee= d. In this way I have the same URI for everbody, but I can restrict how lon= g it is valid for anyone person. =20 Cheers James ________________________________ From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Sat 29/07/2006 9:22 AM To: Winterbottom, James; Ted Hardie; Dawson, Martin; Andrew Newton; IETF SI= P List; GEOPRIV Subject: RE: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV usingprot= ocol Could be, but that would mean the UA is forced to "publish" a location obje= ct to a server each time it wants to convey it By putting the expiration time in the URL, it can reuse the same object eac= h time, offering a different "view" on it to each conveyee. When the locati= on is constant or one of a set of common places (for example, "at home"), t= his can be more convenient The UA could even encrypt its actual location in the URL, and have the serv= er generate a PIDF-LO with that data. Then you have a snapshot by reference= , without being concerned about state on the server, but with additional ac= cess control possibilities Regards, Jeroen -----Oorspronkelijk bericht ----- Van: "Winterbottom, James" Aan: "Jeroen Van Bemmel" ; "Ted Hardie" ; "Dawson, Martin" ; "Andrew Newton" ; "IETF SIP List" ; "GEOPRIV" Verzonden: 29-7-06 12:40 Onderwerp: RE: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV usingpr= otocol Isn't the limited concent component covered by common policy in the form of= a rule validity period? ________________________________ From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Fri 28/07/2006 5:01 PM To: Ted Hardie; Dawson, Martin; Andrew Newton; IETF SIP List; GEOPRIV Subject: RE: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV usingprot= ocol Hi Ted, At what scale do you expect this to work? If the location server is require= d to have a trust relation with everyone I might want to share my location = with, it won't work for the Internet. For that, I think something like trait based authorization is needed: a URL= that encodes my consent for you to retrieve my location, for a limited per= iod Regards, Jeroen ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 29 19:03:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6xo5-0002FF-5p; Sat, 29 Jul 2006 19:01:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6xo3-0002F5-GT for sip@ietf.org; Sat, 29 Jul 2006 19:01:15 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6xo2-00069b-2N for sip@ietf.org; Sat, 29 Jul 2006 19:01:15 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6TN1DfP016382 for ; Sun, 30 Jul 2006 01:01:13 +0200 From: frieda.vanparijs@alcatel.be To: sip@ietf.org Message-ID: Date: Sun, 30 Jul 2006 01:01:10 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/30/2006 01:01:12 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Sip] Frieda VANPARIJS/BE/ALCATEL is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I will be out of the office starting 29/07/2006 and will not return until 21/08/2006. I will respond to your message when I return. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 30 04:37:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G76m8-0004KH-Hn; Sun, 30 Jul 2006 04:35:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G76m7-0004Ie-39; Sun, 30 Jul 2006 04:35:51 -0400 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G76m5-0003XS-PG; Sun, 30 Jul 2006 04:35:51 -0400 Received: from Inbox ([89.205.131.65]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J370049WMFS0270@jes-fe1.zx.nl>; Sun, 30 Jul 2006 10:31:18 +0100 (WEST) Date: Sun, 30 Jul 2006 10:36:28 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance To: "Stark, Barbara" , Henning Schulzrinne , Brian Rosen Message-id: <0J370049XMFU0270@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: IETF SIP List , geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes,mine too, with one additional remark: the location based routing use ca= se should be removed It is a special case of a more general one: route to some party in area X. = This need not have anything to do with the caller's location, in fact for p= rivacy reasons it is better not. LBR is better handled using caller prefs/callee capabilities (eg define +ge= o.zip, not using PIDF at all for simplicity) Given the above, proxy removal of location and data URIs are less of an iss= ue Regards, Jeroen -----Oorspronkelijk bericht ----- Van: "Stark, Barbara" Aan: "Henning Schulzrinne" ; "Brian Rosen" CC: "IETF SIP List" ; geopriv@ietf.org Verzonden: 27-7-06 22:02 Onderwerp: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveya= nce This gets my vote. Barbara > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, July 26, 2006 11:25 PM > To: Brian Rosen > Cc: IETF SIP List; geopriv@ietf.org > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to > location-conveyance >=20 >=20 > My suggestion would be >=20 > - to focus the draft on just defining the Location header syntax, =20 > without ruling out any particular mechanism or scheme; this would =20 > make the draft really short (which I would find helpful). >=20 > - and then add one section to the draft that prototypically defines =20 > what a particular scheme that wants to appear in the Location header =20 > needs to define, using the non-controversial cid mechanism as the =20 > example. Other, separate, drafts can then define other modes, =20 > following the same template. Documents such as the phone-bcp=20 > can then =20 > pick some suitable must-implement subset and make emergency-call-=20 > specific recommendations, rather than sprinkling these=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 30 04:37:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G76m8-0004KH-Hn; Sun, 30 Jul 2006 04:35:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G76m7-0004Ie-39; Sun, 30 Jul 2006 04:35:51 -0400 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G76m5-0003XS-PG; Sun, 30 Jul 2006 04:35:51 -0400 Received: from Inbox ([89.205.131.65]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J370049WMFS0270@jes-fe1.zx.nl>; Sun, 30 Jul 2006 10:31:18 +0100 (WEST) Date: Sun, 30 Jul 2006 10:36:28 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance To: "Stark, Barbara" , Henning Schulzrinne , Brian Rosen Message-id: <0J370049XMFU0270@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: IETF SIP List , geopriv@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes,mine too, with one additional remark: the location based routing use ca= se should be removed It is a special case of a more general one: route to some party in area X. = This need not have anything to do with the caller's location, in fact for p= rivacy reasons it is better not. LBR is better handled using caller prefs/callee capabilities (eg define +ge= o.zip, not using PIDF at all for simplicity) Given the above, proxy removal of location and data URIs are less of an iss= ue Regards, Jeroen -----Oorspronkelijk bericht ----- Van: "Stark, Barbara" Aan: "Henning Schulzrinne" ; "Brian Rosen" CC: "IETF SIP List" ; geopriv@ietf.org Verzonden: 27-7-06 22:02 Onderwerp: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveya= nce This gets my vote. Barbara > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, July 26, 2006 11:25 PM > To: Brian Rosen > Cc: IETF SIP List; geopriv@ietf.org > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to > location-conveyance >=20 >=20 > My suggestion would be >=20 > - to focus the draft on just defining the Location header syntax, =20 > without ruling out any particular mechanism or scheme; this would =20 > make the draft really short (which I would find helpful). >=20 > - and then add one section to the draft that prototypically defines =20 > what a particular scheme that wants to appear in the Location header =20 > needs to define, using the non-controversial cid mechanism as the =20 > example. Other, separate, drafts can then define other modes, =20 > following the same template. Documents such as the phone-bcp=20 > can then =20 > pick some suitable must-implement subset and make emergency-call-=20 > specific recommendations, rather than sprinkling these=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 30 04:37:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G76mL-0004Mb-I1; Sun, 30 Jul 2006 04:36:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G76mJ-0004Ld-Od; Sun, 30 Jul 2006 04:36:03 -0400 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G76mI-0003Xj-Fl; Sun, 30 Jul 2006 04:36:03 -0400 Received: from Inbox ([89.205.131.65]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J370049WMFS0270@jes-fe1.zx.nl>; Sun, 30 Jul 2006 10:31:31 +0100 (WEST) Date: Sun, 30 Jul 2006 10:36:41 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV usingprotocol To: "Winterbottom, James" , Ted Hardie , "Dawson, Martin" , Andrew Newton , IETF SIP List , GEOPRIV Message-id: <0J370049ZMG80270@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James, =20 >It simply tells a local server (the thing that the URI points to) not to r= elease the location information to anyone but but X, and only if X asks for= it within Y. =20 (JvB) I was only talking about the benefits of encoding authorization and e= xpiry in the URL, and the same argument applies here: As you describe it, t= he UA will need (because of the 'within Y' part) to contact the server each= time it conveys its location. Encoding this in the URL can avoid that. It = can be used regardless whether the UA knows its location or not Regards, Jeroen= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 30 04:37:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.i etf.org with esmtp (Exim 4.43) id 1G76mL-0004Mb-I1; Sun, 30 Jul 2006 04:36:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G76mJ-0004Ld-Od; Sun, 30 Jul 2006 04:36:03 -0400 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G76mI-0003Xj-Fl; Sun, 30 Jul 2006 04:36:03 -0400 Received: from Inbox ([89.205.131.65]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J370049WMFS0270@jes-fe1.zx.nl>; Sun, 30 Jul 2006 10:31:31 +0100 (WEST) Date: Sun, 30 Jul 2006 10:36:41 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV usingprotocol To: "Winterbottom, James" , Ted Hardie , "Dawson, Martin" , Andrew Newton , IETF SIP List , GEOPRIV Message-id: <0J370049ZMG80270@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James, =20 >It simply tells a local server (the thing that the URI points to) not to r= elease the location information to anyone but but X, and only if X asks for= it within Y. =20 (JvB) I was only talking about the benefits of encoding authorization and e= xpiry in the URL, and the same argument applies here: As you describe it, t= he UA will need (because of the 'within Y' part) to contact the server each= time it conveys its location. Encoding this in the URL can avoid that. It = can be used regardless whether the UA knows its location or not Regards, Jeroen= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 30 09:03:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Avd-0001IK-5v; Sun, 30 Jul 2006 09:01:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Ava-0001Hx-Ae; Sun, 30 Jul 2006 09:01:54 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7AvZ-00013R-3o; Sun, 30 Jul 2006 09:01:54 -0400 Received: from [192.168.0.41] (pool-141-153-188-67.mad.east.verizon.net [141.153.188.67]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6UD1XMp016460 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 30 Jul 2006 09:01:34 -0400 (EDT) In-Reply-To: <0J370049XMFU0270@jes-fe1.zx.nl> References: <0J370049XMFU0270@jes-fe1.zx.nl> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Sun, 30 Jul 2006 09:01:24 -0400 To: Jeroen Van Bemmel X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.30.54433 X-PerlMx-Spam: Gauge=XXII, Probability=22%, Report='RELAY_IN_NJABL_DYNABLOCK 2.5, RCVD_IN_NJABL_ORG 0, RELAY_IN_NJABL_ORG 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RELAY_IN_NJABL_DYNABLOCK 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > LBR is better handled using caller prefs/callee capabilities (eg > define +geo.zip, not using PIDF at all for simplicity) > This is completely new suggestion; emergency calling is nothing but a special case of location-based routing. I agree that it is useful to separate location information for routing from that shown to end systems, as they often have different resolution needs. (To route to the right branch of your pizza delivery franchiser, you may only need a zip code, but for delivery, you need the full street address. The practical problem is that such boundaries don't always agree with zip codes or any other higher-level geographic unit, such as state, county or town.) Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 30 10:53:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7CdB-0002Cy-B5; Sun, 30 Jul 2006 10:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Cd9-0002Cg-OF for sip@ietf.org; Sun, 30 Jul 2006 10:50:59 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Cd8-0005AT-B4 for sip@ietf.org; Sun, 30 Jul 2006 10:50:59 -0400 Received: (qmail 18238 invoked by uid 0); 30 Jul 2006 14:50:56 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 30 Jul 2006 14:50:56 -0000 Message-ID: <002101c6b3e7$8c14aba0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Henning Schulzrinne" References: <0J370049XMFU0270@jes-fe1.zx.nl> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Sun, 30 Jul 2006 16:50:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Henning, Yes, it was intended as a new angle. And you are right that 'zip' is probably not enough to cover all cases, my intention in providing the 'geo' feature tree as example was to suggest that GEOPRIV might define other feature parameters in this space ("country","state" etc are some obvious candidates, and "geo.lat" and "geo.lon" perhaps?) To me, the "emergency calling" use case should indeed be viewed as a scenario in which "location conveyance" and "location based routing" are combined. Regards, Jeroen ----- Original Message ----- From: "Henning Schulzrinne" To: "Jeroen Van Bemmel" Cc: "IETF SIP List" ; "GEOPRIV" Sent: Sunday, July 30, 2006 3:01 PM Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance >> LBR is better handled using caller prefs/callee capabilities (eg define >> +geo.zip, not using PIDF at all for simplicity) >> > > This is completely new suggestion; emergency calling is nothing but a > special case of location-based routing. I agree that it is useful to > separate location information for routing from that shown to end systems, > as they often have different resolution needs. (To route to the right > branch of your pizza delivery franchiser, you may only need a zip code, > but for delivery, you need the full street address. The practical problem > is that such boundaries don't always agree with zip codes or any other > higher-level geographic unit, such as state, county or town.) > > Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 30 13:47:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7FLg-0005A4-5d; Sun, 30 Jul 2006 13:45:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7FLe-00059C-Nf for sip@ietf.org; Sun, 30 Jul 2006 13:45:06 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7FLe-0000cc-9t for sip@ietf.org; Sun, 30 Jul 2006 13:45:06 -0400 Received: (qmail invoked by alias); 30 Jul 2006 17:45:05 -0000 Received: from p54986C35.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.108.53] by mail.gmx.net (mp021) with SMTP; 30 Jul 2006 19:45:05 +0200 X-Authenticated: #29516787 Message-ID: <44CCF02F.4020801@gmx.net> Date: Sun, 30 Jul 2006 19:45:19 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <0J370049XMFU0270@jes-fe1.zx.nl> <002101c6b3e7$8c14aba0$31713b51@BEMBUSTER> In-Reply-To: <002101c6b3e7$8c14aba0$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: IETF SIP List , GEOPRIV , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeroen, in past discussions we concluded that we don't want to have a special encoding for location-based routing. I agree with Henning that the level of granularity might, in some cases, be different depending on the consumer of the PIDF-LO. This is, however, more a location-based scenario rather than an emergency calling scenario. The problem is that the end host does not necessarily know the service boundary ahead of time and hence you don't know the required granularity of the location object. If you omit too many elements from the PIDF-LO then LoST might just return incorrect information. Ciao Hannes Jeroen van Bemmel wrote: > Hi Henning, > > Yes, it was intended as a new angle. And you are right that 'zip' is > probably not enough to cover all cases, my intention in providing the > 'geo' feature tree as example was to suggest that GEOPRIV might define > other feature parameters in this space ("country","state" etc are some > obvious candidates, and "geo.lat" and "geo.lon" perhaps?) > > To me, the "emergency calling" use case should indeed be viewed as a > scenario in which "location conveyance" and "location based routing" are > combined. > > Regards, > > Jeroen > > ----- Original Message ----- From: "Henning Schulzrinne" > > To: "Jeroen Van Bemmel" > Cc: "IETF SIP List" ; "GEOPRIV" > Sent: Sunday, July 30, 2006 3:01 PM > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to > location-conveyance > > >>> LBR is better handled using caller prefs/callee capabilities (eg >>> define +geo.zip, not using PIDF at all for simplicity) >>> >> >> This is completely new suggestion; emergency calling is nothing but a >> special case of location-based routing. I agree that it is useful to >> separate location information for routing from that shown to end >> systems, as they often have different resolution needs. (To route to >> the right branch of your pizza delivery franchiser, you may only need >> a zip code, but for delivery, you need the full street address. The >> practical problem is that such boundaries don't always agree with zip >> codes or any other higher-level geographic unit, such as state, >> county or town.) >> >> Henning > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 30 14:31:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7G2T-0001sD-3i; Sun, 30 Jul 2006 14:29:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7G2Q-0001s3-O4 for sip@ietf.org; Sun, 30 Jul 2006 14:29:18 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7G2P-0003lB-9x for sip@ietf.org; Sun, 30 Jul 2006 14:29:18 -0400 Received: (qmail 24939 invoked by uid 0); 30 Jul 2006 18:29:16 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 30 Jul 2006 18:29:16 -0000 Message-ID: <00e001c6b406$0bda09c0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Hannes Tschofenig" References: <0J370049XMFU0270@jes-fe1.zx.nl> <002101c6b3e7$8c14aba0$31713b51@BEMBUSTER> <44CCF02F.4020801@gmx.net> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Sun, 30 Jul 2006 20:29:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IETF SIP List , GEOPRIV , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hannes, see inline Regards, jeroen ----- Original Message ----- From: "Hannes Tschofenig" To: "Jeroen van Bemmel" Cc: "Henning Schulzrinne" ; "IETF SIP List" ; "GEOPRIV" Sent: Sunday, July 30, 2006 7:45 PM Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance > Hi Jeroen, > > in past discussions we concluded that we don't want to have a special > encoding for location-based routing. > I was not aware of any such conclusion. IMHO PIDF-LO is not the answer to all location-based problems, but before we delve into that discussion again - I was argueing that "location conveyance" and "location based routing" are separate cases. Do you agree with that? A simple illustrative example: suppose I will be going on holiday to Paris next week. I want to make a hotel reservation, and call some well-known chain of hotels. My location will be somewhere in Holland (at the moment of calling), and I want my call to go to their Paris office. How would this work with only 1 PIDF-LO? > I agree with Henning that the level of granularity might, in some cases, > be different depending on the consumer of the PIDF-LO. This is, however, > more a location-based scenario rather than an emergency calling scenario. > The problem is that the end host does not necessarily know the service > boundary ahead of time and hence you don't know the required granularity > of the location object. If you omit too many elements from the PIDF-LO > then LoST might just return incorrect information. OK, so perhaps the required granularity for matching would have to be specified as part of the callee-capabilities. Then an error would occur (eg the proxy would return '485 Ambiguous', with candidate contacts) when no locations match the given criteria. For specific cases (like Emergency) I imagine the required granularity would be defined, such that the UA would know in advance. I understand the desire to limit the number of different formats and encodings being used, but caller prefs / callee capabilities is more than a format - it is a specific, existing SIP mechanism that can address several useful scenarios. It has many benefits - for one, in this way LBR could be introduced for existing proxies (that support caller prefs). Regards, jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 30 14:50:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7GLL-00028G-HM; Sun, 30 Jul 2006 14:48:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7GLJ-000286-IW for sip@ietf.org; Sun, 30 Jul 2006 14:48:49 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7GLI-00058n-3e for sip@ietf.org; Sun, 30 Jul 2006 14:48:49 -0400 Received: (qmail invoked by alias); 30 Jul 2006 18:48:47 -0000 Received: from p54986C35.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.108.53] by mail.gmx.net (mp028) with SMTP; 30 Jul 2006 20:48:47 +0200 X-Authenticated: #29516787 Message-ID: <44CCFF1C.7090308@gmx.net> Date: Sun, 30 Jul 2006 20:49:00 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <0J370049XMFU0270@jes-fe1.zx.nl> <002101c6b3e7$8c14aba0$31713b51@BEMBUSTER> <44CCF02F.4020801@gmx.net> <00e001c6b406$0bda09c0$31713b51@BEMBUSTER> In-Reply-To: <00e001c6b406$0bda09c0$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: IETF SIP List , GEOPRIV , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeroen, Jeroen van Bemmel wrote: > Hi Hannes, > > see inline > > Regards, > > jeroen > > ----- Original Message ----- From: "Hannes Tschofenig" > > To: "Jeroen van Bemmel" > Cc: "Henning Schulzrinne" ; "IETF SIP List" > ; "GEOPRIV" > Sent: Sunday, July 30, 2006 7:45 PM > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to > location-conveyance > > >> Hi Jeroen, >> >> in past discussions we concluded that we don't want to have a special >> encoding for location-based routing. >> > > I was not aware of any such conclusion. IMHO PIDF-LO is not the answer > to all location-based problems, but before we delve into that discussion > again - I was argueing that "location conveyance" and "location based > routing" are separate cases. Do you agree with that? I agree with you in various ways. The use case is different, the security properties are different and the description in the draft needs to describe both cases. > > A simple illustrative example: suppose I will be going on holiday to > Paris next week. I want to make a hotel reservation, and call some > well-known chain of hotels. My location will be somewhere in Holland (at > the moment of calling), and I want my call to go to their Paris office. > How would this work with only 1 PIDF-LO? I guess the use cases most GEOPRIV/ECRIT folks have in mind is a bit different. From a protocol point of view there is, however, no difference. > >> I agree with Henning that the level of granularity might, in some >> cases, be different depending on the consumer of the PIDF-LO. This is, >> however, more a location-based scenario rather than an emergency >> calling scenario. The problem is that the end host does not >> necessarily know the service boundary ahead of time and hence you >> don't know the required granularity of the location object. If you >> omit too many elements from the PIDF-LO then LoST might just return >> incorrect information. > > > OK, so perhaps the required granularity for matching would have to be > specified as part of the callee-capabilities. Then an error would occur > (eg the proxy would return '485 Ambiguous', with candidate contacts) > when no locations match the given criteria. For specific cases (like > Emergency) I imagine the required granularity would be defined, such > that the UA would know in advance. I have no problem with two PIDF-LOs in a single message: One for routing and the other one for end host consumption. Would this solve your concerns already? For emergency services we know that you have to provide location information at a fine grain granularity. In recent discussions we argued about the need to include composite location with civic information at a floor level. > > I understand the desire to limit the number of different formats and > encodings being used, but caller prefs / callee capabilities is more > than a format - it is a specific, existing SIP mechanism that can > address several useful scenarios. It has many benefits - for one, in > this way LBR could be introduced for existing proxies (that support > caller prefs). I understood your previous comment as a request to specify a different location information format (not PIDF-LO) for location-based routing. Ciao Hannes > > Regards, > > jeroen > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 30 15:54:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7HKP-0008AX-3Z; Sun, 30 Jul 2006 15:51:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7HKN-00088i-V0 for sip@ietf.org; Sun, 30 Jul 2006 15:51:55 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7HKM-00049a-JD for sip@ietf.org; Sun, 30 Jul 2006 15:51:55 -0400 Received: (qmail 26076 invoked by uid 0); 30 Jul 2006 19:51:53 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 30 Jul 2006 19:51:53 -0000 Message-ID: <012201c6b411$96a642c0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Hannes Tschofenig" References: <0J370049XMFU0270@jes-fe1.zx.nl> <002101c6b3e7$8c14aba0$31713b51@BEMBUSTER> <44CCF02F.4020801@gmx.net> <00e001c6b406$0bda09c0$31713b51@BEMBUSTER> <44CCFF1C.7090308@gmx.net> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Sun, 30 Jul 2006 21:51:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: IETF SIP List , GEOPRIV , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > I understood your previous comment as a request to specify a different > location information format (not PIDF-LO) for location-based routing. That depends, I would be happy with a mapping of PIDF-LO onto callee capabilities / caller prefs. Would that be considered a different format? Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 09:18:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Xcb-0004kJ-8x; Mon, 31 Jul 2006 09:15:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Xca-0004k6-4H; Mon, 31 Jul 2006 09:15:48 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7XcY-0007JF-Qt; Mon, 31 Jul 2006 09:15:48 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G7XcN-0006ei-3f; Mon, 31 Jul 2006 08:15:36 -0500 From: "Brian Rosen" To: "'Jeroen van Bemmel'" , "'Hannes Tschofenig'" Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance Date: Mon, 31 Jul 2006 09:15:35 -0400 Message-ID: <03ea01c6b4a3$6add8850$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <012201c6b411$96a642c0$31713b51@BEMBUSTER> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca0EZvrlwvajKWZR+2lxZovf/VJmgAkRK5Q X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'IETF SIP List' , 'GEOPRIV' , 'Henning Schulzrinne' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We have spent a couple of YEARS working on this draft, it has always considers location based routing one of its uses, and at this point, I think this idea is not interesting. Does anyone else besides Jeroen support a different mechanism to convey location for routing than one for conveying location to the endpoint? I remind you that many (but not all) location based routing use cases DO involve conveyance of the location to an endpoint. The usual case we use for location based routing besides the emergency case is the pizza delivery scenario. You use location to route to the correct store, and the store gets your location to deliver the pizza. You don't ALWAYS want to do this, of course, but it is very common. At this point, we need fewer options (not only in the draft, in the SIP world), not more. Brian > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Sunday, July 30, 2006 3:52 PM > To: Hannes Tschofenig > Cc: IETF SIP List; GEOPRIV; Henning Schulzrinne > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location- > conveyance > > > I understood your previous comment as a request to specify a different > > location information format (not PIDF-LO) for location-based routing. > > That depends, I would be happy with a mapping of PIDF-LO onto callee > capabilities / caller prefs. Would that be considered a different format? > > Jeroen > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 09:32:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7XrP-0008WM-P7; Mon, 31 Jul 2006 09:31:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7XrN-0008V0-R0; Mon, 31 Jul 2006 09:31:05 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7XrM-0001Ub-K7; Mon, 31 Jul 2006 09:31:05 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Mon, 31 Jul 2006 09:31:12 -0400 id 015880EA.44CE0620.00002348 Message-ID: <44CE060B.6080806@hxr.us> Date: Mon, 31 Jul 2006 09:30:51 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance References: <03ea01c6b4a3$6add8850$640fa8c0@cis.neustar.com> In-Reply-To: <03ea01c6b4a3$6add8850$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: 'IETF SIP List' , 'GEOPRIV' , 'Henning Schulzrinne' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Rosen wrote: > At this point, we need fewer options (not only in the draft, in the SIP > world), not more. I agree. Not only do I not see a need for this, but such a suggestion this late in the game without any implementation, specification, or formalized use case is not helpful. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 11:10:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZNo-0002o2-T9; Mon, 31 Jul 2006 11:08:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZNn-0002nx-Rz for sip@ietf.org; Mon, 31 Jul 2006 11:08:39 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ZNm-0003Vf-Hx for sip@ietf.org; Mon, 31 Jul 2006 11:08:39 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 31 Jul 2006 08:08:38 -0700 X-IronPort-AV: i="4.07,199,1151910000"; d="scan'208"; a="1842947999:sNHT27301692" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6VF8bRR002425; Mon, 31 Jul 2006 08:08:37 -0700 Received: from [192.168.1.2] (sjc-vpn1-739.cisco.com [10.21.98.227]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6VF8bJi000453; Mon, 31 Jul 2006 08:08:37 -0700 (PDT) In-Reply-To: <02ef01c6a050$b49e9f40$a7c8000a@acmepacket.com> References: <02ef01c6a050$b49e9f40$a7c8000a@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Mon, 31 Jul 2006 08:08:39 -0700 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2033; t=1154358517; x=1155222517; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20rosenberg-sip-identity-coexistence; X=v=3Dcisco.com=3B=20h=3D3W76qn12oY3/kO35fx2svo0v6Rs=3D; b=ezVYFiFFpintLhPEzZKP1yk9vb8iXLwWOVKj0m13P0NzgSjuKETFPxQGVc9Z+cQ2ug/Ym5JP U10HjvhGy/P43oFWU7l78TRKKK/Fb7kjn3AO8p1kHdo3Lk+EprM0uDi5; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 5, 2006, at 9:33 AM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Sunday, July 02, 2006 1:02 PM >> >> On Jun 30, 2006, at 12:57 PM, Hadriel Kaplan wrote: >> >>> I agree with you, but it is used for detecting suspicious From >>> headers even >>> for non-anonymous calls. Obviously if the proxy inserting the PAI >>> _knows_ a >>>> From is spoofed, it could/should reject it. But if the proxy does >>>> _not_ >>> know whether the From is spoofed or not, it just doesn't insert the >>> PAI. >>> For example, ingress proxy receives a request from another domain - >>> if it >>> trusts the domain it passes the PAI (or inserts one). If it does >>> not trust >>> the domain, it removes PAI, but doesn't want to reject the request >>> (else it >>> wouldn't accept requests from such untrusted domains to begin with). >> >> I see your point, I can see how a proxy that is deciding not to >> remove a PAI might not know a From was spoofed. I don't see how a >> proxy that was going to *insert* a PAI would know what to put in the >> PAI and not be able to know if a PAI was spoofed. > > I'm not sure I follow - maybe you meant the word "From" instead of > "PAI" in > the "if a PAI was spoofed" bit? > I meant in the context of implicitly trusted connections. For > example: an > operator receiving a request from a directly-attached business > customer > proxy, where the operator's ingress proxy may insert a PAI of > bob@company.com based on the From, even though company.com's egress > proxy > did not insert the PAI itself. Obviously for an anonymous request the > ingress proxy would not know enough to put that URI in, and it's > certainly > the case that it can't be 100% sure that the request really came > from bob to > begin with (e.g., the company proxy could be hijacked, etc.). But > that > could be the case with Identity in use as well. > > -hadriel Oops - yes I meant From. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 11:39:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZqD-0001MK-4v; Mon, 31 Jul 2006 11:38:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZqA-0001M2-Vz; Mon, 31 Jul 2006 11:37:58 -0400 Received: from sipforum.org ([216.154.220.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Zq9-0005LA-Mr; Mon, 31 Jul 2006 11:37:58 -0400 Received: from [192.168.1.106] (c-24-63-84-148.hsd1.ma.comcast.net [24.63.84.148]) by sipforum.org (8.13.1/8.13.1) with ESMTP id k6VFa2h5019724; Mon, 31 Jul 2006 11:36:02 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <4362AB26-F7CA-44DF-BF45-293223612BA9@sipforum.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: fullmembers@sipforum.org, An open list for discussion of SIP-related topics , SIP Forum Tech WG , marketingwg@sipforum.org, sip@ietf.org, sipping@ietf.org From: Jay Batson Date: Mon, 31 Jul 2006 11:37:55 -0400 X-Mailer: Apple Mail (2.752.2) Received-SPF: softfail (sipforum.org: domain of transitioning batsonjay@sipforum.org does not designate 24.63.84.148 as permitted sender) receiver=sipforum.org; client-ip=24.63.84.148; helo=[192.168.1.106]; envelope-from=batsonjay@sipforum.org; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf2-1.0.0; X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Sip] SIP Forum Board of Director nominations open X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear SIP Forum member -- Five of eight current SIP Forum Board of Director (BoD) seats are expiring shortly. Elections for new Board members will be held at our annual meeting in September this year. (Watch for the formal meeting announcement that will be sent in mid-August.) Nominations are now open for new Directors. Any SIP Forum member (participating/free or full/paid) can be nominated to serve a two- year term. NOMINATIONS MUST BE RECEIVED WITHIN TWO WEEKS, on or before AUGUST 14, 2006. The requirements to be elected, the duties of Board members, and the process to make a nomination, are all described on the SIP Forum website here: http://www.sipforum.org/content/view/272/226/ . Note: You may nominate yourself. If you are passionate about the advancement of SIP, and please take a moment to nominate a passionate person who wants to help. Thank you. Cheers -jb ---------- Jay Batson Acting Managing Director, Chairman of the Board batsonjay@sipforum.org +1-978-824-0111 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 11:50:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7a0t-0003A6-63; Mon, 31 Jul 2006 11:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7a0s-00039l-E0; Mon, 31 Jul 2006 11:49:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Y90-0004BW-IY; Mon, 31 Jul 2006 09:49:18 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7Xyz-0007ti-N2; Mon, 31 Jul 2006 09:38:59 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns3.neustar.com (Postfix) with ESMTP id 7D121175DD; Mon, 31 Jul 2006 13:38:27 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 09:38:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jul 2006 09:38:25 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does Location-Conveyance have an HTTP dereference mechanism defined Thread-Index: Aca0pplgmsITWnO0QY2zuklnycrsOw== From: "Rosen, Brian" To: "IETF SIP List" X-OriginalArrivalTime: 31 Jul 2006 13:38:27.0115 (UTC) FILETIME=[9A3197B0:01C6B4A6] X-Spam-Score: -5.2 (-----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: GEOPRIV Subject: [Sip] Does Location-Conveyance have an HTTP dereference mechanism defined X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have lost track of where we stand on whether the only mentioned URI schemes in location-conveyance are sip/sips/pres. I "think" we have agreed that an HTTP/HTTPS dereference is in a separate document, but I'm not sure. This is NOT the discussion of what the ABNF of the location header looks like (although it would NOT have http/https in it for sure if we agree that an HTTP dereference protocol is a separate draft). If you think location-conveyance DOES have HTTP dereference text in it, please say so, and please explain why you would not be satisfied if there were a separate draft on the subject. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 14:04:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7c5m-0000vM-43; Mon, 31 Jul 2006 14:02:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7c5k-0000qb-MT for sip@ietf.org; Mon, 31 Jul 2006 14:02:12 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7c5i-0001ay-Ap for sip@ietf.org; Mon, 31 Jul 2006 14:02:12 -0400 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6VI4EFx023684 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 31 Jul 2006 13:04:14 -0500 In-Reply-To: <001c01c694f9$81039120$31713b51@BEMBUSTER> References: <44976078.6020408@cisco.com> <001c01c694f9$81039120$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Updated acr-code draft Date: Mon, 31 Jul 2006 13:02:06 -0500 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 21, 2006, at 1:11 AM, Jeroen van Bemmel wrote: > Jonathan, > > (Only) one comment: What about privacy service behavior? In > particular I am > thinking about a privacy service that anonymized the request, and > receives a > 433. > > If the privacy service is acting as a B2BUA, it should probably not > retry > the request "non-anonymously" (this could constitute a downgrade > attack). > This is also something worth mentioning in the security > considerations: the > retrying of the request SHOULD be based on an explicit decision by > the user > making the request, it SHOULD NOT be done automatically Any response on this before we move to last call? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 16:16:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7eAF-00070e-Q8; Mon, 31 Jul 2006 16:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7eAE-0006sl-1m for sip@ietf.org; Mon, 31 Jul 2006 16:14:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7eAB-0001EB-UN for sip@ietf.org; Mon, 31 Jul 2006 16:14:58 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 31 Jul 2006 13:14:56 -0700 X-IronPort-AV: i="4.07,199,1151910000"; d="scan'208"; a="308895200:sNHT32891706" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6VKEt45027750 for ; Mon, 31 Jul 2006 13:14:55 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6VKEsmQ002982 for ; Mon, 31 Jul 2006 13:14:54 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 16:14:54 -0400 Received: from [161.44.52.163] ([161.44.52.163]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 16:14:53 -0400 Message-ID: <44CE64BD.8010807@cisco.com> Date: Mon, 31 Jul 2006 16:14:53 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat References: <44C92DF3.9000602@cisco.com> In-Reply-To: <44C92DF3.9000602@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2006 20:14:53.0863 (UTC) FILETIME=[FC334B70:01C6B4DD] DKIM-Signature: a=rsa-sha1; q=dns; l=20338; t=1154376895; x=1155240895; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20Review=20of=20draft-ietf-sip-gruu-09; X=v=3Dcisco.com=3B=20h=3DBqPi8aBd1zCbsW6Z0/mu0ZLWPJM=3D; b=JVfK61hUnX1iWlV+73n+0aHMVb8uqI/mP+83kGm0GHjzby4+zHv4DXH1lgHiYEpRlDVGK6zX xnhrp8vE5VfamEzS8NAMXc+cg5S+oeYLG4tRotCbKnA5K0oeFMRWfNCY; Authentication-Results: sj-dkim-6.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 089da5e32269fece1072c9ff54523f20 Cc: SIP IETF Subject: [Sip] Re: Review of draft-ietf-sip-gruu-09 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for the detailed review, Paul. Responses below. Paul Kyzivat wrote: > I did a reasonably careful review of draft-ietf-sip-gruu-09. I was > mostly looking for remaining technical issues rather than formatting > nits. For awhile now I have mostly be looking at diffs as new versions > come out and reading selected sections at need. It was good to read the > whole thing again to see how it all hangs together. > > I found nothing really major, but some stuff that is more than > editorial. Some of it is a judgment call about whether something is > clear or not. I won't feel bad to have a number of these comments rejected. > > Paul > > General comment: > > SIPS is mentioned in many places in this draft. Given the current > ongoing issues wrt SIPS, the language here for dealing with it may prove > to be prescient, or may turn out to just be wrong. Can this be dodged > somehow? Maybe this whole draft should only be defined for SIP, with > SIPS left for a separate draft. (I will still comment on some places > containing SIPS, when there are other points than the above.) Well, it used to say nothing about sips and I think you complained it needed to a long time back ;) I'm not awful inclined to hold the draft up for us to figure all of that out, and I'm also not inclined to say nothing. My preference is to address it as best we can based on the current mechanism, and the in-progress sips update will need to tackle gruu. > > Section 5: > > ... The "opaque" parameter is added by the owner > of the domain to correlate the GRUU to its instance ID, and to easily > recognize that the URI has the GRUU property. > > I think this isn't quite right. The "gruu" parameter may be used to > recognize the GRUU property. How about: > > ... The "opaque" parameter is added by the owner > of the domain to correlate the GRUU to its instance ID, and > potentially to help verify that the GRUU has not been forged. Dale flagged this one too. I'll use your text. > > Figure 1: > > Its unfortunate that pictures such as this lead to many questions, often > irrelevant ones. I know we have discussed nuances of this one before. > > - as shown, a contact is bound to 1 AOR, at most one Instance ID and at > most one GRUU. In practice is is possible to bind the same contact to > multiple AORs if one doesn't need to distinguish between them or has > some other means to do so. (And section 7.1.1.1 allows it, since > restriction to a single AOR is only RECOMMENDED.) Fair point. The cardinality in this direction isn't particularly useful. Rather than changing to 'n' and then needing to explain, I just removed the cardinality entirely. The main thing to show here is that there are 0..n contacts bound to the AOR and GRUU. > It is also possible > that the same contact will be associated with more than one Instance ID. > (Ideally there is only one such association at any one time, but over > time it may change.} One at a time is what is meant to be captured here. Changing this to 'n' I think will be very confusing. > > - the figure doesn't show what is in the text: > > A GRUU is associated, in a many-to-one fashion, with the combination > of an instance ID and an AOR. This combination is referred to as an > instance ID/AOR pair. For each GRUU, there is one instance ID/AOR > pair, and for each instance ID/AOR pair, there can be one or more > GRUU. > > (The picture doesn't show anything associated with an AOR/Instance ID > pair.) Right. In earlier versions of GRUU I used to have an object called instance ID/AOR pair. It cluttered the picture way too much and made it even harder to understand. > > I think it is too hard to make a picture that expresses these > relationships accurately, and this should be done with text, without the > figure. It is in the text. Are you suggesting removing the figure entirely? > > Section 6: > > o For each GRUU, both the SIP and Session Initiation Protocol Secure > (SIPS) versions MUST exist. The SIPS URI may not always work, > particularly if the proxy cannot establish a secure connection to > the client. However, the SIPS URI always exists. > > The use of "always" seems problematic. The lifetime of the gruu itself > is not "always". It is no longer than the associated AOR. Also, this > goes into the previous discussion of relationships. Are the SIP and SIPS > forms *separate* AORs, or the same AOR? I'm struggling here to come up > with something that threads the needle. How about: > > o When both SIP and SIPS AORs identify the same resource, and the > AORs differ only in the scheme name, then when a GRUU is assigned > to the resource, both SIP and SIPS GRUUs will be assigned. Only > one will be returned, but both will exist. The SIPS URI may not > always work, particularly if the proxy cannot establish a secure > connection to the client. I think the first bit of this is not needed. It makes it sound like its OK for a SIP and SIPS AOR to not identify the same resource. I think we've concluded all along (and in the sipsec adhoc in Montreal) that they always do. How about: When a GRUU is assigned to an instance ID/AOR pair, both SIP and SIPS GRUUs will be assigned. Only one will be returned, but both will exist. The SIPS URI may not always work, particularly if the proxy cannot establish a secure connection to the client. > > Section 7.1.1.1: > > Specifically, the contact in the REGISTER request SHOULD > NOT contain the gruu Contact header field parameter, and the contact > URI itself SHOULD NOT contain the "grid" URI parameter defined below. > Any such parameters are ignored by the registrar, as the UA cannot > propose a GRUU for usage with the contact. > > Nit: the last sentence is a little weird, because the "as" clause only > applies to gruu, not grid. Perhaps: > > Any such parameters are ignored by the registrar and not stored. > (The UA cannot propose a GRUU for usage with the contact, and > the grid parameter is populated from the GRUU, not the registered > contact.) I just removed the 'as' bit entirely. > > BUT, later I instead suggest treating the presence of grid as an error > rather than ignoring it. That requires different wording here. No, I think its OK. See below. > > Later in the section: > > ... However, it is > permitted for a UA to register any kind of contact it wishes, > including a GRUU. A typical use case for registering a GRUU is if a > user wanted calls to one AOR to be delivered to a specific UA > instance associated with another AOR. > > I just realized this presents a problem wrt grid processing. If the > contact is a gruu associated with a different AOR, then it could also > contain a grid parameter, and if so, that parameter might be important. > One wouldn't want to lose it, or override it. Right. > > Perhaps it should be an *error* to register a contact that contains a > grid URI parameter. That would prevent any confusion. I think we need to prevent it. The current spec is wrong in this regard; it appears to allow it, but it would cause overriding which is wrong. So, here is my proposal. I think there are two cases here. One, where the contact is a 'plain old contact' and is not bound to a gruu at all. In such a case, the contact would not contain the instance ID and can contain gruu and grid params if the contact happens to be a gruu. No gruu gets bound to this contact. If the contact is a specific instance, then it contains the instance ID, in which case it cannot contain a gruu or grid. With this change, btw, you can register a GRUU to its own AOR, and it works as expected. I changed the text to reflect this. It now reads: Besides the procedures discussed above, the REGISTER request is constructed as it is in the case where this extension was not understood. Specifically, if a contact contains an instance ID parameter, then it SHOULD NOT contain the gruu Contact header field parameter, and the contact URI itself SHOULD NOT contain the "grid" or "gruu" URI parameters defined below. Any such parameters are ignored by the registrar and not stored. Typically, the contact URI is not itself a GRUU and will not contain these URI parameters. There are use cases where a contact can contain a GRUU, however. A typical use case is when a user wanted calls to one AOR to be delivered to a specific UA instance associated with another AOR. If a client does include a contact which contains a GRUU, it MUST NOT contain the instance ID parameter. This will ensure that the contact URI does not get bound to any GRUU, avoiding an infinite loop which might otherwise occur. I made updates in a few other places too; most notably where it talks about overriding the grid in the contact. That can never happen with the change here. > > Section 7.1.1.2: > > ... The URI will be a SIP URI if the To header > field in the REGISTER request contained a SIP URI, else (if the To > header field in the REGISTER request contained a SIPS URI) it will be > a SIPS URI. > > (more sips stuff) Per above I propose to keep this. > > ... Normally, the GRUU will > not change in subsequent 2xx responses to REGISTER. Indeed, even if > the UA lets the contact expire, when it re-registers it at any later > time, the registrar will normally provide the same GRUU for the same > address-of-record and instance ID. However, as discussed above, this > property cannot be completely guaranteed, as network failures may > make it impossible to provide an identifier that persists for all > time. As a result, a UA MUST be prepared to receive a different GRUU > for the same instance ID/AOR pair in a subsequent registration > response. > > As written, this puts a burden on a UA. Any time it refreshes a > registration a previously assigned gruu may change. That gruu may be in > use in a dialog. Then the UA would have to to a target refresh to fix > it. That is a lot to ask, and has potential race conditions if the prior > gruu has become invalid. > > IMO it would be better to put the burden on the registrar to keep the > gruu the same for as long as a registration remains active. Well, registrations can last almost indefinitely (at least until there is a power failure). Thus, I'm not sure this changes much practically speaking. I also think that the principle of robustness favors keeping the current text. By having endpoints prepare for this, the system works in various degrees of server reliability. Actually, this got me thinking. I was about to write, "note also that a dialog can exist without a registration, so that you could have a dialog in place when a registration expires". This may be true *prior* to GRUU, but with GRUU, it is actually false! Because you are using a gruu as the remote contact, mid-dialog requests require the home proxy to have a valid registration in order to handle the request. Thus, gruu effectively requires registrations for sending or receiving a dialog forming request. This is similar to the 3gpp constraint, which many folks from IETF fought long and hard against. Funny that, between this and sip-outbound, we've basically arrived at the same place anyway. It is worth pointing that out. I've added the following text in the front of 8.1.1.: A UA first obtains a GRUU using the procedures of , or by other means outside the scope of this specification. If a UA is using registrations to obtain GRUUs, it MUST have an active registration prior to using a GRUU. It cannot simply reuse a previously cached GRUU, even if the URI itself doesn't ever change. This is because mid-dialog requests, which will be targeted at a GRUU, cannot be processed correctly at the home proxy unless a registration is active. > > I think it might also be good to insert a note into this section: > > NOTE: the 2xx response to REGISTER returns all the contacts > bound to the AOR. This may include contacts bound by other > UAs. Any or all of these may include a "gruu" Contact header field > parameter. The UA is responsible for extracting and saving the > GRUU assigned to the contact(s) it has registered. Yes, something like this needs to be said. I rather it not be a 'NOTE' since that tends to confuse folks about whether it is informational or normative behavior. In fact, you are pointing out an important normative thing. So, I put some normative text up front: The 2xx response to REGISTER returns all the contacts bound to the AOR. This may include contacts bound by other UAs. The UA MUST extract the contacts it has just registered, and perform the processing on those contacts as described here. If the response is a 2xx, each Contact header field that contained the "+sip.instance" Contact > > Section 7.1.2: > > A registrar MUST create both the SIP and SIPS versions of the GRUU, > such that if the GRUU exists, both URI exist. > > (more sips stuff) > > Section 7.1.2.1: > > Nothing is mentioned in this section about handling of a "grid" URI > parameter in the contact. If this is present it can screw things up in a > variety of ways. This is sufficiently severe that it probably isn't wise > to just ignore it if present. Instead, should probably reject the > request. (403 again?) The problems that can result: > > - regular calls to the AOR will look (to the UE) like calls to a gruu > - if the contact was itself a GRUU, and had a particular grid value > for some purpose, then when calls are made to the gruu assigned as > part of this registration, the grid value will be messed up. > > (Note that forbidding grid values here doesn't fully solve the problem. > Using a gruu as a contact in another registration has unresolvable > problems about the namespace for grid values. It can only work right if > the two share a common namespace for the values.) You are right that the spec doesn't say what should happen. Per my above suggestion, I've specifide now that if there is an instance ID, you ignore and don't store the gruu and grid param. > > Same section: > > ... If the To > header field in the REGISTER request contains a SIP URI, the SIP > version of the GRUU is returned. If the To header field in the > REGISTER request contains a SIPS URI, the SIPS version of the GRUU is > returned. > > (more sips stuff) > > Section 8.1.1: > > When using a GRUU as a remote target, a UA MAY add the "grid" URI > > Maybe its just me, but here and elsewhere I am confused by use of the > term "remote target". In a dialog, I think of the "remote target" as the > R-URI I use to reference the *other* end of the dialog. I would then > expect the term "local target" to refer to the URI I expect the other > end to use in the R-URI of requests addressed to me. But I think you are > using it differently. I'm using it as defined in the intro (and in rfc3261): The term "remote target" refers to a URI that a user agent uses to identify itself for receipt of both mid-dialog and out-of-dialog requests. A remote target is established by placing a URI in the Contact header field of a dialog-forming request or response and updated by target refresh requests. > > In the above, I am left wondering if others who receive my GRUU will be > filling in the grid parameter. Of course this is wrong, but I can read > it that way. > > If you agree this is an issue, I guess it will require a careful > laundering of all the places that use the term "remote target". In this particular paragraph I see how it can be confusing. I reworded to: When using a GRUU as a remote target (that is, when populating the Contact header field of an INVITE or 200 OK response), the UA placing the GRUU into the request or response MAY add the "grid" URI parameter to the GRUU, and if one is added, MUST include a value for it. This parameter MAY take any value permitted by the grammar defined > > Section 8.2.1: > > First, I think it would be worthwhile to add a statement at the > beginning of this section stating that this only applies when there are > no Route headers. Maybe this is obvious, but maybe not. Stating this > removes any ambiguity about how a Path header interacts with existing > Route headers. This ties back into the much bigger issue about what to do with pre-loaded route headers in dialog forming requests. For now I think it suffices to say that this section is in fact not addressing what happens if the request also contains route headers. But if it does, its hard to say what the right hting is. In some cases there may be legitimate reasons for it that are not attacks. For now I will merely clarify as you suggest. The specific words I used were: The processing in this section applies to requests that are received outside of a dialog. These requests are identified by their lack of a Route header field when received by the proxy. This doesn't say its wrong to receive a dialog-forming request without a route; it simply says that the rules here don't apply to that case. > > The first paragraph could be interpreted as an *alternative* to the > cases mentioned in the 2nd and 3rd paragraphs. I believe it is not > intended that way, and is instead just a modifier that applies > regardless of which of the other cases are followed. I'm not sure that > this paragraph even needs to be here. It places a dependency from this > draft on -outbound behavior over and above the definition of instance > id. The third paragraph already has language that covers the interaction > case when both drafts are mucking with the same behavior. Agree that the first paragraph lends nothing. I deleted it. > > Later in the section > > ... If the grid was already present > in the contact bound to the GRUU, it is overwritten in this process. > > As I noted earlier, this seems dangerous to me, so I think it should be > prevented earlier. Yes, this was removed. > > Section 8.2.2: > > The proxy that accesses the location service (called the home proxy > here) MUST record-route under two circumstances. Firstly, if the > home proxy receives a dialog forming request from a UA in its own > domain (an originating request) whose Contact header field contains a > GRUU (indicated by the presence of the "gruu" URI parameter), the > proxy MUST record-route. > > This really only applies if the proxy is responsible for the GRUU. The words already apply only in cases where the sending UA is in its own domain. So, the only case when this is true, but it wouldn't be responsible for the GRUU, is if the UA used a different GRUU. For example, I'm a customer of abc.com and I happen to get a gruu from xyz.com. I then send an INVITE with a contact of xyz.com. The rules in the UA processing section require that this request visit abc.com prior to being sent. Its still possible that xyz.com home proxy is on the path too. In such an odd case, I've clarified that the proxy checks the domain of the gruu too. Thanks for your comments, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 16:19:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7eDB-0008Gz-UM; Mon, 31 Jul 2006 16:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7eDA-0008Gu-QL for sip@ietf.org; Mon, 31 Jul 2006 16:18:00 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7eD9-0001c8-Dq for sip@ietf.org; Mon, 31 Jul 2006 16:18:00 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 31 Jul 2006 13:17:59 -0700 X-IronPort-AV: i="4.07,199,1151910000"; d="scan'208"; a="1843041511:sNHT29714204" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6VKHwpx015961; Mon, 31 Jul 2006 13:17:58 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6VKHpBk005699; Mon, 31 Jul 2006 13:17:58 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 16:17:52 -0400 Received: from [161.44.52.163] ([161.44.52.163]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 16:17:52 -0400 Message-ID: <44CE656F.304@cisco.com> Date: Mon, 31 Jul 2006 16:17:51 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Updated acr-code draft References: <44976078.6020408@cisco.com> <001c01c694f9$81039120$31713b51@BEMBUSTER> In-Reply-To: <001c01c694f9$81039120$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2006 20:17:52.0451 (UTC) FILETIME=[66A5A930:01C6B4DE] DKIM-Signature: a=rsa-sha1; q=dns; l=2489; t=1154377078; x=1155241078; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Updated=20acr-code=20draft; X=v=3Dcisco.com=3B=20h=3DGv/2jvWZz0X/PADQDW+Z/Y9RhRs=3D; b=nL4E+JJUsE9sNKtxU/CYlT3qww+u1nVPKrhTZhvqig0JMMLzL1rrnVDZ4X8KklSaxJpY+m3b JtR/EPvpXNTJkjtz1G1vqBD7vWfbI1Ce2CJXeW1CetPrrPmGOEa77vkN; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think it can retry automatically if it was at the request of the user to do so. So, I agree with 'explicitly' but that doesn't rule out 'automatically'. I'll clarify in the security considerations section. Thanks, Jonathan R. Jeroen van Bemmel wrote: > Jonathan, > > (Only) one comment: What about privacy service behavior? In particular I am > thinking about a privacy service that anonymized the request, and > receives a > 433. > > If the privacy service is acting as a B2BUA, it should probably not retry > the request "non-anonymously" (this could constitute a downgrade attack). > This is also something worth mentioning in the security considerations: the > retrying of the request SHOULD be based on an explicit decision by the user > making the request, it SHOULD NOT be done automatically > > Regards, > > Jeroen > > ----- Original Message ----- From: "Jonathan Rosenberg" > To: "IETF SIP List" > Sent: Tuesday, June 20, 2006 4:42 AM > Subject: [Sip] Updated acr-code draft > > >> I've just submitted a minor update to the ACR code draft. Until it >> appears, you can pick it up at: >> >> http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-01.txt >> >> The changes were to add the required RFC 2119 boilerplate and fix some >> spell check errors. The document is complete AFAIK and has had no >> discussion since the last revision. I believe it ready for WGLC. >> >> -Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 16:32:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ePg-00015g-9I; Mon, 31 Jul 2006 16:30:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ePe-00015b-Nr for sip@ietf.org; Mon, 31 Jul 2006 16:30:54 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ePd-0004iZ-Bk for sip@ietf.org; Mon, 31 Jul 2006 16:30:54 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 31 Jul 2006 13:30:31 -0700 X-IronPort-AV: i="4.07,199,1151910000"; d="scan'208"; a="1843046879:sNHT1323393904" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6VKUVp3004110 for ; Mon, 31 Jul 2006 13:30:31 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6VKULmm011862 for ; Mon, 31 Jul 2006 13:30:31 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 16:30:30 -0400 Received: from [161.44.52.163] ([161.44.52.163]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 16:30:30 -0400 Message-ID: <44CE6866.5070906@cisco.com> Date: Mon, 31 Jul 2006 16:30:30 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2006 20:30:30.0508 (UTC) FILETIME=[2A7BFAC0:01C6B4E0] DKIM-Signature: a=rsa-sha1; q=dns; l=770; t=1154377831; x=1155241831; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:updated=20acr=20code=20draft; X=v=3Dcisco.com=3B=20h=3DdR2JoNARViDL+dyk8Fo/5GaRrzY=3D; b=O22pj6/d2Blep8zi+mFzLmbIZBl5JIWMgBh6Rowsimz1+rFz7CYKyy7355kfB5BRg8sXVex6 /qcg0mAYkQdQZ0q34PDUuLl9wAA7jgylo93m+oKJFtLSxCgxGsijhTet; Authentication-Results: sj-dkim-6.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] updated acr code draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've submitted a minor update to the ACR code draft. Until it appears, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt the changes are: * replaced P-Asserted-ID with P-Asserted-Identity * added to security considerations section, consideration for anonymizers in the network. Namely, don't retry request on receipt of 433 unless explicitly configured to do so by user Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 16:39:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7eWZ-0004Gj-Oo; Mon, 31 Jul 2006 16:38:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7eWY-0004G6-Bw for sip@ietf.org; Mon, 31 Jul 2006 16:38:02 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7eWX-00069r-2x for sip@ietf.org; Mon, 31 Jul 2006 16:38:02 -0400 Received: from lion.cs.columbia.edu (IDENT:mRWp6MxIvabEPE6LTS2iG9PM4G0lxssS@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6VKbqf7004515 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 31 Jul 2006 16:37:56 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6VKbprh021025 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 31 Jul 2006 16:37:52 -0400 Message-ID: <44CE6A1A.3000200@cs.columbia.edu> Date: Mon, 31 Jul 2006 16:37:46 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] updated acr code draft References: <44CE6866.5070906@cisco.com> In-Reply-To: <44CE6866.5070906@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.31.131932 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just a quick comment: request without requesting anonymity. It SHOULD only do so if it obtains confirmation from the user that this is desirable. Such confirmation could be obtained through the user interface, or by accessing user defined policy. The UAC SHOULD NOT retry the request if user continues to request anonymity. No guidance is given when the UAC might just retry the request without anonymity and without asking. Is "because it feels like it" a good enough reason :-)? Can a vendor just decide that all its products don't really feel that strongly about anonymity or is this something that only users (or administrators) should be able to configure? I think the right answer is that the UAC MUST NOT do this automatically unless the user or administrator has configured an automatic non-anonymous retry. Jonathan Rosenberg wrote: > I've submitted a minor update to the ACR code draft. Until it appears, > you can pick it up at: > > http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt > > the changes are: > > * replaced P-Asserted-ID with P-Asserted-Identity > > * added to security considerations section, consideration > for anonymizers in the network. Namely, don't retry > request on receipt of 433 unless explicitly configured > to do so by user > > > Thanks, > Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 17:04:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7eun-0007ez-KR; Mon, 31 Jul 2006 17:03:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7eum-0007eu-EQ for sip@ietf.org; Mon, 31 Jul 2006 17:03:04 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7euk-0003L4-4E for sip@ietf.org; Mon, 31 Jul 2006 17:03:04 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Jul 2006 14:03:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,199,1151910000"; d="scan'208"; a="34017357:sNHT23341168" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6VL31RG006038 for ; Mon, 31 Jul 2006 17:03:01 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6VL2gYx022500 for ; Mon, 31 Jul 2006 17:03:01 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 17:02:53 -0400 Received: from [161.44.52.163] ([161.44.52.163]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 17:02:53 -0400 Message-ID: <44CE6FFC.4010000@cisco.com> Date: Mon, 31 Jul 2006 17:02:52 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2006 21:02:53.0093 (UTC) FILETIME=[B05AED50:01C6B4E4] DKIM-Signature: a=rsa-sha1; q=dns; l=2324; t=1154379781; x=1155243781; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:updated=20GRUU=20spec |To:IETF=20SIP=20List=20; X=v=3Dcisco.com=3B=20h=3D7AOP+QNX1B+2VteYWIvFaF/YqhY=3D; b=n1Cv6C7yd6o3Ds6wbxmgQVjboO/WsmDpQo4/w+sC9PcCKSTz7mmJmkNkV4myC+6tqUWp5Mos pnrguo5QQoZdn72ydFivbNxWkQCy+lo8K0Cn/oPGUaPA0sdKmEeOj/lu; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Sip] updated GRUU spec X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've just submitted an update to the GRUU spec based on comments on the list. Until it appears, you can pick it up at: * noted that, in the outbound direction, if the home proxy is not on the original request path, another proxy in that domain needs to put in a record-route that points to it. Provide links to some mechanism which allows a home proxy to get on the outbound request path * clarified that, if an outbound proxy is used, the request has to visit the domain from which the gruu was obtained before being forwarded to the party in the r-uri. There are two ways documented to know this: a. using a service route obtained from the same proxy that sent you a gruu b. using an outbound proxy; configuration tells you what domain its from * noted that an outbound proxy is not needed; rules above only apply when one is used * clarified the interaction of caller prefs and callee caps with gruu * clarified how a proxy determines that a request is a mid-dialog request * clarified that GRUU basically implies you can't have a sip dialog without registration * clarified that a UA, in processing a REGISTER response, is going to have to search for and extract its own contacts in case other UA registered against the same AOR * changed rules on inclusion of grid/gruu URI param in the contact. A registered contact cannot have a grid or gruu URI param if its also got an instance ID. If there is no instance ID its ok. Correspondingly, removed check on making sure a contact wasn't a gruu for the AOR in the To field. This is not necessary now, and in fact is permitted and works fine. * clarified that proxy processing of 'initial' requests applies when there are no Route headers. Consequently, treatment of dialog-forming requests which happen to have route headers is not specified. * removed rfc2119 strength text from requirements section Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 17:59:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7flK-00074d-Gf; Mon, 31 Jul 2006 17:57:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7flI-000746-Sg; Mon, 31 Jul 2006 17:57:20 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7flH-0008Iv-Jm; Mon, 31 Jul 2006 17:57:20 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 16:57:17 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 31 Jul 2006 16:57:16 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 16:57:15 -0500 Message-ID: From: "Winterbottom, James" To: "Rosen, Brian" , "IETF SIP List" Date: Mon, 31 Jul 2006 16:55:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 31 Jul 2006 21:57:15.0842 (UTC) FILETIME=[491AEA20:01C6B4EC] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 References: Content-class: urn:content-classes:message Thread-Topic: Does Location-Conveyance have an HTTP dereference mechanismdefined Thread-Index: Aca0pplgmsITWnO0QY2zuklnycrsOwARWrZN X-Spam-Score: 0.5 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: GEOPRIV Subject: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, =20 Your second paragraph re-opens the sore I am afraid. A large number of people have agreed with Henning's statements and these ar= e clear: 1) Do not constrain the ABNF 2) Provide minimal description of the reference function. =20 If you insist on saying then that the ABNF will be restricted if there is n= ot matching text, then I think it unlikely that you will reach a consensus. =20 Cheers James ________________________________ From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Mon 31/07/2006 8:38 AM To: IETF SIP List Cc: GEOPRIV Subject: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechani= sm defined I have lost track of where we stand on whether the only mentioned URI schemes in location-conveyance are sip/sips/pres. I "think" we have agreed that an HTTP/HTTPS dereference is in a separate document, but I'm not sure. This is NOT the discussion of what the ABNF of the location header looks like (although it would NOT have http/https in it for sure if we agree that an HTTP dereference protocol is a separate draft). If you think location-conveyance DOES have HTTP dereference text in it, please say so, and please explain why you would not be satisfied if there were a separate draft on the subject. Brian _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 18:07:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ftS-0002yp-Iw; Mon, 31 Jul 2006 18:05:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ftR-0002xn-92; Mon, 31 Jul 2006 18:05:45 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ftQ-00013M-0o; Mon, 31 Jul 2006 18:05:45 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns0.neustar.com (Postfix) with ESMTP id 0067C32868; Mon, 31 Jul 2006 22:05:43 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 18:05:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jul 2006 18:05:40 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined Thread-Index: Aca0pplgmsITWnO0QY2zuklnycrsOwARWrZNAAAd3gA= From: "Rosen, Brian" To: "Winterbottom, James" , "IETF SIP List" X-OriginalArrivalTime: 31 Jul 2006 22:05:43.0675 (UTC) FILETIME=[77CC14B0:01C6B4ED] X-Spam-Score: -2.3 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: GEOPRIV Subject: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Please don't change the subject, I understand the controversy on constraining the ABNF. I tried (apparently without success) to separate those issues. =20 I'm asking if anyone objects to NOT mentioning HTTP in any way with respect to dereferencing URIs carried by the Location header. That is the only question I asked. =20 I'm not trying to evade the constrained ABNF issue, and I'm not implying anything tricky. I simply want to know if it's okay if we leave anything that deals specifically with HTTP and the Location header URI to another document. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, July 31, 2006 5:55 PM > To: Rosen, Brian; IETF SIP List > Cc: GEOPRIV > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > dereferencemechanism defined >=20 > Brian, >=20 > Your second paragraph re-opens the sore I am afraid. > A large number of people have agreed with Henning's statements and these > are clear: > 1) Do not constrain the ABNF > 2) Provide minimal description of the reference function. >=20 > If you insist on saying then that the ABNF will be restricted if there is > not matching text, then I think it unlikely that you will reach a > consensus. >=20 > Cheers > James >=20 > ________________________________ >=20 > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Mon 31/07/2006 8:38 AM > To: IETF SIP List > Cc: GEOPRIV > Subject: [Geopriv] Does Location-Conveyance have an HTTP > dereferencemechanism defined >=20 >=20 >=20 > I have lost track of where we stand on whether the only mentioned URI > schemes in location-conveyance are sip/sips/pres. I "think" we have > agreed that an HTTP/HTTPS dereference is in a separate document, but I'm > not sure. >=20 > This is NOT the discussion of what the ABNF of the location header looks > like (although it would NOT have http/https in it for sure if we agree > that an HTTP dereference protocol is a separate draft). >=20 > If you think location-conveyance DOES have HTTP dereference text in it, > please say so, and please explain why you would not be satisfied if > there were a separate draft on the subject. >=20 > Brian >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 >=20 > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 18:23:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7g8e-0002L0-FO; Mon, 31 Jul 2006 18:21:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7g8d-0002Ks-Kf; Mon, 31 Jul 2006 18:21:27 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7g8c-0003LE-A9; Mon, 31 Jul 2006 18:21:27 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 17:21:25 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 31 Jul 2006 17:21:24 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 17:21:24 -0500 Message-ID: From: "Winterbottom, James" To: "Rosen, Brian" , "IETF SIP List" Date: Mon, 31 Jul 2006 17:19:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 31 Jul 2006 22:21:24.0479 (UTC) FILETIME=[A88F60F0:01C6B4EF] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 References: Content-class: urn:content-classes:message Thread-Topic: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined Thread-Index: Aca0pplgmsITWnO0QY2zuklnycrsOwARWrZNAAAd3gAAALmFiw== X-Spam-Score: 0.5 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: GEOPRIV Subject: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Not true =20 "> This is NOT the discussion of what the ABNF of the location header looks > like (although it would NOT have http/https in it for sure if we agree > that an HTTP dereference protocol is a separate draft)." =20 This is a discussion on ABNF and what the document contains, and to that ex= tent they are not separable. The consensus has been, do not restrict the ABNF, keep the discussion in th= e document about references limited. I am failing to understand why you can= 't accept that. =20 =20 ________________________________ From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Mon 31/07/2006 5:05 PM To: Winterbottom, James; IETF SIP List Cc: GEOPRIV Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemec= hanism defined Please don't change the subject, I understand the controversy on constraining the ABNF. I tried (apparently without success) to separate those issues.=20 I'm asking if anyone objects to NOT mentioning HTTP in any way with respect to dereferencing URIs carried by the Location header. That is the only question I asked.=20 I'm not trying to evade the constrained ABNF issue, and I'm not implying anything tricky. I simply want to know if it's okay if we leave anything that deals specifically with HTTP and the Location header URI to another document. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, July 31, 2006 5:55 PM > To: Rosen, Brian; IETF SIP List > Cc: GEOPRIV > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > dereferencemechanism defined > > Brian, > > Your second paragraph re-opens the sore I am afraid. > A large number of people have agreed with Henning's statements and these > are clear: > 1) Do not constrain the ABNF > 2) Provide minimal description of the reference function. > > If you insist on saying then that the ABNF will be restricted if there is > not matching text, then I think it unlikely that you will reach a > consensus. > > Cheers > James > > ________________________________ > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Mon 31/07/2006 8:38 AM > To: IETF SIP List > Cc: GEOPRIV > Subject: [Geopriv] Does Location-Conveyance have an HTTP > dereferencemechanism defined > > > > I have lost track of where we stand on whether the only mentioned URI > schemes in location-conveyance are sip/sips/pres. I "think" we have > agreed that an HTTP/HTTPS dereference is in a separate document, but I'm > not sure. > > This is NOT the discussion of what the ABNF of the location header looks > like (although it would NOT have http/https in it for sure if we agree > that an HTTP dereference protocol is a separate draft). > > If you think location-conveyance DOES have HTTP dereference text in it, > please say so, and please explain why you would not be satisfied if > there were a separate draft on the subject. > > Brian > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > > > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 18:46:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gVO-0004N0-30; Mon, 31 Jul 2006 18:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gVL-0004H1-RQ; Mon, 31 Jul 2006 18:44:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7gVL-0005Ub-Nd; Mon, 31 Jul 2006 18:44:55 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7gVJ-0000wx-GS; Mon, 31 Jul 2006 18:44:55 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns3.neustar.com (Postfix) with ESMTP id 3DD22175EE; Mon, 31 Jul 2006 22:44:23 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 18:44:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jul 2006 18:44:21 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined Thread-Index: Aca0pplgmsITWnO0QY2zuklnycrsOwARWrZNAAAd3gAAALmFiwAAITRA From: "Rosen, Brian" To: "Winterbottom, James" , "IETF SIP List" X-OriginalArrivalTime: 31 Jul 2006 22:44:22.0816 (UTC) FILETIME=[DE1CEA00:01C6B4F2] X-Spam-Score: -4.1 (----) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: GEOPRIV Subject: [Sip] RE: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Can't let go can you? I changed the subject line to start a different thread. I'd still like the answer to the original thread. There are two separable issues with respect to the ABNF. The syntactic and the semantic. The syntactic issues could be dealt with by saying: location-param =3D LAQUOT loc-URI RAQUOT *( SEMI loc-param )=20 ;cid-url from RFC2392, SIP/SIPS-URI from RFC3261, PRES-URI from RFC3859=20 ;Absolute URI from RFC3261 loc-URI =3D cid-uri / SIP-URI / SIPS-URI / PRES-URI / AbsoluteURI This answers Henning and Jeroen's objection to strictly limiting the ABNF. The alternative is to just use AbsoluteURI. I guess the question is, what does the text say? I can make the ABNF match what the text says. Does the text say: any URI can appear in the location header, entities must use some undefined mechanism to maintain interoperability. Does it say: location dereferencing is a "using protocol" as defined in geopriv requirements. Any URI found in the location header MUST meet the requirements of a using protocol. Does it say: This document describes the use of SIP and SIPS as a dereferencing protocol (and the use of a pres: uri if the resolution of the pres: scheme in the referenced domain is to a presence service using the sip/sips protocol). All entities using the Location header MUST support SIP dereferencing. =20 Does it say (if the paragraph immediately above is there): Other protocols used for dereferencing MUST have a (?standards track?) RFC defining how to dereference. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, July 31, 2006 6:19 PM > To: Rosen, Brian; IETF SIP List > Cc: GEOPRIV > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > dereferencemechanism defined >=20 > Not true >=20 > "> This is NOT the discussion of what the ABNF of the location header > looks > > like (although it would NOT have http/https in it for sure if we agree > > that an HTTP dereference protocol is a separate draft)." >=20 > This is a discussion on ABNF and what the document contains, and to that > extent they are not separable. > The consensus has been, do not restrict the ABNF, keep the discussion in > the document about references limited. I am failing to understand why you > can't accept that. >=20 >=20 >=20 > ________________________________ >=20 > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Mon 31/07/2006 5:05 PM > To: Winterbottom, James; IETF SIP List > Cc: GEOPRIV > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > dereferencemechanism defined >=20 >=20 >=20 > Please don't change the subject, I understand the controversy on > constraining the ABNF. I tried (apparently without success) to separate > those issues. >=20 > I'm asking if anyone objects to NOT mentioning HTTP in any way with > respect to dereferencing URIs carried by the Location header. That is > the only question I asked. >=20 > I'm not trying to evade the constrained ABNF issue, and I'm not implying > anything tricky. I simply want to know if it's okay if we leave > anything that deals specifically with HTTP and the Location header URI > to another document. >=20 > Brian >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Monday, July 31, 2006 5:55 PM > > To: Rosen, Brian; IETF SIP List > > Cc: GEOPRIV > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > dereferencemechanism defined > > > > Brian, > > > > Your second paragraph re-opens the sore I am afraid. > > A large number of people have agreed with Henning's statements and > these > > are clear: > > 1) Do not constrain the ABNF > > 2) Provide minimal description of the reference function. > > > > If you insist on saying then that the ABNF will be restricted if there > is > > not matching text, then I think it unlikely that you will reach a > > consensus. > > > > Cheers > > James > > > > ________________________________ > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Mon 31/07/2006 8:38 AM > > To: IETF SIP List > > Cc: GEOPRIV > > Subject: [Geopriv] Does Location-Conveyance have an HTTP > > dereferencemechanism defined > > > > > > > > I have lost track of where we stand on whether the only mentioned URI > > schemes in location-conveyance are sip/sips/pres. I "think" we have > > agreed that an HTTP/HTTPS dereference is in a separate document, but > I'm > > not sure. > > > > This is NOT the discussion of what the ABNF of the location header > looks > > like (although it would NOT have http/https in it for sure if we agree > > that an HTTP dereference protocol is a separate draft). > > > > If you think location-conveyance DOES have HTTP dereference text in > it, > > please say so, and please explain why you would not be satisfied if > > there were a separate draft on the subject. > > > > Brian > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] >=20 >=20 >=20 > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 18:47:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gW7-0004oM-0X; Mon, 31 Jul 2006 18:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gW5-0004oF-Cc for sip@ietf.org; Mon, 31 Jul 2006 18:45:41 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7gW4-0005rv-WD for sip@ietf.org; Mon, 31 Jul 2006 18:45:41 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6VMja115616; Mon, 31 Jul 2006 18:45:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: Review of draft-ietf-sip-gruu-09 Date: Mon, 31 Jul 2006 17:44:37 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0BDCAD6B@zrc2hxm0.corp.nortel.com> In-Reply-To: <44CE64BD.8010807@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: Review of draft-ietf-sip-gruu-09 Thread-Index: Aca03hVDu1TkvRkhQoaBRvZ2HQz98wAEOHKQ From: "Francois Audet" To: "Jonathan Rosenberg" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm keeping my comments to sips-related issues.=20 See below. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Monday, July 31, 2006 1:15 PM > To: Paul Kyzivat > Cc: SIP IETF > Subject: [Sip] Re: Review of draft-ietf-sip-gruu-09 >=20 > > SIPS is mentioned in many places in this draft. Given the current=20 > > ongoing issues wrt SIPS, the language here for dealing=20 > with it may=20 > > prove to be prescient, or may turn out to just be wrong.=20 > Can this be=20 > > dodged somehow? Maybe this whole draft should only be=20 > defined for SIP,=20 > > with SIPS left for a separate draft. (I will still=20 > comment on some=20 > > places containing SIPS, when there are other points than=20 > the above.) >=20 > Well, it used to say nothing about sips and I think you=20 > complained it needed to a long time back ;) >=20 > I'm not awful inclined to hold the draft up for us to=20 > figure all of that out, and I'm also not inclined to say=20 > nothing. My preference is to address it as best we can=20 > based on the current mechanism, and the in-progress sips=20 > update will need to tackle gruu. Yeah, it's a fine line we are walking here... See below. > > Section 6: > >=20 > > o For each GRUU, both the SIP and Session Initiation=20 > Protocol Secure > > (SIPS) versions MUST exist. The SIPS URI may not=20 > always work, > > particularly if the proxy cannot establish a secure=20 > connection to > > the client. However, the SIPS URI always exists. > >=20 > > The use of "always" seems problematic. The lifetime of=20 > the gruu itself=20 > > is not "always". It is no longer than the associated AOR.=20 > Also, this=20 > > goes into the previous discussion of relationships. Are=20 > the SIP and SIPS=20 > > forms *separate* AORs, or the same AOR? I'm struggling=20 > here to come up=20 > > with something that threads the needle. How about: > >=20 > > o When both SIP and SIPS AORs identify the same=20 > resource, and the > > AORs differ only in the scheme name, then when a=20 > GRUU is assigned > > to the resource, both SIP and SIPS GRUUs will be=20 > assigned. Only > > one will be returned, but both will exist. The=20 > SIPS URI may not > > always work, particularly if the proxy cannot=20 > establish a secure > > connection to the client. >=20 > I think the first bit of this is not needed. It makes it=20 > sound like its=20 > OK for a SIP and SIPS AOR to not identify the same=20 > resource. I think=20 > we've concluded all along (and in the sipsec adhoc in=20 > Montreal) that=20 > they always do. I wouldn't say it was "all along", but it is definitively what we concluded out of the Montr=E9al sipsec BOF. > How about: >=20 > When a GRUU is assigned to an instance ID/AOR pair, > both SIP and SIPS GRUUs will be assigned. Only one will be > returned, but both will exist. The SIPS URI may not > always work, particularly if the proxy cannot establish a > secure connection to the client. > That seems OK with me. I guess one could argued that both are "reserved", as opposed to = "assigned".=20 You reserve both sip and sips, and only return one. Maybe I would say = that they may not be "usable" instead "working". Something like: When a GRUU is assigned to an instance ID/AOR pair, both SIP and SIPS GRUUs will be reserved. Only one will be returned, but both will exist. The SIPS URI may not always be usable, particularly if the proxy cannot establish a secure connection to the client. But I'm fine either way. Key is that there is one entry in the table for both shemes, as opposed = to 2 entries. > > Section 7.1.1.2: > >=20 > > ... The URI will be a SIP URI if the To header > > field in the REGISTER request contained a SIP URI,=20 > else (if the To > > header field in the REGISTER request contained a SIPS=20 > URI) it will be > > a SIPS URI. > >=20 > > (more sips stuff) >=20 > Per above I propose to keep this. Like Paul, I am a little worried about the following statement: The URI will be a SIP URI if the To header field in the REGISTER request contained a SIP URI, else (if the To header field in the REGISTER request contained a SIPS URI) it will = be a SIPS URI.=20 First, it is not written as a SHOULD or MUST (but as a "will"). And more = importantly, this is where the parallel text concerning contacts and sips in RRFC = 3261/10.2.1 is kind of fuzzy. It says: If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then any Contact header field values in the request SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs under a SIPS address-of-record when the security of the resource represented by the contact address is guaranteed by other means. This may be applicable to URIs that invoke protocols other than SIP, or SIP devices secured by protocols other than TLS. I think we have 3 choices: (1) We clean up the language so that it matches the spirit of the same = text in 3261 (i.e., SHOULD with the fuzzy language). (2) We have a statement that the same rule as for Contacts applies (3) We remore the offending statement. Personally, I believe options (2) and (3) are much better. I prefer (3). > > Section 7.1.2: > >=20 > > A registrar MUST create both the SIP and SIPS versions=20 > of the GRUU, > > such that if the GRUU exists, both URI exist. > >=20 > > (more sips stuff) > >=20 > > Section 7.1.2.1: > > ... If the To > > header field in the REGISTER request contains a SIP=20 > URI, the SIP > > version of the GRUU is returned. If the To header field in the > > REGISTER request contains a SIPS URI, the SIPS version=20 > of the GRUU is > > returned. > >=20 > > (more sips stuff) Same comment as above apply. I'm not sure we need this statement here.=20 If we do decide to keep it, it is a MUST or a SHOULD? It shouldn't be = this passive form "is". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 18:49:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gXy-0006Na-Ux; Mon, 31 Jul 2006 18:47:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gXx-0006EN-33; Mon, 31 Jul 2006 18:47:37 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7gXw-0006Sz-Es; Mon, 31 Jul 2006 18:47:37 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 17:47:36 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 31 Jul 2006 17:47:35 -0500 Received: from AOPEX4.andrew.com ([10.3.20.127]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 17:47:34 -0500 Message-ID: From: "Dawson, Martin" To: "Rosen, Brian" , "Winterbottom, James" , "IETF SIP List" Date: Mon, 31 Jul 2006 17:47:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 31 Jul 2006 22:47:34.0662 (UTC) FILETIME=[50764A60:01C6B4F3] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined Thread-Index: Aca0pplgmsITWnO0QY2zuklnycrsOwARWrZNAAAd3gAAALmFiwAAITRAAADUOHA= X-Spam-Score: 0.5 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: GEOPRIV Subject: [Sip] RE: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just using absoluteuri seems like the complete simplification... > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Tuesday, 1 August 2006 8:44 AM > To: Winterbottom, James; IETF SIP List > Cc: GEOPRIV > Subject: RE: [Geopriv] URI restrictions in location conveyance,was Does > Location-Conveyance have an HTTP dereferencemechanism defined >=20 > Can't let go can you? I changed the subject line to start a different > thread. I'd still like the answer to the original thread. >=20 > There are two separable issues with respect to the ABNF. The syntactic > and the semantic. >=20 > The syntactic issues could be dealt with by saying: >=20 > location-param =3D LAQUOT loc-URI RAQUOT *( SEMI loc-param ) > ;cid-url from RFC2392, SIP/SIPS-URI from RFC3261, PRES-URI from RFC3859 > ;Absolute URI from RFC3261 > loc-URI =3D cid-uri / SIP-URI / SIPS-URI / PRES-URI / AbsoluteURI >=20 > This answers Henning and Jeroen's objection to strictly limiting the > ABNF. > The alternative is to just use AbsoluteURI. >=20 > I guess the question is, what does the text say? I can make the ABNF > match what the text says. >=20 > Does the text say: any URI can appear in the location header, entities > must use some undefined mechanism to maintain interoperability. >=20 > Does it say: location dereferencing is a "using protocol" as defined in > geopriv requirements. Any URI found in the location header MUST meet > the requirements of a using protocol. >=20 > Does it say: This document describes the use of SIP and SIPS as a > dereferencing protocol (and the use of a pres: uri if the resolution of > the pres: scheme in the referenced domain is to a presence service using > the sip/sips protocol). All entities using the Location header MUST > support SIP dereferencing. >=20 > Does it say (if the paragraph immediately above is there): Other > protocols used for dereferencing MUST have a (?standards track?) RFC > defining how to dereference. >=20 > Brian >=20 > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Monday, July 31, 2006 6:19 PM > > To: Rosen, Brian; IETF SIP List > > Cc: GEOPRIV > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > dereferencemechanism defined > > > > Not true > > > > "> This is NOT the discussion of what the ABNF of the location header > > looks > > > like (although it would NOT have http/https in it for sure if we > agree > > > that an HTTP dereference protocol is a separate draft)." > > > > This is a discussion on ABNF and what the document contains, and to > that > > extent they are not separable. > > The consensus has been, do not restrict the ABNF, keep the discussion > in > > the document about references limited. I am failing to understand why > you > > can't accept that. > > > > > > > > ________________________________ > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Mon 31/07/2006 5:05 PM > > To: Winterbottom, James; IETF SIP List > > Cc: GEOPRIV > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > dereferencemechanism defined > > > > > > > > Please don't change the subject, I understand the controversy on > > constraining the ABNF. I tried (apparently without success) to > separate > > those issues. > > > > I'm asking if anyone objects to NOT mentioning HTTP in any way with > > respect to dereferencing URIs carried by the Location header. That is > > the only question I asked. > > > > I'm not trying to evade the constrained ABNF issue, and I'm not > implying > > anything tricky. I simply want to know if it's okay if we leave > > anything that deals specifically with HTTP and the Location header URI > > to another document. > > > > Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Monday, July 31, 2006 5:55 PM > > > To: Rosen, Brian; IETF SIP List > > > Cc: GEOPRIV > > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > > dereferencemechanism defined > > > > > > Brian, > > > > > > Your second paragraph re-opens the sore I am afraid. > > > A large number of people have agreed with Henning's statements and > > these > > > are clear: > > > 1) Do not constrain the ABNF > > > 2) Provide minimal description of the reference function. > > > > > > If you insist on saying then that the ABNF will be restricted if > there > > is > > > not matching text, then I think it unlikely that you will reach a > > > consensus. > > > > > > Cheers > > > James > > > > > > ________________________________ > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > Sent: Mon 31/07/2006 8:38 AM > > > To: IETF SIP List > > > Cc: GEOPRIV > > > Subject: [Geopriv] Does Location-Conveyance have an HTTP > > > dereferencemechanism defined > > > > > > > > > > > > I have lost track of where we stand on whether the only mentioned > URI > > > schemes in location-conveyance are sip/sips/pres. I "think" we have > > > agreed that an HTTP/HTTPS dereference is in a separate document, but > > I'm > > > not sure. > > > > > > This is NOT the discussion of what the ABNF of the location header > > looks > > > like (although it would NOT have http/https in it for sure if we > agree > > > that an HTTP dereference protocol is a separate draft). > > > > > > If you think location-conveyance DOES have HTTP dereference text in > > it, > > > please say so, and please explain why you would not be satisfied if > > > there were a separate draft on the subject. > > > > > > Brian > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 19:04:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gmE-0004w0-Os; Mon, 31 Jul 2006 19:02:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gmD-0004vd-5w; Mon, 31 Jul 2006 19:02:21 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7gmD-0007Up-1f; Mon, 31 Jul 2006 19:02:21 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7gmA-00019Q-I7; Mon, 31 Jul 2006 19:02:20 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns3.neustar.com (Postfix) with ESMTP id 533F21759D; Mon, 31 Jul 2006 23:01:48 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 19:01:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jul 2006 19:01:46 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined Thread-Index: Aca0pplgmsITWnO0QY2zuklnycrsOwARWrZNAAAd3gAAALmFiwAAITRAAADUOHAAABhe8A== From: "Rosen, Brian" To: "Dawson, Martin" , "Winterbottom, James" , "IETF SIP List" X-OriginalArrivalTime: 31 Jul 2006 23:01:47.0794 (UTC) FILETIME=[4CF7E720:01C6B4F5] X-Spam-Score: -4.1 (----) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Cc: GEOPRIV Subject: [Sip] RE: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sure, and so does: "Any URI can be used". That isn't necessarily a good thing. If the text is like the "this document describes how you use sip/sips/pres" then the ABNF I suggested is more appropriate. Any ABNF can be significantly reduced if the only thing you are trying to convey with it is strict syntactic compliance. No significant document with large hunks of ABNF in the IETF does that. We almost always try to make the ABNF show as much of the semantic meaning as is reasonable. If you follow the SIP threads, there are several messages a month whose answer starts: "you can't look at the ABNF alone, you have to read the text". To me, this is a document failure, unless the ABNF was has to be so ugly to be completely correct it fails to communicate. Alas, that happens. But if it is possible to simply communicate the semantics in the ABNF, then it is appropriate to do so. You can use the "token" construction a whole lot more than we do if all you want is syntax checking. Lots of examples in 3261: Priority =3D "Priority" HCOLON priority-value priority-value =3D "emergency" / "urgent" / "normal" / "non-urgent" / other-priority other-priority =3D token Contact =3D ("Contact" / "m" ) HCOLON ( STAR / (contact-param *(COMMA contact-param))) contact-param =3D (name-addr / addr-spec) *(SEMI contact-params) name-addr =3D [ display-name ] LAQUOT addr-spec RAQUOT addr-spec =3D SIP-URI / SIPS-URI / absoluteURI Let's settle on the words first. The ABNF will follow. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Monday, July 31, 2006 6:48 PM > To: Rosen, Brian; Winterbottom, James; IETF SIP List > Cc: GEOPRIV > Subject: RE: [Geopriv] URI restrictions in location conveyance,was Does > Location-Conveyance have an HTTP dereferencemechanism defined >=20 > Just using absoluteuri seems like the complete simplification... >=20 > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Tuesday, 1 August 2006 8:44 AM > > To: Winterbottom, James; IETF SIP List > > Cc: GEOPRIV > > Subject: RE: [Geopriv] URI restrictions in location conveyance,was > Does > > Location-Conveyance have an HTTP dereferencemechanism defined > > > > Can't let go can you? I changed the subject line to start a different > > thread. I'd still like the answer to the original thread. > > > > There are two separable issues with respect to the ABNF. The > syntactic > > and the semantic. > > > > The syntactic issues could be dealt with by saying: > > > > location-param =3D LAQUOT loc-URI RAQUOT *( SEMI loc-param ) > > ;cid-url from RFC2392, SIP/SIPS-URI from RFC3261, PRES-URI from > RFC3859 > > ;Absolute URI from RFC3261 > > loc-URI =3D cid-uri / SIP-URI / SIPS-URI / PRES-URI / AbsoluteURI > > > > This answers Henning and Jeroen's objection to strictly limiting the > > ABNF. > > The alternative is to just use AbsoluteURI. > > > > I guess the question is, what does the text say? I can make the ABNF > > match what the text says. > > > > Does the text say: any URI can appear in the location header, entities > > must use some undefined mechanism to maintain interoperability. > > > > Does it say: location dereferencing is a "using protocol" as defined > in > > geopriv requirements. Any URI found in the location header MUST meet > > the requirements of a using protocol. > > > > Does it say: This document describes the use of SIP and SIPS as a > > dereferencing protocol (and the use of a pres: uri if the resolution > of > > the pres: scheme in the referenced domain is to a presence service > using > > the sip/sips protocol). All entities using the Location header MUST > > support SIP dereferencing. > > > > Does it say (if the paragraph immediately above is there): Other > > protocols used for dereferencing MUST have a (?standards track?) RFC > > defining how to dereference. > > > > Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Monday, July 31, 2006 6:19 PM > > > To: Rosen, Brian; IETF SIP List > > > Cc: GEOPRIV > > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > > dereferencemechanism defined > > > > > > Not true > > > > > > "> This is NOT the discussion of what the ABNF of the location > header > > > looks > > > > like (although it would NOT have http/https in it for sure if we > > agree > > > > that an HTTP dereference protocol is a separate draft)." > > > > > > This is a discussion on ABNF and what the document contains, and to > > that > > > extent they are not separable. > > > The consensus has been, do not restrict the ABNF, keep the > discussion > > in > > > the document about references limited. I am failing to understand > why > > you > > > can't accept that. > > > > > > > > > > > > ________________________________ > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > Sent: Mon 31/07/2006 5:05 PM > > > To: Winterbottom, James; IETF SIP List > > > Cc: GEOPRIV > > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > > dereferencemechanism defined > > > > > > > > > > > > Please don't change the subject, I understand the controversy on > > > constraining the ABNF. I tried (apparently without success) to > > separate > > > those issues. > > > > > > I'm asking if anyone objects to NOT mentioning HTTP in any way with > > > respect to dereferencing URIs carried by the Location header. That > is > > > the only question I asked. > > > > > > I'm not trying to evade the constrained ABNF issue, and I'm not > > implying > > > anything tricky. I simply want to know if it's okay if we leave > > > anything that deals specifically with HTTP and the Location header > URI > > > to another document. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: Monday, July 31, 2006 5:55 PM > > > > To: Rosen, Brian; IETF SIP List > > > > Cc: GEOPRIV > > > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > > > dereferencemechanism defined > > > > > > > > Brian, > > > > > > > > Your second paragraph re-opens the sore I am afraid. > > > > A large number of people have agreed with Henning's statements and > > > these > > > > are clear: > > > > 1) Do not constrain the ABNF > > > > 2) Provide minimal description of the reference function. > > > > > > > > If you insist on saying then that the ABNF will be restricted if > > there > > > is > > > > not matching text, then I think it unlikely that you will reach a > > > > consensus. > > > > > > > > Cheers > > > > James > > > > > > > > ________________________________ > > > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > Sent: Mon 31/07/2006 8:38 AM > > > > To: IETF SIP List > > > > Cc: GEOPRIV > > > > Subject: [Geopriv] Does Location-Conveyance have an HTTP > > > > dereferencemechanism defined > > > > > > > > > > > > > > > > I have lost track of where we stand on whether the only mentioned > > URI > > > > schemes in location-conveyance are sip/sips/pres. I "think" we > have > > > > agreed that an HTTP/HTTPS dereference is in a separate document, > but > > > I'm > > > > not sure. > > > > > > > > This is NOT the discussion of what the ABNF of the location header > > > looks > > > > like (although it would NOT have http/https in it for sure if we > > agree > > > > that an HTTP dereference protocol is a separate draft). > > > > > > > > If you think location-conveyance DOES have HTTP dereference text > in > > > it, > > > > please say so, and please explain why you would not be satisfied > if > > > > there were a separate draft on the subject. > > > > > > > > Brian > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > [mf2] > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 19:13:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gvK-0000wA-6M; Mon, 31 Jul 2006 19:11:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gvI-0000vz-K3; Mon, 31 Jul 2006 19:11:44 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7gvI-0008Gz-3Y; Mon, 31 Jul 2006 19:11:44 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 18:11:43 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 31 Jul 2006 18:11:42 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 18:11:42 -0500 Message-ID: From: "Winterbottom, James" To: "Rosen, Brian" , "Dawson, Martin" , "IETF SIP List" Date: Mon, 31 Jul 2006 18:08:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 31 Jul 2006 23:11:42.0615 (UTC) FILETIME=[AF826270:01C6B4F6] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 References: Content-class: urn:content-classes:message Thread-Topic: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined Thread-Index: Aca0pplgmsITWnO0QY2zuklnycrsOwARWrZNAAAd3gAAALmFiwAAITRAAADUOHAAABhe8AAAqqVS X-Spam-Score: 0.5 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Cc: GEOPRIV Subject: [Sip] RE: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian, =20 So the two things are linked then? =20 It is my belief that the consensus is in favour of what Henning suggested, = and that is what I would like. Perhaps you would like to include precisely that position in your next ques= t for consensus, rather than trying to re-word it and losing the intent. =20 Cheers James ________________________________ From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Mon 31/07/2006 6:01 PM To: Dawson, Martin; Winterbottom, James; IETF SIP List Cc: GEOPRIV Subject: RE: [Geopriv] URI restrictions in location conveyance,was Does Loc= ation-Conveyance have an HTTP dereferencemechanism defined Sure, and so does: "Any URI can be used". That isn't necessarily a good thing. If the text is like the "this document describes how you use sip/sips/pres" then the ABNF I suggested is more appropriate. Any ABNF can be significantly reduced if the only thing you are trying to convey with it is strict syntactic compliance. No significant document with large hunks of ABNF in the IETF does that. We almost always try to make the ABNF show as much of the semantic meaning as is reasonable. If you follow the SIP threads, there are several messages a month whose answer starts: "you can't look at the ABNF alone, you have to read the text". To me, this is a document failure, unless the ABNF was has to be so ugly to be completely correct it fails to communicate. Alas, that happens. But if it is possible to simply communicate the semantics in the ABNF, then it is appropriate to do so. You can use the "token" construction a whole lot more than we do if all you want is syntax checking. Lots of examples in 3261: Priority =3D "Priority" HCOLON priority-value priority-value =3D "emergency" / "urgent" / "normal" / "non-urgent" / other-priority other-priority =3D token Contact =3D ("Contact" / "m" ) HCOLON ( STAR / (contact-param *(COMMA contact-param))) contact-param =3D (name-addr / addr-spec) *(SEMI contact-params) name-addr =3D [ display-name ] LAQUOT addr-spec RAQUOT addr-spec =3D SIP-URI / SIPS-URI / absoluteURI Let's settle on the words first. The ABNF will follow. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Monday, July 31, 2006 6:48 PM > To: Rosen, Brian; Winterbottom, James; IETF SIP List > Cc: GEOPRIV > Subject: RE: [Geopriv] URI restrictions in location conveyance,was Does > Location-Conveyance have an HTTP dereferencemechanism defined > > Just using absoluteuri seems like the complete simplification... > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Tuesday, 1 August 2006 8:44 AM > > To: Winterbottom, James; IETF SIP List > > Cc: GEOPRIV > > Subject: RE: [Geopriv] URI restrictions in location conveyance,was > Does > > Location-Conveyance have an HTTP dereferencemechanism defined > > > > Can't let go can you? I changed the subject line to start a different > > thread. I'd still like the answer to the original thread. > > > > There are two separable issues with respect to the ABNF. The > syntactic > > and the semantic. > > > > The syntactic issues could be dealt with by saying: > > > > location-param =3D LAQUOT loc-URI RAQUOT *( SEMI loc-param ) > > ;cid-url from RFC2392, SIP/SIPS-URI from RFC3261, PRES-URI from > RFC3859 > > ;Absolute URI from RFC3261 > > loc-URI =3D cid-uri / SIP-URI / SIPS-URI / PRES-URI / AbsoluteURI > > > > This answers Henning and Jeroen's objection to strictly limiting the > > ABNF. > > The alternative is to just use AbsoluteURI. > > > > I guess the question is, what does the text say? I can make the ABNF > > match what the text says. > > > > Does the text say: any URI can appear in the location header, entities > > must use some undefined mechanism to maintain interoperability. > > > > Does it say: location dereferencing is a "using protocol" as defined > in > > geopriv requirements. Any URI found in the location header MUST meet > > the requirements of a using protocol. > > > > Does it say: This document describes the use of SIP and SIPS as a > > dereferencing protocol (and the use of a pres: uri if the resolution > of > > the pres: scheme in the referenced domain is to a presence service > using > > the sip/sips protocol). All entities using the Location header MUST > > support SIP dereferencing. > > > > Does it say (if the paragraph immediately above is there): Other > > protocols used for dereferencing MUST have a (?standards track?) RFC > > defining how to dereference. > > > > Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Monday, July 31, 2006 6:19 PM > > > To: Rosen, Brian; IETF SIP List > > > Cc: GEOPRIV > > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > > dereferencemechanism defined > > > > > > Not true > > > > > > "> This is NOT the discussion of what the ABNF of the location > header > > > looks > > > > like (although it would NOT have http/https in it for sure if we > > agree > > > > that an HTTP dereference protocol is a separate draft)." > > > > > > This is a discussion on ABNF and what the document contains, and to > > that > > > extent they are not separable. > > > The consensus has been, do not restrict the ABNF, keep the > discussion > > in > > > the document about references limited. I am failing to understand > why > > you > > > can't accept that. > > > > > > > > > > > > ________________________________ > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > Sent: Mon 31/07/2006 5:05 PM > > > To: Winterbottom, James; IETF SIP List > > > Cc: GEOPRIV > > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > > dereferencemechanism defined > > > > > > > > > > > > Please don't change the subject, I understand the controversy on > > > constraining the ABNF. I tried (apparently without success) to > > separate > > > those issues. > > > > > > I'm asking if anyone objects to NOT mentioning HTTP in any way with > > > respect to dereferencing URIs carried by the Location header. That > is > > > the only question I asked. > > > > > > I'm not trying to evade the constrained ABNF issue, and I'm not > > implying > > > anything tricky. I simply want to know if it's okay if we leave > > > anything that deals specifically with HTTP and the Location header > URI > > > to another document. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: Monday, July 31, 2006 5:55 PM > > > > To: Rosen, Brian; IETF SIP List > > > > Cc: GEOPRIV > > > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > > > dereferencemechanism defined > > > > > > > > Brian, > > > > > > > > Your second paragraph re-opens the sore I am afraid. > > > > A large number of people have agreed with Henning's statements and > > > these > > > > are clear: > > > > 1) Do not constrain the ABNF > > > > 2) Provide minimal description of the reference function. > > > > > > > > If you insist on saying then that the ABNF will be restricted if > > there > > > is > > > > not matching text, then I think it unlikely that you will reach a > > > > consensus. > > > > > > > > Cheers > > > > James > > > > > > > > ________________________________ > > > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > Sent: Mon 31/07/2006 8:38 AM > > > > To: IETF SIP List > > > > Cc: GEOPRIV > > > > Subject: [Geopriv] Does Location-Conveyance have an HTTP > > > > dereferencemechanism defined > > > > > > > > > > > > > > > > I have lost track of where we stand on whether the only mentioned > > URI > > > > schemes in location-conveyance are sip/sips/pres. I "think" we > have > > > > agreed that an HTTP/HTTPS dereference is in a separate document, > but > > > I'm > > > > not sure. > > > > > > > > This is NOT the discussion of what the ABNF of the location header > > > looks > > > > like (although it would NOT have http/https in it for sure if we > > agree > > > > that an HTTP dereference protocol is a separate draft). > > > > > > > > If you think location-conveyance DOES have HTTP dereference text > in > > > it, > > > > please say so, and please explain why you would not be satisfied > if > > > > there were a separate draft on the subject. > > > > > > > > Brian > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > [mf2] > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 19:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7h7o-0007Bw-7w; Mon, 31 Jul 2006 19:24:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7h7m-0007Bb-Bc; Mon, 31 Jul 2006 19:24:38 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7h7l-000165-Np; Mon, 31 Jul 2006 19:24:38 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G7h7Y-0003P7-TD; Mon, 31 Jul 2006 18:24:28 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "Rosen, Brian" , "'Dawson, Martin'" , "'IETF SIP List'" Date: Mon, 31 Jul 2006 19:24:24 -0400 Message-ID: <04a501c6b4f8$7c7e2a10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca0pplgmsITWnO0QY2zuklnycrsOwARWrZNAAAd3gAAALmFiwAAITRAAADUOHAAABhe8AAAqqVSAAAy7GA= X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae Cc: 'GEOPRIV' Subject: [Sip] RE: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org No James, the two threads are not linked. The first asks if there is any reference to HTTP use in dereferencing. The other discusses what the text, and the resulting ABNF says about dereferencing in general. Note in the message below, the token "http" does not appear, yet the text is readable. IF we were to include an http based dereferencing protocol in location conveyance AND we were to have a more semantically correct ABNF, THEN you would see HTTP in the list of protocols. However, you can answer the questions independently without any problem. Henning said we should not syntactically limit the ABNF. The "more specific" ABNF directly addresses that concern, and Jeroen's concern about diagnostics by including AbsoluteURI as an alternative. I'm bowing to list consensus on strictly limiting the ABNF. Let's get back to the question, which in this thread is "what does the text say about what can appear in the Location URI?" Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, July 31, 2006 7:09 PM > To: Rosen, Brian; Dawson, Martin; IETF SIP List > Cc: GEOPRIV > Subject: RE: [Geopriv] URI restrictions in location conveyance,was Does > Location-Conveyance have an HTTP dereferencemechanism defined > > Brian, > > So the two things are linked then? > > It is my belief that the consensus is in favour of what Henning suggested, > and that is what I would like. > Perhaps you would like to include precisely that position in your next > quest for consensus, rather than trying to re-word it and losing the > intent. > > Cheers > James > > ________________________________ > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Mon 31/07/2006 6:01 PM > To: Dawson, Martin; Winterbottom, James; IETF SIP List > Cc: GEOPRIV > Subject: RE: [Geopriv] URI restrictions in location conveyance,was Does > Location-Conveyance have an HTTP dereferencemechanism defined > > > > Sure, and so does: "Any URI can be used". That isn't necessarily a good > thing. > > If the text is like the "this document describes how you use > sip/sips/pres" then the ABNF I suggested is more appropriate. > > Any ABNF can be significantly reduced if the only thing you are trying > to convey with it is strict syntactic compliance. No significant > document with large hunks of ABNF in the IETF does that. We almost > always try to make the ABNF show as much of the semantic meaning as is > reasonable. If you follow the SIP threads, there are several messages a > month whose answer starts: > "you can't look at the ABNF alone, you have to read the text". To me, > this is a document failure, unless the ABNF was has to be so ugly to be > completely correct it fails to communicate. Alas, that happens. But if > it is possible to simply communicate the semantics in the ABNF, then it > is appropriate to do so. > > You can use the "token" construction a whole lot more than we do if all > you want is syntax checking. > > Lots of examples in 3261: > Priority = "Priority" HCOLON priority-value > priority-value = "emergency" / "urgent" / "normal" > / "non-urgent" / other-priority > other-priority = token > > > Contact = ("Contact" / "m" ) HCOLON > ( STAR / (contact-param *(COMMA contact-param))) > contact-param = (name-addr / addr-spec) *(SEMI contact-params) > name-addr = [ display-name ] LAQUOT addr-spec RAQUOT > addr-spec = SIP-URI / SIPS-URI / absoluteURI > > Let's settle on the words first. The ABNF will follow. > > Brian > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Monday, July 31, 2006 6:48 PM > > To: Rosen, Brian; Winterbottom, James; IETF SIP List > > Cc: GEOPRIV > > Subject: RE: [Geopriv] URI restrictions in location conveyance,was > Does > > Location-Conveyance have an HTTP dereferencemechanism defined > > > > Just using absoluteuri seems like the complete simplification... > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > Sent: Tuesday, 1 August 2006 8:44 AM > > > To: Winterbottom, James; IETF SIP List > > > Cc: GEOPRIV > > > Subject: RE: [Geopriv] URI restrictions in location conveyance,was > > Does > > > Location-Conveyance have an HTTP dereferencemechanism defined > > > > > > Can't let go can you? I changed the subject line to start a > different > > > thread. I'd still like the answer to the original thread. > > > > > > There are two separable issues with respect to the ABNF. The > > syntactic > > > and the semantic. > > > > > > The syntactic issues could be dealt with by saying: > > > > > > location-param = LAQUOT loc-URI RAQUOT *( SEMI loc-param ) > > > ;cid-url from RFC2392, SIP/SIPS-URI from RFC3261, PRES-URI from > > RFC3859 > > > ;Absolute URI from RFC3261 > > > loc-URI = cid-uri / SIP-URI / SIPS-URI / PRES-URI / AbsoluteURI > > > > > > This answers Henning and Jeroen's objection to strictly limiting the > > > ABNF. > > > The alternative is to just use AbsoluteURI. > > > > > > I guess the question is, what does the text say? I can make the ABNF > > > match what the text says. > > > > > > Does the text say: any URI can appear in the location header, > entities > > > must use some undefined mechanism to maintain interoperability. > > > > > > Does it say: location dereferencing is a "using protocol" as defined > > in > > > geopriv requirements. Any URI found in the location header MUST > meet > > > the requirements of a using protocol. > > > > > > Does it say: This document describes the use of SIP and SIPS as a > > > dereferencing protocol (and the use of a pres: uri if the resolution > > of > > > the pres: scheme in the referenced domain is to a presence service > > using > > > the sip/sips protocol). All entities using the Location header MUST > > > support SIP dereferencing. > > > > > > Does it say (if the paragraph immediately above is there): Other > > > protocols used for dereferencing MUST have a (?standards track?) RFC > > > defining how to dereference. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: Monday, July 31, 2006 6:19 PM > > > > To: Rosen, Brian; IETF SIP List > > > > Cc: GEOPRIV > > > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > > > dereferencemechanism defined > > > > > > > > Not true > > > > > > > > "> This is NOT the discussion of what the ABNF of the location > > header > > > > looks > > > > > like (although it would NOT have http/https in it for sure if we > > > agree > > > > > that an HTTP dereference protocol is a separate draft)." > > > > > > > > This is a discussion on ABNF and what the document contains, and > to > > > that > > > > extent they are not separable. > > > > The consensus has been, do not restrict the ABNF, keep the > > discussion > > > in > > > > the document about references limited. I am failing to understand > > why > > > you > > > > can't accept that. > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > Sent: Mon 31/07/2006 5:05 PM > > > > To: Winterbottom, James; IETF SIP List > > > > Cc: GEOPRIV > > > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > > > dereferencemechanism defined > > > > > > > > > > > > > > > > Please don't change the subject, I understand the controversy on > > > > constraining the ABNF. I tried (apparently without success) to > > > separate > > > > those issues. > > > > > > > > I'm asking if anyone objects to NOT mentioning HTTP in any way > with > > > > respect to dereferencing URIs carried by the Location header. > That > > is > > > > the only question I asked. > > > > > > > > I'm not trying to evade the constrained ABNF issue, and I'm not > > > implying > > > > anything tricky. I simply want to know if it's okay if we leave > > > > anything that deals specifically with HTTP and the Location header > > URI > > > > to another document. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > > Sent: Monday, July 31, 2006 5:55 PM > > > > > To: Rosen, Brian; IETF SIP List > > > > > Cc: GEOPRIV > > > > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > > > > dereferencemechanism defined > > > > > > > > > > Brian, > > > > > > > > > > Your second paragraph re-opens the sore I am afraid. > > > > > A large number of people have agreed with Henning's statements > and > > > > these > > > > > are clear: > > > > > 1) Do not constrain the ABNF > > > > > 2) Provide minimal description of the reference function. > > > > > > > > > > If you insist on saying then that the ABNF will be restricted if > > > there > > > > is > > > > > not matching text, then I think it unlikely that you will reach > a > > > > > consensus. > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > ________________________________ > > > > > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > > Sent: Mon 31/07/2006 8:38 AM > > > > > To: IETF SIP List > > > > > Cc: GEOPRIV > > > > > Subject: [Geopriv] Does Location-Conveyance have an HTTP > > > > > dereferencemechanism defined > > > > > > > > > > > > > > > > > > > > I have lost track of where we stand on whether the only > mentioned > > > URI > > > > > schemes in location-conveyance are sip/sips/pres. I "think" we > > have > > > > > agreed that an HTTP/HTTPS dereference is in a separate document, > > but > > > > I'm > > > > > not sure. > > > > > > > > > > This is NOT the discussion of what the ABNF of the location > header > > > > looks > > > > > like (although it would NOT have http/https in it for sure if we > > > agree > > > > > that an HTTP dereference protocol is a separate draft). > > > > > > > > > > If you think location-conveyance DOES have HTTP dereference text > > in > > > > it, > > > > > please say so, and please explain why you would not be satisfied > > if > > > > > there were a separate draft on the subject. > > > > > > > > > > Brian > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > This message is for the designated recipient only and may > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > If you have received it in error, please notify the sender > > > > > immediately and delete the original. Any unauthorized use of > > > > > this email is prohibited. > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > [mf2] > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > [mf2] > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 21:05:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ifS-0000o2-U4; Mon, 31 Jul 2006 21:03:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ifS-0000nu-5P; Mon, 31 Jul 2006 21:03:30 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ifQ-0000o7-UK; Mon, 31 Jul 2006 21:03:30 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 31 Jul 2006 21:03:34 -0400 id 0158810F.44CEA866.000012C0 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4DA40460-5855-4BC2-8605-48F9F8EC7BAC@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined Date: Mon, 31 Jul 2006 21:03:22 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IETF SIP List , "Rosen, Brian" , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 31, 2006, at 6:19 PM, Winterbottom, James wrote: > Not true > > "> This is NOT the discussion of what the ABNF of the location header > looks >> like (although it would NOT have http/https in it for sure if we >> agree >> that an HTTP dereference protocol is a separate draft)." > > This is a discussion on ABNF and what the document contains, and to > that extent they are not separable. > The consensus has been, do not restrict the ABNF, keep the > discussion in the document about references limited. I am failing > to understand why you can't accept that. Brian is right. They are not the same issue, atleast they do not have to be. From where I sit, I think the consensus is: - do not constrain the ABNF - HTTP goes in another document Keep in mind, my hat is labeled "GEOPRIV" and this is a SIP document. -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 21:13:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7in4-0004oC-2P; Mon, 31 Jul 2006 21:11:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7in2-0004h5-Ut; Mon, 31 Jul 2006 21:11:20 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7in1-0001Rk-Mh; Mon, 31 Jul 2006 21:11:20 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 20:11:17 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 31 Jul 2006 20:11:17 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 20:11:16 -0500 Message-ID: From: "Winterbottom, James" To: "Andrew Newton" Date: Mon, 31 Jul 2006 20:11:16 -0500 Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 01 Aug 2006 01:11:16.0396 (UTC) FILETIME=[636A7EC0:01C6B507] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 References: <4DA40460-5855-4BC2-8605-48F9F8EC7BAC@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined Thread-Index: Aca1Bk2m52XywjPKRbKMlYnnQ8ydYAAADyjg X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: IETF SIP List , "Rosen, Brian" , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Andy, =20 That is all I have asked for, do not constrain the ABNF. If "how I use HTTP= as a reference" goes in a different document that is fine providing the AB= NF is not constrained in the conveyance specification. This is not how I re= ad Brian's statement below: =20 "This is NOT the discussion of what the ABNF of the location header looks like (although it would NOT have http/https in it for sure if we agree that an HTTP dereference protocol is a separate draft)." =20 Which to me clearly says the ABNF will be restrict to exclude HTTP/HTTPS if= there is agreement that the conveyance draft doesn't have specific text on= how to deference an HTTP reference. =20 Cheers James ________________________________ From: Andrew Newton [mailto:andy@hxr.us] Sent: Mon 31/07/2006 8:03 PM To: Winterbottom, James Cc: Rosen, Brian; IETF SIP List; GEOPRIV Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dere= ferencemechanism defined On Jul 31, 2006, at 6:19 PM, Winterbottom, James wrote: > Not true > > "> This is NOT the discussion of what the ABNF of the location header > looks >> like (although it would NOT have http/https in it for sure if we=20 >> agree >> that an HTTP dereference protocol is a separate draft)." > > This is a discussion on ABNF and what the document contains, and to=20 > that extent they are not separable. > The consensus has been, do not restrict the ABNF, keep the=20 > discussion in the document about references limited. I am failing=20 > to understand why you can't accept that. Brian is right. They are not the same issue, atleast they do not=20 have to be. From where I sit, I think the consensus is: - do not constrain the ABNF - HTTP goes in another document Keep in mind, my hat is labeled "GEOPRIV" and this is a SIP document. -andy ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 31 21:16:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7iqT-0006uD-GP; Mon, 31 Jul 2006 21:14:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7iqS-0006u5-I1; Mon, 31 Jul 2006 21:14:52 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7iqO-0001oa-AS; Mon, 31 Jul 2006 21:14:52 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Mon, 31 Jul 2006 21:14:55 -0400 id 0158810F.44CEAB0F.000014AB In-Reply-To: References: <4DA40460-5855-4BC2-8605-48F9F8EC7BAC@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80BD9605-F287-487E-AF4A-5697A50AB8E4@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined Date: Mon, 31 Jul 2006 21:14:44 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IETF SIP List , "Rosen, Brian" , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 31, 2006, at 9:11 PM, Winterbottom, James wrote: > Hi Andy, > > That is all I have asked for, do not constrain the ABNF. If "how I > use HTTP as a reference" goes in a different document that is fine > providing the ABNF is not constrained in the conveyance > specification. This is not how I read Brian's statement below: > > "This is NOT the discussion of what the ABNF of the location header > looks > like (although it would NOT have http/https in it for sure if we agree > that an HTTP dereference protocol is a separate draft)." > > Which to me clearly says the ABNF will be restrict to exclude HTTP/ > HTTPS if there is agreement that the conveyance draft doesn't have > specific text on how to deference an HTTP reference. > > Cheers > James Please keep in mind that this does not stop the draft from using MUST/ SHOULD language from stipulating "the URI MUST be a GEOPRIV standards track using protocol." -andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip