From daemon@ns.ietf.org Fri Feb 1 00:07:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22984 for ; Fri, 1 Feb 2002 00:07:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA13923 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 00:07:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12980; Thu, 31 Jan 2002 23:43:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12950 for ; Thu, 31 Jan 2002 23:43:33 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21783 for ; Thu, 31 Jan 2002 23:43:27 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g114hZ6Y010541; Thu, 31 Jan 2002 23:43:35 -0500 (EST) Message-ID: <3C5A1CCE.66FEC327@dynamicsoft.com> Date: Thu, 31 Jan 2002 23:42:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sanjoy Sen CC: sip@ietf.org Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks References: <933FADF5E673D411B8A30002A5608A0E0118788D@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sanjoy Sen wrote: > > > There is no difference between early media and media. Local alerting > > would presumably take place as a local implementation choice once a > > suitable provisional response (180, typically) has been received to > > indicate that the far end is, in fact, ringing. It would > > continue until > > the establishment of the session, early or otherwise. As a > > result, a 183 > > w/SDP finalizes the establishment of the session, and so that > > would stop > > any local ringback. > > > > I suppose that suspension of the session, with port zero, before the > > dialog is completed, would be a way to signal a UAC to revert back to > > local ringback, if that functionality was needed. > > Yes, but there would a problem with general PSTN interworking. When the > MGC receives an ACM/Alerting message, it has no way to definitively > infer whether the PSTN would generate early media (e.g., remote > Ring-back or announcement). So, on receipt of ACM, the MGC may send an > 180 (as you said) to the SIP phone which starts playing local ringing > (by local implementation choice), but then any early media which might > be coming through the gateway will be lost (the EM flow can start > anytime after the ACM is issued). I was wondering what kind of rules do > we need to specify to solve this issue and whether its at all solvable > by rules alone. I don't get the problem. Once the gateway receives media, it can establish the session by sending an offer in an UPDATE. Also, I thought there was some bit somewhere in the ACM which indicated that ringback was inband... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Fri Feb 1 00:49:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23566 for ; Fri, 1 Feb 2002 00:49:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA15370 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 00:49:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14342; Fri, 1 Feb 2002 00:20:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14311 for ; Fri, 1 Feb 2002 00:20:24 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23127 for ; Fri, 1 Feb 2002 00:20:21 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 7DD351E036 for ; Fri, 1 Feb 2002 00:20:21 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id AAA04635; Fri, 1 Feb 2002 00:20:18 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id AAA00240; Fri, 1 Feb 2002 00:22:15 -0500 (EST) Date: Fri, 1 Feb 2002 00:22:15 -0500 (EST) Message-Id: <200202010522.AAA00240@fish.research.att.com> To: sip@ietf.org Subject: [Sip] Comments on bis-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'm continuing a detailed review of bis-06, but wanted to post the comments so far, so that they can get into bis-07. Line numbers refer to the pdf version. Minor technical issues and comments: section 6 Definition of Proxy-Server should make a reference to Back-to-Back-UA for a element that goes beyond the specific parts of the request message that a proxy is allowed to rewrite before forwarding. Section 7, lines 758-9 The definition of notation [HX.Y] is buried here. I suggest the notation be defined in section 3, Terminology. Section 7.3.1, line 870 The MUST in this statement is stating a requirement on future extensions, not something that is testable for this specification. The statement is fine as a lower case must, but not as a spec word. Section 8.1.1.9 (line 1072) and 8.2.4 (line 1322) The need for option tags being defined in standards track RFCs is discussed in draft-tsvarea-sipchange-00. As I stated at IETF52, there are problems with this requirement related to various carrier- required functions that will not be standardized in IETF, like electronic surveillance, which was not considered in sipchange-00. I'm still looking forward to sipchange-01, and the last-call promised on the revised version, to resolve this problem. In the meantime, I do not believe 2543bis needs to duplicate the requirement, however it may be resolved. I'd suggest wording like "The option tags listed MUST only refer to extensions defined in accordance with [ref to draft-tsvarea-sipchange-xx]." to replace paragraph starting in 1072, and the last sentence at line 1322. Section 18.2, lines 3451-3455 This paragraph should at lease mention that a forking request may lead to multiple provisional responses, each sent reliably, which requires the UAC to maintain a separate value of RSeq for each dialog resulting from the initial request. Section 26.2, line 5733, and lines 6781-3 The call flow examples draft has expired, but that is a separate issue. As for bis, I question whether this should be a normative reference. There is no text that separates normative from informative refs, so the assumption will be that all are normative. While a number of the references really are just informative, I have no problem with them except [39]. Editorial nits: line 22: ontop -> on top Figure 1: corrupted in pdf version line 1135,1138,1142 quotes around the sip urls are corrupted line 2056: 2xx -> All 2xx (i.e. don't start sentence with "2xx") line 2059: "usage for construction offers and answers" -> "usage for construction __of__ offers and answers" line 2319: since there is no 15.2, drop the 15.1 heading and promote 15.1.1 and 15.1.2 to 15.1 and 15.2 line 2864: wrong font for "OPEN ISSUE #7", but hopefully that will be removed in next version line 3401: "MUSTinclude" -> "MUST include" line 3430: "MUSTbe" -> "MUST be" line 5734-5: dreg? line 5848: illegal character in front of "From" in third line line 5854: excessive space in front of "non-urgent" on 4th line line 5911: "optio" -> "option" line 5913: need closing right bracket at end of line. Probably the note is to the RFC Editor, not IANA. That's the list so far. More to come. Bill Marshall wtm@research.att.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 daemon@ns.ietf.org Fri Feb 1 01:45:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24172 for ; Fri, 1 Feb 2002 01:44:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA26371 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 01:44:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19523; Fri, 1 Feb 2002 01:07:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19372 for ; Fri, 1 Feb 2002 01:07:40 -0500 (EST) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23762 for ; Fri, 1 Feb 2002 01:07:35 -0500 (EST) From: sdhar@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hss.hns.com (8.11.2/8.11.2) with SMTP id g115qkl19713; Fri, 1 Feb 2002 11:22:47 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B53.0020C561 ; Fri, 1 Feb 2002 11:27:56 +0530 X-Lotus-FromDomain: HSSBLR To: Jonathan Rosenberg cc: Sanjoy Sen , sip@ietf.org Message-ID: <65256B53.0020C4C9.00@sampark.hss.hns.com> Date: Fri, 1 Feb 2002 11:27:54 +0530 Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Backwards Call Indicator (BCI) parameter of the ACM indicates that interworking has been encountered (generally designating that the ISUP network sending the ACM is interworking with a less sophisticated network which cannot support cause codes), then there may be in-band announcements of call status such as an audible busy tone or caller intercept message. rgds Sumit Hughes Software Systems Jonathan Rosenberg on 02/01/2002 10:12:54 AM To: Sanjoy Sen cc: sip@ietf.org (bcc: Sumit Dhar/HSSBLR) Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks Sanjoy Sen wrote: > > > There is no difference between early media and media. Local alerting > > would presumably take place as a local implementation choice once a > > suitable provisional response (180, typically) has been received to > > indicate that the far end is, in fact, ringing. It would > > continue until > > the establishment of the session, early or otherwise. As a > > result, a 183 > > w/SDP finalizes the establishment of the session, and so that > > would stop > > any local ringback. > > > > I suppose that suspension of the session, with port zero, before the > > dialog is completed, would be a way to signal a UAC to revert back to > > local ringback, if that functionality was needed. > > Yes, but there would a problem with general PSTN interworking. When the > MGC receives an ACM/Alerting message, it has no way to definitively > infer whether the PSTN would generate early media (e.g., remote > Ring-back or announcement). So, on receipt of ACM, the MGC may send an > 180 (as you said) to the SIP phone which starts playing local ringing > (by local implementation choice), but then any early media which might > be coming through the gateway will be lost (the EM flow can start > anytime after the ACM is issued). I was wondering what kind of rules do > we need to specify to solve this issue and whether its at all solvable > by rules alone. I don't get the problem. Once the gateway receives media, it can establish the session by sending an offer in an UPDATE. Also, I thought there was some bit somewhere in the ACM which indicated that ringback was inband... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 1 02:09:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02595 for ; Fri, 1 Feb 2002 02:09:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA27404 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 02:09:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26567; Fri, 1 Feb 2002 01:53:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26536 for ; Fri, 1 Feb 2002 01:53:36 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24268 for ; Fri, 1 Feb 2002 01:53:34 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g116rNX4020551; Fri, 1 Feb 2002 07:53:23 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g116rNr6011143; Fri, 1 Feb 2002 08:53:23 +0200 (EET) Message-ID: <3C5A3B61.932312@lmf.ericsson.se> Date: Fri, 01 Feb 2002 08:53:21 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Rohan Mahy , Alan Johnston , "'Sanjoy Sen'" , sip@ietf.org Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks References: <200201311951.ACK52219@imop.cisco.com> <3C59AF9F.FA0E8798@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I have a small question of the use of PRACK for the offer purpose. Assume that UA1 calls UA2. UA1 UA2 ========================== -----INVITE (offer 1)--> <----183 (answer 1)----- -----PRACK (offer 2)---> Now, when UA2 receives the PRACK it will probably alarm the user, ie the UA2 phone will start ringing. Then, if (for whatever reason) the 200 to PRACK does not reach UA1, and UA2 answers, is UA2 allowed to send the 200 to INVITE before the 200 to PRACK has reached UA1? This is how it most likely would work in "normal" PRACK scenarios, so... (If UPDATE is used, UA1 would not send UPDATE before it has received 200 to PRACK, so when UA2 receives the UPDATE and alarms the user the PRACK transaction would be finished.) Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > Rohan Mahy wrote: > > > > > >We need to discuss that further. Unify indicated that the > > preference was > > >not to allow it in PRACK. I sent a note to the list already > > describing > > >the reason. The reason is that you may need to reject an > > offer if it > > >occurs in the middle of an outstanding offer (i.e., glare > > prevention). > > >This means that if A sends a COMET to B with an offer, and B > > sends a > > >PRACK to a previous 1xx with an offer to A, A will need to > > reject the > > >PRACK for glare prevention. > > > > Would it help to add an additional restriction: Don't send a > > new offer if you are still waiting for acknowledgement of a > > message you sent in the same dialog. > > It would help, yes. Its broader than you need. I am trying to think if > there would be an negative impacts from this restriction. None I can > think of off hand, though. > > > > > A would be forbidden to send an offer in a COMET (or a 200 > > for the original INVITE) until its provisionals where > > acknowledged. > > As a specific instance of your rule, yes. We could also make it simpler, > which is that you can't send an offer in UPDATE (I think we have > consensus to call it UPDATE) if you have a reliable provisional response > outstanding. > > > > > I think sending offers/answers in PRACK is even more useful > > in the 3pcc early media case. > > > > basically I prefer this: > > > > INVITE (no SDP) --> > > <-- 18x (offer1) > > PRACK (answer1) --> > > <-- 200 (PRACK) > > <-- 200 (INVITE) > > ACK --> > > > > to this: > > > > INVITE (no SDP) --> > > <-- 18x (offer1) > > PRACK --> > > <-- 200 (PRACK) > > COMET (answer1) --> > > <-- 200 (COMET) > > <-- 200 (INVITE) > > ACK --> > > > > (which is technically forbidden by rule 4 above) > > Right, the benefit is the savings of a transaction. > > OK, I'll bite. I think the 3g guys would prefer this as well, since I > suspect the case of 1-of-N codecs + manyfolks will be a common one. > There, without sending SDP in PRACK, you'd need to to this: > > INVITE (SDP offer w/ many codecs + inactive + precon) ------> > <----- 183 (SDP answer w/ one codec + inactive + precon)----- > PRACK------> > <----200 PRACK > COMET (SDP offer w/ one codec + sendrecv + precon) -----------> > <-------200 COMET (SDP answer w/ one codec + sendrecv + precon) > <-----resource reservation--------> > COMET (SDP offer w/ one codec + sendercv + conditions met)-------> > <-------------200 COMET (SDP answer w/ one codec + sendrecv + conditions > met) > <---------180------------------------------------------------- > PRACK---------------------> > <-------------200 PRACK---- > <-----------200 > -----ACK> > > This is an extra pair of messages (an extra COMET) that is not currently > in the flows in 24.228 which would need to be added. Whilst it *doesn't* > increase call setup latency, it uses more bw on the air interface. Yeah, > compression will help some, but I bet theyd prefer to avoid another > transaction to an already overly complex setup flow. Of course, I think > its even easier to avoid preconditions altogether, but let us not > discuss that. > > So, let me ask for consensus on allowing the o/a exchanges in PRACK in > addition to UPDATE, subject to some kind of constraint to avoid the > problem I mention of glare on the PRACK. > > Thanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 1 02:32:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03095 for ; Fri, 1 Feb 2002 02:32:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28409 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 02:32:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27473; Fri, 1 Feb 2002 02:10:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27442 for ; Fri, 1 Feb 2002 02:10:42 -0500 (EST) Received: from hindon.hss.co.in ([202.54.26.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02887 for ; Fri, 1 Feb 2002 02:10:38 -0500 (EST) From: mielias@hss.hns.com Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id g117AwA10838; Fri, 1 Feb 2002 12:40:58 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256B53.0027494B ; Fri, 1 Feb 2002 12:39:06 +0530 X-Lotus-FromDomain: HSS To: sdhar@hss.hns.com cc: Jonathan Rosenberg , Sanjoy Sen , sip@ietf.org Message-ID: <65256B53.0027475B.00@sandesh.hss.hns.com> Date: Fri, 1 Feb 2002 12:43:00 +0530 Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi , The inband information indicator in OBCI (optional backward call indicator) of ACM indicates that the inband information is present from SCN. Based on this information the gateway switches the reverse media path and sends the early media answer sdp in 183 and the announcements will be played in the sip terminal. Otherwise the gateway is going to respond with 180 and the local rbt will be applied in the SIP terminal. Rgds, -Elias sdhar@hss.hns.com on 02/01/2002 11:27:54 AM To: Jonathan Rosenberg cc: Sanjoy Sen , sip@ietf.org (bcc: Mohamed Ibrahim Elias/HSS) Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks Backwards Call Indicator (BCI) parameter of the ACM indicates that interworking has been encountered (generally designating that the ISUP network sending the ACM is interworking with a less sophisticated network which cannot support cause codes), then there may be in-band announcements of call status such as an audible busy tone or caller intercept message. rgds Sumit Hughes Software Systems Jonathan Rosenberg on 02/01/2002 10:12:54 AM To: Sanjoy Sen cc: sip@ietf.org (bcc: Sumit Dhar/HSSBLR) Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks Sanjoy Sen wrote: > > > There is no difference between early media and media. Local alerting > > would presumably take place as a local implementation choice once a > > suitable provisional response (180, typically) has been received to > > indicate that the far end is, in fact, ringing. It would > > continue until > > the establishment of the session, early or otherwise. As a > > result, a 183 > > w/SDP finalizes the establishment of the session, and so that > > would stop > > any local ringback. > > > > I suppose that suspension of the session, with port zero, before the > > dialog is completed, would be a way to signal a UAC to revert back to > > local ringback, if that functionality was needed. > > Yes, but there would a problem with general PSTN interworking. When the > MGC receives an ACM/Alerting message, it has no way to definitively > infer whether the PSTN would generate early media (e.g., remote > Ring-back or announcement). So, on receipt of ACM, the MGC may send an > 180 (as you said) to the SIP phone which starts playing local ringing > (by local implementation choice), but then any early media which might > be coming through the gateway will be lost (the EM flow can start > anytime after the ACM is issued). I was wondering what kind of rules do > we need to specify to solve this issue and whether its at all solvable > by rules alone. I don't get the problem. Once the gateway receives media, it can establish the session by sending an offer in an UPDATE. Also, I thought there was some bit somewhere in the ACM which indicated that ringback was inband... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 1 02:55:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03329 for ; Fri, 1 Feb 2002 02:55:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28934 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 02:55:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27788; Fri, 1 Feb 2002 02:24:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27752 for ; Fri, 1 Feb 2002 02:24:27 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02980 for ; Fri, 1 Feb 2002 02:24:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g117OU6Y010657; Fri, 1 Feb 2002 02:24:30 -0500 (EST) Message-ID: <3C5A4282.AA5FE7F2@dynamicsoft.com> Date: Fri, 01 Feb 2002 02:23:46 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Rohan Mahy , Alan Johnston , "'Sanjoy Sen'" , sip@ietf.org Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks References: <3C5A3B61.932312@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > I have a small question of the use of PRACK for the offer purpose. > > Assume that UA1 calls UA2. > > UA1 UA2 > ========================== > > -----INVITE (offer 1)--> > > <----183 (answer 1)----- > > -----PRACK (offer 2)---> > > Now, when UA2 receives the PRACK it will probably alarm the user, ie the > UA2 phone will start ringing. Huh? What does PRACK have to do with ringing? > > Then, if (for whatever reason) the 200 to PRACK does not reach UA1, and > UA2 answers, is UA2 allowed to send the 200 to INVITE before the 200 to > PRACK has reached UA1? Of course. UA2 doesn't know that its 200-PRACK hasn't reached UA1. From UA1's perspective, it has an offer outstanding in PRACK, and it knows the answer will arrive in the 200-PRACK. If the 2xx to the INVITE should arrive before the 200-PRACK, UA1 knows it has to be an offer. If this had happened through re-INVITEs, that offer would be rejected because of glare. However, we can't reject the 2xx to INVITE. In this case, we can handwave that problem away, by stating that final responses to the invite always come after any 200-PRACK. However, that doesn't extend to provisional responses and UPDATE from UAS back to UAC. There, we have Rohan's rule, which is that you can't send an UPDATE when you have an unacknowledged 1xx outstanding. Its a bit complicated, I admit; I need to think about a good way to express the ordering and glare detection rules for these cases, but I think it works... > This is how it most likely would work in "normal" > PRACK scenarios, so... > > (If UPDATE is used, UA1 would not send UPDATE before it has received 200 > to PRACK, why? I disagree with that. If we didn't allow SDP in PRACKs, we really, really need to allow UPDATE and PRACK to go in parallel to avoid call setup latencies. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 1 03:48:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04454 for ; Fri, 1 Feb 2002 03:48:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA02455 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 03:48:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00274; Fri, 1 Feb 2002 03:22:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00239 for ; Fri, 1 Feb 2002 03:22:54 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02130 for ; Fri, 1 Feb 2002 03:22:51 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g118MWX4004784; Fri, 1 Feb 2002 09:22:32 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g118MVr6017661; Fri, 1 Feb 2002 10:22:31 +0200 (EET) Message-ID: <3C5A5044.B6CD3292@lmf.ericsson.se> Date: Fri, 01 Feb 2002 10:22:28 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Rohan Mahy , Alan Johnston , "'Sanjoy Sen'" , sip@ietf.org Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks References: <3C5A3B61.932312@lmf.ericsson.se> <3C5A4282.AA5FE7F2@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, My comments inline. >>I have a small question of the use of PRACK for the offer purpose. >> >>Assume that UA1 calls UA2. >> >>UA1 UA2 >>========================== >> >>-----INVITE (offer 1)--> >> >><----183 (answer 1)----- >> >>-----PRACK (offer 2)---> >> >>Now, when UA2 receives the PRACK it will probably alarm the user, ie the >>UA2 phone will start ringing. > >Huh? What does PRACK have to do with ringing? [CH] Nothing. It was just an assumption that the called party won't be alarmed before some kind of negoatiation between the nodes is done (compare to the resource reservation mechanism in manyfolks). But, ok, we can assume that the INVITE triggers the ringing. >>Then, if (for whatever reason) the 200 to PRACK does not reach UA1, and >>UA2 answers, is UA2 allowed to send the 200 to INVITE before the 200 to >>PRACK has reached UA1? >Of course. UA2 doesn't know that its 200-PRACK hasn't reached UA1. [CH] No, but if it keeps receving re-transmits of the PRACK it can assume so. >From UA1's perspective, it has an offer outstanding in PRACK, and it >knows the answer will arrive in the 200-PRACK. If the 2xx to the INVITE >should arrive before the 200-PRACK, UA1 knows it has to be an offer. [CH] What if UA1 receives the 200-INVITE before it even receives the 183-INVITE (this can happen if the INVITE triggers the ringing, and the called party picks up the phone)? UA2 will probably stop re-transmitting the 183-INVITE after 200-INVITE has been sent, so UA1 may never get "answer 1". Even if UA1 DOES receive the 183-INVITE later it probably won't care about it since it has already received the 200-INVITE. I don't think we can assume that UA1 will keep waiting for the 183-INVITE after it has received 200-INVITE. Of course, if UA1 does receive the 200-INVITE (also including "answer 1") before it has received the 183-INVITE, it could ACK and then send a re-INVITE (see picture) with "offer 2", but the problem then is that both parties are trying to speak to each other while we're still negoatiating the codec... UA1 UA2 ------INVITE (offer 1)--> X<--183 (answer 1)- <-----200 (answer 1)----- ------ACK---------------> ------INVITE (offer 2)--> ... >If this had happened through re-INVITEs, that offer would be rejected >because of glare. However, we can't reject the 2xx to INVITE. In this >case, we can handwave that problem away, by stating that final responses >to the invite always come after any 200-PRACK. However, that doesn't >extend to provisional responses and UPDATE from UAS back to UAC. There, >we have Rohan's rule, which is that you can't send an UPDATE when you >have an unacknowledged 1xx outstanding. > >Its a bit complicated, I admit; I need to think about a good way to >express the ordering and glare detection rules for these cases, but I >think it works... > >>This is how it most likely would work in "normal" >>PRACK scenarios, so... >> >>(If UPDATE is used, UA1 would not send UPDATE before it has received 200 >>to PRACK, > >why? I disagree with that. If we didn't allow SDP in PRACKs, we really, >really need to allow UPDATE and PRACK to go in parallel to avoid call >setup latencies. So, why don't we? PRACK is only used to ack the 183, but UA1 still won't send the UPDATE before it has received the 183. So when UA2 receives the UPDATE it KNOWS UA1 has received the 183 - even if the PRACK transaction is still open... Regards, Christer Holmberg Ericsson 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 daemon@optimus.ietf.org Fri Feb 1 09:19:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23175 for ; Fri, 1 Feb 2002 09:19:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17135 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 09:19:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15829; Fri, 1 Feb 2002 08:59:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15799 for ; Fri, 1 Feb 2002 08:59:41 -0500 (EST) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22236; Fri, 1 Feb 2002 08:59:35 -0500 (EST) Received: from attrh1i.attrh.att.com ([135.71.62.10]) by almso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g11Dx1920662; Fri, 1 Feb 2002 08:59:04 -0500 (EST) Received: from OCCLUST03EVS1.ugd.att.com (135.71.164.10) by attrh1i.attrh.att.com (5.5.029) id 3C0BA3A5002E55B8; Fri, 1 Feb 2002 08:58:44 -0500 content-class: urn:content-classes:message Date: Fri, 1 Feb 2002 08:58:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Re: delta-encoding in HTTP to proposed standard X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcCd5oftjk180AmuEdWY+QAAOfyDF0NQJ53Q From: "Frost, Thomas F (Tom), ALIPM" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA15800 Subject: [Sip] AT&T IPR Statement Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit This declaration is being made pursuant to the provisions of IETF IPR Policy, Sections 10.3.1 and 10.3.2. This is to advise the IETF that AT&T believes it owns intellectual property that may relate to Internet Draft document " draft-ietf-sip-rfc2543bis-06", including United States Patent No. 6,324,279. To the extent that the technology discussed in this Internet Draft becomes an IETF Standard, and to the extent claims of AT&T's patents are required to implement the IETF Standard, AT&T agrees that, upon written request, AT&T will offer, on a nondiscriminatory basis, non-exclusive licenses on fair and reasonable terms under such patent claims to implement that IETF Standard. AT&T's willingness to grant such licenses is conditioned upon the prospective licensee granting a reciprocal license to AT&T under any patents that the prospective licensee has to any technology required to implement that IETF Standard. > Written requests for licenses may be sent to: > > AT&T Intellectual Property Licensing Intellectual Property Vice President > 180 Park Avenue > Florham Park, NJ 07932 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 1 09:32:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23731 for ; Fri, 1 Feb 2002 09:32:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18049 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 09:32:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16642; Fri, 1 Feb 2002 09:09:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16595 for ; Fri, 1 Feb 2002 09:09:15 -0500 (EST) Received: from localhost (s211-33-80-128.thrunet.ne.kr [211.33.80.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22484 for ; Fri, 1 Feb 2002 09:09:08 -0500 (EST) Message-Id: <200202011409.JAA22484@ietf.org> Reply-To: thanksk@hitel.net From: 실크스타 To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 1 Feb 2002 23:06:41 +0900 Subject: [Sip] 피부기초호장 NO 비만다이어트NO Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org

안녕하셨습니까? 실크스타바이오입니다.
일찍이 괴테는 "인간이 자연에서 멀어진 만큼 병과 가까워진다" 고 했습니다.  이처럼 위대한 선현들이 발견한 지혜는 현대인에게 암시하는 바가 크다고 생각합니다. 
발명 특허 신물질을 기초로
●20g 미용분말
●특수미용액
●SS농축음료
●특수분말 응용제
피부미용과 각종피부염, 반신욕 첨가제 및 팩, 미용수 등으로 가정에서 손수 만들어 사용할 수 있는 방법을 제시하며, 특성은 노폐물 및 독성배출, 항균 항염작용, 혈액순환의 개선으로 면역력을 상승시키며 인체가 스스로 치유할 수 있는 자연치유력을 만들어 주는 자연의학 측면의 상품입니다.  
---------------------------------
정보통신부 권고 사항에 의거 제목에 [광고]라고 표기한 광고 메일입니다.
수신을 원치 않으시면 수신거부를 눌러주세요

   
==================================
당신의 건강과 아름다운 피부를 지키는
 
실크스타바이오 www.silkstarbio.com
 
        Tel    : 055-547-8803
        Fax   : 055-551-3282
        E-mail: thanksk@hitel.net

_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 1 11:11:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27705 for ; Fri, 1 Feb 2002 11:11:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23433 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 11:11:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22132; Fri, 1 Feb 2002 10:51:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22103 for ; Fri, 1 Feb 2002 10:51:25 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27232 for ; Fri, 1 Feb 2002 10:51:20 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g11FpLW38092; Fri, 1 Feb 2002 07:51:21 -0800 (PST) To: "Peterson, Jon" Cc: "'Cullen Jennings'" , Michael Thomas , sip@ietf.org Subject: Re: [Sip] Summary of TLS discussion References: <70565611B164D511957A001083FCDD56CAAE59@VA02> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 01 Feb 2002 07:51:21 -0800 In-Reply-To: "Peterson, Jon"'s message of "Tue, 29 Jan 2002 13:03:19 -0600" Message-ID: Lines: 10 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org "Peterson, Jon" writes: > 1) TLS: Doesn't support UDP. Has an innate key exchange system. Use of TLS > with an application like SIP is fairly straightforward. A minimum profile > for authentication/integrity/encryption is provided in bis06 today. Opinions > to the contrary notwithstanding, it can probably be implemented in less than > 400K of code (a recent IEEE Comm's article claimed 100K). TLS can definitely be done in <100K. I know, since I've done it. I've heard reports of <50K but never verified them myself. -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 daemon@optimus.ietf.org Fri Feb 1 12:27:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04920 for ; Fri, 1 Feb 2002 12:27:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28909 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 12:27:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28071; Fri, 1 Feb 2002 12:12:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28040 for ; Fri, 1 Feb 2002 12:12:47 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04357 for ; Fri, 1 Feb 2002 12:12:43 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 1 Feb 2002 17:13:08 UT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Fri, 1 Feb 2002 17:13:59 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE01122526@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: Comments on bis-06 Thread-Index: AcGrQ9ajggaMIhp6TH6Rzm9ljFZrUw== From: "Jo Hornsby" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA28041 Subject: [Sip] Comments on bis-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Okay, so here are my (incomplete) comments on bis-06; like all the others, I wanted to get them out now so that they might actually be useful bearing-in-mind the Monday Deadline. As a general comment, every so-often, a paragraph seems to be inexplicably all bunched up line-wise; f.ex.: 1942 - 1944, 1982 - 1990, 2060 - 2064. (Obviously, the only concern here is that it offends my aesthetic sensibilities.) ( These are all comments based on the PDF: ) * 619: I find "A call stateful proxy is always stateful" just ever-so-slightly confusing. Maybe it would be helpful to add a paranthetical "transaction", a la "A call stateful proxy is always [transaction] stateful"? * 656: Just a corner case, but would it be better to say something like: "A proxy that receives all request from a client, even though it _may not be_ the server resolved by the Request-URI"? * 676: Should probably say "...the client to contact an alternate set of URIs" for true correctness. * 693: Shouldn't 6xx halt a sequential search, too? * 711: Random Blank Line. * 1040: I'd rather see something like "A UAC MUST insert a Max-Forwards header field into each request it originates. The value needs to be large enough to ensure that the request can traverse a reasonable number of proxies, and in the absence of local / network policy, or otherwise, SHOULD be 70". (Just slightly concerned at the mandatory nature of such a magically random figure.) * 1059: Section Link appears to be broken. * 1063: I think this conflicts with 1832 (and List Discussion, as I recall). * 1152: Isn't it possible for other types of event; e.g., no DNS records, ICMP? * 1177: Is the intention here really just "until a server responds"? I would have thought we were looking for a 2xx / 6xx. * 1674: Shouldn't this be step 7? * 1966: Random Blank Line. * 1985: Small Point, but why a 500? I would have thought that this would be treated as a client error, and thus 4xx? * 2251: Again with the 500 -> 4xx. * 2282: s/unbound/unbounded/ * 2328: Spurious Space Beginning Line. Finally, I feel compelled to do the atypical syncophancy bit. Unfortunately, due to some poor time management (and new seasons of Buffy Angel, of course), I never got around to a proper read of bis-05. So bis-06 is something of a revelation. And it really is such an improvement. Well, to be honest, before reading this, I was secure in my employment before, such that a Lego Desk seemed pretty inevitable; but now things are so well explained, I reckon you've made it such that any old Joe could walk in off the street and write a Proxy or whathaveyou. So thanks for that. Ah well, I guess it's back to TAPI. Damnit. - Jo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 1 12:29:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05014 for ; Fri, 1 Feb 2002 12:29:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28982 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 12:29:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27466; Fri, 1 Feb 2002 12:05:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27439 for ; Fri, 1 Feb 2002 12:05:12 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03800 for ; Fri, 1 Feb 2002 12:05:09 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11H3RS09679; Fri, 1 Feb 2002 11:03:28 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 11:03:27 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187894@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'mielias@hss.hns.com'" , sdhar@hss.hns.com Cc: Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] solving early media, HERFP, and unifying manyfolks Date: Fri, 1 Feb 2002 11:03:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB42.5BEB8F00" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AB42.5BEB8F00 Content-Type: text/plain; charset="iso-8859-1" The OBCI bit doesn't always help because its optional. The BCI bits tell the Gateway whether the called party is (1) free, (2) busy, and (3) Status unknown - which doesn't really help to deduce whether there would be EM or not (and hence, whether to send 183 w/SDP or 180). Detecting media at Gateway will work (as Jonathan proposed) if the GW can report this to MGC but this is complex. Then there's a requirement from SG11 to allow playing remote ring-back always (this is needed for International calls where the tones would vary), so I guess the only solution is for the MGC to always assume that EM will be present from the PSTN and always send an 183 offer. Thoughts? Sanjoy > -----Original Message----- > From: mielias@hss.hns.com [mailto:mielias@hss.hns.com] > Sent: Friday, February 01, 2002 1:13 AM > To: sdhar@hss.hns.com > Cc: Jonathan Rosenberg; Sen, Sanjoy [NGC:B692:EXCH]; sip@ietf.org > Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks > > > > > > Hi , > > The inband information indicator in OBCI (optional backward > call indicator) of > ACM indicates that > the inband information is present from SCN. Based on this > information the > gateway switches the reverse media > path and sends the early media answer sdp in 183 and the > announcements will be > played in the sip terminal. > Otherwise the gateway is going to respond with 180 and the > local rbt will be > applied in the SIP terminal. > > Rgds, > -Elias > > > > > > sdhar@hss.hns.com on 02/01/2002 11:27:54 AM > > To: Jonathan Rosenberg > cc: Sanjoy Sen , sip@ietf.org > (bcc: Mohamed Ibrahim > Elias/HSS) > > Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks > > > > > > > Backwards Call Indicator (BCI) parameter of the ACM indicates > that interworking has been encountered (generally designating that > the ISUP network sending the ACM is interworking with a less > sophisticated network which cannot support cause codes), then there > may be in-band announcements of call status such as an audible busy > tone or caller intercept message. > > rgds > Sumit > Hughes Software Systems > > > > > Jonathan Rosenberg on 02/01/2002 10:12:54 AM > > To: Sanjoy Sen > cc: sip@ietf.org (bcc: Sumit Dhar/HSSBLR) > > Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks > > > > > > > Sanjoy Sen wrote: > > > > > > There is no difference between early media and media. > Local alerting > > > would presumably take place as a local implementation > choice once a > > > suitable provisional response (180, typically) has been > received to > > > indicate that the far end is, in fact, ringing. It would > > > continue until > > > the establishment of the session, early or otherwise. As a > > > result, a 183 > > > w/SDP finalizes the establishment of the session, and so that > > > would stop > > > any local ringback. > > > > > > I suppose that suspension of the session, with port zero, > before the > > > dialog is completed, would be a way to signal a UAC to > revert back to > > > local ringback, if that functionality was needed. > > > > Yes, but there would a problem with general PSTN > interworking. When the > > MGC receives an ACM/Alerting message, it has no way to definitively > > infer whether the PSTN would generate early media (e.g., remote > > Ring-back or announcement). So, on receipt of ACM, the MGC > may send an > > 180 (as you said) to the SIP phone which starts playing > local ringing > > (by local implementation choice), but then any early media > which might > > be coming through the gateway will be lost (the EM flow can start > > anytime after the ACM is issued). I was wondering what kind > of rules do > > we need to specify to solve this issue and whether its at > all solvable > > by rules alone. > > I don't get the problem. Once the gateway receives media, it can > establish the session by sending an offer in an UPDATE. > > Also, I thought there was some bit somewhere in the ACM which > indicated > that ringback was inband... > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 > > > > > ------_=_NextPart_001_01C1AB42.5BEB8F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] solving early media, HERFP, and unifying = manyfolks

The OBCI bit doesn't always help because its = optional. The BCI bits tell the Gateway whether the called party is (1) = free, (2) busy, and (3) Status unknown - which doesn't really help to = deduce whether there would be EM or not (and hence, whether to send 183 = w/SDP or 180). Detecting media at Gateway will work (as Jonathan = proposed) if the GW can report this to MGC but this is = complex.

Then there's a requirement from SG11 to allow playing = remote ring-back always (this is needed for International calls where = the tones would vary), so I guess the only solution is for the MGC to = always assume that EM will be present from the PSTN and always send an = 183 offer. Thoughts?

Sanjoy


> -----Original Message-----
> From: mielias@hss.hns.com [mailto:mielias@hss.hns.com]
> Sent: Friday, February 01, 2002 1:13 AM
> To: sdhar@hss.hns.com
> Cc: Jonathan Rosenberg; Sen, Sanjoy = [NGC:B692:EXCH]; sip@ietf.org
> Subject: Re: [Sip] solving early media, HERFP, = and unifying manyfolks
>
>
>
>
>
> Hi ,
>
> The inband information indicator in OBCI = (optional backward
> call indicator) of
> ACM indicates that
> the inband information is present from SCN. = Based on this
> information the
> gateway switches the reverse media
> path and sends the early media answer sdp in = 183 and the
> announcements will be
> played in the sip terminal.
> Otherwise the gateway is going to respond with = 180  and the
> local rbt  will be
> applied in the SIP terminal.
>
> Rgds,
> -Elias
>
>
>
>
>
> sdhar@hss.hns.com on 02/01/2002 11:27:54 = AM
>
> To:   Jonathan Rosenberg = <jdrosen@dynamicsoft.com>
> cc:   Sanjoy Sen = <sanjoy@nortelnetworks.com>, sip@ietf.org
> (bcc: Mohamed Ibrahim
>       = Elias/HSS)
>
> Subject:  Re: [Sip] solving early media, = HERFP, and unifying manyfolks
>
>
>
>
>
>
> Backwards Call Indicator (BCI) parameter of the = ACM indicates
>    that interworking has been = encountered (generally designating that
>    the ISUP network sending the = ACM is interworking with a less
>    sophisticated network which = cannot support cause codes), then there
>    may be in-band announcements = of call status such as an audible busy
>    tone or caller intercept = message.
>
> rgds
> Sumit
> Hughes Software Systems
>
>
>
>
> Jonathan Rosenberg = <jdrosen@dynamicsoft.com> on 02/01/2002 10:12:54 AM
>
> To:   Sanjoy Sen = <sanjoy@nortelnetworks.com>
> cc:   sip@ietf.org (bcc: Sumit = Dhar/HSSBLR)
>
> Subject:  Re: [Sip] solving early media, = HERFP, and unifying manyfolks
>
>
>
>
>
>
> Sanjoy Sen wrote:
> >
>
> > > There is no difference between early = media and media.
> Local alerting
> > > would presumably take place as a = local implementation
> choice once a
> > > suitable provisional response (180, = typically) has been
> received to
> > > indicate that the far end is, in = fact, ringing. It would
> > > continue until
> > > the establishment of the session, = early or otherwise. As a
> > > result, a 183
> > > w/SDP finalizes the establishment of = the session, and so that
> > > would stop
> > > any local ringback.
> > >
> > > I suppose that suspension of the = session, with port zero,
> before the
> > > dialog is completed, would be a way = to signal a UAC to
> revert back to
> > > local ringback, if that functionality = was needed.
> >
> > Yes, but there would a problem with = general PSTN
> interworking. When the
> > MGC receives an ACM/Alerting message, it = has no way to definitively
> > infer whether the PSTN would generate = early media (e.g., remote
> > Ring-back or announcement). So, on receipt = of ACM, the MGC
> may send an
> > 180 (as you said) to the SIP phone which = starts playing
> local ringing
> > (by local implementation choice), but then = any early media
> which might
> > be coming through the gateway will be lost = (the EM flow can start
> > anytime after the ACM is issued). I was = wondering what kind
> of rules do
> > we need to specify to solve this issue and = whether its at
> all solvable
> > by rules alone.
>
> I don't get the problem. Once the gateway = receives media, it can
> establish the session by sending an offer in an = UPDATE.
>
> Also, I thought there was some bit somewhere in = the ACM which
> indicated
> that ringback was inband...
>
> -Jonathan R.
>
>
> --
> Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
> Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;      East Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;        FAX: (973) = 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
> http://www.dynamicsoft.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
>
>
>
>
>

------_=_NextPart_001_01C1AB42.5BEB8F00-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 1 15:32:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11327 for ; Fri, 1 Feb 2002 15:32:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08532 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 15:32:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07198; Fri, 1 Feb 2002 15:08:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07167 for ; Fri, 1 Feb 2002 15:08:44 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10717 for ; Fri, 1 Feb 2002 15:08:27 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id UAA20069 for ; Fri, 1 Feb 2002 20:08:12 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id UAA02708 for ; Fri, 1 Feb 2002 20:08:30 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 13:08:30 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B371A5@n0214idc1.oss.level3.com> To: sip@ietf.org Date: Fri, 1 Feb 2002 13:08:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] More bis-06 comments/nits Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I am continuing the list from #13 below. Hopefully these are not too late... 1. Section 3 in the text version (PDF version OK) is missing a space in "SHALL NOT" (carried over from bis-05). 2. The text on figure 1 on page 11 is all messed up in the pdf version. Looks like a different language. 3. Line 389 indicates the example contains a minimum required set, but the newly mandatory Max-Forwards is not included. Max-Forwards also appears to be missing in other examples that otherwise appear to have the other minimum required headers, such as sections 11.1, 11.2, 21.4.1 (see note below), 21.4.2, and all requests in section 26. Note, it is debatable whether a Max-Forwards is required in a tunneled Invite as in section 21.4.1, this should get a bit of list discussion. My take is yes, incase some B2BUA or something takes it out and forwards it un-tunneled. I see no reason to special-case this. 4. Section 4, the example 200 OK has the Via list messed up. Looks like the first Via in the list (line 456) should be the last one (line 458). The last Via has the wrong branch compared to the Invite example. The first Via should probably have the biloxi domain in it, not the atlanta domain, and something different than pc33 to avoid reader confusion with the Via added by Alice's PC. 5. Line 1040, I can't recall in the list discussion if there was any specific reason to disallow the value from being more or less than the selected value of 70 beyond future proofing this for really big networks. The current wording locks UACs into always putting 70 in the header. I can see including the header is a MUST, but wonder if the stated value of 70 should be a SHOULD or RECOMMENDED to allow UAs some leeway. 6. Line 1151, is timeout the ONLY thing the TU will see? What happens when an ICMP host unreachable is returned? Does that not get to the TU? Related to this, should line 1184 "or network timeouts" be "or network failures"? 7. Line 1172 references non-existent section 22.10. 8. Line 1334, sooon should be soon. 9. Line 1351, delete last "the" in the line (grammar). 10. Line 1353, "amd" should be "and". 11. Line 1356 "complete" should be "completely". 12. Section 10.1 of the text version has a space before a comma in three places. PDF version is OK (lines 1493-1495). This was also a problem carried over from bis-05. Continued: 13. Line 1601, remove period after "using". 14. Line 1668, "MUST then converted" should be "MUST then be converted". 15. Releated to item 5 above, lines 1718-1722 imply varying values of Max-Forwards can be sent by a UA, in conflict with the language in line 1040. 16. Line 1792, remove dash after "method". 17. Looks like conversion corruption is taking place after italicized words "route set". Section 12.2.1.1, 12.2.1.2 and 12.2.2 in the text version has some missing text compared to the PDF version lines 1909, 1915, 1923 and 1976. There is an unneeded space in the text version between "route set" and following comma (corresponding to line 1911, 1937, 1962 and 1977 in PDF). There is a missing period in the text version after "route set" corresponding to line 1939. 18. Line 2059, "construction" should be "constructing" (carried over from bis-05). 19. The text version has indented text corresponding to PDF version lines 2267-2268 which is not indented. 20. Line 2288, "BYE of CANCEL" should be "BYE or CANCEL". 21. The text version has indented text corresponding to PDF version lines 2290-2292 which is not indented. 22. Line 2406 has "request." which is missing in corresponding text version section 16.3. 23. Lines 2428-2429 in PDF are indented, corresponding text in text version is not indented. 24. Lines 2574-2577 in PDF are indented, corresponding text in text version is not indented. 25. Line 2583 is related to items 5 and 15 above. Also, whatever verbage is arrived at on that issue, should have a MUST to add the Max-Forwards (it's currently lower case). This is because section 16.3 #2 allows missing Max-Forwards, and #3 following it allows loop detection to be optional. With those two items, a proxy MUST add the Max-Forwards header if missing to prevent loops from going undetected. 26. Line 2595, "wishes remain" should be "wishes to remain". 27. Line 2598 in PDF is indented, corresponding text in text version is not indented. 28. Lines 2603-2605 in PDF are indented, corresponding text in text version is not indented. 29. Lines 2616-2618 in PDF are indented, corresponding text in text version is not indented. 30. Line 2650, "by transaction" should be "by the transaction". 31. Line 2671, "address that ordered set" should be "address in that ordered set". 32. Line 2679, "MUST set" should be "MUST be set". 33. Lines 2729-2732 in PDF are indented, corresponding text in text version is not indented. 34. Lines 2749-2754 in PDF are indented, corresponding text in text version is not indented. 35. Lines 2802-2807 in PDF are indented, corresponding text in text version is not indented. John Hearty Level3 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 1 15:33:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11359 for ; Fri, 1 Feb 2002 15:33:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08569 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 15:33:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07392; Fri, 1 Feb 2002 15:12:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07345 for ; Fri, 1 Feb 2002 15:12:11 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10872 for ; Fri, 1 Feb 2002 15:12:05 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g11KBdH05699 for ; Fri, 1 Feb 2002 14:11:39 -0600 Message-ID: <01c501c1ab5c$a7c74580$8e036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: References: <200201312351.g0VNpIH23151@bdsl.66.12.12.130.gte.net> Date: Fri, 1 Feb 2002 14:11:37 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] What to look for in bis draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It has been suggested that we can use all eyes to check all protocol terms are defined. Specifically we may have used two names for the same thing (for example, address-of-record may be called something else in the security section). Consistency would be nice. We can probably also use some specific attention on the BNF. Yes, I know the new BNF is a thing of beauty and wonder, but I sometimes wonder if it's not too beautiful to be right. And of course, everybody has their own special interest in bis, so please check the sections you have a special interest in and make sure they make more sense than my postings to this list sometimes do. -- Dean ----- Original Message ----- From: "Dean Willis" To: Cc: Sent: Thursday, January 31, 2002 5:51 PM Subject: [Sip] SIP bis RFC Work Plan and Call for Review Help > > Here's the current closing-up work plan for SIP bis. > > Beginning immediately, we need to subject bis-06 to "last call" type > scrutiny. Get your comments in now, folks. Note that the loose-routing > section is still being updated, as per Robert Sparks' recent email. > > Going forward: > > 4Feb -- incorporate comments, release bis07, begin formal WGLC > > 18Feb, -- end WGLC, incorporate comments > > 19Feb -- release bis08, send to iesg for feedback > > 26Feb -- close feedback, incorporate all comments > > 27Feb -- send bis09 to IESG last call > > 7Mar -- IESG meeting. Assuming IESG accepts, send draft to RFC editor, > get RFC number, and send RFC# to 3GPP, as they need it before their > plenary meetings end on 8Feb in Korea. > > I'd also like some "detail oriented" individuals to volunteer with > "nits" review of bis07, making sure all the references and citations > and MUSTS and SHOULDS and whatnot are spelled correctly. Clearly this > does not mean me, as I cannot seem to spell "correctly". > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Fri Feb 1 17:43:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13530 for ; Fri, 1 Feb 2002 17:43:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14817 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 17:43:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13707; Fri, 1 Feb 2002 17:20:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13611 for ; Fri, 1 Feb 2002 17:20:20 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13194 for ; Fri, 1 Feb 2002 17:20:15 -0500 (EST) Received: from MLEITE-W2K1.cisco.com (dhcp-171-68-90-113.cisco.com [171.68.90.113]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id OAA11811 for ; Fri, 1 Feb 2002 14:19:44 -0800 (PST) Message-Id: <4.3.2.7.2.20020201211005.01bf02e8@franklin.cisco.com> X-Sender: mleite@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Feb 2002 21:17:26 +0000 To: sip@ietf.org From: Marcelo Leite Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_7773848==_.ALT" Subject: [Sip] Global Redirect Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_7773848==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable What is the current standardization status of the SIP redirect functionality= ? Thanks in advance, Marcelo Leite. =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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Marcelo Leite (mleite@cisco.com) Carriers/Systems Engineer Cisco do Brasil=20 Ltda. |=20 | | | Av. das Am=E9ricas,700 -Bloco:5A- 2 e 3 andares | |= =20 | | | | Barra da Tijuca - Rio de Janeiro -=20 RJ | | |=20 | | | | | CEP:=20 22640-102 Brasil=20 | | | | | | | | | | Phone:=20 55+21 2483-6365=20 | | | | | | | | | | | | | | Fax: 55+21=20 2483-6399=20 ...:| | | | | | | |:.. ...:| | | | | | | |:... Mobile: 55 +21 93329949 = Cisco=20 Systems = Changing=20 the way we work, live, play and learn =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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=====================_7773848==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What is the current standardization status of the SIP redirect functionality ?

Thanks in advance,

Marcelo Leite.

=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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Marcelo Leite (mleite@cisco.com)
Carriers/Systems Engineer
Cisco do Brasil Ltda.            = ;            &nb= sp;            &= nbsp;            = ;    | |                   | |
Av. das Am=E9ricas,700 -Bloco:5A- 2 e 3 andares           &nb= sp;            &= nbsp; | | |            &nb= sp;           | | |
Barra da Tijuca - Rio de Janeiro - RJ            &n= bsp;            =             &nbs= p;      | | | |                       | | | |
CEP: 22640-102  Brasil           &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;   | | | | |                     | | | | |
Phone: 55+21  2483-6365           &= nbsp;            = ;            &nb= sp;            &= nbsp;           | | | | | | |                | | | | | | |
Fax: 55+21 2483-6399           &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ; ...:| | | | | | | |:..       ...:| | | | | | | |:...
Mobile: 55 +21 93329949           &n= bsp;            =        

            &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;         Cisco Systems
       &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             Changing the way we work, live= , play and learn
=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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=====================_7773848==_.ALT-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 1 18:53:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14389 for ; Fri, 1 Feb 2002 18:53:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17876 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 18:53:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16456; Fri, 1 Feb 2002 18:26:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16431 for ; Fri, 1 Feb 2002 18:26:46 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14065 for ; Fri, 1 Feb 2002 18:26:43 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA25989; Fri, 1 Feb 2002 15:26:07 -0800 (PST) Message-ID: <3C5B2424.9B174240@cisco.com> Date: Fri, 01 Feb 2002 18:26:28 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org, wtm@research.att.com Subject: Re: [Sip] Discussion of draft-ietf-sip-privacy-03 issues. References: <200201292253.g0TMrDH03185@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > draft-ietf-sip-privacy-03 does several notable things. > > 1) It defines a Remote-Party-ID header, which provides a way to state > the identity of participants in a dialog, as well as describe some > things about that identity, such directionality and its stutus as a > device or human identity. > > 2) It provides the RPID-privacy header, which allows the end node to > describe the privacy policy it wishes to have applied to any > Remote-Party-ID headers added by intermediate nodes. > > 3) It provides an "Anonymity" header, which may requests some > intermediate node to route the dialog via an "anonimyzer", essentially > a trusted B2BUA that provides additional privacy protections for the > requesting node. > > Let me start with #3, the "Anonymity" header. This appears to be the > request for a specific routing service or feature which may or may not > be available in a given network. I think some generalization of the > expression is appropriate, and it may be worthwhile considering such > alternatives as making this into a request parameter or as a specific > service such as that targedted in RFC 2084. Sounds like a good idea. > In general, I propose that > the "Anonymity" header be extracted from this document and taken into a > seperate body of work. If you are thereby implying, that the IP address privacy problem should not be addressed by the privacy draft, then I'm inclined to disagree. If we don't have the actual mechanism defined in there (e.g. due to timing constraints), then at the very least we should leave the considerations about IP address privacy in there and preferably have some pointers to how one might provide such a service (always hard to reference future work of course). > > #1 and #2, the Remote-Party-ID (RPID) header, and "RPID-Privacy" are > deeply intertwingled. There is an implicit assumption in the draft that > "the network" is a monolithic entity with a relatively homogenous trust > fabric. This is consistent with the draft's stated goal of providing > "NETWORK authenticated RPID", as opposed to RPIDs asserted by other > parties, or by specific networks. > > There are a couple of things that the RPID syntax as drafted does not > do that may be worthwhile to consider. > > 1) Informing us as to WHO has asserted the given RPID. The draft allows > either the user, the terminal or "the network" to assert an RPID, but > gives no indication as to which element has made the assertion. It > might be useful to know which user, which network element, or even > "which network" asserted the RPID. Are you making a distinction between asserting identity versus providing authenticated identity ? If so, do note that the current scope specifically only addresses network authenticated identity, whereas the problem of actually obtaining and verifying that identity is outside the scope of the draft. Are you proposing to change that ? > Such an identification may also be > useful in selecting a decryption key, should the option of protecting > the privacy by encrypting the asserted identity be exercised. > That part is already covered by the draft (a "private" addr-spec contains an identification of the encrypting entity in the hostport). Unencrypted Remote-Party-Id's however do not contain this identification (doesn't add much value as long as we only have transitive chain of trust and a "screen" parameter). > > 2) Informing us at to WHEN each assertion of RPID was made. This is a > critical aspect for considering replay attacks, as a "stale" assertion > seems more likley to be false. Of couse there are issues of absolute > time and clock synchronization to consider, but there are discussions > of using the RPID as a identity "ticket" for (ala Kerberos), and the > value of time-awareness in ticket environments is well-understood. One > might consider seprately the utility of indicating a duration for the > assertion in relative-time terms. > As I indiciated in another e-mail, this is a hard problem and the if propose to relax the strength of the assertion, it's not clear how useful it is. Also, as has been noted before, this is a special case of a more general problem, which is why we removed it from the draft. > > 3) Informing us as to the dialog-context in whch the assertion of > identity is being made. Common SIP usage identifies the session-context > as consisting of the tuple of To:, From:, and Call-ID: headers. Without > this context, we have no way of knowing if the dialog has undergone a > "retargeting" transformation since the identity was asserted. As > drafted, we can assume that the assertion was made in the current > dialog-context, but we have no way to verify that assumption and must > relay on transitive trust back to the currently unidentfied asserting > party. > Same comment as 2). > > 4) Allowing us to verify, or authenticate, each assertion of RPID. It > seems desirable to provide an authentication-token for each RPID which > provides the ability to match the asserted RPID with the asserting > identity, the time of the assertion, and the context of the assertion. > One migh propose to achieve this by hashing the conetxt (To:, From, > Call-ID) together with the asserting identity and the time of > theassertion, using either a secret or public key associated with the > asserting identity. Same comment as 2). > > > It has been previously pointed out (MAT) that a verification token such > as that proposed above (#4) is subject to replay. Specifically, it is > possible for a party in possession of an RPID assertion to replay it > for the same combination of context-determining parameters (To, From, > Call-ID). It may be noted that time-bounding the assertion (as in #2 > above) mitigates this problem to some extent, while adding the > requirement for some general synchronization of clocks in order to > provide this protection. On the other hand, it can be countered that > the utility of such a mechanism, while imperfect, is significantly > better than the warm but vacuous feeling one might get from > implementing the orginal proposal. > On the other hand, some people argue that no security is better than imperfect security. I'm personally of the opinion, that if you have to go through the trouble and overhead of actually signing Remote-Party-Ids and having the accompanying PKI structure in place to support all of this, then you should at least get a secure solution in return. -- Flemming > > So, other than pretending I've been reading too much Dumas, I would > like to poll the list for relevant suggestions. Should we adopt any or > all of the four specific requirements given herein (asserting identity, > time of assertion, context of assertion, and verification of assertion) > into the RPID work? Should we also move the "Anonymity" header into a > seperate draft as suggested? > > Thanks, > > -- > Dean Willis > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 1 20:01:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15328 for ; Fri, 1 Feb 2002 20:01:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA21157 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 20:01:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20302; Fri, 1 Feb 2002 19:43:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20271 for ; Fri, 1 Feb 2002 19:43:23 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15133 for ; Fri, 1 Feb 2002 19:43:14 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id AAA10695 for ; Sat, 2 Feb 2002 00:41:19 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id AAA10765 for ; Sat, 2 Feb 2002 00:43:17 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <1DQK16DJ>; Fri, 1 Feb 2002 17:43:16 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B371A8@n0214idc1.oss.level3.com> To: sip@ietf.org Date: Fri, 1 Feb 2002 17:43:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Yet more bis-06 comments/nits Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Final comments in case anyone is working the weekend to get these in bis-07. This was a crash review so I'm sure I missed plenty, but must say I am very impressed with how this document is shaking out. Excellent work by all. John Hearty Level3 > 1. Section 3 in the text version (PDF version OK) is missing > a space in "SHALL NOT" (carried over from bis-05). > > 2. The text on figure 1 on page 11 is all messed up in the > pdf version. Looks like a different language. > > 3. Line 389 indicates the example contains a minimum required > set, but the newly mandatory Max-Forwards is not included. > Max-Forwards also appears to be missing in other examples > that otherwise appear to have the other minimum required > headers, such as sections 11.1, 11.2, 21.4.1 (see note also 17.1.1.3 > below), 21.4.2, and all requests in section 26. Note, it is > debatable whether a Max-Forwards is required in a tunneled > Invite as in section 21.4.1, this should get a bit of list > discussion. My take is yes, incase some B2BUA or something > takes it out and forwards it un-tunneled. I see no reason to > special-case this. > > 4. Section 4, the example 200 OK has the Via list messed up. > Looks like the first Via in the list (line 456) should be the > last one (line 458). The last Via has the wrong branch > compared to the Invite example. The first Via should > probably have the biloxi domain in it, not the atlanta > domain, and something different than pc33 to avoid reader > confusion with the Via added by Alice's PC. > > 5. Line 1040, I can't recall in the list discussion if there > was any specific reason to disallow the value from being more > or less than the selected value of 70 beyond future proofing > this for really big networks. The current wording locks UACs > into always putting 70 in the header. I can see including > the header is a MUST, but wonder if the stated value of 70 > should be a SHOULD or RECOMMENDED to allow UAs some leeway. > > 6. Line 1151, is timeout the ONLY thing the TU will see? > What happens when an ICMP host unreachable is returned? Does > that not get to the TU? Related to this, should line 1184 > "or network timeouts" be "or network failures"? > > 7. Line 1172 references non-existent section 22.10. > > 8. Line 1334, sooon should be soon. > > 9. Line 1351, delete last "the" in the line (grammar). > > 10. Line 1353, "amd" should be "and". > > 11. Line 1356 "complete" should be "completely". > > 12. Section 10.1 of the text version has a space before a > comma in three places. PDF version is OK (lines 1493-1495). > This was also a problem carried over from bis-05. > > > Continued: > > 13. Line 1601, remove period after "using". > > 14. Line 1668, "MUST then converted" should be "MUST then be > converted". > > 15. Releated to item 5 above, lines 1718-1722 imply varying > values of Max-Forwards can be sent by a UA, in conflict with > the language in line 1040. > > 16. Line 1792, remove dash after "method". > > 17. Looks like conversion corruption is taking place after > italicized words "route set". Section 12.2.1.1, 12.2.1.2 and > 12.2.2 in the text version has some missing text compared to > the PDF version lines 1909, 1915, 1923 and 1976. There is an > unneeded space in the text version between "route set" and > following comma (corresponding to line 1911, 1937, 1962 and > 1977 in PDF). There is a missing period in the text version > after "route set" corresponding to line 1939. > > 18. Line 2059, "construction" should be "constructing" > (carried over from bis-05). > > 19. The text version has indented text corresponding to PDF > version lines 2267-2268 which is not indented. > > 20. Line 2288, "BYE of CANCEL" should be "BYE or CANCEL". > > 21. The text version has indented text corresponding to PDF > version lines 2290-2292 which is not indented. > > 22. Line 2406 has "request." which is missing in > corresponding text version section 16.3. > > 23. Lines 2428-2429 in PDF are indented, corresponding text > in text version is not indented. > > 24. Lines 2574-2577 in PDF are indented, corresponding text > in text version is not indented. > > 25. Line 2583 is related to items 5 and 15 above. Also, > whatever verbage is arrived at on that issue, should have a > MUST to add the Max-Forwards (it's currently lower case). > This is because section 16.3 #2 allows missing Max-Forwards, > and #3 following it allows loop detection to be optional. > With those two items, a proxy MUST add the Max-Forwards > header if missing to prevent loops from going undetected. > > 26. Line 2595, "wishes remain" should be "wishes to remain". > > 27. Line 2598 in PDF is indented, corresponding text in text > version is not indented. > > 28. Lines 2603-2605 in PDF are indented, corresponding text > in text version is not indented. > > 29. Lines 2616-2618 in PDF are indented, corresponding text > in text version is not indented. > > 30. Line 2650, "by transaction" should be "by the transaction". > > 31. Line 2671, "address that ordered set" should be "address > in that ordered set". > > 32. Line 2679, "MUST set" should be "MUST be set". > > 33. Lines 2729-2732 in PDF are indented, corresponding text > in text version is not indented. > > 34. Lines 2749-2754 in PDF are indented, corresponding text > in text version is not indented. > > 35. Lines 2802-2807 in PDF are indented, corresponding text > in text version is not indented. 36. Line 3132 has space before period. This also resulted in period wrapping to next line in text version. 37. Line 3140-3141 "that that" should be "that". 38. Section 17.2.1 Figure 7 title is too low, overwriting the page footer. Same for figure 8 under section 17.2.3. 39. Section 18.1 and 18.2 in the text version has multiple occurences of missing text and space before comma corruption problems following instances of "100rel". 40. Line 3385, "a Unsupported" should be "an Unsupported". 41. Line 3400, "must contain Require header" should be "must contain a Require header". 42. Line 3545, don't stateful proxies also forward stray responses statelessly? If so, the word "stateless" in this line might best be removed. 43. Line 4588, what about TLS transport (port 5061)? 44. Line 4600 has bad section link. 45. Line 5264-5266 should probabally be reworded a little in light of 100rel. 46. Line 5414, bad section reference. 47. Section 26.2 Via headers (other than top Via) are missing received= parm where required since changing to FQDNs. 48. Section 26 Via headers in 26.1 F1, F2, and 26.2 F13 & F14 are not changed to Recommended FQDN. 49. Lines 5734-5735 are extraneous and should be removed. John Hearty Level3 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 1 20:55:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16039 for ; Fri, 1 Feb 2002 20:55:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA22794 for sip-archive@odin.ietf.org; Fri, 1 Feb 2002 20:55:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22367; Fri, 1 Feb 2002 20:34:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22336 for ; Fri, 1 Feb 2002 20:34:52 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15842 for ; Fri, 1 Feb 2002 20:34:47 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g121YJH16058; Fri, 1 Feb 2002 19:34:19 -0600 Message-ID: <00b401c1ab89$d997d480$8e036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: , References: <71.19cbe966.298c61b1@aol.com> Subject: Re: SIP Spam Prevention (was Re: [Sip] calling number blocking at sip/isup ga... Date: Fri, 1 Feb 2002 19:35:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Warning! This response contains philosophical ranting. Please take a large dose of humour supplement to help ease the pain. ----- Original Message ----- From: > Dean mumbled: > > Ah. In the case I referenced, there WAS no service provider originating the > > call. It was produced by a SIP UA on the Internet. From that point of view, > > every PC is a service provider . . . > > Interesting, but this points out the basic difference in network > architectures that we are addressing. You talk as if the telephone call > originates out of nowhere, like some Spam seems to today. I am talking of a > network architecture view in which every telephone call must begin and end > under control of a "service provider". (And that doesn't mean a provider with > a physical netwok like today's telephone companies.) In this network > architecture, all the privacy issues (calling party ID, called party ID, > names, etc.) are dealt with by the choosen service provider. (You don't get > service from someone you don't trust, nor do they provide service to someone > if they don't have a way to verify who is trying to originate a call.) And at > the same time, the legal invasions of privacy, to support wire-tapping, would > be dealt with by this same service provider. I believe you have us confused with the ITU ;-) . . Mike, this is the INTERNET Engineering Task Force. We're concerned with the Internet -- it's a big packet-switching thing that allows arbitrary communications between arbitrary endpoints. Being a "Service Provider" fundamentally means to take packets from a customer, insert them into the switching fabric, and swish them on their merry way -- or, to take packets from the switching fabric as appropriate and hand them to your customer. Of course, there can be higher-level service providers. VeriSign is a good example of a service provider who provides tools to cope with the issues you raise, without being "Big Brother" and controlling everybody. I should give my speech on the difference between "control" and "service" for you someday . . . As for the rest, please see RFC 2804 for the IETF policy on wiretapping and RFC 1984 for the general policy on crypto. Good recreational reads, right up there with the Magna Carta and the Declaration of Independence, which are also probably useful reads for someone with too much background in tradtional telephony. > Yes, someone could agree to handle originations of telephone calls from > unknown parties, but I can't imagine these calls ever being allowed to > interwork into the PSTN or into a comercial IP-based telephony service > provider's network. And laws on electronic surveillance will eventually > forbid it anyway. Try setting up a session to sip:dwillis@dynamicsoft.com. If I'm not sitting at my desk, said call will be interworked into the PSTN and delivered to my cell phone. Right now, and every day for the past year and a half, except when the phone company broke the ISDN lines for a while. I suppose it could be spammed in a denial-of-service attack, but the last guy to do that is still suffering. Of course, you just just call my cell phone directly from outside the US with the same effect. On the other hand, we are working on triocks to verify that the request you've sent really came from the IP address that's claiming to send it, and barring the Zombie Attacks engendered by flawed Redmondian security systems will probably be adequate for my purposes. > > > > > What bothers me is that we are modeling this on current stuff, and > yesterday > > > I got two copies of the new "Party" virus attached to e-mails from > > > "UnknownSender". If we can't stop this in e-mail today, what is the > future > > > telephony network going to be like? > > > > Absoultely correct. This is why I want cryptographic support for the RPID > > header, and transitive vouching techniques thereon. If you get a call whose > > RPID can't be verified, it becomes perfectly legitimate to do something > > nasty to it like forward it to a robot that explains your policy about > > anonymmous calls. Or, you can listen if you want -- some people LIKE to > live > > dangerously. > > Again, in the network architecture I'm referring to, cryptographic procedures > are not the answer to privacy for calling party ID. Yes, such procedures may > be used by the originating service provider to verify that the calling party > is legitimate, and by the terminating party to determine that the call > attempt comes from their choosen service provider, then these procedures do > not need to be applied to the calling party ID iteself. In an enterprise > network, we may use cryptographic measures between parties in that closed > set, but for the general telephony environment, the end user who receives a > call shouldn't be required to apply cryptographic procedures with the > originator to verify contents of the call setup message. You have to do the crypto, either with the originator or with a trusted intermediary who vouches for the originator. Sounds like a service provider opportunity to me. What you're proposing is not really different than the fundamental PKI model -- it's just a question of who does the crypto, and since your "phone" is going to have to do crypto just to recognize the service provider, there's not much of a difference in the scope of the problem. It's all just a big "proxy" business. For example, let's say I want to trade some stocks. I fire up my browser and point it at Schwab. How do I know that it's really the Schwab site responding, and not my ex-wife's attorney trying to figure out where I hid my last 37 cents? Well, Schwab has a cert. It was signed by VeriSign. Thru other channels, I got a copy of VeriSign's cert (Chairman Bill was kind enough to include it with the OS on my office PC, and some guys in Red Hats packaged it up for my house). I use VeriSign's cert to check that my connection with Schwab was signed with Schwab's cert. Transitive trust, right? So why don't we use this approach for everything? Simple, really -- people are too cheap to pay for their own cert, too lazy to deal with it, or to ignorant to care (I suffer from all three). Or they just don't trust Big Guys, and would rather weave their own web of transitive trust with something like PGP, which also tends to run afoul of the "lazy" and "ignorant" set. And very occasionally because the device involved is just a little too small to run the crypto (the threshold is a code size somwhere around 64kB). . . . much elided . . . > Concerning your comment above that the call may start at any SIP UA on the > Internet (someone's PC). I firmly believe that it will eventually be admitted > that the issues of verification, privacy, service provisioning, accounting, > wiretap, etc. require that every "end user" of SIP have a dedicated SIP proxy > to handle originating and terminating calls. This UA-SIP proxy relationship > must be established when the device is turned on, makes the first call, etc. > Thereafter, all interactions for individual phone calls are between this > trusted SIP proxy and the end-user (SIP UA). The SIP Proxy is then the > service provider (and responsible for all the above functions). I believe > this architecture is beginning to be recognized as required for various > purposes and we can't move forward until it is accepted for all cases. Wow. I really hope you're completely wrong in the general case, otherwise I've wasted most of the last twenty years working on the Internet. Especially since I'm my own service provider and run my own proxy and my own PSTN interconnects. I also run my own web server and my own email exchanger and do all sorts of other stuff you would probably expect to reserve for "service providers". Hey, you better reject this email, because it just came from an Unknown Source! Yep, I use service providers, but I choose to do so at a different level than you're proposing, and that's OK, because this is the Internet, not a government-sponsored work camp for the political re-education of people who have expressed libertarian sympathies in a public forum. On the other hand, there IS substance in much of what you're saying. It's just that we hope to offer solutions that don't require fixed "wires", or the virtual equivalent thereof, between the slaves and the masters. In fact, I think most of the community would happily do without the "slaves" and the "masters" as well. And it now being Friday evening, I'm going to go work from the other desk. Good night. -- 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 daemon@optimus.ietf.org Sat Feb 2 00:02:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20461 for ; Sat, 2 Feb 2002 00:02:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA00196 for sip-archive@odin.ietf.org; Sat, 2 Feb 2002 00:02:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28650; Fri, 1 Feb 2002 23:25:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28551 for ; Fri, 1 Feb 2002 23:25:53 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19719 for ; Fri, 1 Feb 2002 23:25:49 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g124PKH16864; Fri, 1 Feb 2002 22:25:20 -0600 Message-ID: <001e01c1aba1$9ff73ff0$ab5ded0c@C1893415A> From: "Dean Willis" To: , "Marcelo Leite" References: <4.3.2.7.2.20020201211005.01bf02e8@franklin.cisco.com> Subject: Re: [Sip] Global Redirect Date: Fri, 1 Feb 2002 22:25:19 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C1AB6F.550BC9C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C1AB6F.550BC9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Basic redirect functionality is addressed in RFC 2543, which is in IETF = terms a Proposed Standard. We expect RFC 2543 to be superceded by a = newer RFC sometime this spring (hopefully early March). The new RFC will = also be released at the Proposed Standard level. I believe there have = been very few changes to the basics of "redirect" in the new document. = However, there have been sizable changes in message routing and system = security. -- Dean ----- Original Message -----=20 From: Marcelo Leite=20 To: sip@ietf.org=20 Sent: Friday, February 01, 2002 3:17 PM Subject: [Sip] Global Redirect What is the current standardization status of the SIP redirect = functionality ? Thanks in advance, Marcelo Leite.=20 = =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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Marcelo Leite (mleite@cisco.com) Carriers/Systems Engineer Cisco do Brasil Ltda. = | | | | Av. das Am=E9ricas,700 -Bloco:5A- 2 e 3 andares = | | | | | | Barra da Tijuca - Rio de Janeiro - RJ = | | | | | | | | CEP: 22640-102 Brasil = | | | | | | | | | | Phone: 55+21 2483-6365 = | | | | | | | | | | | | | | Fax: 55+21 2483-6399 = ...:| | | | | | | |:.. ...:| | | | | | | |:... Mobile: 55 +21 93329949 =20 = Cisco Systems = Changing the way we work, live, play and learn=20 = =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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 ------=_NextPart_000_001B_01C1AB6F.550BC9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Basic redirect functionality is = addressed in RFC=20 2543, which is in IETF terms a Proposed Standard. We expect RFC 2543 to = be=20 superceded by a newer RFC sometime this spring (hopefully early March). = The new=20 RFC will also be released at the Proposed Standard level. I believe = there have=20 been very few changes to the basics of "redirect" in the new document. = However,=20 there have been sizable changes in message routing and system=20 security.
 
--
Dean
 
----- Original Message -----
From:=20 Marcelo = Leite=20
Sent: Friday, February 01, 2002 = 3:17=20 PM
Subject: [Sip] Global = Redirect


What is the current standardization status of the SIP redirect=20 functionality ?

Thanks in advance,

Marcelo Leite.=20 =

=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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Marcelo Leite (mleite@cisco.com)
Carr= iers/Systems=20 Engineer
Cisco do Brasil=20 = Ltda.           &n= bsp;           &nb= sp;           &nbs= p;            = ;     =20 | |      =20             | = |
Av. das Am=E9ricas,700 -Bloco:5A- 2 e 3 = = andares           =             &= nbsp; =20 | |=20 = |            =            =20 | | |
Barra da Tijuca - Rio de Janeiro -=20 = RJ            = ;            =             &= nbsp;      =20 | | |=20 |         =    =20           | | |=20 |
CEP: 22640-102 =20 = Brasil           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;     =20 | | | |=20 |          =   =20         | | | | = |
Phone: 55+21 =20 = 2483-6365          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;=20 | | | | | |=20 |           =20     | | | | | | |
Fax: = 55+21=20 = 2483-6399          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;  =20 ...:| | | | | | |=20 |:..       ...:| | | | | | |=20 |:...
Mobile: 55 +21=20 = 93329949           = ;            =         =20 =

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp; =20 Cisco = Systems
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;          =20 Changing the way we work, = live, play=20 and learn=20 =
=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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 ------=_NextPart_000_001B_01C1AB6F.550BC9C0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 2 00:27:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20714 for ; Sat, 2 Feb 2002 00:27:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA00904 for sip-archive@odin.ietf.org; Sat, 2 Feb 2002 00:27:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA00542; Sat, 2 Feb 2002 00:13:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA00511 for ; Sat, 2 Feb 2002 00:13:22 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20580 for ; Sat, 2 Feb 2002 00:13:19 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g125DH6Y011388; Sat, 2 Feb 2002 00:13:17 -0500 (EST) Message-ID: <3C5B7542.D8FE951A@dynamicsoft.com> Date: Sat, 02 Feb 2002 00:12:34 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sanjoy Sen CC: "'mielias@hss.hns.com'" , sdhar@hss.hns.com, sip@ietf.org Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks References: <933FADF5E673D411B8A30002A5608A0E01187894@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sanjoy Sen wrote: > > The OBCI bit doesn't always help because its optional. The BCI bits tell > the Gateway whether the called party is (1) free, (2) busy, and (3) > Status unknown - which doesn't really help to deduce whether there would > be EM or not (and hence, whether to send 183 w/SDP or 180). Detecting > media at Gateway will work (as Jonathan proposed) if the GW can report > this to MGC but this is complex. > > Then there's a requirement from SG11 to allow playing remote ring-back > always (this is needed for International calls where the tones would > vary), so I guess the only solution is for the MGC to always assume that > EM will be present from the PSTN and always send an 183 offer. Thoughts? Its a gateway implementation issue. The spec allows for whatever you need, early media now, later, never, or always. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sat Feb 2 08:39:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03374 for ; Sat, 2 Feb 2002 08:39:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28016 for sip-archive@odin.ietf.org; Sat, 2 Feb 2002 08:39:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27093; Sat, 2 Feb 2002 08:10:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27062 for ; Sat, 2 Feb 2002 08:10:19 -0500 (EST) Received: from hotmail.com (f58.law4.hotmail.com [216.33.149.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03068 for ; Sat, 2 Feb 2002 08:10:15 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 2 Feb 2002 05:09:45 -0800 Received: from 4.25.108.14 by lw4fd.law4.hotmail.msn.com with HTTP; Sat, 02 Feb 2002 13:09:45 GMT X-Originating-IP: [4.25.108.14] From: "steve steinberg" To: sip@ietf.org Date: Sat, 02 Feb 2002 13:09:45 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Feb 2002 13:09:45.0541 (UTC) FILETIME=[E2983F50:01C1ABEA] Subject: [Sip] Active Discussions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org How can I get involved in the active discussions? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 2 14:20:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06425 for ; Sat, 2 Feb 2002 14:20:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09454 for sip-archive@odin.ietf.org; Sat, 2 Feb 2002 14:20:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08433; Sat, 2 Feb 2002 13:58:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08401 for ; Sat, 2 Feb 2002 13:58:07 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06270 for ; Sat, 2 Feb 2002 13:58:04 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g12IvQH21144; Sat, 2 Feb 2002 12:57:26 -0600 Message-ID: <005f01c1ac1b$92ca7200$55fa403f@dfw.dynamicsoft.com> From: "Dean Willis" To: "steve steinberg" , References: Subject: Re: [Sip] Active Discussions Date: Sat, 2 Feb 2002 12:58:16 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Well, they (active discussion) mostly happen on this list. If you have something relevant to say, say it. Of course, people might say stuff back. Or they might not. Some groups of people also have side conversations about specific topics. -- Dean ----- Original Message ----- From: "steve steinberg" To: Sent: Saturday, February 02, 2002 1:09 PM Subject: [Sip] Active Discussions > How can I get involved in the active discussions? > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sat Feb 2 14:59:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06745 for ; Sat, 2 Feb 2002 14:59:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10620 for sip-archive@odin.ietf.org; Sat, 2 Feb 2002 14:59:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10384; Sat, 2 Feb 2002 14:47:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10353 for ; Sat, 2 Feb 2002 14:47:13 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06653 for ; Sat, 2 Feb 2002 14:47:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g12JlL6Y011539 for ; Sat, 2 Feb 2002 14:47:22 -0500 (EST) Message-ID: <3C5C421F.B6B3B23D@dynamicsoft.com> Date: Sat, 02 Feb 2002 14:46:39 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: multipart/mixed; boundary="------------0DB98A64290F4BCA7E85C1E6" Subject: [Sip] [Fwd: WG Last Call for Offer/Answer] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------0DB98A64290F4BCA7E85C1E6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com --------------0DB98A64290F4BCA7E85C1E6 Content-Type: message/rfc822 Content-Disposition: inline Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D9WP5JSK; Sat, 2 Feb 2002 12:00:26 -0500 Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g12GwgLS024843 for ; Sat, 2 Feb 2002 11:58:43 -0500 (EST) Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g12H02408684; Sat, 2 Feb 2002 18:00:02 +0100 (MET) Message-ID: <3C5C1B02.73F44DC9@tzi.uni-bremen.de> From: Joerg Ott To: mmusic@ietf.org Cc: mankin@isi.edu, csp@isi.edu, jdrosen@dynamicsoft.com Subject: WG Last Call for Offer/Answer Date: Sat, 2 Feb 2002 11:59:46 -0500 MIME-Version: 1.0 Content-Type: text/plain X-Mozilla-Status2: 00000000 Folks, this is to announce Working Group Last Call on draft-ietf-mmusic-sdp-offer-answer-00.txt for Proposed Standard. Please note that this document is a revision of draft-rosenberg-mmusic-offer-answer-00.txt. The WG Last Call is to expire in two weeks, on 16 Feb 2002. Please note that this document is referenced by SIP bis06 and thus is crucial to the 3G work. So, please, review this document quickly (it is not that long) and should you have any comments, please submit them asap to the MMUSIC mailing list and the authors. Thanks a lot, Joerg co-chair, MMUSIC --------------0DB98A64290F4BCA7E85C1E6-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 2 16:15:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07696 for ; Sat, 2 Feb 2002 16:15:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13723 for sip-archive@odin.ietf.org; Sat, 2 Feb 2002 16:15:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12981; Sat, 2 Feb 2002 15:56:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12950 for ; Sat, 2 Feb 2002 15:56:45 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07517 for ; Sat, 2 Feb 2002 15:56:39 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA04193; Sat, 2 Feb 2002 12:56:08 -0800 (PST) Message-ID: <3C5C527B.21E99302@cisco.com> Date: Sat, 02 Feb 2002 15:56:27 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson CC: SIP Mailing List Subject: Re: [Sip] privacy draft and calling vs called References: <3C59BEB0.1CBEC3F5@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This is indeed a good question. In previous versions of the privacy draft, we always assumed that only the initial INVITE would contain the Remote-Party-ID information. A couple of things have changed since then, most notably the fact that the proxy is now the one responsible for inserting the Remote-Party-Id, and proxies don't know whether INVITE's (or other messages which may now also contain Remote-Party-ID's) are initial, or come from the originating or terminating party. In other words, it becomes difficult to do anything but simply put "calling" in requests and "called" in responses, however it's not clear to me that we always want to do that, e.g. in case of redirection services. What do people think ? -- Flemming Terry L Anderson wrote: > The privacy draft uses > party = calling | called > as the rpi-pty-type in the Remote-Party-ID header. The descriptions in > 5.1 (assumed type if parameter is absent), 6.1 and 6.3 indentify > "calling" with the sender of the request and "called" with the sender of > a response. This seems obvious for an initial INVITE. But I want to > confirm the intention for a reINVITE which does NOT come from the party > that initiated the call. Should "calling" still be indentified with > "requesting" even though the party is not the original calling party for > the call? That is, should calling and called be reversed (as To and > >From are) from the original for the established call-leg or should they > maintain their PSTN-like meaning with calling always referring to the > party that initiated the call-leg? > > In either case, it would be helpful to be more explicit about usage for > subsequent requests since "calling" and "called" are not SIP terms and > might be confused with their PSTN usage. > > -- > > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 2 16:23:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07756 for ; Sat, 2 Feb 2002 16:23:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13842 for sip-archive@odin.ietf.org; Sat, 2 Feb 2002 16:23:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13647; Sat, 2 Feb 2002 16:11:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13616 for ; Sat, 2 Feb 2002 16:11:21 -0500 (EST) Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07674 for ; Sat, 2 Feb 2002 16:11:16 -0500 (EST) Message-ID: <20020202211119.25159.qmail@web11607.mail.yahoo.com> Received: from [12.237.5.37] by web11607.mail.yahoo.com via HTTP; Sat, 02 Feb 2002 13:11:19 PST Date: Sat, 2 Feb 2002 13:11:19 -0800 (PST) From: Sean Olson Subject: Re: [Sip] privacy draft and calling vs called To: Flemming Andreasen , Terry L Anderson Cc: SIP Mailing List In-Reply-To: <3C5C527B.21E99302@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org It just makes sense for the RPID to be transaction based; the RPID should reflect the From: header in requests and the To: header in responses. Or to look at it from a different point of view, the caller's proxy should never have to insert a RPID for the calling party. /sean --- Flemming Andreasen wrote: > This is indeed a good question. In previous versions > of the privacy draft, > we always assumed that only the initial INVITE would > contain the > Remote-Party-ID information. A couple of things have > changed since then, > most notably the fact that the proxy is now the one > responsible for > inserting the Remote-Party-Id, and proxies don't > know whether INVITE's (or > other messages which may now also contain > Remote-Party-ID's) are initial, or > come from the originating or terminating party. In > other words, it becomes > difficult to do anything but simply put "calling" in > requests and "called" > in responses, however it's not clear to me that we > always want to do that, > e.g. in case of redirection services. What do people > think ? > > -- Flemming > > > > Terry L Anderson wrote: > > > The privacy draft uses > > party = calling | called > > as the rpi-pty-type in the Remote-Party-ID header. > The descriptions in > > 5.1 (assumed type if parameter is absent), 6.1 and > 6.3 indentify > > "calling" with the sender of the request and > "called" with the sender of > > a response. This seems obvious for an initial > INVITE. But I want to > > confirm the intention for a reINVITE which does > NOT come from the party > > that initiated the call. Should "calling" still > be indentified with > > "requesting" even though the party is not the > original calling party for > > the call? That is, should calling and called be > reversed (as To and > > >From are) from the original for the established > call-leg or should they > > maintain their PSTN-like meaning with calling > always referring to the > > party that initiated the call-leg? > > > > In either case, it would be helpful to be more > explicit about usage for > > subsequent requests since "calling" and "called" > are not SIP terms and > > might be confused with their PSTN usage. > > > > -- > > > > > ------------------------------------------------------------ > > Terry L Anderson > mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Lucent Technologies/INS/Voice Over IP Access > Networks > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) > http://www.gti.net/tla > > -- > Flemming Andreasen > Cisco Systems > > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip ===== Sean Olson __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.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 daemon@optimus.ietf.org Sat Feb 2 19:56:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09381 for ; Sat, 2 Feb 2002 19:56:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA20480 for sip-archive@odin.ietf.org; Sat, 2 Feb 2002 19:56:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20220; Sat, 2 Feb 2002 19:36:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20189 for ; Sat, 2 Feb 2002 19:36:46 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09262 for ; Sat, 2 Feb 2002 19:36:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.156]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g130XjgZ012382 for ; Sat, 2 Feb 2002 19:33:45 -0500 (EST) Message-ID: <3C5C85DD.2020206@dynamicsoft.com> Date: Sat, 02 Feb 2002 19:35:41 -0500 From: Anders Kristensen Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: SIP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] bis-06 comments Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Some minor comments on bis-06. "Note that both the transaction corresponding to the original request and the CANCEL transaction will 1453 complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request 1454 Terminated) response for the original request, as an RFC 2543-compliant UAS will not generate such a 1455 response. If there is no final response for the original request in 64*T1 seconds (T1 is defined in Section 1456 17.1.1.1), the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client 1457 transaction handling the original request. 1458" Not that it really matters, but shouldn't this really be 64*T1 minus however long the transaction has been in the Calling state? "A dialog can also be in the "early" state, which occurs when it is created with a provisional response, and then transition to the "confirmed" state when the final response comes. 1812" - or to the "terminated" state, depending on the status code. Evidently, there's a dialog state machine hiding in there. Maybe it should be made explicit. When a 1xx to an initial INVITE does contain a To tag, this 1xx and not a subsequent final response, establishes the dialog. Text like "When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the 1824 UAS MUST copy all Record-Route headers from the request into the response (including the URIs, URI 1825 parameters, and any Record-Route header parameters, whether they are known or unknown to the UAS) 1826 and MUST maintain the order of those headers. The UAS MUST add a Contact header field to the response. 1827" then applies to the 1xx but not necessarily to the 2xx (as I read it), meaning that a 200 to an INVITE might legally not contain Record-Route and Contact. This is probably unfortunate and unintended. BTW, 180's in the Examples section doesn't include R-R and Contacts. 1xx's other than 100 now MUST always be given a To tag. This puts extra work load on dialog-stateful proxies and I don't really see what the point of such a requirement would be. "13.2.2.2 3xx responses A 3xx response may contain a Contact header field providing new addresses 2084 where the callee might be reachable. Depending on the status code of the 3xx response (see Section 25.3) 2085 the UAC MAY choose to try those new addresses. 2086" Actually, "the UAC MAY choose to try those new addresses" regardless of the actual 3xx. "A 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved Temporarily) response SHOULD contain 2168 a Contact header field containing URIs of new addresses to be tried. 2169" Should be "SHOULD contain one or more...". ""the wire". In this case, the UAC will receive a 2xx to the INVITE.ItSHOULD then terminate the call by 2306 following the procedures described in Section 15.1.1. 2307" I'd suggest making this a MUST or remove the upper-case requirement altogether. "a proxy performing load balancing may route a BYE without a Route header field in a different way than the INVITE,since 2317 both requests have different CSeq sequence numbers. 2318" That's not what section 24.2 USED to say (in bis-05): "More specifically, once a request is delivered successfully to a par- ticular next hop, all subsequent requests with the same Call-ID MUST be delivered to that next hop. 4187". Mind you, this was obviously bogus anyway, as the route being constructed might dictate otherwise. I'm confused about section 24.2. There doesn't seem to be any note about it's disappearance in the Changes. Is it supposed to be replaced by draft-ietf-sip-srv-04.txt? That draft and what was 24.2 doesn't seem to have very much in common (in the sense of shared text), in particular the quote above isn't in the draft. "If the domain of the Request-URI indicates a domain this element is not responsible for, it SHOULD set 2109 the next hop URI to the Request-URI, and leave the IP address, port and transport of the next hop empty. 2110" Hmm, isn't it really up to the proxy itself to decide where to route such an incoming request? The suggested behaviour is a good default but it's not wrong to make different decisions, right? "If this proxy wishes to request to remain on the path of future requests in this dialog, it MUST insert a Record-Route header value (Section refsec:record-route) into the copy before any existing Record- 2225 Route header values. 2226" - should be "If this proxy wishes to request to remain on the path of future requests in this dialog *and* this is an initial request *and* the request potentially establishes a dialog..."? "The Request-URI will be different each time the request passes through. 2250" Is this necessarily so? "If the proxy chooses to recurse on a 3xx class response, it MUST NOT add the response to the response 2327 context 2328" What if the proxy *partially* recursed, e.g. if it tried all sip URLs but not mailto and http URLs? In this case it makes sense to return a 3xx with just those Contacts that haven't been tried. Maybe the best way to view this situation is as if such a 3xx had been received from a "virtual" branch. "If a 6xx response is received, it is not immediately forwarded, but the stateful proxy SHOULD cancel 2334 all pending transactions as described in Section 9. 2335" ... "and no new branches can be created in this context." Seems to me the majority of SHOULD/SHOULD NOT items in 17.1.1.2 should be MUST/MUST NOT. 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 daemon@optimus.ietf.org Sun Feb 3 00:54:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13595 for ; Sun, 3 Feb 2002 00:54:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA29005 for sip-archive@odin.ietf.org; Sun, 3 Feb 2002 00:54:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28681; Sun, 3 Feb 2002 00:32:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28649 for ; Sun, 3 Feb 2002 00:32:54 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13498 for ; Sun, 3 Feb 2002 00:32:53 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 1615D4CE39 for ; Sun, 3 Feb 2002 00:32:54 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id AAA14175; Sun, 3 Feb 2002 00:32:49 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id AAA87223; Sun, 3 Feb 2002 00:34:57 -0500 (EST) Date: Sun, 3 Feb 2002 00:34:57 -0500 (EST) Message-Id: <200202030534.AAA87223@fish.research.att.com> To: sip@ietf.org Subject: [Sip] further comments on bis-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Following are additional comments to add to my original list. First, a few general comments. The use of MUST, MAY, SHOULD, etc, is covered in RFC2119. However, use of "must", "may", and "should" (in lower case) are not spec words. But they are confusing, and could be misinterpreted as spec words. Therefore, wherever I saw one of them, I included an editorial change below to re-word the sentence without it. Second, the reference structure helps a lot in understanding the protocol, but should not be normative. In particular, normative language regarding interaction between layers of the reference structure is not appropriate. Wherever I saw such use of a MUST, I included an editorial change below to re-word the sentence without the spec word. Section 10.3 has a noticeable lack of spec words. I recommend the following be promoted: line 1647 must to MUST; line 1667 sends to MUST send; line 1675 returns to MUST return; line 1698 is to MUST be; line 1699 updates or removes to MUST update or remove; line 1703 are to MUST be; line 1704 fails to MUST fail; line 1705 are to MUST be. Section 12.2.1 and 12.2.2, it is not clear that UAC/UAS might be different than the roles in the initial INVITE. This could be clarified in 12.2, or make the following changes: line 1892: change to "Behavior of UA initiating a request within a dialog" line 1921,1928,1930, and 1943: change UAC to UA line 1946: change to "Behavior of UA receiving a request within a dialog" line 1948,1951,1952,1956,1957(4timess),1959,1964: change UAS to UA Minor technical items: Content-Length is never mentioned as a header that a proxy MUST add; however, if the UA sends a request/response over UDP (and therefore without a Content-Length header) but the proxy uses TCP, then the proxy must add it. Section 8.1.1.6, line 1040: My recollection of the list discussion was that the value 70 was RECOMMENDED, not MUST. But perhaps I missed something. Section 8.1.4.5: While processing the list of Contact headers, if one returns another 3xx response with more Contact headers, ... Perhaps some words should be added about adding to the list, and not replacing the previous list. Section 10.2.4, line 1606: "unless redirected." seems to be the only mention anywhere about a 3xx response to a REGISTER. Is this allowed? Perhaps it should reference 8.1.4.5 in line 1606. Section 10.2.7, line 1630: "SHOULD wait some reasonable time interval" is untestable. Suggest changing to "MUST NOT retry immediately.." Section 11.2, line 1748: "The response code chosen is the same that would have been chosen had the request been an INVITE." The "is" should be a spec word. Should it be a SHOULD or a MUST? Section 12.1.1, line 1831: "and have global scope". This seems particularly NAT-unfriendly, even for local calls with both parties behind the same NAT. Also it is given as a requirement for the UAS, but not the UAC. I recommend it be dropped here. Section 15, line 2285-6: "A UA joining a multicast session MAY terminate the SIP dialog immediately after the INVITE transaction used to join the session has completed." I'd hate to recommend such an action, since it may have unintended consequences to the QoS of the media stream in some cases. Section 15, lines 2291-2295, spec language is very confusing. "As a general rule...MUST" later "SHOULD". I think these are clear MUSTs. Section 16.7. Timer C fires, and the proxy resets it with an infinite value. Is that really OK? We already allow the proxy to have an arbitrary large initial setting of Timer C. Perhaps 16.7 should say the proxy SHOULD generate a CANCEL. Section 23.1.6, line 4660: shouldn't there be a "user=phone" on these SIP URLs? Also 4662, 4671, 4672, 4678, 4679, 4689, 4694. Editorial changes: line 702: ...ACK for the response... to ...ACK for the response to an INVITE transaction... line 702-3: ...ACK for a 2xx response... to ...ACK for a 2xx response to an INVITE transaction... line 922: add "Note the Content-Length header is always present with UDP." line 994: change"ahhs.aa" to "localhost" line 1005: is the space allowed between ">" and ";tag"? line 1059: bad section number cross reference line 1065: change "Only a single URI MUST be present" to "A Request MUST NOT contain multiple Contact header values." line 1091: change to "See Sections 24.11 through 24.15." line 1278: change SHOULD to "will typically". Spec is in line 8146. line 1281: change should to SHOULD. Possibly to a MUST line 1311: change "MUST do so if support for tht extension is indicated in the Supported header in the request" to "MUST NOT do so if that extension is not listed in the Supported header in the request." line 1314: can't spec new specs. Change sentence to "To ensure that this can be fulfilled, any specification of a new extension needs to include a discussion of how to return gracefully to baseline SIP ..." line 1319: "NOT RECOMMENDED" is not a spec word. Change sentence to "This behavior will generally break interoperability, and SHOULD NOT be done." line 1398: for consistency, change GSTN to PSTN. only occurence. line 1406: needs spec word. change to "Malformed values SHOULD be treated as equivalent to 3600." line 1410: spec is in UAC section, change here to "... the extension will be taged in the Proxy-Require field..." line 1489: change first sentence to "SIP proxies offer a discovery capability" line 1489-90: change "... SIP must discover the current host(s) that the destination user is reachable at." to "... a SIP proxy discovers the current host(s) where the destination user is reachable." line 1517: change "may" to "can" line 1519: change "may" to "can" twice line 1538.5: add "A REGISTER request MUST NOT contain Record-Route or Route header fields." (This is currently in the server section, line 1642, but is actually a UAC requirement.) line 1458: change to a spec word. "Malformed values SHOULD be treated as equivalent to 3600." line 1550-1: change "...to which SIP requests for the address of record should be forwarded." to "... to which the UAC desires requests to be forwarded." line 1576: needs a spec word. "...a default suggestion of one hour (3600) SHOULD be assumed." line 1589-90: change "but it MUST only be used when the Expires header field is present with a value of "0"." to "but it MUST NOT be used unless the Expires header field is present with a value of "0"." line 1627-8: change "UACs should follow the procedures ..." to "UACs follow the procedures ..." line 1642: change "MUST NOT" to "will not". Spec language inserted at 1538.5 above. line 1644: change "A registrar must know" to "A registrar knows" line 1647: should be a spec word. "Each REGISTER message MUST be processed independently of any other registration or binding changes." line 1768: change UA to UAS line 1792: no space in "method-independent" line 1872: change UA to UAS line 1961: change must to MUST line 2008: change UA to UAC line 2015: change UA to UAC line 2016: change UA to UAS line 2020: change Caller to UAC line 2025: change UA to UAC line 2026: change UA to UAC line 2031: change UA to UAC line 2034: change UA to UAC line 2064: drop space before closing right paren line 2074: change "Section 24" to "Section 24 and 23.1.4" But nowhere can I find rules for comparing CSeq header values. line 2098-9: change "2xx response using the procedures of Section 12.1.2. Otherwise, a new dialog in the "confirmed" state is constructed in the same fashion." to "2xx response using the procedures of Section 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST BE constructued using the procedures of 12.1.2." line 2103,2109: I don't think the spec should specify which element in the reference architecture MUST generate a particular request. Suggest changing "UAC core" to "UAC". line 2120: change caller to UAC line 2121: change caller to UAC line 2122: change Callee to UAS line 2148: change to "If the INVITE does not contain a session description, the UAS is being asked to participate in a session and the UAC has asked that the UAS provide the offer of the session." line 2150: change callee to UAS line 2152: change to "If the UAS is not able to answer the invitation immeidately, it can choose to indicate some kind of progress..." line 2158: change "will require" to "desires" line 2186: add space after period before "Note" line 2208: change "NOT RECOMMENDED" to "SHOULD NOT be done," line 2227: drop "Note that, as opposed to initial INVITEs (see Section 13)." and change "re-INIVTEs" to "Re-INVITEs" line 2230: change "Note that a UAC" to "A UAC" line 2312: change "uses BYE request" to "uses a BYE request" line 2328: spurious space at beginning of line line 2335: change "and MUST pass that to the server transaction for transmission" to "and passes that to the server transaction..." i.e. remove the spec language for inter-module control flows. line 2347: change "proxy must first decide" to "proxy first decides" line 2348: change "may" to "could" line 2404-5: spec is in line 2403. change "SHOULD NOT" here to "would not", twice. line 2407: change "may" to "can" line 2421: change "field value with A sent-by" to ".. a sent-by" line 2431: change "may" to "can" line 2433: change "telling the proxy it should not process the request" to "telling the proxy not to process the request" line 2442: change "the proxy must decide" to "the proxy decides" line 2477: add a closing right paren line 2499: change "may" to "can" line 2529: I think this "must" should be a spec word, "MUST" line 2545: change "Only those fields detailed in the processsing described below may be removed." to "Fields not detailed in the process described below MUST NOT be removed." line 2583: should be a spec word, change must to MUST line 2586: should be a spec word, change must to MUST line 2699.5: add point 2, Record Route line 2700: change to point 3 line 2814: change "may" to "could" line 2817: change "The client must receive all of those challenges and supply credentials..." to "The client receives all of those challenges and supplies credentials..." line 2833-4: change "one of the operations it must perform is" to "one of the operations is performs is" line 2850: change "the proxy may perform any feature..." to "the proxy performs any feature..." line 2852: ref to "Section 3" should probably be to "Step 3" line 2854: "The proxy MUST pass the response to the server transaction associated with the response context" to "The proxy passes the response..." i.e. remove the spec word for internal control within the reference design line 2857: "..the element MUST forward the response statelessly by sending it to the server transport." Again, we should not spec control within the reference design. "...the element forwards ..." line 2858: change "should" to "would" line 2888: change "may" to "can" line 2892: change "INVITEs" to "INVITE's" line 2912: should be a spec word, change "must" to "MUST" line 2913: should be a spec word, change "must" to "MUST" line 2920: should be a spec word, change "must" to "MUST" line 2949: should be a spec word, change "inspects" to "MUST inspect" line 3051: another spec word related to design of future extensions. change "SHOULD" to "would" line 3126: add the text from lines 3143-4 immediately after the section title: "These rules for construction of ACK only apply to the client transaction. A UAC core which generates an ACK for 2xx MUST instead follow the rules described in Section 13." lines 3143-4: moved to line 3126, so drop line 3159: capitalize, "Non-INVITE" line 3270: capitalize, "Non-INVITE" line 3382: change "may" to "can" line 3400: change "MUSTcontain" to "MUST contain" line 3401: change "MUSTinclude" to "MUST include" line 3617: remove extra space "Digest need" line 3624: remove space in "auth-scheme" line 3629: remove space in "Proxy-Authorization" line 3658: drop lc "should" requirement given elsewhere for UAC line 3720: add "All" before 407, to not start sentence with digit. line 3754: add closing right paren after 16.6 line 3757: spec is in section 16.6, change "MUST be" to "is" line 3765: also in 16.6, change "MUST be" to "is" line 3767: also in 16.6, change "MUST be" to "is" line 3775: drop space in "Proxy-Authenciation" line 3859: should be a spec word, change "should" to "SHOULD" line 4261: change "MUSTNOT" to "MUST NOT" line 4600: bad cross reference to undefined section line 4626: change "must" to "needs to" line 4745: move 'a' to be in alphabetical order, above 'c' line 4748: move 'o' to be in alphabetical order, after 'm' line 4757: move 'c' to be in alphabetical order, before 'm' line 4839: remove space from "case-sensitive" line 6774: rfc 1806 superceeded by 2183. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 3 08:37:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24877 for ; Sun, 3 Feb 2002 08:37:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA23007 for sip-archive@odin.ietf.org; Sun, 3 Feb 2002 08:37:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22021; Sun, 3 Feb 2002 08:11:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21928 for ; Sun, 3 Feb 2002 08:11:11 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24704 for ; Sun, 3 Feb 2002 08:11:08 -0500 (EST) Received: from MLEITE-W2K1.cisco.com (dhcp-171-68-90-114.cisco.com [171.68.90.114]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id FAA08776; Sun, 3 Feb 2002 05:10:22 -0800 (PST) Message-Id: <4.3.2.7.2.20020203105846.0383f188@franklin.cisco.com> X-Sender: mleite@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 03 Feb 2002 10:59:19 +0000 To: "Dean Willis" From: Marcelo Leite Subject: Re: [Sip] Global Redirect Cc: In-Reply-To: <001e01c1aba1$9ff73ff0$ab5ded0c@C1893415A> References: <4.3.2.7.2.20020201211005.01bf02e8@franklin.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_58227076==_.ALT" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_58227076==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Dean, Thanks a lot!!! Marcelo Leite. At 10:25 PM 2/1/2002 -0600, Dean Willis wrote: >Basic redirect functionality is addressed in RFC 2543, which is in IETF=20 >terms a Proposed Standard. We expect RFC 2543 to be superceded by a newer= =20 >RFC sometime this spring (hopefully early March). The new RFC will also be= =20 >released at the Proposed Standard level. I believe there have been very=20 >few changes to the basics of "redirect" in the new document. However,=20 >there have been sizable changes in message routing and system security. =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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Marcelo Leite (mleite@cisco.com) Carriers/Systems Engineer Cisco do Brasil=20 Ltda. |=20 | | | Av. das Am=E9ricas,700 -Bloco:5A- 2 e 3 andares | |= =20 | | | | Barra da Tijuca - Rio de Janeiro -=20 RJ | | |=20 | | | | | CEP:=20 22640-102 Brasil=20 | | | | | | | | | | Phone:=20 55+21 2483-6365=20 | | | | | | | | | | | | | | Fax: 55+21=20 2483-6399=20 ...:| | | | | | | |:.. ...:| | | | | | | |:... Mobile: 55 +21 93329949 = Cisco=20 Systems = Changing=20 the way we work, live, play and learn =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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=====================_58227076==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dean,

Thanks a lot!!!

Marcelo Leite.
At 10:25 PM 2/1/2002 -0600, Dean Willis wrote:
Basic redirect functionality is addressed in RFC 2543, which is in IETF terms a Proposed Standard. We expect RFC 2543 to be superceded by a newer RFC sometime this spring (hopefully early March). The new RFC will also be released at the Proposed Standard level. I believe there have been very few changes to the basics of "redirect" in the new document. However, there have been sizable changes in message routing and system security.


=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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Marcelo Leite (mleite@cisco.com)
Carriers/Systems Engineer
Cisco do Brasil Ltda.            = ;            &nb= sp;            &= nbsp;            = ;    | |                   | |
Av. das Am=E9ricas,700 -Bloco:5A- 2 e 3 andares           &nb= sp;            &= nbsp; | | |            &nb= sp;           | | |
Barra da Tijuca - Rio de Janeiro - RJ            &n= bsp;            =             &nbs= p;      | | | |                       | | | |
CEP: 22640-102  Brasil           &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;   | | | | |                     | | | | |
Phone: 55+21  2483-6365           &= nbsp;            = ;            &nb= sp;            &= nbsp;           | | | | | | |                | | | | | | |
Fax: 55+21 2483-6399           &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ; ...:| | | | | | | |:..       ...:| | | | | | | |:...
Mobile: 55 +21 93329949           &n= bsp;            =        

            &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;         Cisco Systems
       &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             Changing the way we work, live= , play and learn
=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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=====================_58227076==_.ALT-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 3 08:47:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24954 for ; Sun, 3 Feb 2002 08:47:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA23178 for sip-archive@odin.ietf.org; Sun, 3 Feb 2002 08:47:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22911; Sun, 3 Feb 2002 08:32:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22879 for ; Sun, 3 Feb 2002 08:32:35 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24841 for ; Sun, 3 Feb 2002 08:32:32 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id EA2EC1E049 for ; Sun, 3 Feb 2002 08:32:30 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA19089; Sun, 3 Feb 2002 08:32:26 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA96847; Sun, 3 Feb 2002 08:34:33 -0500 (EST) Date: Sun, 3 Feb 2002 08:34:33 -0500 (EST) Message-Id: <200202031334.IAA96847@fish.research.att.com> To: sip@ietf.org Subject: [Sip] Re: further comments on bis-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org tried tooo hard to get them done quickly. > line 922: add "Note the Content-Length header is always present > with UDP." This should instead say TCP, of course. Bill Marshall wtm@research.att.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 daemon@optimus.ietf.org Sun Feb 3 11:40:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27476 for ; Sun, 3 Feb 2002 11:40:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29964 for sip-archive@odin.ietf.org; Sun, 3 Feb 2002 11:40:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29133; Sun, 3 Feb 2002 11:20:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29102 for ; Sun, 3 Feb 2002 11:20:08 -0500 (EST) Received: from sumo.vocaltec.co.il (vocaltec.co.il [199.203.72.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27212 for ; Sun, 3 Feb 2002 11:20:04 -0500 (EST) From: Dror@vocaltec.com Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135]) by sumo.vocaltec.co.il (8.10.2+Sun/8.10.2) with ESMTP id g13GIC524568 for ; Sun, 3 Feb 2002 18:18:12 +0200 (IST) To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: Date: Sun, 3 Feb 2002 18:17:00 +0200 X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.8 |June 18, 2001) at 02/03/2002 06:16:57 PM, Serialize complete at 02/03/2002 06:16:57 PM Content-Type: text/plain; charset="us-ascii" Subject: [Sip] Possible errors in BNF definition in bis-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org It seems to me that there are few errors in the BNF (I don't know if they were introduced in bis-06 or earlier) 1. Line-breaks are allowed to be added almost freely in the text, breaking many of the (english spelled) rules COMMA = SWS "," SWS this means that before and after every comma, CRLF sequence is allowed, with optional leading and trailing spaces. 2. No extension header is allowed (though many other items, such as methods, define extensions) 3. no CRLF after header lines. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 3 12:51:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28148 for ; Sun, 3 Feb 2002 12:51:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02873 for sip-archive@odin.ietf.org; Sun, 3 Feb 2002 12:51:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01984; Sun, 3 Feb 2002 12:27:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01955 for ; Sun, 3 Feb 2002 12:27:51 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27936 for ; Sun, 3 Feb 2002 12:27:48 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g13HRF501091 for ; Sun, 3 Feb 2002 09:27:15 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACK77656; Sun, 3 Feb 2002 09:27:20 -0800 (PST) Date: Sun, 3 Feb 2002 09:26:28 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] bis-06 BNF issues Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I'm also in the middle of a detailed bis-06 review, and haven't finished, but since I noticed that none of the other comments focussed on the BNF, I redirected my efforts there. I found several errors or questions on my first pass, so here they are. The last time I thoroughly read the BNF was bis-04, so I was a bit surprised by some of the implications of the "explicit whitespace" BNF. Please accept my apologies if this has been discussed already. 1) The thing that surprised me most is that "quoted-string" allows CRLF. So the following are legal according to the BNF in bis-06: To: " Bob " Server: MyUA/1.0 ( "A comment that spans many lines" ) WWW-Authenticate: Digest realm = " my realm " Was this the intent? If so, it certainly seems to complicate parsing and line-folding (you cannot collapse LWS into a single SP) Lines 5812-5813 seem to indicate that quoted text should not contain CRLF. 2) Also, I think that SWS is either misdefined or used improperly instead of LWS in many places. Some examples: To: "Bob" is currently valid, because LAQUOT contains SWS, and SWS does not necessarily contain SP or HT after a CRLF. For that matter, SWS doesn't have to contain anything, so this is also valid: To: "Bob" I am assuming the later was intended, as I think this is a good thing. It just might not be obvious to readers/implementors. 3) Likewise the definition of "word" includes SP and HT. this may be OK, but I don't think it is such a good idea: Call-ID: ab cd@ef gh 4) Ampersands (&) seem to disappeer in the PDF version. perhaps this is tex escaping issue? for example, lines: 5771 (reserved), 5817 (headers), 5818 (pchar) 5) Reason-Phrase in 5822 seems to have -- instead of | . Also, shouldn't you be able to include UTF8-NONASCII and UTF8-CONT in a reason phrase? 6) Shouldn't message-header include an extension-header ? 7) display-name in line 5838 has an extra trailing ")" 8) qvalue (line 5838) has an error, it should be: ("0" [ "." 1*3DIGIT ] ) | ("1" [ "." 1*3("0") ] ) unless you want ;q=0. 9) the definition of "challenge" in 5855 needs some LWS: WWW-Authenticate: Digestrealm="foo.com",etc.... = "Digest" LWS digest-challenge or (preferably) we can resurrect auth-scheme from RFC2617 and use an IANA registration for sip-auth-schemes or something. 10) Also, I know its late, but I'd like to propose that extension-method names be limited to upalpha, or alphanum. We really don't want/need method names as in this example: *L.~ sip:foo@bar.org SIP/2.0 11) no defintion of "psuedonym" (line 5872 -- warn-agent), plus warn-agent should use existing definition of hostport (COLONs SWS is not apropos here). 12) line 5818 (absoluteURI) should use ":" not COLON (don't need whitespace in an http URL) 13) telephone-subscriber should match definition in RFC2806 which also allows several other characters, for example: * # A B C D p w ( ) 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 daemon@optimus.ietf.org Sun Feb 3 13:05:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28272 for ; Sun, 3 Feb 2002 13:05:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03515 for sip-archive@odin.ietf.org; Sun, 3 Feb 2002 13:05:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02660; Sun, 3 Feb 2002 12:43:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02629 for ; Sun, 3 Feb 2002 12:43:02 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28076 for ; Sun, 3 Feb 2002 12:43:00 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g13HgQ502975 for ; Sun, 3 Feb 2002 09:42:26 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACK77701; Sun, 3 Feb 2002 09:42:31 -0800 (PST) Date: Sun, 3 Feb 2002 09:41:38 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] possible fix for SWS definition Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Below is a proposed fix for problem #2 in my previous mail. old definition: SWS = *( SP | HT ) [CRLF] *( SP | HT ) ; sep whitespace proposed definition: SWS = *( SP | HT ) [ CRLF 1*( SP | HT ) ] ; sep whitespace thus, you can have no whitespace, arbitrary "horizontal" whitespace, or you can linefold, in which case you need at least some "horizontal" whitespace after the CRLF. 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 daemon@optimus.ietf.org Sun Feb 3 14:15:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28926 for ; Sun, 3 Feb 2002 14:15:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05993 for sip-archive@odin.ietf.org; Sun, 3 Feb 2002 14:15:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04900; Sun, 3 Feb 2002 13:54:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04869 for ; Sun, 3 Feb 2002 13:54:53 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28750 for ; Sun, 3 Feb 2002 13:54:51 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 0FD824CE13 for ; Sun, 3 Feb 2002 13:54:53 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA23018 for ; Sun, 3 Feb 2002 13:54:52 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA03053; Sun, 3 Feb 2002 10:54:52 -0800 (PST) Message-Id: <200202031854.KAA03053@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: sip@ietf.org Date: Sun, 3 Feb 2002 10:54:51 -0800 Versions: dmail (solaris) 2.3/makemail 2.9b Subject: [Sip] Some sipbis-06 ABNF syntax issues Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Here are some purely syntactic issues with the ABNF in bis-06. LHEX = digit | "a" | "b" | "c" | "d" | "e" | "f" This "digit" should be "DIGIT", since that's what's defined above. quoted-pair = "\" (%x00 - %x09 | %x0b | %x0c | %x0e - %x7f) These ranges must be %x00-09 and %x0e-7f . hex4 = 1*4HEX This must be 1*4hex (or the definition of "hex" below "LHEX" could be changed to "HEX") scheme = alpha *( alpha | digit | "+" | "-" | "." ) This "digit" must also be "DIGIT". Method = "INVITE" | "ACK" | "OPTIONS" | "BYE" | "CANCEL | "REGISTER" | "PRACK" | extension-method "CANCEL" is missing the closing quote. Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF "SIP-version" should be "SIP-Version". language-range = ( ( 1*8ALPHA *( MINUS 1*8ALPHA ) ) | "*" ) These should be "alpha", not "ALPHA". credentials = ("Digest" digest-response) | (token gen-resp)) There's an extra close-paren. gen-resp = *token *((COMMA *token) | (EQUAL (*token | quoted-string)) This is missing a close paren. This allows foo=bar=baz=bip, is that intended? AuthenticationInfo __ "Authentication-Info" COLON ainfo *(COMMA ainfo) This token should be "Authentication-Info" (or its use elsewhere should be "AuthenticationInfo", and the "__" should be "=". display-name = *(token LWS)| quoted-string) There's an extra close-paren here. primary-tag = 1*8ALPHA subtag = 1*8ALPHA These need to be "1*8alpha". >From = ( "From" | "f" ) HCOLON from-spec This leading > probably doesn't belong. In-Reply-To = "In-Reply-To" HCOLON called *(COMMA called)) I suspect "called" should be "callid". realm = "realm" EQUALS realm-value This "EQUALS" should be "EQUAL". URI = absoluteURI | abs_path This "abs_path" should be "abs-path". Route = "Route" HCOLON route=param *(COMMA route-param) This "route=param" should be "route-param". Supported = ( "Supported" | "k" ) HCOLON (option-tag *(COMMA option-tag) This is missing a close paren (or has an extra close-paren). There are still two undefined tokens: parameter: Used 1 times, but not defined request-uri: Used 1 times, but not defined The comment after "request-uri" says "As specified by HTTP/1.1", so that's probably OK. It was not immediately obvious what "parameter" was supposed to be; perhaps "m-parameter". The following are not a big deal, just pointing to possible problems where something was defined to be used and then wasn't. It's probably not worth removing the unused definitions. Punctuation: ATSIGN: Defined but not used BANG: Defined but not used BAR: Defined but not used CHAR: Defined but not used CTL: Defined but not used DOT: Defined but not used DQUOT: Defined but not used LANGLE: Defined but not used LBRACK: Defined but not used PERCENT: Defined but not used PLUS: Defined but not used RANGLE: Defined but not used RBRACK: Defined but not used TILDE: Defined but not used Top-level message (this is obviously external so can't be used): SIP-message: Defined but not used Others (possibly points to a problem where these were meant to be used but weren't): TEXT-UTF8: Defined but not used separators: Defined but not used Rohan found some of the actual grammar problems that I was worried about; I'm planning to make another pass on the details of the grammar. Bill _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 3 16:55:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00430 for ; Sun, 3 Feb 2002 16:55:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11030 for sip-archive@odin.ietf.org; Sun, 3 Feb 2002 16:55:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10715; Sun, 3 Feb 2002 16:36:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10685 for ; Sun, 3 Feb 2002 16:36:13 -0500 (EST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00214 for ; Sun, 3 Feb 2002 16:36:08 -0500 (EST) Received: from jariws1 ([62.248.146.42]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020203213609.YLED1068.fep02-app.kolumbus.fi@jariws1>; Sun, 3 Feb 2002 23:36:09 +0200 Message-ID: <021801c1acfa$cd42e7c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Peterson, Jon" , "'James Undery'" , "SIP \(E-mail\)" References: <70565611B164D511957A001083FCDD56CAAE39@VA02> Subject: Re: [Sip] S/MIME, Authentication and Integrity Date: Sun, 3 Feb 2002 23:36:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I tend to agree with Jon on this issue. After thinking about this for a while and studying the SSH documentation, I think Bis 06 achieves roughly the same as SSH did. However, I believe Bis 06 text could still indicate that in the SIP world there are more of these potentially bad intermediaries as there were in the SSH case (as you indicate below). Also, I'm not sure the current text says as clearly as the SSH text does that there are three alternative methods for key verification -- config, CA, and leap-of-faith. The config option I think isn't mentioned. But I do believe James does have a point on the lack of key exchange framework. However I do not see a security difference in what SSH achieves and what we can achieve with S/MIME. But functionality-wise SSH provides session key establishment after initial authentication, which the current text in Bis 06 does not provide, as far as I can see. But this would still be doable, perhaps as a future extension of SIP in a separate RFC. For instance, assuming self signed certs are the main usage pattern, we could get away with encrypted session keys inside the first S/MIME attachment, then resorting to the symmetric crypto capabilities of S/MIME on further messages. This could be relevant for e.g. busy media servers that employ S/MIME as a means to reduce the number of public key operations. Jari ----- Original Message ----- From: "Peterson, Jon" To: "'James Undery'" ; "SIP (E-mail)" Sent: 28. tammikuuta 2002 20:21 Subject: RE: [Sip] S/MIME, Authentication and Integrity > On removal of certificates, yes, I totally agree that's an omission. I > thought we had some text about how to handle this (and a couple of similar > cases, like what happens when S/MIME is unsupported by a recipient) but now > I can't find it anywhere in the text. Hmm, been doing too much cut and paste > lately to be sure. Well, it'll be added in the build next Monday. Removal is > I think pretty easy to detect (easier that replacement), and it's fairly > obvious what you should do in that case. > > The relatively 'likeliness' of having obtained a reliable fingerprint is > debatable; there are certainly some people who use SSH that make sure to > acquire an original fingerprint from the same LAN as the host in question > before they go on a business trip or what have you. In some SIP > architectures this certainty won't be achievable - but then again, in some > it will be. Clearly there are all sorts of customary SIP intermediaries, > such as proxy servers, that potentially have carte blanche to act as MiTMs > which are not a concern in SSH. So I don't entirely disagree with you - but, > that much said, I think it's pretty clear why we draw the analogy. Perhaps > the most important similarity between the two is that the oversight of a > human is required in trust establishment. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > Sent: Monday, January 28, 2002 9:03 AM > > To: Peterson, Jon; SIP (E-mail) > > Subject: RE: [Sip] S/MIME, Authentication and Integrity > > > > > > comments inline. > > > > > -----Original Message----- > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > > > The attack is mentioned in 21.2, and discussed relatively > > > extensively in > > > 22.4.2. > > > > The replacement of a certificate is mentioned, the removal of > > certificates isn't. > > > > > The basic jist of the text is that while the use of the > > > S/MIME mechanism > > > admits of the startup MiTM attack, it nevertheless improves > > > the security of > > > SIP. We contend that this isn't entirely dissimilar to the > > > degree that SSH > > > improves telnet security. > > > > I'd agree it improves security, I'd just disagree it was anywhere near > > the amount SSH improves telnet. The reason for this is if I > > telnet to a > > machine I am much more likely to have obtained a reliable > > fingerprint/copy of the certificate for the machine. The other reason > > and the one that definately isn't addressed is the lack of > > framework for > > the key exchange, which SSH provides. > > > > James > > > > > > -----Original Message----- > > > > From: James Undery [mailto:jundery@ubiquity.net] > > > > > > Looking over section 21.4.1 I am having trouble seeing how > > > any of the > > > > claims can be justified against a MiTM attack. Without a > > > > challange/credentials framework S/MIME can't offer > > Authentication or > > > > Integrity e.g. a MiTM just removes the S/MIME protection (and > > > > optionally > > > > adds it's own). > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sun Feb 3 19:09:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01340 for ; Sun, 3 Feb 2002 19:09:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA15894 for sip-archive@odin.ietf.org; Sun, 3 Feb 2002 19:09:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15077; Sun, 3 Feb 2002 18:49:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15031 for ; Sun, 3 Feb 2002 18:49:41 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01238 for ; Sun, 3 Feb 2002 18:49:37 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g13Nn4519436 for ; Sun, 3 Feb 2002 15:49:04 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACK78998; Sun, 3 Feb 2002 15:49:09 -0800 (PST) Date: Sun, 3 Feb 2002 15:48:16 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] more BNF issues Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, In addition to some of the issues that Bill Fenner caught.... - AuthenticationInfo should use HCOLON instead of COLON - qvalue is defined twice (Accept-Encoding and Contact) - Via is really screwed a) there is currently no space of any kind between sent-protocol and sent-by: Via: SIP/2.0/UDPhost.domain.com should this be a single SP, HWS, or LWS? b) I don't think we want any space between sent-protocol and sent-by. I would use "/" instead of SLASH here.. I would redefine sent-protocol as follows: sent-protocol = SIP-Version "/" transport and delete protocol name and protocol version to be consistent with the start-line. - I propose a new HWS (horizontal white space) label HWS = ( SP | HT ) LWS = *HWS [CRLF] 1*HWS SWS = *HWS [CRLF 1*HWS] i think this makes the intent more obvious - option-tag should move down near Require - to make Contact consistent with Caller Preferences, STAR needs to migrate into the contact-param line: Contact = ("Contact" | "m") HCOLON contact-param *(COMMA contact-param) contact-param = (STAR | name-addr | addr-spec) *(SEMI contact-params) - the definition of "credentials" (Authorization header in line 5833) also needs to have LWS between "Digest" and the params. - general comment. using <'> instead of "'" would be more readable IMO - the precedence of disposition-param if ambiguous. propose: Content-Disposition = "Content-Disposition" HCOLON disposition-type *( SEMI ( disposition-param | generic-param ) ) disposition-param = "handling" EQUAL ("optional" | "required" | other-handling) - similar issue with retry-param - Accept and Content Language should use "-" instead of MINUS - i imagine rfc1123-date should be: = wkday "," SP date1 SP time SP "GMT" - in the definition of digest-chlng the "optional" brackets [] are redundant - qop-options is COMMA apropos or should it be "," SP or "," HWS - Timestamp header. i've never seen one really used, and the only example gives no mention of the second "delay" token. is this an error? ok, more later? 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 daemon@optimus.ietf.org Sun Feb 3 21:49:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03481 for ; Sun, 3 Feb 2002 21:49:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA21380 for sip-archive@odin.ietf.org; Sun, 3 Feb 2002 21:49:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20974; Sun, 3 Feb 2002 21:30:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20934 for ; Sun, 3 Feb 2002 21:30:47 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02353 for ; Sun, 3 Feb 2002 21:30:44 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g142Ux6Y011992; Sun, 3 Feb 2002 21:30:59 -0500 (EST) Message-ID: <3C5DF237.3D81B77F@dynamicsoft.com> Date: Sun, 03 Feb 2002 21:30:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] bis-06 BNF issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks for the comments. Responses inline. Rohan Mahy wrote: > > Hi, > > I'm also in the middle of a detailed bis-06 review, and haven't > finished, > but since I noticed that none of the other comments focussed on the BNF, > I > redirected my efforts there. I found several errors or questions on my > first pass, so here they are. > > The last time I thoroughly read the BNF was bis-04, so I was a bit > surprised by some of the implications of the "explicit whitespace" BNF. > Please accept my apologies if this has been discussed already. > > 1) The thing that surprised me most is that "quoted-string" allows CRLF. This has been allowed for as long as I remember. Its even allowed according to rfc2543. Quoting that: quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) qdtext = > and then, for TEXT-UTF8: TEXT-UTF8 = which explicitly calls out that LWS is allowed. THus, this is not a change. > So the following are legal according to the BNF in bis-06: > > To: " > Bob > " > > Server: MyUA/1.0 ( "A comment > that spans > many lines" ) > > WWW-Authenticate: Digest realm = " my > realm " > > Was this the intent? If so, it certainly seems to complicate parsing > and > line-folding (you cannot collapse LWS into a single SP) Lines 5812-5813 > seem to indicate that quoted text should not contain CRLF. No, these lines merely indicate that you cannot escape a CRLF by itself. THat is: From: "there is an \ esaped CRLF here" The intent, to my knowledge, has been to allow LWS in a quoted string. > > 2) Also, I think that SWS is either misdefined or used improperly > instead > of LWS in many places. Some examples: > > To: "Bob" > > > is currently valid, because LAQUOT contains SWS, and SWS does not > necessarily contain SP or HT after a CRLF. For that matter, SWS doesn't > have to contain anything, so this is also valid: > > To: "Bob" > > I am assuming the later was intended, as I think this is a good thing. > It > just might not be obvious to readers/implementors. SWS is broken in bis-06, we got many comments to that regard. The new definition is the following: LWS = [*WSP CRLF] 1*WSP ; linear whitespace SWS = [LWS] ; sep whitespace WSP is from rfc2234, its SP / HT. > > 3) Likewise the definition of "word" includes SP and HT. this may be > OK, > but I don't think it is such a good idea: > > Call-ID: ab cd@ef gh It shouldnt matter, but this does represent a change from bis-04 and bis-05. Thank goodness for bugzilla, I found the entry matching this change. We can't use token, since it rules out usage of a v6 address after the @ sign. However, I believe SP and HT shouldn't be in there, and some comments in bugzilla even expressly said it should not. Thus, I believe this is an error. I will remove. > > 4) Ampersands (&) seem to disappeer in the PDF version. perhaps this is > tex escaping issue? for example, lines: 5771 (reserved), 5817 > (headers), > 5818 (pchar) Yeah, I got all of those. It was a bug in our latex to text converter. Henning fixed it. > > 5) Reason-Phrase in 5822 seems to have -- instead of | . Already fixed that one. We've convereted to full rfc2234 compliance, by the way, so these are all going to be / instead of |. > Also, > shouldn't > you be able to include UTF8-NONASCII and UTF8-CONT in a reason phrase? Yeah, I would think thats quite important for internationalization. Good catch on that one. I will add them both. > > 6) Shouldn't message-header include an extension-header ? Doh! This doesn't appear to be in rfc2543 or any later versions of bis. I cannot believe we missed it. I will add it. I defined it as: extension-header = header-name HCOLON header-value header-name = token header-value = *(TEXT-UTF8CHAR / UTF8-CONT / LWS) which is pretty much anything but the ascii controls; except that space and tabs and CRLF are restricted to be valid linear white space. This allows you to frame an extension header no matter what its contents. > > 7) display-name in line 5838 has an extra trailing ")" Thanks, fixed. > > 8) qvalue (line 5838) has an error, it should be: > > ("0" [ "." 1*3DIGIT ] ) | > ("1" [ "." 1*3("0") ] ) > > unless you want ;q=0. Interesting. This is copied right from http 1.1, which has the same bnf exactly, and allows 0. I will assume this is OK as a result..... > > 9) the definition of "challenge" in 5855 needs some LWS: > > WWW-Authenticate: Digestrealm="foo.com",etc.... > > = "Digest" LWS digest-challenge > > or (preferably) we can resurrect auth-scheme from RFC2617 and use an > IANA > registration for sip-auth-schemes or something. Yeah, I fixed all of that already. It allows for other schemes. > > 10) Also, I know its late, but I'd like to propose that extension-method > names be limited to upalpha, or alphanum. We really don't want/need > method > names as in this example: > > *L.~ sip:foo@bar.org SIP/2.0 Another example of inheritances from HTTP. 1.1 also allows token there. As with q-value, I will note this in bugzilla, but wont change for now. I could imagine people doing things like: SET_DATA which is already beyond upalpha and alphanum. Although its aesthetically ugly, I dont see anything wrong with tokens there from a processing perspective. > > 11) no defintion of "psuedonym" (line 5872 -- warn-agent), plus > warn-agent > should use existing definition of hostport (COLONs SWS is not apropos > here). Huh? pseudonym is defined a few lines down. As per SWS, there is nothing wrong with SWS, since it is still completely parseable (warn-text would start with "). However, it is odd given the usage of SP as the separator otherwise. I'll change to hostport. > > 12) line 5818 (absoluteURI) should use ":" not COLON (don't need > whitespace in an http URL) Yup, and also segment should use ; instead of SEMI > > 13) telephone-subscriber should match definition in RFC2806 which also > allows several other characters, for example: > > * # A B C D p w ( ) Yes. That one has been fixed. The spec now points to rfc2806 for the BNF. Not sure thats the right thing either, since that bnf allows for some stuff that is not allowed in the user part... For now, it references 2806 and says you need to escape stuff that is not allowed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sun Feb 3 22:07:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03600 for ; Sun, 3 Feb 2002 22:07:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA22206 for sip-archive@odin.ietf.org; Sun, 3 Feb 2002 22:07:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21502; Sun, 3 Feb 2002 21:51:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21454 for ; Sun, 3 Feb 2002 21:51:49 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03521 for ; Sun, 3 Feb 2002 21:51:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g142pV6Y012008; Sun, 3 Feb 2002 21:51:31 -0500 (EST) Message-ID: <3C5DF707.FD26648A@dynamicsoft.com> Date: Sun, 03 Feb 2002 21:50:47 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dror@vocaltec.com CC: sip@ietf.org Subject: Re: [Sip] Possible errors in BNF definition in bis-06 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dror@vocaltec.com wrote: > > It seems to me that there are few errors in the BNF (I don't know if > they > were introduced in bis-06 or earlier) > > 1. Line-breaks are allowed to be added almost freely in the text, > breaking > many of the (english spelled) rules > COMMA = SWS "," SWS > this means that before and after every comma, CRLF sequence is allowed, > with optional leading and trailing spaces. This is an error in the definition of SWS. SWS is now defined as: LWS = [*WSP CRLF] 1*WSP SWS = [LWS] which does not permit a standalone CRLF. > > 2. No extension header is allowed (though many other items, such as > methods, define extensions) Yeah, Rohan mentioned that as well. Its been added; see my reply to his note. Its a shocker to me that it wasnt in there till now. > > 3. no CRLF after header lines. Another excellent catch. Fixed. Thanks for your comments, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sun Feb 3 22:38:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04789 for ; Sun, 3 Feb 2002 22:38:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA23361 for sip-archive@odin.ietf.org; Sun, 3 Feb 2002 22:38:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22513; Sun, 3 Feb 2002 22:21:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22410 for ; Sun, 3 Feb 2002 22:21:39 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03689 for ; Sun, 3 Feb 2002 22:21:36 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g143Lo6Y012017; Sun, 3 Feb 2002 22:21:50 -0500 (EST) Message-ID: <3C5DFE22.1E3AC9D4@dynamicsoft.com> Date: Sun, 03 Feb 2002 22:21:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner CC: sip@ietf.org Subject: Re: [Sip] Some sipbis-06 ABNF syntax issues References: <200202031854.KAA03053@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bill, Thanks for your comments and careful read. Responses inline: Bill Fenner wrote: > > Here are some purely syntactic issues with the ABNF in bis-06. > > LHEX = digit | "a" | "b" | "c" | "d" | "e" | "f" > > This "digit" should be "DIGIT", since that's what's defined above. > The BNF in bis-07 is now based on rfc2234, so we have reused DIGIT, which is defined there. I will note that rule names are case insensitive according to rfc2234, so technically LHEX is correct, but I changed it to DIGIT anyway as part of the conversion to 2234. > quoted-pair = "\" (%x00 - %x09 | %x0b | %x0c | %x0e - %x7f) > > These ranges must be %x00-09 and %x0e-7f . Good catch. Fixed. > > hex4 = 1*4HEX > > This must be 1*4hex (or the definition of "hex" below "LHEX" could be > changed to "HEX") Since we are using rfc2234, its now actually hex4 = 1*4HEXDIG and HEXDIG is defined in 2234. > > scheme = alpha *( alpha | digit | "+" | "-" | "." ) > > This "digit" must also be "DIGIT". Fixed. alpha is now also ALPHA. > > Method = "INVITE" | "ACK" | "OPTIONS" | "BYE" > | "CANCEL | "REGISTER" | "PRACK" > | extension-method > > "CANCEL" is missing the closing quote. Well, this one has changed radically. According to rfc2234, quoted strings in BNF are case insensitive. However, methods are case sensitive. To fix this, here is the new, ugly definition of Method: INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps ACKm = %x41.43.4B ; ACK in caps OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps BYEm = %x42.59.45 ; BYE in caps CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps PRACKm = %x50.52.41.43.4B ; PRACK in caps Method = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / PRACKm / extension-method Please, please look this over and make sure I didn't screw up my ascii tables. I'll buy a beer at the next IETF for anyone who can find an error in the above. > > Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF > > "SIP-version" should be "SIP-Version". Fixed, thanks. > > language-range = ( ( 1*8ALPHA *( MINUS 1*8ALPHA ) ) | "*" ) > > These should be "alpha", not "ALPHA". They are correct now as ALPHA because ALPHA is defined in 2234. > > credentials = ("Digest" digest-response) | (token gen-resp)) Already found that; note also that you missed the missing LWS between token and gen-resp.... > > There's an extra close-paren. > > gen-resp = *token *((COMMA *token) | (EQUAL > (*token | quoted-string)) > > This is missing a close paren. > > This allows foo=bar=baz=bip, is that intended? No, this BNF is wrong so far as I can tell. The bnf is now like this: Authorization = "Authorization" HCOLON credentials credentials = ("Digest" LWS digest-response) / other-response digest-response = dig-resp *(COMMA dig-resp) other-response = auth-scheme LWS auth-param *(COMMA auth-param) auth-scheme = token and this mirrors the BNF for challenge. > > AuthenticationInfo __ "Authentication-Info" COLON ainfo *(COMMA ainfo) > > This token should be "Authentication-Info" (or its use elsewhere should > be "AuthenticationInfo", and the "__" should be "=". Good catch on the token name; fixed. The __ was fixed already. > > display-name = *(token LWS)| quoted-string) > > There's an extra close-paren here. I think Rohan pointed out this one already. Fixed. > > primary-tag = 1*8ALPHA > subtag = 1*8ALPHA > > These need to be "1*8alpha". ALPHA is OK now, per 2234. > > >From = ( "From" | "f" ) HCOLON from-spec > > This leading > probably doesn't belong. Fixed. > > In-Reply-To = "In-Reply-To" HCOLON called *(COMMA called)) > > I suspect "called" should be "callid". Yup; already fixed that one. > > realm = "realm" EQUALS realm-value > > This "EQUALS" should be "EQUAL". Good eye; fixed. > > URI = absoluteURI | abs_path > > This "abs_path" should be "abs-path". Another good one. Fixed. > > Route = "Route" HCOLON route=param *(COMMA route-param) > > This "route=param" should be "route-param". Already found that one. > > Supported = ( "Supported" | "k" ) HCOLON > (option-tag *(COMMA option-tag) > > This is missing a close paren (or has an extra close-paren). It has an extra open paren. Already found that one. > > There are still two undefined tokens: > > parameter: Used 1 times, but not defined > request-uri: Used 1 times, but not defined > > The comment after "request-uri" says "As specified by HTTP/1.1", so > that's probably OK. Almost OK. Since rule names are case insensitive, and we have defined Request-URI here specifically for SIP, thats a boo-boo. I changed it to rquest-uri, and said this is equal to request-uri from HTTP/1.1. > It was not immediately obvious what "parameter" > was supposed to be; perhaps "m-parameter". Yes, I believe so. Changed to m-parameter. > > The following are not a big deal, just pointing to possible problems > where something was defined to be used and then wasn't. It's probably > not worth removing the unused definitions. > > Punctuation: > > ATSIGN: Defined but not used > BANG: Defined but not used > BAR: Defined but not used > CHAR: Defined but not used > CTL: Defined but not used > DOT: Defined but not used > DQUOT: Defined but not used > LANGLE: Defined but not used > LBRACK: Defined but not used > PERCENT: Defined but not used > PLUS: Defined but not used > RANGLE: Defined but not used > RBRACK: Defined but not used > TILDE: Defined but not used I think its OK to keep these. > > Top-level message (this is obviously external so can't be used): > > SIP-message: Defined but not used Right. > > Others (possibly points to a problem where these were meant to be > used but weren't): > > TEXT-UTF8: Defined but not used This is a good question. I don't know... maybe Henning or Brian has some idea. > separators: Defined but not used Hmm; I think that is OK. Again, maybe Henning or Brian has some idea if this is a real issue. Thanks so much for your comments!!! -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sun Feb 3 22:40:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04834 for ; Sun, 3 Feb 2002 22:40:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA23414 for sip-archive@odin.ietf.org; Sun, 3 Feb 2002 22:40:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22634; Sun, 3 Feb 2002 22:23:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22596 for ; Sun, 3 Feb 2002 22:23:05 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03700 for ; Sun, 3 Feb 2002 22:23:01 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA08426; Sun, 3 Feb 2002 22:22:59 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-40-5.mad.east.verizon.net [138.89.40.5]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g143MvJ2020063 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 3 Feb 2002 22:22:58 -0500 (EST) Message-ID: <3C5DFFDA.C4619405@cs.columbia.edu> Date: Sun, 03 Feb 2002 22:28:26 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Rohan Mahy , sip@ietf.org Subject: Re: [Sip] bis-06 BNF issues References: <3C5DF237.3D81B77F@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > This has been allowed for as long as I remember. Its even allowed > according to rfc2543. Quoting that: > > quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) > qdtext = > > > and then, for TEXT-UTF8: > > TEXT-UTF8 = but including LWS> > > which explicitly calls out that LWS is allowed. THus, this is not a > change. Also, RFC 2822, the granddaddy of all these syntax patterns, allows this explicitly, in BNF and wording: Section 3.2.5: qtext = NO-WS-CTL / ; Non white space controls %d33 / ; The rest of the US-ASCII %d35-91 / ; characters not including "\" %d93-126 ; or the quote character qcontent = qtext / quoted-pair quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS] A quoted-string is treated as a unit. That is, quoted-string is identical to atom, semantically. Since a quoted-string is allowed to contain FWS, folding is permitted. Also note that since quoted-pair is allowed in a quoted-string, the quote and backslash characters may appear in a quoted-string so long as they appear as a quoted-pair > It shouldnt matter, but this does represent a change from bis-04 and > bis-05. Thank goodness for bugzilla, I found the entry matching this > change. We can't use token, since it rules out usage of a v6 address > after the @ sign. However, I believe SP and HT shouldn't be in there, > and some comments in bugzilla even expressly said it should not. Thus, I > believe this is an error. I will remove. Yes, we had this discussion explicitly on the list. No spaces in Call-ID. > > extension-header = header-name HCOLON header-value > header-name = token > header-value = *(TEXT-UTF8CHAR / UTF8-CONT / LWS) > > which is pretty much anything but the ascii controls; except that space > and tabs and CRLF are restricted to be valid linear white space. This > allows you to frame an extension header no matter what its contents. > Below is the 2822 definition for header-value. Obviously, we'd have to replace ASCII by UTF-8. utext = NO-WS-CTL / ; Non white space controls %d33-126 / ; The rest of US-ASCII obs-utext unstructured = *([FWS] utext) [FWS] > which is already beyond upalpha and alphanum. Although its aesthetically > ugly, I dont see anything wrong with tokens there from a processing > perspective. Heck, we may need a provision for methods that correspond to the unprintable @&%$#* bubbles in comics. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 4 00:30:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06088 for ; Mon, 4 Feb 2002 00:30:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA27747 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 00:30:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27300; Mon, 4 Feb 2002 00:17:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27271 for ; Mon, 4 Feb 2002 00:17:11 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05931 for ; Mon, 4 Feb 2002 00:17:08 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g145Gp6Y012079; Mon, 4 Feb 2002 00:16:51 -0500 (EST) Message-ID: <3C5E1918.B5CD411F@dynamicsoft.com> Date: Mon, 04 Feb 2002 00:16:08 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Rohan Mahy , sip@ietf.org Subject: Re: [Sip] bis-06 BNF issues References: <3C5DFFDA.C4619405@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > > > extension-header = header-name HCOLON header-value > > header-name = token > > header-value = *(TEXT-UTF8CHAR / UTF8-CONT / LWS) > > > > which is pretty much anything but the ascii controls; except that > space > > and tabs and CRLF are restricted to be valid linear white space. This > > allows you to frame an extension header no matter what its contents. > > > > Below is the 2822 definition for header-value. Obviously, we'd have to > replace ASCII by UTF-8. > > utext = NO-WS-CTL / ; Non white space controls > %d33-126 / ; The rest of US-ASCII > obs-utext > > unstructured = *([FWS] utext) [FWS] Is there any real reason why you would allow controls? The definition above that I have given seems simpler... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 4 00:30:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06103 for ; Mon, 4 Feb 2002 00:30:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA27995 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 00:30:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27034; Mon, 4 Feb 2002 00:09:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27003 for ; Mon, 4 Feb 2002 00:09:20 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05895 for ; Mon, 4 Feb 2002 00:09:18 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1459V6Y012076; Mon, 4 Feb 2002 00:09:31 -0500 (EST) Message-ID: <3C5E1760.F325E52F@dynamicsoft.com> Date: Mon, 04 Feb 2002 00:08:48 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] more BNF issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > Hi, > > In addition to some of the issues that Bill Fenner caught.... > > - AuthenticationInfo should use HCOLON instead of COLON Fixed. > > - qvalue is defined twice (Accept-Encoding and Contact) I've already fixed that one, thanks. > > - Via is really screwed a) there is currently no space of any kind > between sent-protocol and sent-by: > > Via: SIP/2.0/UDPhost.domain.com > > should this be a single SP, HWS, or LWS? LWS. I already fixed that one. > > b) I don't think we want any space between sent-protocol and sent-by. I > would use "/" instead of SLASH here.. I would redefine sent-protocol as > follows: > > sent-protocol = SIP-Version "/" transport > > and delete protocol name and protocol version to be consistent with the > start-line. I don't feel strongly here, but am inclined to keep the current definition, as this is what has been specified in rfc2543, although with implicit LWS. Why remove it here and not other places? > > - I propose a new HWS (horizontal white space) label > > HWS = ( SP | HT ) > LWS = *HWS [CRLF] 1*HWS > SWS = *HWS [CRLF 1*HWS] Since we are using RFC2234, it defines WSP for us as your HWS. THen, we have copied the rfc2822 version of LWS, and defined SWS as [LWS]. I think that makes the intent the most clear. > > i think this makes the intent more obvious > > - option-tag should move down near Require I moved to to after Proxy-Require; this is the first reference to it. > > - to make Contact consistent with Caller Preferences, STAR needs to > migrate into the contact-param line: > > Contact = ("Contact" | "m") HCOLON contact-param *(COMMA contact-param) > contact-param = (STAR | name-addr | addr-spec) *(SEMI contact-params) Hmm. I don't know about that. When Contact is *, parameters have never been allowed. The semantics are different from Accept-Contact, where parameters make sense. I would prefer the BNF to follow the semantics rather then get consistency in the grammar of similar headers. > > - the definition of "credentials" (Authorization header in line 5833) > also > needs to have LWS between "Digest" and the params. Already fixed. > > - general comment. using <'> instead of "'" would be more readable IMO Sorry; where is it used? > > - the precedence of disposition-param if ambiguous. propose: > > Content-Disposition = "Content-Disposition" HCOLON disposition-type > *( SEMI ( disposition-param | generic-param ) ) > > disposition-param = "handling" EQUAL ("optional" | "required" | > other-handling) Already fixed, using that precedence. > > - similar issue with retry-param Already fixed, using same precedence. > > - Accept and Content Language should use "-" instead of MINUS Good catch. Fixed. > > - i imagine rfc1123-date should be: > > = wkday "," SP date1 SP time SP "GMT" Yikes, good catch. The whole idea of rfc1123-date is its supposed to be fixed length. > > - in the definition of digest-chlng the "optional" brackets [] are > redundant Indeed. I had a conversation with the authors of rfc2617 on this. They indicated that they used [] around parameters that were optional according to the protocol usage. I have kept that intention here. > > - qop-options is COMMA apropos or should it be "," SP or "," HWS I would be inclined to have no lws of any sort here, since lws inside of quoted string values is just going to far, imho. I changed it to just "," > > - Timestamp header. i've never seen one really used, and the only > example > gives no mention of the second "delay" token. is this an error? The text on delay got lost somewhere... although there isn't much use of timestamp yet, we finally have a well-defined and documented mechanism as of bis-05. I will add text on usage of the delay parameter. > > ok, more later? Sure... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 4 01:17:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06524 for ; Mon, 4 Feb 2002 01:17:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA08929 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 01:17:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29003; Mon, 4 Feb 2002 01:00:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28973 for ; Mon, 4 Feb 2002 00:59:57 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06333 for ; Mon, 4 Feb 2002 00:59:56 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g145xQ611689; Sun, 3 Feb 2002 21:59:27 -0800 (PST) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint) with SMTP id ACK80093 (AUTH rmahy); Sun, 3 Feb 2002 21:59:25 -0800 (PST) Message-Id: <200202040559.ACK80093@imop.cisco.com> Received: from 171.68.225.134 by imop.cisco.com with HTTP/1.0; Sun, 3 Feb 2002 22:00:51 -0800 Date: Sun, 3 Feb 2002 22:00:51 -0800 From: Rohan Mahy Subject: Re: [Sip] more BNF issues To: Jonathan Rosenberg Cc: Rohan Mahy , sip@ietf.org X-Mailer: Mirapoint Webmail Direct 2.9.1.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit two comments inline... [snip] >> >> sent-protocol = SIP-Version "/" transport >> >> and delete protocol name and protocol version to be consistent with the >> start-line. > >I don't feel strongly here, but am inclined to keep the current >definition, as this is what has been specified in rfc2543, although with >implicit LWS. Why remove it here and not other places? i likewise don't have strong feelings here. it just seems silly to use an explicit string for SIP-Version and then redefine the same string with some whitespace nobody will ever use. i guess i feel like we have gone a bit overboard on the WS. i thought one the main benefits of using explicit whitespace was so you could get rid of some of it! ;-) >> - general comment. using <'> instead of "'" would be more readable IMO > >Sorry; where is it used? "'" is just used once -- in the definition of token thx, -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 daemon@optimus.ietf.org Mon Feb 4 01:26:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06626 for ; Mon, 4 Feb 2002 01:26:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA09171 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 01:26:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA07212; Mon, 4 Feb 2002 01:12:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA07160 for ; Mon, 4 Feb 2002 01:12:15 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06459 for ; Mon, 4 Feb 2002 01:12:14 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g146CR6Y012104; Mon, 4 Feb 2002 01:12:27 -0500 (EST) Message-ID: <3C5E2620.F26D703C@dynamicsoft.com> Date: Mon, 04 Feb 2002 01:11:44 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: Rohan Mahy , sip@ietf.org Subject: Re: [Sip] more BNF issues References: <200202040559.ACK80093@imop.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > two comments inline... > > [snip] > > >> > >> sent-protocol = SIP-Version "/" transport > >> > >> and delete protocol name and protocol version to be > consistent with the > >> start-line. > > > >I don't feel strongly here, but am inclined to keep the > current > >definition, as this is what has been specified in rfc2543, > although with > >implicit LWS. Why remove it here and not other places? > > i likewise don't have strong feelings here. it just seems > silly to use an explicit string for SIP-Version and then > redefine the same string with some whitespace nobody will > ever use. > > i guess i feel like we have gone a bit overboard on the WS. > i thought one the main benefits of using explicit whitespace > was so you could get rid of some of it! ;-) Well, in all honest, I suspect most everyones parsers will accept lws everywhere, since its more of a burden to special case it than to just assume it is always there. > > >> - general comment. using <'> instead of "'" would be more > readable IMO > > > >Sorry; where is it used? > > "'" is just used once -- in the definition of token Actually, reading rfc2234 carefully, I do not think I can make this change. <> is used to surround rules that have a name. To me, that means the rule is defined elswehere in the bnf. There is no defined rule for ', so I dont think I can do this. Then again, maybe I am reading too much into it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 4 02:15:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15492 for ; Mon, 4 Feb 2002 02:15:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA11353 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 02:15:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10214; Mon, 4 Feb 2002 01:48:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10187 for ; Mon, 4 Feb 2002 01:48:39 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06824 for ; Mon, 4 Feb 2002 01:48:37 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 247EA4CE68; Mon, 4 Feb 2002 01:48:39 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id BAA01660; Mon, 4 Feb 2002 01:48:38 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id WAA09873; Sun, 3 Feb 2002 22:48:38 -0800 (PST) Message-Id: <200202040648.WAA09873@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jdrosen@dynamicsoft.com Subject: Re: [Sip] Some sipbis-06 ABNF syntax issues Cc: sip@ietf.org References: <200202031854.KAA03053@windsor.research.att.com> <3C5DFE22.1E3AC9D4@dynamicsoft.com> Date: Sun, 3 Feb 2002 22:48:37 -0800 Versions: dmail (solaris) 2.3/makemail 2.9b Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org >Thanks for your comments and careful read. Don't give me too much credit; it was less careful reading and more running through the ABNF parser from www.ops.ietf.org . >I will note that rule names are case insensitive according >to rfc2234 Erk. This means that the "server" and "Server" rules conflict, huh. server = [ [ userinfo "@" ] hostport ] Server = "Server" HCOLON 1*( product | comment ) I think this was already meantioned, but qvalue and response-num are also multiply-defined: qvalue = ( "0" [ "." 0*3DIGIT ] ) qvalue = ( "0" [ "." 0*3DIGIT ] ) response-num = 1*DIGIT response-num = 1*DIGIT >Please, please look this over and make sure I didn't screw up my ascii >tables. I used a handy perl script, "hextoascii", which verified that your conversions look right. Bill _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 4 02:22:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15647 for ; Mon, 4 Feb 2002 02:22:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA11642 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 02:22:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10460; Mon, 4 Feb 2002 01:59:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10429 for ; Mon, 4 Feb 2002 01:59:15 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07015 for ; Mon, 4 Feb 2002 01:59:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g146xH6Y012128; Mon, 4 Feb 2002 01:59:18 -0500 (EST) Message-ID: <3C5E311A.F093E56C@dynamicsoft.com> Date: Mon, 04 Feb 2002 01:58:34 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Rohan Mahy , Alan Johnston , "'Sanjoy Sen'" , sip@ietf.org Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks References: <3C5A5044.B6CD3292@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Responses inline. Christer Holmberg wrote: > > Hi, > > >>Assume that UA1 calls UA2. > >> > >>UA1 UA2 > >>========================== > >> > >>-----INVITE (offer 1)--> > >> > >><----183 (answer 1)----- > >> > >>-----PRACK (offer 2)---> > >> > [CH] What if UA1 receives the 200-INVITE before it even receives the > 183-INVITE (this can happen if the INVITE triggers the ringing, and the > called party picks up the phone)? UA2 will probably stop re-transmitting > the 183-INVITE after 200-INVITE has been sent, so UA1 may never get > "answer 1". It cant do that. In this case, it needs to continue retransmitting that reliable provisional response, and actually delay the 2xx, until it gets a PRACK. Note that there is no media clipping or adverse user experience as a result; its the same issue as sending a BYE only after getting ACK for the 2xx; its just a protocol thing. > Even if UA1 DOES receive the 183-INVITE later it probably > won't care about it since it has already received the 200-INVITE. I > don't think we can assume that UA1 will keep waiting for the 183-INVITE > after it has received 200-INVITE. Thats right. Indeed, because proxies won't likely forward provisionals after a final, you cannot assure delivery of reliable provisionals through a SIP network once a final has been sent. Thats why you need to delay the 2xx. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 4 03:48:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16645 for ; Mon, 4 Feb 2002 03:48:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA16983 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 03:48:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14518; Mon, 4 Feb 2002 03:14:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14489 for ; Mon, 4 Feb 2002 03:14:39 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16216 for ; Mon, 4 Feb 2002 03:14:36 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g148EMC24377; Mon, 4 Feb 2002 09:14:22 +0100 (MET) Received: from lmf.ericsson.se (lmf04630pc.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g148ELr6023172; Mon, 4 Feb 2002 10:14:21 +0200 (EET) Message-ID: <3C5E42DA.D88A35C6@lmf.ericsson.se> Date: Mon, 04 Feb 2002 10:14:18 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Rohan Mahy , Alan Johnston , "'Sanjoy Sen'" , sip@ietf.org Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks References: <3C5A5044.B6CD3292@lmf.ericsson.se> <3C5E311A.F093E56C@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>[CH] What if UA1 receives the 200-INVITE before it even receives the >>183-INVITE (this can happen if the INVITE triggers the ringing, and the >>called party picks up the phone)? UA2 will probably stop re-transmitting >>the 183-INVITE after 200-INVITE has been sent, so UA1 may never get >>"answer 1". > >It cant do that. In this case, it needs to continue retransmitting that >reliable provisional response, and actually delay the 2xx, until it gets >a PRACK. Note that there is no media clipping or adverse user experience >as a result; its the same issue as sending a BYE only after getting ACK >for the 2xx; its just a protocol thing. Well, the server would be able to send lots of free "early media"... And, if the node is a gateway the PSTN network won't know anything about it, since it assumes the connection is established. >>Even if UA1 DOES receive the 183-INVITE later it probably >>won't care about it since it has already received the 200-INVITE. I >>don't think we can assume that UA1 will keep waiting for the 183-INVITE >>after it has received 200-INVITE. >Thats right. Indeed, because proxies won't likely forward provisionals >after a final, you cannot assure delivery of reliable provisionals >through a SIP network once a final has been sent. Thats why you need to >delay the 2xx. This is an issue which was discussed a long time ago, in the "early days" of PRACK, and the understanding then was that one should NOT have to delay the 2xx, due to a number of reasons (I guess most of those were related to PSTN GW issues). And, how long would we delay the 2xx? Until the 18x time-out? I think one easy way to go would be to handle the negoatiation first, THEN alarm the user (like manyfolks handle the resource reservation first, and then alarms the user). Regards, Christer Holmberg Ericsson 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 daemon@optimus.ietf.org Mon Feb 4 03:54:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16728 for ; Mon, 4 Feb 2002 03:54:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA17373 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 03:54:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15356; Mon, 4 Feb 2002 03:28:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15325 for ; Mon, 4 Feb 2002 03:28:06 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16391 for ; Mon, 4 Feb 2002 03:28:03 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g148SJ6Y012620 for ; Mon, 4 Feb 2002 03:28:19 -0500 (EST) Message-ID: <3C5E45F5.B2C5FBB@dynamicsoft.com> Date: Mon, 04 Feb 2002 03:27:33 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] final "unify" rules for bis Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I worked through the various scenarios of offers and answers in bis, and came up with a concrete statement of where they can, and cannot be. Here is the result: 1. INVITE may contain an offer, or may be empty 2. If a UAS gets an INVITE with an offer, it MAY place the answer either in a reliable provisional, or the final 2xx, but not both (of course). It MUST NOT attempt to place an offer in any responses, provisional, or final. 3. If a UAS gets an INVITE without an offer, it MUST place an offer in either a single reliable provisional, or the final 2xx, but not both (of course). "Single" implies that it can only make a single offer. 4. If the UAC did not make an offer in the INVITE, the offer will come in either a reliable 1xx or a 2xx. In that case, the UAC MUST generate an answer in the corresponding PRACK and ACK, respectively. After that, the UAC MAY generate additional offers in PRACK (and the UAS places its answer in the corresponding 2xx PRACK) 5. If the UAC did make an offer in the INVITE, and the answer came in a reliable 1xx, the UAC MAY make subsequent offers in a PRACK (and the UAS places its answer in the corresponding 2xx PRACK). 6. If a UAS has SDP, either an offer or answer, in a reliable provisional response, it MUST NOT generate a final response until the provisional has been acknowledged. 7. Extensions specify whether offers or answers can be used with them; they must also discuss any interactions with these rules and show how the meet the requirements of o/a. Basically, the exchanges are pretty simple. Beyond the two we already know (offer in INVITE, answer in 2xx, offer in 2xx, answer in ACK) Its mostly three useful ones: INV (offer) 1xx (answer) PRACK 2xx-PRACK 2xx ACK or INV 1xx (offer) PRACK (answer) 2xx-PRACK 2xx ACK or INV (offer) 1xx (answer) PRACK (offer) 2xx PRACK (answer) 2xx ACK You can have additional offers in PRACK, but this just isn't useful since the UAC would need to wait for a provisonal to make the offer. Why these restrictions? O/A requires a few simple properties. Besides avoiding overlap, the main one is guaranteeing order. So, that made me eliminate some cases: 1. you cant make offers in any 1xx except the first. Otherwise, that offer could reach the UAC while the UAC had just sent an UPDATE or other forward request with an offer. That would require the UAC to reject the 1xx, but it cant. 2. You can't make offers in any 2xx unless its the first offer. Same reason as above, you can't reject it. My simple conclusion was thus you can't generally have offers in resposnes, since they can't be rejected. The only case where it won't be rejected is if its the first offer of the exchange. That works OK. From this, the above rules basically are distilled. With UPDATE, you get the ability to have offers in the reverse direction from callee to caller. You also get asynchronous offers from caller to callee. UPDATE is outside of bis, though. UPDATE will also need to say that a callee cant send one if it has a reliable provisional response outstanding (we discussed that on the list), but thats outside the scope of bis as well. I have placed these new rules, in more general form (so that UPDATE could add stuff and not violate them) into bis-07. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 4 03:59:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16811 for ; Mon, 4 Feb 2002 03:59:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA17608 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 03:59:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16129; Mon, 4 Feb 2002 03:34:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16098 for ; Mon, 4 Feb 2002 03:34:01 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16463 for ; Mon, 4 Feb 2002 03:33:59 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g148YE6Y012623; Mon, 4 Feb 2002 03:34:14 -0500 (EST) Message-ID: <3C5E4758.AE4C9ADF@dynamicsoft.com> Date: Mon, 04 Feb 2002 03:33:28 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner CC: sip@ietf.org Subject: Re: [Sip] Some sipbis-06 ABNF syntax issues References: <200202040648.WAA09873@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bill Fenner wrote: > > >Thanks for your comments and careful read. > > Don't give me too much credit; it was less careful reading and more > running through the ABNF parser from www.ops.ietf.org . Well, thanks for taking the time to do it and post the responses. Geez, you can't complement anyone these days.... > > >I will note that rule names are case insensitive according > >to rfc2234 > > Erk. This means that the "server" and "Server" rules conflict, huh. > > server = [ [ userinfo "@" ] hostport ] > Server = "Server" HCOLON 1*( product | comment ) Changed the former to srvr. > > I think this was already meantioned, but qvalue and response-num are > also multiply-defined: > > qvalue = ( "0" [ "." 0*3DIGIT ] ) > qvalue = ( "0" [ "." 0*3DIGIT ] ) This one I did fix before. > response-num = 1*DIGIT > response-num = 1*DIGIT This I hadn't noticed. > > >Please, please look this over and make sure I didn't screw up my ascii > >tables. > > I used a handy perl script, "hextoascii", which verified that your > conversions look right. If I spent more time writing code, and less time writing specs, I would have done a similar kind of thing. I think its nearing time to swing the pendulum back the other way... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 4 04:10:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17003 for ; Mon, 4 Feb 2002 04:10:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA18412 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 04:10:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16778; Mon, 4 Feb 2002 03:45:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16644 for ; Mon, 4 Feb 2002 03:45:32 -0500 (EST) Received: from x263.net ([218.6.2.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA16585 for ; Mon, 4 Feb 2002 03:45:19 -0500 (EST) Message-Id: <200202040845.DAA16585@ietf.org> From: "L Mi" To: Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Date: Mon, 4 Feb 2002 16:41:06 +0800 Reply-To: "L Mi" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] * To help your business succeed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Dear friend

Dear friend :

Now there are billions of email users in the world,and this amount is increasing greatly every 
year .  People are now sending informations and conducting the  internet marketing  through
email , because of its cheap cost and fast connection .  If you want to introduce and sell your
product or service ,  it would be the best way  for you  to use the  email to  contact  with  your 
targeted  customers  ( of  course you should be aware of  the  email address of the targeted  
customers  firstly  )  . Targeted  email  is no doubt very effective .  If  you could introduce your 
product or  service  through  email  directly  to  the  customer  who  are interested in them , it 
will bring to you much  more business chance and success.

We,HenXin Email Marketing Center,have many years of experience in developing & utilizing 
internet resources.We have set up global business email address databases, which  contain
millions  of   email  addresses of  commercial  enterprises and  consumers all over the world. 
These email addresses are sorted by countries and fields. By using  advanced  professional
technology, we also continuously update our databases,add new addresses ,  remove undel-
iverables and unsubscribe addresses.With the cooperation with our partners, We are able to
supply  valid targeted email  addresses  according  to  your  requirements ( for example,  you 
need some email addresses of Importers in the field of auto spare part in England ). With our 
supplied email addresses,you can easily and directly contact your potential customers.

We also supply  a  wide variety  of software. 
For example , WORLDCAST,  the software for  fast-sending emails: this software will enable 
you to send  emails  at  the rate of  over 10,000  pcs  per hour, and to release  information  to 
thousands of people in a short  time.

We are pleased to tell you that we are now offering our best prices :

          Emails  or  Software                                       Remark     Price
100,000 targeted email addresses 
We are  able  to  supply  valid  targeted  email address according to your requirements , which are all compiled  upon your order,such as region / country / occupation / field / Domain Name (like AOL.com or MSN.com) etc.

   USD 30.00 
     623,000 email addresses
                    623,000 email addresses of
     global auto parts  importer/wholesaler/distributors
 		  USD 110.00 
    8 millions email addresses
8 millions global commercial enterprises email addresses
 		  USD 240.00 
        Worldcast software 
Software for fast-sending emails 
 		   USD 39.00 
       Email searcher software  Software for searching email addresses
   USD 68.00 
        Global Trade Poster
Spreading information about your business or products over 3000 trade message boards and newgroups.  
 		  USD 125.00 
       Jet-Hits Plus 2000 Pro 
Software for submitting website to 8000+  search engines 
 		   USD 79.00 


You can order the emails or  softwares  directly  from our website.  We will send the emails 
or softwares to you by email within two working days  when we receive  your order.
For more details , please refer to our website: http://www.biz-help.com  

It is our honour if you are interested in our services or softwares.  Please do not hesitate to
contact us if any queries or concerns. It is always our pleasure to serve you.


Thanks and best regards !

                            L.Mi
Marketing Manager
Sales@biz-help.com
Http://www.biz-help.com
HenXin Email Marketing Center 

To help your business succeed, biz-help.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 daemon@optimus.ietf.org Mon Feb 4 05:59:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18314 for ; Mon, 4 Feb 2002 05:59:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA23747 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 05:59:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22632; Mon, 4 Feb 2002 05:35:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22601 for ; Mon, 4 Feb 2002 05:35:51 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18035 for ; Mon, 4 Feb 2002 05:35:47 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g14AZT6Y012664; Mon, 4 Feb 2002 05:35:29 -0500 (EST) Message-ID: <3C5E63C6.1515578C@dynamicsoft.com> Date: Mon, 04 Feb 2002 05:34:46 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] bis-07 now available Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, After much toil, bis-07 is now available. You can pick it up from: http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-07.pdf http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-07.txt http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-07.ps or http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-07.txt http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-07.pdf http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-07.ps It'll appear in the I-D editor archives shortly as well. The PDF and PS have changebars and line numbers, as always. Since there are no longer changes noted from the previous draft, here are the changes: 1. single consolidated "changes from rfc2543" section, listing major stuff. 2. BNF converted to rfc2234, countless bugs fixed based on comments 3. new loose route text incorporated. Please read this. The text is different from what Robert had described on the list. Whilst incorporating that text, we ran into a case that didn't work. TUrns out the fix simplified the whole thing even further. Based on robert's note, a proxy that wanted to route to a strict router would need to dig up the first loose router in a route set, say A, and replace that route entry with A, target, A, where target is the current r-uri. That is not the case now; it simply appends the r-uri to the bottom-most route element. This improves the backwards compatibility story, improves proxy performance, and makes things much more self consistent. Proxy processing of route/record-route is now shrunk considerably from bis-05 and bis-06. 4. split references into normative and non-normative. 5. incorporated text on generalized offer/answer mappings to SIP requests and responses 6. Reduced usage of 70 as max-forwards value from MUST to SHOULD 7. Included fix for open issue #58. When UAS generates an offer in a 2xx to re-invite, it uses the broadest SDP possible that it belives will not be rejected by its peer. 8. Added some S/MIME error cases. 9. Fixed normative strengths of S/MIME support (MUST for signed-data and certs-only). 10. Strengthened TLS/IPSec wording (fixing nits). 11. S/MIME should now be able to reuse root CAs used to verify TLS/IPSec keys. 12. Added brief statement to start of threat model section describing threat environment. 13. Added eavesdropping to threats based on body modification. 14. clarified conditions under which multiple headers can be folded into one header with comma separated values. Also pointed out exception for the Auth headers. 15. Max-Forwards needs to be between 1 and 255. 16. Added anonymous username and password for digest. 17. Clarified usage of timestamp delay parameter. THis document is now officially in working group last call! -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 4 06:10:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18533 for ; Mon, 4 Feb 2002 06:10:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA24859 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 06:10:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23311; Mon, 4 Feb 2002 05:52:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23282 for ; Mon, 4 Feb 2002 05:52:07 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18210 for ; Mon, 4 Feb 2002 05:52:02 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g14ApwX4007610; Mon, 4 Feb 2002 11:51:58 +0100 (MET) Received: from lmf.ericsson.se (lmf04630pc.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g14Apvr6004631; Mon, 4 Feb 2002 12:51:57 +0200 (EET) Message-ID: <3C5E67C7.36790376@lmf.ericsson.se> Date: Mon, 04 Feb 2002 12:51:51 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] final "unify" rules for bis References: <3C5E45F5.B2C5FBB@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I think the rules are pretty clear. A couple of issues, though. >I worked through the various scenarios of offers and answers in bis, and >came up with a concrete statement of where they can, and cannot be. Here >is the result: > >1. INVITE may contain an offer, or may be empty >2. If a UAS gets an INVITE with an offer, it MAY place the answer either >in a reliable provisional, or the final 2xx, but not both (of course). >It MUST NOT attempt to place an offer in any responses, provisional, or >final. >3. If a UAS gets an INVITE without an offer, it MUST place an offer in >either a single reliable provisional, or the final 2xx, but not both (of >course). "Single" implies that it can only make a single offer. >4. If the UAC did not make an offer in the INVITE, the offer will come >in either a reliable 1xx or a 2xx. In that case, the UAC MUST generate >an answer in the corresponding PRACK and ACK, respectively. After that, >the UAC MAY generate additional offers in PRACK (and the UAS places its >answer in the corresponding 2xx PRACK) This sounds like the UAC can generate PRACKs without receiving a provisional response, and even after it has sent ACK, so I guess it needs a little more detailed clarification. >5. If the UAC did make an offer in the INVITE, and the answer came in a >reliable 1xx, the UAC MAY make subsequent offers in a PRACK (and the UAS >places its answer in the corresponding 2xx PRACK). >6. If a UAS has SDP, either an offer or answer, in a reliable >provisional response, it MUST NOT generate a final response until the >provisional has been acknowledged. I am aware of the reason for this restriction (I brought up the reason myself in another thread, so...), but I don't think it's the best way to solve the issue (that a final response may reach the UAC before a provisional response with an offer does). If we can't send the 200 before we have received the PRACK, I see no reason to alarm the called party before we have received the PRACK... Regards, Christer Holmberg Ericsson Finland > 7. Extensions specify whether offers or answers can be used with them; > they must also discuss any interactions with these rules and show how > the meet the requirements of o/a. > > Basically, the exchanges are pretty simple. Beyond the two we already > know (offer in INVITE, answer in 2xx, offer in 2xx, answer in ACK) Its > mostly three useful ones: > > INV (offer) > 1xx (answer) > PRACK > 2xx-PRACK > 2xx > ACK > > or > > INV > 1xx (offer) > PRACK (answer) > 2xx-PRACK > 2xx > ACK > > or > > INV (offer) > 1xx (answer) > PRACK (offer) > 2xx PRACK (answer) > 2xx > ACK > > You can have additional offers in PRACK, but this just isn't useful > since the UAC would need to wait for a provisonal to make the offer. > > Why these restrictions? O/A requires a few simple properties. Besides > avoiding overlap, the main one is guaranteeing order. So, that made me > eliminate some cases: > > 1. you cant make offers in any 1xx except the first. Otherwise, that > offer could reach the UAC while the UAC had just sent an UPDATE or other > forward request with an offer. That would require the UAC to reject the > 1xx, but it cant. > > 2. You can't make offers in any 2xx unless its the first offer. Same > reason as above, you can't reject it. > > My simple conclusion was thus you can't generally have offers in > resposnes, since they can't be rejected. The only case where it won't be > rejected is if its the first offer of the exchange. That works OK. From > this, the above rules basically are distilled. > > With UPDATE, you get the ability to have offers in the reverse direction > from callee to caller. You also get asynchronous offers from caller to > callee. UPDATE is outside of bis, though. UPDATE will also need to say > that a callee cant send one if it has a reliable provisional response > outstanding (we discussed that on the list), but thats outside the scope > of bis as well. > > I have placed these new rules, in more general form (so that UPDATE > could add stuff and not violate them) into bis-07. > > Thanks, > Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 4 07:08:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19419 for ; Mon, 4 Feb 2002 07:08:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA28402 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 07:08:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27235; Mon, 4 Feb 2002 06:47:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27196 for ; Mon, 4 Feb 2002 06:47:37 -0500 (EST) Received: from sumo.vocaltec.co.il (vocaltec.co.il [199.203.72.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19171 for ; Mon, 4 Feb 2002 06:47:28 -0500 (EST) From: Dror@vocaltec.com Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135]) by sumo.vocaltec.co.il (8.10.2+Sun/8.10.2) with ESMTP id g14BjQ518753 for ; Mon, 4 Feb 2002 13:45:26 +0200 (IST) To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: Date: Mon, 4 Feb 2002 13:44:15 +0200 X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.8 |June 18, 2001) at 02/04/2002 01:44:12 PM, Serialize complete at 02/04/2002 01:44:12 PM Content-Type: text/plain; charset="us-ascii" Subject: [Sip] Some more ABNF issues - bis07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 1. TEXT-UTF8-TRIM - while the text claims it does not allow leading WS, it actually does. should be redefined as: TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) (added "1" before "*") 2. token - isn't there a requirement for a token to start with alphanum ? (e.g. current definition allows -.+!' as a valid token) 3. SIP-Version - "SIP/2.0" is the current version, but I believe SIP-Version = "SIP/" 1*DIGIT "." 1*DIGIT is the general term. 4. line-breaks: Many places allow LWS (e.g. surrounding the "=" in any URL parameter) - which are converted into a single space when parsed. The table characters should be used sparingly (if at all) 4. method-extension allows "token". see (1) above 5. parameter ambiguity for URI's. e.g: from-spec = ( name-addr = addr-spec ) *( SEMI from-param ) Cannot tell if a parameter is "from-spec" parameter, or "addr-spec" (actually, SIP-URI) parameter. Also, the format suggests that all SIP-URI parameters MUST appear before all "from-spec" parameters (otherwise, they are parsed as "extension" parameters of the "from-spec". This actually might be a "good thing" - but should be documented in English as well... Note: this is an "eye" scan, not any automated parser... Did anyone ran an automated ABNF parser, and passed the "torture test" messages ? /dror _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 4 07:13:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19533 for ; Mon, 4 Feb 2002 07:13:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA28609 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 07:13:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27514; Mon, 4 Feb 2002 06:56:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27483 for ; Mon, 4 Feb 2002 06:55:58 -0500 (EST) Received: from sumo.vocaltec.co.il (vocaltec.co.il [199.203.72.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19266 for ; Mon, 4 Feb 2002 06:55:52 -0500 (EST) From: Dror@vocaltec.com Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135]) by sumo.vocaltec.co.il (8.10.2+Sun/8.10.2) with ESMTP id g14Bru519215 for ; Mon, 4 Feb 2002 13:53:56 +0200 (IST) To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: Date: Mon, 4 Feb 2002 13:52:46 +0200 X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.8 |June 18, 2001) at 02/04/2002 01:52:42 PM, Serialize complete at 02/04/2002 01:52:42 PM Content-Type: text/plain; charset="us-ascii" Subject: [Sip] Report an error on BYE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org One thing that I think the BYE message is missing: there's no way to signal an error condition that caused the "BYE" - as reason codes are available only in responses. It would be nice if the "Warning" header was allowed, and thus a reason-code could be passed along as a hint for the reason this BYE was sent. The new BNF now actually supports it (as there's no distinction between "General-Header", "Request-Header" and "Response-Header". The absence of such reason-code means "normal user disconnect" _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 4 07:29:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20257 for ; Mon, 4 Feb 2002 07:29:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA29242 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 07:29:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28350; Mon, 4 Feb 2002 07:06:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28319 for ; Mon, 4 Feb 2002 07:05:59 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19409 for ; Mon, 4 Feb 2002 07:05:55 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g14C5nX4028244; Mon, 4 Feb 2002 13:05:50 +0100 (MET) Received: from lmf.ericsson.se (lmf04630pc.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g14C5mr6011010; Mon, 4 Feb 2002 14:05:48 +0200 (EET) Message-ID: <3C5E7915.FEA1D3D2@lmf.ericsson.se> Date: Mon, 04 Feb 2002 14:05:41 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dror@vocaltec.com CC: sip@ietf.org Subject: Re: [Sip] Report an error on BYE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Please have a look at draft-schulzrinne-sip-reason-00.txt. Regards, Christer Holmberg Ericsson Finland Dror@vocaltec.com wrote: > > One thing that I think the BYE message is missing: there's no way to > signal an error condition that caused the "BYE" - as reason codes are > available only in responses. > It would be nice if the "Warning" header was allowed, and thus a > reason-code could be passed along as a hint for the reason this BYE was > sent. > The new BNF now actually supports it (as there's no distinction between > "General-Header", "Request-Header" and "Response-Header". > The absence of such reason-code means "normal user disconnect" > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Mon Feb 4 09:25:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23222 for ; Mon, 4 Feb 2002 09:25:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04941 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 09:25:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03997; Mon, 4 Feb 2002 09:01:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03966 for ; Mon, 4 Feb 2002 09:01:28 -0500 (EST) Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22491 for ; Mon, 4 Feb 2002 09:01:23 -0500 (EST) Received: from sophia.inria.fr by sophia.inria.fr (8.11.6/8.10.0) with ESMTP id g14E1Oe10364 for ; Mon, 4 Feb 2002 15:01:24 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host django.inria.fr [138.96.88.73] claimed to be sophia.inria.fr Message-ID: <3C5E9434.F114452F@sophia.inria.fr> Date: Mon, 04 Feb 2002 15:01:24 +0100 From: Qiang Ni Organization: INRIA Sophia Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: fr, fr-FR, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Question about SIP and Cisco 3600 router?? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi,all: I'm a new-comer in SIP family. Call me Ni Qiang. Could anybody help me the following question? I have a problem with interworking between SIP and Cisco 3600 router-phone talk, for example I have configured the Voip port in C3600: dial-peer voice 100 voip destination-pattern +101 session target ipv4:138.96.252.100 codec g711ulaw And I used a SDR-3.0/SIP in a redhat Linux machine to call the phone by sip:101@138.96.252.200-----Router's IP address. The phone can ring but I can't talk between SDR/SIP/RAT and Voip phone, I think the problem come from the C3600 router can't know the audio signal from SIP machine. And I have enabled the SIP function in C3600. Anyone know how to solve such a problem? Thanks a lot! My topology is: 138.96.252.200 <------- 138.96.252.100(SIP/SDR/RAT caller) (Router C3600) | \|/ | 101(Voip phone) Ni Qiang -- *********************************** Planete Group, Sophia Antipolis,INRIA,France Qiang.Ni@sophia.inria.fr (+33) 4 92 38 79 59 *********************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 4 09:25:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23261 for ; Mon, 4 Feb 2002 09:25:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04965 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 09:26:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03532; Mon, 4 Feb 2002 08:59:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03506 for ; Mon, 4 Feb 2002 08:59:34 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22428 for ; Mon, 4 Feb 2002 08:59:31 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g14DxFC19618; Mon, 4 Feb 2002 14:59:16 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g14DxFr6018833; Mon, 4 Feb 2002 15:59:15 +0200 (EET) Message-ID: <3C5E93B1.DB54D5D@lmf.ericsson.se> Date: Mon, 04 Feb 2002 15:59:13 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Rohan Mahy , Alan Johnston , "'Sanjoy Sen'" , sip@ietf.org Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks References: <3C5A5044.B6CD3292@lmf.ericsson.se> <3C5E311A.F093E56C@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>Even if UA1 DOES receive the 183-INVITE later it probably >>won't care about it since it has already received the 200-INVITE. I >>don't think we can assume that UA1 will keep waiting for the 183-INVITE >>after it has received 200-INVITE. > >Thats right. Indeed, because proxies won't likely forward provisionals >after a final, you cannot assure delivery of reliable provisionals >through a SIP network once a final has been sent. Thats why you need to >delay the 2xx. Another place where this won't work very good is in a forking scenario. For example, assume that I have two phones. Both start ringing, and I answer one. However, if the 200 isn't sent, the other phone will keep on ringing... And, the other phone may be a phone answering machine, so it may send a final response a CANCEL will be sent to my phone... No, I agree that in a real-life scenario, where the forking proxy may be "close" to the servers, this won't happen, but in bigger scale networks it may. We should remember that the PRACK may take a completely different route than the INVITE/18x/200, due to a record-route. Regards, Christer Holmberg Ericsson 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 daemon@optimus.ietf.org Mon Feb 4 09:33:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23477 for ; Mon, 4 Feb 2002 09:33:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05830 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 09:33:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04056; Mon, 4 Feb 2002 09:01:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04027 for ; Mon, 4 Feb 2002 09:01:54 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22498 for ; Mon, 4 Feb 2002 09:01:53 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA03601; Mon, 4 Feb 2002 09:01:53 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-40-5.mad.east.verizon.net [138.89.40.5]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g14E1pJ2004125 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Feb 2002 09:01:52 -0500 (EST) Message-ID: <3C5E95D0.51E21D0C@cs.columbia.edu> Date: Mon, 04 Feb 2002 09:08:16 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Rohan Mahy , sip@ietf.org Subject: Re: [Sip] bis-06 BNF issues References: <3C5DFFDA.C4619405@cs.columbia.edu> <3C5E1918.B5CD411F@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Is there any real reason why you would allow controls? The definition > above that I have given seems simpler... > Don't know; my general answer is that it is probably wise to avoid restricting the character set without a good reason. I'll ask the editor of 2822 to see if there was a special reason. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 4 11:36:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28035 for ; Mon, 4 Feb 2002 11:36:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13394 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 11:36:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10447; Mon, 4 Feb 2002 10:46:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10416 for ; Mon, 4 Feb 2002 10:46:50 -0500 (EST) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26161 for ; Mon, 4 Feb 2002 10:46:28 -0500 (EST) From: seshashayi@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hss.hns.com (8.11.2/8.11.2) with SMTP id g14FUIl02007; Mon, 4 Feb 2002 21:00:20 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B56.0055B415 ; Mon, 4 Feb 2002 21:06:06 +0530 X-Lotus-FromDomain: HSSBLR To: Jonathan Rosenberg cc: sip@ietf.org, sip-implementors@cs.columbia.edu Message-ID: <65256B56.0055B233.00@sampark.hss.hns.com> Date: Mon, 4 Feb 2002 21:06:01 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Re: [Sip-implementors] bis-07 now available Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, A minor typo in the draft-ietf-sip-rfc2543bis-07.txt draft. (Section 7.3.1, Page 23) "The exception to this rule are the Authorization, Proxy-Authorization, Proxy-Authenticate and Proxy-Authorization headers." The Proxy-Authorization is mentioned twice.I think, one of them should be WWW-Authenticate. Rgds -Seshu seshashayi@hss.hns.com http://www.hssworld.com Jonathan Rosenberg on 02/04/2002 04:04:46 PM To: sip@ietf.org, sip-implementors@cs.columbia.edu cc: (bcc: Seshashayi T/HSSBLR) Subject: [Sip-implementors] bis-07 now available Folks, After much toil, bis-07 is now available. You can pick it up from: http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-07.pdf http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-07.txt http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-07.ps or http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-07.txt http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-07.pdf http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-07.ps It'll appear in the I-D editor archives shortly as well. The PDF and PS have changebars and line numbers, as always. Since there are no longer changes noted from the previous draft, here are the changes: 1. single consolidated "changes from rfc2543" section, listing major stuff. 2. BNF converted to rfc2234, countless bugs fixed based on comments 3. new loose route text incorporated. Please read this. The text is different from what Robert had described on the list. Whilst incorporating that text, we ran into a case that didn't work. TUrns out the fix simplified the whole thing even further. Based on robert's note, a proxy that wanted to route to a strict router would need to dig up the first loose router in a route set, say A, and replace that route entry with A, target, A, where target is the current r-uri. That is not the case now; it simply appends the r-uri to the bottom-most route element. This improves the backwards compatibility story, improves proxy performance, and makes things much more self consistent. Proxy processing of route/record-route is now shrunk considerably from bis-05 and bis-06. 4. split references into normative and non-normative. 5. incorporated text on generalized offer/answer mappings to SIP requests and responses 6. Reduced usage of 70 as max-forwards value from MUST to SHOULD 7. Included fix for open issue #58. When UAS generates an offer in a 2xx to re-invite, it uses the broadest SDP possible that it belives will not be rejected by its peer. 8. Added some S/MIME error cases. 9. Fixed normative strengths of S/MIME support (MUST for signed-data and certs-only). 10. Strengthened TLS/IPSec wording (fixing nits). 11. S/MIME should now be able to reuse root CAs used to verify TLS/IPSec keys. 12. Added brief statement to start of threat model section describing threat environment. 13. Added eavesdropping to threats based on body modification. 14. clarified conditions under which multiple headers can be folded into one header with comma separated values. Also pointed out exception for the Auth headers. 15. Max-Forwards needs to be between 1 and 255. 16. Added anonymous username and password for digest. 17. Clarified usage of timestamp delay parameter. THis document is now officially in working group last call! -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/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 daemon@ns.ietf.org Mon Feb 4 11:51:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28680 for ; Mon, 4 Feb 2002 11:51:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14531 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 11:51:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12462; Mon, 4 Feb 2002 11:26:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12430 for ; Mon, 4 Feb 2002 11:26:02 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27611 for ; Mon, 4 Feb 2002 11:25:59 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 2850D1E052; Mon, 4 Feb 2002 11:26:02 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA12203; Mon, 4 Feb 2002 11:25:50 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id IAA14563; Mon, 4 Feb 2002 08:25:51 -0800 (PST) Message-Id: <200202041625.IAA14563@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: dror@vocaltec.com Subject: Re: [Sip] Some more ABNF issues - bis07 Cc: sip@ietf.org Date: Mon, 4 Feb 2002 08:25:50 -0800 Versions: dmail (solaris) 2.3/makemail 2.9b Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org >Did anyone ran an automated ABNF parser, and passed the "torture test" >messages ? I've been running the one from http://www.ops.ietf.org/, but I've been fixing parser bugs as well as grammar bugs, so don't take everything it says to heart. Problems I've found in sipbis-07 so far: Jonathan's suspicion was correct, <"> doesn't work; my guess is you should use %x22 . There's still a | seperator before ttl-param. Probably didn't catch it because of the lack of whitespace. "nextnonce" and "composite-type" are missing an '=' between the rule name and definition. Here are the warnings at the end: rquest-uri: Used 1 times, but not defined This is the reference to HTTP/1.1 . start-line: Used 1 times, but not defined This is from the ABNF in section 7, defining generic-message, but there's no ABNF defining start-line. Is this ABNF still supposed to be in section 7, or should it have moved to section 27 too? telephone-subscriber: Used 1 times, but not defined This is imported from RFC 2806. ATSIGN: Defined but not used BANG: Defined but not used BAR: Defined but not used BIT: Defined but not used CHAR: Defined but not used CTL: Defined but not used digest-uri-value: Multiply defined This is from the ABNF in section 7 and 27; they both have the same definition. DOT: Defined but not used DQUOT: Defined but not used DQUOTE: Defined but not used generic-message: Defined but not used LANGLE: Defined but not used LBRACK: Defined but not used LWSP: Defined but not used MINUS: Defined but not used PERCENT: Defined but not used PLUS: Defined but not used RANGLE: Defined but not used RBRACK: Defined but not used separators: Defined but not used SIP-message: Defined but not used TEXT-UTF8: Defined but not used TILDE: Defined but not used VCHAR: Defined but not used TEXT-UTF8char: Referred to as TEXT-UTF8CHAR This is not a big deal, since names are case-insensitive, but it's a possible source of confusion (as it was for me before I realized that names are case-insensitive.) Bill _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 4 12:06:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29471 for ; Mon, 4 Feb 2002 12:06:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16616 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 12:06:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13783; Mon, 4 Feb 2002 11:40:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13752 for ; Mon, 4 Feb 2002 11:40:16 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28252 for ; Mon, 4 Feb 2002 11:40:13 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id ABAEE4CE6C for ; Mon, 4 Feb 2002 11:40:15 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA12671 for ; Mon, 4 Feb 2002 11:40:15 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id IAA14839; Mon, 4 Feb 2002 08:40:15 -0800 (PST) Message-Id: <200202041640.IAA14839@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: sip@ietf.org Subject: Re: [Sip] Some more ABNF issues - bis07 Date: Mon, 4 Feb 2002 08:40:14 -0800 Versions: dmail (solaris) 2.3/makemail 2.9b Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org >Jonathan's suspicion was correct, <"> doesn't work; my guess is you >should use %x22 . I take this back. <"> is a legal prose-val; however it doesn't have the semantics of "exactly a quote"; it says "implementor must interpret what's inside the angle brackets and decide what to do". %x22 is more precise. Bill _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 4 12:07:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29511 for ; Mon, 4 Feb 2002 12:07:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16665 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 12:07:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14506; Mon, 4 Feb 2002 11:51:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14437 for ; Mon, 4 Feb 2002 11:51:10 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28611 for ; Mon, 4 Feb 2002 11:49:11 -0500 (EST) Received: from jku.dynamicsoft.com (ds63-113-46-158.dynamicsoft.com [63.113.46.158]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g14GmOH24251; Mon, 4 Feb 2002 17:48:24 +0100 Message-Id: <5.1.0.14.0.20020204172630.030224d8@mailhost.fokus.gmd.de> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Feb 2002 17:33:44 +0100 To: Jonathan Rosenberg , Rohan Mahy From: Jiri Kuthan Subject: Re: [Sip] more BNF issues Cc: Rohan Mahy , sip@ietf.org In-Reply-To: <3C5E2620.F26D703C@dynamicsoft.com> References: <200202040559.ACK80093@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > i likewise don't have strong feelings here. it just seems >> silly to use an explicit string for SIP-Version and then >> redefine the same string with some whitespace nobody will >> ever use. >> >> i guess i feel like we have gone a bit overboard on the WS. >> i thought one the main benefits of using explicit whitespace >> was so you could get rid of some of it! ;-) > >Well, in all honest, I suspect most everyones parsers will accept lws >everywhere, since its more of a burden to special case it than to just >assume it is always there. Well, that depends on what you think that a special case is. In my opinion, useless whitespacess are a special case since they take additional code. The more code, the less speed, the more bugs. I don't feel strongly about what we do now, but when building a new protocol I will strongly recommend against too much liberalism. -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 daemon@ns.ietf.org Mon Feb 4 12:48:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01153 for ; Mon, 4 Feb 2002 12:48:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19481 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 12:48:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17504; Mon, 4 Feb 2002 12:16:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17461 for ; Mon, 4 Feb 2002 12:16:19 -0500 (EST) Received: from mxout1.netvision.net.il (mxout1.netvision.net.il [194.90.9.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29833 for ; Mon, 4 Feb 2002 12:16:15 -0500 (EST) Received: from nt-mail.tlv.radvision.com ([212.143.185.30]) by mxout1.netvision.net.il (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GR00056KQMCC0@mxout1.netvision.net.il> for sip@ietf.org; Mon, 04 Feb 2002 19:15:48 +0200 (IST) Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2650.21) id <11LMPKAW>; Mon, 04 Feb 2002 19:15:27 +0200 Content-return: allowed Date: Mon, 04 Feb 2002 19:15:20 +0200 From: Boris Perlov To: "'sip@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sip] Question according to draft-ietf-sip-srv-04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hi all, in "draft-ietf-sip-srv-04" paragraph "4.2 Determining Port and IP" of the client DNS usage, it is specified that "...If the TARGET was not a numeric IP address, and no port was present in the URI the client performs an SRV query using the service identifier _sip and the transport protocol as determined from section 4.1 ...". It is not clear what should be done if no SRV records are found. Previous version of the rfc2543 (bis 05), in case when no SRV records are found, requires to apply 'A'/'AAAA' class DNS query. Thanks, Boris Perlov _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 4 13:02:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01563 for ; Mon, 4 Feb 2002 13:02:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20477 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 13:02:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18074; Mon, 4 Feb 2002 12:25:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18045 for ; Mon, 4 Feb 2002 12:25:14 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00148 for ; Mon, 4 Feb 2002 12:25:10 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id C93FC1E052 for ; Mon, 4 Feb 2002 12:25:13 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA14405; Mon, 4 Feb 2002 12:25:10 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id MAA76667; Mon, 4 Feb 2002 12:26:51 -0500 (EST) Date: Mon, 4 Feb 2002 12:26:51 -0500 (EST) Message-Id: <200202041726.MAA76667@fish.research.att.com> To: sip@ietf.org Subject: [Sip] Last Call comments on 2543bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I see that most of my editorial corrections to bis-06 were ignored by the editors. While I accept that as editor's discression, there were a number that I feel are more important. These I'm repeating here as last-call comments. 1) I'm still concerned by the number of "untestable MUSTs" in bis-07. For example, an implementation of a UA has no control over definition of future extensions of SIP, yet those are given as MUST-strength requirements. Example, in lines: 889: All new header fields MUST follow this generic format... 1298: specification of a new extension MUST include discussion... 3140-2: Protocol extensions ... SHOULD use two transactions... 2) Carriers are unfortunately obliged to meet regulatory requirements. At least some of these, related to Electronic Surveillance, will not be standardized by IETF (see RFC 2804), though publication is encouraged (presumably as informational RFCs). However, they may require extensions to SIP, and definition of additional headers and option tags. It would be unfortunate if this resulting protocol could not be called SIP. This is an ugly subject, granted, and I do not want it to delay publication of bis as an RFC. My proposed resolution of this is to have bis make reference to draft-tsvarea-sipchange-xx for the guidelines of extensions being standard-track RFCs, and have the discussion when that draft is re-issued and last-called. Affects lines 1094-7, 1103-4, 1306-7 3) The Content-Length header may need to be added by a proxy, like if the UA sent the request/response via UDP without one, and the proxy uses TCP. Nowhere is this allowed. Affects Table 2, line for Content-Length, column for Proxy, change to "amr". 4) When a dialog exists due to a provisional response, the 2xx response moves it to "confirmed" (lines 2091-3). However, the local sequence number can't be reset to the value of the request - that would result in the same CSeq being used as was in a PRACK. So the reference to Section 12.1.2 in line 2093 is wrong. I believe the solution is to reference Section 12.2.1.2, which updates the dialog state (and consider the INVITE as a "route refresh request"). Line 2094 would then need a change, "in the same fashion" to "using the procedures of Section 12.1.2" Some editorial stuff I mentioned before that still _needs_ to be fixed: 1081: bad cross reference to "sec:proxy-response-processing-via" 2719.5: add "record route" between steps 1 & 2, to match the description. 2665: wrong cross reference, should probably be "Step 3" 4776: bad cross reference to "sec:header-fields" 6316: rfc1806 has been supersceeded by 2183 Some editorial stuff that _really should_ be fixed, but was overlooked: 1385: s/GSTN/PSTN/ (for consistency with PSTN in rest of document) 2740: remove the stray semicolon 3494: s/MUSTcontain/MUST contain/ 3495: s/MUSTinclude/MUST include/ 3524: s/MUSTbe/MUST be/ 5018: s/case- sensitive/case-sensitive/ 6075: s/optio/option/ 6077: needs a closing right bracket Bill Marshall wtm@research.att.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 daemon@ns.ietf.org Mon Feb 4 15:20:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04982 for ; Mon, 4 Feb 2002 15:20:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA28707 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 15:20:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26818; Mon, 4 Feb 2002 14:44:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26792 for ; Mon, 4 Feb 2002 14:44:00 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04172 for ; Mon, 4 Feb 2002 14:43:56 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.45]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g14Ji86Y012926; Mon, 4 Feb 2002 14:44:09 -0500 (EST) Message-ID: <3C5EE45D.719193BE@dynamicsoft.com> Date: Mon, 04 Feb 2002 14:43:25 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 References: <200202041726.MAA76667@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > > I see that most of my editorial corrections to bis-06 were ignored > by the editors. While I accept that as editor's discression, there > were a number that I feel are more important. These I'm repeating here > as last-call comments. No, they were not ignored. We did not get to them. THere were tons of comments, Bill, and there was no way to get them all in before bis-07. We are not supermen, and it was already quite an effort to get this out with all the bnf comments and the new loose route, unify, and other text. One of us will answer your comments on the list shortly. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Mon Feb 4 17:41:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07413 for ; Mon, 4 Feb 2002 17:41:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04920 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 17:41:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03722; Mon, 4 Feb 2002 17:10:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03691 for ; Mon, 4 Feb 2002 17:10:24 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06935 for ; Mon, 4 Feb 2002 17:10:21 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g14Lw7202259; Mon, 4 Feb 2002 15:58:07 -0600 Message-ID: <3C5F03EE.9090408@dynamicsoft.com> Date: Mon, 04 Feb 2002 15:58:06 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: John.Hearty@Level3.com CC: sip@ietf.org Subject: Re: [Sip] Yet more bis-06 comments/nits References: <17052388D394D411803900508BDFFAF601B371A8@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks for the scrutiny John - this is great help. We got many of these before -07 was released. I fixed the rest of the nits today and entered bugs against the bigger issues. See responses inline - John.Hearty@Level3.com wrote: > Final comments in case anyone is working the weekend to get these in > bis-07. This was a crash review so I'm sure I missed plenty, but must say I > am very impressed with how this document is shaking out. Excellent work by > all. > > John Hearty > Level3 > > > >>1. Section 3 in the text version (PDF version OK) is missing >>a space in "SHALL NOT" (carried over from bis-05). This is an artifact of the tool used to build .txt files from the TeX output (as are many of the other comments below). For some of these we can fix the tool. For others, we'll have to make manual fixes after processing. In the interim builds, we're catching what we need to in order for the text to be legible. More attention to the layout detail will go into the final build (afaik, the RFC editor will still push it all through an NROFF step to produce the RFC text version, so there is a point of diminishing returns with fighting the margin format type errors during these steps). Keep reporting these kinds of errors as you see them though. >> >>2. The text on figure 1 on page 11 is all messed up in the >>pdf version. Looks like a different language. Fixed >> >>3. Line 389 indicates the example contains a minimum required >>set, but the newly mandatory Max-Forwards is not included. >>Max-Forwards also appears to be missing in other examples >>that otherwise appear to have the other minimum required >>headers, such as sections 11.1, 11.2, 21.4.1 (see note >> > > also 17.1.1.3 > > >>below), 21.4.2, and all requests in section 26. Note, it is >>debatable whether a Max-Forwards is required in a tunneled >>Invite as in section 21.4.1, this should get a bit of list >>discussion. My take is yes, incase some B2BUA or something >>takes it out and forwards it un-tunneled. I see no reason to >>special-case this. I did a global pass through the document and added Max-Forwards to example requests that were supposed to be complete, including inside the referenced tunnelled message. >> >>4. Section 4, the example 200 OK has the Via list messed up. >>Looks like the first Via in the list (line 456) should be the >>last one (line 458). The last Via has the wrong branch >>compared to the Invite example. The first Via should >>probably have the biloxi domain in it, not the atlanta >>domain, and something different than pc33 to avoid reader >>confusion with the Via added by Alice's PC. Fixed >> >>5. Line 1040, I can't recall in the list discussion if there >>was any specific reason to disallow the value from being more >>or less than the selected value of 70 beyond future proofing >>this for really big networks. The current wording locks UACs >>into always putting 70 in the header. I can see including >>the header is a MUST, but wonder if the stated value of 70 >>should be a SHOULD or RECOMMENDED to allow UAs some leeway. Changed text to reflect SHOULD and motivate the choice of 70. >> >>6. Line 1151, is timeout the ONLY thing the TU will see? >>What happens when an ICMP host unreachable is returned? Does >>that not get to the TU? Related to this, should line 1184 >>"or network timeouts" be "or network failures"? This didn't get fixed for -07 - I've opened a bug against it. >> >>7. Line 1172 references non-existent section 22.10. Fixed >> >>8. Line 1334, sooon should be soon. Fixed >> >>9. Line 1351, delete last "the" in the line (grammar). Fixed >> >>10. Line 1353, "amd" should be "and". Fixed >> >>11. Line 1356 "complete" should be "completely". Fixed >> >>12. Section 10.1 of the text version has a space before a >>comma in three places. PDF version is OK (lines 1493-1495). >>This was also a problem carried over from bis-05. conversion to text (see 1) >> >> >>Continued: >> >>13. Line 1601, remove period after "using". Fixed >> >>14. Line 1668, "MUST then converted" should be "MUST then be >>converted". Fixed >> >>15. Releated to item 5 above, lines 1718-1722 imply varying >>values of Max-Forwards can be sent by a UA, in conflict with >>the language in line 1040. Fixed (See 5) >> >>16. Line 1792, remove dash after "method". Fixed >> >>17. Looks like conversion corruption is taking place after >>italicized words "route set". Section 12.2.1.1, 12.2.1.2 and >>12.2.2 in the text version has some missing text compared to >>the PDF version lines 1909, 1915, 1923 and 1976. There is an >>unneeded space in the text version between "route set" and >>following comma (corresponding to line 1911, 1937, 1962 and >>1977 in PDF). There is a missing period in the text version >>after "route set" corresponding to line 1939. I think I got all these for -07, let me know if you still see something broken. >> >>18. Line 2059, "construction" should be "constructing" >>(carried over from bis-05). Fixed >> >>19. The text version has indented text corresponding to PDF >>version lines 2267-2268 which is not indented. text conversion (see 1) >> >>20. Line 2288, "BYE of CANCEL" should be "BYE or CANCEL". Fixed >> >>21. The text version has indented text corresponding to PDF >>version lines 2290-2292 which is not indented. 21 through 24 are text conversion (see 1) >> >>22. Line 2406 has "request." which is missing in >>corresponding text version section 16.3. >> >>23. Lines 2428-2429 in PDF are indented, corresponding text >>in text version is not indented. >> >>24. Lines 2574-2577 in PDF are indented, corresponding text >>in text version is not indented. >> >>25. Line 2583 is related to items 5 and 15 above. Also, >>whatever verbage is arrived at on that issue, should have a >>MUST to add the Max-Forwards (it's currently lower case). >>This is because section 16.3 #2 allows missing Max-Forwards, >>and #3 following it allows loop detection to be optional. >>With those two items, a proxy MUST add the Max-Forwards >>header if missing to prevent loops from going undetected. Fixed (see 5) >> >>26. Line 2595, "wishes remain" should be "wishes to remain". Fixed >> >>27. Line 2598 in PDF is indented, corresponding text in text >>version is not indented. 27-29 are text conversion (see 1) >> >>28. Lines 2603-2605 in PDF are indented, corresponding text >>in text version is not indented. >> >>29. Lines 2616-2618 in PDF are indented, corresponding text >>in text version is not indented. >> >>30. Line 2650, "by transaction" should be "by the transaction". Fixed >> >>31. Line 2671, "address that ordered set" should be "address >>in that ordered set". Fixed >> >>32. Line 2679, "MUST set" should be "MUST be set". Fixed >> >>33. Lines 2729-2732 in PDF are indented, corresponding text >>in text version is not indented. 33-35 are text conversion (see 1) >> >>34. Lines 2749-2754 in PDF are indented, corresponding text >>in text version is not indented. >> >>35. Lines 2802-2807 in PDF are indented, corresponding text >>in text version is not indented. >> > > 36. Line 3132 has space before period. This also resulted in period > wrapping to next line in text version. Fixed > > 37. Line 3140-3141 "that that" should be "that". Fixed > > 38. Section 17.2.1 Figure 7 title is too low, overwriting the page footer. > Same for figure 8 under section 17.2.3. Bug entered against this > > 39. Section 18.1 and 18.2 in the text version has multiple occurences of > missing text and space before comma corruption problems following instances > of "100rel". text formatting (see 1), but I think I may have avoided the bug with a minor change to the source - See if this goes away in -08. > > 40. Line 3385, "a Unsupported" should be "an Unsupported". Fixed > > 41. Line 3400, "must contain Require header" should be "must contain a > Require header". Fixed > > 42. Line 3545, don't stateful proxies also forward stray responses > statelessly? If so, the word "stateless" in this line might best be > removed. > Yes, transaction stateful proxies would forward strays statelessly. However, they don't forward _all_ responses, so striking the word stateless isn't the right change. We'll clean this up. > 43. Line 4588, what about TLS transport (port 5061)? Well, this gets interesting. Turns out that to align with sip-srv, this whole rule is going to go away. sip:foo;transport=tls is not equivalent to sip:foo:5061;transport=tls and more shockingly sip:foo is not equivalent to sip:foo:5060 This is because sip:foo and sip:foo:5060 will resolve differently (potentially to different addresses) under the mechanisms in sip-srv There is a bug against the URI section to modify this bullet accordingly. > > 44. Line 4600 has bad section link. Fixed > > 45. Line 5264-5266 should probabally be reworded a little in light of > 100rel. Done. > > 46. Line 5414, bad section reference. Fixed > > 47. Section 26.2 Via headers (other than top Via) are missing received= parm > where required since changing to FQDNs. bug entered > > 48. Section 26 Via headers in 26.1 F1, F2, and 26.2 F13 & F14 are not > changed to Recommended FQDN. bug entered > > 49. Lines 5734-5735 are extraneous and should be removed. *Laugh* - you are _too_ kind... They are gone. > > > John Hearty > Level3 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Mon Feb 4 19:04:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08723 for ; Mon, 4 Feb 2002 19:04:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA10014 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 19:04:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08288; Mon, 4 Feb 2002 18:36:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08257 for ; Mon, 4 Feb 2002 18:36:53 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08326 for ; Mon, 4 Feb 2002 18:36:49 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g14NOb202427; Mon, 4 Feb 2002 17:24:37 -0600 Message-ID: <3C5F1835.60708@dynamicsoft.com> Date: Mon, 04 Feb 2002 17:24:37 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 References: <200202041726.MAA76667@fish.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > I see that most of my editorial corrections to bis-06 were ignored > by the editors. While I accept that as editor's discression, there > were a number that I feel are more important. These I'm repeating here > as last-call comments. > > 1) I'm still concerned by the number of "untestable MUSTs" in bis-07. > For example, an implementation of a UA has no control over definition > of future extensions of SIP, yet those are given as MUST-strength > requirements. Example, in lines: > 889: All new header fields MUST follow this generic format... > 1298: specification of a new extension MUST include discussion... > 3140-2: Protocol extensions ... SHOULD use two transactions... This class of requirement is obviously on future specifications, not implementations. As such, you could argue that they belong in the guidelines draft. I would have no problem moving the three examples you present here, but I get the feeling that this isn't a complete list. Is requirements on future extensions the _only_ class of requirements giving you trouble? > > 2) Carriers are unfortunately obliged to meet regulatory requirements. > At least some of these, related to Electronic Surveillance, will not > be standardized by IETF (see RFC 2804), though publication is > encouraged (presumably as informational RFCs). However, they may require > extensions to SIP, and definition of additional headers and option tags. > It would be unfortunate if this resulting protocol could not be called > SIP. This is an ugly subject, granted, and I do not want it to delay > publication of bis as an RFC. My proposed resolution of this is > to have bis make reference to draft-tsvarea-sipchange-xx for the > guidelines of extensions being standard-track RFCs, and have the > discussion when that draft is re-issued and last-called. > Affects lines 1094-7, 1103-4, 1306-7 I'll let the chairs comment on this. > > 3) The Content-Length header may need to be added by a proxy, like > if the UA sent the request/response via UDP without one, and the proxy > uses TCP. Nowhere is this allowed. Affects Table 2, line for > Content-Length, column for Proxy, change to "amr". Bug entered - this will be fixed in -08. > > 4) When a dialog exists due to a provisional response, the 2xx response > moves it to "confirmed" (lines 2091-3). However, the local sequence > number can't be reset to the value of the request - that would result > in the same CSeq being used as was in a PRACK. So the reference to > Section 12.1.2 in line 2093 is wrong. I believe the solution is to > reference Section 12.2.1.2, which updates the dialog state (and > consider the INVITE as a "route refresh request"). Line 2094 would > then need a change, "in the same fashion" to "using the procedures of > Section 12.1.2" The sentence says to update the route set as per 12.1.2, not follow all of 12.1.2. This will be made more clear. 12.2.1.2 isn't strong enough, the route-set really does get replaced when transitioning from early to confirmed. Only the remote target gets updated by route refresh requests (suggesting they are now badly named). I agree with the change to "in the same fashion". > > Some editorial stuff I mentioned before that still _needs_ to be fixed: > 1081: bad cross reference to "sec:proxy-response-processing-via" fixed > 2719.5: add "record route" between steps 1 & 2, to match the description. done > 2665: wrong cross reference, should probably be "Step 3" I disagree - it is a reference to what endpoints do with Record-Route, not proxies. > 4776: bad cross reference to "sec:header-fields" fixed > 6316: rfc1806 has been supersceeded by 2183 bug entered > > Some editorial stuff that _really should_ be fixed, but was overlooked: > 1385: s/GSTN/PSTN/ (for consistency with PSTN in rest of document) changed > 2740: remove the stray semicolon done > 3494: s/MUSTcontain/MUST contain/ done > 3495: s/MUSTinclude/MUST include/ done > 3524: s/MUSTbe/MUST be/ dine > 5018: s/case- sensitive/case-sensitive/ done > 6075: s/optio/option/ done > 6077: needs a closing right bracket done _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 4 19:11:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08848 for ; Mon, 4 Feb 2002 19:11:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA10200 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 19:11:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09020; Mon, 4 Feb 2002 18:51:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08987 for ; Mon, 4 Feb 2002 18:51:42 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08506 for ; Mon, 4 Feb 2002 18:51:31 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA27586; Mon, 4 Feb 2002 18:51:27 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g14NpQJ2024230 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Feb 2002 18:51:27 -0500 (EST) Message-ID: <3C5F1DB8.D617CC97@cs.columbia.edu> Date: Mon, 04 Feb 2002 18:48:08 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: William Marshall , sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 References: <200202041726.MAA76667@fish.research.att.com> <3C5F1835.60708@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > This class of requirement is obviously on future specifications, not > implementations. As such, you could argue that they belong in the > guidelines draft. I would have no problem moving the three examples you > present here, but I get the feeling that this isn't a complete list. Is > requirements on future extensions the _only_ class of requirements > giving you trouble? My suggestion is that all of them should move into or close to the IANA sections, since they are needed by things that need IANA registration in any event. The section can then be prefixed by a "this is for specifying compliancy of protocol designers, not implementations" (obviously, not worded that 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 daemon@ns.ietf.org Mon Feb 4 19:35:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09234 for ; Mon, 4 Feb 2002 19:35:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA11519 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 19:35:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10502; Mon, 4 Feb 2002 19:20:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10473 for ; Mon, 4 Feb 2002 19:19:59 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09018 for ; Mon, 4 Feb 2002 19:19:57 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 2F12A4CE0D; Mon, 4 Feb 2002 19:19:58 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA24850; Mon, 4 Feb 2002 19:19:55 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id TAA21479; Mon, 4 Feb 2002 19:22:01 -0500 (EST) Date: Mon, 4 Feb 2002 19:22:01 -0500 (EST) Message-Id: <200202050022.TAA21479@fish.research.att.com> To: rsparks@dynamicsoft.com Cc: hgs@cs.columbia.edu, sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Henning Schulzrinne wrote: > Robert Sparks wrote: > > This class of requirement is obviously on future specifications, not > > implementations. As such, you could argue that they belong in the > > guidelines draft. I would have no problem moving the three examples you > > present here, but I get the feeling that this isn't a complete list. Is > > requirements on future extensions the _only_ class of requirements > > giving you trouble? > > My suggestion is that all of them should move into or close to the IANA > sections, since they are needed by things that need IANA registration in > any event. The section can then be prefixed by a "this is for specifying > compliancy of protocol designers, not implementations" (obviously, not > worded that way...) This suggestion works fine for me. I'd then re-word the lines where the spec words now appear as simple statements of fact, e.g.. "All new header fields follow this generic format..." And, that is the _only_ class of requirements giving me major trouble. There was a second class of requirements that I mentioned previously, (though not enough to raise in my email this morning). Several places in the draft are spec words about inter-layer communication in the reference design. For example, line 2335 says "UAS core ... MUST pass [the 2xx response] to the server transaction for transmission." I believe normative language about retransmission of 2xx responses to non-INVITEs is covered elsewhere, and this could be re-written as "UAS core ... passes [the 2xx response] to the server transaction..." and thus avoid specifying the reference design as a MUST. I'll leave these to the editor's discression. Bill Marshall wtm@research.att.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 daemon@ns.ietf.org Mon Feb 4 19:40:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09290 for ; Mon, 4 Feb 2002 19:40:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA11609 for sip-archive@odin.ietf.org; Mon, 4 Feb 2002 19:40:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10803; Mon, 4 Feb 2002 19:25:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10774 for ; Mon, 4 Feb 2002 19:25:09 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09105 for ; Mon, 4 Feb 2002 19:25:07 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA04211; Mon, 4 Feb 2002 19:25:07 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g150P6J2024963 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Feb 2002 19:25:06 -0500 (EST) Message-ID: <3C5F259C.1544665@cs.columbia.edu> Date: Mon, 04 Feb 2002 19:21:48 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: rsparks@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 References: <200202050022.TAA21479@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree that having a MUST or SHOULD in simple behavioral statements just makes the text hard to read and monotonous. This is a fine line to walk, since some people would want every sentence with a verb to have a MUST before the verb. I tend to think of MUST and SHOULD as emphasis, where it is likely that an implementor will do something different if left to her own devices, rather than just describing routine behavior. Others likely disagree. > non-INVITEs is covered elsewhere, and this could be re-written as > "UAS core ... passes [the 2xx response] to the server transaction..." > and thus avoid specifying the reference design as a MUST. I'll > leave these to the editor's discression. > > Bill Marshall > wtm@research.att.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 daemon@optimus.ietf.org Tue Feb 5 04:04:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25538 for ; Tue, 5 Feb 2002 04:04:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA14236 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 04:04:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12929; Tue, 5 Feb 2002 03:38:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12901 for ; Tue, 5 Feb 2002 03:38:43 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25328 for ; Tue, 5 Feb 2002 03:38:39 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g158caC05148 for ; Tue, 5 Feb 2002 09:38:36 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g158car6011102 for ; Tue, 5 Feb 2002 10:38:36 +0200 (EET) Message-ID: <3C5F99E2.AFF1D7F@lmf.ericsson.se> Date: Tue, 05 Feb 2002 10:37:54 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Thoughts on 1-of-N with forking Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I have some thoughts about the 1-of-N codec mechanism, and how it will work in a forking scenario. Assume that we send an INVITE. Then we receive multiple 18x responses, from different servers, and we are not able to choose a common "final codec" for all of them. The problem is that we don't know which of the early dialogs will finally return 200, so we won't know which codec will actually be used. Now, if the node does support multiple codecs at the same time this is no problem, but to my understanding the idea of the 1-of-N mechanism was to be able to choose a single specific codec for nodes which don't. Of course, the client can terminate dialogs which don't "fit" the common single codec, but that would maybe not always be a very good idea. For example, phones will start ringing, and then suddenly stop. This is also a reason why I think it would be a good idea to handle the codec negoatiation BEFORE the called party is alarmed... My question is: do we need to say something about this in the spec, or shall it be regarded as a pure implementation issue? Regards, Christer Holmberg Ericsson 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 daemon@optimus.ietf.org Tue Feb 5 09:42:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01217 for ; Tue, 5 Feb 2002 09:42:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA02715 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 09:42:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00590; Tue, 5 Feb 2002 09:19:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00566 for ; Tue, 5 Feb 2002 09:19:50 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00507 for ; Tue, 5 Feb 2002 09:19:41 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g15EJBH20183 for ; Tue, 5 Feb 2002 09:19:12 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g15EJ9l06474 for ; Tue, 5 Feb 2002 09:19:09 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J339DWN>; Tue, 5 Feb 2002 09:19:10 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000102AF9A@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'sip@ietf.org'" Date: Tue, 5 Feb 2002 09:19:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AE50.15B673E0" Subject: [Sip] Proxies Can Modify SDP? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AE50.15B673E0 Content-Type: text/plain; charset="iso-8859-1" I've been involved in a little bit of correspondence with TIPHON WG 3, where there is some question whether proxies are allowed to modify SDP. I know this has shown up in E-mail, but it does not show up in 2543bis. Could someone confirm this so I can forward the message to TIPHON? Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ------_=_NextPart_001_01C1AE50.15B673E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Proxies Can Modify SDP?

I've been involved in a little bit of correspondence = with TIPHON WG 3, where there is some question whether proxies are = allowed to modify SDP.  I know this has shown up in E-mail, but it = does not show up in 2543bis.  Could someone confirm this so I can = forward the message to TIPHON?

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

------_=_NextPart_001_01C1AE50.15B673E0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 5 09:44:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01346 for ; Tue, 5 Feb 2002 09:44:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA02906 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 09:44:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00844; Tue, 5 Feb 2002 09:23:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00818 for ; Tue, 5 Feb 2002 09:23:17 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00694 for ; Tue, 5 Feb 2002 09:23:13 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g15ENDC26642; Tue, 5 Feb 2002 15:23:13 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g15ENDr6007408; Tue, 5 Feb 2002 16:23:13 +0200 (EET) Message-ID: <3C5FEA9C.8079DBF3@lmf.ericsson.se> Date: Tue, 05 Feb 2002 16:22:20 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor CC: "'sip@ietf.org'" Subject: Re: [Sip] Proxies Can Modify SDP? References: <4D79C746863DD51197690002A52CDA000102AF9A@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A proxy controlling a media firewall, and/or doing some kind of "codec filtering", should be able to modify the SDP, right? Regards, Christer Holmberg Ericsson Finland >I've been involved in a little bit of correspondence with TIPHON WG 3, >where there is some question whether proxies are allowed to modify >SDP. I know this has shown up in E-mail, but it does not show up in >2543bis. Could someone confirm this so I can forward the message to >TIPHON? > >Tom Taylor >taylor@nortelnetworks.com >Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 5 10:17:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03170 for ; Tue, 5 Feb 2002 10:17:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05663 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 10:17:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03735; Tue, 5 Feb 2002 09:52:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03625 for ; Tue, 5 Feb 2002 09:52:30 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02091; Tue, 5 Feb 2002 09:52:28 -0500 (EST) Message-Id: <200202051452.JAA02091@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 05 Feb 2002 09:52:27 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-rfc2543bis-07.txt,.ps,.pdf Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : SIP: Session Initiation Protocol Author(s) : J. Rosenberg, H. Schulzrinne et al. Filename : draft-ietf-sip-rfc2543bis-07.txt,.ps,.pdf Pages : 278 Date : 04-Feb-02 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution and multimedia conferences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2543bis-07.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-rfc2543bis-07.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020204134348.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc2543bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc2543bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020204134348.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 5 10:42:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04610 for ; Tue, 5 Feb 2002 10:42:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07819 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 10:42:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05313; Tue, 5 Feb 2002 10:10:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05265 for ; Tue, 5 Feb 2002 10:10:16 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02765 for ; Tue, 5 Feb 2002 10:10:14 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g15F9gZ03817 for ; Tue, 5 Feb 2002 10:09:42 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA17829; Tue, 5 Feb 2002 16:09:41 +0100 (MET) Cc: Tom-PT Taylor , "'sip@ietf.org'" Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA17798; Tue, 5 Feb 2002 16:09:36 +0100 (MET) Message-ID: <3C5FF5DA.CD9A3BCD@lucent.com> Date: Tue, 05 Feb 2002 16:10:18 +0100 From: Paul Sijben Organization: Lucent technologies, The Netherlands X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Original-CC: Tom-PT Taylor , "'sip@ietf.org'" Subject: Re: [Sip] Proxies Can Modify SDP? References: <4D79C746863DD51197690002A52CDA000102AF9A@zcard0kc.ca.nortel.com> <3C5FEA9C.8079DBF3@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The discussion on the TIPHON list was how such a box should be called. TIPHON has been using the term proxy for such a box for a while but it seemed not appropriate usage since a proxy was intended as a routing element ONLY. So we shwitched to B2BUA. However that terms has been scrapped now from the draft. Paul Christer Holmberg wrote: > > Hi, > > A proxy controlling a media firewall, and/or doing some kind of "codec > filtering", should be able to modify the SDP, right? > > Regards, > > Christer Holmberg > Ericsson Finland > > >I've been involved in a little bit of correspondence with TIPHON WG 3, > >where there is some question whether proxies are allowed to modify > >SDP. I know this has shown up in E-mail, but it does not show up in > >2543bis. Could someone confirm this so I can forward the message to > >TIPHON? > > > >Tom Taylor > >taylor@nortelnetworks.com > >Ph. +1 613 736 0961 (ESN 396 1490) > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Paul Sijben Tel:+31 356874774 Bell Labs - Advanced Technologies Fax:+31 356875954 Lucent Technologies (internal) http://voip.nl.lucent.com/~sijben Huizen, The Netherlands _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 5 10:48:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05014 for ; Tue, 5 Feb 2002 10:48:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08288 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 10:48:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05906; Tue, 5 Feb 2002 10:21:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05876 for ; Tue, 5 Feb 2002 10:21:28 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03354 for ; Tue, 5 Feb 2002 10:21:26 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id PAA15468; Tue, 5 Feb 2002 15:19:06 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id PAA12958; Tue, 5 Feb 2002 15:21:28 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <1J3WR93M>; Tue, 5 Feb 2002 08:21:27 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B371B4@n0214idc1.oss.level3.com> To: christer.holmberg@lmf.ericsson.se, taylor@nortelnetworks.com Cc: sip@ietf.org Subject: RE: [Sip] Proxies Can Modify SDP? Date: Tue, 5 Feb 2002 08:21:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Yes, a prominent proxy vendor does this with their firewall control proxy. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, February 05, 2002 7:22 AM > To: Tom-PT Taylor > Cc: 'sip@ietf.org' > Subject: Re: [Sip] Proxies Can Modify SDP? > > > > Hi, > > A proxy controlling a media firewall, and/or doing some kind of "codec > filtering", should be able to modify the SDP, right? > > Regards, > > Christer Holmberg > Ericsson Finland > > >I've been involved in a little bit of correspondence with > TIPHON WG 3, > >where there is some question whether proxies are allowed to modify > >SDP. I know this has shown up in E-mail, but it does not show up in > >2543bis. Could someone confirm this so I can forward the message to > >TIPHON? > > > >Tom Taylor > >taylor@nortelnetworks.com > >Ph. +1 613 736 0961 (ESN 396 1490) > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Tue Feb 5 11:02:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05897 for ; Tue, 5 Feb 2002 11:02:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09585 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 11:02:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07162; Tue, 5 Feb 2002 10:32:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07130 for ; Tue, 5 Feb 2002 10:32:36 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04032 for ; Tue, 5 Feb 2002 10:32:34 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15137; Tue, 5 Feb 2002 10:32:05 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19845; Tue, 5 Feb 2002 10:32:05 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Feb 2002 10:32:04 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57C8E5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Robert Sparks'" , William Marshall Cc: sip@ietf.org Subject: RE: [Sip] Last Call comments on 2543bis-07 Date: Tue, 5 Feb 2002 10:32:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > 2) Carriers are unfortunately obliged to meet regulatory > requirements. > > At least some of these, related to Electronic Surveillance, will not > > be standardized by IETF (see RFC 2804), though publication is > > encouraged (presumably as informational RFCs). However, > they may require > > extensions to SIP, and definition of additional headers and > option tags. > > It would be unfortunate if this resulting protocol could > not be called > > SIP. This is an ugly subject, granted, and I do not want > it to delay > > publication of bis as an RFC. My proposed resolution of this is > > to have bis make reference to draft-tsvarea-sipchange-xx for the > > guidelines of extensions being standard-track RFCs, and have the > > discussion when that draft is re-issued and last-called. > > Affects lines 1094-7, 1103-4, 1306-7 > > > I'll let the chairs comment on this. > This chair wouldn't allow bis to be held because of a normative reference to tsvarea-sipchange, but wouldn't object if that was not a problem. Brian *********This message is definitely not confidential and it does not matter in practice who sees it and whether or not it goes astray. No harm whatever would come to anyone even if it were published in a national newspaper. I apologies therefore for the unnecessary and irritating message that may or may not follow (I don't know because it is invisible to me)!!!!****** This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachment, use the contents for any purposes, or disclose the contents to any other person: to do so could be a breach of confidence. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 5 11:21:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06524 for ; Tue, 5 Feb 2002 11:21:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10782 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 11:21:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08608; Tue, 5 Feb 2002 10:52:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08577 for ; Tue, 5 Feb 2002 10:52:41 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05327 for ; Tue, 5 Feb 2002 10:52:38 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id DA3534CE2F; Tue, 5 Feb 2002 10:52:41 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id KAA10260; Tue, 5 Feb 2002 10:52:38 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id KAA12943; Tue, 5 Feb 2002 10:54:20 -0500 (EST) Date: Tue, 5 Feb 2002 10:54:20 -0500 (EST) Message-Id: <200202051554.KAA12943@fish.research.att.com> To: Brian.Rosen@marconi.com Cc: rsparks@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] Last Call comments on 2543bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Brian, As I understand the procedures and concerns, a normative references to draft-tsvarea-sipchange would hold bis in the RFC Editor's queue, which would delay the actual publication of bis as an RFC. It would not delay the assigning of an RFC number, which is what 3GPP wants on March 7. I'm not at all clear on how the RFC Editor will handle non-normative references to internet-drafts, like [30] SIP telephony call flow examples. If publication as an RFC "freezes" the text, then they may hold it in the queue for this, too. But again, it won't delay the assignment of an RFC number for 3GPP. The specific text in bis-07 leading to this discussion is regarding option tags that MUST be defined in standards- track RFCs. There is no reason that needs to be a normative reference. It actually falls into the category of "untestable" uses of spec language. It would best be left out. Bill Marshall wtm@research.att.com -----original message----- From: "Rosen, Brian" To: "'Robert Sparks'" , William Marshall Cc: sip@ietf.org Subject: RE: [Sip] Last Call comments on 2543bis-07 Date: Tue, 5 Feb 2002 10:32:03 -0500 > > 2) Carriers are unfortunately obliged to meet regulatory > requirements. > > At least some of these, related to Electronic Surveillance, will not > > be standardized by IETF (see RFC 2804), though publication is > > encouraged (presumably as informational RFCs). However, > they may require > > extensions to SIP, and definition of additional headers and > option tags. > > It would be unfortunate if this resulting protocol could > not be called > > SIP. This is an ugly subject, granted, and I do not want > it to delay > > publication of bis as an RFC. My proposed resolution of this is > > to have bis make reference to draft-tsvarea-sipchange-xx for the > > guidelines of extensions being standard-track RFCs, and have the > > discussion when that draft is re-issued and last-called. > > Affects lines 1094-7, 1103-4, 1306-7 > > > I'll let the chairs comment on this. > This chair wouldn't allow bis to be held because of a normative reference to tsvarea-sipchange, but wouldn't object if that was not a problem. 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 daemon@optimus.ietf.org Tue Feb 5 11:33:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07023 for ; Tue, 5 Feb 2002 11:33:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11983 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 11:33:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10459; Tue, 5 Feb 2002 11:16:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10429 for ; Tue, 5 Feb 2002 11:16:51 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06360 for ; Tue, 5 Feb 2002 11:16:47 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g15Fetb19217; Tue, 5 Feb 2002 07:40:55 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAV03605; Tue, 5 Feb 2002 07:40:25 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA24147; Tue, 5 Feb 2002 07:40:54 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15455.64774.662810.736248@thomasm-u1.cisco.com> Date: Tue, 5 Feb 2002 07:40:54 -0800 (PST) To: "Tom-PT Taylor" Cc: "'sip@ietf.org'" Subject: [Sip] Proxies Can Modify SDP? In-Reply-To: <4D79C746863DD51197690002A52CDA000102AF9A@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA000102AF9A@zcard0kc.ca.nortel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Tom-PT Taylor writes: > I've been involved in a little bit of correspondence with TIPHON WG 3, where > there is some question whether proxies are allowed to modify SDP. I know > this has shown up in E-mail, but it does not show up in 2543bis. Could > someone confirm this so I can forward the message to TIPHON? A better question to ask is what happens when a proxy wants to modify SDP, but the SDP was either sent encrypted or end to end. 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 daemon@optimus.ietf.org Tue Feb 5 11:38:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07217 for ; Tue, 5 Feb 2002 11:38:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12618 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 11:38:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09765; Tue, 5 Feb 2002 11:04:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09736 for ; Tue, 5 Feb 2002 11:04:48 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05970 for ; Tue, 5 Feb 2002 11:04:41 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g15G4ZX27001; Tue, 5 Feb 2002 11:04:35 -0500 (EST) Date: Tue, 5 Feb 2002 11:04:35 -0500 (EST) From: Scott Bradner Message-Id: <200202051604.g15G4ZX27001@newdev.harvard.edu> To: Brian.Rosen@marconi.com, rsparks@dynamicsoft.com, wtm@research.att.com Subject: RE: [Sip] Last Call comments on 2543bis-07 Cc: sip@ietf.org Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > This chair wouldn't allow bis to be held because of a normative reference > to tsvarea-sipchange, but wouldn't object if that was not a problem. I expect things could be worded so it was not a normative reference Scott _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 5 11:40:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07331 for ; Tue, 5 Feb 2002 11:40:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12849 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 11:40:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10685; Tue, 5 Feb 2002 11:19:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10654 for ; Tue, 5 Feb 2002 11:19:37 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06451 for ; Tue, 5 Feb 2002 11:19:33 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g15GJZC25261 for ; Tue, 5 Feb 2002 17:19:35 +0100 (MET) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.7]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g15GJZr6013394 for ; Tue, 5 Feb 2002 18:19:35 +0200 (EET) Message-ID: <3C600647.E478FF90@ericsson.com> Date: Tue, 05 Feb 2002 18:20:23 +0200 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Proxies adding bodies Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: I am thinking of a scenario where a proxy is adding a body to the SIP message, just to transport some sort of information that is only of use within the network where the proxy is operating. According to the SIP bis-07, I see that table 2 restricts a proxy the ability to modify the Content-Type, Content-Length and other suitables parameters that are needed to describe a possible new body added by a proxy. Why is it forbidden that a proxy modifies the Content-Length and Content-Type of a message? Any good reason? /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 5 11:56:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08168 for ; Tue, 5 Feb 2002 11:56:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14831 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 11:56:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11277; Tue, 5 Feb 2002 11:27:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11246 for ; Tue, 5 Feb 2002 11:27:47 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06806 for ; Tue, 5 Feb 2002 11:27:44 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g15GRet28833; Tue, 5 Feb 2002 11:27:40 -0500 Message-Id: <200202051627.g15GRet28833@minotaur.nge.isi.edu> To: William Marshall cc: Brian.Rosen@marconi.com, rsparks@dynamicsoft.com, sip@ietf.org Reply-To: mankin@isi.edu Subject: Re: [Sip] Last Call comments on 2543bis-07 In-reply-to: Your message of Tue, 05 Feb 2002 10:54:20 -0500. <200202051554.KAA12943@fish.research.att.com> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Tue, 05 Feb 2002 11:27:40 -0500 From: Allison Mankin Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, Brian Rosen wrote: > > > > I'll let the chairs comment on this. > > > This chair wouldn't allow bis to be held because of a normative reference > to tsvarea-sipchange, but wouldn't object if that was not a problem. > Bill Marshall wrote: > > As I understand the procedures and concerns, a normative > references to draft-tsvarea-sipchange would hold > bis in the RFC Editor's queue, which would delay the actual > publication of bis as an RFC. It would not delay the assigning > of an RFC number, which is what 3GPP wants on March 7. > > I'm not at all clear on how the RFC Editor will handle > non-normative references to internet-drafts, like [30] > SIP telephony call flow examples. If publication as an > RFC "freezes" the text, then they may hold it in the queue > for this, too. But again, it won't delay the assignment > of an RFC number for 3GPP. > The early RFC number procedure from RFC Editor is a favor, and we would not like to push it by having normative references to i-ds in there when we send them the approved bis i-d. This is something that I'm planning to review with the chairs and editors before 08. As Scott says, we can* probably word a reference to the tsvarea- sipchange draft to be non-normative. Bill continued: > The specific text in bis-07 leading to this discussion is > regarding option tags that MUST be defined in standards- > track RFCs. There is no reason that needs to be a normative > reference. It actually falls into the category of "untestable" > uses of spec language. It would best be left out. > I have some trouble agreeing that option tag extensibility rules can't be made testable. What would your reaction be to registering headers that IETF has not published in standard track or will not publish (such as the Electronic Surveillance ones you mention) in an x- category? Allison _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 5 12:02:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08432 for ; Tue, 5 Feb 2002 12:02:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16680 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 12:02:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13135; Tue, 5 Feb 2002 11:42:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13104 for ; Tue, 5 Feb 2002 11:42:01 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07432 for ; Tue, 5 Feb 2002 11:41:57 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id QAA14955; Tue, 5 Feb 2002 16:41:00 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id QAA28360; Tue, 5 Feb 2002 16:41:59 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <1J3WSF18>; Tue, 5 Feb 2002 09:41:59 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B371B5@n0214idc1.oss.level3.com> To: Miguel.A.Garcia@ericsson.com, sip@ietf.org Subject: RE: [Sip] Proxies adding bodies Date: Tue, 5 Feb 2002 09:41:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Good point. The firewall control proxies discussed in a thread earlier today need to be able to modify Content-Length, but table 2 does not allow this... John Hearty Level3 > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Tuesday, February 05, 2002 9:20 AM > To: sip@ietf.org > Subject: [Sip] Proxies adding bodies > > > Hi: > > I am thinking of a scenario where a proxy is adding a body to > the SIP message, > just to transport some sort of information that is only of > use within the > network where the proxy is operating. > > According to the SIP bis-07, I see that table 2 restricts a > proxy the ability > to modify the Content-Type, Content-Length and other > suitables parameters that > are needed to describe a possible new body added by a proxy. > > Why is it forbidden that a proxy modifies the Content-Length > and Content-Type > of a message? Any good reason? > > /Miguel > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Tue Feb 5 12:02:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08449 for ; Tue, 5 Feb 2002 12:02:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16707 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 12:02:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13745; Tue, 5 Feb 2002 11:46:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13717 for ; Tue, 5 Feb 2002 11:46:54 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07667 for ; Tue, 5 Feb 2002 11:46:50 -0500 (EST) From: John.Hearty@level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id QAA16676; Tue, 5 Feb 2002 16:46:24 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id QAA29429; Tue, 5 Feb 2002 16:46:30 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <1J3WSFRT>; Tue, 5 Feb 2002 09:46:30 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B371B6@n0214idc1.oss.level3.com> To: mat@cisco.com, taylor@nortelnetworks.com Cc: sip@ietf.org Subject: RE: [Sip] Proxies Can Modify SDP? Date: Tue, 5 Feb 2002 09:46:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Also note what just came up in a separate thread, table 2 in bis does not allow a proxy to modify the Content-Length header, which would typically be needed to modify SDP. John Hearty Level3 > > > Tom-PT Taylor writes: > > I've been involved in a little bit of correspondence with > TIPHON WG 3, where > > there is some question whether proxies are allowed to > modify SDP. I know > > this has shown up in E-mail, but it does not show up in > 2543bis. Could > > someone confirm this so I can forward the message to TIPHON? > > A better question to ask is what happens when a > proxy wants to modify SDP, but the SDP was either > sent encrypted or end to end. > > 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 daemon@optimus.ietf.org Tue Feb 5 12:06:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08608 for ; Tue, 5 Feb 2002 12:06:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17177 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 12:06:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14029; Tue, 5 Feb 2002 11:49:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13993 for ; Tue, 5 Feb 2002 11:49:17 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07808 for ; Tue, 5 Feb 2002 11:49:13 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g15Gn9C10035; Tue, 5 Feb 2002 17:49:09 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g15Gn8r6014708; Tue, 5 Feb 2002 18:49:08 +0200 (EET) Message-ID: <3C600CCD.FD507F33@lmf.ericsson.se> Date: Tue, 05 Feb 2002 18:48:13 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: John.Hearty@Level3.com CC: Miguel.A.Garcia@ericsson.com, sip@ietf.org Subject: Re: [Sip] Proxies adding bodies References: <17052388D394D411803900508BDFFAF601B371B5@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Even if the message body itself isn't changed, a Content-Length header has to be ADDED if a message received on UDP, to be forwarded by the proxy on TCP, didn't contain a Content-Length header (optional for UDP, but mandatory for TCP). Regards, Christer Holmberg Ericsson Finland John.Hearty@Level3.com wrote: > > Good point. The firewall control proxies discussed in a thread earlier > today need to be able to modify Content-Length, but table 2 does not allow > this... > > John Hearty > Level3 > > > -----Original Message----- > > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > > Sent: Tuesday, February 05, 2002 9:20 AM > > To: sip@ietf.org > > Subject: [Sip] Proxies adding bodies > > > > > > Hi: > > > > I am thinking of a scenario where a proxy is adding a body to > > the SIP message, > > just to transport some sort of information that is only of > > use within the > > network where the proxy is operating. > > > > According to the SIP bis-07, I see that table 2 restricts a > > proxy the ability > > to modify the Content-Type, Content-Length and other > > suitables parameters that > > are needed to describe a possible new body added by a proxy. > > > > Why is it forbidden that a proxy modifies the Content-Length > > and Content-Type > > of a message? Any good reason? > > > > /Miguel > > -- > > Miguel-Angel Garcia Oy LM Ericsson AB > > Jorvas, Finland > > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Tue Feb 5 12:07:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08656 for ; Tue, 5 Feb 2002 12:07:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17236 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 12:07:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14184; Tue, 5 Feb 2002 11:50:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14161 for ; Tue, 5 Feb 2002 11:50:44 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07846 for ; Tue, 5 Feb 2002 11:50:40 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA03102; Tue, 5 Feb 2002 11:50:39 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g15GocJ2018295 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Feb 2002 11:50:39 -0500 (EST) Message-ID: <3C600C98.EF3B82D@cs.columbia.edu> Date: Tue, 05 Feb 2002 11:47:20 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mankin@isi.edu CC: William Marshall , Brian.Rosen@marconi.com, rsparks@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 References: <200202051627.g15GRet28833@minotaur.nge.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > What would your reaction be to registering headers that IETF has > not published in standard track or will not publish (such as the > Electronic Surveillance ones you mention) in an x- category? From my vantage point, designating headers with a special prefix has been an unmitigated disaster in the past twenty years. Witness email. People pick random names, without registration, which then partially end up being folded into standards, yet maintain the X- designation or get documented (see Palme's documents). In addition, since there's no coordination, we get collisions and have to deal with things like whether X-Foo and Foo are the same thing. (Again, see email, if you need examples.) What's wrong with having IANA register regular header names, with no more normative strength or endorsement of their moral or technical value than having IANA register port numbers for random commercial applications or enterprise IDs or any of the other myriad non-standard protocol parts that IANA deals with? There are only 65,000 port numbers, there is an almost infinite supply of header names, so this is not a resource that is likely to become extremely scarce, as long as people don't get the idea that they need to register vanity header names. Thus, Bill can register "Monitored-By" to satisfy his favorite three-letter agency RFP, but all i would say is in the IANA table Monitored-By William Marshall plus suitable contact information. What is the advantage of bypassing a well-established entity like IANA? 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 daemon@optimus.ietf.org Tue Feb 5 12:13:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09025 for ; Tue, 5 Feb 2002 12:13:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17857 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 12:13:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14790; Tue, 5 Feb 2002 11:56:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14756 for ; Tue, 5 Feb 2002 11:56:35 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08152 for ; Tue, 5 Feb 2002 11:56:31 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g15GuWX4029769 for ; Tue, 5 Feb 2002 17:56:32 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g15GuWr6014978 for ; Tue, 5 Feb 2002 18:56:32 +0200 (EET) Message-ID: <3C600E89.39B82EBD@lmf.ericsson.se> Date: Tue, 05 Feb 2002 18:55:37 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Table 2: Proxy-Require Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Another issue on table 2, which I also raised some months ago, related to Proxy-Require. According to the table, a proxy is not allowed to modify/add/remove the Proxy-Require headers, or specific tags in the header. However, if there is a specific extensioin required, which only one proxy in the path needs to support, that proxy may then remove the option-tag for other proxies to support the same extension. Regards, Christer Holmberg Ericsson 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 daemon@optimus.ietf.org Tue Feb 5 12:18:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09284 for ; Tue, 5 Feb 2002 12:18:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18426 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 12:18:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16804; Tue, 5 Feb 2002 12:03:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16748 for ; Tue, 5 Feb 2002 12:03:01 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08474 for ; Tue, 5 Feb 2002 12:02:57 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id RAA23515; Tue, 5 Feb 2002 17:02:14 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id RAA03241; Tue, 5 Feb 2002 17:02:59 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <1J3WSHD7>; Tue, 5 Feb 2002 10:02:58 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B371B7@n0214idc1.oss.level3.com> To: christer.holmberg@lmf.ericsson.se, sip@ietf.org Cc: Miguel.A.Garcia@ericsson.com Subject: RE: [Sip] Proxies adding bodies Date: Tue, 5 Feb 2002 10:02:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Another good point. bis editors, please advise what changes to table 2 will be made. At minimum, "a" needs to be added to the proxy column for Content-Length, "m" also needs to be added to the proxy column to allow firewall control proxies to remain compliant. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, February 05, 2002 9:48 AM > To: Hearty, John > Cc: Miguel.A.Garcia@ericsson.com; sip@ietf.org > Subject: Re: [Sip] Proxies adding bodies > > > > Hi, > > Even if the message body itself isn't changed, a Content-Length header > has to be ADDED if a message received on UDP, to be forwarded by the > proxy on TCP, didn't contain a Content-Length header > (optional for UDP, > but mandatory for TCP). > > Regards, > > Christer Holmberg > Ericsson Finland > > > > John.Hearty@Level3.com wrote: > > > > Good point. The firewall control proxies discussed in a > thread earlier > > today need to be able to modify Content-Length, but table 2 > does not allow > > this... > > > > John Hearty > > Level3 > > > > > -----Original Message----- > > > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > > > Sent: Tuesday, February 05, 2002 9:20 AM > > > To: sip@ietf.org > > > Subject: [Sip] Proxies adding bodies > > > > > > > > > Hi: > > > > > > I am thinking of a scenario where a proxy is adding a body to > > > the SIP message, > > > just to transport some sort of information that is only of > > > use within the > > > network where the proxy is operating. > > > > > > According to the SIP bis-07, I see that table 2 restricts a > > > proxy the ability > > > to modify the Content-Type, Content-Length and other > > > suitables parameters that > > > are needed to describe a possible new body added by a proxy. > > > > > > Why is it forbidden that a proxy modifies the Content-Length > > > and Content-Type > > > of a message? Any good reason? > > > > > > /Miguel > > > -- > > > Miguel-Angel Garcia Oy LM Ericsson AB > > > Jorvas, Finland > > > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > > > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Tue Feb 5 12:32:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09939 for ; Tue, 5 Feb 2002 12:32:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19931 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 12:32:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18186; Tue, 5 Feb 2002 12:16:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18157 for ; Tue, 5 Feb 2002 12:16:54 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09161 for ; Tue, 5 Feb 2002 12:16:49 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g15HGoC21683; Tue, 5 Feb 2002 18:16:51 +0100 (MET) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.7]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g15HGor6015862; Tue, 5 Feb 2002 19:16:50 +0200 (EET) Message-ID: <3C6013B2.DAFEA476@ericsson.com> Date: Tue, 05 Feb 2002 19:17:38 +0200 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: John.Hearty@Level3.com CC: christer.holmberg@lmf.ericsson.se, sip@ietf.org Subject: Re: [Sip] Proxies adding bodies References: <17052388D394D411803900508BDFFAF601B371B7@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: Based on the discussion, I believe that both the Content-Length and Content-Type should have "am" in the proxy column in table 2. /Miguel John.Hearty@Level3.com wrote: > > Another good point. bis editors, please advise what changes to table 2 > will be made. At minimum, "a" needs to be added to the proxy column for > Content-Length, "m" also needs to be added to the proxy column to allow > firewall control proxies to remain compliant. > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Tuesday, February 05, 2002 9:48 AM > > To: Hearty, John > > Cc: Miguel.A.Garcia@ericsson.com; sip@ietf.org > > Subject: Re: [Sip] Proxies adding bodies > > > > > > > > Hi, > > > > Even if the message body itself isn't changed, a Content-Length header > > has to be ADDED if a message received on UDP, to be forwarded by the > > proxy on TCP, didn't contain a Content-Length header > > (optional for UDP, > > but mandatory for TCP). > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > John.Hearty@Level3.com wrote: > > > > > > Good point. The firewall control proxies discussed in a > > thread earlier > > > today need to be able to modify Content-Length, but table 2 > > does not allow > > > this... > > > > > > John Hearty > > > Level3 > > > > > > > -----Original Message----- > > > > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > > > > Sent: Tuesday, February 05, 2002 9:20 AM > > > > To: sip@ietf.org > > > > Subject: [Sip] Proxies adding bodies > > > > > > > > > > > > Hi: > > > > > > > > I am thinking of a scenario where a proxy is adding a body to > > > > the SIP message, > > > > just to transport some sort of information that is only of > > > > use within the > > > > network where the proxy is operating. > > > > > > > > According to the SIP bis-07, I see that table 2 restricts a > > > > proxy the ability > > > > to modify the Content-Type, Content-Length and other > > > > suitables parameters that > > > > are needed to describe a possible new body added by a proxy. > > > > > > > > Why is it forbidden that a proxy modifies the Content-Length > > > > and Content-Type > > > > of a message? Any good reason? > > > > > > > > /Miguel > > > > -- > > > > Miguel-Angel Garcia Oy LM Ericsson AB > > > > Jorvas, Finland > > > > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > > > > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP 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 > > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Feb 5 12:43:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10455 for ; Tue, 5 Feb 2002 12:43:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20721 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 12:43:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18772; Tue, 5 Feb 2002 12:23:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18729 for ; Tue, 5 Feb 2002 12:23:25 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09485 for ; Tue, 5 Feb 2002 12:23:22 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g15HMx6Y014401; Tue, 5 Feb 2002 12:22:59 -0500 (EST) Message-ID: <3C6014C5.416A0A89@dynamicsoft.com> Date: Tue, 05 Feb 2002 12:22:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: William Marshall , rsparks@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 References: <3C5F259C.1544665@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > I agree that having a MUST or SHOULD in simple behavioral statements > just makes the text hard to read and monotonous. This is a fine line to > walk, since some people would want every sentence with a verb to have a > MUST before the verb. I tend to think of MUST and SHOULD as emphasis, > where it is likely that an implementor will do something different if > left to her own devices, rather than just describing routine behavior. > Others likely disagree. Indeed, we've gotten burned before because non-normative statements meant people weren't clear what to do. In the case of these kinds of statements below, the interpretation of "MUST send to layer X" is really "MUST follow the procedures specified in section XX from here on". -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Tue Feb 5 12:43:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10486 for ; Tue, 5 Feb 2002 12:43:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20796 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 12:43:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19035; Tue, 5 Feb 2002 12:27:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18998 for ; Tue, 5 Feb 2002 12:27:07 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09641 for ; Tue, 5 Feb 2002 12:27:03 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g15HQO6Y014405; Tue, 5 Feb 2002 12:26:24 -0500 (EST) Message-ID: <3C601595.DC631A2A@dynamicsoft.com> Date: Tue, 05 Feb 2002 12:25:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: rsparks@dynamicsoft.com, hgs@cs.columbia.edu, sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 References: <200202050022.TAA21479@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > > Henning Schulzrinne wrote: > > Robert Sparks wrote: > > > This class of requirement is obviously on future specifications, not > > > implementations. As such, you could argue that they belong in the > > > guidelines draft. I would have no problem moving the three examples > you > > > present here, but I get the feeling that this isn't a complete list. > Is > > > requirements on future extensions the _only_ class of requirements > > > giving you trouble? > > > > My suggestion is that all of them should move into or close to the > IANA > > sections, since they are needed by things that need IANA registration > in > > any event. The section can then be prefixed by a "this is for > specifying > > compliancy of protocol designers, not implementations" (obviously, not > > worded that way...) > > This suggestion works fine for me. I'd then re-word the lines where > the spec words now appear as simple statements of fact, e.g.. "All > new header fields follow this generic format..." IANA is not going to look at this, I suspect. I dont think it is their job to check that extensions follow particular BNF patterns. I suspect the right thing might be to move such things into draft-ietf-sip-guidelines. Indeed, the particular bit about generic header formats is already in there. That document would serve as the SIP working groups measuring stick when reviewing drafts (preferably in advance of wglc). Anyone object to moving these types of references there? We'll need a volunteer to do a clean sweep of bis to find them all. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Tue Feb 5 13:05:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11258 for ; Tue, 5 Feb 2002 13:05:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22237 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 13:05:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18614; Tue, 5 Feb 2002 12:22:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18583 for ; Tue, 5 Feb 2002 12:22:08 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09415 for ; Tue, 5 Feb 2002 12:21:59 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g15HLrC23459; Tue, 5 Feb 2002 18:21:53 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g15HLqr6016075; Tue, 5 Feb 2002 19:21:52 +0200 (EET) Message-ID: <3C601479.DAA57584@lmf.ericsson.se> Date: Tue, 05 Feb 2002 19:20:57 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: John.Hearty@Level3.com, sip@ietf.org Subject: Re: [Sip] Proxies adding bodies References: <17052388D394D411803900508BDFFAF601B371B7@n0214idc1.oss.level3.com> <3C6013B2.DAFEA476@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Whar about Content-Encoding? The proxy could, for example, encode the message body (for compression/whatever purpose...). In fact, maybe all these issues affect most (every?) Content-Xxx header... Regards, Christer Holmberg Ericsson Finland "Miguel A. Garcia" wrote: > > Hi: > > Based on the discussion, I believe that both the Content-Length and > Content-Type should have "am" in the proxy column in table 2. > > /Miguel > > John.Hearty@Level3.com wrote: > > > > Another good point. bis editors, please advise what changes to table 2 > > will be made. At minimum, "a" needs to be added to the proxy column for > > Content-Length, "m" also needs to be added to the proxy column to allow > > firewall control proxies to remain compliant. > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Tuesday, February 05, 2002 9:48 AM > > > To: Hearty, John > > > Cc: Miguel.A.Garcia@ericsson.com; sip@ietf.org > > > Subject: Re: [Sip] Proxies adding bodies > > > > > > > > > > > > Hi, > > > > > > Even if the message body itself isn't changed, a Content-Length header > > > has to be ADDED if a message received on UDP, to be forwarded by the > > > proxy on TCP, didn't contain a Content-Length header > > > (optional for UDP, > > > but mandatory for TCP). > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > > John.Hearty@Level3.com wrote: > > > > > > > > Good point. The firewall control proxies discussed in a > > > thread earlier > > > > today need to be able to modify Content-Length, but table 2 > > > does not allow > > > > this... > > > > > > > > John Hearty > > > > Level3 > > > > > > > > > -----Original Message----- > > > > > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > > > > > Sent: Tuesday, February 05, 2002 9:20 AM > > > > > To: sip@ietf.org > > > > > Subject: [Sip] Proxies adding bodies > > > > > > > > > > > > > > > Hi: > > > > > > > > > > I am thinking of a scenario where a proxy is adding a body to > > > > > the SIP message, > > > > > just to transport some sort of information that is only of > > > > > use within the > > > > > network where the proxy is operating. > > > > > > > > > > According to the SIP bis-07, I see that table 2 restricts a > > > > > proxy the ability > > > > > to modify the Content-Type, Content-Length and other > > > > > suitables parameters that > > > > > are needed to describe a possible new body added by a proxy. > > > > > > > > > > Why is it forbidden that a proxy modifies the Content-Length > > > > > and Content-Type > > > > > of a message? Any good reason? > > > > > > > > > > /Miguel > > > > > -- > > > > > Miguel-Angel Garcia Oy LM Ericsson AB > > > > > Jorvas, Finland > > > > > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > > > > > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP 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 > > > > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Feb 5 13:07:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11340 for ; Tue, 5 Feb 2002 13:07:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22364 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 13:07:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21046; Tue, 5 Feb 2002 12:48:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21014 for ; Tue, 5 Feb 2002 12:48:56 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10659 for ; Tue, 5 Feb 2002 12:48:53 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g15HmNH12913; Tue, 5 Feb 2002 12:48:23 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g15HmL319331; Tue, 5 Feb 2002 12:48:22 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J339J69>; Tue, 5 Feb 2002 12:48:21 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000102AFA0@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'mankin@isi.edu'" , William Marshall Cc: Brian.Rosen@marconi.com, rsparks@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] Last Call comments on 2543bis-07 Date: Tue, 5 Feb 2002 12:48:18 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org We have a provision for private package registration in Megaco. All this does is reserve the package name -- no details have to be provided about the package itself. Our rules also tend to separate the name spaces for the public and private packages respectively. -----Original Message----- From: Allison Mankin [mailto:mankin@isi.edu] Sent: Tuesday, February 05, 2002 5:28 PM To: William Marshall Cc: Brian.Rosen@marconi.com; rsparks@dynamicsoft.com; sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 snip ... What would your reaction be to registering headers that IETF has not published in standard track or will not publish (such as the Electronic Surveillance ones you mention) in an x- category? Allison _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Tue Feb 5 13:07:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11389 for ; Tue, 5 Feb 2002 13:07:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22379 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 13:07:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20531; Tue, 5 Feb 2002 12:41:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20492 for ; Tue, 5 Feb 2002 12:41:07 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10323 for ; Tue, 5 Feb 2002 12:41:04 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g15HfPi20880 for ; Tue, 5 Feb 2002 19:41:25 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 5 Feb 2002 19:41:01 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Feb 2002 19:40:39 +0200 Received: from essrv103nok14881.ntc.nokia.com ([172.21.148.81]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 5 Feb 2002 19:40:39 +0200 From: Aki Niemi To: sip@ietf.org In-Reply-To: <3C600CCD.FD507F33@lmf.ericsson.se> References: <17052388D394D411803900508BDFFAF601B371B5@n0214idc1.oss.level3.com> <3C600CCD.FD507F33@lmf.ericsson.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 05 Feb 2002 20:40:26 +0200 Message-Id: <1012934426.9892.146.camel@essrv103nok14881.ntc.nokia.com> Mime-Version: 1.0 X-OriginalArrivalTime: 05 Feb 2002 17:40:39.0195 (UTC) FILETIME=[39C446B0:01C1AE6C] Content-Transfer-Encoding: 7bit Subject: [Sip] Authentication header issues in bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A couple of issues with the Digest authentication headers: 1) Lines 3884 - 3886 in section 20.4.0.1 say that the 'uri' parameter must be enclosed in quotation marks. However, the BNF for Authorization doesn't reflect that. Also, the example on lines 3795 - 3803 is missing quotes. 2) Section 20.1 guidelines for creating realm strings require globally unique strings. However, section 24 examples for the authentication headers (lines 5012, 5234, 5247, 5433) don't quite fulfill those guidelines. Cheers, Aki (Apologies if these issues were already known. Just making sure. ;) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Feb 5 13:26:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12378 for ; Tue, 5 Feb 2002 13:26:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23451 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 13:26:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22286; Tue, 5 Feb 2002 13:05:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22257 for ; Tue, 5 Feb 2002 13:05:50 -0500 (EST) Received: from mail4.intermedia.net (mail4.intermedia.net [206.40.48.154]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11257 for ; Tue, 5 Feb 2002 13:05:46 -0500 (EST) Received: from DBX09611 (unverified [208.1.63.130]) by mail4.intermedia.net (Rockliffe SMTPRA 4.5.4) with ESMTP id for ; Tue, 5 Feb 2002 10:05:07 -0800 From: "Christopher P Rigano" To: Date: Tue, 5 Feb 2002 13:04:51 -0600 Message-ID: <000001c1ae78$00a61f00$7301a8c0@DBX09611> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C1AE45.B60BAF00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] NAT, FIREWALLS, Endpoint Addressing Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C1AE45.B60BAF00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Are there any resources to further describe how IP addressing is being addressed for the following? 1. SIP Call Control Source addressing through firewalls. 2. SIP Call Control addressing through NAT. 3. SIP Call Control UDP/IP addressing through firewalls. 4. SIP Call Control UDP/IP addressing through NAT. 5. Bearer/Speech Path through Firewalls, specifically RTP/RTCP port reconciliation. 6. Bearer/Speech Path through NAT, specifically RTP/RTCP port reconciliation. Thanks and regards, Chris ------=_NextPart_000_0001_01C1AE45.B60BAF00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are there any resources to further describe how IP = addressing is being addressed for the following?

  1. SIP Call Control Source addressing through = firewalls.
  2. SIP Call Control addressing through NAT.
  3. SIP Call Control UDP/IP addressing through = firewalls.
  4. SIP Call Control UDP/IP addressing through = NAT.
  5. Bearer/Speech Path through Firewalls, specifically RTP/RTCP port = reconciliation.
  6. Bearer/Speech Path through NAT, specifically RTP/RTCP port = reconciliation.

 

Thanks and regards,

 

Chris

------=_NextPart_000_0001_01C1AE45.B60BAF00-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Feb 5 13:41:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13093 for ; Tue, 5 Feb 2002 13:41:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24428 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 13:41:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23269; Tue, 5 Feb 2002 13:24:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23234 for ; Tue, 5 Feb 2002 13:24:19 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12264 for ; Tue, 5 Feb 2002 13:24:16 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g15INkH16567; Tue, 5 Feb 2002 13:23:47 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g15INil02508; Tue, 5 Feb 2002 13:23:44 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J339K6L>; Tue, 5 Feb 2002 13:23:45 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD754012A5065@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Michael Thomas , "Tom-PT Taylor" Cc: "'sip@ietf.org'" Subject: RE: [Sip] Proxies Can Modify SDP? Date: Tue, 5 Feb 2002 13:23:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AE72.3880E280" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AE72.3880E280 Content-Type: text/plain; charset="iso-8859-1" how about a compressed one? abbie > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, February 05, 2002 10:41 AM > To: Taylor, Tom-PT [CAR:B800:EXCH] > Cc: 'sip@ietf.org' > Subject: [Sip] Proxies Can Modify SDP? > > > Tom-PT Taylor writes: > > I've been involved in a little bit of correspondence with > TIPHON WG 3, where > > there is some question whether proxies are allowed to > modify SDP. I know > > this has shown up in E-mail, but it does not show up in > 2543bis. Could > > someone confirm this so I can forward the message to TIPHON? > > A better question to ask is what happens when a > proxy wants to modify SDP, but the SDP was either > sent encrypted or end to end. > > 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 > ------_=_NextPart_001_01C1AE72.3880E280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Proxies Can Modify SDP?

how about a compressed one?

abbie

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Tuesday, February 05, 2002 10:41 = AM
> To: Taylor, Tom-PT [CAR:B800:EXCH]
> Cc: 'sip@ietf.org'
> Subject: [Sip] Proxies Can Modify SDP?
>
>
> Tom-PT Taylor writes:
>  > I've been involved in a little bit = of correspondence with
> TIPHON WG 3, where
>  > there is some question whether = proxies are allowed to
> modify SDP.  I know
>  > this has shown up in E-mail, but it = does not show up in
> 2543bis.  Could
>  > someone confirm this so I can = forward the message to TIPHON?
>
>    A better question to ask is = what happens when a
>    proxy wants to modify SDP, = but the SDP was either
>    sent encrypted or end to = end.
>
>       =           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
>

------_=_NextPart_001_01C1AE72.3880E280-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Feb 5 14:26:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15116 for ; Tue, 5 Feb 2002 14:26:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27023 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 14:26:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26287; Tue, 5 Feb 2002 14:06:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26261 for ; Tue, 5 Feb 2002 14:06:17 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14093 for ; Tue, 5 Feb 2002 14:06:13 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g15J67b27749; Tue, 5 Feb 2002 14:06:07 -0500 (EST) Date: Tue, 5 Feb 2002 14:06:07 -0500 (EST) From: Scott Bradner Message-Id: <200202051906.g15J67b27749@newdev.harvard.edu> To: Brian.Rosen@marconi.com, wtm@research.att.com Subject: RE: [Sip] Last Call comments on 2543bis-07 Cc: rsparks@dynamicsoft.com, sip@ietf.org Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > I'm not at all clear on how the RFC Editor will handle > non-normative references to internet-drafts, they publish the document - the reference would be to a "work in progress" Scott _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Feb 5 14:26:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15134 for ; Tue, 5 Feb 2002 14:26:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27034 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 14:26:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25270; Tue, 5 Feb 2002 13:57:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25164 for ; Tue, 5 Feb 2002 13:57:07 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13751 for ; Tue, 5 Feb 2002 13:57:04 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g15IidY01696; Tue, 5 Feb 2002 12:44:39 -0600 Message-ID: <3C602816.4080001@dynamicsoft.com> Date: Tue, 05 Feb 2002 12:44:38 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: John.Hearty@Level3.com CC: christer.holmberg@lmf.ericsson.se, sip@ietf.org, Miguel.A.Garcia@ericsson.com Subject: Re: [Sip] Proxies adding bodies References: <17052388D394D411803900508BDFFAF601B371B7@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The plan is "amr" RjS John.Hearty@Level3.com wrote: > Another good point. bis editors, please advise what changes to table 2 > will be made. At minimum, "a" needs to be added to the proxy column for > Content-Length, "m" also needs to be added to the proxy column to allow > firewall control proxies to remain compliant. > > > > >>-----Original Message----- >>From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] >>Sent: Tuesday, February 05, 2002 9:48 AM >>To: Hearty, John >>Cc: Miguel.A.Garcia@ericsson.com; sip@ietf.org >>Subject: Re: [Sip] Proxies adding bodies >> >> >> >>Hi, >> >>Even if the message body itself isn't changed, a Content-Length header >>has to be ADDED if a message received on UDP, to be forwarded by the >>proxy on TCP, didn't contain a Content-Length header >>(optional for UDP, >>but mandatory for TCP). >> >>Regards, >> >>Christer Holmberg >>Ericsson Finland >> >> >> >>John.Hearty@Level3.com wrote: >> >>> Good point. The firewall control proxies discussed in a >>> >>thread earlier >> >>>today need to be able to modify Content-Length, but table 2 >>> >>does not allow >> >>>this... >>> >>>John Hearty >>>Level3 >>> >>> >>>>-----Original Message----- >>>>From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>>>Sent: Tuesday, February 05, 2002 9:20 AM >>>>To: sip@ietf.org >>>>Subject: [Sip] Proxies adding bodies >>>> >>>> >>>>Hi: >>>> >>>>I am thinking of a scenario where a proxy is adding a body to >>>>the SIP message, >>>>just to transport some sort of information that is only of >>>>use within the >>>>network where the proxy is operating. >>>> >>>>According to the SIP bis-07, I see that table 2 restricts a >>>>proxy the ability >>>>to modify the Content-Type, Content-Length and other >>>>suitables parameters that >>>>are needed to describe a possible new body added by a proxy. >>>> >>>>Why is it forbidden that a proxy modifies the Content-Length >>>>and Content-Type >>>>of a message? Any good reason? >>>> >>>>/Miguel >>>>-- >>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>> Jorvas, Finland >>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 >>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Tue Feb 5 14:45:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16079 for ; Tue, 5 Feb 2002 14:45:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28080 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 14:45:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26791; Tue, 5 Feb 2002 14:20:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26760 for ; Tue, 5 Feb 2002 14:20:39 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14758 for ; Tue, 5 Feb 2002 14:20:36 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g15JKo6Y014655; Tue, 5 Feb 2002 14:20:50 -0500 (EST) Message-ID: <3C603065.B5DCA32B@dynamicsoft.com> Date: Tue, 05 Feb 2002 14:20:05 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christopher P Rigano CC: sip@ietf.org Subject: Re: [Sip] NAT, FIREWALLS, Endpoint Addressing References: <000001c1ae78$00a61f00$7301a8c0@DBX09611> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit You can find a plethora of material on this topic. Some of the documents include: http://search.ietf.org/internet-drafts/draft-rosenberg-sipping-nat-scenarios-00.txt http://search.ietf.org/internet-drafts/draft-ietf-sip-nat-01.txt http://search.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt http://search.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-00.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-00.txt http://search.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-01.txt http://search.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt also, see every document written for the midcom working group. Enjoy, Jonathan R. Christopher P Rigano wrote: > > Are there any resources to further describe how IP addressing is being > addressed for the following? > 1. SIP Call Control Source addressing through firewalls. > 2. SIP Call Control addressing through NAT. > 3. SIP Call Control UDP/IP addressing through firewalls. > 4. SIP Call Control UDP/IP addressing through NAT. > 5. Bearer/Speech Path through Firewalls, specifically RTP/RTCP port > reconciliation. > 6. Bearer/Speech Path through NAT, specifically RTP/RTCP port > reconciliation. > > Thanks and regards, > > Chris -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Tue Feb 5 15:13:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17433 for ; Tue, 5 Feb 2002 15:13:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA29319 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 15:13:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28470; Tue, 5 Feb 2002 14:59:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28442 for ; Tue, 5 Feb 2002 14:59:18 -0500 (EST) Received: from boca-isbu-nt04.boca.unispheresolutions.com (mailboca.unispherenetworks.com [63.111.211.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16759 for ; Tue, 5 Feb 2002 14:59:15 -0500 (EST) Received: by boca-isbu-nt04.boca.unispheresolutions.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 14:58:46 -0500 Message-ID: <153BDA136259D311859900A0C99B5263FA0E7E@boca-isbu-nt04.boca.unispheresolutions.com> From: "Buller, Jeremy" To: "'sip@ietf.org'" Date: Tue, 5 Feb 2002 14:58:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Last call comment, Re: bis-07, section 20.1 - example Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Example in 20.1. has INVITE with 'WWW-Authenticate:' (Response header/Challenge), 'Authorization:'? Kind regards, Jim _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Feb 5 17:04:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21077 for ; Tue, 5 Feb 2002 17:04:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05107 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 17:04:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03840; Tue, 5 Feb 2002 16:46:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03810 for ; Tue, 5 Feb 2002 16:46:19 -0500 (EST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20597 for ; Tue, 5 Feb 2002 16:46:13 -0500 (EST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 31D116A904; Tue, 5 Feb 2002 23:46:15 +0200 (EET) Message-ID: <3C604DFE.9020907@piuha.net> Date: Tue, 05 Feb 2002 23:26:22 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: jdrosen@dynamicsoft.com, mat@cisco.com Cc: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: SIP and PKI Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mike wrote first: > bis-06 implies very strongly that SIP elements > should use PKI based authentication. This should > be removed. And then Jonathan wrote: > Hmm, I don't recall it saying you had to use PKI, just > that S/MIME is a SHOULD. Honestly, I think its useless > for encryption, but there is a VERY useful application > for authentication using self-signed certs. There's two parts in the spec that could potentially use PKIs: TLS and S/MIME. The usage appears to be as follows, according to bis 07: * TLS is expected to be run in the same manner as web security * S/MIME is expected to be run in the same manner as SSH So, what should we say about the debate Mike and Jonathan were having? First, I'd like to agree with Jonathan that the way that S/MIME is being used does not necessarily imply PKI. I like the "opportunistic" or SSH style authentication and I believe it's very useful for SIP. PKI is a SHOULD/MAY in the spec for S/MIME. Secondly, I'd like to agree with Mike that the Bis 07 does imply PKI in another part of the text: the TLS usage. I think the text in Bis also needs clarification to make it more clear exactly what is being required [or I need to to be pointed to the right place in the spec]. Regarding the PKI implication, 22.3.1 states that a mutually authenticating TLS implementation is a MUST for proxies. Assuming the security connection is useful, the certificates passed from both sides have to be verified against something. Thus, there has to be root certificates configured somewhere, and both sides must be under the same root. Ok, so you can use the same roots that you use for web servers. Fine, but this is actually the same as what you need to do in IPsec, isn't it? The typical TLS one-sided authentication is a useful feature, but that typically be applied UA - proxy, not proxy-proxy... Regarding text clarifications: - The text says e.g. in 22.3.2.1 something about verifying certificates and domain names in them. Perhaps we should clarify that this indeed happens through some configured root CAs -- such as those which are the default in your Netscape, but some roots are needed. - 22.3.1 sets forth requirements for UAs to verify certificates. Why are these a SHOULD, not a MUST? - And why aren't there any requirements for proxies to do the verification? - In 22.3.2.2 there's the following text that describes how to talk TLS between two proxies: "... noting the domain name that appears in the certificate for comparison with the headers of SIP messages." Maybe it is obvious, but I'm not sure which headers this refers to. Certainly not the From, since this was the transitive case. The Via, then? Any DNS operations in between? - Wouldn't it be sufficient to verify *either* the From field against the TLS certs, or the latest via/source address? Then the INVITE comes from a known source in any case. - 5th paragraph in 22.3.2.2 ends abruptly. Something missing? Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Feb 5 20:39:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27241 for ; Tue, 5 Feb 2002 20:39:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA15702 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 20:39:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14244; Tue, 5 Feb 2002 20:12:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14213 for ; Tue, 5 Feb 2002 20:12:28 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26791 for ; Tue, 5 Feb 2002 20:12:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g15NoD6Y014955; Tue, 5 Feb 2002 18:50:14 -0500 (EST) Message-ID: <3C606F8A.7877E01D@dynamicsoft.com> Date: Tue, 05 Feb 2002 18:49:30 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Abbie Barbir CC: Michael Thomas , Tom-PT Taylor , "'sip@ietf.org'" Subject: Re: [Sip] Proxies Can Modify SDP? References: <87609AFB433BD5118D5E0002A52CD754012A5065@zcard0k6.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Danger, Will Robinson, danger! Having proxies muck with bodies, for the purposes of nat traversal, compression for low speed access, and so on, is very dangerous territory. It brings us to issues of robustness, integrity and informed consent which have been the pain of opes for well over a year now. I suggest you read RFC 3238 for a summary of some of the issues. The use of encryption alone means that we know for certain that this mechanism will not work in many cases. I recommend we steer clear of it in the spec. Another nicety I came up with was Require. What happens if a UA modifies the semantic of SDP in some way, and uses Require to enforce it? Now, the "proxy" will need to look at the Require headers too. Hmm. Sounds like a B2BUA again. That means that the column for Content-Length under proxy would be "ar", since we will need to add one when converting from UDP to TCP. The spec will mention that as the reason this value is present. However, I believe the spec should remain as is with regards to the other content headers; proxies are not supposed to muck with them. Now, it is true that, ahem, certain prominent sip vendors have products called firewall control proxies which muck with the SDP. Whether these things are rightly proxies, based on the SIP spec, or a B2BUA, is more a matter of technical marketing than standards, so I would not lose too much sleep over it. Its far less a stretch than what people are calling softswitches these days ;). Our job here at IETF is to write standards that work and are good for the Internet. Thanks, Jonathan R. Abbie Barbir wrote: > > how about a compressed one? > > abbie > > > -----Original Message----- > > From: Michael Thomas [ mailto:mat@cisco.com ] > > Sent: Tuesday, February 05, 2002 10:41 AM > > To: Taylor, Tom-PT [CAR:B800:EXCH] > > Cc: 'sip@ietf.org' > > Subject: [Sip] Proxies Can Modify SDP? > > > > > > Tom-PT Taylor writes: > > > I've been involved in a little bit of correspondence with > > TIPHON WG 3, where > > > there is some question whether proxies are allowed to > > modify SDP. I know > > > this has shown up in E-mail, but it does not show up in > > 2543bis. Could > > > someone confirm this so I can forward the message to TIPHON? > > > > A better question to ask is what happens when a > > proxy wants to modify SDP, but the SDP was either > > sent encrypted or end to end. > > > > 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 > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Tue Feb 5 20:48:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27381 for ; Tue, 5 Feb 2002 20:48:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA15997 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 20:48:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14587; Tue, 5 Feb 2002 20:23:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14563 for ; Tue, 5 Feb 2002 20:22:59 -0500 (EST) Received: from revere.sonusnet.com (mail.sonusnet.com [208.45.178.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26970 for ; Tue, 5 Feb 2002 20:22:56 -0500 (EST) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g161M0b13242; Tue, 5 Feb 2002 20:22:00 -0500 (EST) Received: from matt.verizon.net (MATT [10.128.82.128]) by sonusdc3.sonusnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DATJY1Y9; Tue, 5 Feb 2002 20:22:17 -0500 Message-Id: <5.1.0.14.2.20020205163314.00a60b70@mail.verizon.net> X-Sender: res06gzk@mail.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Feb 2002 16:37:50 -0800 To: Dean Willis , sip@ietf.org From: Matt Holdrege Subject: Re: [Sip] calling number blocking at sip/isup gateway In-Reply-To: <200201291657.g0TGvGN09741@bdsl.66.12.12.130.gte.net> References: <168.7e29cf2.2987fd5d@aol.com> <168.7e29cf2.2987fd5d@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 08:57 AM 1/29/2002, Dean Willis wrote: >I run a real IP telephone service. Unknown parties may place calls over >the Internet to my subscribers. My subscribers's profiles may result in >forwarding those calls to a PSTN gateway. PSTN charges originating from >this operation are charged back to the subscriber (the called party), >not the calling party with whom I have no relationship outside the SIP >used to set up the call. > >It really doesn't matter what the calling party put in their From: >field, I still need to complete the call. Now, if they were kind enough >to put in a phone number, I can map that into the IAM. But if they >didn't, I just can't. Now, there's an interesting question on >"authenticating" the phone number that they might have included., but >that's a different problem. You can get away with that now and even traditional PBX access methods do the same on a case by case basis. But the regulatory trend in some places is that you will be required to supply a number at the interconnect point. Even if you invent a number out of your head, you will be responsible for it. But (again) all we need to do is provide the method in the protocol for inserting a number. So what is the problem? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Feb 5 21:19:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27925 for ; Tue, 5 Feb 2002 21:19:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA17466 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 21:19:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA16931; Tue, 5 Feb 2002 21:01:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA16901 for ; Tue, 5 Feb 2002 21:01:39 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27697 for ; Tue, 5 Feb 2002 21:01:36 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g16212e20032; Tue, 5 Feb 2002 18:01:02 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAV20346; Tue, 5 Feb 2002 18:00:30 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA24226; Tue, 5 Feb 2002 18:00:59 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15456.36443.572081.366576@thomasm-u1.cisco.com> Date: Tue, 5 Feb 2002 18:00:59 -0800 (PST) To: Jonathan Rosenberg Cc: Abbie Barbir , Michael Thomas , Tom-PT Taylor , "'sip@ietf.org'" Subject: Re: [Sip] Proxies Can Modify SDP? In-Reply-To: <3C606F8A.7877E01D@dynamicsoft.com> References: <87609AFB433BD5118D5E0002A52CD754012A5065@zcard0k6.ca.nortel.com> <3C606F8A.7877E01D@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit What is the bright line distinction between this and a proxy (re)writing remote party id? I've never been entirely comfortable with this general subject either, but I think it's a bit overbroad to say that we haven't embarked on this slippery slope. Mike Jonathan Rosenberg writes: > Danger, Will Robinson, danger! > > Having proxies muck with bodies, for the purposes of nat traversal, > compression for low speed access, and so on, is very dangerous > territory. It brings us to issues of robustness, integrity and informed > consent which have been the pain of opes for well over a year now. I > suggest you read RFC 3238 for a summary of some of the issues. > > The use of encryption alone means that we know for certain that this > mechanism will not work in many cases. I recommend we steer clear of it > in the spec. Another nicety I came up with was Require. What happens if > a UA modifies the semantic of SDP in some way, and uses Require to > enforce it? Now, the "proxy" will need to look at the Require headers > too. Hmm. Sounds like a B2BUA again. > > That means that the column for Content-Length under proxy would be "ar", > since we will need to add one when converting from UDP to TCP. The spec > will mention that as the reason this value is present. However, I > believe the spec should remain as is with regards to the other content > headers; proxies are not supposed to muck with them. > > Now, it is true that, ahem, certain prominent sip vendors have products > called firewall control proxies which muck with the SDP. Whether these > things are rightly proxies, based on the SIP spec, or a B2BUA, is more a > matter of technical marketing than standards, so I would not lose too > much sleep over it. Its far less a stretch than what people are calling > softswitches these days ;). Our job here at IETF is to write standards > that work and are good for the Internet. > > > Thanks, > Jonathan R. > > > > > Abbie Barbir wrote: > > > > how about a compressed one? > > > > abbie > > > > > -----Original Message----- > > > From: Michael Thomas [ mailto:mat@cisco.com ] > > > Sent: Tuesday, February 05, 2002 10:41 AM > > > To: Taylor, Tom-PT [CAR:B800:EXCH] > > > Cc: 'sip@ietf.org' > > > Subject: [Sip] Proxies Can Modify SDP? > > > > > > > > > Tom-PT Taylor writes: > > > > I've been involved in a little bit of correspondence with > > > TIPHON WG 3, where > > > > there is some question whether proxies are allowed to > > > modify SDP. I know > > > > this has shown up in E-mail, but it does not show up in > > > 2543bis. Could > > > > someone confirm this so I can forward the message to TIPHON? > > > > > > A better question to ask is what happens when a > > > proxy wants to modify SDP, but the SDP was either > > > sent encrypted or end to end. > > > > > > 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 > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 daemon@ns.ietf.org Tue Feb 5 21:20:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27963 for ; Tue, 5 Feb 2002 21:20:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA17494 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 21:21:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA16495; Tue, 5 Feb 2002 21:00:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA16456 for ; Tue, 5 Feb 2002 21:00:11 -0500 (EST) Received: from revere.sonusnet.com (mail.sonusnet.com [208.45.178.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27627 for ; Tue, 5 Feb 2002 21:00:08 -0500 (EST) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g161xEb17407; Tue, 5 Feb 2002 20:59:14 -0500 (EST) Received: from matt.verizon.net (10.128.82.132 [10.128.82.132]) by sonusdc3.sonusnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DATJY10N; Tue, 5 Feb 2002 20:59:32 -0500 Message-Id: <5.1.0.14.2.20020205175200.00aa2730@mail.verizon.net> X-Sender: res06gzk@mail.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Feb 2002 17:58:49 -0800 To: Jonathan Rosenberg From: Matt Holdrege Subject: Re: [Sip] Proxies Can Modify SDP? Cc: sip@ietf.org In-Reply-To: <3C606F8A.7877E01D@dynamicsoft.com> References: <87609AFB433BD5118D5E0002A52CD754012A5065@zcard0k6.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org So should the bis draft mention something about how you SHOULD not mess with SDP in between endpoints? I think the lack of such a statement is showing right now. It led to this thread. At 03:49 PM 2/5/2002, Jonathan Rosenberg wrote: >Danger, Will Robinson, danger! > >Having proxies muck with bodies, for the purposes of nat traversal, >compression for low speed access, and so on, is very dangerous >territory. It brings us to issues of robustness, integrity and informed >consent which have been the pain of opes for well over a year now. I >suggest you read RFC 3238 for a summary of some of the issues. > >The use of encryption alone means that we know for certain that this >mechanism will not work in many cases. I recommend we steer clear of it >in the spec. Another nicety I came up with was Require. What happens if >a UA modifies the semantic of SDP in some way, and uses Require to >enforce it? Now, the "proxy" will need to look at the Require headers >too. Hmm. Sounds like a B2BUA again. > >That means that the column for Content-Length under proxy would be "ar", >since we will need to add one when converting from UDP to TCP. The spec >will mention that as the reason this value is present. However, I >believe the spec should remain as is with regards to the other content >headers; proxies are not supposed to muck with them. > >Now, it is true that, ahem, certain prominent sip vendors have products >called firewall control proxies which muck with the SDP. Whether these >things are rightly proxies, based on the SIP spec, or a B2BUA, is more a >matter of technical marketing than standards, so I would not lose too >much sleep over it. Its far less a stretch than what people are calling >softswitches these days ;). Our job here at IETF is to write standards >that work and are good for the Internet. > > >Thanks, >Jonathan R. > > > > >Abbie Barbir wrote: > > > > how about a compressed one? > > > > abbie > > > > > -----Original Message----- > > > From: Michael Thomas [ mailto:mat@cisco.com ] > > > Sent: Tuesday, February 05, 2002 10:41 AM > > > To: Taylor, Tom-PT [CAR:B800:EXCH] > > > Cc: 'sip@ietf.org' > > > Subject: [Sip] Proxies Can Modify SDP? > > > > > > > > > Tom-PT Taylor writes: > > > > I've been involved in a little bit of correspondence with > > > TIPHON WG 3, where > > > > there is some question whether proxies are allowed to > > > modify SDP. I know > > > > this has shown up in E-mail, but it does not show up in > > > 2543bis. Could > > > > someone confirm this so I can forward the message to TIPHON? > > > > > > A better question to ask is what happens when a > > > proxy wants to modify SDP, but the SDP was either > > > sent encrypted or end to end. > > > > > > 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 > > > > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PH: (973) 952-5000 >http://www.dynamicsoft.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 daemon@ns.ietf.org Tue Feb 5 21:56:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29849 for ; Tue, 5 Feb 2002 21:56:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA19990 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 21:56:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18838; Tue, 5 Feb 2002 21:42:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18782 for ; Tue, 5 Feb 2002 21:42:24 -0500 (EST) Received: from ps.pxserver.com ([202.164.189.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29486 for ; Tue, 5 Feb 2002 21:42:14 -0500 (EST) Received: from localhost ([202.164.189.225]) by ps.pxserver.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 10:46:24 +0800 X-Sender: johnx3001@yahoo.com From: John M To: sip@ietf.org Date: Wed, 06 Feb 2002 10:46:23 +0800 Reply-To: johnx3002@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 06 Feb 2002 02:46:24.0009 (UTC) FILETIME=[77325F90:01C1AEB8] Content-Transfer-Encoding: 7bit Subject: [Sip] JOIN FOR FREE! ... Learn and Earn Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello Fellow Networker, My name is John Miranda. I am now focusing on one online opportunity. I have tried several of these online opportunities full of hype promising us thousands of dollars every month. It is a sad fact that many people who are in need to earn additional income is being victimized by this fly by night scam artists. Every time I tried one opportunity after the other, I ended more broke than ever. As a result of trying all these opportunities, I have decided to select on my portfolio the company which is true to their words. Not the one full of hype. The only one that has consistently sent me the monthly check. Even without the hype they have given me the best compensation plan with their high % commission. They are providing real service not the one that simply transfer wealth from the new signups to the people at the top of the pyramid. They are not a form of a pyramid scam. Also when you join, you will have a team of upline sponsors who will help you succeed every step of the way. Instead of being left alone, you will be guided step by step by real people, not those autoresponders. Do not believe in do nothing, no recruiting, no selling schemes. They are scams. You might want to try it to prove my words. Only you can make your own success together with the help of your sponsors. If you have 2 to 3 hours a day, you will be able to earn a full income in a few months. And there is absolutely no limit as how much you can earn. It is designed to gain momentum after some time. But I prefer to avoid such statements as "You will get rich". I read it everywhere and I do not want to sound like them. To get your FREE membership ID send email to johnx300@yahoo.com and put "REGISTER ME FOR FREE" in the subject and your fullname in the body of your email. Regards, John Miranda johnx300@yahoo.com Note: You don't need to request for removal. This is a one time email. Your email address will be automatically de-activated in our list if you don't reply in this mail. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Feb 5 22:00:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29968 for ; Tue, 5 Feb 2002 22:00:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA20444 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 22:00:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19112; Tue, 5 Feb 2002 21:45:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19083 for ; Tue, 5 Feb 2002 21:45:19 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29550 for ; Tue, 5 Feb 2002 21:45:15 -0500 (EST) Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g162ime18486 for ; Tue, 5 Feb 2002 18:44:48 -0800 (PST) Date: Tue, 5 Feb 2002 18:44:47 -0800 (PST) From: Rohan Mahy To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] re: Can Proxy Modify SDP? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan Rosenberg said: >Now, it is true that, ahem, certain prominent sip vendors have products >called firewall control proxies which muck with the SDP. Whether these >things are rightly proxies, based on the SIP spec, or a B2BUA, is more a >matter of technical marketing than standards, so I would not lose too >much sleep over it. Its far less a stretch than what people are calling >softswitches these days ;). Our job here at IETF is to write standards >that work and are good for the Internet. I agree with Jonathan here. We should leave the spec as is with the exception of *adding* Contact-Length. Another prominent vendor that I know has an ALG that modifies the SDP, and I don't even want to *think* about what you would call it. Both of these will break as soon as someone turns on the end-to-end SMIME integrity and encryption. I would like to have that problem some day... 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 daemon@ns.ietf.org Tue Feb 5 22:15:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00212 for ; Tue, 5 Feb 2002 22:15:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA21552 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 22:15:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19986; Tue, 5 Feb 2002 21:56:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19955 for ; Tue, 5 Feb 2002 21:56:49 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29844 for ; Tue, 5 Feb 2002 21:56:42 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g162uXb20694; Tue, 5 Feb 2002 21:56:33 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 20:56:33 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAEAB@VA02> From: "Peterson, Jon" To: "'jari.arkko@piuha.net'" Cc: sip@ietf.org Subject: RE: [Sip] Re: SIP and PKI Date: Tue, 5 Feb 2002 20:56:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for these very useful comments. Some notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, February 05, 2002 1:26 PM > To: jdrosen@dynamicsoft.com; mat@cisco.com > Cc: sip@ietf.org > Subject: [Sip] Re: SIP and PKI > [snip] > > Regarding the PKI implication, 22.3.1 states that a > mutually authenticating TLS implementation is a MUST for > proxies. Assuming the security connection is useful, the > certificates passed from both sides have to be verified against > something. Thus, there has to be root certificates > configured somewhere, and both sides must be under > the same root. Ok, so you can use the same roots that > you use for web servers. Fine, but this is actually > the same as what you need to do in IPsec, isn't it? > The typical TLS one-sided authentication is a useful > feature, but that typically be applied UA - proxy, not > proxy-proxy... Yes, you should probably do the same thing (use mutual auth between proxies) for IPSec. I think you need both one-way auth and mutual auth for a complete PKI solution, though. We don't really specify how you might use IPSec in bis, which is why we only talk about these auth rules in the context of TLS. As you know, I suspect we need some kind of IPSec profile document to really understand how IPSec will be used for SIP. Agreed, btw, that you can use the same CA roots that you use for web servers for proxy servers (i.e. their hostnames are the important thing). > > Regarding text clarifications: > > - The text says e.g. in 22.3.2.1 something about > verifying certificates and domain names in them. > Perhaps we should clarify that this indeed happens through > some configured root CAs -- such as those which are the > default in your Netscape, but some roots are needed. Okay, we can explicitly say that this entails holding one or more CA root certificates - that was our intention. I wonder if we should say anything about CRLs? > > - 22.3.1 sets forth requirements for UAs to verify > certificates. Why are these a SHOULD, not a MUST? I read in 22.3.1 that certificate verification is a MUST for TLS, and a SHOULD/MAY or S/MIME. The SHOULD/MAY for S/MIME reflects that we expect self-signed "leap of faith" stuff to be more common than the use of root certificates. Btw, I will remember to add something somewhere about configuration as one way of learning about remote certificates for S/MIME. > > - And why aren't there any requirements for proxies > to do the verification? It's an oversight; frankly, I just assumed it would be understood. We can spell that out explicitly in bis if it seems especially misleading. We show this behavior in 22.3.2.2, anyway. > > - In 22.3.2.2 there's the following text that describes > how to talk TLS between two proxies: "... noting the domain > name that appears in the certificate for comparison with > the headers of SIP messages." Maybe it is obvious, but > I'm not sure which headers this refers to. Certainly not > the From, since this was the transitive case. The Via, > then? Any DNS operations in between? > > - Wouldn't it be sufficient to verify *either* the From > field against the TLS certs, or the latest via/source > address? Then the INVITE comes from a known source in > any case. Well, 22.3.2.2 assumes a sort of network in which every administrative domain that supports SIP has a proxy (acting as a registrar/local outbound/inbound proxy), and every administrative domain's proxy can reach every other administrative domain's proxy - although they don't necessarily have a pre-existing trust relationship. We don't talk too much about these underlying assumptions because this is, after all, just an example of how trust relationships could be established. In any event, for this architecture the From field of each request contains a domain which will correspond to the hostname of the proxy server from which a request originates - which should also correspond to the proxy's certificate. The term 'correspond' here is intentionally a little loose - the proxy's hostname might be 'sip.atlanta.com', whereas the From field of a request might be 'sip:alice@atlanta.com'. The correspondence of the proxy's domainname and certificate is initially discussed in the first paragraph of 22.3.2.1. The fact that requests coming from your administrative domain should probably have From fields corresponding to your domainname is discussed in 22.3.2.2 - again, this example architecture doesn't take into account any sort of transit carrier that requests might need to go through. The topmost Via header would probably also help the remote proxy to confirm the identity of the local proxy - but it wouldn't, however, help the local proxy understand the remote proxy's position; the local proxy just makes sure that the certificates corresponds to the Request-URI of the request it has sent. > > - 5th paragraph in 22.3.2.2 ends abruptly. Something missing? It doesn't end abruptly in the .pdf version, just the .txt version. I've learned that LaTeX really hates single ticks (`) on a line when it is rendering txt, in this case it's tripping on: `biloxi.com'. We'll fix that. > > Jari > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Tue Feb 5 22:16:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00233 for ; Tue, 5 Feb 2002 22:16:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA21591 for sip-archive@odin.ietf.org; Tue, 5 Feb 2002 22:16:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20244; Tue, 5 Feb 2002 21:59:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20140 for ; Tue, 5 Feb 2002 21:59:31 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29913 for ; Tue, 5 Feb 2002 21:59:27 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g162xCb23765; Tue, 5 Feb 2002 20:59:12 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 20:59:12 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAEAC@VA02> From: "Peterson, Jon" To: "'Matt Holdrege'" , Dean Willis , sip@ietf.org Subject: RE: [Sip] calling number blocking at sip/isup gateway Date: Tue, 5 Feb 2002 20:59:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I agree, but I'm not sure why this requires any method in the protocol for making up telephone numbers. It sounds like a gateway implementation issue. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Matt Holdrege [mailto:matt.holdrege@verizon.net] > Sent: Tuesday, February 05, 2002 4:38 PM > To: Dean Willis; sip@ietf.org > Subject: Re: [Sip] calling number blocking at sip/isup gateway > > > At 08:57 AM 1/29/2002, Dean Willis wrote: > >I run a real IP telephone service. Unknown parties may place > calls over > >the Internet to my subscribers. My subscribers's profiles > may result in > >forwarding those calls to a PSTN gateway. PSTN charges > originating from > >this operation are charged back to the subscriber (the called party), > >not the calling party with whom I have no relationship > outside the SIP > >used to set up the call. > > > >It really doesn't matter what the calling party put in their From: > >field, I still need to complete the call. Now, if they were > kind enough > >to put in a phone number, I can map that into the IAM. But if they > >didn't, I just can't. Now, there's an interesting question on > >"authenticating" the phone number that they might have included., but > >that's a different problem. > > You can get away with that now and even traditional PBX > access methods do > the same on a case by case basis. But the regulatory trend in > some places > is that you will be required to supply a number at the > interconnect point. > Even if you invent a number out of your head, you will be > responsible for > it. But (again) all we need to do is provide the method in > the protocol for > inserting a number. > > So what is the problem? > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Wed Feb 6 00:01:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03389 for ; Wed, 6 Feb 2002 00:01:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA25955 for sip-archive@odin.ietf.org; Wed, 6 Feb 2002 00:01:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24727; Tue, 5 Feb 2002 23:34:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24697 for ; Tue, 5 Feb 2002 23:34:06 -0500 (EST) Received: from out009.verizon.net (out009pub.verizon.net [206.46.170.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02934 for ; Tue, 5 Feb 2002 23:34:01 -0500 (EST) Received: from matt.verizon.net ([204.119.252.110]) by out009.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020206043344.ZNUI11848.out009.verizon.net@matt.verizon.net>; Tue, 5 Feb 2002 22:33:44 -0600 Message-Id: <5.1.0.14.2.20020205202926.00ab7d90@mail.verizon.net> X-Sender: res06gzk@mail.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Feb 2002 20:30:49 -0800 To: "Peterson, Jon" , Dean Willis , sip@ietf.org From: Matt Holdrege Subject: RE: [Sip] calling number blocking at sip/isup gateway In-Reply-To: <70565611B164D511957A001083FCDD56CAAEAC@VA02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org My point exactly. I'm wondering why the argument has taken this direction. Are we OK now with the protocol allowing the preservation of the caller-ID restricted flag? At 06:59 PM 2/5/2002, Peterson, Jon wrote: >I agree, but I'm not sure why this requires any method in the protocol for >making up telephone numbers. It sounds like a gateway implementation issue. > >Jon Peterson >NeuStar, Inc. > > > -----Original Message----- > > From: Matt Holdrege [mailto:matt.holdrege@verizon.net] > > Sent: Tuesday, February 05, 2002 4:38 PM > > To: Dean Willis; sip@ietf.org > > Subject: Re: [Sip] calling number blocking at sip/isup gateway > > > > > > At 08:57 AM 1/29/2002, Dean Willis wrote: > > >I run a real IP telephone service. Unknown parties may place > > calls over > > >the Internet to my subscribers. My subscribers's profiles > > may result in > > >forwarding those calls to a PSTN gateway. PSTN charges > > originating from > > >this operation are charged back to the subscriber (the called party), > > >not the calling party with whom I have no relationship > > outside the SIP > > >used to set up the call. > > > > > >It really doesn't matter what the calling party put in their From: > > >field, I still need to complete the call. Now, if they were > > kind enough > > >to put in a phone number, I can map that into the IAM. But if they > > >didn't, I just can't. Now, there's an interesting question on > > >"authenticating" the phone number that they might have included., but > > >that's a different problem. > > > > You can get away with that now and even traditional PBX > > access methods do > > the same on a case by case basis. But the regulatory trend in > > some places > > is that you will be required to supply a number at the > > interconnect point. > > Even if you invent a number out of your head, you will be > > responsible for > > it. But (again) all we need to do is provide the method in > > the protocol for > > inserting a number. > > > > So what is the problem? > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Wed Feb 6 00:21:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03668 for ; Wed, 6 Feb 2002 00:21:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA26991 for sip-archive@odin.ietf.org; Wed, 6 Feb 2002 00:21:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23081; Tue, 5 Feb 2002 22:58:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23050 for ; Tue, 5 Feb 2002 22:58:56 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02022 for ; Tue, 5 Feb 2002 22:58:52 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id BFEAF4CED1; Tue, 5 Feb 2002 22:58:55 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id WAA27442; Tue, 5 Feb 2002 22:58:52 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id XAA91288; Tue, 5 Feb 2002 23:01:13 -0500 (EST) Date: Tue, 5 Feb 2002 23:01:13 -0500 (EST) Message-Id: <200202060401.XAA91288@fish.research.att.com> To: mankin@isi.edu Cc: Brian.Rosen@marconi.com, rsparks@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Allison wrote: > What would your reaction be to registering headers that IETF has > not published in standard track or will not publish (such as the > Electronic Surveillance ones you mention) in an x- category? IANA registration of the option tags and header names is far preferred to the haphazard naming of X- headers in email. So whether the option tags and header names start with X-, or start with z9hG4bK, or anything else, the important part is the registration with IANA so that there are no conflicting uses of the same option name or header name. Provided the x- category guarantees the same uniqueness as other category tags, I'd be happy with this resolution. Simply identifying the headers and options as non-standards-track in the IANA registration is also fine. My complaint is with the wording which appeared first in bis-05 that the extension MUST be defined in a standards-track RFC. As noted, certain extensions can't be defined that way. Bis-00 through bis-04 did not have this restriction. Bill Marshall wtm@research.att.com -----original message----- To: William Marshall Cc: Brian.Rosen@marconi.com, rsparks@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 Date: Tue, 05 Feb 2002 11:27:40 -0500 From: Allison Mankin Folks, Brian Rosen wrote: > > > > I'll let the chairs comment on this. > > > This chair wouldn't allow bis to be held because of a normative reference > to tsvarea-sipchange, but wouldn't object if that was not a problem. > Bill Marshall wrote: > > As I understand the procedures and concerns, a normative > references to draft-tsvarea-sipchange would hold > bis in the RFC Editor's queue, which would delay the actual > publication of bis as an RFC. It would not delay the assigning > of an RFC number, which is what 3GPP wants on March 7. > > I'm not at all clear on how the RFC Editor will handle > non-normative references to internet-drafts, like [30] > SIP telephony call flow examples. If publication as an > RFC "freezes" the text, then they may hold it in the queue > for this, too. But again, it won't delay the assignment > of an RFC number for 3GPP. > The early RFC number procedure from RFC Editor is a favor, and we would not like to push it by having normative references to i-ds in there when we send them the approved bis i-d. This is something that I'm planning to review with the chairs and editors before 08. As Scott says, we can* probably word a reference to the tsvarea- sipchange draft to be non-normative. Bill continued: > The specific text in bis-07 leading to this discussion is > regarding option tags that MUST be defined in standards- > track RFCs. There is no reason that needs to be a normative > reference. It actually falls into the category of "untestable" > uses of spec language. It would best be left out. > I have some trouble agreeing that option tag extensibility rules can't be made testable. What would your reaction be to registering headers that IETF has not published in standard track or will not publish (such as the Electronic Surveillance ones you mention) in an x- category? Allison _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Wed Feb 6 01:45:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04699 for ; Wed, 6 Feb 2002 01:45:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA10181 for sip-archive@odin.ietf.org; Wed, 6 Feb 2002 01:45:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04234; Wed, 6 Feb 2002 01:09:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04161 for ; Wed, 6 Feb 2002 01:09:27 -0500 (EST) Received: from mailserver.sylantro.com ([65.200.90.207]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04311 for ; Wed, 6 Feb 2002 01:09:26 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Tue, 05 Feb 2002 22:04:18 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id <1F5J8CLZ>; Tue, 5 Feb 2002 22:04:18 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD9CFC02@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "'sip@ietf.org'" Date: Tue, 5 Feb 2002 22:04:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 107E18E8105549-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Some thoughts about sip-reconstitute-state and session timers. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, The sip-reconstitue-state favours failure detection by means of RTCP/RTP failures by the far end which triggers re-INVITEs that could be used to reconstruct state by servers that crashed. This model works well for servers where the media originates from the device that is also generating RTP. More specifically, this model doesn't help reconstitution of sessions in cases where applications (such as B2B UA's) enable non-SIP devices to communicate with SIP end devices, since in this scenario, no RTP/RTCP failures are detected due to the application crash. I was wondering if we could enhance sip-session-timer-08.txt to make the UA that is waiting for 'session refreshes' to send a re-INVITE before it tears the call down by sending a BYE on session-timer expiry (rather a few seconds before the expiry). This would assist such applications to reconstitute state of sessions as well if they persist exactly the same information that is indicated in the sip-reconstitute-state draft and keep such dialogs active. Regards. Venkatesh _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 6 08:15:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18861 for ; Wed, 6 Feb 2002 08:15:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00540 for sip-archive@odin.ietf.org; Wed, 6 Feb 2002 08:15:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28454; Wed, 6 Feb 2002 07:40:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28423 for ; Wed, 6 Feb 2002 07:40:44 -0500 (EST) Received: from avgw.vxserver.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18360 for ; Wed, 6 Feb 2002 07:40:38 -0500 (EST) Received: from ridgeway.ridgeway-sys.com ([10.1.1.1]) by avgw.vxserver.com (NAVGW 2.5.1.16) with SMTP id M2002020612374413446 for ; Wed, 06 Feb 2002 12:37:44 GMT Received: by ThisAddressDoesNotExist with Internet Mail Service (5.5.2653.19) id <11G0153A>; Wed, 6 Feb 2002 12:40:08 -0000 Message-ID: <00533D13955AD411AF3800A0C9B4263994D6FA@ThisAddressDoesNotExist> From: Phil Reynolds To: "'sip@ietf.org'" Subject: RE: [Sip] Proxies Can Modify SDP? Date: Wed, 6 Feb 2002 12:40:07 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AF0B.687BA800" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AF0B.687BA800 Content-Type: text/plain; charset="ISO-8859-1" Dangerous, it may be, but then that's my middle name :-) Mucking about with the network headers without understanding the bodies is even more dangerous -- at best every thing just works (more by luck than judgement), normally the world just goes bang in varied and unpredictable ways. Any protocol that relies on end-to-end integrity of the message is doomed to failure unless the absolute nature of both ends are known up front, or are you trying to tell me that your VoIP to PSTN gateway doesn't muck with the message body. For a protocol to be widely acceptable and universal it must be adaptable to the needs of all and, in the case of VoIP protocols, be transferable through a wide variety network architectures and infrastructure. The widespread take-up of VoIP and videoconferencing has been hampered by its inability to reach beyond the confines of a single enterprise without breaking the security of the enterprise firewall. Being one of the "prominent sip vendors" (we like to think so anyway :-)) who produce NAT traversal proxies, we feel that if you want your communications to work then you have to put up with us mucking about with your SDP and hence content-length header. Weather that makes us a B2BUA or an "illegal proxy" is irrelevant to anyone except the marketing people. If you are sufficiently paranoid (quite rightly so in many applications) then you are going to have to deploy network infrastructure that does not change addresses, as encrypting the SDP is about as interoperable as encrypting the entire network packet (IP headers and all), it just ain't going to work in the general case. To add security to SIP there needs to be some way of adding authentication/encryption information without affecting the ability of the network infrastructure to read and modify the control information (e.g. add a separate body with authentication information, or add this to the RTP payload -- I'm no security expert so don't quote me). --------------------------------------------------------- Phil Reynolds Ridgeway Systems and Software Tel: +44 118 938 1211 Fax: +44 118 935 4444 mailto:preynolds@ridgewaysystems.com http://www.ridgewaysystems.com > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 05 February 2002 23:50 > > Danger, Will Robinson, danger! > > Having proxies muck with bodies, for the purposes of nat traversal, > compression for low speed access, and so on, is very dangerous > territory. It brings us to issues of robustness, integrity > and informed > consent which have been the pain of opes for well over a year now. I > suggest you read RFC 3238 for a summary of some of the issues. > > The use of encryption alone means that we know for certain that this > mechanism will not work in many cases. I recommend we steer > clear of it > in the spec. Another nicety I came up with was Require. What > happens if > a UA modifies the semantic of SDP in some way, and uses Require to > enforce it? Now, the "proxy" will need to look at the Require headers > too. Hmm. Sounds like a B2BUA again. > > That means that the column for Content-Length under proxy > would be "ar", > since we will need to add one when converting from UDP to > TCP. The spec > will mention that as the reason this value is present. However, I > believe the spec should remain as is with regards to the other content > headers; proxies are not supposed to muck with them. > > Now, it is true that, ahem, certain prominent sip vendors > have products > called firewall control proxies which muck with the SDP. Whether these > things are rightly proxies, based on the SIP spec, or a > B2BUA, is more a > matter of technical marketing than standards, so I would not lose too > much sleep over it. Its far less a stretch than what people > are calling > softswitches these days ;). Our job here at IETF is to write standards > that work and are good for the Internet. > > > Thanks, > Jonathan R. > ------_=_NextPart_001_01C1AF0B.687BA800 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Proxies Can Modify SDP?

Dangerous, it may be, but then that's my middle name = :-)

Mucking about with the network headers without = understanding the bodies is even more dangerous -- at best every thing = just works (more by luck than judgement), normally the world just goes = bang in varied and unpredictable ways. Any protocol that relies on = end-to-end integrity of the message is <mock-Scottish-accent, = British-cultural-in-joke> doomed </mock-Scottish-accent> to = failure unless the absolute nature of both ends are known up front, or = are you trying to tell me that your VoIP to PSTN gateway doesn't muck = with the message body.

For a protocol to be widely acceptable and universal = it must be adaptable to the needs of all and, in the case of VoIP = protocols, be transferable through a wide variety network architectures = and infrastructure. The widespread take-up of VoIP and = videoconferencing has been hampered by its inability to reach beyond = the confines of a single enterprise without breaking the security of = the enterprise firewall.

Being one of the "prominent sip vendors" = (we like to think so anyway :-)) who produce NAT traversal proxies, we = feel that if you want your communications to work then you have to put = up with us mucking about with your SDP and hence content-length header. = Weather that makes us a B2BUA or an "illegal proxy" is = irrelevant to anyone except the marketing people.

If you are sufficiently paranoid (quite rightly so in = many applications) then you are going to have to deploy network = infrastructure that does not change addresses, as encrypting the SDP is = about as interoperable as encrypting the entire network packet (IP = headers and all), it just ain't going to work in the general case. To = add security to SIP there needs to be some way of adding = authentication/encryption information without affecting the ability of = the network infrastructure to read and modify the control information = (e.g. add a separate body with authentication information, or add this = to the RTP payload -- I'm no security expert so don't quote = me).

---------------------------------------------------------
Phil Reynolds
Ridgeway Systems and Software
Tel: +44 118 938 1211
Fax: +44 118 935 4444
mailto:preynolds@ridgeways= ystems.com
http://www.ridgewaysystems.com

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 05 February 2002 23:50
>
> Danger, Will Robinson, danger!
>
> Having proxies muck with bodies, for the = purposes of nat traversal,
> compression for low speed access, and so on, is = very dangerous
> territory. It brings us to issues of = robustness, integrity
> and informed
> consent which have been the pain of opes for = well over a year now. I
> suggest you read RFC 3238 for a summary of some = of the issues.
>
> The use of encryption alone means that we know = for certain that this
> mechanism will not work in many cases. I = recommend we steer
> clear of it
> in the spec. Another nicety I came up with was = Require. What
> happens if
> a UA modifies the semantic of SDP in some way, = and uses Require to
> enforce it? Now, the "proxy" will = need to look at the Require headers
> too. Hmm. Sounds like a B2BUA again.
>
> That means that the column for Content-Length = under proxy
> would be "ar",
> since we will need to add one when converting = from UDP to
> TCP. The spec
> will mention that as the reason this value is = present. However, I
> believe the spec should remain as is with = regards to the other content
> headers; proxies are not supposed to muck with = them.
>
> Now, it is true that, ahem, certain prominent = sip vendors
> have products
> called firewall control proxies which muck with = the SDP. Whether these
> things are rightly proxies, based on the SIP = spec, or a
> B2BUA, is more a
> matter of technical marketing than standards, = so I would not lose too
> much sleep over it. Its far less a stretch than = what people
> are calling
> softswitches these days ;). Our job here at = IETF is to write standards
> that work and are good for the Internet.
>
>
> Thanks,
> Jonathan R.
>


------_=_NextPart_001_01C1AF0B.687BA800-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 6 14:30:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29348 for ; Wed, 6 Feb 2002 14:30:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22234 for sip-archive@odin.ietf.org; Wed, 6 Feb 2002 14:31:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20790; Wed, 6 Feb 2002 14:06:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20757 for ; Wed, 6 Feb 2002 14:06:49 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28744 for ; Wed, 6 Feb 2002 14:06:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g16J6lio013670 for ; Wed, 6 Feb 2002 21:06:47 +0200 Date: Wed, 06 Feb 2002 21:06:47 +0200 (EET) Message-Id: <20020206.210647.49172519.jh@lohi.eng.song.fi> To: sip@ietf.org From: Juha Heinanen X-Mailer: Mew version 2.0.50 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] bug in date header specification Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit when defining the date header, sip i-d refers to rfc1123 date. i think it should refer to rfc1123 date-time, since date doesn't include time at all, but date-time does. -- 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 daemon@optimus.ietf.org Wed Feb 6 18:36:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05093 for ; Wed, 6 Feb 2002 18:36:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA03563 for sip-archive@odin.ietf.org; Wed, 6 Feb 2002 18:37:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02500; Wed, 6 Feb 2002 18:12:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02469 for ; Wed, 6 Feb 2002 18:12:04 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04868 for ; Wed, 6 Feb 2002 18:12:00 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id C1F641E091 for ; Wed, 6 Feb 2002 18:12:03 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA19666 for ; Wed, 6 Feb 2002 18:12:03 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA19363; Wed, 6 Feb 2002 15:12:03 -0800 (PST) Message-Id: <200202062312.PAA19363@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: sip@ietf.org Subject: Re: [Sip] Some more ABNF issues - bis07 Date: Wed, 6 Feb 2002 15:12:03 -0800 Versions: dmail (solaris) 2.3/makemail 2.9b Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org So, this may seem a little weird, but I wrote my own ABNF parser and ran the bis07 ABNF through it, and came up with another couple of fairly subtle issues: - "word" is missing slashes between "~" and "(", and between ">" and ":". This makes these elements concatenate, i.e. ... "'" / ( "~" "(" ) / ")" / "<" / ( ">" ":" ) / "\" / <"> ... which is clearly bad. - Similar precedence issue: concatenation binds more tightly than alternation, so despite the whitespace, you need a grouping around the second line of Contact: Contact = ("Contact" / "m" ) HCOLON STAR / (contact-param *(COMMA contact-param)) else it really means (("Contact" / "m" ) HCOLON STAR) / (contact-param *(COMMA contact-param)) These were the only two problems that this new tool caught that I don't think have been mentioned yet. Also, I'm sure this is redundant by now, but to continue earlier thoughts on representing the double quote character, there's a DQUOTE element in the ABNF core that can be used instead of <"> or %x22 . Bill _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 6 22:21:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09254 for ; Wed, 6 Feb 2002 22:21:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA15212 for sip-archive@odin.ietf.org; Wed, 6 Feb 2002 22:21:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA14347; Wed, 6 Feb 2002 22:05:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA14316 for ; Wed, 6 Feb 2002 22:05:05 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09036 for ; Wed, 6 Feb 2002 22:05:00 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1732b4q024638; Wed, 6 Feb 2002 22:02:37 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 22:04:33 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F362FFF7@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach Reply-To: sip@ietf.org To: "'sip@ietf.org'" Cc: "'simple@mailman.dynamicsoft.com'" Date: Wed, 6 Feb 2002 22:04:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] draft-ietf-sip-events-02 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org draft-ietf-sip-events-02.txt has been submitted for publication. All known issues have been resolved, and this draft is ready for working group last call. Until it appears in the archives, you may access a copy at: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-02.txt Also, a PDF version of the draft, with changebars, may be retrieved from: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-02.pdf /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 daemon@optimus.ietf.org Thu Feb 7 01:05:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12680 for ; Thu, 7 Feb 2002 01:05:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA22300 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 01:05:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA20627; Thu, 7 Feb 2002 00:48:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA20582 for ; Thu, 7 Feb 2002 00:48:37 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12405 for ; Thu, 7 Feb 2002 00:48:36 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g175m6H13740 for ; Wed, 6 Feb 2002 23:48:06 -0600 Message-ID: <017401c1af9b$262846d0$9219a8c0@dfw.dynamicsoft.com> From: "Dean Willis" To: Date: Wed, 6 Feb 2002 23:49:01 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0171_01C1AF68.DA749EA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] New Path Extension Header Draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0171_01C1AF68.DA749EA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've cobbled together a rough draft of a Path header extension in an = attempt to meet the a requirement for service route discovery during = REGISTER for 3GPP established in the Garcia 3GPP requirements draft in = the SIPPING group. It will be announced on internet-drafts soon, and you can pull from: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-00.txt ------=_NextPart_000_0171_01C1AF68.DA749EA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I've cobbled together a rough draft of = a Path=20 header extension in an attempt to meet the a requirement for service = route=20 discovery during REGISTER for 3GPP established in the Garcia 3GPP = requirements=20 draft in the SIPPING group.
 
It will be announced on internet-drafts = soon, and=20 you can pull from:
 
 ------=_NextPart_000_0171_01C1AF68.DA749EA0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 7 04:01:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23149 for ; Thu, 7 Feb 2002 04:01:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA08920 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 04:01:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05263; Thu, 7 Feb 2002 03:01:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05175 for ; Thu, 7 Feb 2002 03:01:37 -0500 (EST) Received: from chollian.net (s210-221-76-10.thrunet.ne.kr [210.221.76.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22107 for ; Thu, 7 Feb 2002 03:01:11 -0500 (EST) Message-Id: <200202070801.DAA22107@ietf.org> Reply-To: lee8153@chollian.net From: 최진희 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 7 Feb 2002 17:05:20 +0900 X-User: 2.62-hkilfmlu-hlpnip-Ffkik Subject: [Sip] 칼라레이져/컴퓨터/화면100인치<급처분> 홍 ' 보* Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org
문서번호:21가마-008977
수 신:대표이사님
발 신:사무기관리조합 최진범
참 조:컴퓨터/복사기/사무기/LCD/부동산 처분건
◈ 안녕하십니까? 사무기관리조합입니다.중소기업협참조로 연락드리오니 회사및
직원분들이 필요하시면 참조하시기 바랍니다.(대리점 정리하는 사무기 처분건입니다)
◈ 저희 사무기관리조합은 사무기기 대리점관리 및 대리점 정리시 사무기기를 일시적으로
처분하여 드리며 본 공문처분가격은 일시적인 처분가격 입니다.
 LCD(두께2cm)모니터19인치 무료상기물품 구입자만 무료임
(화면 100인치포함)모든제품 보증서 포함됨
★LCD빔프로젝터+레이져칼라프린터구입가격 1,600만원→처분가격285만
(프로젝터와 +칼라레이져는 세트입니다 각각 분리구입은 불가능함)
(소니,산요,샤프,엡손,HP 메이커별로 여러가지가 있음 가격은 무조건 285만원임)
◐ 구입은 현금및 자기앞 수표만 가능하며
세금계산서는 의무적으로 발행하여드림
◐컴퓨터/복사기/팩스/키폰/사무기7가지세트용
☞7가지원 소비자가격1,200만원⇒처분가격385만원
*****************************************************************
①복사기(축소,확대,줌 배율기능)+②삼성컴퓨터(686 DVD내장형/정품프로그램CD10종류외
* 화상카메라/*고성능 마이크포함) +③프린터초고속+④스캐너+⑤일반용지 팩시밀리
⑥키폰 LG디지탈16국선+⑦LCD모니터 19인치 (반드시 7가지를 1세트로 구입하셔야함)
★ 상기 모든 제품은 박스도 풀지 않은 신품 입니다(전제품무상A/S보증서 포함임)
★7가지원 소비자가격1,200만원→7가지 세트 처분가격:385만원(현금및자기앞수표만가능)
★7가지를 세트로 만 구입 하셔야 하며 낱개는 구입불가함(예,컴퓨터만은구입불가) 
****************************************************************
$$상기 7가지 제품은 여러세트가 있으니 창고에서 보시고 유리하신것으로 선택바람
★-- 대표이사님이 직접 방문 상기사무기기만 구입할경우는 중소기업
대표자 예우차원에서 10%할인하여드림(직원은 절대 할인불가함)
◐부동산 처분건 -서서울에서 30분거리 서해대교도로변 땅급매건
★ 주의사항★사장님이직접방문 구입할 경우 중소기업 대표자 예우차원에서 10%할인
1-상기 모든제품은 박스도 풀지않은 신품입니다(전제품 무상보증서 포함되어있음)
2-(대표자)결정권자가 직접방문 구입하셔야합니다.모든제품은 (부가세 별도)입니다..
3-상부에 결제 또는 보고를 드려야 하는 직원은 출입을 금합니다.
4-자세한 제품사양 및 모델은 전화상의로 문의할수없고 창고로 직접 방문하셔서
보시고 만족하시면 즉시 구입하시기 바랍니다.(세금계산서는의무적으로발행하여 드림)
5-모든제품이(박스도 풀지않는제품)이지만 LCD모니터19"형만은중고인관계로 무료로드림
6-LCD빔프로젝터+레이져칼라프린터는 중고제품이며사장님이 방문구입바랍니다
7-반드시 구입하실 날짜에 방문 하셔서 직접 보시고 그자리에서 (금액을 완불바람)
8-사장님이직접방문 구입할 경우 중소기업 대표자 예우차원에서 10%할인하여드림
필히 본 공문과 사업자등록증 사본, 신분증을 가지고 방문 (상기물품만 10%할인함)
☞업무시간:오전9시30분부터~오후6시까지(토요일은 쉽니다)
☞ 주 차:1층에서 5층까지1톤화물차까지 편리함 (구입영수증이 있어야무료임)
☎(02)761-1407     FAX(02)783-2058- FAX(02)-784-5766
☞혼자서만 보시지마시고 신규 사장님에게도 알려 주시기 바랍니다
☞주차- 한빛은행건물(하늘색) 지하 5층까지임 구입영수증이 있어야 무료임
63빌딩바로 옆건물 한빛은행9층 사무기관리조합 안내실로방문
사   무   기   관   리   조   합
본 메일은 인터넷 상에서 수집된것이며 메일 주소 이외에 어떠한 개인정보도 알수없습니다 본메일은 두번다시 발송 않합니다
수신거부는여기를 클릭해주세요
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 7 09:12:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27263 for ; Thu, 7 Feb 2002 09:12:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA21625 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 09:12:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20464; Thu, 7 Feb 2002 08:48:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20433 for ; Thu, 7 Feb 2002 08:48:03 -0500 (EST) Received: from mailhost.wellx.com (mailhost.wellx.com [62.161.157.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26434 for ; Thu, 7 Feb 2002 08:48:01 -0500 (EST) Received: from mail.wellx.com by mailhost.wellx.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 7 Feb 2002 13:43:16 UT Received: from wellx.com (192.168.1.114 [192.168.1.114]) by srvwellx.wellx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CVPQAHKX; Thu, 7 Feb 2002 14:42:43 +0100 Message-ID: <3C6287AB.B5E08F45@wellx.com> Date: Thu, 07 Feb 2002 14:56:59 +0100 From: Aymeric MOIZARD Organization: WellX X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 CC: sip@ietf.org References: <017401c1af9b$262846d0$9219a8c0@dfw.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] draft-ietf-sip-call-flows-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Is there any update for this draft for bis-06 or bis-07? I notice that in section 7.5 (INVITE with inconsistent Accept and message body), the SDP message does not have any "o=" line.... Aymeric _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 7 09:30:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27868 for ; Thu, 7 Feb 2002 09:30:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA22710 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 09:30:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21355; Thu, 7 Feb 2002 09:07:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21324 for ; Thu, 7 Feb 2002 09:07:09 -0500 (EST) Received: from mailhost.wellx.com (mailhost.wellx.com [62.161.157.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26991 for ; Thu, 7 Feb 2002 09:07:07 -0500 (EST) Received: from mail.wellx.com by mailhost.wellx.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 7 Feb 2002 14:02:22 UT Received: from wellx.com (192.168.1.114 [192.168.1.114]) by srvwellx.wellx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CVPQAHK8; Thu, 7 Feb 2002 15:01:49 +0100 Message-ID: <3C628C26.1B01EFFA@wellx.com> Date: Thu, 07 Feb 2002 15:16:06 +0100 From: Aymeric MOIZARD Organization: WellX X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-call-flows-05.txt References: <017401c1af9b$262846d0$9219a8c0@dfw.dynamicsoft.com> <3C6287AB.B5E08F45@wellx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Also, many SDP messages does not contains any "t=" line This is true from section 7.1 to section 7.19 Aymeric MOIZARD wrote: > > Is there any update for this draft for bis-06 or bis-07? > > I notice that in section 7.5 (INVITE with inconsistent Accept > and message body), the SDP message does not have any "o=" line.... > > Aymeric > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Thu Feb 7 09:58:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29003 for ; Thu, 7 Feb 2002 09:58:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24043 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 09:58:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23233; Thu, 7 Feb 2002 09:39:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23204 for ; Thu, 7 Feb 2002 09:39:02 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28255 for ; Thu, 7 Feb 2002 09:39:00 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42260) id <0GR6004013C70Q@firewall.wcom.com> for sip@ietf.org; Thu, 7 Feb 2002 14:38:31 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GR60036E3C6IP@firewall.wcom.com>; Thu, 07 Feb 2002 14:38:31 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GR6006013C4OS@dgismtp02.wcomnet.com>; Thu, 07 Feb 2002 14:38:30 +0000 (GMT) Received: from ajohnston ([166.44.56.92]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GR6004AV3BRI8@dgismtp02.wcomnet.com>; Thu, 07 Feb 2002 14:38:17 +0000 (GMT) Date: Thu, 07 Feb 2002 08:38:08 -0600 From: Alan Johnston Subject: RE: [Sip] draft-ietf-sip-call-flows-05.txt In-reply-to: <3C628C26.1B01EFFA@wellx.com> To: "'Aymeric MOIZARD'" , sip@ietf.org Message-id: <001301c1afe5$1020ef50$e4202aa6@ajohnston> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Aymeric, Thanks for the comments - we'll make the changes. We are working on an update to the document - it will be released shortly. The major changes will be adding From tags, branch IDs, Max-Forwards, and updating Record-Route behavior to bring it in line with recent changes to bis. We'll also be going through all the test messages with a fine tooth comb as well. Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Aymeric MOIZARD > Sent: Thursday, February 07, 2002 8:16 AM > To: sip@ietf.org > Subject: Re: [Sip] draft-ietf-sip-call-flows-05.txt > > > Also, many SDP messages does not contains any "t=" line > This is true from section 7.1 to section 7.19 > > > Aymeric MOIZARD wrote: > > > > Is there any update for this draft for bis-06 or bis-07? > > > > I notice that in section 7.5 (INVITE with inconsistent Accept and > > message body), the SDP message does not have any "o=" line.... > > > > Aymeric > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Thu Feb 7 10:08:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29317 for ; Thu, 7 Feb 2002 10:08:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24897 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 10:08:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23489; Thu, 7 Feb 2002 09:43:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23457 for ; Thu, 7 Feb 2002 09:43:32 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28391 for ; Thu, 7 Feb 2002 09:43:30 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 0A40A1E155; Thu, 7 Feb 2002 09:43:33 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA04173; Thu, 7 Feb 2002 09:43:30 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id JAA07536; Thu, 7 Feb 2002 09:45:56 -0500 (EST) Date: Thu, 7 Feb 2002 09:45:56 -0500 (EST) Message-Id: <200202071445.JAA07536@fish.research.att.com> To: rsparks@dynamicsoft.com Cc: sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Robert Sparks replied to my comments, in part: > > 2665: wrong cross reference, should probably be "Step 3" > > I disagree - it is a reference to what endpoints do with Record-Route, > not proxies. I made a typo in this comment...it should have been to line 2865. Text reads: Unless otherwise specified, the proxy MUST NOT removed the message body or any header fields other than the Via header field discussed in Section 3. Section 3 defines the spec language, MUST, MAY, SHOULD, etc. It is clearly the wrong place to reference. I believe "Step 3" is correct. And there is another cross reference in line 1081 (say again 1081, and again 1081, take the majority to error-correct) Text reads: Via processing for proxies is described in Section 3 and I'm not sure what this should refer to, but again Section 3 is not it. Bill Marshall wtm@research.att.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 daemon@optimus.ietf.org Thu Feb 7 10:27:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29733 for ; Thu, 7 Feb 2002 10:27:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA25845 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 10:27:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24090; Thu, 7 Feb 2002 09:59:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24062 for ; Thu, 7 Feb 2002 09:58:58 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29019 for ; Thu, 7 Feb 2002 09:58:56 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g17Ex86Y016467; Thu, 7 Feb 2002 09:59:08 -0500 (EST) Message-ID: <3C629610.12B106B4@dynamicsoft.com> Date: Thu, 07 Feb 2002 09:58:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] New Path Extension Header Draft References: <017401c1af9b$262846d0$9219a8c0@dfw.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean, Thanks for pulling this together.... Some comments. 1. The example messages are screwed up, looks like a CRLF was lost at the end of each line. 2. I think the mechanism you have here differs in a subtle, but important way from Record-Route. By my reading, the registrar does *not* return the received path headers in the 2xx response. Rather, proxies must explicitly insert the path in both the request and the response if they wish to be present in both directions. I think this is very much the right thing to do (I am not sure what 3gpp has done here). In the general case, the problem is really that P2 does not know about P1, and so cannot delivery incoming calls towards UA1 without learning about P1, through a registration. That is the primary function that Path needs to satisfy. Now, interestingly, there is no corresponding discovery problem, in the general case, for requests from UA1 out. UA1 already knows about P1 and P2; it does not need to discover them through Path in order to construct the forward route set. Indeed, the only reason why a forward request would need to have a route set learned from register, is if there were elements that created state whose lifetime was equal to that of the registration state. In this case, those specific elements would need to be on the path of subsequent register's in order to properly maintain that state (and, more importantly, expire it). This is the case for 3gpp, where the forward path effectively stores the state associated with the selection of the S-CSCF. However, that is not a general scenario, and the maintenance of state for registration lifetimes in elements outside of the registrar is something we should not assume by default. Thus, I like the notion of having Path be used for incoming requests normally, but allowing it for outgoing if proxies so desire, in order to support 3gpp. 3. If this draft moves forward, you will need to have sections for UA, proxy and registrars defining concise behaviors, such as this issue above. -Jonathan R. Dean Willis wrote: > > I've cobbled together a rough draft of a Path header extension in an > attempt to meet the a requirement for service route discovery during > REGISTER for 3GPP established in the Garcia 3GPP requirements draft in > the SIPPING group. > > It will be announced on internet-drafts soon, and you can pull from: > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-00.txt > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 7 10:32:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29857 for ; Thu, 7 Feb 2002 10:32:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26402 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 10:32:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24791; Thu, 7 Feb 2002 10:03:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24759 for ; Thu, 7 Feb 2002 10:03:54 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29196 for ; Thu, 7 Feb 2002 10:03:53 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g17F456Y016470; Thu, 7 Feb 2002 10:04:06 -0500 (EST) Message-ID: <3C629739.1AB90A7D@dynamicsoft.com> Date: Thu, 07 Feb 2002 10:03:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: sip@ietf.org Subject: Re: [Sip] bug in date header specification References: <20020206.210647.49172519.jh@lohi.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha Heinanen wrote: > > when defining the date header, sip i-d refers to rfc1123 date. i think > it should refer to rfc1123 date-time, since date doesn't include time at > all, but date-time does. We do explicitly define rfc1123-date, so there is no bug here per se. The definition is actually copied verbatim from HTTP 1.1, rfc2616, which specified the format for rfc-1123 date: HTTP-date = rfc1123-date | rfc850-date | asctime-date rfc1123-date = wkday "," SP date1 SP time SP "GMT" So, we are consistent with that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 7 10:53:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00366 for ; Thu, 7 Feb 2002 10:53:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27203 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 10:53:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25751; Thu, 7 Feb 2002 10:25:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25713 for ; Thu, 7 Feb 2002 10:25:31 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29672 for ; Thu, 7 Feb 2002 10:25:29 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g17FDAc01496; Thu, 7 Feb 2002 09:13:10 -0600 Message-ID: <3C629986.7020602@dynamicsoft.com> Date: Thu, 07 Feb 2002 09:13:10 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 References: <200202071445.JAA07536@fish.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Fixed them both. They should have been (and now are) references to 16.5 step 3 and 16.6 step 3. RjS William Marshall wrote: > Robert Sparks replied to my comments, in part: > >>>2665: wrong cross reference, should probably be "Step 3" >>> >>I disagree - it is a reference to what endpoints do with Record-Route, >>not proxies. >> > > I made a typo in this comment...it should have been to line 2865. > Text reads: > Unless otherwise specified, the proxy MUST NOT removed the message > body or any header fields other than the Via header field discussed > in Section 3. > > Section 3 defines the spec language, MUST, MAY, SHOULD, etc. It is > clearly the wrong place to reference. I believe "Step 3" is correct. > > And there is another cross reference in line 1081 > (say again 1081, and again 1081, take the majority to error-correct) > Text reads: > Via processing for proxies is described in Section 3 and bad-cross-reference-already-identified> > > I'm not sure what this should refer to, but again Section 3 is not it. > > Bill Marshall > wtm@research.att.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 daemon@optimus.ietf.org Thu Feb 7 12:05:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02356 for ; Thu, 7 Feb 2002 12:05:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03032 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 12:05:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00617; Thu, 7 Feb 2002 11:41:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00586 for ; Thu, 7 Feb 2002 11:41:37 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01679 for ; Thu, 7 Feb 2002 11:41:34 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g17Gf6H17880; Thu, 7 Feb 2002 10:41:06 -0600 Message-ID: <01b701c1aff6$5f4ad580$9219a8c0@dfw.dynamicsoft.com> From: "Dean Willis" To: Cc: "Joerg Ott" , "Brian Rosen" , "Jonathan Rosenberg" Date: Thu, 7 Feb 2002 10:42:02 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B4_01C1AFC4.14225650" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] WGLC of SIP SRV draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_01B4_01C1AFC4.14225650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We'd like to start today the Working Group Last Call of the SIP SRV = specification. WGLC will close 19Feb02. http://search.ietf.org/internet-drafts/draft-ietf-sip-srv-04.txt Thanks. Please copy comments to this list and Jonathan. -- Dean ------=_NextPart_000_01B4_01C1AFC4.14225650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We'd like to start today the Working = Group Last=20 Call of the SIP SRV specification. WGLC will close 19Feb02.
 
http://search.ietf.org/internet-drafts/draft-ietf-sip-srv-04.txt
 
Thanks. Please copy comments to this = list and=20 Jonathan.
 
--
Dean
------=_NextPart_000_01B4_01C1AFC4.14225650-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 7 12:16:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02876 for ; Thu, 7 Feb 2002 12:16:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03474 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 12:16:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00691; Thu, 7 Feb 2002 11:44:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00664 for ; Thu, 7 Feb 2002 11:44:36 -0500 (EST) Received: from tnint06.telogy.com ([209.116.120.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01715 for ; Thu, 7 Feb 2002 11:44:33 -0500 (EST) Received: by tnint06.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id <120X8ZQ0>; Thu, 7 Feb 2002 11:43:57 -0500 Message-ID: <61891BA043DED21180920090273F17380374B83F@tnint06.telogy.design.ti.com> From: "Yadavalli, Satyamurthy" To: "'Alan Johnston'" , "'Aymeric MOIZARD'" , sip@ietf.org Cc: sip-implementors@cs.columbia.edu Date: Thu, 7 Feb 2002 11:43:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: [Sip-implementors] draft-ietf-sip-service-examples-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I keep hearing these terms 3pcc, B2BUA, and other approaches etc., and I wonder how different vendors of SIP components (UAs, proxy servers etc.,) will be able to realize supplementary features (sip-service-examples) each independantly presuming an approach for each feature. The same thing said differently: for a simple feature like call forwarding....should the UA do it or should the proxy do it. If there exists no specification how would different vendors interoperate to achieve the call control features across networks? -satya > -----Original Message----- > From: Alan Johnston [mailto:alan.johnston@wcom.com] > Sent: Wednesday, January 23, 2002 2:45 PM > To: 'Aymeric MOIZARD' > Cc: sip-implementors@cs.columbia.edu > Subject: RE: [Sip-implementors] draft-ietf-sip-service-examples-03.txt > > > Hi Aymeric, > > An example of where 3pcc or B2BUA might be a better choice would be if > some of the UAs invoved in a session to be transferred do not support > the REFER method. Generally, the advantage of 3pcc or B2BUA > is that they > rely on SIP without requiring extensions or feature support. > > Thanks, > Alan Johnston > WorldCom > sip:alan@siptest.wcom.com > > > -----Original Message----- > > From: sip-implementors-admin@cs.columbia.edu > > [mailto:sip-implementors-admin@cs.columbia.edu] On Behalf Of > > Aymeric MOIZARD > > Sent: Monday, January 21, 2002 9:36 AM > > Cc: sip-implementors@cs.columbia.edu > > Subject: [Sip-implementors] draft-ietf-sip-service-examples-03.txt > > > > > > > > Hi, > > the draft "draft-ietf-sip-service-examples-03.txt" > > states in the "1. Overview" section that: > > > > "...Also, these flows do not represent the only way to > > implement these services - other approaches such as 3pcc > > (Third Party Call Control) or Back-to-Back User Agents > > (B2BUA) may be more appropriate in some circumstances." > > > > Does anybody can help and give some highlights about which > > "circumstances" can lead to choosing another approach. > > > > Thanks > > Aymeric > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/> sip-implementors > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/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 daemon@optimus.ietf.org Thu Feb 7 13:02:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03858 for ; Thu, 7 Feb 2002 13:02:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05907 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 13:02:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03535; Thu, 7 Feb 2002 12:16:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03503 for ; Thu, 7 Feb 2002 12:16:45 -0500 (EST) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02891 for ; Thu, 7 Feb 2002 12:16:41 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g17HGhi20321 for ; Thu, 7 Feb 2002 12:16:43 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K49XXPW>; Thu, 7 Feb 2002 17:16:42 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E8D2@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org, "'Dean Willis'" Subject: RE: [Sip] New Path Extension Header Draft (long) Date: Thu, 7 Feb 2002 17:16:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org You've beaten me to this draft so here are comments based on the text I had already written in order to get this together quicker. Keith 1) Abstract. I suggest this rather than the one in your proposal. Your abstract contains too much about service-routes which are not part of the proposal, and which are already meant to be in the bis draft. This draft provides a mechanism to be used in the REGISTER method, that allows the proxies that wish to be outbound proxies in future transactions, or inbound proxies in future transactions, and which are situated on the signalling path between the UA and the registrar, to communicate their URL to the UA and the registrar, such that these URLs can form part of a preloaded route list for future transactions. References to any 3GPP requirements should be moved to the background section. 2) In section 4, you mention that Path header is based on the Route header. It is surely more correct to say it is based on the Record-Route header, as that is where the rr-param comes from. I notice that you have an extra level of decomposition in the BNF. Based on the Record-Route header I had envisaged only: Path = "Path" HCOLON 1# ( name-addr *( SEMI rr-param )) rr-param = generic-param where rr-param is already defined. If we need the extra level of decomposition, then surely this should also exist in the Record-Route header in the bis draft. As introductory text to the section defining the BNF I would suggest the following text: Path header is a mechanism whereby a proxy can request to be on a signalling path for the request exchanged between the UE and the registrar. The path-establishment procedure is originated by the P-CSCF during the registration process. The procedure is performed during registration and all subsequent reregistrations. The list of Path headers obtained by a reregistration overwrites the existing list of Path headers at the registrar. Each reregistration of the same UA may result in new list of Path headers. The UA uses the list of Path headers to construct a list of Route headers. When initiating a dialog or standalone transaction, the list of Route headers will be pre-loaded into the initial INVITE request.. If a CSCF wants to receive subsequent requests, it will insert its own name to the Record Route header of the initial INVITE request. Once on the route, a CSCF remains on the route for the duration of the call. The path learned while re-registering during an active call does not affect the existing call, since the routing path for the respective call has already been established. The list of Path headers is not forwarded to the UE. 3) I notice that your proposal operates independently in both directions, i.e. a proxy can choose to be on the path as an inbound proxy, an outbound proxy, or both. This means that you have ended with with a different mechanism to that which 3GPP has currently documented. In 3GPP the current mechanism operates with proxies being on the path as both inbound and outbound proxies, and therefore the addition of URLs to the Path header is much more similar to Record-Route (i.e. the path is built on the request, and the entire path is passed back in the response). In the example you have given in the text, the changes would be as follows: F2 Path: as currently F4 Path: , F5 Path: , (this is your 2nd F4) If you wish to change the 3GPP current intentions then we need to agree something quickly. The 3GPP requirements do not need to separate outbound from inbound proxies. I also cannot envisage when one would want to do this, so I am not sure it is really a requirement. 4) Your procedures seem to imply that the registrar is always located at an outbound proxy. While this is the case in 3GPP, I had envisaged that a registrar can be located at an outbound proxy, but that this is not mandatory. 5) I was envisaging separate sections for - procedures at the UAC - procedures at the proxy - procedures at the registrar The text of the procedures according to the 3GPP way of operation that I have is as follows: Procedures at the UAC When a UAC receives a response to REGISTER containing the Path header, the UAC shall remove its SIP URL from the list of Path headers, reverse the order of the list and save the resulting list of Path headers. This list shall be stored during the entire registration period of the respective ???public user identity. If this registration is a reregistration, the P-CSCF shall replace the already existing Path headers with the new list A UAC MUST use any route list created by the Path mechanism during a registration procedure as the pre-loaded route in the Route header of the first request in a dialog, or in any request that does not form part of a dialog. Procedures at the UAS There are no procedures for the UAS. Procedures at the proxy An outbound proxy that wishes to be on the path for future transactions or dialogs relating to a REGISTER request MUST insert a resolveable identifier that will reach the proxy as the topmost entry in the Path header before proxying that request. Proxies that are not on the path of the REGISTER request cannot use this mechanism. Procedures at the registrar If a Path header exists in a sucessful REGISTER request, the registrar shall construct a list of preloaded Route headers from the list of entries in the Path header. The order in the lists is preserved. The registrar MUST bind to each contact information the respective Path header entries, that were received in the same REGISTER message as that contact information. The registrar shall also return the path list as a Path header in a 200 OK response to the REGISTER request. An inbound proxy which uses the location server to determine the Contact address of the user MUST also use this list of preloaded Route headers in the transaction request. The registrar can also act as a proxy as described above (in which case it inserts a resolvable identifier identifying itself in the Path header) before storing the list of preloaded Route headers. I think the current text you have in section 5 would be best treated as an example of operation, as appears in a number of other SIP drafts, and we should concentrate on detailing procedures as I have identified. 6) 3GPP consider that an option-tag should also be defined where such operation is considered essential. This would need to appear in the Require header (where it is understood by the registrar) and the Proxy-Require header (where it is understood by proxies) of the REGISTER request. The text I had drafted for this is as follows: Option-tag This draft defines the option-tag "path" for use in the Require, Proxy-Require, Supported and Unsupported headers specified in bisdraft [xx]. A server responding to an OPTION request MUST include this option-tag in accordance with bisdraft [xx] A UAC MAY include a "Require: path" in a REGISTER request if it wants the registration to fail if the registrar does not support this feature. A proxy MAY add a "Require: path" in a REGISTER request if it wants the registration to fail if the registrar does not support this feature. A UAC MAY include a "Proxy-Require: path" in a REGISTER request if it wants the registration to fail if any outbound proxies before the registrar do not support this feature. A proxy MAY add a "Proxy-Require: path" in a REGISTER request if it wants the registration to fail if any subsequent outbound proxies before the registrar do not support this feature. 7) And finally, in the acknowledgements can you include Min Huang and Stinson Mathai, as they put together the original proposal in 3GPP for this mechanism, and worked most of the 3GPP procedures in 24.229. Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Dean Willis[SMTP:dean.willis@softarmor.com] > Sent: 07 February 2002 5:49 > To: sip@ietf.org > Subject: [Sip] New Path Extension Header Draft > > I've cobbled together a rough draft of a Path header extension in an > attempt to meet the a requirement for service route discovery during > REGISTER for 3GPP established in the Garcia 3GPP requirements draft in the > SIPPING group. > > It will be announced on internet-drafts soon, and you can pull from: > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-00.txt > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 7 13:19:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04438 for ; Thu, 7 Feb 2002 13:19:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA06641 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 13:19:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05368; Thu, 7 Feb 2002 12:59:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05343 for ; Thu, 7 Feb 2002 12:59:21 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03762 for ; Thu, 7 Feb 2002 12:59:17 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g17HxFio014791; Thu, 7 Feb 2002 19:59:15 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15458.49267.636465.51849@harjus.eng.song.fi> Date: Thu, 7 Feb 2002 19:59:15 +0200 To: Jonathan Rosenberg Cc: sip@ietf.org Subject: Re: [Sip] bug in date header specification In-Reply-To: <3C629739.1AB90A7D@dynamicsoft.com> References: <20020206.210647.49172519.jh@lohi.eng.song.fi> <3C629739.1AB90A7D@dynamicsoft.com> X-Mailer: VM 7.00 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > HTTP-date = rfc1123-date | rfc850-date | asctime-date > rfc1123-date = wkday "," SP date1 SP time SP "GMT" > > So, we are consistent with that. ok, i just looked rfc 1123 and there a syntax item called "date" doesn't include time, but "date-time" does. in order to avoid confusion, the first sentence The Date header field contains an RFC 1123 date (see [H14.18]). could be changed to The Date header field contains an rfc1123-date (see [H14.18]). because "RFC 1123 date" doesn't include time. -- 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 daemon@ns.ietf.org Thu Feb 7 13:35:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05077 for ; Thu, 7 Feb 2002 13:35:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA08165 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 13:35:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06154; Thu, 7 Feb 2002 13:10:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06115 for ; Thu, 7 Feb 2002 13:10:23 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04185 for ; Thu, 7 Feb 2002 13:10:19 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g17I9lH18559; Thu, 7 Feb 2002 12:09:48 -0600 Message-ID: <027a01c1b002$c33cf620$9219a8c0@dfw.dynamicsoft.com> From: "Dean Willis" To: "Drage, Keith \(Keith\)" Cc: References: <475FF955A05DD411980D00508B6D5FB00439E8D2@en0033exch001u.uk.lucent.com> Subject: Re: [Sip] New Path Extension Header Draft (long) Date: Thu, 7 Feb 2002 12:03:04 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Drage, Keith (Keith)" To: ; "'Dean Willis'" Sent: Thursday, February 07, 2002 11:16 AM Subject: RE: [Sip] New Path Extension Header Draft (long) > You've beaten me to this draft so here are comments based on the text I had > already written in order to get this together quicker. > > Keith > > 1) Abstract. > > I suggest this rather than the one in your proposal. Your abstract contains > too much about service-routes which are not part of the proposal, and which > are already meant to be in the bis draft. > > This draft provides a mechanism to be used in the REGISTER method, > that allows the proxies that wish to be outbound proxies in future > transactions, or inbound proxies in future transactions, and which are > situated on the signalling path between the UA and the registrar, to > communicate their URL to the UA and the registrar, such that these URLs can > form part of a preloaded route list for future transactions. I've modified your suggestion and will include > References to any 3GPP requirements should be moved to the background > section. done > 2) In section 4, you mention that Path header is based on the Route > header. It is surely more correct to say it is based on the Record-Route > header, as that is where the rr-param comes from. done > I notice that you have an extra level of decomposition in the BNF. Based on > the Record-Route header I had envisaged only: > > Path = "Path" HCOLON 1# > ( name-addr *( SEMI rr-param )) > rr-param = generic-param > > where rr-param is already defined. If we need the extra level of > decomposition, then surely this should also exist in the Record-Route header > in the bis draft. I've included both forms pending further comment > As introductory text to the section defining the BNF I would suggest the > following text: > > Path header is a mechanism whereby a proxy can request to be on a > signalling path for the request exchanged between the UE and the registrar. > The path-establishment procedure is originated by the P-CSCF during the > registration process. The procedure is performed during registration and all > subsequent reregistrations. The list of Path headers obtained by a > reregistration overwrites the existing list of Path headers at the > registrar. Each reregistration of the same UA may result in new list of Path > headers. The UA uses the list of Path headers to construct a list of Route > headers. When initiating a dialog or standalone transaction, the list of > Route headers will be pre-loaded into the initial INVITE request.. If a CSCF > wants to receive subsequent requests, it will insert its own name to the > Record Route header of the initial INVITE request. Once on the route, a CSCF > remains on the route for the duration of the call. The path learned while > re-registering during an active call does not affect the existing call, > since the routing path for the respective call has already been established. > The list of Path headers is not forwarded to the UE. I've added some discussion here, but your suggested wording is very 3GPP specific. I invite further suggestions mode generic in nature. > 3) I notice that your proposal operates independently in both > directions, i.e. a proxy can choose to be on the path as an inbound proxy, > an outbound proxy, or both. This means that you have ended with with a > different mechanism to that which 3GPP has currently documented. In 3GPP the > current mechanism operates with proxies being on the path as both inbound > and outbound proxies, and therefore the addition of URLs to the Path header > is much more similar to Record-Route (i.e. the path is built on the request, > and the entire path is passed back in the response). That's correct. I like my way better. It's very reasonable (as noted by JDR) to use PATH to discover weird proxy routes toward a UA, without using it to discover a "home outbound proxy", simply because one may not use or need a "home outbound proxy" As is. it neatly solves the problem of a "multihop registration". > > In the example you have given in the text, the changes would be as follows: > F2 Path: as currently > F4 Path: , > F5 Path: , (this is your 2nd F4) > > If you wish to change the 3GPP current intentions then we need to agree > something quickly. The 3GPP requirements do not need to separate outbound > from inbound proxies. I also cannot envisage when one would want to do this, > so I am not sure it is really a requirement. Please consider the mechanism as documented further. > 4) Your procedures seem to imply that the registrar is always located > at an outbound proxy. While this is the case in 3GPP, I had envisaged that a > registrar can be located at an outbound proxy, but that this is not > mandatory. I've amended to include "It is also possible for a node with specific knowledge of network topology to add a Path header referencing another node, thereby allowing construction of a Path which is discongreunt with the route taken by the REGISTER or REGISTER Response." in the Usage section. > 5) I was envisaging separate sections for > > - procedures at the UAC > - procedures at the proxy > - procedures at the registrar Absolutely needed. I agree. > The text of the procedures according to the 3GPP way of operation that I > have is as follows: > > Procedures at the UAC > > When a UAC receives a response to REGISTER containing the Path > header, the UAC shall remove its SIP URL from the list of Path headers, > reverse the order of the list and save the resulting list of Path headers. > This list shall be stored during the entire registration period of the > respective ???public user identity. If this registration is a > reregistration, the P-CSCF shall replace the already existing Path headers > with the new list > > A UAC MUST use any route list created by the Path mechanism during a > registration procedure as the pre-loaded route in the Route header of the > first request in a dialog, or in any request that does not form part of a > dialog. > > > Procedures at the UAS > > There are no procedures for the UAS. > > > Procedures at the proxy > > An outbound proxy that wishes to be on the path for future > transactions or dialogs relating to a REGISTER request MUST insert a > resolveable identifier that will reach the proxy as the topmost entry in the > Path header before proxying that request. > > Proxies that are not on the path of the REGISTER request cannot use > this mechanism. > > > Procedures at the registrar > > If a Path header exists in a sucessful REGISTER request, the > registrar shall construct a list of preloaded Route headers from the list of > entries in the Path header. The order in the lists is preserved. The > registrar MUST bind to each contact information the respective Path header > entries, that were received in the same REGISTER message as that contact > information. The registrar shall also return the path list as a Path header > in a 200 OK response to the REGISTER request. The last section of the preceding disagrees with the unidirectional path model. > An inbound proxy which uses the location server to determine the > Contact address of the user MUST also use this list of preloaded Route > headers in the transaction request. > > The registrar can also act as a proxy as described above (in which > case it inserts a resolvable identifier identifying itself in the Path > header) before storing the list of preloaded Route headers. > > I think the current text you have in section 5 would be best treated as an > example of operation, as appears in a number of other SIP drafts, and we > should concentrate on detailing procedures as I have identified. fair. > 6) 3GPP consider that an option-tag should also be defined where such > operation is considered essential. This would need to appear in the Require > header (where it is understood by the registrar) and the Proxy-Require > header (where it is understood by proxies) of the REGISTER request. I disagree. If a UA is expecting a Path on its register resposne and doesn't get one, it knows the registrar doesn't supply it and none of the proxies in between cared. Nodes that are unaware of Path will forward it correctly. > The text I had drafted for this is as follows: . . . > 7) And finally, in the acknowledgements can you include Min Huang and > Stinson Mathai, as they put together the original proposal in 3GPP for this > mechanism, and worked most of the 3GPP procedures in 24.229. Sure. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Feb 7 13:39:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05201 for ; Thu, 7 Feb 2002 13:39:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA08425 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 13:39:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06295; Thu, 7 Feb 2002 13:10:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06199 for ; Thu, 7 Feb 2002 13:10:44 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04212 for ; Thu, 7 Feb 2002 13:10:42 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g17IADH18586; Thu, 7 Feb 2002 12:10:13 -0600 Message-ID: <027f01c1b002$d2355be0$9219a8c0@dfw.dynamicsoft.com> From: "Dean Willis" To: "Dean Willis" , References: <017401c1af9b$262846d0$9219a8c0@dfw.dynamicsoft.com> Subject: Re: [Sip] New Path Extension Header Draft Date: Thu, 7 Feb 2002 12:11:09 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027C_01C1AFD0.872546B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_027C_01C1AFD0.872546B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Having garbled some formatting on the original and now fixed it (and = included a few early comments) I've reissued: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-01.txt -- Dean ----- Original Message -----=20 From: Dean Willis=20 To: sip@ietf.org=20 Sent: Wednesday, February 06, 2002 11:49 PM Subject: [Sip] New Path Extension Header Draft I've cobbled together a rough draft of a Path header extension in an = attempt to meet the a requirement for service route discovery during = REGISTER for 3GPP established in the Garcia 3GPP requirements draft in = the SIPPING group. It will be announced on internet-drafts soon, and you can pull from: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-00.txt ------=_NextPart_000_027C_01C1AFD0.872546B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Having garbled some formatting on the = original and=20 now fixed it (and included a few early comments) I've = reissued:
 
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-01.txt=
 
 
--
Dean
----- Original Message -----
From:=20 Dean Willis
Sent: Wednesday, February 06, = 2002 11:49=20 PM
Subject: [Sip] New Path = Extension Header=20 Draft

I've cobbled together a rough draft = of a Path=20 header extension in an attempt to meet the a requirement for service = route=20 discovery during REGISTER for 3GPP established in the Garcia 3GPP = requirements=20 draft in the SIPPING group.
 
It will be announced on = internet-drafts soon, and=20 you can pull from:
 
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-00.txt=
------=_NextPart_000_027C_01C1AFD0.872546B0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Feb 7 13:42:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05271 for ; Thu, 7 Feb 2002 13:42:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA08626 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 13:42:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06183; Thu, 7 Feb 2002 13:10:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06122 for ; Thu, 7 Feb 2002 13:10:24 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04186 for ; Thu, 7 Feb 2002 13:10:20 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g17I9mH18562; Thu, 7 Feb 2002 12:09:48 -0600 Message-ID: <027b01c1b002$c3ccb300$9219a8c0@dfw.dynamicsoft.com> From: "Dean Willis" To: "Drage, Keith \(Keith\)" Cc: References: <475FF955A05DD411980D00508B6D5FB00439E8D2@en0033exch001u.uk.lucent.com> Subject: Re: [Sip] New Path Extension Header Draft (long) Date: Thu, 7 Feb 2002 12:10:44 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Drage, Keith (Keith)" To: ; "'Dean Willis'" Sent: Thursday, February 07, 2002 11:16 AM Subject: RE: [Sip] New Path Extension Header Draft (long) > You've beaten me to this draft so here are comments based on the text I had > already written in order to get this together quicker. > > Keith > > 1) Abstract. > > I suggest this rather than the one in your proposal. Your abstract contains > too much about service-routes which are not part of the proposal, and which > are already meant to be in the bis draft. > > This draft provides a mechanism to be used in the REGISTER method, > that allows the proxies that wish to be outbound proxies in future > transactions, or inbound proxies in future transactions, and which are > situated on the signalling path between the UA and the registrar, to > communicate their URL to the UA and the registrar, such that these URLs can > form part of a preloaded route list for future transactions. I've modified your suggestion and will include > References to any 3GPP requirements should be moved to the background > section. done > 2) In section 4, you mention that Path header is based on the Route > header. It is surely more correct to say it is based on the Record-Route > header, as that is where the rr-param comes from. done > I notice that you have an extra level of decomposition in the BNF. Based on > the Record-Route header I had envisaged only: > > Path = "Path" HCOLON 1# > ( name-addr *( SEMI rr-param )) > rr-param = generic-param > > where rr-param is already defined. If we need the extra level of > decomposition, then surely this should also exist in the Record-Route header > in the bis draft. I've included both forms pending further comment > As introductory text to the section defining the BNF I would suggest the > following text: > > Path header is a mechanism whereby a proxy can request to be on a > signalling path for the request exchanged between the UE and the registrar. > The path-establishment procedure is originated by the P-CSCF during the > registration process. The procedure is performed during registration and all > subsequent reregistrations. The list of Path headers obtained by a > reregistration overwrites the existing list of Path headers at the > registrar. Each reregistration of the same UA may result in new list of Path > headers. The UA uses the list of Path headers to construct a list of Route > headers. When initiating a dialog or standalone transaction, the list of > Route headers will be pre-loaded into the initial INVITE request.. If a CSCF > wants to receive subsequent requests, it will insert its own name to the > Record Route header of the initial INVITE request. Once on the route, a CSCF > remains on the route for the duration of the call. The path learned while > re-registering during an active call does not affect the existing call, > since the routing path for the respective call has already been established. > The list of Path headers is not forwarded to the UE. I've added some discussion here, but your suggested wording is very 3GPP specific. I invite further suggestions mode generic in nature. > 3) I notice that your proposal operates independently in both > directions, i.e. a proxy can choose to be on the path as an inbound proxy, > an outbound proxy, or both. This means that you have ended with with a > different mechanism to that which 3GPP has currently documented. In 3GPP the > current mechanism operates with proxies being on the path as both inbound > and outbound proxies, and therefore the addition of URLs to the Path header > is much more similar to Record-Route (i.e. the path is built on the request, > and the entire path is passed back in the response). That's correct. I like my way better. It's very reasonable (as noted by JDR) to use PATH to discover weird proxy routes toward a UA, without using it to discover a "home outbound proxy", simply because one may not use or need a "home outbound proxy" As is. it neatly solves the problem of a "multihop registration". > > In the example you have given in the text, the changes would be as follows: > F2 Path: as currently > F4 Path: , > F5 Path: , (this is your 2nd F4) > > If you wish to change the 3GPP current intentions then we need to agree > something quickly. The 3GPP requirements do not need to separate outbound > from inbound proxies. I also cannot envisage when one would want to do this, > so I am not sure it is really a requirement. Please consider the mechanism as documented further. > 4) Your procedures seem to imply that the registrar is always located > at an outbound proxy. While this is the case in 3GPP, I had envisaged that a > registrar can be located at an outbound proxy, but that this is not > mandatory. I've amended to include "It is also possible for a node with specific knowledge of network topology to add a Path header referencing another node, thereby allowing construction of a Path which is discongreunt with the route taken by the REGISTER or REGISTER Response." in the Usage section. > 5) I was envisaging separate sections for > > - procedures at the UAC > - procedures at the proxy > - procedures at the registrar Absolutely needed. I agree. > The text of the procedures according to the 3GPP way of operation that I > have is as follows: > > Procedures at the UAC > > When a UAC receives a response to REGISTER containing the Path > header, the UAC shall remove its SIP URL from the list of Path headers, > reverse the order of the list and save the resulting list of Path headers. > This list shall be stored during the entire registration period of the > respective ???public user identity. If this registration is a > reregistration, the P-CSCF shall replace the already existing Path headers > with the new list > > A UAC MUST use any route list created by the Path mechanism during a > registration procedure as the pre-loaded route in the Route header of the > first request in a dialog, or in any request that does not form part of a > dialog. > > > Procedures at the UAS > > There are no procedures for the UAS. > > > Procedures at the proxy > > An outbound proxy that wishes to be on the path for future > transactions or dialogs relating to a REGISTER request MUST insert a > resolveable identifier that will reach the proxy as the topmost entry in the > Path header before proxying that request. > > Proxies that are not on the path of the REGISTER request cannot use > this mechanism. > > > Procedures at the registrar > > If a Path header exists in a sucessful REGISTER request, the > registrar shall construct a list of preloaded Route headers from the list of > entries in the Path header. The order in the lists is preserved. The > registrar MUST bind to each contact information the respective Path header > entries, that were received in the same REGISTER message as that contact > information. The registrar shall also return the path list as a Path header > in a 200 OK response to the REGISTER request. The last section of the preceding disagrees with the unidirectional path model. > An inbound proxy which uses the location server to determine the > Contact address of the user MUST also use this list of preloaded Route > headers in the transaction request. > > The registrar can also act as a proxy as described above (in which > case it inserts a resolvable identifier identifying itself in the Path > header) before storing the list of preloaded Route headers. > > I think the current text you have in section 5 would be best treated as an > example of operation, as appears in a number of other SIP drafts, and we > should concentrate on detailing procedures as I have identified. fair. > 6) 3GPP consider that an option-tag should also be defined where such > operation is considered essential. This would need to appear in the Require > header (where it is understood by the registrar) and the Proxy-Require > header (where it is understood by proxies) of the REGISTER request. I disagree. If a UA is expecting a Path on its register resposne and doesn't get one, it knows the registrar doesn't supply it and none of the proxies in between cared. Nodes that are unaware of Path will forward it correctly. > The text I had drafted for this is as follows: . . . > 7) And finally, in the acknowledgements can you include Min Huang and > Stinson Mathai, as they put together the original proposal in 3GPP for this > mechanism, and worked most of the 3GPP procedures in 24.229. Sure. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Feb 7 13:47:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05390 for ; Thu, 7 Feb 2002 13:47:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09094 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 13:47:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06902; Thu, 7 Feb 2002 13:23:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06871 for ; Thu, 7 Feb 2002 13:23:03 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04611 for ; Thu, 7 Feb 2002 13:23:01 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g17IMuK20188 for ; Thu, 7 Feb 2002 13:23:01 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K49XZN8>; Thu, 7 Feb 2002 18:22:56 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E8D3@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: William Marshall , "'mankin@isi.edu'" Cc: Brian.Rosen@marconi.com, rsparks@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] Last Call comments on 2543bis-07 Date: Thu, 7 Feb 2002 18:22:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I think there is a good case for keeping normative statements in the bis draft to SIP implementations (i.e. UAs, proxies, registrars, etc.). If there is really a need for normative statements on SIP designers, then I consider this should be in a separate RFC with a separate scope. I see no need for one document to normatively reference the other. Therefore we do not need a reference in bis to the tsvar document, nor to guidelines, nor do we need statements on publishing option-tags in standards track RFCs. Of course, it is not quite as simple as this. We do need some statements about what an implementor implements when he hits token in the BNF, for example. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Allison Mankin[SMTP:mankin@isi.edu] > Reply To: mankin@isi.edu > Sent: 05 February 2002 16:27 > To: William Marshall > Cc: Brian.Rosen@marconi.com; rsparks@dynamicsoft.com; sip@ietf.org > Subject: Re: [Sip] Last Call comments on 2543bis-07 > > Folks, > > Brian Rosen wrote: > > > > > > I'll let the chairs comment on this. > > > > > This chair wouldn't allow bis to be held because of a normative > reference > > to tsvarea-sipchange, but wouldn't object if that was not a problem. > > > > Bill Marshall wrote: > > > > As I understand the procedures and concerns, a normative > > references to draft-tsvarea-sipchange would hold > > bis in the RFC Editor's queue, which would delay the actual > > publication of bis as an RFC. It would not delay the assigning > > of an RFC number, which is what 3GPP wants on March 7. > > > > I'm not at all clear on how the RFC Editor will handle > > non-normative references to internet-drafts, like [30] > > SIP telephony call flow examples. If publication as an > > RFC "freezes" the text, then they may hold it in the queue > > for this, too. But again, it won't delay the assignment > > of an RFC number for 3GPP. > > > > The early RFC number procedure from RFC Editor is a favor, and > we would not like to push it by having normative references to i-ds > in there when we send them the approved bis i-d. > > This is something that I'm planning to review with the chairs and > editors before 08. > > As Scott says, we can* probably word a reference to the tsvarea- > sipchange draft to be non-normative. > > Bill continued: > > The specific text in bis-07 leading to this discussion is > > regarding option tags that MUST be defined in standards- > > track RFCs. There is no reason that needs to be a normative > > reference. It actually falls into the category of "untestable" > > uses of spec language. It would best be left out. > > > > I have some trouble agreeing that option tag extensibility rules > can't be made testable. > > What would your reaction be to registering headers that IETF has > not published in standard track or will not publish (such as the > Electronic Surveillance ones you mention) in an x- category? > > Allison > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Thu Feb 7 15:34:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09012 for ; Thu, 7 Feb 2002 15:34:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15999 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 15:34:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14552; Thu, 7 Feb 2002 15:17:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14521 for ; Thu, 7 Feb 2002 15:17:12 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08402 for ; Thu, 7 Feb 2002 15:17:08 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g17KGeH19537; Thu, 7 Feb 2002 14:16:40 -0600 Message-ID: <02eb01c1b014$7c5ba5a0$1df30a0a@dfw.dynamicsoft.com> From: "Dean Willis" To: Cc: "Joerg Ott" , "Brian Rosen" , "Adam Roach" , "Jonathan Rosenberg" References: <9BF66EBF6BEFD942915B4D4D45C051F362FFF7@DYN-TX-EXCH-001.dynamicsoft.com> Date: Thu, 7 Feb 2002 12:57:16 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC draft-ietf-sip-events-02 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We'd like to announce Working Group Last Call on the SIP Events draft. The WG last call will close on 19Feb. Until it appears in the archives, you may access a copy at: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-02.txt Also, a PDF version of the draft, with changebars, may be retrieved from: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-02.pdf --- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Feb 7 17:51:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11973 for ; Thu, 7 Feb 2002 17:51:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22239 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 17:51:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21566; Thu, 7 Feb 2002 17:31:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21537 for ; Thu, 7 Feb 2002 17:31:34 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11593 for ; Thu, 7 Feb 2002 17:31:31 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g17MV4H22802; Thu, 7 Feb 2002 16:31:04 -0600 Message-ID: <045401c1b027$42d08720$1df30a0a@dfw.dynamicsoft.com> From: "Dean Willis" To: "Dean Willis" , Date: Thu, 7 Feb 2002 16:32:00 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Revised SIP bis RFC Work Plan Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rats, that should have been 8Mar for the 3GPP Plenary . . . (Thanks, Gonzo!) ----- Original Message ----- From: "Dean Willis" To: Sent: Thursday, February 07, 2002 4:30 PM Subject: Revised SIP bis RFC Work Plan > Note that I'm learning a little more about IETF process as we go. Turns out > that "Sending to IESG" and "IETF Last Call" are synonymous. So, the revised > plan for bis should be: > > we're in WGLC now, on bis-07 > > 19Feb, -- end WGLC, incorporate comments into bis-08 > > 21 Feb -- release bis08, send to IETF Last Call. . . . there may be a bis09 > during this period if any feedback from IETF last call prompts it . . . > We'll try and synchronize sip-events and sip-srv with bis for IETF Last > Call. > > 7Mar -- IESG meeting. Assuming IESG accepts, send draft to RFC editor, get > RFC number, and send RFC# to 3GPP, as they need it before their plenary > meetings end on 8Feb in Korea. > > -- > 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 daemon@ns.ietf.org Thu Feb 7 17:52:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11997 for ; Thu, 7 Feb 2002 17:52:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22275 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 17:52:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21088; Thu, 7 Feb 2002 17:29:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21057 for ; Thu, 7 Feb 2002 17:29:52 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11550 for ; Thu, 7 Feb 2002 17:29:49 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g17MTMH22773 for ; Thu, 7 Feb 2002 16:29:22 -0600 Message-ID: <044701c1b027$060e2d10$1df30a0a@dfw.dynamicsoft.com> From: "Dean Willis" To: Date: Thu, 7 Feb 2002 16:30:18 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Revised SIP bis RFC Work Plan Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Note that I'm learning a little more about IETF process as we go. Turns out that "Sending to IESG" and "IETF Last Call" are synonymous. So, the revised plan for bis should be: we're in WGLC now, on bis-07 19Feb, -- end WGLC, incorporate comments into bis-08 21 Feb -- release bis08, send to IETF Last Call. . . . there may be a bis09 during this period if any feedback from IETF last call prompts it . . . We'll try and synchronize sip-events and sip-srv with bis for IETF Last Call. 7Mar -- IESG meeting. Assuming IESG accepts, send draft to RFC editor, get RFC number, and send RFC# to 3GPP, as they need it before their plenary meetings end on 8Feb in Korea. -- 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 daemon@ns.ietf.org Thu Feb 7 17:53:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12013 for ; Thu, 7 Feb 2002 17:53:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22315 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 17:53:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21612; Thu, 7 Feb 2002 17:32:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21581 for ; Thu, 7 Feb 2002 17:32:32 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11623 for ; Thu, 7 Feb 2002 17:32:29 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g17MWh6Y017082; Thu, 7 Feb 2002 17:32:44 -0500 (EST) Message-ID: <3C63005F.FD59A5F7@dynamicsoft.com> Date: Thu, 07 Feb 2002 17:31:59 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: sip@ietf.org Subject: Re: [Sip] bug in date header specification References: <15458.49267.636465.51849@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha Heinanen wrote: > > Jonathan Rosenberg writes: > > > HTTP-date = rfc1123-date | rfc850-date | asctime-date > > rfc1123-date = wkday "," SP date1 SP time SP "GMT" > > > > So, we are consistent with that. > > ok, i just looked rfc 1123 and there a syntax item called "date" doesn't > include time, but "date-time" does. in order to avoid confusion, the > first sentence > > The Date header field contains an RFC 1123 date (see [H14.18]). > > could be changed to > > The Date header field contains an rfc1123-date (see [H14.18]). I just changed to "The Date header field contains the date and time." -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Thu Feb 7 18:21:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12679 for ; Thu, 7 Feb 2002 18:21:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23785 for sip-archive@odin.ietf.org; Thu, 7 Feb 2002 18:21:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22409; Thu, 7 Feb 2002 17:56:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22378 for ; Thu, 7 Feb 2002 17:56:31 -0500 (EST) Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12098 for ; Thu, 7 Feb 2002 17:56:27 -0500 (EST) Received: (qmail 22819 invoked by alias); 7 Feb 2002 22:56:32 -0000 Received: from unknown (HELO indigosw.com) (194.78.202.25) by 0 with SMTP; 7 Feb 2002 22:56:32 -0000 Message-ID: <3C630638.7020406@indigosw.com> Date: Thu, 07 Feb 2002 23:56:56 +0100 From: Torrey Searle User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020206 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] question on draft-ietf-sip-events-02 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit in section 4.1.1 of the sip events draft it says that a 200 response to a SUBSCRIBE may lengthen or shorten the duration of a subscribtion. in section 4.1.6.1 it says that a 200 response to a SUBSCRIBE can shorten the duration, but MUST not lengthen it. It seems these two statements are in conflict, which one should be the correct statement to follow? Torrey Searle Indigo Software _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Feb 8 00:28:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20664 for ; Fri, 8 Feb 2002 00:28:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA06996 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 00:28:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06456; Fri, 8 Feb 2002 00:09:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06430 for ; Fri, 8 Feb 2002 00:09:04 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20323 for ; Fri, 8 Feb 2002 00:09:04 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1859H6Y017361; Fri, 8 Feb 2002 00:09:18 -0500 (EST) Message-ID: <3C635D50.5779327@dynamicsoft.com> Date: Fri, 08 Feb 2002 00:08:32 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Torrey Searle CC: sip@ietf.org Subject: Re: [Sip] question on draft-ietf-sip-events-02 References: <3C630638.7020406@indigosw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We should be consistent on this with bis. Our conclusion was that the duration of registrations cannot be increased, not reduced, and the same should go for subscriptions. -Jonathan R. Torrey Searle wrote: > > in section 4.1.1 of the sip events draft it says that a 200 response to > a SUBSCRIBE may lengthen or shorten the duration of a subscribtion. > > in section 4.1.6.1 it says that a 200 response to a SUBSCRIBE can > shorten the duration, but MUST not lengthen it. > > It seems these two statements are in conflict, which one should be the > correct statement to follow? > > Torrey Searle > Indigo Software > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Fri Feb 8 00:38:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20818 for ; Fri, 8 Feb 2002 00:38:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA07621 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 00:38:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06916; Fri, 8 Feb 2002 00:22:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06885 for ; Fri, 8 Feb 2002 00:22:57 -0500 (EST) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20538 for ; Fri, 8 Feb 2002 00:22:55 -0500 (EST) Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g185MOA02237 for ; Fri, 8 Feb 2002 10:52:25 +0530 (IST) Received: from m1coet3567 ([10.115.6.222]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GR789601.WG2; Fri, 8 Feb 2002 10:52:18 +0530 Reply-To: From: "VIDHI RASTOGI" To: "'Jonathan Rosenberg'" , Date: Fri, 8 Feb 2002 10:56:02 +0530 Message-ID: <000e01c1b061$1a32fcf0$de06730a@m1coet3567> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-6262ce1e-1c44-11d6-af7e-0080c8048dde" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-reply-to: <3C63005F.FD59A5F7@dynamicsoft.com> Subject: [Sip] To tag in 101-199 responses [bis07] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPartTM-000-6262ce1e-1c44-11d6-af7e-0080c8048dde Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have a question regarding the To tags in the 1xx response.. Sec 8.2.6.2 of bis-07 states that "the UAS MUST add a tag to the To field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present)...." This would mean that a provisional response (say 180) for INVITE request would always establish an early dialog. But according to "Sec10.2.2.1" of the same draft, " The early dialog will only be needed if the UAC needs to send a request to its peer within the dialog before the initial INVITE transaction completes. This will be the case for all reliable provisional responses, which require transmission of PRACK." This section implies that an early dialog is not mandatory. But the To Tag present in the 180 response would always result in an early dialog. Could you please explain the intent behind adding a To-Tag in all the provisional responses (except 100 trying). Is there any way to avoid early dialogs, if the UAC does not want to establish one. When the transaction layer receives a provisional response with a To Tag, does it need to clone the transaction? Please let me know if I am missing something here.. thanks & regards Vidhi ------=_NextPartTM-000-6262ce1e-1c44-11d6-af7e-0080c8048dde Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPartTM-000-6262ce1e-1c44-11d6-af7e-0080c8048dde-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Feb 8 00:51:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20964 for ; Fri, 8 Feb 2002 00:51:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA07924 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 00:51:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07269; Fri, 8 Feb 2002 00:30:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07238 for ; Fri, 8 Feb 2002 00:30:30 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20727 for ; Fri, 8 Feb 2002 00:30:29 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g185Uh6Y017369; Fri, 8 Feb 2002 00:30:44 -0500 (EST) Message-ID: <3C636258.BB184578@dynamicsoft.com> Date: Fri, 08 Feb 2002 00:30:00 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Venkatesh Venkataramanan CC: "'sip@ietf.org'" Subject: Re: [Sip] Some thoughts about sip-reconstitute-state and session timers. References: <79FEAA5FABA7D411BF580001023D1BBD9CFC02@mailserver.sylantro.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Venkatesh Venkataramanan wrote: > > I was wondering if we could enhance sip-session-timer-08.txt to make the > UA > that is waiting for 'session refreshes' to send a re-INVITE before it > tears > the call down by sending a BYE on session-timer expiry (rather a few > seconds > before the expiry). This would assist such applications to reconstitute > state of sessions as well if they persist exactly the same information > that > is indicated in the sip-reconstitute-state draft and keep such dialogs > active. Well, I don't see anything wrong with doing that per se, but there are two issues: 1. session-timer has already gone to IESG, so it is a bit late for addition of features to the draft, 2. Its not clear to me what the scope of applicability of this would be. Specifically, the amount of time it takes to discover failures with session timer is really, really long. More than likely if you application crashed for 20m before that was reconstitiuted by session timer, its been gone too long to be useful. Session timer is really meant as a state cleanup mechanism, i.e., a long term garbage collector, not for failure recovery. The ICMP approach in the reconstitute draft is very rapid because it uses the media stream. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 01:35:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21429 for ; Fri, 8 Feb 2002 01:35:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA18936 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 01:35:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12849; Fri, 8 Feb 2002 01:08:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12776 for ; Fri, 8 Feb 2002 01:08:28 -0500 (EST) Received: from mailserver.sylantro.com ([65.200.90.207]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21145 for ; Fri, 8 Feb 2002 01:08:27 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Thu, 07 Feb 2002 22:03:19 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id <1F5J8HD0>; Thu, 7 Feb 2002 22:03:19 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD9CFC15@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "'Jonathan Rosenberg'" cc: "'sip@ietf.org'" Subject: RE: [Sip] Some thoughts about sip-reconstitute-state and session timers. Date: Thu, 7 Feb 2002 22:03:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 107DB5AD142259-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: Thanks for the reply! In response to item 2, consider the following: A B2B UA (or a 3pcc kind of application that is enabling click to call services). Or an example would be say a calling card type service. User calls in. He/she is prompted for his PIN and card id. Once authenticated, he/she is requested to dial the number that needs to be contacted. The IVR app places a new call, and bridges the two. It now waits for hang up from one side and then prompts user to dial next number or terminates both calls if his/her calling card is exhausted. In this scenario, the B2B UA is really assisting in setting up a dialog between 2 end points. Once the dialog is established, the application is not in the media path. It sends out peridic reINVITES to keep both these call legs active/detect any far end crashes. A BYE from one side triggers a disconnect to the other. The thought I had in mind is to allow calls set up by applications such as this to reconstitute states and provide a mechanism for such applications to recover from crashes, implementing session timers would terminate these calls although from an end user perspective neither of their phones never really crashed? Venkatesh -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, February 07, 2002 9:30 PM To: Venkatesh Venkataramanan Cc: 'sip@ietf.org' Subject: Re: [Sip] Some thoughts about sip-reconstitute-state and session timers. Venkatesh Venkataramanan wrote: > > I was wondering if we could enhance sip-session-timer-08.txt to make the > UA > that is waiting for 'session refreshes' to send a re-INVITE before it > tears > the call down by sending a BYE on session-timer expiry (rather a few > seconds > before the expiry). This would assist such applications to reconstitute > state of sessions as well if they persist exactly the same information > that > is indicated in the sip-reconstitute-state draft and keep such dialogs > active. Well, I don't see anything wrong with doing that per se, but there are two issues: 1. session-timer has already gone to IESG, so it is a bit late for addition of features to the draft, 2. Its not clear to me what the scope of applicability of this would be. Specifically, the amount of time it takes to discover failures with session timer is really, really long. More than likely if you application crashed for 20m before that was reconstitiuted by session timer, its been gone too long to be useful. Session timer is really meant as a state cleanup mechanism, i.e., a long term garbage collector, not for failure recovery. The ICMP approach in the reconstitute draft is very rapid because it uses the media stream. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 01:48:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21589 for ; Fri, 8 Feb 2002 01:48:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA19212 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 01:48:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18838; Fri, 8 Feb 2002 01:31:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18797 for ; Fri, 8 Feb 2002 01:31:00 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21393 for ; Fri, 8 Feb 2002 01:30:58 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g186UPH25666; Fri, 8 Feb 2002 00:30:25 -0600 Message-ID: <06a801c1b06a$3a0e6b50$1df30a0a@dfw.dynamicsoft.com> From: "Dean Willis" To: "William Marshall" , References: <200112271650.LAA87369@fish.research.att.com> Subject: Re: [Sip] SIP WG - 5 - Last Call Open Discussion - draft-ietf-sip-refer-02.txt Date: Fri, 8 Feb 2002 00:31:21 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "William Marshall" > Without an adequate mechanism to verify the information in the Referred-By > header, and to verify the timeliness of that information, the header is > worse than useless. It should be removed from the draft. Strong wording from someone who trusts the network to provide "remote party ID suitable for law enforcement purposes" with no means for authenticating it . . . Whoa! Was that an evil comeback line, or what? -- 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 daemon@optimus.ietf.org Fri Feb 8 03:04:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00684 for ; Fri, 8 Feb 2002 03:04:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA22431 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 03:04:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21387; Fri, 8 Feb 2002 02:47:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21355 for ; Fri, 8 Feb 2002 02:47:14 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00432 for ; Fri, 8 Feb 2002 02:47:12 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g187lQ6Y017435; Fri, 8 Feb 2002 02:47:28 -0500 (EST) Message-ID: <3C638261.B38B8A44@dynamicsoft.com> Date: Fri, 08 Feb 2002 02:46:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vidhi.rastogi@wipro.com CC: sip@ietf.org References: <000e01c1b061$1a32fcf0$de06730a@m1coet3567> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: To tag in 101-199 responses [bis07] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit VIDHI RASTOGI wrote: > > Hi, > I have a question regarding the To tags in the 1xx response.. > > Sec 8.2.6.2 of bis-07 states that > > "the UAS MUST add a tag to the To field in the response > (with the exception of the 100 (Trying) response, in which a tag MAY > be present)...." > > This would mean that a provisional response (say 180) for INVITE request > would always establish an early dialog. > But according to "Sec10.2.2.1" of the same draft, > > " The early dialog will only be needed if the UAC needs to send a > request to its peer within the dialog before the initial INVITE > transaction completes. This will be the case for all reliable > provisional responses, which require transmission of PRACK." > > This section implies that an early dialog is not mandatory. But the To > Tag > present in the 180 response would always result in an early dialog. The text in 10.2.2.1 is saying that even though the tag is there, the UAC need not construct the actual early dialog. Doing that would only be needed if it had to send a request or some other such thing. However, on pondering this further, it occurs to me that we could be in trouble down the road if the UAC doesn't always build the early dialog. The reason is that the UAS might send a COMET/UPDATE eventually. If it sends a 18x first, with a tag, but the UAC ignores the tag and doesn't build a dialog, and then the UAS sends a COMET/UPDATE, that will not properly match any existing dialog at the caller. The solution is to either (1) mdante the UAC to build an early dialog for any tags, in which case we probably should relax the constraint on tags in provisionals, or (2) allow for a COMET/UPDATE to create a dialog, much like a NOTIFY can for SUBSCRIBE. In the case of (2), this would be handled entirely within the specification of COMET/UPDATE. I'll need to ponder that one some more. > > Could you please explain the intent behind adding a To-Tag in all the > provisional > responses (except 100 trying). Is there any way to avoid early dialogs, > if > the UAC > does not want to establish one. We made tags in all 1xx mandatory to make things simpler, and also, figured that more information is always better than less. After all, the UAC is going to want to know which provisional responses are from the which UASs, and it can't do that unless they are tagged. > > When the transaction layer receives a provisional response with a To > Tag, > does it > need to clone the transaction? No, of course not. Transactions and dialogs are independent things. Each provisional response, with or without tags, is passed from the server transaction to the TU. The TU deals with dialogs. Note, however, that how you build your implementation is your choice. If you have implemented a transaction layer in code that does some dialog work too, you may need to clone it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 03:09:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00796 for ; Fri, 8 Feb 2002 03:09:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA22684 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 03:09:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21072; Fri, 8 Feb 2002 02:35:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21048 for ; Fri, 8 Feb 2002 02:35:18 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00293 for ; Fri, 8 Feb 2002 02:35:17 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g187ZX6Y017425; Fri, 8 Feb 2002 02:35:33 -0500 (EST) Message-ID: <3C637F98.39489CD9@dynamicsoft.com> Date: Fri, 08 Feb 2002 02:34:48 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Torrey Searle , sip@ietf.org Subject: Re: [Sip] question on draft-ietf-sip-events-02 References: <3C635D50.5779327@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > We should be consistent on this with bis. Our conclusion was that the > duration of registrations cannot be increased, not reduced, and the same ^^^ | only > should go for subscriptions. Sorry about that, Jonathan R. > Torrey Searle wrote: > > > > in section 4.1.1 of the sip events draft it says that a 200 response > to > > a SUBSCRIBE may lengthen or shorten the duration of a subscribtion. > > > > in section 4.1.6.1 it says that a 200 response to a SUBSCRIBE can > > shorten the duration, but MUST not lengthen it. > > > > It seems these two statements are in conflict, which one should be the > > correct statement to follow? > > > > Torrey Searle > > Indigo Software > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 07:56:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04981 for ; Fri, 8 Feb 2002 07:56:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA04462 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 07:56:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04013; Fri, 8 Feb 2002 07:36:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03982 for ; Fri, 8 Feb 2002 07:36:09 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04607; Fri, 8 Feb 2002 07:36:06 -0500 (EST) Message-Id: <200202081236.HAA04607@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 08 Feb 2002 07:36:06 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-events-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : SIP-Specific Event Notification Author(s) : A. Roach Filename : draft-ietf-sip-events-02.txt Pages : 41 Date : 07-Feb-02 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Concrete uses of the mechanism described in this document may be standardized in the future. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-events-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-events-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-ietf-sip-events-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020207165952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-events-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-events-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020207165952.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 8 11:33:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13903 for ; Fri, 8 Feb 2002 11:33:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18688 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 11:33:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17279; Fri, 8 Feb 2002 11:18:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17172 for ; Fri, 8 Feb 2002 11:17:59 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13250 for ; Fri, 8 Feb 2002 11:17:56 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AA374B5E0370; Fri, 08 Feb 2002 11:17:59 -0500 Message-ID: <000901c1b0ba$ed7a37a0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Jonathan Rosenberg" , Date: Fri, 8 Feb 2002 11:09:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] bis-07: conflicting statements on route refresh Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There are conflicting statements about what a "route refresh request" can change. Line 1862 says "A route refresh request sent within a dialog is defined as a request that can modify the route set of the dialog." However, line 1951 says "Route refresh requests only update the dialog's remote target URI, and not the route set formed ..." Based on the backward compatibility note at 1952, the statement at 1862 should be modified or clarified. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.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 daemon@optimus.ietf.org Fri Feb 8 12:02:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14790 for ; Fri, 8 Feb 2002 12:02:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22181 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 12:02:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20267; Fri, 8 Feb 2002 11:46:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20232 for ; Fri, 8 Feb 2002 11:46:35 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14414 for ; Fri, 8 Feb 2002 11:46:30 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g18Gi24q006600; Fri, 8 Feb 2002 11:44:02 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Feb 2002 11:45:59 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F363001B@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Torrey Searle'" , sip@ietf.org Subject: RE: [Sip] question on draft-ietf-sip-events-02 Date: Fri, 8 Feb 2002 11:45:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Good catch. I missed that one; sorry. /a > -----Original Message----- > From: Torrey Searle [mailto:tsearle@indigosw.com] > Sent: Thursday, February 07, 2002 4:57 PM > To: sip@ietf.org > Subject: [Sip] question on draft-ietf-sip-events-02 > > > in section 4.1.1 of the sip events draft it says that a 200 > response to > a SUBSCRIBE may lengthen or shorten the duration of a subscribtion. > > in section 4.1.6.1 it says that a 200 response to a SUBSCRIBE can > shorten the duration, but MUST not lengthen it. > > It seems these two statements are in conflict, which one > should be the > correct statement to follow? > > Torrey Searle > Indigo Software > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Fri Feb 8 12:10:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15190 for ; Fri, 8 Feb 2002 12:10:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22861 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 12:10:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20493; Fri, 8 Feb 2002 11:50:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20464 for ; Fri, 8 Feb 2002 11:50:25 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14518 for ; Fri, 8 Feb 2002 11:50:22 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g18Glw4q006661; Fri, 8 Feb 2002 11:47:58 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1NKG9D4W>; Fri, 8 Feb 2002 11:49:54 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F363001C@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Adam Roach , "'Torrey Searle'" , sip@ietf.org Subject: RE: [Sip] question on draft-ietf-sip-events-02 Date: Fri, 8 Feb 2002 11:49:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I realized my response was less than useful. The correct answer is that the duration rules are the same as for 2543bis: increases are not allowed; decreases are. In other words, the text in section 4.1.6.1 is correct. This (and any other nits) will be reflected in the -03 draft. /a > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Friday, February 08, 2002 10:46 AM > To: 'Torrey Searle'; sip@ietf.org > Subject: RE: [Sip] question on draft-ietf-sip-events-02 > > > Good catch. I missed that one; sorry. > > /a > > > -----Original Message----- > > From: Torrey Searle [mailto:tsearle@indigosw.com] > > Sent: Thursday, February 07, 2002 4:57 PM > > To: sip@ietf.org > > Subject: [Sip] question on draft-ietf-sip-events-02 > > > > > > in section 4.1.1 of the sip events draft it says that a 200 > > response to > > a SUBSCRIBE may lengthen or shorten the duration of a subscribtion. > > > > in section 4.1.6.1 it says that a 200 response to a SUBSCRIBE can > > shorten the duration, but MUST not lengthen it. > > > > It seems these two statements are in conflict, which one > > should be the > > correct statement to follow? > > > > Torrey Searle > > Indigo Software > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Fri Feb 8 13:05:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17716 for ; Fri, 8 Feb 2002 13:05:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26650 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 13:05:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24948; Fri, 8 Feb 2002 12:38:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24897 for ; Fri, 8 Feb 2002 12:38:46 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16715 for ; Fri, 8 Feb 2002 12:38:45 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g18Hcw6Y017837; Fri, 8 Feb 2002 12:38:58 -0500 (EST) Message-ID: <3C640D05.2A75077@dynamicsoft.com> Date: Fri, 08 Feb 2002 12:38:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter =?iso-8859-1?Q?P=E4ppinghaus?= CC: sip@ietf.org References: <3C63D3F8.8F4AC103@icn.siemens.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] Re: [Sipping] Flaw in loose routing? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Moved to sip, and inline. Peter P�ppinghaus wrote: > > Hi, > > I have a few questions and comments on the bis-07 draft of SIP, mainly > concerning the new loose routing mechanism. > > 1) Unless I misunderstand something, I believe there is a flaw in the > loose routing mechanism, leading to the consequence that a loose routing > proxy may have to handle a request differently depending on whether the > previous hop proxy is a strict or a loose router. Presumably this is an > undesired effect. > > I'll try to explain the problem using a modification of the Basic SIP > Trapezoid example of section 16.11.1.1 in bis-07. > > Assume the initial INVITE sent by U1 (cf. line 2983f.) has a preloaded > Route header, and so the following request is forwarded from U1 to proxy > P1. > > INVITE sip:callee@domain.com SIP/2.0 > Route: > Route: > Contact: sip:caller@u1.example.com > > P1 then forwards the following request to proxy P2. > > INVITE sip:callee@domain.com SIP/2.0 > Route: > Contact: sip:caller@u1.example.com > Record-Route: > > P2 processes this request according to sections 16.3, 16.4 and 16.5 of > bis-07. Let us assume the request was successfully validated (section > 16.3) and processing of section 16.4 follows. The processing of lines > 2456-2484 effectively is a no-op in this case (P2 being responsible for > domain.com). Now P2 runs a location service yielding several possible > destinations to route the request to. But since there is a Route header > present in the request, P2 is not allowed to fork, P2 MUST choose a > single destination, place it into the Request-URI and continue according > to section 16.5. Good catch. The problem is that the route stripping needs to happen fairly early on. We'll move the text to the right place. Thanks. > In my opinion it seems that in the procedures of sections 16.4 and 16.5 > a loose routing proxy removes a topmost Route header addressing itself > much too late. One can consider the processing of lines 2452-2474 as > preprocessing. If checking and possibly removing the topmost Route > header would be done immediately after this preprocessing stage, and > before determining the destination set, then the problem outlined above > would disappear. Agreed. > > Maybe I overlook some other problem being created by such an early > removal of an own Route header. Not that I can think of; maybe Robert has some thoughts but I think it is just an oversight. Mostly because our thinking during most of the writing was about requests that had route headers all the way through to the end. > > 2) Semantics and manipulation of Request-URI and Route headers are now > clearly separated in SIP. In view of this, I find the title of section > 16.4 ("Making a Routing Decision") very confusing. Another excellent point. We should be consisting in our usage of terminology, and the new split now introduces two things - discovery of the destination, and figuring out the route to get there. Determining the > destination set (and accordingly updating the Request-URI) is what > section 16.4 really is about. This confusion is enhanced by wording like > "At this point, the proxy must decide where to forward the request." > (line 2452), "next-hop location" (line 2455), "the element MAY use > whatever mechanism it desires to determine where to send the request." > (line 2486f.). Only after reading section 16.5, it became clear to me > that the next-hop routing decision (namely possibly updating the Route > header and forwarding the request according to the topmost Route header, > if present) is the subject of section 16.5 and not of section 16.4. We'll work through this text to make it more consistent. THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 13:13:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18040 for ; Fri, 8 Feb 2002 13:13:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26905 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 13:13:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25773; Fri, 8 Feb 2002 12:52:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25730 for ; Fri, 8 Feb 2002 12:52:31 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17323 for ; Fri, 8 Feb 2002 12:52:29 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g18Hq16Y017847; Fri, 8 Feb 2002 12:52:02 -0500 (EST) Message-ID: <3C641014.1413D432@dynamicsoft.com> Date: Fri, 08 Feb 2002 12:51:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Yadavalli, Satyamurthy" CC: "'Alan Johnston'" , "'Aymeric MOIZARD'" , sip@ietf.org, sip-implementors@cs.columbia.edu Subject: Re: [Sip] RE: [Sip-implementors] draft-ietf-sip-service-examples-03.txt References: <61891BA043DED21180920090273F17380374B83F@tnint06.telogy.design.ti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Yadavalli, Satyamurthy" wrote: > > I keep hearing these terms 3pcc, B2BUA, and other approaches etc., and I > wonder how different vendors of SIP components (UAs, proxy servers > etc.,) > will be able to realize supplementary features (sip-service-examples) > each > independantly presuming an approach for each feature. > The same thing said differently: for a simple feature like call > forwarding....should the UA do it or should the proxy do it. If there > exists > no specification how would different vendors interoperate to achieve the > call control features across networks? The SIP spec doesn't tell an operator what services to role out, where to put them, and so on. The sip spec, and the rest of the specifications, ensure that the proper SIP tools exist to make the service work. Let us take the case of forwarding. It can be done in a proxy in the network, or in a UA. If a provider chooses not to do it, all that means is that their service doesn't offer the feature. You can choose to get a UA that does it, or not, and that would be a user's choice. If the provider does implement it, the user can make use of that service, or disable it, and then have it provided on their UA. In all cases, there is no interop problems at all. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 13:14:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18082 for ; Fri, 8 Feb 2002 13:14:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26922 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 13:14:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25331; Fri, 8 Feb 2002 12:45:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25303 for ; Fri, 8 Feb 2002 12:45:13 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17021 for ; Fri, 8 Feb 2002 12:45:11 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g18HjQ6Y017844; Fri, 8 Feb 2002 12:45:26 -0500 (EST) Message-ID: <3C640E89.47D102C3@dynamicsoft.com> Date: Fri, 08 Feb 2002 12:44:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: sip@ietf.org References: <000901c1b0ba$ed7a37a0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: bis-07: conflicting statements on route refresh Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bob Penfield wrote: > > There are conflicting statements about what a "route refresh request" > can > change. > > Line 1862 says "A route refresh request sent within a dialog is defined > as a > request that can modify the route set of the dialog." > > However, line 1951 says "Route refresh requests only update the dialog's > remote target URI, and not the route set formed ..." > > Based on the backward compatibility note at 1952, the statement at 1862 > should be modified or clarified. Yup. Again, another artifcat of the split of contact out of the route set, into a new element, called the remote target. Indeed, based on this, the name "route refresh request" is entirely wrong; it doesn't affect the route set at all as defined now! Thus, we will rename it to something more suitable, say "target refresh request", and make sure the inconsistencies are straightened out. THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 13:25:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18473 for ; Fri, 8 Feb 2002 13:25:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27154 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 13:25:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26597; Fri, 8 Feb 2002 13:04:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26570 for ; Fri, 8 Feb 2002 13:04:44 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17683 for ; Fri, 8 Feb 2002 13:04:42 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g18I3t013077; Fri, 8 Feb 2002 13:03:56 -0500 (EST) Received: from cisco.com (rtp-vpn1-198.cisco.com [10.82.224.198]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAS45116; Fri, 8 Feb 2002 13:03:36 -0500 (EST) Message-ID: <3C6412F8.8090702@cisco.com> Date: Fri, 08 Feb 2002 13:03:36 -0500 From: Suheel Hussain Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Yadavalli, Satyamurthy" CC: "'Alan Johnston'" , "'Aymeric MOIZARD'" , sip@ietf.org, sip-implementors@cs.columbia.edu Subject: Re: [Sip] RE: [Sip-implementors] draft-ietf-sip-service-examples-03.txt References: <61891BA043DED21180920090273F17380374B83F@tnint06.telogy.design.ti.com> Content-Type: multipart/alternative; boundary="------------000507090905020001050406" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --------------000507090905020001050406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Satya, From point of view, SIP pushes major decisions -- call setup, etc. -- into UA. For all practical purpose proxy should not take part in call-control. It is upto network designer to designate one or more UAs as call manager to provide features like call forwarding. -suheel Yadavalli, Satyamurthy wrote: >I keep hearing these terms 3pcc, B2BUA, and other approaches etc., and I >wonder how different vendors of SIP components (UAs, proxy servers etc.,) >will be able to realize supplementary features (sip-service-examples) each >independantly presuming an approach for each feature. >The same thing said differently: for a simple feature like call >forwarding....should the UA do it or should the proxy do it. If there exists >no specification how would different vendors interoperate to achieve the >call control features across networks? >-satya > > >>-----Original Message----- >>From: Alan Johnston [mailto:alan.johnston@wcom.com] >>Sent: Wednesday, January 23, 2002 2:45 PM >>To: 'Aymeric MOIZARD' >>Cc: sip-implementors@cs.columbia.edu >>Subject: RE: [Sip-implementors] draft-ietf-sip-service-examples-03.txt >> >> >>Hi Aymeric, >> >>An example of where 3pcc or B2BUA might be a better choice would be if >>some of the UAs invoved in a session to be transferred do not support >>the REFER method. Generally, the advantage of 3pcc or B2BUA >>is that they >>rely on SIP without requiring extensions or feature support. >> >>Thanks, >>Alan Johnston >>WorldCom >>sip:alan@siptest.wcom.com >> >>>-----Original Message----- >>>From: sip-implementors-admin@cs.columbia.edu >>>[mailto:sip-implementors-admin@cs.columbia.edu] On Behalf Of >>>Aymeric MOIZARD >>>Sent: Monday, January 21, 2002 9:36 AM >>>Cc: sip-implementors@cs.columbia.edu >>>Subject: [Sip-implementors] draft-ietf-sip-service-examples-03.txt >>> >>> >>> >>>Hi, >>>the draft "draft-ietf-sip-service-examples-03.txt" >>>states in the "1. Overview" section that: >>> >>>"...Also, these flows do not represent the only way to >>>implement these services - other approaches such as 3pcc >>>(Third Party Call Control) or Back-to-Back User Agents >>>(B2BUA) may be more appropriate in some circumstances." >>> >>>Does anybody can help and give some highlights about which >>>"circumstances" can lead to choosing another approach. >>> >>>Thanks >>>Aymeric >>>_______________________________________________ >>>Sip-implementors mailing list >>>Sip-implementors@cs.columbia.edu >>>http://lists.cs.columbia.edu/mailman/listinfo/> sip-implementors >>> >>_______________________________________________ >>Sip-implementors mailing list >>Sip-implementors@cs.columbia.edu >>http://lists.cs.columbia.edu/mailman/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 > --------------000507090905020001050406 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Satya,

From point of view, SIP pushes major decisions -- call setup, etc. -- into
UA. For all practical purpose proxy should not take part in call-control. It is
upto network designer to designate one or more UAs as call manager to
provide features like call forwarding.

-suheel 

Yadavalli, Satyamurthy wrote:
I keep hearing these terms 3pcc, B2BUA, and other approaches etc., and I
wonder how different vendors of SIP components (UAs, proxy servers etc.,)
will be able to realize  supplementary features (sip-service-examples) each
independantly presuming an  approach for each feature.
The same thing said differently: for a simple feature like call
forwarding....should the UA do it or should the proxy do it. If there exists
no specification how would different vendors interoperate to achieve the
call control features across networks?
-satya


-----Original Message-----
From: Alan Johnston [mailto:alan.johnston@wcom.com]
Sent: Wednesday, January 23, 2002 2:45 PM
To: 'Aymeric MOIZARD'
Cc: sip-implementors@cs.columbia.edu
Subject: RE: [Sip-implementors] draft-ietf-sip-service-examples-03.txt


Hi Aymeric,

An example of where 3pcc or B2BUA might be a better choice would be if
some of the UAs invoved in a session to be transferred do not support
the REFER method. Generally, the advantage of 3pcc or B2BUA 
is that they
rely on SIP without requiring extensions or feature support.

Thanks,
Alan Johnston
WorldCom
sip:alan@siptest.wcom.com

-----Original Message-----
From: sip-implementors-admin@cs.columbia.edu 
[mailto:sip-implementors-admin@cs.columbia.edu] On Behalf Of 
Aymeric MOIZARD
Sent: Monday, January 21, 2002 9:36 AM
Cc: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] draft-ietf-sip-service-examples-03.txt



Hi,
the draft "draft-ietf-sip-service-examples-03.txt"
states in the "1. Overview" section that:

"...Also, these flows do not represent the only way to 
implement these services - other approaches such as 3pcc 
(Third Party Call Control) or Back-to-Back User Agents 
(B2BUA) may be more appropriate in some circumstances."

Does anybody can help
 and give some highlights about which 
"circumstances" can lead to choosing another approach.

Thanks
Aymeric
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu 
http://lists.cs.columbia.edu/mailman/listinfo/> sip-implementors

_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/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


--------------000507090905020001050406-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 8 14:18:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20169 for ; Fri, 8 Feb 2002 14:18:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00183 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 14:18:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28888; Fri, 8 Feb 2002 13:59:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28860 for ; Fri, 8 Feb 2002 13:59:20 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19462 for ; Fri, 8 Feb 2002 13:59:17 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g18IxS6Y017915; Fri, 8 Feb 2002 13:59:28 -0500 (EST) Message-ID: <3C641FE4.472DCB57@dynamicsoft.com> Date: Fri, 08 Feb 2002 13:58:44 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: Peter =?iso-8859-1?Q?P=E4ppinghaus?= , sip@ietf.org References: <000d01c1b0c6$51b1bb20$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] Flaw in loose routing? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bob Penfield wrote: > > > They do say it, in bullet 5: > > > > In absence of a policy for forwarding a request through specific next > > hops, the proxy MUST inspect the topmost Route header field value. If > > that value indicates this proxy, the proxy MUST remove the > > value from the copy (removing the Route header field if that was the > > only value). > > That's in 16.5, I mean the procedures in 16.4. It says that the proxy > computes a set of destinations. But it also says if there is a route > header, > then is should only put one destination in that set (line 2487). > Shouldn't > it check the route header for its own address BEFORE it consults the > location service to construct a set of destinations? Yes. I agreed with Peter's comment in that regard, and the change will be made. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 14:27:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21207 for ; Fri, 8 Feb 2002 14:27:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00550 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 14:27:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29878; Fri, 8 Feb 2002 14:11:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29847 for ; Fri, 8 Feb 2002 14:11:09 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19994 for ; Fri, 8 Feb 2002 14:11:07 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g18JBK6Y017940; Fri, 8 Feb 2002 14:11:21 -0500 (EST) Message-ID: <3C6422AA.C4E43306@dynamicsoft.com> Date: Fri, 08 Feb 2002 14:10:34 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Aki Niemi CC: sip@ietf.org Subject: Re: [Sip] Authentication header issues in bis-07 References: <1012934426.9892.146.camel@essrv103nok14881.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Aki Niemi wrote: > > Hi, > > A couple of issues with the Digest authentication headers: > > 1) > Lines 3884 - 3886 in section 20.4.0.1 say that the 'uri' parameter must > be enclosed in quotation marks. However, the BNF for Authorization > doesn't reflect that. Also, the example on lines 3795 - 3803 is missing > quotes. Egads, good catch. Thanks. I fixed both. > > 2) > Section 20.1 guidelines for creating realm strings require globally > unique strings. However, section 24 examples for the authentication > headers (lines 5012, 5234, 5247, 5433) don't quite fulfill those > guidelines. OK, we'll fix. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 14:41:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21842 for ; Fri, 8 Feb 2002 14:41:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01565 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 14:41:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00024; Fri, 8 Feb 2002 14:13:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29991 for ; Fri, 8 Feb 2002 14:13:41 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20040 for ; Fri, 8 Feb 2002 14:13:38 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g18JDn6Y017943; Fri, 8 Feb 2002 14:13:50 -0500 (EST) Message-ID: <3C64233E.6144D05D@dynamicsoft.com> Date: Fri, 08 Feb 2002 14:13:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] Table 2: Proxy-Require References: <3C600E89.39B82EBD@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > Another issue on table 2, which I also raised some months ago, related > to Proxy-Require. > > According to the table, a proxy is not allowed to modify/add/remove the > Proxy-Require headers, or specific tags in the header. > > However, if there is a specific extensioin required, which only one > proxy in the path needs to support, that proxy may then remove the > option-tag for other proxies to support the same extension. Well, I don't like to encourage proxy-require usage, but since require is already acr, proxy-require ought to be the same. So, I will change unless someone objects. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 14:58:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22452 for ; Fri, 8 Feb 2002 14:58:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02260 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 14:58:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01363; Fri, 8 Feb 2002 14:38:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01334 for ; Fri, 8 Feb 2002 14:38:02 -0500 (EST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21627 for ; Fri, 8 Feb 2002 14:37:58 -0500 (EST) Received: from attrh1i.attrh.att.com ([135.71.62.10]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g18JbRW26877 for ; Fri, 8 Feb 2002 14:37:28 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029) id 3C62A10C00018150; Fri, 8 Feb 2002 14:37:02 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] RE: [Sip-implementors] draft-ietf-sip-service-examples-03.txt Date: Fri, 8 Feb 2002 14:37:02 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F90154ED9A@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] RE: [Sip-implementors] draft-ietf-sip-service-examples-03.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcGwypCosqNWcBy6EdaSygAAwCUaDwAC0hvg From: "Roy, Radhika R, ALASO" To: "Jonathan Rosenberg" , "Yadavalli, Satyamurthy" Cc: "Alan Johnston" , "Aymeric MOIZARD" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA01335 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, Jonathan and Satyamurthy: I believe that Jonathan is right. SIP provides all the tools for service creation. Jonathan's draft (draft-rosenberg-sip-3pcc-03.txt) provides an example how 3pcc services can be provided. This kind of the drafts when finalized will foster the interoperability (again, services are NOT standardized). Similar is the case with SIP services example and others. Hope that Satyamurthy may look into Janathan's draft and may pose questions differently. That is, if there are questions related to the 3pcc draft, SIP services example, and others, we may like to discuss here. Best regards, Radhika R. Roy -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, February 08, 2002 12:51 PM To: Yadavalli, Satyamurthy Cc: 'Alan Johnston'; 'Aymeric MOIZARD'; sip@ietf.org; sip-implementors@cs.columbia.edu Subject: Re: [Sip] RE: [Sip-implementors] draft-ietf-sip-service-examples-03.txt "Yadavalli, Satyamurthy" wrote: > > I keep hearing these terms 3pcc, B2BUA, and other approaches etc., and I > wonder how different vendors of SIP components (UAs, proxy servers > etc.,) > will be able to realize supplementary features (sip-service-examples) > each > independantly presuming an approach for each feature. > The same thing said differently: for a simple feature like call > forwarding....should the UA do it or should the proxy do it. If there > exists > no specification how would different vendors interoperate to achieve the > call control features across networks? The SIP spec doesn't tell an operator what services to role out, where to put them, and so on. The sip spec, and the rest of the specifications, ensure that the proper SIP tools exist to make the service work. Let us take the case of forwarding. It can be done in a proxy in the network, or in a UA. If a provider chooses not to do it, all that means is that their service doesn't offer the feature. You can choose to get a UA that does it, or not, and that would be a user's choice. If the provider does implement it, the user can make use of that service, or disable it, and then have it provided on their UA. In all cases, there is no interop problems at all. -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 daemon@optimus.ietf.org Fri Feb 8 15:06:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23003 for ; Fri, 8 Feb 2002 15:06:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03027 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 15:06:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01795; Fri, 8 Feb 2002 14:48:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01767 for ; Fri, 8 Feb 2002 14:48:11 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22155 for ; Fri, 8 Feb 2002 14:48:08 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id TAA25370 for ; Fri, 8 Feb 2002 19:47:11 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id TAA24159 for ; Fri, 8 Feb 2002 19:48:04 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <1J3WZP75>; Fri, 8 Feb 2002 12:48:03 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B371D0@n0214idc1.oss.level3.com> To: sip@ietf.org Date: Fri, 8 Feb 2002 12:48:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] bis-07 nits part 1 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Here are comments on the first half of my review. Thought I'd send some now instead of all comments at the last minute. More to come. 1. Line 333 begins: "SIP does not provide services." Line 343 goes on to state "The nature of the services provided by SIP...", looks like the latter sentence needs to be wordsmithed. 2. Max-Forwards brief description is needed after line 406. 3. Line 429, 430 and 434 reference "IP address" included in the Via's, this should be changed to domain, or just "address". 4. Lines 456-458, the Via headers need received= parameters. 5. Line 567, FSM not defined. 6. Line 644, "adress-of-record" should be "address-of-record". 7. Line 980, "this by done" should be "this be done". 8. Line 994, "the domain the right hand side" should be "the domain to the right hand side". 9. Text version text corresponding to line 1093 is missing a period after "100rel" similar to corruption corrected in other sections. 10. Do a global replace on proceedures with procedures. Multiple occurences throughout doc. 11. Line 1124, "as way to" should be "as a way to". 12. Line 1137, is timeout the ONLY thing the TU will see? What happens when an ICMP host unreachable is returned? Does that not get to the TU? Related to this, should line 1170 "or network timeouts" be "or network failures"? (Reported in bis-06 nits, response was change didn't make it into bis-07, bug opened) 13. Line 1207, reference section missing closing ")". 14. Line 1407, suggest changing "has not yet sent a response" to "has not yet sent a final response". 15. Section 10.1 of the text version has a space before a comma in three places. PDF version is OK (lines 1481-1483). Reported this for bis-06, response was this is a text conversion problem, but keep reporting when seen. 16. Line 1645 indicates a registrar SHOULD authenticate the UAC, but section 26.1 does not show this. Suggestion: if this is not included for brevity reasons, perhaps just a note in section 26.1 indicating authentication should also be done. 17. Lines 1653-1654 are indented in PDF version, but not in txt version. Reported for other sections in bis-06, response was this is a text conversion problem, but keep reporting when seen. Other instances of this problem: lines 1679-1684, 1691, 2438-2439, 2553-2554, 2581-2584, 2592, 2615-2618, 2623, 2628-2630, 2642-2644, 2749-2752, 2769-2774, 2822-2827. 18. Line 1655, "field of request" should be "field of the request". 19. Line 1662, "a Expires" should be "an Expires". 20. Line 1728, Via header not changed to Recommended FQDN. Noted this for examples in section 26 of bis-06, response is bug entered, I guess this can be added to that. Problem also seen on line 1762. Also, if these get changed to FQDNs for responses, remember to also add received= parameter. 21. Line 1780, "a two user agents" should be "two user agents". 22. Line 1861, is this open issue considered resolved? Delete line if so. 23. Line 1888, "MUST a Route header" should be "MUST include a Route header". 24. Line 1918, "recieves" should be "receives". 25. Line 1920, "for the a request" should be "for a request". 26. Sections 13.2.1 and 13.3.1.4 indicate Allow and Supported headers SHOULD be present in an Invite and 2xx, respectively, but the example in 26.2 does not contain these. If these are added, the example would no longer have the minimum set described in section 4 which references section 26.2. Suggestion: if headers are added, include a small note explaining the difference with section 4. Otherwise, include a note that the headers normally SHOULD be included. 27. Line 2035, "send" should be "sent". 28. Line 2037, "this means the a UAS" should be "this means a UAS". 29. The text version has indented text corresponding to PDF version lines 2270-2272 which is not indented. Reported same problem in bis-06, response was this is a text conversion problem, but keep reporting when seen. Same problem for lines 2296-2298. 30. The text in section 16.2 of the text version corresponding with lines 2394-2397 has the formatting corrupted, with ".IP" stuffed in three times. 31. Line 2416 has "a request." which is missing in corresponding text version section 16.3. 32. Figure 3 on page 63 of PDF version has no title identifying it. OK in txt version. 33. Lines 2438-2439, not sure if this note should be included when this becomes an RFC. 34. Line 2464, bad section reference. 35. Line 2604, "unless it known" should be "unless it is known". 36. Line 2856, "to to" should be "to". 37. Line 2889, what is the point of resetting timer C when it expires? Expiring timers normally invoke some action other than simply resetting the timer. 38. Lines 2968-2973 have both bullets and step numbers. 39. Line 3058, "U1 receives" should be "U1 sends" 40. Line 3061, "P1 its location service" should be "P1 uses its location service". John Hearty Level3 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 8 15:11:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23198 for ; Fri, 8 Feb 2002 15:11:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03122 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 15:11:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02104; Fri, 8 Feb 2002 14:53:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01987 for ; Fri, 8 Feb 2002 14:53:52 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22301 for ; Fri, 8 Feb 2002 14:53:49 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g18Js26Y017993; Fri, 8 Feb 2002 14:54:02 -0500 (EST) Message-ID: <3C642CAB.5B42CEA4@dynamicsoft.com> Date: Fri, 08 Feb 2002 14:53:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Abbie Barbir , Tom-PT Taylor , "'sip@ietf.org'" Subject: Re: [Sip] Proxies Can Modify SDP? References: <15456.36443.572081.366576@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > What is the bright line distinction between this > and a proxy (re)writing remote party id? I've > never been entirely comfortable with this general > subject either, but I think it's a bit overbroad > to say that we haven't embarked on this slippery > slope. Well, in the case of R-PID, the header was inserted by a proxy in the first place; its one of these headers thats supposed to be mucked with. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 15:22:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23610 for ; Fri, 8 Feb 2002 15:22:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03443 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 15:22:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02346; Fri, 8 Feb 2002 14:58:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02321 for ; Fri, 8 Feb 2002 14:58:48 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22487 for ; Fri, 8 Feb 2002 14:58:44 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 6F6744CE46; Fri, 8 Feb 2002 14:58:45 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA13563; Fri, 8 Feb 2002 14:58:37 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id OAA21359; Fri, 8 Feb 2002 14:59:11 -0500 (EST) Date: Fri, 8 Feb 2002 14:59:11 -0500 (EST) Message-Id: <200202081959.OAA21359@fish.research.att.com> To: jdrosen@dynamicsoft.com, rsparks@dynamicsoft.com, hgs@cs.columbia.edu Cc: sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan wrote (complete email message attached below): > I suspect the right thing might be to move such things [requirements > on future specifications, not on implementations] into > draft-ietf-sip-guidelines. Indeed, the particular bit about generic > header formats is already in there. That document would serve as the SIP > working groups measuring stick when reviewing drafts (preferably in > advance of wglc). > > Anyone object to moving these types of references there? We'll need a > volunteer to do a clean sweep of bis to find them all. > Since I didn't hear any objections, I made another clean sweep of bis-07 looking for them. Following are my recommended changes for bis-08. These change avoid any references to tsvarea-sipchange. line 777-8, on page 20 in pdf file, section 7.1: SIP extensions, documented in standards track RFCs, may define additional methods. change to: SIP extensions may define additional methods. line 889-890, on page 23 in pdf file, section 7.3.1 All new header fields MUST follow this generic format unless they have been inherited from other RFC 2822-like specifications. change to: All new header fields follow this generic format unless they have been inherited from other RFC 2822-like specifications. line 1094-97, on page 29 in pdf file, section 8.1.1.9 The option-tags listed MUST only refer to extensions defined in standards-track RFCs. delete entire paragraph line 1103-4, on page 29 in pdf file, section 8.1.1.9 As with the Supported header, the option-tags in the Require header MUST only refer to extensions defined instandards-track RFCs. delete this single-sentence paragraph line 1298, on page 34 of pdf file, section 8.2.4 To ensure that the SHOULD can be fulfilled, any specification of a new extension MUST include discussion of how to return gracefully to baseline SIP when the extension is not present. change to: To ensure that the SHOULD can be fulfilled, any specification of a new extension includes a discussion of how to return gracefully to baseline SIP when the extension is not present. line 1306, on page 34 of pdf file, section 8.2.4 As a result of this, the Require header in a response will only ever contain option tags defined in standards-track RFCs. delete the sentence line 1468, on page 38 of pdf file, section 9.2 Extensions to this specification that define new methods MUST define the behavior of a UAS upon reception of a CANCEL for those methods. change to: Extensions to this specification that define new methods define the behavior of a UAS upon reception of a CANCEL for those methods. line 2040-1, on page 53 of pdf file, section 13.2 However, those extensions MUST adhere to the protocol rules specified in [2], and MUST adhere to the additional constraints in the list above. change to: However, those extensions adhere to the protocol rules specified in [2], and adhere to the additional constraints in the list above. line 3141-2, on page 83 of pdf file, section 17.1 Protocol extensions which require longer durations for generation of a response (such as a new method that does require human interaction) SHOULD instead use two transactions - one to send the request, and another in the reverse direction to convey the results of the request. change to: Protocol extensions which require longer durations for generation of a response (such as a new method that does require human interaction) will instead use two transactions - one to send the request, and another in the reverse direction to convey the results of the request. line 5284-5, on page 144 of pdf file, section 24.33 A UAC compliant to this specification MUST only include option tags corresponding to standards-track RFCs. delete this sentence line 5328, on page 145 of pdf file, section 24.39 A UA compliant to this specification MUST only include option tags corresponding to standards-track RFCs. delete this sentence line 6056-7, on page 178 of pdf file, section 28.1 The name MAY be of any length, but SHOULD be no more than twenty characters long. The name MUST consist of alphanum (Section 27) characters only. change to: The name may be of any length, but should be no more than twenty characters long. The name consists of alphanum (Section 27) characters only. line 6059, on page 178 of pdf file, section 28.1 A SIP option MUST NOT redefine header fields or parameters defined in either RFC2543, any standards-track extensions to RFC2543, or other extensions registered through IANA. change to: A SIP option cannot redefine header fields or parameters defined in either RFC2543, any standards-track extensions to RFC2543, or other extensions registered through IANA. Bill Marshall wtm@research.att.com -----original message----- Date: Tue, 05 Feb 2002 12:25:41 -0500 From: Jonathan Rosenberg To: William Marshall Cc: rsparks@dynamicsoft.com, hgs@cs.columbia.edu, sip@ietf.org Subject: Re: [Sip] Last Call comments on 2543bis-07 William Marshall wrote: > > Henning Schulzrinne wrote: > > Robert Sparks wrote: > > > This class of requirement is obviously on future specifications, not > > > implementations. As such, you could argue that they belong in the > > > guidelines draft. I would have no problem moving the three examples > you > > > present here, but I get the feeling that this isn't a complete list. > Is > > > requirements on future extensions the _only_ class of requirements > > > giving you trouble? > > > > My suggestion is that all of them should move into or close to the > IANA > > sections, since they are needed by things that need IANA registration > in > > any event. The section can then be prefixed by a "this is for > specifying > > compliancy of protocol designers, not implementations" (obviously, not > > worded that way...) > > This suggestion works fine for me. I'd then re-word the lines where > the spec words now appear as simple statements of fact, e.g.. "All > new header fields follow this generic format..." IANA is not going to look at this, I suspect. I dont think it is their job to check that extensions follow particular BNF patterns. I suspect the right thing might be to move such things into draft-ietf-sip-guidelines. Indeed, the particular bit about generic header formats is already in there. That document would serve as the SIP working groups measuring stick when reviewing drafts (preferably in advance of wglc). Anyone object to moving these types of references there? We'll need a volunteer to do a clean sweep of bis to find them all. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 15:49:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24248 for ; Fri, 8 Feb 2002 15:49:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04619 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 15:49:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03629; Fri, 8 Feb 2002 15:24:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03588 for ; Fri, 8 Feb 2002 15:24:33 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23680 for ; Fri, 8 Feb 2002 15:24:30 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g18KC2U01838; Fri, 8 Feb 2002 14:12:03 -0600 Message-ID: <3C643112.5080003@dynamicsoft.com> Date: Fri, 08 Feb 2002 14:12:02 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: Re: [Sip] further comments on bis-06 References: <200202030534.AAA87223@fish.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > Following are additional comments to add to my original list. > > First, a few general comments. The use of MUST, MAY, SHOULD, etc, is > covered in RFC2119. However, use of "must", "may", and "should" (in > lower case) are not spec words. But they are confusing, and could > be misinterpreted as spec words. Therefore, wherever I saw one > of them, I included an editorial change below to re-word the > sentence without it. Thanks for pointing at these. > > Second, the reference structure helps a lot in understanding the > protocol, but should not be normative. In particular, normative > language regarding interaction between layers of the reference > structure is not appropriate. Wherever I saw such use of a MUST, > I included an editorial change below to re-word the sentence without > the spec word. Where the requirement could have been confusing, I made an adjustment. In general, these are concise statements of "MUST follow the steps specified in xxxx". I don't see them causing harm. > > Section 10.3 has a noticeable lack of spec words. I recommend the > following be promoted: line 1647 must to MUST; line 1667 sends to MUST > send; line 1675 returns to MUST return; line 1698 is to MUST be; line 1699 > updates or removes to MUST update or remove; line 1703 are to MUST be; > line 1704 fails to MUST fail; line 1705 are to MUST be. I made these changes and touched other places like them in this section. > > Section 12.2.1 and 12.2.2, it is not clear that UAC/UAS might be different > than the roles in the initial INVITE. This could be clarified in 12.2, > or make the following changes: > line 1892: change to "Behavior of UA initiating a request within a dialog" > line 1921,1928,1930, and 1943: change UAC to UA > line 1946: change to "Behavior of UA receiving a request within a dialog" > line 1948,1951,1952,1956,1957(4timess),1959,1964: change UAS to UA Reiterated in 12.2 that UAC/UAS are roles a UA plays and that those roles may change from transaction to transaction in a dialog. > > > Minor technical items: > > Content-Length is never mentioned as a header that a proxy MUST add; > however, if the UA sends a request/response over UDP (and therefore > without a Content-Length header) but the proxy uses TCP, then the > proxy must add it. Per separate thread - the ability to add when transiting between UDP and a stream-oriented protocol will be reflected in the appropriate places. > > Section 8.1.1.6, line 1040: My recollection of the list discussion > was that the value 70 was RECOMMENDED, not MUST. But perhaps I > missed something. This was fixed in time for -07. > > Section 8.1.4.5: While processing the list of Contact headers, if one > returns another 3xx response with more Contact headers, ... > Perhaps some words should be added about adding to the list, > and not replacing the previous list. Good idea. > > Section 10.2.4, line 1606: "unless redirected." seems to be the only > mention anywhere about a 3xx response to a REGISTER. Is this allowed? > Perhaps it should reference 8.1.4.5 in line 1606. 3xx to a unicast REGISTER is allowed. The text will be modified to make this more clear. > > Section 10.2.7, line 1630: "SHOULD wait some reasonable time interval" > is untestable. Suggest changing to "MUST NOT retry immediately.." I made a similar adjustment (to SHOULD NOT, not MUST NOT). > > Section 11.2, line 1748: "The response code chosen is the same that > would have been chosen had the request been an INVITE." The "is" should > be a spec word. Should it be a SHOULD or a MUST? Changed to MUST based on the text around it. > > Section 12.1.1, line 1831: "and have global scope". This seems > particularly NAT-unfriendly, even for local calls with both parties > behind the same NAT. Also it is given as a requirement for the UAS, but > not the UAC. I recommend it be dropped here. The requirements for the UAC are reflected where the UAC forms requests for messages in a dialog, but not for initial requests. That will be corrected. The global scope here means valid outside the scope of the dialog, not globally resolvable in DNS. The question being answered is whether a URI provided in a Contact header in a dialog initiating or refreshing message can be used outside that dialog. The text will be modified to be more precise. > > Section 15, line 2285-6: "A UA joining a multicast session MAY terminate > the SIP dialog immediately after the INVITE transaction used to join > the session has completed." I'd hate to recommend such an action, since > it may have unintended consequences to the QoS of the media stream in > some cases. MAY is not a recommendation. Having a MAY allows a UA to drop the dialog state if it no longer needs it. However, your point that terminating the dialog may have side-effects in the network is well taken. > > Section 15, lines 2291-2295, spec language is very confusing. "As a > general rule...MUST" later "SHOULD". I think these are clear MUSTs. We'll straighten out the text. > > Section 16.7. Timer C fires, and the proxy resets it with an infinite > value. Is that really OK? We already allow the proxy to have an arbitrary > large initial setting of Timer C. Perhaps 16.7 should say the proxy SHOULD > generate a CANCEL. If a proxy wants to extend the time the transaction can pend, why not let it. If it decides to quit checking in on the transaction and use an infinite value, that should be its prerogative (the transaction will eventually be torn down by the actions of the endpoints). This allows a proxy to decide to extent individual transactions as they progress. > > Section 23.1.6, line 4660: shouldn't there be a "user=phone" on > these SIP URLs? Also 4662, 4671, 4672, 4678, 4679, 4689, 4694. Sure - I'll add it. Unless I've commented below, the Editorial changes below have been addressed > Editorial changes: > line 702: ...ACK for the response... to ...ACK for the response to > an INVITE transaction... > line 702-3: ...ACK for a 2xx response... to ...ACK for a 2xx response > to an INVITE transaction... > line 922: add "Note the Content-Length header is always present > with UDP." > line 994: change"ahhs.aa" to "localhost" Do you feel strongly about this one? There's pushback the other way. > line 1005: is the space allowed between ">" and ";tag"? Yes > line 1059: bad section number cross reference > line 1065: change "Only a single URI MUST be present" to "A Request > MUST NOT contain multiple Contact header values." > line 1091: change to "See Sections 24.11 through 24.15." > line 1278: change SHOULD to "will typically". Spec is in line 8146. 8146 must be a typo - where were you pointing? > line 1281: change should to SHOULD. Possibly to a MUST > line 1311: change "MUST do so if support for tht extension is indicated > in the Supported header in the request" to "MUST NOT do so if that > extension is not listed in the Supported header in the request." > line 1314: can't spec new specs. Change sentence to "To ensure that this > can be fulfilled, any specification of a new extension needs to > include a discussion of how to return gracefully to baseline SIP ..." > line 1319: "NOT RECOMMENDED" is not a spec word. Change sentence to > "This behavior will generally break interoperability, and SHOULD NOT > be done." Actually, "NOT RECOMMENDED" is an alias for "SHOULD NOT" in RFC2119. We'll add "NOT RECOMMENDED" to the list in Section 3 (its the only normative descriptor defined in RFC2119 that isn't currently reflected in Section 3). > line 1398: for consistency, change GSTN to PSTN. only occurence. > line 1406: needs spec word. change to "Malformed values SHOULD be > treated as equivalent to 3600." > line 1410: spec is in UAC section, change here to "... the extension will > be taged in the Proxy-Require field..." > line 1489: change first sentence to "SIP proxies offer a discovery > capability" > line 1489-90: change "... SIP must discover the current host(s) that > the destination user is reachable at." to "... a SIP proxy > discovers the current host(s) where the destination user is > reachable." > line 1517: change "may" to "can" > line 1519: change "may" to "can" twice > line 1538.5: add "A REGISTER request MUST NOT contain Record-Route or > Route header fields." (This is currently in the server section, > line 1642, but is actually a UAC requirement.) And its not quite right. Record-Route has no meaning for Register, but Route can (in the case of preloaded Routes). This text, and the other places where this is discussed will be fixed. Your point about keeping the normative text in the right sections will be reflected. > line 1458: change to a spec word. "Malformed values SHOULD be treated > as equivalent to 3600." > line 1550-1: change "...to which SIP requests for the address of record > should be forwarded." to "... to which the UAC desires requests to be > forwarded." > line 1576: needs a spec word. "...a default suggestion of one hour > (3600) SHOULD be assumed." > line 1589-90: change "but it MUST only be used when the Expires header > field is present with a value of "0"." to "but it MUST NOT be used > unless the Expires header field is present with a value of "0"." > line 1627-8: change "UACs should follow the procedures ..." to > "UACs follow the procedures ..." > line 1642: change "MUST NOT" to "will not". Spec language inserted > at 1538.5 above. > line 1644: change "A registrar must know" to "A registrar knows" > line 1647: should be a spec word. "Each REGISTER message MUST be > processed independently of any other registration or binding changes." > line 1768: change UA to UAS > line 1792: no space in "method-independent" > line 1872: change UA to UAS Changed to "remote UA" instead > line 1961: change must to MUST Changed to "need to". MUST take into consideration is untestable. > line 2008: change UA to UAC > line 2015: change UA to UAC > line 2016: change UA to UAS I disagree with those two - the roles the two UAs are playing are pretty clear, and the dialog is established between the UAs. Saying a dialog is established between a UAC and a UAS will lead some to confusion when it comes time to send a request in the opposite direction. > line 2020: change Caller to UAC > line 2025: change UA to UAC Again, I think UA is right - it will be playing the UAS role on the mentioned subsequent requests. > line 2026: change UA to UAC > line 2031: change UA to UAC The above two similarly discuss things about the UA when it can either be acting as a UAC or a UAS. > line 2034: change UA to UAC > line 2064: drop space before closing right paren > line 2074: change "Section 24" to "Section 24 and 23.1.4" But nowhere > can I find rules for comparing CSeq header values. Section 24 points back to 23.1.4 where it needs to. However, I think this line should be modified to reuse the request/response matching text in the transaction section. I don't see a place that says "two CSeq header fields are equal if" either. That'll get fixed. > line 2098-9: change "2xx response using the procedures of Section 12.1.2. > Otherwise, a new dialog in the "confirmed" state is constructed in > the same fashion." to "2xx response using the procedures of > Section 12.2.1.2. Otherwise, a new dialog in the "confirmed" state > MUST BE constructued using the procedures of 12.1.2." > line 2103,2109: I don't think the spec should specify which element in the > reference architecture MUST generate a particular request. Suggest > changing "UAC core" to "UAC". The point here is that it is the TU (synonym for core - see TU in the definitions) is responsible for the ACK. The transaction layer is not going to handle it. I don't understand your objection - can you clarify? > line 2120: change caller to UAC > line 2121: change caller to UAC > line 2122: change Callee to UAS > line 2148: change to "If the INVITE does not contain a session > description, the UAS is being asked to participate in a session and > the UAC has asked that the UAS provide the offer of the session." > line 2150: change callee to UAS > line 2152: change to "If the UAS is not able to answer the invitation > immeidately, it can choose to indicate some kind of progress..." > line 2158: change "will require" to "desires" > line 2186: add space after period before "Note" > line 2208: change "NOT RECOMMENDED" to "SHOULD NOT be done," > line 2227: drop "Note that, as opposed to initial INVITEs (see > Section 13)." and change "re-INIVTEs" to "Re-INVITEs" > line 2230: change "Note that a UAC" to "A UAC" > line 2312: change "uses BYE request" to "uses a BYE request" > line 2328: spurious space at beginning of line > line 2335: change "and MUST pass that to the server transaction for > transmission" to "and passes that to the server transaction..." > i.e. remove the spec language for inter-module control flows. > line 2347: change "proxy must first decide" to "proxy first decides" > line 2348: change "may" to "could" > line 2404-5: spec is in line 2403. change "SHOULD NOT" here to "would > not", twice. > line 2407: change "may" to "can" > line 2421: change "field value with A sent-by" to ".. a sent-by" > line 2431: change "may" to "can" > line 2433: change "telling the proxy it should not process the request" > to "telling the proxy not to process the request" > line 2442: change "the proxy must decide" to "the proxy decides" > line 2477: add a closing right paren > line 2499: change "may" to "can" > line 2529: I think this "must" should be a spec word, "MUST" I don't think a lowercase must introduces a possibility for confusion here. > line 2545: change "Only those fields detailed in the processsing > described below may be removed." to "Fields not detailed in the > process described below MUST NOT be removed." > line 2583: should be a spec word, change must to MUST > line 2586: should be a spec word, change must to MUST > line 2699.5: add point 2, Record Route > line 2700: change to point 3 > line 2814: change "may" to "could" > line 2817: change "The client must receive all of those challenges and > supply credentials..." to "The client receives all of those > challenges and supplies credentials..." used "needs to" > line 2833-4: change "one of the operations it must perform is" to "one > of the operations is performs is" > line 2850: change "the proxy may perform any feature..." to "the proxy > performs any feature..." > line 2852: ref to "Section 3" should probably be to "Step 3" > line 2854: "The proxy MUST pass the response to the server transaction > associated with the response context" to "The proxy passes the > response..." i.e. remove the spec word for internal control within > the reference design > line 2857: "..the element MUST forward the response statelessly by > sending it to the server transport." Again, we should not spec > control within the reference design. "...the element forwards ..." > line 2858: change "should" to "would" > line 2888: change "may" to "can" Made it MAY > line 2892: change "INVITEs" to "INVITE's" > line 2912: should be a spec word, change "must" to "MUST" > line 2913: should be a spec word, change "must" to "MUST" > line 2920: should be a spec word, change "must" to "MUST" > line 2949: should be a spec word, change "inspects" to "MUST inspect" > line 3051: another spec word related to design of future extensions. > change "SHOULD" to "would" > line 3126: add the text from lines 3143-4 immediately after the > section title: "These rules for construction of ACK only apply > to the client transaction. A UAC core which generates an ACK for > 2xx MUST instead follow the rules described in Section 13." > lines 3143-4: moved to line 3126, so drop > line 3159: capitalize, "Non-INVITE" > line 3270: capitalize, "Non-INVITE" > line 3382: change "may" to "can" > line 3400: change "MUSTcontain" to "MUST contain" > line 3401: change "MUSTinclude" to "MUST include" > line 3617: remove extra space "Digest need" > line 3624: remove space in "auth-scheme" > line 3629: remove space in "Proxy-Authorization" > line 3658: drop lc "should" requirement given elsewhere for UAC > line 3720: add "All" before 407, to not start sentence with digit. > line 3754: add closing right paren after 16.6 > line 3757: spec is in section 16.6, change "MUST be" to "is" > line 3765: also in 16.6, change "MUST be" to "is" > line 3767: also in 16.6, change "MUST be" to "is" > line 3775: drop space in "Proxy-Authenciation" > line 3859: should be a spec word, change "should" to "SHOULD" > line 4261: change "MUSTNOT" to "MUST NOT" > line 4600: bad cross reference to undefined section > line 4626: change "must" to "needs to" > line 4745: move 'a' to be in alphabetical order, above 'c' > line 4748: move 'o' to be in alphabetical order, after 'm' > line 4757: move 'c' to be in alphabetical order, before 'm' > line 4839: remove space from "case-sensitive" > line 6774: rfc 1806 superceeded by 2183. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Fri Feb 8 16:17:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25182 for ; Fri, 8 Feb 2002 16:17:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA06005 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 16:17:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04885; Fri, 8 Feb 2002 15:59:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04852 for ; Fri, 8 Feb 2002 15:59:05 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24539 for ; Fri, 8 Feb 2002 15:59:01 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 407C21E054; Fri, 8 Feb 2002 15:59:04 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA15664; Fri, 8 Feb 2002 15:59:01 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id QAA30031; Fri, 8 Feb 2002 16:01:22 -0500 (EST) Date: Fri, 8 Feb 2002 16:01:22 -0500 (EST) Message-Id: <200202082101.QAA30031@fish.research.att.com> To: rsparks@dynamicsoft.com Cc: sip@ietf.org Subject: Re: [Sip] further comments on bis-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Robert, I'm happy with your resolution of all those comments. For the few cases where you had a question or comment attached --- > > > line 994: change"ahhs.aa" to "localhost" > > Do you feel strongly about this one? There's pushback the other way. > We ran into this in an early version of the privacy draft. The original recommendation there was to use a junk hostname, like the use of "ahhs.aa" above. There was pushback at that time that the value had to be resolvable by DNS, so was changed in the later revisions of the privacy draft to "localhost". No strong opinion either way here. If there are no other comments requesting it be changed, leave it as "ahhs.aa" > > > line 1278: change SHOULD to "will typically". Spec is in line 8146. > > 8146 must be a typo - where were you pointing? > Sorry about that. The spec for this behavior is in section 8.1.4.6 > > > line 2103,2109: I don't think the spec should specify which element in the > > reference architecture MUST generate a particular request. Suggest > > changing "UAC core" to "UAC". > > The point here is that it is the TU (synonym for core - see TU in the > definitions) is responsible for the ACK. The transaction layer > is not going to handle it. > > I don't understand your objection - can you clarify? > Your resolution to the earlier comment, considering them concise statements of "MUST follow the steps specified in UAC core" addresses this. Bill Marshall wtm@research.att.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 daemon@optimus.ietf.org Fri Feb 8 16:25:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25421 for ; Fri, 8 Feb 2002 16:25:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA06250 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 16:25:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05616; Fri, 8 Feb 2002 16:05:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05507 for ; Fri, 8 Feb 2002 16:05:05 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24830 for ; Fri, 8 Feb 2002 16:05:01 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g18L4x6Y018082; Fri, 8 Feb 2002 16:04:59 -0500 (EST) Message-ID: <3C643D4B.6AF6A2AD@dynamicsoft.com> Date: Fri, 08 Feb 2002 16:04:11 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] Thoughts on 1-of-N with forking References: <3C5F99E2.AFF1D7F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > I have some thoughts about the 1-of-N codec mechanism, and how it will > work in a forking scenario. > > Assume that we send an INVITE. Then we receive multiple 18x responses, > from different servers, and we are not able to choose a common "final > codec" for all of them. The problem is that we don't know which of the > early dialogs will finally return 200, so we won't know which codec will > actually be used. > > Now, if the node does support multiple codecs at the same time this is > no problem, but to my understanding the idea of the 1-of-N mechanism was > to be able to choose a single specific codec for nodes which don't. If I only support one codec at a time, but I want to have a number of recipients each be able to select amongst a set of codecs, each of which wants to send me early media AND I don't want clipping of media, then this is a provably unsolvable set of constraints for any protocol. One needs to relax one of these constraints. Whichever one you choose to relax, sip and o/a have a means to convey it. These include: 1. Send the initial offer with all codecs, all inactive. Each 18x contains an answer. One or possibly more 2xx will be returned. Select a codec common to both 2xx, and update it in each dialog with a new offer in a re-invite. This means you will lose all early media, but only ever have one codec in use. 2. Send the initial offer with all codecs, all inactive. Each 18x contains an answer. The UAC picks the first one, sends it an updated offer in PRACK, reactivating and using one codec. For the other ones, it does not reactivate. If a 2xx comes on a different dialog, that one is activated with whatever codec is desired. This approach allows one branch to provide early media. > > My question is: do we need to say something about this in the spec, or > shall it be regarded as a pure implementation issue? I would rather not say anything. The idea is that O/A provides a fairly general way to do stuff, and it seems we've been able to do quite a bit with it, including various handlings of the cases above. There is no need to standardize any of it. Any of the choices above could be made and there would still be interoperability. THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 16:34:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25637 for ; Fri, 8 Feb 2002 16:34:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA06969 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 16:34:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05964; Fri, 8 Feb 2002 16:16:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05933 for ; Fri, 8 Feb 2002 16:16:00 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25163 for ; Fri, 8 Feb 2002 16:15:56 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g18LGB6Y018092; Fri, 8 Feb 2002 16:16:12 -0500 (EST) Message-ID: <3C643FEC.410F2FD9@dynamicsoft.com> Date: Fri, 08 Feb 2002 16:15:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: rsparks@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] further comments on bis-06 References: <200202082101.QAA30031@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > > Robert, > > I'm happy with your resolution of all those comments. For the > few cases where you had a question or comment attached --- > > > > > > line 994: change"ahhs.aa" to "localhost" > > > > Do you feel strongly about this one? There's pushback the other way. > > > We ran into this in an early version of the privacy draft. The > original recommendation there was to use a junk hostname, like > the use of "ahhs.aa" above. There was pushback at that time > that the value had to be resolvable by DNS, so was changed in > the later revisions of the privacy draft to "localhost". I think that was because there were times when DNS resolution was actually applied to From - when the INVITE had no Contact. Not that localhost would have helped, of course. However, since Contact is now mandatory, and widely used I think in real implementations, we are at the point where To and From are logical identifiers only, and represent an identity asserted by the ednpoints. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 17:19:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26443 for ; Fri, 8 Feb 2002 17:19:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA09051 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 17:19:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08160; Fri, 8 Feb 2002 17:00:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08112 for ; Fri, 8 Feb 2002 17:00:27 -0500 (EST) Received: from mail2.intervoice-brite.com (mail2.intervoice-brite.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26161 for ; Fri, 8 Feb 2002 17:00:22 -0500 (EST) Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id QAA03259 for ; Fri, 08 Feb 2002 16:04:18 -0600 Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Fri, 8 Feb 2002 15:43:57 -0600 Received: from bculpepperpc ([151.214.151.115]) by 172.16.16.64; Fri, 08 Feb 2002 15:59:21 -0600 From: "Bert Culpepper" To: Cc: "'Adam Roach'" Date: Fri, 8 Feb 2002 16:59:14 -0500 Message-ID: <005a01c1b0eb$d99ddfd0$7397d697@bculpepperpc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <02eb01c1b014$7c5ba5a0$1df30a0a@dfw.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Subject: [Sip] nits - draft-ietf-sip-events-02 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Some editorial issues... definition of State Agent in section 3 - near the end of the first sentence is "...it may need gather such...", should be "...it may need to gather such...". throughout - there are several places where sentence punctuation appears inside double-quoted information. This should not be so IMHO. Almost all occurrences are with parameter values defined in the SIP spec., whose definition doesn't contain the punctuation. throughout - there are several places where an extra space appears between a reference and the period at the end of the sentence. Where the reference is to a section in the document the trailing period of the section number appears. This seems odd to me. Section 4.2.1 Header - only first word is capitalized. Also, the first sentence of the 3rd paragraph doesn't read well IMHO. Suggest changing "...package name corresponds defines behavior..." to "...package name corresponds to, defines behavior..." Section 5.4.7 last paragraph - This is confusing to me, the words "optionally" and "required" are present. Otherwise, much improved IMHO from previous versions. Regards, Bert _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 8 18:57:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27682 for ; Fri, 8 Feb 2002 18:57:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA12783 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 18:57:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12213; Fri, 8 Feb 2002 18:33:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12182 for ; Fri, 8 Feb 2002 18:33:05 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27446 for ; Fri, 8 Feb 2002 18:33:02 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g18NUb4q009867; Fri, 8 Feb 2002 18:30:37 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Feb 2002 18:32:34 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630020@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Bert Culpepper'" Cc: "'sip@ietf.org'" Date: Fri, 8 Feb 2002 18:32:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: nits - draft-ietf-sip-events-02 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for your comments, Bert. I'll be incorporating them into the next version. >throughout - there are several places where sentence punctuation appears >inside double-quoted information. This should not be so IMHO. Almost all >occurrences are with parameter values defined in the SIP spec., whose >definition doesn't contain the punctuation. Yeah, that's an oddity of American English. British English reverses this rule, if I recall correctly. I agree that that the British usage makes more sense overall, but I don't think mixing styles is acceptable. I'll cite NASA's technical writing guidelines on the topic: 3.14.3. Use With Other Marks Quotation marks may be used with all other marks of punctuation. Closing quotation marks always follow commas and periods, regardless of the context. (from http://stipo.larc.nasa.gov/sp7084/sp7084ch3.html) /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 daemon@optimus.ietf.org Fri Feb 8 21:49:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00725 for ; Fri, 8 Feb 2002 21:49:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA19190 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 21:49:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18160; Fri, 8 Feb 2002 21:29:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18136 for ; Fri, 8 Feb 2002 21:29:04 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29569 for ; Fri, 8 Feb 2002 21:29:01 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g192TE6Y018426 for ; Fri, 8 Feb 2002 21:29:14 -0500 (EST) Message-ID: <3C64894C.4B4DCA96@dynamicsoft.com> Date: Fri, 08 Feb 2002 21:28:28 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] note: change in URI comparison rules coming Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, There is a change in the URI comparison rules that is coming. It has already been discussed in draft-ietf-sip-srv, but I suspect that with the volume of material flying around these days, it has been missed. Previously, the following two URIs were considered equivalent: sip:user@domain sip:user@domain:5060 The reasoning was that we figured that the default port ought to equal an explicit port equal to the default. The problem is in the DNS resolution of the URI. There is wide agreement that, when the port is present, you should use that port. This pretty much rules out an SRV lookup, since SRV would provide an alternate port, and there is no way you can use just the host and ignore the port. So, you need to do an A record lookup. Now, presumably, two URI that are equivalent ought to be looked up in the same way. So, we cannot look up the two URIs above differently if they are equal. If we use SRV for both, we end up ignoring the explicit port. THis results in serious surprise; a URI pointing to port 5060 explicitly might end up going to a different port, depending on the URI lookup. Very likely NOT what was intended. As a result of these problems, pointed out to us by DNS experts within IETF, draft-ietf-sip-srv is simple on this one. If there is a port, you use that port, and do A record lookup on the host value. No exceptions. This means that the two URI above are NOT equal any longer. This will be reflected in the URI comparison rules in bis-08. Will this introduce interop problems? I tend to doubt it. Right now, URI equality is needed in (1) dialog identification, (2) matching address-of-records into location service, (3) checking whether a contact has been updated in a registration. In the case of (1), its the From and To fields, which almost never have ports, and anyway, you're not likely to see someone put in a port and then someone strip it in a request in the reverse direction. Regarding (2), AOR shouldn't really have ports, (3) will only be an issue if the same UA decides to send one registration for a contact without a port, and update it with a port. I consider that unlikely too. So, I dont think there are any serious repercussions here. However, if you think this is a problem for you, please speak up. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 22:06:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01015 for ; Fri, 8 Feb 2002 22:06:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA20193 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 22:06:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19044; Fri, 8 Feb 2002 21:45:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19013 for ; Fri, 8 Feb 2002 21:44:57 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00658 for ; Fri, 8 Feb 2002 21:44:54 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA20783; Fri, 8 Feb 2002 21:44:56 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g192itJ2010347 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 8 Feb 2002 21:44:55 -0500 (EST) Message-ID: <3C648D25.41CAE73A@cs.columbia.edu> Date: Fri, 08 Feb 2002 21:44:53 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: rsparks@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] further comments on bis-06 References: <200202082101.QAA30031@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > > line 994: change"ahhs.aa" to "localhost" > > > > Do you feel strongly about this one? There's pushback the other way. > > > We ran into this in an early version of the privacy draft. The > original recommendation there was to use a junk hostname, like > the use of "ahhs.aa" above. There was pushback at that time > that the value had to be resolvable by DNS, so was changed in > the later revisions of the privacy draft to "localhost". > > No strong opinion either way here. If there are no > other comments requesting it be changed, leave it as "ahhs.aa" example.com comes to mind. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 8 22:34:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02207 for ; Fri, 8 Feb 2002 22:34:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA21291 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 22:34:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20356; Fri, 8 Feb 2002 22:14:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20325 for ; Fri, 8 Feb 2002 22:14:30 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01094 for ; Fri, 8 Feb 2002 22:14:27 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g193Ej6Y018522 for ; Fri, 8 Feb 2002 22:14:45 -0500 (EST) Message-ID: <3C6493F7.3C902424@dynamicsoft.com> Date: Fri, 08 Feb 2002 22:13:59 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Anonymization of To & revisiting tags alone for dialog ID Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The spec has generally assumed that the r-uri equals the To field for new requests. The exceptions are register, and pre-loaded routes, both of which are mentioned in bis-07. However, I think there might be some implications for privacy if you always make the To equal to the request URI. Lets say I have a group dialing application, and I have a group called "idiots@mydomain.com", which expands to a set of folks I unfortunately need to have a conference call with. Now, it is arguable that I don't want to put that in the To field. Putting in the r-uri is fine, it will be expanded by the group dialing (in this case, group conferencing) app, and thus never seen by these people I need to call. More generally, the To field represents the identity of the target as you wish them to know. I see no reason not to do things like: INVITE sip:speed-dial-1@mydomain.com To: Unknown or: INVITE sip:idiots@conferences.com To: My Best Friends! I think a sentence or two about this in 8.1.1.1 and in the security sections would be a fine idea. The strength of To = R-URI would remain SHOULD there, but some text on these issues would help motivate when a UA would have good reason to do something else. Basically, To and From URI are really in the cateory of "informational" data; only the tags should have meaning to SIP machinery. Now, that leads to another issue. We've now had a couple of cases come up where we needed a proxy to modify the To/From URL (Juha's privacy example). 3gpp also has such a need, also because of privacy reasons. I wonder if we should think harder about the decision not to move towards tags as the sole dialog identifier (rather than the URI and tags). We had already discussed this as open issue #140, and it was rejected. This idea was rejected primarily because one could use the tags as identifiers anyway, so long as you didn't muck with the URL. Furthermore, there was a real backwards compatibility issue. I would suggest that bis move us towards the right destination, without arriving there yet. It should specify ONLY the tags as dialog identifiers (so that finally, no sip identifiers include urls), but mandate that the To and From URL be reflected in the response, noting that elements shouldn't depend on it, however. This gives us a path to removing the requirement for reflecting the To/From URLs in subsequent requests when we go to draft. It will then also codify the preferred mechanism of dialog ID using tags and Call-ID only. Comments? Silence is consensus. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 8 23:08:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02575 for ; Fri, 8 Feb 2002 23:08:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA22485 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 23:08:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21461; Fri, 8 Feb 2002 22:42:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21430 for ; Fri, 8 Feb 2002 22:42:44 -0500 (EST) Received: from web11605.mail.yahoo.com (web11605.mail.yahoo.com [216.136.172.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02380 for ; Fri, 8 Feb 2002 22:42:40 -0500 (EST) Message-ID: <20020209034242.56630.qmail@web11605.mail.yahoo.com> Received: from [216.51.102.166] by web11605.mail.yahoo.com via HTTP; Fri, 08 Feb 2002 19:42:42 PST Date: Fri, 8 Feb 2002 19:42:42 -0800 (PST) From: Sean Olson Subject: Re: [Sip] note: change in URI comparison rules coming To: Jonathan Rosenberg , sip@ietf.org In-Reply-To: <3C64894C.4B4DCA96@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Please note that if your proxy implemenation is inserting the default port (5060) into either the To:/From:/Contact: (allowed, but questionable), that it will cause all manner of problems. I always hated the fact that the To:/From: were not immutable, but now it may cause some very serious problems. /sean --- Jonathan Rosenberg wrote: > Folks, > > There is a change in the URI comparison rules that > is coming. It has > already been discussed in draft-ietf-sip-srv, but I > suspect that with > the volume of material flying around these days, it > has been missed. > > Previously, the following two URIs were considered > equivalent: > > sip:user@domain > sip:user@domain:5060 > > The reasoning was that we figured that the default > port ought to equal > an explicit port equal to the default. > > The problem is in the DNS resolution of the URI. > There is wide agreement > that, when the port is present, you should use that > port. This pretty > much rules out an SRV lookup, since SRV would > provide an alternate port, > and there is no way you can use just the host and > ignore the port. So, > you need to do an A record lookup. Now, presumably, > two URI that are > equivalent ought to be looked up in the same way. > So, we cannot look up > the two URIs above differently if they are equal. If > we use SRV for > both, we end up ignoring the explicit port. THis > results in serious > surprise; a URI pointing to port 5060 explicitly > might end up going to a > different port, depending on the URI lookup. Very > likely NOT what was > intended. > > As a result of these problems, pointed out to us by > DNS experts within > IETF, draft-ietf-sip-srv is simple on this one. If > there is a port, you > use that port, and do A record lookup on the host > value. No exceptions. > This means that the two URI above are NOT equal any > longer. > > This will be reflected in the URI comparison rules > in bis-08. > > Will this introduce interop problems? I tend to > doubt it. Right now, URI > equality is needed in (1) dialog identification, (2) > matching > address-of-records into location service, (3) > checking whether a contact > has been updated in a registration. In the case of > (1), its the From and > To fields, which almost never have ports, and > anyway, you're not likely > to see someone put in a port and then someone strip > it in a request in > the reverse direction. Regarding (2), AOR shouldn't > really have ports, > (3) will only be an issue if the same UA decides to > send one > registration for a contact without a port, and > update it with a port. I > consider that unlikely too. So, I dont think there > are any serious > repercussions here. However, if you think this is a > problem for you, > please speak up. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle > Rock Avenue > Chief Scientist First Floor > dynamicsoft East > Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) > 952-5050 > http://www.jdrosen.net PH: (973) > 952-5000 > http://www.dynamicsoft.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 ===== Sean Olson __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.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 daemon@optimus.ietf.org Fri Feb 8 23:51:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03444 for ; Fri, 8 Feb 2002 23:51:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA24190 for sip-archive@odin.ietf.org; Fri, 8 Feb 2002 23:52:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23790; Fri, 8 Feb 2002 23:37:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23753 for ; Fri, 8 Feb 2002 23:37:18 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03245 for ; Fri, 8 Feb 2002 23:37:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g194bU6Y018647; Fri, 8 Feb 2002 23:37:30 -0500 (EST) Message-ID: <3C64A75C.1B8477F0@dynamicsoft.com> Date: Fri, 08 Feb 2002 23:36:44 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: sip@ietf.org Subject: Re: [Sip] note: change in URI comparison rules coming References: <20020209034242.56630.qmail@web11605.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sean Olson wrote: > > Please note that if your proxy implemenation is > inserting the default port (5060) into either > the To:/From:/Contact: (allowed, but questionable), > that it will cause all manner of problems. I always > hated the fact that the To:/From: were not immutable, > but now it may cause some very serious problems. Well, then you'll like the other post I made this evening.... Basically, to propose that we revisit the decision not to use tags alone as dialog ID, so that we can make the URI mutable when we go to draft. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sat Feb 9 11:34:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17113 for ; Sat, 9 Feb 2002 11:34:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23352 for sip-archive@odin.ietf.org; Sat, 9 Feb 2002 11:34:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22563; Sat, 9 Feb 2002 11:08:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22531 for ; Sat, 9 Feb 2002 11:07:57 -0500 (EST) Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16925 for ; Sat, 9 Feb 2002 11:07:53 -0500 (EST) Message-ID: <20020209160756.45958.qmail@web11604.mail.yahoo.com> Received: from [12.237.5.37] by web11604.mail.yahoo.com via HTTP; Sat, 09 Feb 2002 08:07:56 PST Date: Sat, 9 Feb 2002 08:07:56 -0800 (PST) From: Sean Olson Subject: Re: [Sip] further comments on bis-06 To: William Marshall , rsparks@dynamicsoft.com Cc: sip@ietf.org In-Reply-To: <200202082101.QAA30031@fish.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --- William Marshall wrote: > Robert, > > I'm happy with your resolution of all those > comments. For the > few cases where you had a question or comment > attached --- > > > > > > line 994: change"ahhs.aa" to "localhost" > > > > Do you feel strongly about this one? There's > pushback the other way. > > > We ran into this in an early version of the privacy > draft. The > original recommendation there was to use a junk > hostname, like > the use of "ahhs.aa" above. There was pushback at > that time > that the value had to be resolvable by DNS, so was > changed in > the later revisions of the privacy draft to > "localhost". > > No strong opinion either way here. If there are no > other comments requesting it be changed, leave it as > "ahhs.aa" localhost makes things a bit cleaner as well as bit more explicit which seems like a good general goal. /sean ===== Sean Olson __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.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 daemon@optimus.ietf.org Sat Feb 9 20:51:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21487 for ; Sat, 9 Feb 2002 20:51:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA10820 for sip-archive@odin.ietf.org; Sat, 9 Feb 2002 20:51:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10621; Sat, 9 Feb 2002 20:33:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10590 for ; Sat, 9 Feb 2002 20:33:20 -0500 (EST) Received: from mailserver.sylantro.com ([65.200.90.207]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21387 for ; Sat, 9 Feb 2002 20:33:16 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Sat, 09 Feb 2002 17:28:07 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id <1F5J8JS3>; Sat, 9 Feb 2002 17:28:07 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD9CFC1D@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "'sip@ietf.org'" Date: Sat, 9 Feb 2002 17:28:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 107B132D162364-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Clarification as regards Expires Header in INVITE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Per bis07, section 24.19, the Expires header is an integer number in seconds. However section 13.3.1 of the bis (Processing of INVITE) indicates that an UAS is supposed to respond with a 487 response for the INVITE if the INVITE has "Expired". How would an UAS decide if the request has "expired" if the Expires header is not expressed more like a "Date" header in the request? Regards, Venkatesh _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 9 21:15:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21655 for ; Sat, 9 Feb 2002 21:15:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA11605 for sip-archive@odin.ietf.org; Sat, 9 Feb 2002 21:15:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10940; Sat, 9 Feb 2002 20:56:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10912 for ; Sat, 9 Feb 2002 20:56:53 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21527 for ; Sat, 9 Feb 2002 20:56:49 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA01920; Sat, 9 Feb 2002 20:56:51 -0500 (EST) Received: from bart.cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1A1uoPu011600; Sat, 9 Feb 2002 20:56:50 -0500 (EST) Received: from localhost (sankaran@localhost) by bart.cs.columbia.edu (8.12.1/8.12.1/Submit) with ESMTP id g1A1uoVc011597; Sat, 9 Feb 2002 20:56:50 -0500 (EST) Date: Sat, 9 Feb 2002 20:56:50 -0500 (EST) From: Sankaran Narayanan To: Venkatesh Venkataramanan cc: "'sip@ietf.org'" Subject: Re: [Sip] Clarification as regards Expires Header in INVITE In-Reply-To: <79FEAA5FABA7D411BF580001023D1BBD9CFC1D@mailserver.sylantro.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org i think if there is a Date header, Date + Expires < Current will give whats needed. On Sat, 9 Feb 2002, Venkatesh Venkataramanan wrote: > Hi, > > Per bis07, section 24.19, the Expires header is an integer number in > seconds. However section 13.3.1 of the bis (Processing of INVITE) indicates > that an UAS is supposed to respond with a 487 response for the INVITE if the > INVITE has "Expired". How would an UAS decide if the request has "expired" > if the Expires header is not expressed more like a "Date" header in the > request? > > Regards, > Venkatesh > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sun Feb 10 19:42:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12635 for ; Sun, 10 Feb 2002 19:42:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA00546 for sip-archive@odin.ietf.org; Sun, 10 Feb 2002 19:42:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29461; Sun, 10 Feb 2002 19:16:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29427 for ; Sun, 10 Feb 2002 19:16:33 -0500 (EST) Received: from mailserver.sylantro.com ([65.200.90.207]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12339 for ; Sun, 10 Feb 2002 19:16:31 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Sun, 10 Feb 2002 16:11:21 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id <1F5J8J0A>; Sun, 10 Feb 2002 16:11:21 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD9CFC1F@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "'sip@ietf.org'" cc: "'sankaran@cs.columbia.edu'" Date: Sun, 10 Feb 2002 16:11:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1079D3A3166779-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Question regarding Section 13.3.1 item 1.. ?? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sorry. Let me re-phrase my question ! The earlier versions of the bis allowed "Expires" header to be expressed as absolute time (basically equivalent to the "Date" header). This caused interoperability problems when UA's were out of sync as regards time (section 29.1 talks about this). To alleviate this problem, Expires now use "relative time". Now, as regards INVITE processing, per section 13.3.1 of bis07, "If the request is an INVITE that contains an Expires header field the UAS core inspects this header field. If the INVITE has ALREADY expired, a 487 response SHOULD be generated." And this part (ascertaining if an INVITE has "already" expired) is not valid anymore. The reason being: There is no way for the UAS to accurately determine if the request has expired when it receives the request, if the two UA's under consideration were out of sync as regards time. Say UA1 and UA2 are out-of-sync by 10 minutes (UA1 is ahead of UA2). Say UA2 initiates an INVITE to UA1 with the following information with Expires header set to 180: INVITE .... Date: Sat, 10 Feb 2002 10:20:00 PST Expires: 180 ... When UA2 receives this request, the INVITE has already expired per UA2's time ( as it is 10 minutes ahead of UA1). Hence it generates a 487 Response which is the problem... Regards, Venkatesh -----Original Message----- From: Sankaran Narayanan [mailto:sankaran@cs.columbia.edu] Sent: Saturday, February 09, 2002 5:57 PM To: Venkatesh Venkataramanan Cc: 'sip@ietf.org' Subject: Re: [Sip] Clarification as regards Expires Header in INVITE i think if there is a Date header, Date + Expires < Current will give whats needed. On Sat, 9 Feb 2002, Venkatesh Venkataramanan wrote: > Hi, > > Per bis07, section 24.19, the Expires header is an integer number in > seconds. However section 13.3.1 of the bis (Processing of INVITE) indicates > that an UAS is supposed to respond with a 487 response for the INVITE if the > INVITE has "Expired". How would an UAS decide if the request has "expired" > if the Expires header is not expressed more like a "Date" header in the > request? > > Regards, > Venkatesh > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Mon Feb 11 09:54:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04305 for ; Mon, 11 Feb 2002 09:54:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11633 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 09:54:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10212; Mon, 11 Feb 2002 09:29:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10181 for ; Mon, 11 Feb 2002 09:29:28 -0500 (EST) Received: from mail4.intermedia.net (mail4.intermedia.net [206.40.48.154]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03620 for ; Mon, 11 Feb 2002 09:29:26 -0500 (EST) Received: from DBX09611 (unverified [208.1.63.130]) by mail4.intermedia.net (Rockliffe SMTPRA 4.5.4) with ESMTP id for ; Mon, 11 Feb 2002 06:29:27 -0800 From: "Christopher P Rigano" To: Date: Mon, 11 Feb 2002 09:50:16 -0600 Message-ID: <002a01c1b313$cd22e050$7301a8c0@DBX09611> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C1B2E1.82887050" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [Sip] Registration/Redirection Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C1B2E1.82887050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings Does anyone know of a freeware redirection and registration server? Best regards, Chris ------=_NextPart_000_002B_01C1B2E1.82887050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings

 

Does anyone know of a freeware redirection and = registration server?

 

Best regards,

 

Chris

------=_NextPart_000_002B_01C1B2E1.82887050-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 11 09:56:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04366 for ; Mon, 11 Feb 2002 09:56:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11735 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 09:56:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10142; Mon, 11 Feb 2002 09:28:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10111 for ; Mon, 11 Feb 2002 09:28:09 -0500 (EST) Received: from mail4.intermedia.net (mail4.intermedia.net [206.40.48.154]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03573 for ; Mon, 11 Feb 2002 09:28:08 -0500 (EST) Received: from DBX09611 (unverified [208.1.63.130]) by mail4.intermedia.net (Rockliffe SMTPRA 4.5.4) with ESMTP id for ; Mon, 11 Feb 2002 06:28:09 -0800 From: "Christopher P Rigano" To: Date: Mon, 11 Feb 2002 09:48:57 -0600 Message-ID: <002501c1b313$9e45a740$7301a8c0@DBX09611> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C1B2E1.53AB3740" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [Sip] verification organization/test bed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C1B2E1.53AB3740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings Does anyone know of an independent QoS verification, VoIP test bed? Best regards, Chris ------=_NextPart_000_0026_01C1B2E1.53AB3740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings

 

Does anyone know of an independent QoS verification, VoIP test = bed?

 

Best regards,

 

Chris

------=_NextPart_000_0026_01C1B2E1.53AB3740-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 11 11:39:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08898 for ; Mon, 11 Feb 2002 11:39:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18640 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 11:39:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17021; Mon, 11 Feb 2002 11:17:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16990 for ; Mon, 11 Feb 2002 11:17:39 -0500 (EST) Received: from mailhost2.unispherenetworks.com ([65.194.140.138]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07709 for ; Mon, 11 Feb 2002 11:17:36 -0500 (EST) Received: by email2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <1MBWC6AZ>; Mon, 11 Feb 2002 11:17:09 -0500 Message-ID: <9DCB6C9DC7C3D311B835009027DE069F049A07A4@email2.it.west.unispherenetworks.com> From: "Mahey, Sonit" To: "'hgs@cs.columbia.edu'" , "'sip@ietf.org'" Date: Mon, 11 Feb 2002 11:17:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] SIP Security: Client certificates Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Henning, In the draft "Draft-schulzrinne-sip-security-00.txt", you make an assumption: Client certificates are less likely to be available than server certificates. I argue that this is not true since SET (Secure Electronic Transaction) uses (credit) cardholder's certificates. I grant that this does not cover the entire population, but from a VoP service provider's perspective, it would not be off the mark to assume that most (~95%-98%) subscriber's - prospective and current - would have a credit card. - sonit Sonit Mahey, Architect - Voice Business Unit, Unisphere Networks, 10 Technology Park Drive, Westford, MA 01886, 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 daemon@ns.ietf.org Mon Feb 11 11:41:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08993 for ; Mon, 11 Feb 2002 11:41:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18699 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 11:41:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17502; Mon, 11 Feb 2002 11:25:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17473 for ; Mon, 11 Feb 2002 11:24:59 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08130 for ; Mon, 11 Feb 2002 11:24:55 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1BGOr43020659; Mon, 11 Feb 2002 17:24:53 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1BGOrr6000080; Mon, 11 Feb 2002 18:24:53 +0200 (EET) Message-ID: <3C67F055.CAA7CB9@lmf.ericsson.se> Date: Mon, 11 Feb 2002 18:24:53 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Mahey, Sonit" CC: "'hgs@cs.columbia.edu'" , "'sip@ietf.org'" Subject: Re: [Sip] SIP Security: Client certificates References: <9DCB6C9DC7C3D311B835009027DE069F049A07A4@email2.it.west.unispherenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Mahey, Sonit" wrote: > In the draft "Draft-schulzrinne-sip-security-00.txt", you make an > assumption: Client certificates are less likely to be available than server > certificates. > I argue that this is not true since SET (Secure Electronic Transaction) uses > (credit) cardholder's certificates. I grant that this does not cover the > entire population, but from a VoP service provider's perspective, it would > not be off the mark to assume that most (~95%-98%) subscriber's - > prospective and current - would have a credit card. I'm not sure what you are saying. I have a credit card but I do *not* use SET and as far as I know, I don't have a certificate because of the credit card. Or perhaps you are saying that SET acts as a credential creation tool, input your card number (and $10) and out comes a cert? If so, there are also a number of other potential sources of certificates that we could bootstrap ourselves into. Most ISPs apply some sort of authentication; you could use PIC to generate certs from that etc. However, I'm still not convinced that the users have usable certs and everything is linked through some global co-operating roots. In conclusion I agree with Henning on this. Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 11 11:45:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09225 for ; Mon, 11 Feb 2002 11:45:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19079 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 11:45:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17449; Mon, 11 Feb 2002 11:24:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17420 for ; Mon, 11 Feb 2002 11:24:41 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08111 for ; Mon, 11 Feb 2002 11:24:38 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1BGP0713895; Mon, 11 Feb 2002 08:25:00 -0800 (PST) To: "Mahey, Sonit" Cc: "'hgs@cs.columbia.edu'" , "'sip@ietf.org'" Subject: Re: [Sip] SIP Security: Client certificates References: <9DCB6C9DC7C3D311B835009027DE069F049A07A4@email2.it.west.unispherenetworks.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 11 Feb 2002 08:25:00 -0800 In-Reply-To: "Mahey, Sonit"'s message of "Mon, 11 Feb 2002 11:17:06 -0500" Message-ID: Lines: 20 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > In the draft "Draft-schulzrinne-sip-security-00.txt", you make an > assumption: Client certificates are less likely to be available than server > certificates. > I argue that this is not true since SET (Secure Electronic Transaction) uses > (credit) cardholder's certificates. I grant that this does not cover the > entire population, but from a VoP service provider's perspective, it would > not be off the mark to assume that most (~95%-98%) subscriber's - > prospective and current - would have a credit card. SET's deployment could be charitably described as underwhelming. The probability that any given credit card holder will have a SET certificate is somewhere between vanishing and nonexistent. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Mon Feb 11 12:09:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10726 for ; Mon, 11 Feb 2002 12:09:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21758 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 12:09:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19597; Mon, 11 Feb 2002 11:52:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19563 for ; Mon, 11 Feb 2002 11:52:55 -0500 (EST) Received: from sumo.vocaltec.co.il (vocaltec.co.il [199.203.72.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09740 for ; Mon, 11 Feb 2002 11:52:51 -0500 (EST) From: Dror@vocaltec.com Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135]) by sumo.vocaltec.co.il (8.10.2+Sun/8.10.2) with ESMTP id g1BGot521199 for ; Mon, 11 Feb 2002 18:50:55 +0200 (IST) To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: Date: Mon, 11 Feb 2002 18:49:34 +0200 X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.8 |June 18, 2001) at 02/11/2002 06:49:35 PM, Serialize complete at 02/11/2002 06:49:35 PM Content-Type: text/plain; charset="us-ascii" Subject: [Sip] One more small ABNF error in bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The text version of bis-07 defines the following BNF: url-parameter = transport-param / user-param / method-param |ttl-param / maddr-param / lr-param / other-param ^ Note the use of "|" instead of "/", just before the "ttl-param". Strangely, the PDF version uses "/", as it should. /dror _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 11 12:45:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12399 for ; Mon, 11 Feb 2002 12:45:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23458 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 12:45:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22019; Mon, 11 Feb 2002 12:16:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21988 for ; Mon, 11 Feb 2002 12:16:28 -0500 (EST) Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11172 for ; Mon, 11 Feb 2002 12:16:25 -0500 (EST) Received: from cvis05.marconicomms.com (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 11 Feb 2002 17:15:53 +0000 Received: from cvdgwy01.uk.marconicomms.com by cvis05.marconicomms.com with ESMTP (8.10.2+Sun/cvms-34) id g1BHFsK10500; Mon, 11 Feb 2002 17:15:54 GMT To: sip@ietf.org From: "Keith Robinson" Date: Mon, 11 Feb 2002 17:15:22 +0000 Message-ID: X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at 11/02/2002 17:15:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, This question may already have been dealt with, so my apologies if it has. Anyway, in 16.4 (Making A Routing Decision) the text states that when a bis07 proxy detects that the received R-URI is one that it would have written into the Record-Route header then it must replace it with that last entry of the Route header and continue as if this was the received R-URI. It also says that this will only happen if the previous element was a strict router. If all the preceding elements were strict routers then the last entry in the Route header would not be the target URI as none of the previous element would have appended it; indeed there may not be a last entry as the list may be empty. How is this situation handled, or am I missing something ? Thanks, K. Robinson ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 11 14:25:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14688 for ; Mon, 11 Feb 2002 14:25:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27849 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 14:25:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27022; Mon, 11 Feb 2002 14:03:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26993 for ; Mon, 11 Feb 2002 14:03:10 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14167 for ; Mon, 11 Feb 2002 14:03:08 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A567309001A2; Mon, 11 Feb 2002 14:03:03 -0500 Message-ID: <005a01c1b32e$a3089240$2300000a@acmepacket.com> From: "Bob Penfield" To: , "Keith Robinson" References: Subject: Re: [Sip] (no subject) Date: Mon, 11 Feb 2002 14:02:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Keith Robinson" > Hello, > > This question may already have been dealt with, so my apologies if it > has. > > Anyway, in 16.4 (Making A Routing Decision) the text states that when a > bis07 proxy detects that the received R-URI is one that it would have > written into the Record-Route header then it must replace it with that last > entry of the Route header and continue as if this was the received R-URI. > It also says that this will only happen if the previous element was a > strict router. If all the preceding elements were strict routers then the > last entry in the Route header would not be the target URI as none of the > previous element would have appended it; indeed there may not be a last > entry as the list may be empty. How is this situation handled, or am I > missing something ? > In this case, the UAC will construct the route headers the same way whether it understands loose routing or not. A pre-bis-06 UA would put the route set plus the contact address (the real/target Request-URI) in the route header. A bis-06/07 compliant UA will add the contact address to the route headers when it recognizes that the first route entry is a strict-router. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 11 15:00:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15573 for ; Mon, 11 Feb 2002 15:00:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA29705 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 15:00:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27830; Mon, 11 Feb 2002 14:25:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27799 for ; Mon, 11 Feb 2002 14:25:33 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14665 for ; Mon, 11 Feb 2002 14:25:31 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1BJPD6Y024990; Mon, 11 Feb 2002 14:25:13 -0500 (EST) Message-ID: <3C681A6C.F06AD5C4@dynamicsoft.com> Date: Mon, 11 Feb 2002 14:24:28 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dror@vocaltec.com CC: sip@ietf.org Subject: Re: [Sip] One more small ABNF error in bis-07 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dror@vocaltec.com wrote: > > The text version of bis-07 defines the following BNF: > url-parameter = transport-param / user-param / method-param > |ttl-param / maddr-param / lr-param / > other-param > ^ > > Note the use of "|" instead of "/", just before the "ttl-param". Yes, this is already fixed. > > Strangely, the PDF version uses "/", as it should. Well, there is a story to that. Basically, I noticed this error just after I finished the builds for the -07 release. It is a simple process to rebuild the pdf, but a huge pain for the .txt. So, I fixed and rebuilt the pdf, but manually edited the txt version to fix the problem. However, since it was around 430 in the morning, I missed the first vertical bar. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 11 15:55:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16904 for ; Mon, 11 Feb 2002 15:55:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02018 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 15:55:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00685; Mon, 11 Feb 2002 15:24:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00654 for ; Mon, 11 Feb 2002 15:23:59 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16210 for ; Mon, 11 Feb 2002 15:23:58 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1BKOF6Y025459; Mon, 11 Feb 2002 15:24:15 -0500 (EST) Message-ID: <3C682841.433E3E7F@dynamicsoft.com> Date: Mon, 11 Feb 2002 15:23:29 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen CC: SIP Subject: Re: [Sip] bis-06 comments References: <3C5C85DD.2020206@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Anders, thanks for your comments. Responses inline. Anders Kristensen wrote: > > Some minor comments on bis-06. > > "Note that both the transaction corresponding to the original request > and the CANCEL transaction will 1453 > complete independently. However, a UAC canceling a request cannot rely > on receiving a 487 (Request 1454 > Terminated) response for the original request, as an RFC 2543-compliant > UAS will not generate such a 1455 > response. If there is no final response for the original request in > 64*T1 seconds (T1 is defined in Section 1456 > 17.1.1.1), the client SHOULD then consider the original transaction > cancelled and SHOULD destroy the client 1457 > transaction handling the original request. 1458" > > Not that it really matters, but shouldn't this really be 64*T1 minus > however long the transaction has been in the Calling state? No, I think its right as written. Lets say I send an INVITE, and then get a 1xx. Then, I CANCEL. The CANCEL is received a the UAS. The UAS begins to send a final response at that point, or will never do so (for older UAS). The tiemr needs to be large enough to cover the case where the UAS is sending the final response, but there are network problems. The UAS will continue to retransmit that final response for 64*T1 after receiving the cancel, and this is how long the UAC needs to wait. > > "A dialog can also be in the "early" state, which occurs when it is > created with a provisional response, and then transition to the > "confirmed" state when the final response comes. 1812" > > - or to the "terminated" state, depending on the status code. Good point. I will clarify that it goes to confirmed only for a 2xx on that dialog. For other response codes, or for a timeout after the last 2xx, it terminates. > Evidently, there's a dialog state machine hiding in there. Maybe it > should be made explicit. I think its simple enough that a textual description will suffice. I think the spec is long enough as it is ;) > > When a 1xx to an initial INVITE does contain a To tag, this 1xx and not > a subsequent final response, establishes the dialog. Text like > > "When a UAS responds to a request with a response that establishes a > dialog (such as a 2xx to INVITE), the 1824 > UAS MUST copy all Record-Route headers from the request into the > response (including the URIs, URI 1825 > parameters, and any Record-Route header parameters, whether they are > known or unknown to the UAS) 1826 > and MUST maintain the order of those headers. The UAS MUST add a Contact > > header field to the response. 1827" > > then applies to the 1xx but not necessarily to the 2xx (as I read it), > meaning that a 200 to an INVITE might legally not contain Record-Route > and Contact. This is probably unfortunate and unintended. How do you read that? The text explicitly calls out 2xx to INVITE. The text in section 12.1 is also very explicit on which responses create dialogs. > BTW, 180's in > the Examples section doesn't include R-R and Contacts. Well, there is no RR because there is no record-routing, but there ought to be a contact. I've fixed that. > > 1xx's other than 100 now MUST always be given a To tag. This puts extra > work load on dialog-stateful proxies and I don't really see what the > point of such a requirement would be. This is being discussed in another thread, and also amongst the editors. We're working it. > > "13.2.2.2 3xx responses A 3xx response may contain a Contact header > field providing new addresses 2084 > where the callee might be reachable. Depending on the status code of the > > 3xx response (see Section 25.3) 2085 > the UAC MAY choose to try those new addresses. 2086" > > Actually, "the UAC MAY choose to try those new addresses" regardless of > the actual 3xx. Sure, but this section is talking about 3xx, and I think its worth pointing it out, since it is the primary function of 3xx. Is something wrong with the text as written? > > "A 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved > Temporarily) response SHOULD contain 2168 > a Contact header field containing URIs of new addresses to be tried. > 2169" > > Should be "SHOULD contain one or more...". Actually, no. This is another subject that has been tossed around amongs the editors. When you see a header like: Contact: sip:a@example.com Contact: sip:b@example.com is that two contact headers, or one contact header with two values? It is inconsistent in the text right now, as written. We are going to be using the consistent naming that this is one header with two values, I think that is more correct. > > ""the wire". In this case, the UAC will receive a 2xx to the > INVITE.ItSHOULD then terminate the call by 2306 > following the procedures described in Section 15.1.1. 2307" > > I'd suggest making this a MUST or remove the upper-case requirement > altogether. Well, MUST is wrong, I think. Its OK if the UAC decides that "oh, I got a 2xx anyway. Alright, I'll continue with the call". However, if the intention was to hang up, the process ought to continue, and thus the SHOULD. My general preference (and not all of the editors agree on this) is to err on the side of explicit strengths rather than a simple active voice. We've gotten in trouble on this in the past many times. > > "a proxy performing load balancing may route a BYE without a Route > header field in a different way than the INVITE,since 2317 > both requests have different CSeq sequence numbers. 2318" > > That's not what section 24.2 USED to say (in bis-05): "More > specifically, once a request is delivered successfully to a par- ticular > > next hop, all subsequent requests with the same Call-ID MUST be > delivered to that next hop. 4187". Mind you, this was obviously bogus > anyway, as the route being constructed might dictate otherwise. Right. Well, that old text is now gone. I think the note is OK as written given the current state of bis. > > I'm confused about section 24.2. There doesn't seem to be any note about > > it's disappearance in the Changes. Is it supposed to be replaced by > draft-ietf-sip-srv-04.txt? Yes. There is a long, painful history with this draft and the text it is associated with. > That draft and what was 24.2 doesn't seem to > have very much in common (in the sense of shared text), in particular > the quote above isn't in the draft. Right. The problem is that the requirement mandates dialog-statefulness to handle failure cases. THus, the new text has relaxed the constraint. Now, its just within a transaction that requests need to go to the same place. A proxy can use a hash of the call-id as a random-number generator for the SRV selection procedures. This results in reuqests within the same call usually going to the same server, but not if there has been a failure between transactions. It also doesn't require call statefulness. > > "If the domain of the Request-URI indicates a domain this element is not > > responsible for, it SHOULD set 2109 > the next hop URI to the Request-URI, and leave the IP address, port and > transport of the next hop empty. 2110" > > Hmm, isn't it really up to the proxy itself to decide where to route > such an incoming request? The suggested behaviour is a good default but > it's not wrong to make different decisions, right? The general idea is that if you don't own a namespace, you really can't do a location service lookup on it to change it. So, a proxy cannot change the desintation (i.e., r-uri), although it can certainly decide a different next hop to send it to (loose routing). What did you have in mind that required a proxy to modify a URI for a domain it doesn't own? > > "If this proxy wishes to request to remain on the path of future > requests in this dialog, it MUST insert a Record-Route header value > (Section refsec:record-route) into the copy before any existing Record- > 2225 > Route header values. 2226" > > - should be "If this proxy wishes to request to remain on the path of > future requests in this dialog *and* this is an initial request *and* > the request potentially establishes a dialog..."? Yeah, good point. This text might make people think that they need to record-route mid-dialog requests. I'll clarify. It now reads: If this proxy wishes to remain on the path of future requests in a dialog created by this request (assuming the request creates a dialog), it {\MUST} insert a \header{Record-Route} header field into the copy before any existing \header{Record-Route} header field, even if a \header{Route} header field is already present. > > "The Request-URI will be different each time the request passes through. > > 2250" > > Is this necessarily so? No, its not necessarily so. You can legitimately spiral even if the r-uri is unchanged. THis text is gone, however, in the changes that led to bis-07. > > "If the proxy chooses to recurse on a 3xx class response, it MUST NOT > add the response to the response 2327 > context 2328" > > What if the proxy *partially* recursed, e.g. if it tried all sip URLs > but not mailto and http URLs? In this case it makes sense to return a > 3xx with just those Contacts that haven't been tried. Maybe the best way > > to view this situation is as if such a 3xx had been received from a > "virtual" branch. This has already been fixed. Its fixed in bis-07, at least, maybe earlier versions too (I didnt check). > > "If a 6xx response is received, it is not immediately forwarded, but the > > stateful proxy SHOULD cancel 2334 > all pending transactions as described in Section 9. 2335" > > ... "and no new branches can be created in this context." Good point. I added the text. > > Seems to me the majority of SHOULD/SHOULD NOT items in 17.1.1.2 should > be MUST/MUST NOT. Many of them; those related to retransmissions, primarily. I've changed them. Thanks for your comments, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 11 16:11:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17223 for ; Mon, 11 Feb 2002 16:11:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA02929 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 16:11:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01834; Mon, 11 Feb 2002 15:45:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01807 for ; Mon, 11 Feb 2002 15:45:50 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16713 for ; Mon, 11 Feb 2002 15:45:47 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1BKjW6Y025515; Mon, 11 Feb 2002 15:45:33 -0500 (EST) Message-ID: <3C682D3F.EB284818@dynamicsoft.com> Date: Mon, 11 Feb 2002 15:44:47 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Venkatesh Venkataramanan CC: "'sip@ietf.org'" , "'sankaran@cs.columbia.edu'" Subject: Re: [Sip] Question regarding Section 13.3.1 item 1.. ?? References: <79FEAA5FABA7D411BF580001023D1BBD9CFC1F@mailserver.sylantro.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Venkatesh Venkataramanan wrote: > > Sorry. Let me re-phrase my question ! > > The earlier versions of the bis allowed "Expires" header to be expressed > as > absolute time (basically equivalent to the "Date" header). This caused > interoperability problems when UA's were out of sync as regards time > (section 29.1 talks about this). To alleviate this problem, Expires now > use > "relative time". Now, as regards INVITE processing, per section 13.3.1 > of > bis07, > > "If the request is an INVITE that contains an Expires header field the > UAS > core inspects this header field. If the INVITE has ALREADY expired, a > 487 > response SHOULD be generated." > > And this part (ascertaining if an INVITE has "already" expired) is not > valid > anymore. The reason being: > > There is no way for the UAS to accurately determine if the request has > expired when it receives the request, if the two UA's under > consideration > were out of sync as regards time. Yes, this is a good point. It could have Expires: 0, but that is not all that useful. I fixed. > > Say UA1 and UA2 are out-of-sync by 10 minutes (UA1 is ahead of UA2). Say > UA2 > initiates an INVITE to UA1 with the following information with Expires > header set to 180: > > INVITE .... > Date: Sat, 10 Feb 2002 10:20:00 PST > Expires: 180 > ... > > When UA2 receives this request, the INVITE has already expired per UA2's > time ( as it is 10 minutes ahead of UA1). Hence it generates a 487 > Response > which is the problem... No, no; the expires is not taken relative to the Date, its taken relative to the local time at the UA. What text leads you to believe its relative to any Date header? I will try to clarify the exact process. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 11 17:10:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19289 for ; Mon, 11 Feb 2002 17:10:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05821 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 17:10:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04196; Mon, 11 Feb 2002 16:35:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04109 for ; Mon, 11 Feb 2002 16:34:55 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17883 for ; Mon, 11 Feb 2002 16:33:51 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1BLY96Y025602; Mon, 11 Feb 2002 16:34:10 -0500 (EST) Message-ID: <3C6838A0.86D9AF48@dynamicsoft.com> Date: Mon, 11 Feb 2002 16:33:20 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: tsvchange and Supported/Require, was: [Sip] Last Call comments on 2543bis-07 References: <200202041726.MAA76667@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit going through this thread, logging the bugs needed to be fixed. Ran into a question here: William Marshall wrote: > 2) Carriers are unfortunately obliged to meet regulatory requirements. > At least some of these, related to Electronic Surveillance, will not > be standardized by IETF (see RFC 2804), though publication is > encouraged (presumably as informational RFCs). However, they may > require > extensions to SIP, and definition of additional headers and option tags. > > It would be unfortunate if this resulting protocol could not be called > SIP. This is an ugly subject, granted, and I do not want it to delay > publication of bis as an RFC. My proposed resolution of this is > to have bis make reference to draft-tsvarea-sipchange-xx for the > guidelines of extensions being standard-track RFCs, and have the > discussion when that draft is re-issued and last-called. > Affects lines 1094-7, 1103-4, 1306-7 I think much of this thread was not properly interpreted by the list, because people are not aware of the specific content of these lines. And that makes a big difference. These lines are about the usage of option tags in Supported and Require. The spec says that these headers can only contain references to standards track RFCs. That does NOT mean that one can't define an extension to sip outside of IETF and use it (that is covered by tsvchange). This requirement does say that such an extension could not be *required* by clients, and it cannot be indicated as being explicitly supported (which would allow servers to require it). These words about Require and Supported come from IESG, and they are based on bad experiences with protocols in the past that did not have such restrictions. Specifically, a protocol in the past allowed for mandatory vendor specific extensions. This was abused by a large vendor, whose servers always required support of their extensions from clients. That vendor was able to call their product compliant to the spec. What we are hoping to avoid is similar problems with SIP. You can't force someone to only put standards-track tags in Require/Supported, but if they do, you can at least publically state that it is not compliant to the specification. Since this issue is really independent of tsv-change, there is no need to reference tsv-change at all, and I have no plans to do so. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 11 20:58:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21825 for ; Mon, 11 Feb 2002 20:58:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA14586 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 20:58:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13181; Mon, 11 Feb 2002 20:19:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13152 for ; Mon, 11 Feb 2002 20:18:59 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21393 for ; Mon, 11 Feb 2002 20:18:57 -0500 (EST) Received: from e2k-sea-xch1.ecsbu-lab-sea.cisco.com (e2k-sea-xch1.cisco.com [10.93.248.22]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1C1ILE09344; Mon, 11 Feb 2002 17:18:21 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [Sip] RE: nits - draft-ietf-sip-events-02 X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 11 Feb 2002 17:18:21 -0800 Message-ID: <4D1E846548771F4AA7FAE28F4B358DB5011A1474@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> Thread-Topic: [Sip] RE: nits - draft-ietf-sip-events-02 Thread-Index: AcGzY29xbDwTUntQRDCk+vpSfa8E5Q== From: "Schulz, Eric" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA13153 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Adam, If you follow this rule consistently, the last paragraph of section 7 (p.27) should read... Registered tokens to designate packages and template-packages MUST NOT contain the character ".," which is used to separate template-packages from packages. The draft does currently have several closing quotation marks that proceed a comma or period, staring with the third paragraph from the top down to the last Reference. I agree with Bert that this is much less confusing than NASA's style, especially when the quoted material is highly dependent on syntax. -Eric "Adam Roach" wrote in message news:<9BF66EBF6BEFD942915B4D4D45C051F3630020.25318@DYN-TX-EXCH-001.dynamicsoft.com>... > Thanks for your comments, Bert. I'll be incorporating them into > the next version. > > >throughout - there are several places where sentence punctuation appears > >inside double-quoted information. This should not be so IMHO. Almost all > >occurrences are with parameter values defined in the SIP spec., whose > >definition doesn't contain the punctuation. > > Yeah, that's an oddity of American English. British English reverses this > rule, if I recall correctly. I agree that that the British usage makes > more sense overall, but I don't think mixing styles is acceptable. > > I'll cite NASA's technical writing guidelines on the topic: > > 3.14.3. Use With Other Marks > > Quotation marks may be used with all other marks of punctuation. > Closing quotation marks always follow commas and periods, > regardless of the context. > > (from http://stipo.larc.nasa.gov/sp7084/sp7084ch3.html) > > /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 daemon@optimus.ietf.org Tue Feb 12 04:41:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06903 for ; Tue, 12 Feb 2002 04:41:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA11318 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 04:41:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09649; Tue, 12 Feb 2002 04:11:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09621 for ; Tue, 12 Feb 2002 04:11:27 -0500 (EST) Received: from cvis22.marconicomms.com (cvis22.marconicomms.com [195.99.244.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06474 for ; Tue, 12 Feb 2002 04:10:14 -0500 (EST) Received: from cvis05.marconicomms.com (unverified) by cvis22.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 12 Feb 2002 09:09:40 +0000 Received: from cvdgwy01.uk.marconicomms.com by cvis05.marconicomms.com with ESMTP (8.10.2+Sun/cvms-34) id g1C99gK27821; Tue, 12 Feb 2002 09:09:42 GMT Subject: Re: [Sip] (no subject) To: bpenfield@acmepacket.com Cc: " From: "Keith Robinson" Date: Tue, 12 Feb 2002 09:09:14 +0000 Message-ID: X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at 12/02/2002 09:09:41 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, I see a problem here. The contact address that the UAC would put at the end of the route headers is the contact address that was supplied by the terminating UA in a 200 OK response; this is not necessarily the same as the original R-URI that was sent in the original INVITE, it may simply be an IP address. I think it is the original R-URI that the loose routing proxies are interested in, either for resolving to the correct internal state machine (along with the from and to headers) or deciding which terminating services to execute. Regards, K. Robinson "Bob Penfield" on 02/11/2002 07:02:22 PM To: , "Keith Robinson" cc: Subject: Re: [Sip] (no subject) ----- Original Message ----- From: "Keith Robinson" > Hello, > > This question may already have been dealt with, so my apologies if it > has. > > Anyway, in 16.4 (Making A Routing Decision) the text states that when a > bis07 proxy detects that the received R-URI is one that it would have > written into the Record-Route header then it must replace it with that last > entry of the Route header and continue as if this was the received R-URI. > It also says that this will only happen if the previous element was a > strict router. If all the preceding elements were strict routers then the > last entry in the Route header would not be the target URI as none of the > previous element would have appended it; indeed there may not be a last > entry as the list may be empty. How is this situation handled, or am I > missing something ? > In this case, the UAC will construct the route headers the same way whether it understands loose routing or not. A pre-bis-06 UA would put the route set plus the contact address (the real/target Request-URI) in the route header. A bis-06/07 compliant UA will add the contact address to the route headers when it recognizes that the first route entry is a strict-router. ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 12 06:46:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08101 for ; Tue, 12 Feb 2002 06:46:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA16433 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 06:46:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15462; Tue, 12 Feb 2002 06:21:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15268 for ; Tue, 12 Feb 2002 06:21:10 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07822 for ; Tue, 12 Feb 2002 06:21:08 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1CBL9b10184 for ; Tue, 12 Feb 2002 06:21:09 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7FQ0MW>; Tue, 12 Feb 2002 05:21:08 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF11@VA02> From: "Peterson, Jon" To: "'sip@ietf.org'" Date: Tue, 12 Feb 2002 05:21:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] 'sips' URI scheme (comments on proposal?) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org As something of a last-minute feature to supplement the SIP security story, the editors have been kicking around the idea of a TLS-specific URI scheme known as SIPS, that would be used in URIs like: 'sips:alice@atlanta.com'. We believe that the SIPS scheme potentially has applicability to many of the ways in which URIs are used in SIP architectures today, including in the Request-URI, in addresses-of-record (which would appear in the To/From field of messages), contact addresses (populating Contact headers, including those of REGISTER methods), and Route headers. The SIPS scheme allows those fields to designate secure resources. First off, let's be clear that this is a TLS-specific feature; like HTTPS, its ancestor, it signifies that the resource identified by the URI should be contacted over TLS. TLS is a SHOULD for UAs, and thus support for these procedures in UAs is conditional on support for TLS. Most powerfully, when used for an address-of-record (the URI you put on your business cards, that you put in the To/From field of requests you send, the address for which you register), the scheme signifies that each hop over which the request travels must be secured with TLS, or more precisely that: - When a SIP entity attempts to forward a request whose Request-URI uses the SIPS URI scheme, if the next hop cannot accept the request over a TLS connection, the request MUST fail. In effect, using SIPS in the Request-URI ensures that TLS is used on every segment between the originator of the request and the destination. This is a handy service, though admittedly one that is specific to architectures in which it is desirable to use TLS for every hop. Note that users handing out contact addresses today have no effective means of expressing a security preference for TLS; if 'sip:alice@atlanta.com;transport=tls' is in the Request-URI, the 'transport' parameter may be removed by the first hop that dereferences the URI, and thus any subsequent hops might be unsecured - however, it doesn't seem far-fetched that Alice might naively assume that the transport parameters would pertain to the entire request path. As an aside, this also hints at one of the benefits of the SIPS URI scheme: transport is independent of TLS, and thus 'sips:alice@atlanta.com;transport=tcp' and 'sips:alice@atlanta.com;transport=sctp' are both valid. The proposal would deprecate the use of ';transport=tls'. There are of course multiple ways in which a client can attempt to forward a request. Perhaps most commonly, a client deferences the Request-URI with a DNS lookup, through the process described in draft-ietf-sip-srv-04. Provided that we accept the SIPS URI proposal, the process described in sip-srv would be updated to reflect the new URI scheme. We would probably create service fields with distinct 'protocol' subfields. Today, in sip-srv-04, we use SIP+D2T to indicate SIP over TCP, and SIP+D2S to indicate SIP over TLS in the NAPTR records used to select a destination. Under this new model, we would use SIPS+D2T to reflect SIP over TLS over TCP. The rules would be: - When a SIP entity looks up the NAPTR resource record set corresponding to the domain of a SIPS URI, it MUST discard all service fields that do not use a SIPS 'protocol' subfield before selecting a resource - then, if no SIPS service fields exist in the resource record set, the request MUST fail. If the lookup is for a domain corresponding to a SIP URI, clients MUST follow the standard NAPTR order and preference system for selecting a record. It is RECOMMENDED that authors of NAPTR records make a SIPS record the most preferred record. NAPTR records associated with proxy servers, redirect servers and registrars MUST have a SIPS record. The result will be that clients referencing SIPS URIs will not select records that do not support SIPS. Note that s> ervers that would like to refuse all requests that have not traveled over TLS can provision only SIPS service fields in their NAPTR records. Also note that if a SIPS+D2T NAPTR record results from a SIP URI lookup, then TLS will be guaranteed only for the next hop (to the IP address/port/transport identified by the SIPS record) - the Request-URI is not re-written after a DNS lookup, and SIPS services > are NOT guaranteed for any subsequent hops in the signaling path. If there are any Route headers associated with the request, clients defer the derefencing of the Request-URI and obey the loose routing rules instead. Since Route headers also contain URIs, these could use the SIPS scheme as well. The use of SIPS in a Route header suggests that regardless of the scheme of the Request-URI, the request should be sent over TLS to the entity identified by the Route header's URI. However: - A SIP entity MUST NOT send a request destined for a SIPS URI to any loose routing entity designated by a SIP URI in a Route header. SIP entities SHOULD support the conversion of SIP to SIPS URIs in Route headers to support SIPS requests. Any loose routing entity that provides a SIP URI in a Record-Route (or through any other means of populating Route headers in clients) MUST be prepared to accept SIPS URIs, and the associated TLS connections, in their stead. Note that the process by which clients route requests to loose routing entities may also involve the deferencing of the URIs in Route headers - this process should follow the general rules for NAPTR record processing given above. Clearly, the operation of location services and registrars requires some restrictions to ensure that this will work properly; if a SIP URI (for a device without TLS support) could be registered under a SIPS address-of-record, for example, that could guarantee that requests will fail - but in that instance the user in question shouldn't be attempting to use a SIPS AoR. The important rules are that: - When a SIP entity registers contact addresses under a SIPS address-of-record, these contact addresses MUST use the SIPS URI scheme. SIP entities MAY register SIPS contact addresses under a SIP address-of-record when appropriate. Finally, there are a couple of limitations or restrictions we should be mindful of: - DNS lookups have a number of security problems that we will not be able to fix here. Therefore, in the cases in which you dereference a URI by resolving the domain with a NAPTR record, it is possible that an attacker could tamper with NAPTR records in a way that degrades security (so they can snoop on your signaling, maybe) or that just denies service. Fortunately, SIPS in the Request-URI can at least make it explicit that a request should fail if security is not available. Note that implementations could also keep track of the security preferences of peers with whom they have longer-term relationships - if a proxy that had a SIPS record yesterday doesn't have one today, that could very well be a hint that something improper is afoot. - Using TLS on every segment means that the terminating UAS will have to be reachable over TLS. Today in the specification, UASs are not strongly encouraged to accept incoming TLS connections, nor to have appropriate certificates to assert their identity with TLS - this may be feasible for some UASs (like PSTN gateways, which could use a site certificate), but not for typical end-user phones. For that reason this mechanism most likely has to rely on persistent TLS connections established upon registration that are kept open indefinitely as a secure channel over which UASs can receive requests. This UAS TLS architecture is already detailed in bis07; however, it has some known scalability limitations. - Pesky humans that use these protocols will undoubtedly discern the difference between SIPS and SIP URIs, and they may manually edit them in response to stimuli. This can either benefit or degrade security. For example, if an attacker corrupts a DNS cache, inserting a fake record set that effectively removes all SIPS records for a proxy server, then any SIPS requests that traverse this proxy server may fail. When a user, however, sees that repeated calls to a SIPS AoR are failing, on some devices they could manually convert the scheme from 'sips' to 'sip' and retry. Of course, there are some safeguards against this (if the destination UA is truly paranoid it could refuse all non-> SIPS requests), but it is a limitation worth noting. On the bright side, users could guess 'SIPS' would be valid even when they are informed only of a SIP URI. That sums up the major points about the proposal. Any comments? Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 12 08:28:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10596 for ; Tue, 12 Feb 2002 08:28:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20570 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 08:28:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19586; Tue, 12 Feb 2002 07:55:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19556 for ; Tue, 12 Feb 2002 07:55:33 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09957 for ; Tue, 12 Feb 2002 07:55:00 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id DBDFCA404; Tue, 12 Feb 2002 14:52:12 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: , Date: Tue, 12 Feb 2002 14:51:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit Subject: [Sip] comments and nits on bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, Line numbers refer to the pdf version. -line 568: should start in a new paragraph after the full stop. - line 644: adress should be address - line 722: "is" is repeated - line 739: definition of UAS says that "If it generates a request later on, it assumes the role of a user agent client for the processing of that transaction". I think this confuses people who are trying to understand the separate roles of a UAC and UAS. It is the UA that can act as a UAC or a UAS, not the UAS. So a UAC is created (or something like that) - line 788: definition of SIP-Version. "The SIP-Version string is case-insensitive, but implementations MUST send upper-case". Maybe I missed earlier discussion, but if its a MUST for uppercase, why make it case-insensitive? - line 855: "Proxy-Authorization" repeated. - lines 1160 - 1161: same info is repeated in lines 1163 - 1165. - line 1162: why is it a MUST to try ALL contacts until a server responds? Can a user just choose to try a subset? - line 1207: a closing bracket is missing after (Section 25.4.14 - line 1211: I think a should is too strong, a client puts a Require header there for a reason, and possibly doesn't want to or can't retry without these required extensions. A MAY could be sufficient there. - line 1263: same as on line 1211. Actually, this statement is just a duplicate of line 1211. - line 1366 - 1368: "A redirect server does not issue any SIP requests of its own. After receiving a request other than CANCEL, the server gathers the list of alternative locations from the location service and either returns a final response of class 3xx or it refuses the request." Why is the request refused after locations have been gathered? on some occasions, requests can be rejected before any alternate locations have been gathered. - line 1404: "CANCEL has no effect on a request to which a UAS has already responded." should say "CANCEL has no effect on a request to which a UAS has already responded to with a final response". - line 1407: "a UAS that receives a CANCEL request for an INVITE, but has not yet sent a response, would 뱒top ringing�" should say "a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would 뱒top ringing�" -lines 1512 and 1527: line 1512 says "The following header fields MUST be included:" and then lists the contact header in line 1527. Although it says that zero or more contact headers, the above sentence gives the false assumption that a contact is mandatory in a REGISTER request. - line 1697: why is it a MUST for a contact header to contain an "expires" parameter? - line 1731 and line 1765: the call-id header in line 1731 is missing the host part in the example (or the call-id in line 1765 has a host that shouldn't be there). - line 1757: "(application/sdp if the Accept header was not present)" should say "(application/sdp is the default if the Accept header was not present)" - lines 1811 - 1813: are a repeat of line 1785 to 1789. - line 1833: does say when the local sequence number would be set. - line 1847: "(it is established when the UA sends a request within the dialog)", this needs to be more specific; which UA are we exactly referring to? how about "(it is established when the remote UA sends a request within the dialog)" - line 1861: open issue - line 1872: "Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers" why MUST be contiguous? its can be a SHOULD. - line 1875: should say "MUST be placed into the Cseq header". ("be" is missing). - line 1888: should say "MUST add a Route header". ("add" is missing). - line 1951 - 1953: this is a general statement about Requests within a dialog and not just specific to UAS behaviour. I propose for it to be moved to section 12.2 (before 12.2.1). - line 1967: "When a dialog is established with INVITE, it is terminated with a BYE". I propose "When a dialog is established with INVITE, it MUST be terminated with a BYE". - line 2021: "In this specification, offers and answers can only appear in INVITE and PRACK requests and responses". What about ACK? an answer can be there. - line 2064: "excluding the tag" should be put in brackets instead of between commas to show that this comment only belongs to the To header. - line 2166: section 13.3.1.2 does not talk about what happens if a 3xx is returned with no contacts. - line 2189 - 2195: is that INVITE server transaction destroyed as soon as it receives the final response or as soon as it sends the final response? does the UAS core then directly pass retransmissions to the transport layer? - line 2278: what would be the reason for a UAC to send a re-INVITE with no SDP? - line 2285: why terminate the session, this is just a re-INVITE. The UAC can re-INVITE yet again. - line 2296: Sections 13 and 12. Make it sections 12 and 13 :) - line 2327: "Once the BYE is constructed, it creates a new non-INVITE client transaction". Who is it? maybe it should say "Once the BYE is constructed, the UAC core creates a new non-INVITE client transaction" - line 2364: choose instead of chose. - line 2375: "The proxy SHOULD NOT send a CANCEL." Does it really mean that a proxy SHOULD NOT initiate a CANCEL? - line 2394: in the .txt version, the numbers there are screwed up. - line 2416: in the .txt version, the words "a request" are missing after "forwarding". - line 2454: "is" is repeated. - line 2464: section number is missing. - line 2475: "Otherwise, if the Request-URI contains an maddr parameter, the Request-URI MUST be ..." could instead say "Otherwise, if the Request-URI contains an maddr parameter the proxy is not responsible for, the Request-URI MUST be ..." - line 2712: this section 16.6 contains 5 then 3 processing points, yet the details show 10. Also the numbers for detailed steps don't follow the numbers above. - line 2806: should say "1xx and 2xx responses may be involved in the establishment of dialogs". ("of" is missing) - line 2811: "Since a proxy may not..." should say "Since a proxy MUST NOT" to be precise. - line 2856: "to" is repeated. - line 2910: should the reference be to section 9? - line 2941: "The proxy examines the branch ID of the received request". Which branch-id? the one in the top-most via header? there could be more than 1 via header. - lines 3099 to 3100: "The transaction exists between the UA or stateful proxy on one side of the stateless proxy, and the UA or stateful proxy on the other side. As far as SIP transactions are concerned, stateless proxies are effectively transparent" doesn't make sense. Should it say "The transaction exists between the UA or stateful proxy on one side, and the UA or stateful proxy on the other side. As far as SIP transactions are concerned, stateless proxies are effectively transparent"? (remove "of the stateless proxy"). - line 3186: "transaction to" is repeated. - line 3212: "Whenever a response is received by the transport, if the transport layer finds no matching client transaction (using the rules of Section 17.1.3), the response is passed directly to the core." Is this for a 2xx response only? If so, it should mention that. It should also mention what happens if transport layer received a non-2xx final response and no matching client transaction is found. - line 3233: "These rules", which ones? all from the start of this section? If so, this sentence starting from this line should be at the start of the section. Other wise specify which rules. - line 3258: "what" should be changed to "to" - line 3275: "...SHOULD move to the 밣roceeding� state." It should go on to say that "Timer E MUST be reset to T2". - line 3287: why is T4 so low at 5 seconds? (maybe I missed this discussion). - line 3464: "PRACK is a normal SIP message, like BYE. As such, its own reliability is ensured hop-by-hop through each stateful proxy". I failed to find where that is mentioned about BYE that it is hop-by-hop. - line 3475: "...100rel. While this specification..." The .txt version ate some of the words here. It says "100rel specification" - line 3478: "option tag 100rel. If the UAS is unwilling to do so, it MUST reject the initial request with a 420 (Bad Extension)". Again, the .txt version ate some words. it says "option tag 100rel initial request with a 420 (Bad Extension)". - line 3512: "It SHOULD cease retransmissions of the reliable provisional response". Why isn't this a MUST? That's all for now. More comments are in separate emails. Regards, Hisham Khartabil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 12 09:06:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11935 for ; Tue, 12 Feb 2002 09:06:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA22497 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 09:06:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21381; Tue, 12 Feb 2002 08:44:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21354 for ; Tue, 12 Feb 2002 08:44:22 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11046 for ; Tue, 12 Feb 2002 08:44:19 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AC333DE601A2; Tue, 12 Feb 2002 08:44:19 -0500 Message-ID: <002b01c1b3cb$29712b20$2300000a@acmepacket.com> From: "Bob Penfield" To: "Keith Robinson" Cc: " References: Subject: Re: [Sip] (no subject) Date: Tue, 12 Feb 2002 08:42:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit For subsequent requests in a dialog, the contact provided by the UA in a 200 OK is what the UAC wants to use for the target URI (last hop in the route). If there are no route headers, the target URI is used as the R-URI. If this is a new request with a pre-loaded route, the UA will put the target URI (usually the same at the To header) as the last route header. This has always been to only way to guarantee that the last hop in the route would receive the R-URI the UAC intended. ----- Original Message ----- From: "Keith Robinson" To: Cc: " Sent: Tuesday, February 12, 2002 4:09 AM Subject: Re: [Sip] (no subject) > > Hello, > > I see a problem here. > > The contact address that the UAC would put at the end of the route headers > is the contact address that was supplied by the terminating UA in a 200 OK > response; this is not necessarily the same as the original R-URI that was > sent in the original INVITE, it may simply be an IP address. I think it is > the original R-URI that the loose routing proxies are interested in, either > for resolving to the correct internal state machine (along with the from > and to headers) or deciding which terminating services to execute. > > Regards, > > K. Robinson > > > > > "Bob Penfield" on 02/11/2002 07:02:22 PM > > To: , "Keith Robinson" > cc: > > Subject: Re: [Sip] (no subject) > > > ----- Original Message ----- > From: "Keith Robinson" > > > Hello, > > > > This question may already have been dealt with, so my apologies if > it > > has. > > > > Anyway, in 16.4 (Making A Routing Decision) the text states that when a > > bis07 proxy detects that the received R-URI is one that it would have > > written into the Record-Route header then it must replace it with that > last > > entry of the Route header and continue as if this was the received R-URI. > > It also says that this will only happen if the previous element was a > > strict router. If all the preceding elements were strict routers then the > > last entry in the Route header would not be the target URI as none of the > > previous element would have appended it; indeed there may not be a last > > entry as the list may be empty. How is this situation handled, or am I > > missing something ? > > > > In this case, the UAC will construct the route headers the same way whether > it understands loose routing or not. A pre-bis-06 UA would put the route > set > plus the contact address (the real/target Request-URI) in the route header. > A bis-06/07 compliant UA will add the contact address to the route headers > when it recognizes that the first route entry is a strict-router. > > > > > > > > ------------ > This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 12 09:06:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11962 for ; Tue, 12 Feb 2002 09:06:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA22515 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 09:06:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21190; Tue, 12 Feb 2002 08:36:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21157 for ; Tue, 12 Feb 2002 08:35:58 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10794 for ; Tue, 12 Feb 2002 08:35:55 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id ADFE71E08E; Tue, 12 Feb 2002 08:35:48 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA00237; Tue, 12 Feb 2002 08:35:45 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA20420; Tue, 12 Feb 2002 08:37:26 -0500 (EST) Date: Tue, 12 Feb 2002 08:37:26 -0500 (EST) Message-Id: <200202121337.IAA20420@fish.research.att.com> To: jdrosen@dynamicsoft.com Cc: sip@ietf.org Subject: Re: [Sip] tsvchange and Supported/Require, was: [Sip] Last Call comments on 2543bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The text that I am objecting to here first appeared in the bis rewrite (bis-05). If it was preceeded by any list discussion leading to a consensus that it should be included, then I missed it. I've been objecting regularly ever since the text in bis-05 appeared. The discussion last week concluded, I believe, that IANA registration of header names and option tags, combined with text regarding formats and discussion to appear in the extension guidelines draft, was sufficient. No reference to tsvarea-sipchange was needed. While registration of header names could be independent of option tags, it is not clear that is a good idea. The "Proxy-Require" with an option tag corresponding to an added header is one technique similar to those used to go from 4 9's of reliability to 5 9's. If all is working well the option tag in the Proxy-Require is totally redundant; however it serves as a backup check on several other parts of the system (like message routing in particular). There are a number of "facts" that I don't think need any discussion. Some of these are 1) Carriers will be obliged to meet regulatory requirements, and 2) Some regulatory requirements will not be standardized by IETF. As I stated before, it is an ugly subject. So assume there is an implementation of a protocol that starts with SIP and adds extensions necessary to meet the regulatory requirements on carriers. IETF then publically states that it is not compliant to SIP. Then the decision comes down from high that SIP can't meet the service requirements, so pick a standard protocol that can. And then the whole network architecture is changed. Where can we break this sequence before it reaches the bad conclusion? One way is to design the extensions needed for regulatory requirements so that they don't need new headers. One way is to keep the IANA registry of headers, but don't add a Proxy-Require tag. One way is to allow the result to be called compliant to the specification of SIP. It would be nice if no new information were needed to convey between proxies. Unfortunately there are cases (actually very common cases) where it is essential. This was studied in depth for PacketCable. I'd welcome alternative designs, but am very skeptical. This is not a subject for the sip list, anyway. If the additional information needed to meet regulatory requirements were, instead, added as a body part (making a multi-part attachment), then the problem just moves. The "content-type" of this additional body part would need a name, and the requirement would then be that the receiving proxy understand this new content-type. That seems no different than understanding a new header. And if routing goofs, then this multi-part reaches the UAS. While a UAS could easily recover from an unknown header in the request, it is not so clear that it could recover from an unknown multi-part body. If the additional headers were added based on IANA registration, but an option tag were not, then the problem becomes one of system reliability. As I stated above, double-checks like the header-optiontag are the tools to get to 5 9's. Give up on the reliability goal? I doubt it. While I agree there is a problem that allows abuse by the unnamed large vendor, the solution proposed in bis-05 has other unintended side-effects. The only solution I can see is to allow these non-standards-track extensions, and try again at the general problem. Bill Marshall wtm@research.att.com -----original message----- Date: Mon, 11 Feb 2002 16:33:20 -0500 From: Jonathan Rosenberg To: William Marshall Cc: sip@ietf.org Subject: tsvchange and Supported/Require, was: [Sip] Last Call comments on 2543bis-07 going through this thread, logging the bugs needed to be fixed. Ran into a question here: William Marshall wrote: > 2) Carriers are unfortunately obliged to meet regulatory requirements. > At least some of these, related to Electronic Surveillance, will not > be standardized by IETF (see RFC 2804), though publication is > encouraged (presumably as informational RFCs). However, they may > require > extensions to SIP, and definition of additional headers and option tags. > > It would be unfortunate if this resulting protocol could not be called > SIP. This is an ugly subject, granted, and I do not want it to delay > publication of bis as an RFC. My proposed resolution of this is > to have bis make reference to draft-tsvarea-sipchange-xx for the > guidelines of extensions being standard-track RFCs, and have the > discussion when that draft is re-issued and last-called. > Affects lines 1094-7, 1103-4, 1306-7 I think much of this thread was not properly interpreted by the list, because people are not aware of the specific content of these lines. And that makes a big difference. These lines are about the usage of option tags in Supported and Require. The spec says that these headers can only contain references to standards track RFCs. That does NOT mean that one can't define an extension to sip outside of IETF and use it (that is covered by tsvchange). This requirement does say that such an extension could not be *required* by clients, and it cannot be indicated as being explicitly supported (which would allow servers to require it). These words about Require and Supported come from IESG, and they are based on bad experiences with protocols in the past that did not have such restrictions. Specifically, a protocol in the past allowed for mandatory vendor specific extensions. This was abused by a large vendor, whose servers always required support of their extensions from clients. That vendor was able to call their product compliant to the spec. What we are hoping to avoid is similar problems with SIP. You can't force someone to only put standards-track tags in Require/Supported, but if they do, you can at least publically state that it is not compliant to the specification. Since this issue is really independent of tsv-change, there is no need to reference tsv-change at all, and I have no plans to do so. -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 daemon@optimus.ietf.org Tue Feb 12 10:20:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14885 for ; Tue, 12 Feb 2002 10:20:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26942 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 10:20:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24481; Tue, 12 Feb 2002 09:42:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24456 for ; Tue, 12 Feb 2002 09:42:40 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13452 for ; Tue, 12 Feb 2002 09:42:37 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id D4F131E0FA; Tue, 12 Feb 2002 09:42:38 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA01907; Tue, 12 Feb 2002 09:42:35 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id JAA34204; Tue, 12 Feb 2002 09:45:00 -0500 (EST) Date: Tue, 12 Feb 2002 09:45:00 -0500 (EST) Message-Id: <200202121445.JAA34204@fish.research.att.com> To: jon.peterson@neustar.biz Cc: sip@ietf.org Subject: [Sip] 'sips' URI scheme (comments on proposal?) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I've always believed (maybe incorrectly) that one reason for https was to prevent proxies from doing anything with the request, thereby forcing it to be a pure client-server transaction. Doesn't an http proxy merely tunnel a https: request, without even seeing the Request-URI? Wouldn't sips: be expected to mean the same? That seems a lot different from requesting tls on every link. Bill Marshall wtm@research.att.com -----original message----- From: "Peterson, Jon" To: "'sip@ietf.org'" Date: Tue, 12 Feb 2002 05:21:01 -0600 Subject: [Sip] 'sips' URI scheme (comments on proposal?) As something of a last-minute feature to supplement the SIP security story, the editors have been kicking around the idea of a TLS-specific URI scheme known as SIPS, that would be used in URIs like: 'sips:alice@atlanta.com'. We believe that the SIPS scheme potentially has applicability to many of the ways in which URIs are used in SIP architectures today, including in the Request-URI, in addresses-of-record (which would appear in the To/From field of messages), contact addresses (populating Contact headers, including those of REGISTER methods), and Route headers. The SIPS scheme allows those fields to designate secure resources. First off, let's be clear that this is a TLS-specific feature; like HTTPS, its ancestor, it signifies that the resource identified by the URI should be contacted over TLS. TLS is a SHOULD for UAs, and thus support for these procedures in UAs is conditional on support for TLS. Most powerfully, when used for an address-of-record (the URI you put on your business cards, that you put in the To/From field of requests you send, the address for which you register), the scheme signifies that each hop over which the request travels must be secured with TLS, or more precisely that: - When a SIP entity attempts to forward a request whose Request-URI uses the SIPS URI scheme, if the next hop cannot accept the request over a TLS connection, the request MUST fail. In effect, using SIPS in the Request-URI ensures that TLS is used on every segment between the originator of the request and the destination. This is a handy service, though admittedly one that is specific to architectures in which it is desirable to use TLS for every hop. Note that users handing out contact addresses today have no effective means of expressing a security preference for TLS; if 'sip:alice@atlanta.com;transport=tls' is in the Request-URI, the 'transport' parameter may be removed by the first hop that dereferences the URI, and thus any subsequent hops might be unsecured - however, it doesn't seem far-fetched that Alice might naively assume that the transport parameters would pertain to the entire request path. As an aside, this also hints at one of the benefits of the SIPS URI scheme: transport is independent of TLS, and thus 'sips:alice@atlanta.com;transport=tcp' and 'sips:alice@atlanta.com;transport=sctp' are both valid. The proposal would deprecate the use of ';transport=tls'. There are of course multiple ways in which a client can attempt to forward a request. Perhaps most commonly, a client deferences the Request-URI with a DNS lookup, through the process described in draft-ietf-sip-srv-04. Provided that we accept the SIPS URI proposal, the process described in sip-srv would be updated to reflect the new URI scheme. We would probably create service fields with distinct 'protocol' subfields. Today, in sip-srv-04, we use SIP+D2T to indicate SIP over TCP, and SIP+D2S to indicate SIP over TLS in the NAPTR records used to select a destination. Under this new model, we would use SIPS+D2T to reflect SIP over TLS over TCP. The rules would be: - When a SIP entity looks up the NAPTR resource record set corresponding to the domain of a SIPS URI, it MUST discard all service fields that do not use a SIPS 'protocol' subfield before selecting a resource - then, if no SIPS service fields exist in the resource record set, the request MUST fail. If the lookup is for a domain corresponding to a SIP URI, clients MUST follow the standard NAPTR order and preference system for selecting a record. It is RECOMMENDED that authors of NAPTR records make a SIPS record the most preferred record. NAPTR records associated with proxy servers, redirect servers and registrars MUST have a SIPS record. The result will be that clients referencing SIPS URIs will not select records that do not support SIPS. Note that s> ervers that would like to refuse all requests that have not traveled over TLS can provision only SIPS service fields in their NAPTR records. Also note that if a SIPS+D2T NAPTR record results from a SIP URI lookup, then TLS will be guaranteed only for the next hop (to the IP address/port/transport identified by the SIPS record) - the Request-URI is not re-written after a DNS lookup, and SIPS services > are NOT guaranteed for any subsequent hops in the signaling path. If there are any Route headers associated with the request, clients defer the derefencing of the Request-URI and obey the loose routing rules instead. Since Route headers also contain URIs, these could use the SIPS scheme as well. The use of SIPS in a Route header suggests that regardless of the scheme of the Request-URI, the request should be sent over TLS to the entity identified by the Route header's URI. However: - A SIP entity MUST NOT send a request destined for a SIPS URI to any loose routing entity designated by a SIP URI in a Route header. SIP entities SHOULD support the conversion of SIP to SIPS URIs in Route headers to support SIPS requests. Any loose routing entity that provides a SIP URI in a Record-Route (or through any other means of populating Route headers in clients) MUST be prepared to accept SIPS URIs, and the associated TLS connections, in their stead. Note that the process by which clients route requests to loose routing entities may also involve the deferencing of the URIs in Route headers - this process should follow the general rules for NAPTR record processing given above. Clearly, the operation of location services and registrars requires some restrictions to ensure that this will work properly; if a SIP URI (for a device without TLS support) could be registered under a SIPS address-of-record, for example, that could guarantee that requests will fail - but in that instance the user in question shouldn't be attempting to use a SIPS AoR. The important rules are that: - When a SIP entity registers contact addresses under a SIPS address-of-record, these contact addresses MUST use the SIPS URI scheme. SIP entities MAY register SIPS contact addresses under a SIP address-of-record when appropriate. Finally, there are a couple of limitations or restrictions we should be mindful of: - DNS lookups have a number of security problems that we will not be able to fix here. Therefore, in the cases in which you dereference a URI by resolving the domain with a NAPTR record, it is possible that an attacker could tamper with NAPTR records in a way that degrades security (so they can snoop on your signaling, maybe) or that just denies service. Fortunately, SIPS in the Request-URI can at least make it explicit that a request should fail if security is not available. Note that implementations could also keep track of the security preferences of peers with whom they have longer-term relationships - if a proxy that had a SIPS record yesterday doesn't have one today, that could very well be a hint that something improper is afoot. - Using TLS on every segment means that the terminating UAS will have to be reachable over TLS. Today in the specification, UASs are not strongly encouraged to accept incoming TLS connections, nor to have appropriate certificates to assert their identity with TLS - this may be feasible for some UASs (like PSTN gateways, which could use a site certificate), but not for typical end-user phones. For that reason this mechanism most likely has to rely on persistent TLS connections established upon registration that are kept open indefinitely as a secure channel over which UASs can receive requests. This UAS TLS architecture is already detailed in bis07; however, it has some known scalability limitations. - Pesky humans that use these protocols will undoubtedly discern the difference between SIPS and SIP URIs, and they may manually edit them in response to stimuli. This can either benefit or degrade security. For example, if an attacker corrupts a DNS cache, inserting a fake record set that effectively removes all SIPS records for a proxy server, then any SIPS requests that traverse this proxy server may fail. When a user, however, sees that repeated calls to a SIPS AoR are failing, on some devices they could manually convert the scheme from 'sips' to 'sip' and retry. Of course, there are some safeguards against this (if the destination UA is truly paranoid it could refuse all non-> SIPS requests), but it is a limitation worth noting. On the bright side, users could guess 'SIPS' would be valid even when they are informed only of a SIP URI. That sums up the major points about the proposal. Any comments? Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 12 10:40:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15548 for ; Tue, 12 Feb 2002 10:40:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28122 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 10:40:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26737; Tue, 12 Feb 2002 10:17:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26706 for ; Tue, 12 Feb 2002 10:17:41 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14784 for ; Tue, 12 Feb 2002 10:17:37 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id B3D74A566; Tue, 12 Feb 2002 17:17:34 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: , Date: Tue, 12 Feb 2002 17:17:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] PRACK holding the offer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Perhaps this has been discussed earlier, but here is goes anyway: What is the harm in a PRACK carrying the SDP offer and the answer being carried in the 200OK for PRACK or even in the 200OK for the initial INVITE? INVITE (no SDP) -------------------> 1xx (no SDP) 100rel <------------------ PRACK (SDP) -------------------> 200 (SDP) for PRACK <------------------ OR 200 (SDP) for INVITE <------------------ 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 daemon@optimus.ietf.org Tue Feb 12 10:41:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15609 for ; Tue, 12 Feb 2002 10:41:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28157 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 10:41:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26457; Tue, 12 Feb 2002 10:12:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26417 for ; Tue, 12 Feb 2002 10:11:59 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14554 for ; Tue, 12 Feb 2002 10:11:55 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id CF05DA53A; Tue, 12 Feb 2002 17:11:52 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: , Date: Tue, 12 Feb 2002 17:11:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] References in bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, It looks like whenever text refers to a reference beyond [18] in bin-07, it refers to the wrong one. eg: Line 828 references [20] instead of [21] for RFC2822. (It could be a result of adding the S/MIME reference). Regards, Hisham Khartabil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 12 11:14:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16794 for ; Tue, 12 Feb 2002 11:14:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29812 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 11:14:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28769; Tue, 12 Feb 2002 10:57:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28661 for ; Tue, 12 Feb 2002 10:57:04 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16147 for ; Tue, 12 Feb 2002 10:57:02 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1CFv0h18001; Tue, 12 Feb 2002 09:57:00 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1CFv0e15728; Tue, 12 Feb 2002 09:57:00 -0600 (CST) Received: from lmf.ericsson.se (rmt160202.am.ericsson.se [138.85.160.202]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA02440; Tue, 12 Feb 2002 09:56:58 -0600 (CST) Message-ID: <3C6942B8.86847586@lmf.ericsson.se> Date: Tue, 12 Feb 2002 18:28:40 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hisham Khartabil CC: sip@ietf.org, jdrosen@dynamicsoft.com Subject: Re: [Sip] PRACK holding the offer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, So far we have assumed that if you do not send an offer in the INVITE it is because you wait for an offer from the UAS. Do you have an scenario where the UAC does not introduce an offer in the INVITE but intends to do it later (only if the first 1xx does not contain one)?? Gonzalo Hisham Khartabil wrote: > > Hi, > > Perhaps this has been discussed earlier, but here is goes anyway: > > What is the harm in a PRACK carrying the SDP offer and the answer being > carried in the 200OK for PRACK or even in the 200OK for the initial INVITE? > > INVITE (no SDP) > -------------------> > > 1xx (no SDP) 100rel > <------------------ > > PRACK (SDP) > -------------------> > > 200 (SDP) for PRACK > <------------------ > > OR > 200 (SDP) for INVITE > <------------------ > > 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 -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Tue Feb 12 11:52:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18180 for ; Tue, 12 Feb 2002 11:52:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01672 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 11:52:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00009; Tue, 12 Feb 2002 11:20:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29974 for ; Tue, 12 Feb 2002 11:19:57 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16936 for ; Tue, 12 Feb 2002 11:19:55 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1CGJOE13987; Tue, 12 Feb 2002 08:19:25 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW33506; Tue, 12 Feb 2002 08:18:54 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA26893; Tue, 12 Feb 2002 08:19:23 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15465.16522.952757.438593@thomasm-u1.cisco.com> Date: Tue, 12 Feb 2002 08:19:22 -0800 (PST) To: "Peterson, Jon" Cc: "'sip@ietf.org'" Subject: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: <70565611B164D511957A001083FCDD56CAAF11@VA02> References: <70565611B164D511957A001083FCDD56CAAF11@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > > As something of a last-minute feature to supplement the SIP > security story, Is there no concept of feature freeze? The amount of things being added that have had next to no scrutiny is mind boggling. 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 daemon@optimus.ietf.org Tue Feb 12 12:32:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19531 for ; Tue, 12 Feb 2002 12:32:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05196 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 12:32:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03424; Tue, 12 Feb 2002 12:02:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03397 for ; Tue, 12 Feb 2002 12:01:56 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18571 for ; Tue, 12 Feb 2002 12:01:53 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A862F9A00C8; Tue, 12 Feb 2002 11:52:50 -0500 Message-ID: <0be801c1b3e5$772ff980$2300000a@acmepacket.com> From: "Bob Penfield" To: "Michael Thomas" , "Peterson, Jon" Cc: References: <70565611B164D511957A001083FCDD56CAAF11@VA02> <15465.16522.952757.438593@thomasm-u1.cisco.com> Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) Date: Tue, 12 Feb 2002 11:51:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Although at first glance the idea has merit, I'm inclined to agree with Mike Thomas. If the intention is to include this proposal in the bis spec, it should at the very least follow the process used for the loose routing proposal with an I-D and a few weeks to review and comment before it gets added to bis. That would require a delay of up to a month or more in our current schedule. We are 6 days from concluding WG Last Call on bis, right? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Michael Thomas" To: "Peterson, Jon" Cc: Sent: Tuesday, February 12, 2002 11:19 AM Subject: [Sip] 'sips' URI scheme (comments on proposal?) > Peterson, Jon writes: > > > > As something of a last-minute feature to supplement the SIP > > security story, > > Is there no concept of feature freeze? The amount of > things being added that have had next to no scrutiny > is mind boggling. > > 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 daemon@optimus.ietf.org Tue Feb 12 12:36:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19626 for ; Tue, 12 Feb 2002 12:36:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05281 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 12:36:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03899; Tue, 12 Feb 2002 12:10:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03872 for ; Tue, 12 Feb 2002 12:10:43 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18813 for ; Tue, 12 Feb 2002 12:10:40 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GRF00K01JOJH3@firewall.wcom.com> for sip@ietf.org; Tue, 12 Feb 2002 17:09:56 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GRF00K1XJOJ8L@firewall.wcom.com>; Tue, 12 Feb 2002 17:09:55 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GRF00501JOFII@dgismtp02.wcomnet.com>; Tue, 12 Feb 2002 17:09:55 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GRF003CKJO6W0@dgismtp02.wcomnet.com>; Tue, 12 Feb 2002 17:09:43 +0000 (GMT) Date: Tue, 12 Feb 2002 11:09:44 -0600 From: Henry Sinnreich Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?) In-reply-to: <15465.16522.952757.438593@thomasm-u1.cisco.com> To: "'Michael Thomas'" , "'Peterson, Jon'" Cc: sip@ietf.org Message-id: <000001c1b3e8$115f7e20$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree with: > Is there no concept of feature freeze? The amount of > things being added that have had next to no scrutiny > is mind boggling. Though it is an interesting proposition for some next phase. Let's focus and execute what we have now on the plate. Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Michael Thomas > Sent: Tuesday, February 12, 2002 10:19 AM > To: Peterson, Jon > Cc: 'sip@ietf.org' > Subject: [Sip] 'sips' URI scheme (comments on proposal?) > > > Peterson, Jon writes: > > > > As something of a last-minute feature to supplement the > SIP > security story, > > Is there no concept of feature freeze? The amount of > things being added that have had next to no scrutiny > is mind boggling. > > 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 daemon@optimus.ietf.org Tue Feb 12 12:38:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19701 for ; Tue, 12 Feb 2002 12:38:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05347 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 12:38:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03832; Tue, 12 Feb 2002 12:08:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03800 for ; Tue, 12 Feb 2002 12:08:30 -0500 (EST) Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18726 for ; Tue, 12 Feb 2002 12:08:26 -0500 (EST) Message-ID: <20020212170731.45633.qmail@web11603.mail.yahoo.com> Received: from [216.51.103.156] by web11603.mail.yahoo.com via HTTP; Tue, 12 Feb 2002 09:07:31 PST Date: Tue, 12 Feb 2002 09:07:31 -0800 (PST) From: Sean Olson Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) To: Bob Penfield , Michael Thomas , "Peterson, Jon" Cc: sip@ietf.org In-Reply-To: <0be801c1b3e5$772ff980$2300000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a very sudden change, but the sips: scheme appears to have merit over a "transport=tls" solution. I would prefer that the tls parameter at least be deprecated in bis if the sips: scheme cannot be added. In any event, the sips: scheme appears at first to provide a complete TLS solution for SIP where the original transport parameter did not. /sean --- Bob Penfield wrote: > Although at first glance the idea has merit, I'm > inclined to agree with Mike > Thomas. If the intention is to include this proposal > in the bis spec, it > should at the very least follow the process used for > the loose routing > proposal with an I-D and a few weeks to review and > comment before it gets > added to bis. That would require a delay of up to a > month or more in our > current schedule. We are 6 days from concluding WG > Last Call on bis, right? > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Michael Thomas" > To: "Peterson, Jon" > Cc: > Sent: Tuesday, February 12, 2002 11:19 AM > Subject: [Sip] 'sips' URI scheme (comments on > proposal?) > > > > Peterson, Jon writes: > > > > > > As something of a last-minute feature to > supplement the SIP > > > security story, > > > > Is there no concept of feature freeze? The > amount of > > things being added that have had next to no > scrutiny > > is mind boggling. > > > > Mike ===== Sean Olson __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.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 daemon@optimus.ietf.org Tue Feb 12 13:20:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21018 for ; Tue, 12 Feb 2002 13:20:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA06860 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 13:20:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05811; Tue, 12 Feb 2002 12:55:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05780 for ; Tue, 12 Feb 2002 12:55:01 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20166 for ; Tue, 12 Feb 2002 12:54:59 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id 3B6B6A07E; Tue, 12 Feb 2002 19:54:59 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: "Gonzalo Camarillo" Cc: , Subject: RE: [Sip] PRACK holding the offer Date: Tue, 12 Feb 2002 19:54:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C6942B8.86847586@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Well, I don't have a specific scenario, just the general one where I invite you and say "lets do something, what do you have", you send a 1xx saying "ok, but you let me first what you have". I just questioned it because the restrictions in section 13.2.1 prohibit such scenario and I was wondering why should it be prohibited. Regards, Hisham > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Gonzalo > Camarillo > Sent: Tuesday, 12 February 2002 6:29 PM > To: Hisham Khartabil > Cc: sip@ietf.org; jdrosen@dynamicsoft.com > Subject: Re: [Sip] PRACK holding the offer > > > Hi, > > So far we have assumed that if you do not send an offer in the INVITE it > is because you wait for an offer from the UAS. > > Do you have an scenario where the UAC does not introduce an offer in the > INVITE but intends to do it later (only if the first 1xx does not > contain one)?? > > Gonzalo > > Hisham Khartabil wrote: > > > > Hi, > > > > Perhaps this has been discussed earlier, but here is goes anyway: > > > > What is the harm in a PRACK carrying the SDP offer and the answer being > > carried in the 200OK for PRACK or even in the 200OK for the > initial INVITE? > > > > INVITE (no SDP) > > -------------------> > > > > 1xx (no SDP) 100rel > > <------------------ > > > > PRACK (SDP) > > -------------------> > > > > 200 (SDP) for PRACK > > <------------------ > > > > OR > > 200 (SDP) for INVITE > > <------------------ > > > > 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 > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Tue Feb 12 13:20:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21035 for ; Tue, 12 Feb 2002 13:20:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA06874 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 13:20:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05940; Tue, 12 Feb 2002 12:58:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05910 for ; Tue, 12 Feb 2002 12:58:31 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20254 for ; Tue, 12 Feb 2002 12:58:29 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id g1CHvxp27370 for ; Tue, 12 Feb 2002 18:57:59 +0100 Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.1/8.12.1) with ESMTP id g1CHvxkv008950 for ; Tue, 12 Feb 2002 18:57:59 +0100 (MET) Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id <1XS5SSR5>; Tue, 12 Feb 2002 18:57:57 +0100 Message-ID: From: Brazier Lachlan To: "'sip@ietf.org'" Date: Tue, 12 Feb 2002 18:57:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3EE.CD6CEA20" Subject: [Sip] Routing examples Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B3EE.CD6CEA20 Content-Type: text/plain Hello, sorry if I missed this in one of the mailing lists. In the examples for Proxy Route processing (16.11.1.1 Basic SIP Trapezoid) P1 finds P2 resposible for "domain.com". P2 receives the INVITE request, and inserts a Record-Route (Record-Route: ). Wouldn't the Record-Route header be: Record-Route: Did I miss something with DNS or a chapter in the draft? Thanks Lachlan ------_=_NextPart_001_01C1B3EE.CD6CEA20 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTMuMTIiPg0KPFRJVExFPlJvdXRpbmcg ZXhhbXBsZXM8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5IZWxs byw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5zb3JyeSBpZiBJIG1pc3NlZCB0aGlz IGluIG9uZSBvZiB0aGUgbWFpbGluZyBsaXN0cy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJ WkU9Mj5JbiB0aGUgZXhhbXBsZXMgZm9yIFByb3h5IFJvdXRlIHByb2Nlc3NpbmcgKDE2LjExLjEu MSBCYXNpYyBTSVAgVHJhcGV6b2lkKTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+UDEgZmluZHMg UDIgcmVzcG9zaWJsZSBmb3IgJnF1b3Q7ZG9tYWluLmNvbSZxdW90Oy4gUDIgcmVjZWl2ZXMgdGhl IElOVklURSByZXF1ZXN0LCBhbmQgaW5zZXJ0cyBhIFJlY29yZC1Sb3V0ZSAoUmVjb3JkLVJvdXRl OiAmbHQ7c2lwOnAyLmRvbWFpbi5jb207bHImZ3Q7KS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBT SVpFPTI+V291bGRuJ3QgdGhlIFJlY29yZC1Sb3V0ZSBoZWFkZXIgYmU6IFJlY29yZC1Sb3V0ZTog Jmx0O3NpcDpkb21haW4uY29tO2xyJmd0OzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y PkRpZCBJIG1pc3Mgc29tZXRoaW5nIHdpdGggRE5TIG9yIGEgY2hhcHRlciBpbiB0aGUgZHJhZnQ/ PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhhbmtzIDwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+TGFjaGxhbjwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C1B3EE.CD6CEA20-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 12 13:52:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21865 for ; Tue, 12 Feb 2002 13:52:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA08101 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 13:52:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06766; Tue, 12 Feb 2002 13:17:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06735 for ; Tue, 12 Feb 2002 13:17:07 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20925 for ; Tue, 12 Feb 2002 13:17:05 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1CIH3h24903; Tue, 12 Feb 2002 12:17:04 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1CIH2x06147; Tue, 12 Feb 2002 12:17:02 -0600 (CST) Received: from lmf.ericsson.se (rmt160202.am.ericsson.se [138.85.160.202]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA17355; Tue, 12 Feb 2002 12:17:00 -0600 (CST) Message-ID: <3C696389.B6B9EAEE@lmf.ericsson.se> Date: Tue, 12 Feb 2002 20:48:41 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hisham Khartabil CC: sip@ietf.org, jdrosen@dynamicsoft.com Subject: Re: [Sip] PRACK holding the offer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A reson for not allowing this exchange is that it would complicate the glare prevention mechanisms (if the UAS sends an offer in a 1xx and the UAC is sending at the same time an offer in an UPDATE we will have a collision). But I believe you are thinking of only using the PRACK to a 1xx to send the offer from the UAC. In my opinion this increases the complexity of the protocol for no real gain. If the UAC can send an offer in the first place, it will send it it the INVITE. If it could not send the offer in the INVITE (maybe because it is a 3pcc controller), why would it be able to send it now in the PRACK? On the UAS side, if there is an scenario (I do not know of any) where the UAS can send an answer, but not an offer, it would not work with plain SIP (INVITE-200 OK-ACK). Therefore, you would be defining a mechanism that would only work with certain extensions. Best regards, Gonzalo Hisham Khartabil wrote: > > Well, I don't have a specific scenario, just the general one where I invite > you and say "lets do something, what do you have", you send a 1xx saying > "ok, but you let me first what you have". > > I just questioned it because the restrictions in section 13.2.1 prohibit > such scenario and I was wondering why should it be prohibited. > > Regards, > Hisham > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Gonzalo > > Camarillo > > Sent: Tuesday, 12 February 2002 6:29 PM > > To: Hisham Khartabil > > Cc: sip@ietf.org; jdrosen@dynamicsoft.com > > Subject: Re: [Sip] PRACK holding the offer > > > > > > Hi, > > > > So far we have assumed that if you do not send an offer in the INVITE it > > is because you wait for an offer from the UAS. > > > > Do you have an scenario where the UAC does not introduce an offer in the > > INVITE but intends to do it later (only if the first 1xx does not > > contain one)?? > > > > Gonzalo > > > > Hisham Khartabil wrote: > > > > > > Hi, > > > > > > Perhaps this has been discussed earlier, but here is goes anyway: > > > > > > What is the harm in a PRACK carrying the SDP offer and the answer being > > > carried in the 200OK for PRACK or even in the 200OK for the > > initial INVITE? > > > > > > INVITE (no SDP) > > > -------------------> > > > > > > 1xx (no SDP) 100rel > > > <------------------ > > > > > > PRACK (SDP) > > > -------------------> > > > > > > 200 (SDP) for PRACK > > > <------------------ > > > > > > OR > > > 200 (SDP) for INVITE > > > <------------------ > > > > > > 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 > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.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 -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Tue Feb 12 14:42:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23507 for ; Tue, 12 Feb 2002 14:42:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10753 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 14:42:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08930; Tue, 12 Feb 2002 14:03:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08896 for ; Tue, 12 Feb 2002 14:03:13 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22103 for ; Tue, 12 Feb 2002 14:03:09 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1CJ2dJ15685 for ; Tue, 12 Feb 2002 14:02:40 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K496P0Q>; Tue, 12 Feb 2002 19:02:39 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E8F6@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@ietf.org'" Date: Tue, 12 Feb 2002 19:02:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Sip] bis-07 comment: Min-Expires header nit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The current text of section 24.23 specifies: 24.23 Min-Expires The Min-Expires header field conveys the minimum registration expiration interval to a registrar. The header field contains a decimal integer number of seconds. The use of the header field in a 423 (Registration Too Brief) response is described in Sections 10.2.8, 10.3, and 25.4.17. As this header is only included in a response, then surely the 1st sentence of the text should say something like ...from a registrar... Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: 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 From daemon@optimus.ietf.org Tue Feb 12 14:46:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23722 for ; Tue, 12 Feb 2002 14:46:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10832 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 14:46:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09521; Tue, 12 Feb 2002 14:13:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09490 for ; Tue, 12 Feb 2002 14:13:54 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22583 for ; Tue, 12 Feb 2002 14:13:52 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1CJDMJ19488 for ; Tue, 12 Feb 2002 14:13:23 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K496QGA>; Tue, 12 Feb 2002 19:13:22 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E8F7@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@ietf.org'" Subject: RE: [Sip] bis-07 comment: Min-Expires header nit Date: Tue, 12 Feb 2002 19:13:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Further to the comment below, in the table in the bis-07 draft, I note that the Min-Expires header is optional a 423 response to REGISTER, and in the events-02 draft, it is mandatory in 423 response to SUBSCRIBE. I believe it should be the same in both drafts. I believe the bis draft is correct and the events draft incorrect, as the status-code in the response can convey meaning even in the absence of the header. However I am looking for consistency. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Drage, Keith (Keith)[SMTP:drage@lucent.com] > Sent: 12 February 2002 19:02 > To: 'sip@ietf.org' > Subject: [Sip] bis-07 comment: Min-Expires header nit > > The current text of section 24.23 specifies: > > 24.23 Min-Expires > > The Min-Expires header field conveys the minimum > registration expiration interval to a registrar. The header field contains > a > decimal integer number of seconds. The use of the header field in a 423 > (Registration Too Brief) response is described in Sections 10.2.8, 10.3, > and > 25.4.17. > > As this header is only included in a response, then surely the 1st > sentence > of the text should say something like > > > ...from a registrar... > > Keith > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: 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 daemon@optimus.ietf.org Tue Feb 12 15:41:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23506 for ; Tue, 12 Feb 2002 14:42:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10752 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 14:42:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09062; Tue, 12 Feb 2002 14:05:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09033 for ; Tue, 12 Feb 2002 14:05:54 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22165 for ; Tue, 12 Feb 2002 14:05:52 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g1CJ5l710565; Tue, 12 Feb 2002 14:05:47 -0500 Message-Id: <200202121905.g1CJ5l710565@minotaur.nge.isi.edu> To: "Peterson, Jon" cc: "'sip@ietf.org'" , sob@harvard.edu Reply-To: mankin@isi.edu Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-reply-to: Your message of Tue, 12 Feb 2002 05:21:01 -0600. <70565611B164D511957A001083FCDD56CAAF11@VA02> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Tue, 12 Feb 2002 14:05:47 -0500 From: Allison Mankin Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jon, One thing that was lacking in your sips proposal was a motivation that reflect the fact that security evaluation (part of the ongoing AD review of bis) resulted in a push on the editors for something like sips. The reviews identified that enabling TLS through NAPTR and the SIP URI transport parameter did not provide reference integrity for TLS use. This led to a request for development of additional mechanism. The editors' process here is similar to responding to IETF Last Call, AD review, and IESG review comments, when these require changes, except that normally such changes are requested well after IETF Last Call has concluded. The Chairs and I are collaborating to try to ensure that AD and IESG comments/issues are expressed and handled earlier than normal, because of the 3GPP deadline. (We also hope that the strong efforts by this WG to review *everything* means that IETF Last Call has few or no surprises). WG scrutiny is called for, but it should not surprise the WG to see holes identified and proposals made for filling them, even now. Note that the process would be different if the spec was going to Draft Standard at this time. Allison Mankin IESG Area Director for 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 daemon@optimus.ietf.org Tue Feb 12 18:38:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00766 for ; Tue, 12 Feb 2002 18:38:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA20786 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 18:38:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19855; Tue, 12 Feb 2002 18:13:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19823 for ; Tue, 12 Feb 2002 18:13:07 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00435 for ; Tue, 12 Feb 2002 18:13:04 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.136]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1CNDJ6Y028598 for ; Tue, 12 Feb 2002 18:13:19 -0500 (EST) Message-ID: <3C69A161.53BF19A5@dynamicsoft.com> Date: Tue, 12 Feb 2002 18:12:33 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] removal of 100rel from bis Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It was out. Then it was in. Now it is going to be out again. The section on reliability of provisional responses is going to be removed from bis-08. The reasons have very little to do with technology. Rather, it is in the interests of maintaining bis as an open and clean specification as it has always been; something that people can implement without obstacles. There will be no change in the specifications, only in which documents they appear in. draft-ietf-sip-100rel will come back to life, and go to RFC along with bis and the other key drafts. Furthermore, the last call on 100rel will extend backwards in time, starting with the last call of bis. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Tue Feb 12 18:59:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01153 for ; Tue, 12 Feb 2002 18:59:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA21197 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 18:59:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20743; Tue, 12 Feb 2002 18:36:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20707 for ; Tue, 12 Feb 2002 18:36:56 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00743 for ; Tue, 12 Feb 2002 18:36:53 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id XAA00288; Tue, 12 Feb 2002 23:33:34 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id XAA27084; Tue, 12 Feb 2002 23:36:54 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <1J3XACH9>; Tue, 12 Feb 2002 16:36:54 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B371E2@n0214idc1.oss.level3.com> To: jdrosen@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] removal of 100rel from bis Date: Tue, 12 Feb 2002 16:36:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hmm. There was a fair amount of related text sprinkled throughout bis. Will there be any changes to the schedule for a WGLC for bis08, or are we having faith things will be cleaned up properly? > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, February 12, 2002 4:13 PM > To: sip@ietf.org > Subject: [Sip] removal of 100rel from bis > > > It was out. Then it was in. Now it is going to be out again. > > The section on reliability of provisional responses is going to be > removed from bis-08. The reasons have very little to do with > technology. > Rather, it is in the interests of maintaining bis as an open and clean > specification as it has always been; something that people > can implement > without obstacles. > > There will be no change in the specifications, only in which documents > they > appear in. draft-ietf-sip-100rel will come back to life, and go to RFC > along > with bis and the other key drafts. Furthermore, the last call > on 100rel > will > extend backwards in time, starting with the last call of bis. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 daemon@optimus.ietf.org Tue Feb 12 23:33:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08081 for ; Tue, 12 Feb 2002 23:33:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA01982 for sip-archive@odin.ietf.org; Tue, 12 Feb 2002 23:33:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA00508; Tue, 12 Feb 2002 22:58:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA00482 for ; Tue, 12 Feb 2002 22:58:28 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07138 for ; Tue, 12 Feb 2002 22:58:24 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1D3wa6Y028953; Tue, 12 Feb 2002 22:58:37 -0500 (EST) Message-ID: <3C69E43A.E9B01DD5@dynamicsoft.com> Date: Tue, 12 Feb 2002 22:57:46 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John.Hearty@Level3.com CC: sip@ietf.org Subject: Re: [Sip] removal of 100rel from bis References: <17052388D394D411803900508BDFFAF601B371E2@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit John.Hearty@Level3.com wrote: > > Hmm. There was a fair amount of related text sprinkled throughout bis. > Will there be any changes to the schedule for a WGLC for bis08, or are > we > having faith things will be cleaned up properly? With lots of coffee and lots of faith, it will be done in time. Time does not allow for any slack in the wglc schedule. -Jonathan R. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, February 12, 2002 4:13 PM > > To: sip@ietf.org > > Subject: [Sip] removal of 100rel from bis > > > > > > It was out. Then it was in. Now it is going to be out again. > > > > The section on reliability of provisional responses is going to be > > removed from bis-08. The reasons have very little to do with > > technology. > > Rather, it is in the interests of maintaining bis as an open and clean > > specification as it has always been; something that people > > can implement > > without obstacles. > > > > There will be no change in the specifications, only in which documents > > they > > appear in. draft-ietf-sip-100rel will come back to life, and go to RFC > > along > > with bis and the other key drafts. Furthermore, the last call > > on 100rel > > will > > extend backwards in time, starting with the last call of bis. > > > > Thanks, > > Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PH: (973) 952-5000 > > http://www.dynamicsoft.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. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 01:05:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11412 for ; Wed, 13 Feb 2002 01:05:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA07232 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 01:05:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA04983; Wed, 13 Feb 2002 00:44:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA04952 for ; Wed, 13 Feb 2002 00:44:42 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10761 for ; Wed, 13 Feb 2002 00:44:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1D5is6Y029023; Wed, 13 Feb 2002 00:44:55 -0500 (EST) Message-ID: <3C69FD28.C8E61373@dynamicsoft.com> Date: Wed, 13 Feb 2002 00:44:08 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'sip@ietf.org'" Subject: Re: [Sip] bis-07 comment: Min-Expires header nit References: <475FF955A05DD411980D00508B6D5FB00439E8F6@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline: "Drage, Keith (Keith)" wrote: > > The current text of section 24.23 specifies: > > 24.23 Min-Expires > > The Min-Expires header field conveys the minimum > registration expiration interval to a registrar. The header field > contains a > decimal integer number of seconds. The use of the header field in a 423 > (Registration Too Brief) response is described in Sections 10.2.8, 10.3, > and > 25.4.17. > > As this header is only included in a response, then surely the 1st > sentence > of the text should say something like > > ...from a registrar... This text has already been reworded to allow reuse of this error code for sip-events. The above text is too registrar specific. The new text reads: The \header{Min-Expires} header field conveys the minimum refresh interval supported for soft-state elements managed by that server. This includes \header{Contact} headers that are stored by a registrar. The header field contains a decimal integer number of seconds from 0 to (2**32)-1. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 01:08:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11480 for ; Wed, 13 Feb 2002 01:08:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA10021 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 01:08:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA05164; Wed, 13 Feb 2002 00:48:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA05132 for ; Wed, 13 Feb 2002 00:48:41 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10873 for ; Wed, 13 Feb 2002 00:48:38 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1D5mr6Y029026; Wed, 13 Feb 2002 00:48:53 -0500 (EST) Message-ID: <3C69FE16.5E0F32A7@dynamicsoft.com> Date: Wed, 13 Feb 2002 00:48:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'sip@ietf.org'" Subject: Re: [Sip] bis-07 comment: Min-Expires header nit References: <475FF955A05DD411980D00508B6D5FB00439E8F7@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Drage, Keith (Keith)" wrote: > > Further to the comment below, in the table in the bis-07 draft, I note > that > the Min-Expires header is optional a 423 response to REGISTER, and in > the > events-02 draft, it is mandatory in 423 response to SUBSCRIBE. > > I believe it should be the same in both drafts. Agreed. However, as far as I can tell, its mandatory in the 423 to REGISTER according to bis-07. Are you sure you were reading the right row? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 01:11:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11642 for ; Wed, 13 Feb 2002 01:11:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA13222 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 01:11:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA05313; Wed, 13 Feb 2002 00:51:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA05190 for ; Wed, 13 Feb 2002 00:51:01 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10946 for ; Wed, 13 Feb 2002 00:50:59 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1D5pF6Y029029; Wed, 13 Feb 2002 00:51:16 -0500 (EST) Message-ID: <3C69FEA4.FB9F05AD@dynamicsoft.com> Date: Wed, 13 Feb 2002 00:50:28 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brazier Lachlan CC: "'sip@ietf.org'" Subject: Re: [Sip] Routing examples References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Brazier Lachlan wrote: > > Hello, > > sorry if I missed this in one of the mailing lists. > > In the examples for Proxy Route processing (16.11.1.1 Basic SIP > Trapezoid) > P1 finds P2 resposible for "domain.com". P2 receives the INVITE request, > and inserts a Record-Route (Record-Route: ). > > Wouldn't the Record-Route header be: Record-Route: > > Did I miss something with DNS or a chapter in the draft? The only requirement is that the record-route URI route back to that proxy. A DNS lookup of domain.com probably would point to a bunch of servers in a cluster, and thus may not route back to that specific proxy. So, the proxy has inserted a FQDN for the specific host it is running on, in this case, p2.domain.com, which has an A record only. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 01:16:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11782 for ; Wed, 13 Feb 2002 01:16:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA15515 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 01:16:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA05434; Wed, 13 Feb 2002 00:53:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA05405 for ; Wed, 13 Feb 2002 00:53:40 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11011 for ; Wed, 13 Feb 2002 00:53:32 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1D5rl6Y029032; Wed, 13 Feb 2002 00:53:47 -0500 (EST) Message-ID: <3C69FF3C.21E2818@dynamicsoft.com> Date: Wed, 13 Feb 2002 00:53:00 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Hisham Khartabil , sip@ietf.org Subject: Re: [Sip] PRACK holding the offer References: <3C696389.B6B9EAEE@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree with Gonzalo on all points. To further his reasoning, with this proposal, a UAS would not know whether it needs to make the offer, or whether the UAC will offer it later. This will require additional signaling from UAC to UAS to say "even though I am not sending the offer in invite, i will send it later". More needless signaling and complexity. -Jonathan R. Gonzalo Camarillo wrote: > > Hi, > > A reson for not allowing this exchange is that it would complicate the > glare prevention mechanisms (if the UAS sends an offer in a 1xx and the > UAC is sending at the same time an offer in an UPDATE we will have a > collision). > > But I believe you are thinking of only using the PRACK to a 1xx to send > the offer from the UAC. In my opinion this increases the complexity of > the protocol for no real gain. > > If the UAC can send an offer in the first place, it will send it it the > INVITE. If it could not send the offer in the INVITE (maybe because it > is a 3pcc controller), why would it be able to send it now in the PRACK? > > On the UAS side, if there is an scenario (I do not know of any) where > the UAS can send an answer, but not an offer, it would not work with > plain SIP (INVITE-200 OK-ACK). Therefore, you would be defining a > mechanism that would only work with certain extensions. > > Best regards, > > Gonzalo > > Hisham Khartabil wrote: > > > > Well, I don't have a specific scenario, just the general one where I > invite > > you and say "lets do something, what do you have", you send a 1xx > saying > > "ok, but you let me first what you have". > > > > I just questioned it because the restrictions in section 13.2.1 > prohibit > > such scenario and I was wondering why should it be prohibited. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Gonzalo > > > Camarillo > > > Sent: Tuesday, 12 February 2002 6:29 PM > > > To: Hisham Khartabil > > > Cc: sip@ietf.org; jdrosen@dynamicsoft.com > > > Subject: Re: [Sip] PRACK holding the offer > > > > > > > > > Hi, > > > > > > So far we have assumed that if you do not send an offer in the > INVITE it > > > is because you wait for an offer from the UAS. > > > > > > Do you have an scenario where the UAC does not introduce an offer in > the > > > INVITE but intends to do it later (only if the first 1xx does not > > > contain one)?? > > > > > > Gonzalo > > > > > > Hisham Khartabil wrote: > > > > > > > > Hi, > > > > > > > > Perhaps this has been discussed earlier, but here is goes anyway: > > > > > > > > What is the harm in a PRACK carrying the SDP offer and the answer > being > > > > carried in the 200OK for PRACK or even in the 200OK for the > > > initial INVITE? > > > > > > > > INVITE (no SDP) > > > > -------------------> > > > > > > > > 1xx (no SDP) 100rel > > > > <------------------ > > > > > > > > PRACK (SDP) > > > > -------------------> > > > > > > > > 200 (SDP) for PRACK > > > > <------------------ > > > > > > > > OR > > > > 200 (SDP) for INVITE > > > > <------------------ > > > > > > > > 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 > > > > > > -- > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > Columbia University Mobile: +358 40 702 35 35 > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > New York, NY 10027 > > > USA Gonzalo.Camarillo@ericsson.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 > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 01:35:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12312 for ; Wed, 13 Feb 2002 01:35:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA16372 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 01:35:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15614; Wed, 13 Feb 2002 01:18:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15582 for ; Wed, 13 Feb 2002 01:18:50 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11864 for ; Wed, 13 Feb 2002 01:18:47 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1D6J36Y029091; Wed, 13 Feb 2002 01:19:03 -0500 (EST) Message-ID: <3C6A0528.FA8F4659@dynamicsoft.com> Date: Wed, 13 Feb 2002 01:18:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: Re: [Sip] tsvchange and Supported/Require, was: [Sip] Last Call comments on 2543bis-07 References: <200202121337.IAA20420@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > > The text that I am objecting to here first appeared in the bis rewrite > (bis-05). If it was preceeded by any list discussion leading to a > consensus that it should be included, then I missed it. I've been > objecting regularly ever since the text in bis-05 appeared. As I have said, this text was the result of discussions with IESG, who requested its inclusion in the specification. The words you are reading were carefully reviewed and scrutinized. It is frequent for changes in documents to be based on IESG feedback. > > The discussion last week concluded, I believe, that IANA registration > of header names and option tags, combined with text regarding formats > and discussion to appear in the extension guidelines draft, was > sufficient. No reference to tsvarea-sipchange was needed. Agreed. > There are a number of "facts" that I don't think need any discussion. > Some of these are 1) Carriers will be obliged to meet regulatory > requirements, and 2) Some regulatory requirements will not be > standardized by IETF. As I stated before, it is an ugly subject. > > So assume there is an implementation of a protocol that starts with > SIP and adds extensions necessary to meet the regulatory requirements > on carriers. IETF then publically states that it is not compliant > to SIP. Then the decision comes down from high that SIP can't meet > the service requirements, so pick a standard protocol that can. > And then the whole network architecture is changed. Bill, these are FUD arguments, very similar to ones I have heard in the past to push other drafts that I shall not name. I am honestly quite tired at this point of these kinds of "do as I say or we will use something else" arguments, as they are nothing more than veiled threats. Please keep them to yourself. First off, no one ever said that IETF can't or won't work on extensions for meeting regulatory requirements. Things like 911 are of much interest to people here, and are being worked on. Perhaps you refer to raven, where the decision was that IETF won't work on legal intercept. It remains totally unclear to me that any extensions are needed to support these kinds of functions. People are already using b2bua and media intermediaries for this as you well know. While I may dislike such things, they are within the realm of the specifications to build them. So, what exactly ARE you talking about? Let us, for the moment, entertain the notion that there is some extension which cannot be done at IETF, and which is useful for some kind of service mandated by regulatory requirements. Fine. A SIP implementation that uses them is still SIP compliant. The problem only arises if the client INSISTS that the network or endpoints provide this service, or vice-a-versa. It is not clear to me at all that any such extension would be built such that a client or server HAD to implement it in order to provide service to another sip element. > If the additional headers were added based on IANA registration, > but an option tag were not, then the problem becomes one of system > reliability. As I stated above, double-checks like the header-optiontag > are the tools to get to 5 9's. Give up on the reliability goal? I > doubt it. Are you honestly trying to tell me, that using an extension without a Require/Supported tag, won't allow us to get to 5 nines of reliability? On what concrete technical grounds could you conceivably make such a claim? I anxiously wait the numerical analysis. Sounds like more FUD to me - "uh oh, SIP can't do five nines!". > > While I agree there is a problem that allows abuse by the unnamed > large vendor, the solution proposed in bis-05 has other unintended > side-effects. The only solution I can see is to allow these > non-standards-track extensions, and try again at the general problem. I am in favor of keeping the text as it stands. To further the point, it is my understanding that IESG still feels that the words that are there are needed, even in the presence of some IANA registration mechanism for headers. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 01:39:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12414 for ; Wed, 13 Feb 2002 01:39:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA16482 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 01:39:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15766; Wed, 13 Feb 2002 01:25:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15735 for ; Wed, 13 Feb 2002 01:25:38 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12044 for ; Wed, 13 Feb 2002 01:25:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1D6Pm6Y029097; Wed, 13 Feb 2002 01:25:48 -0500 (EST) Message-ID: <3C6A06BA.944C0E9C@dynamicsoft.com> Date: Wed, 13 Feb 2002 01:24:58 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mankin@isi.edu CC: "Peterson, Jon" , "'sip@ietf.org'" , sob@harvard.edu Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: <200202121905.g1CJ5l710565@minotaur.nge.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'll also add that the editors have been doing everything we can to get these kinds of changes and feedback posted to the list ASAP for broader comment. This item in particular came up only in the past few days, and was brought to the list even before consensus amongst the editors was reached, in order to get maximum air time with the group. Thanks, Jonathan R. Allison Mankin wrote: > > Jon, > > One thing that was lacking in your sips proposal was a > motivation that reflect the fact that security evaluation > (part of the ongoing AD review of bis) resulted in a push on > the editors for something like sips. The reviews identified > that enabling TLS through NAPTR and the SIP URI transport parameter > did not provide reference integrity for TLS use. This led > to a request for development of additional mechanism. > > The editors' process here is similar to responding to IETF Last > Call, AD review, and IESG review comments, when these require > changes, except that normally such changes are requested well after > IETF Last Call has concluded. The Chairs and I are collaborating > to try to ensure that AD and IESG comments/issues are expressed > and handled earlier than normal, because of the 3GPP deadline. > (We also hope that the strong efforts by this WG to review > *everything* means that IETF Last Call has few or no surprises). > > WG scrutiny is called for, but it should not surprise the > WG to see holes identified and proposals made for filling them, > even now. Note that the process would be different if the > spec was going to Draft Standard at this time. > > Allison Mankin > IESG Area Director for 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. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 03:08:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22601 for ; Wed, 13 Feb 2002 03:08:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA19893 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 03:08:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18879; Wed, 13 Feb 2002 02:53:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18846 for ; Wed, 13 Feb 2002 02:53:14 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22073 for ; Wed, 13 Feb 2002 02:53:12 -0500 (EST) Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062402; Tue, 12 Feb 2002 18:29:59 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: In-Reply-To: <000001c1b3e8$115f7e20$fae023a6@hsinnreich2> References: <000001c1b3e8$115f7e20$fae023a6@hsinnreich2> Date: Tue, 12 Feb 2002 18:29:56 +0000 To: Henry Sinnreich , "'Michael Thomas'" , "'Peterson, Jon'" From: Lawrence Conroy Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?) Cc: sip@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 11:09 am -0600 12/2/02, Henry Sinnreich wrote: >I agree with: > >> Is there no concept of feature freeze? The amount of >> things being added that have had next to no scrutiny >> is mind boggling. > >Though it is an interesting proposition for some next phase. >Let's focus and execute what we have now on the plate. > >Thanks, Henry > Hi Folks, I understand the concerns/frustrations. However, Sean suggests that initial work consists ONLY of deprecating ";transport=tls". AFAIK, that's all that needs to be done in the bis WGLC. (this is not so much adding yet another thing as removing a carbuncle :). The introduction of a new URL scheme looks good to me. I don't understand why it's a "core" bis issue and could give people (more) ulcers - it's a new scheme, not "sip:", so I would have thought that this is ideal for a further draft, using bis as its reference. Hence I'm confused at the strong reaction. Does even its own mother love ";transport=tls"? If the proposal is to lose this, I'll second that as I've never liked the overloading (and a future sips: doc appears to do all it could be expected to achieve, and more). best regards, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 13 05:48:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26448 for ; Wed, 13 Feb 2002 05:48:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA26606 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 05:48:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25372; Wed, 13 Feb 2002 05:25:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25341 for ; Wed, 13 Feb 2002 05:25:27 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25806 for ; Wed, 13 Feb 2002 05:25:19 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1DAPLK24418 for ; Wed, 13 Feb 2002 05:25:21 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K4966Q3>; Wed, 13 Feb 2002 10:25:20 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E8FC@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org, "'Jonathan Rosenberg'" Subject: RE: [Sip] removal of 100rel from bis Date: Wed, 13 Feb 2002 10:25:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org NO!!! NO!!! NO!!! I am frantically trying to juggle related 3GPP documentation and all I see here is a ploy to further derail manyfolks. I see nothing below which justifies taking it back out of bis. Furthermore, the additional delay of 100 rel that thus results is unacceptable. It went into WGLC in bis and nobody is raising technical objections via the list, which is what should be happening if this change is justified. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > Sent: 12 February 2002 23:12 > To: sip@ietf.org > Subject: [Sip] removal of 100rel from bis > > It was out. Then it was in. Now it is going to be out again. > > The section on reliability of provisional responses is going to be > removed from bis-08. The reasons have very little to do with technology. > Rather, it is in the interests of maintaining bis as an open and clean > specification as it has always been; something that people can implement > without obstacles. > > There will be no change in the specifications, only in which documents > they > appear in. draft-ietf-sip-100rel will come back to life, and go to RFC > along > with bis and the other key drafts. Furthermore, the last call on 100rel > will > extend backwards in time, starting with the last call of bis. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 05:52:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26580 for ; Wed, 13 Feb 2002 05:52:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA26776 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 05:52:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25658; Wed, 13 Feb 2002 05:30:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25610 for ; Wed, 13 Feb 2002 05:30:09 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25947 for ; Wed, 13 Feb 2002 05:30:05 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1DAU6K25999 for ; Wed, 13 Feb 2002 05:30:07 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K4966YV>; Wed, 13 Feb 2002 10:30:06 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E8FD@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Drage, Keith (Keith)" , "'Jonathan Rosenberg'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] bis-07 comment: Min-Expires header nit Date: Wed, 13 Feb 2002 10:30:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org True, I am off to replace my glasses. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > Sent: 13 February 2002 5:48 > To: Drage, Keith (Keith) > Cc: 'sip@ietf.org' > Subject: Re: [Sip] bis-07 comment: Min-Expires header nit > > > > "Drage, Keith (Keith)" wrote: > > > > Further to the comment below, in the table in the bis-07 draft, I note > > that > > the Min-Expires header is optional a 423 response to REGISTER, and in > > the > > events-02 draft, it is mandatory in 423 response to SUBSCRIBE. > > > > I believe it should be the same in both drafts. > > Agreed. However, as far as I can tell, its mandatory in the 423 to > REGISTER according to bis-07. Are you sure you were reading the right > row? > > Thanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 05:57:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26739 for ; Wed, 13 Feb 2002 05:57:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA26940 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 05:57:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25930; Wed, 13 Feb 2002 05:30:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25904 for ; Wed, 13 Feb 2002 05:30:54 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25963 for ; Wed, 13 Feb 2002 05:30:50 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1DAUqK26218 for ; Wed, 13 Feb 2002 05:30:52 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K4966ZV>; Wed, 13 Feb 2002 10:30:51 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E8FE@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Drage, Keith (Keith)" , "'Jonathan Rosenberg'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] bis-07 comment: Min-Expires header nit Date: Wed, 13 Feb 2002 10:30:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The new text fixes my problem, in that it gets rid of the "to". Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > Sent: 13 February 2002 5:44 > To: Drage, Keith (Keith) > Cc: 'sip@ietf.org' > Subject: Re: [Sip] bis-07 comment: Min-Expires header nit > > inline: > > "Drage, Keith (Keith)" wrote: > > > > The current text of section 24.23 specifies: > > > > 24.23 Min-Expires > > > > The Min-Expires header field conveys the minimum > > registration expiration interval to a registrar. The header field > > contains a > > decimal integer number of seconds. The use of the header field in a 423 > > (Registration Too Brief) response is described in Sections 10.2.8, 10.3, > > and > > 25.4.17. > > > > As this header is only included in a response, then surely the 1st > > sentence > > of the text should say something like > > > > ...from a registrar... > > This text has already been reworded to allow reuse of this error code > for sip-events. The above text is too registrar specific. The new text > reads: > > The \header{Min-Expires} header field conveys the minimum refresh > interval > supported for soft-state elements managed by that server. This > includes \header{Contact} headers that are stored by a registrar. The > header > field contains a decimal > integer number of seconds from 0 to (2**32)-1. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 08:40:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01254 for ; Wed, 13 Feb 2002 08:40:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03945 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 08:40:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02556; Wed, 13 Feb 2002 08:14:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02518 for ; Wed, 13 Feb 2002 08:14:24 -0500 (EST) Received: from mailhost.wellx.com (mailhost.wellx.com [62.161.157.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00501 for ; Wed, 13 Feb 2002 08:14:19 -0500 (EST) Received: from mail.wellx.com by mailhost.wellx.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 13 Feb 2002 13:09:29 UT Received: from wellx.com (SIP [192.168.1.114]) by srvwellx.wellx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CVPQA2NJ; Wed, 13 Feb 2002 14:08:57 +0100 Message-ID: <3C6A68CA.E18582CF@wellx.com> Date: Wed, 13 Feb 2002 14:23:22 +0100 From: Aymeric MOIZARD Organization: WellX X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "'sip@ietf.org'" References: <475FF955A05DD411980D00508B6D5FB00439E8FE@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] route refresh request goal? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit my question concerns the route refresh mechanism. This is located in bis-07 in 12.2 Requests within a Dialog For a UAS: "Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI." So requests which are route refresh requests do not update the Route set! For a UAC: "When a UAC recieves a 2xx response to a route refresh resquest, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present." So requests which are route refresh requests do not update the Route set! Back to the Global defintion of route refresh request: "A route refresh request sent within a dialog is defined as a request that can modify the route set of the dialog." I do not understand why those method are named "route refresh request"? In either cases (UAC or UAS), those requests can only modify the remote target URI. As far as I understand, those requests should be named "remote target refresh request"! Did I miss something? Is there any cases where the route set COULD/MUST be modified? Thanks Aymeric _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 13 10:30:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07561 for ; Wed, 13 Feb 2002 10:30:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09956 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 10:30:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08583; Wed, 13 Feb 2002 10:00:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08461 for ; Wed, 13 Feb 2002 10:00:25 -0500 (EST) Received: from imo-r08.mx.aol.com (imo-r08.mx.aol.com [152.163.225.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05878 for ; Wed, 13 Feb 2002 10:00:23 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r08.mx.aol.com (mail_out_v32.5.) id d.107.ce77833 (15902); Wed, 13 Feb 2002 09:59:42 -0500 (EST) Received: from web29.aolmail.aol.com (web29.aolmail.aol.com [205.188.222.5]) by air-id09.mx.aol.com (v83.35) with ESMTP id MAILINID95-0213095942; Wed, 13 Feb 2002 09:59:42 -0500 Date: Wed, 13 Feb 2002 09:59:41 EST Subject: Re: SIP Spam Prevention (was Re: [Sip] calling number blocking at sip/isup ga... To: , Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Message-ID: <107.ce77833.299bd95e@aol.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean, Sorry it took me so long to reply. Hope the copy of previous e-mail exchange isn't confusing, since the way I am replying did not add carrots. I inserted who said it in []. Thanks for the long, heart-felt response. No, I don't see your response as being "ranting" and I couldn't survive this type of work if I didn't keep a little humour with it. And I appreciate people who don't hold back on their ideas. I think your comments, and your apparent view of what is important, emphasizes my main point that there are two different applications, or environments, in which SIP will be used to provide a telephony over IP capability. I represent an organization which is interested in using it in a large network to potentially replace the existing circuit-switched network (as standardized by ITU, etc.) You speak of an environment in which there is really no "telephony network", at least not in the traditional sense. Calls are set up from anywhere to anywhere ("arbitrary end-points") with no overall control by a "service provider". Yes, I agree that there is a place for such a non-network environment. But I am trying to address the other environment. Also, there have been many opinions expressed that the desire is for the existing circuit-switched PSTN to be completely replaced with a packet-based network using SIP. I believe that, in order for this to happen, the current operation and requirements of the telephony network, including those mandated by state/federal laws, must be taken into account. Yes, I realize that the IETF is not the ITU. (I'm at SG16 right now.) I believe that each organization has its advantages and disadvantages in its working procedures, but that is not the issue here. In the past, they dealt with competely different environments and networks. Now, both are trying to deal with the other's traditional network, and must take into account the realities of that other environment. RFC 2804 is interesting reading, especially the part about how this policy (on not dealing with wire-tapping) was established. It says: "Twenty-nine people spoke during the plenary session. ... Very few people spoke out strongly in support for adding the intercept features, while many spoke out against it, but a sizable portion of the audience refused to state an opinion (raised their hands when asked for "abstain" in the show of hands)." Given the prevailing attitude in the IETF, can you image someone standing up in front of hundreds of participants and saying "I think this group should actively work on protocols to support wiretapping"? I can't. I wonder how many of those who didn't express an opinion represent companies whose official position is that they must support development of protocols for wire-tapping. Anyway, I was not suggesting that the IETF should develop the protocols fpr this, only that other protocols developed should not make support of electronic surveillance impossible. Note that RFC 2804 says that the reasons for adopting this policy include: "the use of existing network features, if deployed intelligently, provides extensive opportunities for wiretapping, and should be sufficient under presently seen requirements for many cases." and "Correlating users' identities with their points of attachment to the Internet can be significantly harder, but not impossible, if the user uses standard means of identification. However, this means linking into multiple Internet subsystems used for address assignment, name resolution and so on; this is not trivial." It seems to me that this reason for not addressing wire-tapping would no longer be true if SIP (and the network architecture) allows users to originate telephone calls with no identification. In fact, other required functions such as call tracing and maintenance also require the same, authenticated calling party identification capabilities. (Incidentally, the IETF "policy" means little if the laws of the country mandate certain capabilities be supported as a criteria for providing service. Note Juha's e-mail of Jan 29.) I understand your description of what happens if I try to set up a session to your SIP address and it's forwarded to your cell phone via the PSTN. But what you are doing doesn't constitute a "service provider" in the sense of what I am referring to. It's a simple call-forwarding function at the destination (of the IP portion). When you interwork to the PSTN to complete the call, then the PSTN's originating switch is the service provider and knows your identity (the ISDN line you use). Of course, it doesn't know or care about the identity of the first part of the call (the one to your SIP address). Yes, the bad guy may use such a service to make anonymous calls, but as soon as that is discovered, you, as the one who is providing the forwarding service could be required to support further identification of the original source of the call. I agree that the verification between the end user and their "service provider" (SIP proxy) would use some "crypto" function. (I don't really call this "crypto" but rather a signing function.) Yes, in some environments VeriSign's certificate could be used, but other means exist depending on the nature of the local network. It's between the end party and their service provider. The point I'm making is that in the world-wide telephony network, the ability to believe that the calling party number delivered at the destination is legitimate should not involve such a crypto or signing function between the called party and the originating party or some agent representing the originating party. I have a hard time believing that this can occur in the time required for call set up. Your example of doing stock trades with Schwab is not one of using the calling party ID that we have been discussing. It presumes that some previous business relationship exists between you and Schwab, including the establishment of a shared secret. They don't care that the call was made from your phone, they want to know it's really you, no mater what phone you're using. On the other hand, the calling party identification we're talking about must be between any two phones in the network (the whole world?). I don't open e-mail if I don't recognize the "from" or the subject. I accepted and opened your e-mail based on some level of trust that what came to me had a legitimate "from" address. Yes, I realize that the e-mail you sent me could have been faked and really be from someone else. I want a telephony network in which the called party can trust the calling party ID delivered to them (because they trust their own proxy or "service provider"). In a message dated 2/1/02 8:34:45 PM Eastern Standard Time, dean.willis@softarmor.com writes: Warning! This response contains philosophical ranting. Please take a large dose of humour supplement to help ease the pain. ----- Original Message ----- From: > Dean mumbled: > > Ah. In the case I referenced, there WAS no service provider originating the > > call. It was produced by a SIP UA on the Internet. From that point of view, > > every PC is a service provider . . . > [Mike] > Interesting, but this points out the basic difference in network > architectures that we are addressing. You talk as if the telephone call > originates out of nowhere, like some Spam seems to today. I am talking of a > network architecture view in which every telephone call must begin and end > under control of a "service provider". (And that doesn't mean a provider with > a physical netwok like today's telephone companies.) In this network > architecture, all the privacy issues (calling party ID, called party ID, > names, etc.) are dealt with by the choosen service provider. (You don't get > service from someone you don't trust, nor do they provide service to someone > if they don't have a way to verify who is trying to originate a call.) And at > the same time, the legal invasions of privacy, to support wire-tapping, would > be dealt with by this same service provider. [Dean] I believe you have us confused with the ITU ;-) . . Mike, this is the INTERNET Engineering Task Force. We're concerned with the Internet -- it's a big packet-switching thing that allows arbitrary communications between arbitrary endpoints. Being a "Service Provider" fundamentally means to take packets from a customer, insert them into the switching fabric, and swish them on their merry way -- or, to take packets from the switching fabric as appropriate and hand them to your customer. Of course, there can be higher-level service providers. VeriSign is a good example of a service provider who provides tools to cope with the issues you raise, without being "Big Brother" and controlling everybody. I should give my speech on the difference between "control" and "service" for you someday . . As for the rest, please see RFC 2804 for the IETF policy on wiretapping and RFC 1984 for the general policy on crypto. Good recreational reads, right up there with the Magna Carta and the Declaration of Independence, which are also probably useful reads for someone with too much background in tradtional telephony. [Mike] > Yes, someone could agree to handle originations of telephone calls from > unknown parties, but I can't imagine these calls ever being allowed to > interwork into the PSTN or into a comercial IP-based telephony service > provider's network. And laws on electronic surveillance will eventually > forbid it anyway. [Dean] Try setting up a session to sip:dwillis@dynamicsoft.com. If I'm not sitting at my desk, said call will be interworked into the PSTN and delivered to my cell phone. Right now, and every day for the past year and a half, except when the phone company broke the ISDN lines for a while. I suppose it could be spammed in a denial-of-service attack, but the last guy to do that is still suffering. Of course, you just just call my cell phone directly from outside the US with the same effect. On the other hand, we are working on triocks to verify that the request you've sent really came from the IP address that's claiming to send it, and barring the Zombie Attacks engendered by flawed Redmondian security systems will probably be adequate for my purposes. [Mike] > > > What bothers me is that we are modeling this on current stuff, and yesterday > > > I got two copies of the new "Party" virus attached to e-mails from > > > "UnknownSender". If we can't stop this in e-mail today, what is the future > > > telephony network going to be like? > > [Dean] > > Absoultely correct. This is why I want cryptographic support for the PID > > header, and transitive vouching techniques thereon. If you get a call whose > > RPID can't be verified, it becomes perfectly legitimate to do something > > nasty to it like forward it to a robot that explains your policy about > > anonymmous calls. Or, you can listen if you want -- some people LIKE to live > > dangerously. > [Mike] > Again, in the network architecture I'm referring to, cryptographic procedures > are not the answer to privacy for calling party ID. Yes, such procedures may > be used by the originating service provider to verify that the calling party > is legitimate, and by the terminating party to determine that the call > attempt comes from their choosen service provider, then these procedures do > not need to be applied to the calling party ID iteself. In an enterprise > network, we may use cryptographic measures between parties in that closed > set, but for the general telephony environment, the end user who receives a > call shouldn't be required to apply cryptographic procedures with the > originator to verify contents of the call setup message. [Dean] You have to do the crypto, either with the originator or with a trusted intermediary who vouches for the originator. Sounds like a service provider opportunity to me. What you're proposing is not really different than the fundamental PKI model -- it's just a question of who does the crypto, and since your "phone" is going to have to do crypto just to recognize the service provider, there's not much of a difference in the scope of the problem. It's all just a big "proxy" business. For example, let's say I want to trade some stocks. I fire up my browser and point it at Schwab. How do I know that it's really the Schwab site responding, and not my ex-wife's attorney trying to figure out where I hid my last 37 cents? Well, Schwab has a cert. It was signed by VeriSign. Thru other channels, I got a copy of VeriSign's cert (Chairman Bill was kind enough to include it with the OS on my office PC, and some guys in Red Hats packaged it up for my house). I use VeriSign's cert to check that my connection with Schwab was signed with Schwab's cert. Transitive trust, right? So why don't we use this approach for everything? Simple, really -- people are too cheap to pay for their own cert, too lazy to deal with it, or to ignorant to care (I suffer from all three). Or they just don't trust Big Guys, and would rather weave their own web of transitive trust with something like PGP, which also tends to run afoul of the "lazy" and "ignorant" set. And very occasionally because the device involved is just a little too small to run the crypto (the threshold is a code size somwhere around 64kB). . . much elided . . . [Mike] > Concerning your comment above that the call may start at any SIP UA on the > Internet (someone's PC). I firmly believe that it will eventually be admitted > that the issues of verification, privacy, service provisioning, accounting, > wiretap, etc. require that every "end user" of SIP have a dedicated SIP proxy > to handle originating and terminating calls. This UA-SIP proxy relationship > must be established when the device is turned on, makes the first call, etc. > Thereafter, all interactions for individual phone calls are between this > trusted SIP proxy and the end-user (SIP UA). The SIP Proxy is then the > service provider (and responsible for all the above functions). I believe > this architecture is beginning to be recognized as required for various > purposes and we can't move forward until it is accepted for all cases. [Dean] Wow. I really hope you're completely wrong in the general case, otherwise I've wasted most of the last twenty years working on the Internet. Especially since I'm my own service provider and run my own proxy and my own PSTN interconnects. I also run my own web server and my own email exchanger and do all sorts of other stuff you would probably expect to reserve for "service providers". Hey, you better reject this email, because it just came from an Unknown Source! Yep, I use service providers, but I choose to do so at a different level than you're proposing, and that's OK, because this is the Internet, not a government-sponsored work camp for the political re-education of people who have expressed libertarian sympathies in a public forum. On the other hand, there IS substance in much of what you're saying. It's just that we hope to offer solutions that don't require fixed "wires", or the virtual equivalent thereof, between the slaves and the masters. In fact, I think most of the community would happily do without the "slaves" and the "masters" as well. And it now being Friday evening, I'm going to go work from the other desk. Good night. -- 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 daemon@optimus.ietf.org Wed Feb 13 11:00:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08677 for ; Wed, 13 Feb 2002 11:00:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12235 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 11:00:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11193; Wed, 13 Feb 2002 10:43:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11168 for ; Wed, 13 Feb 2002 10:43:57 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08118 for ; Wed, 13 Feb 2002 10:43:54 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1DFi96Y029354; Wed, 13 Feb 2002 10:44:13 -0500 (EST) Message-ID: <3C6A8999.51BDBCF3@dynamicsoft.com> Date: Wed, 13 Feb 2002 10:43:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Conroy CC: Henry Sinnreich , "'Michael Thomas'" , "'Peterson, Jon'" , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Lawrence Conroy wrote: > > The introduction of a new URL scheme looks good to me. I don't > understand > why it's a "core" bis issue and could give people (more) ulcers - it's a > new > scheme, not "sip:", so I would have thought that this is ideal for a > further > draft, using bis as its reference. Hence I'm confused at the strong > reaction. > Does even its own mother love ";transport=tls"? It needs to be core, since the baseline sip security mechanism is not viewed as sufficiently good without it. The same argument could have been made for any of the security stuff, smime, for example. It was put into bis for the same reason. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 11:07:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09132 for ; Wed, 13 Feb 2002 11:07:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13137 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 11:07:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10500; Wed, 13 Feb 2002 10:36:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10466 for ; Wed, 13 Feb 2002 10:36:27 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07739 for ; Wed, 13 Feb 2002 10:36:24 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A7F9887000C6; Wed, 13 Feb 2002 10:36:25 -0500 Message-ID: <005a01c1b4a4$17a65ee0$2300000a@acmepacket.com> From: "Bob Penfield" To: Cc: "Jonathan Rosenberg" Date: Wed, 13 Feb 2002 10:35:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] bis-07 comments Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit First I would like to express my appreciation for all the hard work of the editors and the authors. Given the effort required to review this spec, I can barely imagine the immense effort that has gone into producing this document and incorporating the massive amount of comments and last minute changes and features. This spec is truly light-years ahead of the early bis versions in its organization and understandability. It is making the jobs of all of us implementers easier. Thank you. Now that you are sufficiently buttered up (: , here are my comments. I apologize for any repeats. Sec 8.1.1.3: (very minor nit) line 1011 says that the From should not contain FQDNs, but the example at line 1025 has a FQDN. sec 8.1.1.7: line 1070 says CANCEL is an exception to the unique branch id rule. Isn't ACK also an exception? sec 8.1.1.8: line 1103. Should the standard-track RFC rule also apply to Proxy-Require? sec 8.1.3.2: lines 1140-1144. 1xx needs to be an exception to the x00 rule since 100 has many special rules that should not apply to 101-199. sec 12.2.1.1: line 1888. change "and MUST a Route header" to "and MUST add a Route header" sec 12.2: line 1857-1861. If the open issue (#113) of allowing overlapping non-INVITEs is still open, I vote we should allow them. lines 2698-2702 describes Timer C as being a client transaction timer, yet it no longer appears in the INVITE client transaction FSM in figure 5. Is this really a TU timer? Would the removal of 100rel affect this? line 2700 and 2731 (nit) The text indicates the minimum value of Timer C is 181 seconds. Should it be 180? lines 2880-2881. The text should point out that the proxy should send a CANCEL if and when it receives a provisional response on a branch whose client transaction is in the "calling" state. sec 16.7: lines 2889-2890: A little bit more is needed here. Does the proxy generate a 408 upstream? or just silently discard all state? CANCEL can only be sent on branches that received a 1xx. sec 17.1.2.2: lines 3275-3279. What should timer E be set to when entering the "Proceeding" state? T2? sec 19: line 3576. This is the only mention of T3 I could find in the spec. What is it? sec 20.4.0.1 (line 3880) should be 20.4.1. sec 25: line 5440 (really minor nit) in the 4xx class, values in the 42x range have been defined so its not just x80 upwards. line 5610: The startline of the example is not formatted properly change "485 Ambiguous SIP/2.0" to "SIP/2.0 485 Ambiguous" line 5990: response code 409 is listed in Client-Error, but not described in section 25. line 5990: response code 421 is missing from Client-Error. line 5991: response code 513 is missing from Server-Error. sec 28: lines 6047-6050. Does there need to be a provision for the case of an I-D expiring and never becoming an RFC? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.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 daemon@optimus.ietf.org Wed Feb 13 11:25:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10546 for ; Wed, 13 Feb 2002 11:25:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13850 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 11:25:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10845; Wed, 13 Feb 2002 10:41:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10816 for ; Wed, 13 Feb 2002 10:41:19 -0500 (EST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07912 for ; Wed, 13 Feb 2002 10:41:15 -0500 (EST) Received: from jariws1 ([62.248.150.36]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020213154035.EKLP6990.fep07-app.kolumbus.fi@jariws1>; Wed, 13 Feb 2002 17:40:35 +0200 Message-ID: <021901c1b4a4$e096cce0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Peterson, Jon" Cc: References: <70565611B164D511957A001083FCDD56CAAEAB@VA02> Subject: Re: [Sip] Re: SIP and PKI Date: Wed, 13 Feb 2002 17:41:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > - The text says e.g. in 22.3.2.1 something about > > verifying certificates and domain names in them. > > Perhaps we should clarify that this indeed happens through > > some configured root CAs -- such as those which are the > > default in your Netscape, but some roots are needed. > > Okay, we can explicitly say that this entails holding one or more CA root > certificates - that was our intention. I wonder if we should say anything > about CRLs? Don't say anything about CRLs. Or at the most, MAY access ... CRLs don't work well if you happened to have a very large user base. There are also alternative schemes such as OCSP. > > - 22.3.1 sets forth requirements for UAs to verify > > certificates. Why are these a SHOULD, not a MUST? > > I read in 22.3.1 that certificate verification is a MUST for TLS, and a > SHOULD/MAY or S/MIME. The SHOULD/MAY for S/MIME reflects that we expect > self-signed "leap of faith" stuff to be more common than the use of root > certificates. Yes, but we MUST still verify the certs, even if they are verified against our leap-of-faith learned individual "root" certs... > Btw, I will remember to add something somewhere about configuration as one > > - Wouldn't it be sufficient to verify *either* the From > > field against the TLS certs, or the latest via/source > > address? Then the INVITE comes from a known source in > > any case. > > Well, 22.3.2.2 assumes a sort of network in which every administrative > domain that supports SIP has a proxy (acting as a registrar/local > outbound/inbound proxy), and every administrative domain's proxy can reach > every other administrative domain's proxy - although they don't necessarily > have a pre-existing trust relationship. We don't talk too much about these > underlying assumptions because this is, after all, just an example of how > trust relationships could be established. In any event, for this > architecture the From field of each request contains a domain which will > correspond to the hostname of the proxy server from which a request > originates - which should also correspond to the proxy's certificate. The > term 'correspond' here is intentionally a little loose - the proxy's > hostname might be 'sip.atlanta.com', whereas the From field of a request > might be 'sip:alice@atlanta.com'. > > The correspondence of the proxy's domainname and certificate is initially > discussed in the first paragraph of 22.3.2.1. The fact that requests coming > from your administrative domain should probably have From fields > corresponding to your domainname is discussed in 22.3.2.2 - again, this > example architecture doesn't take into account any sort of transit carrier > that requests might need to go through. The topmost Via header would > probably also help the remote proxy to confirm the identity of the local > proxy - but it wouldn't, however, help the local proxy understand the remote > proxy's position; the local proxy just makes sure that the certificates > corresponds to the Request-URI of the request it has sent. Ok Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 13 11:28:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10645 for ; Wed, 13 Feb 2002 11:28:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14027 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 11:28:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10613; Wed, 13 Feb 2002 10:37:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10582 for ; Wed, 13 Feb 2002 10:37:49 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07781 for ; Wed, 13 Feb 2002 10:37:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1DFbw6Y029341; Wed, 13 Feb 2002 10:37:59 -0500 (EST) Message-ID: <3C6A8826.11A86BF5@dynamicsoft.com> Date: Wed, 13 Feb 2002 10:37:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Aymeric MOIZARD CC: "'sip@ietf.org'" Subject: Re: [Sip] route refresh request goal? References: <3C6A68CA.E18582CF@wellx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Inline. Aymeric MOIZARD wrote: > > my question concerns the route refresh mechanism. > This is located in bis-07 in 12.2 Requests within a Dialog > > For a UAS: > "Requests within a dialog MAY contain Record-Route and Contact header > fields. However, these requests do not cause the dialog's route set > to be modified, although they may modify the remote target URI." > > So requests which are route refresh requests do not update the > Route set! Yup, weird, isn't it? > > For a UAC: > > "When a UAC recieves a 2xx response to a route refresh resquest, it > MUST replace the dialog's remote target URI with the URI from the > Contact header field in that response, if present." > > So requests which are route refresh requests do not update the > Route set! True again. > > Back to the Global defintion of route refresh request: > "A route refresh request sent within a dialog is defined as a request > that can modify the route set of the dialog." > > I do not understand why those method are named "route refresh request"? > In either cases (UAC or UAS), those requests can only modify the > remote target URI. As far as I understand, those requests should > be named "remote target refresh request"! Indeed. We already recognized this, and the name has already been updated. The name is an artifact of the way routing was working pre-bis-06. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 11:34:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10830 for ; Wed, 13 Feb 2002 11:34:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14711 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 11:35:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13353; Wed, 13 Feb 2002 11:10:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13324 for ; Wed, 13 Feb 2002 11:10:27 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09297 for ; Wed, 13 Feb 2002 11:10:24 -0500 (EST) Received: from rporter [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AFF211400C8; Wed, 13 Feb 2002 11:10:26 -0500 Message-ID: <012f01c1b4a8$da106ee0$2a00000a@acmepacket.com> From: "Rick W. Porter" To: Date: Wed, 13 Feb 2002 11:09:44 -0500 Organization: Acme Packet MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Generally, I like the idea of standardizing the basic SIP-RADIUS Accounting relationship, but there are a couple issues that should be addressed by something defining that relationship. I have one "major" concern, and a few smaller details. My major concern is the draft does not address branching scenarios. The SIP Call-Id will be the same for all branches, and there is nothing in the RADIUS message to distinguish each branch. The back-end RADIUS processing may break down if the fundamental assumption of one Start and one Stop per session is violated. I see two possible solutions: include the Branch-ID for all RADIUS messages, or make the SIP proxy stateful enough to generate RADIUS messages for only chosen branch (or the whole session if all branches fail). My detailed concerns are listed by section comments below: Section 5.1 (User-name, p4) - If the intent of this attribute is to establish responsibility for the session, it does not work unless the SIP proxy is session stateful! The only way to record responsibility is when the SIP proxy receives the initial INVITE (or the first one that is Authenticated), because the SIP message From, To, and Authentication username, will change based on who initiates each SIP message, not who initiated the session. Therefore, I think the attribute fails to meet the its intent. Furthermore, without Authentication this attribute will be redundant--why include the information twice? Maybe make this should be an optional RADIUS attribute that is include if authentication is done? Section 5.5 (Acct-Status-Type, p6) - It appears that the draft suggests generating an Interim-Update to report receiving all SIP messages other than initial INVITEs, BYEs, and failures for initial INVITEs. This creates potential problems for branching scenarios as discussed above. Section 5.6 (Acct-Delay-Time, p7) - By including this attribute, the RADUIS message must get a new ID and the authenticator must be recalculated each time the message is retransmitted. It would seem to me that it is more efficient to let messages age with the "time sensitive" information included as part of the original message (i.e. Event-timestamp). Or, do RADIUS servers do something useful with the Acct-Delay-Time attribute? Section 5.9 (Acct-Session-Time, p8) - First, unless your SIP proxy is session stateful, where do you get the information to calculate this? Second, since the amount of time from receiving the INVITE to receiving the 200-OK is not deterministic, it seems to me that this time should be 0 for all sessions that never received the 200-OK; again, the SIP proxy needs to be session stateful to get this information. You wouldn't want to get a phone bill for attempted calls where the line was busy, so the reported time should be the time from the 200-OK to the BYE. Section 5.10 (Acct-Terminate-Cause, p9) - How do SIP events map to the RADIUS values? Some are intuitive (i.e. BYE = User Request), but others are not (404, 482, 500, ...). Section 5.14 (Sip-From, p12) and Section 5.15 (Sip-From, p12) - Why not use the Calling-Station-Id and Called-Station-Id instead of defining new attributes? Section 5.17 (Sip-Remote-IP-Address, p14) and Section 5.18 (Sip-Remote-Port, p14) - First, I would suggest a name change to Sip-Previous-IP-Address and Sip-Previous-Port, since there may be a inbound and outbound Remote IP Address/Port. Second, where does this info come from (Rec-Route header? Via header? or socket?) There may be minor NAT issues that may be intertwined with your choice. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 13 12:08:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13305 for ; Wed, 13 Feb 2002 12:08:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17230 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 12:08:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15067; Wed, 13 Feb 2002 11:42:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15035 for ; Wed, 13 Feb 2002 11:42:26 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11090 for ; Wed, 13 Feb 2002 11:42:22 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1DG9Dio020872; Wed, 13 Feb 2002 18:09:13 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15466.36777.821785.996536@harjus.eng.song.fi> Date: Wed, 13 Feb 2002 18:09:13 +0200 To: Jonathan Rosenberg Cc: Lawrence Conroy , Henry Sinnreich , "'Michael Thomas'" , "'Peterson, Jon'" , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: <3C6A8999.51BDBCF3@dynamicsoft.com> References: <3C6A8999.51BDBCF3@dynamicsoft.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > It needs to be core, since the baseline sip security mechanism is not > viewed as sufficiently good without it. The same argument could have > been made for any of the security stuff, smime, for example. It was put > into bis for the same reason. i have seen sip UAs that support basic authentication together with tls and digest authentication without any transport layer security, but i haven't heard of any that would do smime. is there any? if not, then does it make sense to have smimi in the bis. -- 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 daemon@optimus.ietf.org Wed Feb 13 13:45:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16910 for ; Wed, 13 Feb 2002 13:45:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22574 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 13:45:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21556; Wed, 13 Feb 2002 13:28:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21527 for ; Wed, 13 Feb 2002 13:28:03 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16279 for ; Wed, 13 Feb 2002 13:28:00 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #47837) id <0GRH00001HX4M3@firewall.wcom.com> for sip@ietf.org; Wed, 13 Feb 2002 18:27:04 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GRH0003JHX330@firewall.wcom.com>; Wed, 13 Feb 2002 18:27:03 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GRH00B01HWVUH@pmismtp01.wcomnet.com>; Wed, 13 Feb 2002 18:27:03 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GRH009CQHWLKB@pmismtp01.wcomnet.com>; Wed, 13 Feb 2002 18:26:50 +0000 (GMT) Date: Wed, 13 Feb 2002 12:26:46 -0600 From: Henry Sinnreich Subject: RE: SIP Spam Prevention (was Re: [Sip] calling number blocking at sip/isup ga... In-reply-to: <107.ce77833.299bd95e@aol.com> To: Mpierce1@aol.com, dean.willis@softarmor.com, sip@ietf.org Message-id: <000d01c1b4bc$00e2a7f0$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit >I believe that, in order for this to happen, the current operation >requirements of the telephony network, including those mandated by >state/federal laws, must be taken into account. This is a serious statement that we always have to keep in mind, though the right way: 1 - IP communications on the Internet does on no way need to replicate the existing telephone network, with all its limitations, for many good reasons, not the least because so many new services are possible on the Internet. 2 - State/federal laws regarding the Internet are still under development, and as can be noticed, may be very different than those applying for the telephone network. Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Mpierce1@aol.com > Sent: Wednesday, February 13, 2002 9:00 AM > To: dean.willis@softarmor.com; sip@ietf.org > Subject: Re: SIP Spam Prevention (was Re: [Sip] calling > number blocking at sip/isup ga... > > > Dean, > > Sorry it took me so long to reply. Hope the copy of previous > e-mail exchange isn't confusing, since the way I am replying > did not add carrots. I inserted who said it in []. > > Thanks for the long, heart-felt response. No, I don't see > your response as being "ranting" and I couldn't survive this > type of work if I didn't keep a little humour with it. And I > appreciate people who don't hold back on their ideas. > > I think your comments, and your apparent view of what is > important, emphasizes my main point that there are two > different applications, or environments, in which SIP will be > used to provide a telephony over IP capability. I represent > an organization which is interested in using it in a large > network to potentially replace the existing circuit-switched > network (as standardized by ITU, etc.) You speak of an > environment in which there is really no "telephony network", > at least not in the traditional sense. Calls are set up from > anywhere to anywhere ("arbitrary end-points") with no overall > control by a "service provider". Yes, I agree that there is a > place for such a non-network environment. But I am trying to > address the other environment. > > Also, there have been many opinions expressed that the desire > is for the existing circuit-switched PSTN to be completely > replaced with a packet-based network using SIP. I believe > that, in order for this to happen, the current operation and > requirements of the telephony network, including those > mandated by state/federal laws, must be taken into account. > > Yes, I realize that the IETF is not the ITU. (I'm at SG16 > right now.) I believe that each organization has its > advantages and disadvantages in its working procedures, but > that is not the issue here. In the past, they dealt with > competely different environments and networks. Now, both are > trying to deal with the other's traditional network, and must > take into account the realities of that other environment. > > RFC 2804 is interesting reading, especially the part about > how this policy (on not dealing with wire-tapping) was > established. It says: > > "Twenty-nine people spoke during the plenary session. ... > Very few people spoke out strongly in support for adding the > intercept features, while many spoke out against it, but a > sizable portion of the audience refused to state an opinion > (raised their hands when asked for "abstain" in the show of hands)." > > Given the prevailing attitude in the IETF, can you image > someone standing up in front of hundreds of participants and > saying "I think this group should actively work on protocols > to support wiretapping"? I can't. I wonder how many of those > who didn't express an opinion represent companies whose > official position is that they must support development of > protocols for wire-tapping. > > Anyway, I was not suggesting that the IETF should develop the > protocols fpr this, only that other protocols developed > should not make support of electronic surveillance > impossible. Note that RFC 2804 says that the reasons for > adopting this policy include: > > "the use of existing network features, if deployed > intelligently, provides extensive opportunities for > wiretapping, and should be sufficient under presently seen > requirements for many cases." > > and > > "Correlating users' identities with their points of > attachment to the Internet can be significantly harder, but > not impossible, if the user uses standard means of > identification. However, this means linking into multiple > Internet subsystems used for address assignment, name > resolution and so on; this is not trivial." > > It seems to me that this reason for not addressing > wire-tapping would no longer be true if SIP (and the network > architecture) allows users to originate telephone calls with > no identification. In fact, other required functions such as > call tracing and maintenance also require the same, > authenticated calling party identification capabilities. > > (Incidentally, the IETF "policy" means little if the laws of > the country mandate certain capabilities be supported as a > criteria for providing service. Note Juha's e-mail of Jan 29.) > > I understand your description of what happens if I try to set > up a session to your SIP address and it's forwarded to your > cell phone via the PSTN. But what you are doing doesn't > constitute a "service provider" in the sense of what I am > referring to. It's a simple call-forwarding function at the > destination (of the IP portion). When you interwork to the > PSTN to complete the call, then the PSTN's originating switch > is the service provider and knows your identity (the ISDN > line you use). Of course, it doesn't know or care about the > identity of the first part of the call (the one to your SIP > address). Yes, the bad guy may use such a service to make > anonymous calls, but as soon as that is discovered, you, as > the one who is providing the forwarding service could be > required to support further identification of the original > source of the call. > > I agree that the verification between the end user and their > "service provider" (SIP proxy) would use some "crypto" > function. (I don't really call this "crypto" but rather a > signing function.) Yes, in some environments VeriSign's > certificate could be used, but other means exist depending on > the nature of the local network. It's between the end party > and their service provider. The point I'm making is that in > the world-wide telephony network, the ability to believe that > the calling party number delivered at the destination is > legitimate should not involve such a crypto or signing > function between the called party and the originating party > or some agent representing the originating party. I have a > hard time believing that this can occur in the time required > for call set up. > > Your example of doing stock trades with Schwab is not one of > using the calling party ID that we have been discussing. It > presumes that some previous business relationship exists > between you and Schwab, including the establishment of a > shared secret. They don't care that the call was made from > your phone, they want to know it's really you, no mater what > phone you're using. On the other hand, the calling party > identification we're talking about must be between any two > phones in the network (the whole world?). > > I don't open e-mail if I don't recognize the "from" or the > subject. I accepted and opened your e-mail based on some > level of trust that what came to me had a legitimate "from" > address. Yes, I realize that the e-mail you sent me could > have been faked and really be from someone else. I want a > telephony network in which the called party can trust the > calling party ID delivered to them (because they trust their > own proxy or "service provider"). > > > In a message dated 2/1/02 8:34:45 PM Eastern Standard Time, > dean.willis@softarmor.com writes: > > > Warning! This response contains philosophical ranting. Please > take a large dose of humour supplement to help ease the pain. > > ----- Original Message ----- > From: > > Dean mumbled: > > > Ah. In the case I referenced, there WAS no service provider > > > originating the call. It was produced by a SIP UA on the > Internet. > > > From that point of view, every PC is a service provider . . . > > > > > [Mike] > > Interesting, but this points out the basic difference in network > > architectures that we are addressing. You talk as if the telephone > > call originates out of nowhere, like some Spam seems to today. I am > > talking of a network architecture view in which every > telephone call > > must begin and end under control of a "service provider". (And that > > doesn't mean a provider with a physical netwok like today's > telephone > > companies.) In this network architecture, all the privacy issues > > (calling party ID, called party ID, names, etc.) are dealt > with by the > > choosen service provider. (You don't get service from someone you > > don't trust, nor do they provide service to someone if they > don't have > > a way to verify who is trying to originate a call.) And at the same > > time, the legal invasions of privacy, to support > wire-tapping, would > > be dealt with by this same service provider. > > > > [Dean] > I believe you have us confused with the ITU ;-) . . > > Mike, this is the INTERNET Engineering Task Force. We're > concerned with the Internet -- it's a big packet-switching > thing that allows arbitrary communications between arbitrary > endpoints. Being a "Service Provider" fundamentally means to > take packets from a customer, insert them into the switching > fabric, and swish them on their merry way -- or, to take > packets from the switching fabric as appropriate and hand > them to your customer. Of course, there can be higher-level > service providers. VeriSign is a good example of a service > provider who provides tools to cope with the issues you > raise, without being "Big Brother" and controlling everybody. > I should give my speech on the difference between "control" > and "service" for you someday . . > > As for the rest, please see RFC 2804 for the IETF policy on > wiretapping and RFC 1984 for the general policy on crypto. > Good recreational reads, right up there with the Magna Carta > and the Declaration of Independence, which are also probably > useful reads for someone with too much background in > tradtional telephony. > > > [Mike] > > Yes, someone could agree to handle originations of telephone calls > > from unknown parties, but I can't imagine these calls ever being > > allowed to interwork into the PSTN or into a comercial IP-based > > telephony service provider's network. And laws on electronic > > surveillance will eventually forbid it anyway. > > > [Dean] > Try setting up a session to sip:dwillis@dynamicsoft.com. If > I'm not sitting at my desk, said call will be interworked > into the PSTN and delivered to my cell phone. Right now, and > every day for the past year and a half, except when the phone > company broke the ISDN lines for a while. I suppose it could > be spammed in a denial-of-service attack, but the last guy to > do that is still suffering. Of course, you just just call my > cell phone directly from outside the US with the same effect. > On the other hand, we are working on triocks to verify that > the request you've sent really came from the IP address > that's claiming to send it, and barring the Zombie Attacks > engendered by flawed Redmondian security systems will > probably be adequate for my purposes. > > [Mike] > > > > What bothers me is that we are modeling this on current > stuff, and > > > > yesterday I got two copies of the new "Party" virus attached to > > > > e-mails from "UnknownSender". If we can't stop this in e-mail > > > > today, what is the future telephony network going to be like? > > > > > [Dean] > > > Absoultely correct. This is why I want cryptographic > support for the > > > PID header, and transitive vouching techniques thereon. > If you get a > > > call whose RPID can't be verified, it becomes perfectly > legitimate > > > to do something nasty to it like forward it to a robot > that explains > > > your policy about anonymmous calls. Or, you can listen if > you want > > > -- some people LIKE to live dangerously. > > > > > [Mike] > > Again, in the network architecture I'm referring to, cryptographic > > procedures are not the answer to privacy for calling party ID. Yes, > > such procedures may be used by the originating service provider to > > verify that the calling party is legitimate, and by the terminating > > party to determine that the call attempt comes from their choosen > > service provider, then these procedures do not need to be > applied to > > the calling party ID iteself. In an enterprise network, we may use > > cryptographic measures between parties in that closed set, > but for the > > general telephony environment, the end user who receives a call > > shouldn't be required to apply cryptographic procedures with the > > originator to verify contents of the call setup message. > > > [Dean] > You have to do the crypto, either with the originator or with > a trusted intermediary who vouches for the originator. Sounds > like a service provider opportunity to me. What you're > proposing is not really different than the fundamental PKI > model -- it's just a question of who does the crypto, and > since your "phone" is going to have to do crypto just to > recognize the service provider, there's not much of a > difference in the scope of the problem. It's all just a big > "proxy" business. > > For example, let's say I want to trade some stocks. I fire up > my browser and point it at Schwab. How do I know that it's > really the Schwab site responding, and not my ex-wife's > attorney trying to figure out where I hid my last 37 cents? > Well, Schwab has a cert. It was signed by VeriSign. Thru > other channels, I got a copy of VeriSign's cert (Chairman > Bill was kind enough to include it with the OS on my office > PC, and some guys in Red Hats packaged it up for my house). I > use VeriSign's cert to check that my connection with Schwab > was signed with Schwab's cert. Transitive trust, right? So > why don't we use this approach for everything? Simple, really > -- people are too cheap to pay for their own cert, too lazy > to deal with it, or to ignorant to care (I suffer from all > three). Or they just don't trust Big Guys, and would rather > weave their own web of transitive trust with something like > PGP, which also tends to run afoul of the "lazy" and > "ignorant" set. And very occasionally because the device > involved is just a little too small to run the crypto (the > threshold is a code size somwhere around 64kB). > > . . much elided . . . > > > [Mike] > > Concerning your comment above that the call may start at > any SIP UA on > > the Internet (someone's PC). I firmly believe that it will > eventually > > be admitted that the issues of verification, privacy, service > > provisioning, accounting, wiretap, etc. require that every > "end user" > > of SIP have a dedicated SIP proxy to handle originating and > > terminating calls. This UA-SIP proxy relationship must be > established > > when the device is turned on, makes the first call, etc. > Thereafter, > > all interactions for individual phone calls are between > this trusted > > SIP proxy and the end-user (SIP UA). The SIP Proxy is then > the service > > provider (and responsible for all the above functions). I > believe this > > architecture is beginning to be recognized as required for various > > purposes and we can't move forward until it is accepted for > all cases. > > [Dean] > Wow. I really hope you're completely wrong in the general > case, otherwise I've wasted most of the last twenty years > working on the Internet. Especially since I'm my own service > provider and run my own proxy and my own PSTN interconnects. > I also run my own web server and my own email exchanger and > do all sorts of other stuff you would probably expect to > reserve for "service providers". Hey, you better reject this > email, because it just came from an Unknown Source! Yep, I > use service providers, but I choose to do so at a different > level than you're proposing, and that's OK, because this is > the Internet, not a government-sponsored work camp for the > political re-education of people who have expressed > libertarian sympathies in a public forum. > > On the other hand, there IS substance in much of what you're > saying. It's just that we hope to offer solutions that don't > require fixed "wires", or the virtual equivalent thereof, > between the slaves and the masters. In fact, I think most of > the community would happily do without the "slaves" and the > "masters" as well. > > And it now being Friday evening, I'm going to go work from > the other desk. Good night. > > -- > 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 daemon@optimus.ietf.org Wed Feb 13 13:46:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16966 for ; Wed, 13 Feb 2002 13:46:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22692 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 13:46:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21495; Wed, 13 Feb 2002 13:27:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21468 for ; Wed, 13 Feb 2002 13:27:36 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16261 for ; Wed, 13 Feb 2002 13:27:33 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #47837) id <0GRH00001HWZLD@firewall.wcom.com> for sip@ietf.org; Wed, 13 Feb 2002 18:27:00 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GRH00053HWZ31@firewall.wcom.com>; Wed, 13 Feb 2002 18:26:59 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GRH00B01HWVUH@pmismtp01.wcomnet.com>; Wed, 13 Feb 2002 18:26:59 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GRH009CQHWLKB@pmismtp01.wcomnet.com>; Wed, 13 Feb 2002 18:26:46 +0000 (GMT) Date: Wed, 13 Feb 2002 12:26:46 -0600 From: Henry Sinnreich Subject: RE: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt In-reply-to: <012f01c1b4a8$da106ee0$2a00000a@acmepacket.com> To: "'Rick W. Porter'" , sip@ietf.org Message-id: <000501c1b4bb$fec8c8a0$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I am not quite confortable standardizing SIP-RADIUS, given the "legacy" nature of RADIUS. Would not a web services approach using XML be preferable? Thanks, Henry Sinnreich WorldCom > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Rick W. Porter > Sent: Wednesday, February 13, 2002 10:10 AM > To: sip@ietf.org > Subject: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt > > > Generally, I like the idea of standardizing the basic > SIP-RADIUS Accounting relationship, but there are a couple > issues that should be addressed by something defining that > relationship. I have one "major" concern, and a few smaller details. > > My major concern is the draft does not address branching > scenarios. The SIP Call-Id will be the same for all branches, > and there is nothing in the RADIUS message to distinguish > each branch. The back-end RADIUS processing may break down if > the fundamental assumption of one Start and one Stop per > session is violated. I see two possible solutions: include > the Branch-ID for all RADIUS messages, or make the SIP proxy > stateful enough to generate RADIUS messages for only chosen > branch (or the whole session if all branches fail). > > My detailed concerns are listed by section comments below: > > Section 5.1 (User-name, p4) - > If the intent of this attribute is to establish > responsibility for the session, it does not work unless the > SIP proxy is session stateful! The only way to record > responsibility is when the SIP proxy receives the initial > INVITE (or the first one that is Authenticated), because the > SIP message From, To, and Authentication username, will > change based on who initiates each SIP message, not who > initiated the session. Therefore, I think the attribute fails > to meet the its intent. Furthermore, without Authentication > this attribute will be redundant--why include the information > twice? Maybe make this should be an optional RADIUS attribute > that is include if authentication is done? > > Section 5.5 (Acct-Status-Type, p6) - > It appears that the draft suggests generating an > Interim-Update to report receiving all SIP messages other > than initial INVITEs, BYEs, and failures for initial INVITEs. > This creates potential problems for branching scenarios as > discussed above. > > Section 5.6 (Acct-Delay-Time, p7) - > By including this attribute, the RADUIS message must get a > new ID and the authenticator must be recalculated each time > the message is retransmitted. It would seem to me that it is > more efficient to let messages age with the "time sensitive" > information included as part of the original message (i.e. > Event-timestamp). Or, do RADIUS servers do something useful > with the Acct-Delay-Time attribute? > > Section 5.9 (Acct-Session-Time, p8) - > First, unless your SIP proxy is session stateful, where do > you get the information to calculate this? Second, since the > amount of time from receiving the INVITE to receiving the > 200-OK is not deterministic, it seems to me that this time > should be 0 for all sessions that never received the 200-OK; > again, the SIP proxy needs to be session stateful to get this > information. You wouldn't want to get a phone bill for > attempted calls where the line was busy, so the reported time > should be the time from the 200-OK to the BYE. > > Section 5.10 (Acct-Terminate-Cause, p9) - > How do SIP events map to the RADIUS values? Some are > intuitive (i.e. BYE = User Request), but others are not (404, > 482, 500, ...). > > Section 5.14 (Sip-From, p12) and Section 5.15 (Sip-From, p12) > - Why not use the Calling-Station-Id and Called-Station-Id > instead of defining new attributes? > > Section 5.17 (Sip-Remote-IP-Address, p14) and Section 5.18 > (Sip-Remote-Port, > p14) - > First, I would suggest a name change to > Sip-Previous-IP-Address and Sip-Previous-Port, since there > may be a inbound and outbound Remote IP Address/Port. Second, > where does this info come from (Rec-Route header? Via header? > or socket?) There may be minor NAT issues that may be > intertwined with your choice. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Wed Feb 13 14:14:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17917 for ; Wed, 13 Feb 2002 14:14:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24899 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 14:14:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23171; Wed, 13 Feb 2002 13:53:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23139 for ; Wed, 13 Feb 2002 13:53:14 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17194 for ; Wed, 13 Feb 2002 13:53:10 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1DIr8io020972; Wed, 13 Feb 2002 20:53:09 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15466.46612.952838.292051@harjus.eng.song.fi> Date: Wed, 13 Feb 2002 20:53:08 +0200 To: Henry Sinnreich Cc: "'Rick W. Porter'" , sip@ietf.org Subject: RE: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt In-Reply-To: <000501c1b4bb$fec8c8a0$fae023a6@hsinnreich2> References: <012f01c1b4a8$da106ee0$2a00000a@acmepacket.com> <000501c1b4bb$fec8c8a0$fae023a6@hsinnreich2> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henry Sinnreich writes: > I am not quite confortable standardizing SIP-RADIUS, given the "legacy" > nature of RADIUS. Would not a web services approach using XML be > preferable? radius accounting and authorization are very widely used by all kinds of service providers and i would consider it a MUST that i can authenticate my sip users and collect their accounting data via radius. it makes no sense for a service provider who is currently using radius for those functions to have something else for sip. of course, the use of radius accounting and authentication is never mandatory if a service provider doesn't need 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 daemon@optimus.ietf.org Wed Feb 13 14:34:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18546 for ; Wed, 13 Feb 2002 14:34:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26548 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 14:34:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25078; Wed, 13 Feb 2002 14:17:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25053 for ; Wed, 13 Feb 2002 14:17:03 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18041 for ; Wed, 13 Feb 2002 14:17:00 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA28231; Wed, 13 Feb 2002 14:17:00 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1DJGxJ2023227 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Feb 2002 14:16:59 -0500 (EST) Message-ID: <3C6ABBA6.931E8F42@cs.columbia.edu> Date: Wed, 13 Feb 2002 14:16:54 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henry Sinnreich CC: "'Rick W. Porter'" , sip@ietf.org Subject: Re: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt References: <000501c1b4bb$fec8c8a0$fae023a6@hsinnreich2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Yes, we can re-invent RADIUS via XML. What exactly does this buy us? No, RADIUS isn't sexy, but it certainly is used by a lot of ISPs (and some organizations). Henry Sinnreich wrote: > > I am not quite confortable standardizing SIP-RADIUS, given the "legacy" > nature of RADIUS. Would not a web services approach using XML be > preferable? > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 13 14:49:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18950 for ; Wed, 13 Feb 2002 14:49:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27243 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 14:50:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25420; Wed, 13 Feb 2002 14:19:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25280 for ; Wed, 13 Feb 2002 14:19:39 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18115 for ; Wed, 13 Feb 2002 14:19:35 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id UAA16251; Wed, 13 Feb 2002 20:19:33 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id UAA29466; Wed, 13 Feb 2002 20:19:27 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id <1DHM3PX9>; Wed, 13 Feb 2002 20:19:32 +0100 Message-ID: From: Mayer Georg To: "'Jonathan Rosenberg'" , Gonzalo Camarillo Cc: Hisham Khartabil , sip@ietf.org Subject: AW: [Sip] PRACK holding the offer Date: Wed, 13 Feb 2002 20:19:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA25285 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hello, does this mean the PRACK will generally not be allowed to carry SDP information or were the comments below only based on the initially described scenario (no SDP in INVITE and 183)? From 3GPP point of view it would be of great value of INVITE/183 and its PRACK/200 could carry SDP, follwed by COMET/200 after ressource reservation. Thanks for the help Georg > -----Urspr�ngliche Nachricht----- > Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Gesendet: Mittwoch, 13. Februar 2002 06:53 > An: Gonzalo Camarillo > Cc: Hisham Khartabil; sip@ietf.org > Betreff: Re: [Sip] PRACK holding the offer > > > I agree with Gonzalo on all points. To further his reasoning, > with this > proposal, a UAS would not know whether it needs to make the offer, or > whether the UAC will offer it later. This will require additional > signaling from UAC to UAS to say "even though I am not > sending the offer > in invite, i will send it later". More needless signaling and > complexity. > > -Jonathan R. > > Gonzalo Camarillo wrote: > > > > Hi, > > > > A reson for not allowing this exchange is that it would > complicate the > > glare prevention mechanisms (if the UAS sends an offer in a > 1xx and the > > UAC is sending at the same time an offer in an UPDATE we will have a > > collision). > > > > But I believe you are thinking of only using the PRACK to a > 1xx to send > > the offer from the UAC. In my opinion this increases the > complexity of > > the protocol for no real gain. > > > > If the UAC can send an offer in the first place, it will > send it it the > > INVITE. If it could not send the offer in the INVITE (maybe > because it > > is a 3pcc controller), why would it be able to send it now > in the PRACK? > > > > On the UAS side, if there is an scenario (I do not know of > any) where > > the UAS can send an answer, but not an offer, it would not work with > > plain SIP (INVITE-200 OK-ACK). Therefore, you would be defining a > > mechanism that would only work with certain extensions. > > > > Best regards, > > > > Gonzalo > > > > Hisham Khartabil wrote: > > > > > > Well, I don't have a specific scenario, just the general > one where I > > invite > > > you and say "lets do something, what do you have", you send a 1xx > > saying > > > "ok, but you let me first what you have". > > > > > > I just questioned it because the restrictions in section 13.2.1 > > prohibit > > > such scenario and I was wondering why should it be prohibited. > > > > > > Regards, > > > Hisham > > > > > > > -----Original Message----- > > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > > Gonzalo > > > > Camarillo > > > > Sent: Tuesday, 12 February 2002 6:29 PM > > > > To: Hisham Khartabil > > > > Cc: sip@ietf.org; jdrosen@dynamicsoft.com > > > > Subject: Re: [Sip] PRACK holding the offer > > > > > > > > > > > > Hi, > > > > > > > > So far we have assumed that if you do not send an offer in the > > INVITE it > > > > is because you wait for an offer from the UAS. > > > > > > > > Do you have an scenario where the UAC does not > introduce an offer in > > the > > > > INVITE but intends to do it later (only if the first > 1xx does not > > > > contain one)?? > > > > > > > > Gonzalo > > > > > > > > Hisham Khartabil wrote: > > > > > > > > > > Hi, > > > > > > > > > > Perhaps this has been discussed earlier, but here is > goes anyway: > > > > > > > > > > What is the harm in a PRACK carrying the SDP offer > and the answer > > being > > > > > carried in the 200OK for PRACK or even in the 200OK for the > > > > initial INVITE? > > > > > > > > > > INVITE (no SDP) > > > > > -------------------> > > > > > > > > > > 1xx (no SDP) 100rel > > > > > <------------------ > > > > > > > > > > PRACK (SDP) > > > > > -------------------> > > > > > > > > > > 200 (SDP) for PRACK > > > > > <------------------ > > > > > > > > > > OR > > > > > 200 (SDP) for INVITE > > > > > <------------------ > > > > > > > > > > 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 > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > > Columbia University Mobile: +358 40 702 35 35 > > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > > New York, NY 10027 > > > > USA Gonzalo.Camarillo@ericsson.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 > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 15:28:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19872 for ; Wed, 13 Feb 2002 15:28:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA29295 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 15:28:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28249; Wed, 13 Feb 2002 15:05:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28217 for ; Wed, 13 Feb 2002 15:05:48 -0500 (EST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19385 for ; Wed, 13 Feb 2002 15:05:43 -0500 (EST) Received: from piuha.net ([62.248.150.36]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with ESMTP id <20020213200503.FNLR6990.fep07-app.kolumbus.fi@piuha.net>; Wed, 13 Feb 2002 22:05:03 +0200 Message-ID: <3C6AC753.6020109@piuha.net> Date: Wed, 13 Feb 2002 22:06:43 +0200 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Henning Schulzrinne CC: Henry Sinnreich , "'Rick W. Porter'" , sip@ietf.org Subject: Re: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt References: <000501c1b4bb$fec8c8a0$fae023a6@hsinnreich2> <3C6ABBA6.931E8F42@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Yes, we can re-invent RADIUS via XML. What exactly does this buy us? No, > RADIUS isn't sexy, but it certainly is used by a lot of ISPs (and some > organizations). I agree. I do have a few comments on the draft though: - Section 7 talks about the need to do Record-Route and keep all signaling for the call in the same proxy. I wonder if that's really always necessary. You seem take the approach that the the SIP node calculates session times etc. Admittedly this is quite RADIUS-like and traditional accounting. However, you could have left this also to postprocessing, or the task of the accounting server. That would have allowed your SIP nodes to be stateless and just report "what's going on". On the other hand that might generate quite a bit of traffic to the accounting server, so it might also better to just have a "session" i.e. INVITE and report it's start and end, but this is then stateful. - I'm not sure I like very much the freedom you give to the policy of choosing either From or username to be sent in User-Name. Preferrably, both should be sent. Also, if you did this then it would be clearer that it has to be in the same manner as in the potential SIP RADIUS/DIAMETER authentication protocol. - Section 6 requirements on "some form of backoff" might be better if described in a bit more concrete form as there could potentially be a lot of traffic if all SIP events are sent to the accounting server. (DIAMETER would have helped you a little here.) - Do we really need to inform the accounting server of all SIP events (methods)? Why do we need to report on e.g. OPTIONS? - Diameter could have been considered as a base for this protocol as well, since it would be easier extensible when you add all the necessary SIP fields, and because the accounting retransmission etc. rules are much clearer [imho ;-) ] The downside is that the RFC isn't done yet. On the other hand you can run Radius attributes under Diameter anyway so... Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 13 15:33:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19987 for ; Wed, 13 Feb 2002 15:33:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA29832 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 15:33:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28640; Wed, 13 Feb 2002 15:15:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28609 for ; Wed, 13 Feb 2002 15:15:34 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19580 for ; Wed, 13 Feb 2002 15:15:31 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1DKFi6Y029771; Wed, 13 Feb 2002 15:15:45 -0500 (EST) Message-ID: <3C6AC93E.6BDF201E@dynamicsoft.com> Date: Wed, 13 Feb 2002 15:14:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mayer Georg CC: Gonzalo Camarillo , Hisham Khartabil , sip@ietf.org Subject: Re: AW: [Sip] PRACK holding the offer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mayer Georg wrote: > > Hello, > > does this mean the PRACK will generally not be allowed to carry SDP > information or were the comments below only based on the initially > described scenario (no SDP in INVITE and 183)? No, we are only talking about the initial offer. It is allowed for the following to occur: inital offer in the initial INVITE initial answer in the 18x second offer in PRACK second answer in 2xx Take a look at the rules about this in bis-07. > > >From 3GPP point of view it would be of great value of INVITE/183 and its > PRACK/200 could carry SDP, follwed by COMET/200 after ressource > reservation. UPDATE/COMET would also be allowed to contain offers after the initial exchanges have completed, yes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 13 15:52:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20380 for ; Wed, 13 Feb 2002 15:52:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00791 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 15:51:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29173; Wed, 13 Feb 2002 15:26:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29141 for ; Wed, 13 Feb 2002 15:26:41 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19842 for ; Wed, 13 Feb 2002 15:26:37 -0500 (EST) Received: from dwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1DKQ2w27581; Wed, 13 Feb 2002 14:26:02 -0600 Message-ID: <00ab01c1b4cc$d3f8a3a0$b3036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: "Peterson, Jon" , References: <70565611B164D511957A001083FCDD56CAAF11@VA02> Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) Date: Wed, 13 Feb 2002 14:27:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jon wrote: > - When a SIP entity attempts to forward a request whose Request-URI uses the > SIPS URI scheme, if the next hop cannot accept the request over a TLS > connection, the request MUST fail. > > In effect, using SIPS in the Request-URI ensures that TLS is used on every > segment between the originator of the request and the destination. This is a > handy service, though admittedly one that is specific to architectures in > which it is desirable to use TLS for every hop. Note that users handing out > contact addresses today have no effective means of expressing a security > preference for TLS; if 'sip:alice@atlanta.com;transport=tls' is in the > Request-URI, the 'transport' parameter may be removed by the first hop that > dereferences the URI, and thus any subsequent hops might be unsecured - > however, it doesn't seem far-fetched that Alice might naively assume that > the transport parameters would pertain to the entire request path. There are two "request forwarding modes" in SIP. 1) basic forwarding: take in the request, look at the Route header, pop the Route hedader, and send the request on towards the target given in the request-URI. 2) Change the request-URI to indicate a different target. This could turn it into a sip: URL, a tel: URL, or potentially something else. The proposed sips behavior seems fine for type-1 forwarding. However, it doesn't seem appropriate for the calling party to be able to dictate what sort of retargeting can be dome in the type-2 scenario. It also seems reasonable that a proxy could retarget an incoming sip: or tel: URL to a sips: URL. For example, consider my phone system. Incoming phone calls tickle my gateway, which sends an appropriate INVTE to a sip:URL of "sip:phone-number@defaultproxy." Let's say I have a sips contact registered at defaultproxy. The proxy should be able to forward that INVITE over TLS to the registered contact. This is a very reasonable application, since my gateway and proxy are in a trusted private network, and my PC is roaming on some public network. So if this is reasonable, why isn't the inverse? In the typical calling scenario, a proxy transforming a sips: URI into another URI SHOULD prefer transforming into another sips: URI, but making that a MUST is just completely bogus from an application capability point of view. So, I would propose that we need a clarification that allows application level retargeting of a request initially sent with a sips: URI to a new target which may or may not be a sips: uri, and distinguish this from the basic proxy operation, which requires use of TLS for requests conating a sips: URI. -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 13 16:22:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21271 for ; Wed, 13 Feb 2002 16:22:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA02346 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 16:22:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01334; Wed, 13 Feb 2002 16:00:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01280 for ; Wed, 13 Feb 2002 16:00:24 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20606 for ; Wed, 13 Feb 2002 16:00:22 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GRH00L01OZDJS@firewall.wcom.com> for sip@ietf.org; Wed, 13 Feb 2002 20:59:37 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GRH00JK2OZD65@firewall.wcom.com>; Wed, 13 Feb 2002 20:59:37 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GRH00B01OZAFJ@pmismtp01.wcomnet.com>; Wed, 13 Feb 2002 20:59:36 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GRH0088SOYYX2@pmismtp01.wcomnet.com>; Wed, 13 Feb 2002 20:59:22 +0000 (GMT) Date: Wed, 13 Feb 2002 14:59:23 -0600 From: Henry Sinnreich Subject: RE: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt In-reply-to: <3C6ABBA6.931E8F42@cs.columbia.edu> To: "'Henning Schulzrinne'" Cc: "'Rick W. Porter'" , sip@ietf.org Message-id: <002701c1b4d1$507fc580$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Yes, we can re-invent RADIUS via XML. What exactly does this > buy us? It may buy an OSS system based on web services, where various components can be outsourced or offered as services, such as customer service, billing, traffic reporting, etc. Quite similar in concept to the component services architecture in SIP. Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Henning Schulzrinne > Sent: Wednesday, February 13, 2002 1:17 PM > To: Henry Sinnreich > Cc: 'Rick W. Porter'; sip@ietf.org > Subject: Re: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt > > > Yes, we can re-invent RADIUS via XML. What exactly does this > buy us? No, RADIUS isn't sexy, but it certainly is used by a > lot of ISPs (and some organizations). > > Henry Sinnreich wrote: > > > > I am not quite confortable standardizing SIP-RADIUS, given the > > "legacy" nature of RADIUS. Would not a web services > approach using XML > > be preferable? > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Wed Feb 13 16:23:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21393 for ; Wed, 13 Feb 2002 16:22:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA02377 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 16:23:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01625; Wed, 13 Feb 2002 16:01:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01527 for ; Wed, 13 Feb 2002 16:01:11 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20625 for ; Wed, 13 Feb 2002 16:01:09 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA09712; Wed, 13 Feb 2002 16:00:39 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1DL0cJ2026761 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Feb 2002 16:00:39 -0500 (EST) Message-ID: <3C6AD3F1.915F60F3@cs.columbia.edu> Date: Wed, 13 Feb 2002 16:00:33 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jarkko@piuha.net CC: sip@ietf.org Subject: Re: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt References: <000501c1b4bb$fec8c8a0$fae023a6@hsinnreich2> <3C6ABBA6.931E8F42@cs.columbia.edu> <3C6AC753.6020109@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > I do have a few comments on the draft though: Thanks for the comments. > > - Section 7 talks about the need to do Record-Route and > keep all signaling for the call in the same proxy. > I wonder if that's really always necessary. You seem > take the approach that the the SIP node calculates > session times etc. Admittedly this is quite RADIUS-like > and traditional accounting. However, you could have left > this also to postprocessing, or the task of the accounting > server. That would have allowed your SIP nodes to be > stateless and just report "what's going on". On the other > hand that might generate quite a bit of traffic to the > accounting server, so it might also better to just have > a "session" i.e. INVITE and report it's start and end, > but this is then stateful. I agree that this is just one model, so I'll qualify that section. It really depends on who generates the RADIUS: a proxy or a the gateway acting as a SIP UA. The caveats are necessary only in the former case. We locally run a dumb gateway, so that colored my thinking. > > - I'm not sure I like very much the freedom you give to > the policy of choosing either From or username to be > sent in User-Name. Preferrably, both should be sent. > Also, if you did this then it would be clearer that > it has to be in the same manner as in the potential SIP > RADIUS/DIAMETER authentication protocol. Agreed, that's probably a bit too much liberty. I'm guessing both are needed and that the username is closer in spirit to the User-Name account name. > > - Section 6 requirements on "some form of backoff" might > be better if described in a bit more concrete form > as there could potentially be a lot of traffic if > all SIP events are sent to the accounting server. > (DIAMETER would have helped you a little here.) > As far as I know, the RADIUS spec is similarly vague (I tried to find anything on this, without much luck), which is not much of an excuse. Would the SIP timeout progression be an acceptable choice? I don't think that the traffic would necessarily be more than for a dial-up server, except that maybe the call duration for voice calls is a bit shorter on average. Not being part of that crowd: Is DIAMETER making headway? > - Do we really need to inform the accounting server > of all SIP events (methods)? Why do we need to > report on e.g. OPTIONS? Probably not if your objective is just phone billing. I agree that this should be optional and a matter of local policy. > > - Diameter could have been considered as a base for this protocol > as well, since it would be easier extensible when you add > all the necessary SIP fields, and because the accounting > retransmission etc. rules are much clearer [imho ;-) ] > The downside is that the RFC isn't done yet. On the other > hand you can run Radius attributes under Diameter anyway > so... I have no particular affinity for RADIUS, just that it was very easy to extend existing implementations to do what's described in the draft. (We've implemented this in our server and tested it with a few standard open-source RADIUS implementations.) In terms of DIAMETER: See my question above. DIAMETER always seems to be just about done... > > Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 13 17:05:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22553 for ; Wed, 13 Feb 2002 17:05:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04883 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 17:05:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03337; Wed, 13 Feb 2002 16:38:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03302 for ; Wed, 13 Feb 2002 16:38:17 -0500 (EST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22073 for ; Wed, 13 Feb 2002 16:38:14 -0500 (EST) Received: from piuha.net ([62.248.150.36]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with ESMTP id <20020213213734.FXWK6990.fep07-app.kolumbus.fi@piuha.net>; Wed, 13 Feb 2002 23:37:34 +0200 Message-ID: <3C6ADD03.4040105@piuha.net> Date: Wed, 13 Feb 2002 23:39:15 +0200 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Henning Schulzrinne CC: sip@ietf.org Subject: Re: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt References: <000501c1b4bb$fec8c8a0$fae023a6@hsinnreich2> <3C6ABBA6.931E8F42@cs.columbia.edu> <3C6AC753.6020109@piuha.net> <3C6AD3F1.915F60F3@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > As far as I know, the RADIUS spec is similarly vague (I tried to find > anything on this, without much luck), which is not much of an excuse. Yes it is vague, and as a result it's often anyone's guess exactly what RADIUS accounting does under congestion or extended periods of server unavailability. Good products handle things well, but you can't necessarily tell it from the RFCs... > Would the SIP timeout progression be an acceptable choice? Probably as far as congestion control goes. However, you also need to specify e.g. that implementations SHOULD have a storage for records they could not deliver and they SHOULD have a policy on what to do if they conclusively can't deliver or store any additional accounting records at this time. More background data in RFC 2975, section 2. Could also take a look at section 9.4 in draft-ietf-aaa-diameter-08.txt. > I don't think that the traffic would necessarily be more than for a > dial-up server, except that maybe the call duration for voice calls is a > bit shorter on average. Perhaps. > Not being part of that crowd: Is DIAMETER making headway? If you're asking standards process status, DIAMETER was going fast to RFC about half a year ago, but since then we've discovered that big specs have lots of small things to get right, even if there's less controversial discussions as we have in SIP. And it isn't helping that some key people have been busy at their "day jobs"... I think the current plan is to make one more round and go for final last call. > In terms of DIAMETER: See my question above. DIAMETER always seems to be > just about done... Tell me about it. Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 13 17:08:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22585 for ; Wed, 13 Feb 2002 17:08:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04995 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 17:08:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03473; Wed, 13 Feb 2002 16:41:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03442 for ; Wed, 13 Feb 2002 16:41:39 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22130 for ; Wed, 13 Feb 2002 16:41:36 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 5E74A1E024; Wed, 13 Feb 2002 16:41:37 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA11518; Wed, 13 Feb 2002 16:41:34 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id QAA82297; Wed, 13 Feb 2002 16:43:46 -0500 (EST) Date: Wed, 13 Feb 2002 16:43:46 -0500 (EST) Message-Id: <200202132143.QAA82297@fish.research.att.com> To: jdrosen@dynamicsoft.com Cc: sip@ietf.org Subject: Re: [Sip] tsvchange and Supported/Require, was: [Sip] Last Call comments on 2543bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan wrote, in part: > It remains totally unclear to me that any extensions are needed to > support [legal intercept] functions. People are already using b2bua and > media intermediaries for this as you well know. If you are interested in understanding electronic surveillance requirements, I can send megabytes of documents. If not, then continue to make statements about a b2bua w/media doing the job. Either way, per raven, the discussion does not belong on an ietf list. And that is somewhat difficult as it requires extensions. > Are you honestly trying to tell me, that using an extension without a > Require/Supported tag, won't allow us to get to 5 nines of reliability? > On what concrete technical grounds could you conceivably make such a > claim? I anxiously wait the numerical analysis. Sounds like more FUD to > me - "uh oh, SIP can't do five nines!". It is up to you as a vendor to show how you meet a reliability goal. My claim is that one of the commonly-used tools to achieve this in the past is duplication and double-checking within the messages themselves. If you can achieve the reliability without it, fine. I would think that other vendors might be more interested in keeping the tools available. Bill Marshall wtm@research.att.com -----original message----- Date: Wed, 13 Feb 2002 01:18:16 -0500 From: Jonathan Rosenberg To: William Marshall Cc: sip@ietf.org Subject: Re: [Sip] tsvchange and Supported/Require, was: [Sip] Last Call comments on 2543bis-07 William Marshall wrote: > > The text that I am objecting to here first appeared in the bis rewrite > (bis-05). If it was preceeded by any list discussion leading to a > consensus that it should be included, then I missed it. I've been > objecting regularly ever since the text in bis-05 appeared. As I have said, this text was the result of discussions with IESG, who requested its inclusion in the specification. The words you are reading were carefully reviewed and scrutinized. It is frequent for changes in documents to be based on IESG feedback. > > The discussion last week concluded, I believe, that IANA registration > of header names and option tags, combined with text regarding formats > and discussion to appear in the extension guidelines draft, was > sufficient. No reference to tsvarea-sipchange was needed. Agreed. > There are a number of "facts" that I don't think need any discussion. > Some of these are 1) Carriers will be obliged to meet regulatory > requirements, and 2) Some regulatory requirements will not be > standardized by IETF. As I stated before, it is an ugly subject. > > So assume there is an implementation of a protocol that starts with > SIP and adds extensions necessary to meet the regulatory requirements > on carriers. IETF then publically states that it is not compliant > to SIP. Then the decision comes down from high that SIP can't meet > the service requirements, so pick a standard protocol that can. > And then the whole network architecture is changed. Bill, these are FUD arguments, very similar to ones I have heard in the past to push other drafts that I shall not name. I am honestly quite tired at this point of these kinds of "do as I say or we will use something else" arguments, as they are nothing more than veiled threats. Please keep them to yourself. First off, no one ever said that IETF can't or won't work on extensions for meeting regulatory requirements. Things like 911 are of much interest to people here, and are being worked on. Perhaps you refer to raven, where the decision was that IETF won't work on legal intercept. It remains totally unclear to me that any extensions are needed to support these kinds of functions. People are already using b2bua and media intermediaries for this as you well know. While I may dislike such things, they are within the realm of the specifications to build them. So, what exactly ARE you talking about? Let us, for the moment, entertain the notion that there is some extension which cannot be done at IETF, and which is useful for some kind of service mandated by regulatory requirements. Fine. A SIP implementation that uses them is still SIP compliant. The problem only arises if the client INSISTS that the network or endpoints provide this service, or vice-a-versa. It is not clear to me at all that any such extension would be built such that a client or server HAD to implement it in order to provide service to another sip element. > If the additional headers were added based on IANA registration, > but an option tag were not, then the problem becomes one of system > reliability. As I stated above, double-checks like the header-optiontag > are the tools to get to 5 9's. Give up on the reliability goal? I > doubt it. Are you honestly trying to tell me, that using an extension without a Require/Supported tag, won't allow us to get to 5 nines of reliability? On what concrete technical grounds could you conceivably make such a claim? I anxiously wait the numerical analysis. Sounds like more FUD to me - "uh oh, SIP can't do five nines!". > > While I agree there is a problem that allows abuse by the unnamed > large vendor, the solution proposed in bis-05 has other unintended > side-effects. The only solution I can see is to allow these > non-standards-track extensions, and try again at the general problem. I am in favor of keeping the text as it stands. To further the point, it is my understanding that IESG still feels that the words that are there are needed, even in the presence of some IANA registration mechanism for headers. -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 daemon@optimus.ietf.org Wed Feb 13 17:58:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23570 for ; Wed, 13 Feb 2002 17:58:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA07504 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 17:58:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05213; Wed, 13 Feb 2002 17:11:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06131 for ; Wed, 13 Feb 2002 09:24:38 -0500 (EST) Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03301 for ; Wed, 13 Feb 2002 09:24:34 -0500 (EST) Received: from cvis05.marconicomms.com (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Wed, 13 Feb 2002 14:02:44 +0000 Received: from cvdgwy01.uk.marconicomms.com by cvis05.marconicomms.com with ESMTP (8.10.2+Sun/cvms-34) id g1DE2hK03698; Wed, 13 Feb 2002 14:02:43 GMT Subject: Re: [Sip] (no subject) To: " From: "Keith Robinson" Date: Wed, 13 Feb 2002 13:55:48 +0000 Message-ID: X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at 13/02/2002 14:02:38 MIME-Version: 1.0 Content-type: multipart/mixed ; Boundary="0__=80256B5F004C7E838f9e8a93df938690918c80256B5F004C7E83" Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --0__=80256B5F004C7E838f9e8a93df938690918c80256B5F004C7E83 Content-type: text/plain; charset=us-ascii ---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 02/13/2002 01:53 PM --------------------------- (Embedded image moved to file: pic09961.pcx) From: Keith Robinson On: 02/13/2002 12:30:52 PM To: "Bob Penfield" @ MCEXT cc: @MCEXT Subject: Re: [Sip] (no subject) (Document link: Keith Robinson) The concern I have is the original R-URI that a proxy sees is not the same as subsequent R-URI within the same dialog. Below is the scenario I have in mind. Say we have a terminating proxy, term-p1.new-domain.com, that receives the following INVITE: (some fields missing for brevity) INVITE sip:new-callee@new-domain.com To: sip:callee@called-domain.com From: sip:caller@calling-domain.com Contact: sip:caller@ua1.calling-domain.com Record-Route: In this case, the proxy at called-domain.com, which, for this situation is a strict router, has determined that callee@called-domain.com is contactable as new-callee@new-domain.com, has sent the INVITE on and Record-Routed, using the maddr parameter to direct subsequent messages to itself while preserving the original R-URI. term-p1new-domain.com has the ability to execute scripts on set up and tear down, dependant on such variables as To, From and R-URI. So, term-p1 requires the ability to save the original values of these fields so that consistent scripts (correct user and context) can be invoked on set up and clear down. To do this, it Record-Routes the same way as the strict routing proxy above. The following INVITE is sent to new-callee INVITE sip:new-callee@new-domain.com To: sip:callee@called-domain.com From: sip:caller@calling-domain.com Contact: sip:caller@ua1.calling-domain.com Record-Route: Record-Route: The response from the terminating user agent looks like SIP/2.0 200 OK Contact: Record-Route: Record-Route: Eventually, term-p1 wil get a BYE message; bearing in mind that the proxy at called-domain.com is a strict router, the message will be as follows BYE sip:new-callee@new-domain.com;maddr=170.60.50.200;lr To: sip:callee@called-domain.com From: sip:caller@calling-domain.com Route: Now following the rules given in bis07: 16.3 - Validate request OK 16.4 - Inspect the R-URI to see if it is one that would have been placed in a Record-Route by this proxy; evidently it is so this is overwritten with the last parameter in the Route header. The subsequent message looks like: BYE sip:170.60.50.100 To: sip:callee@called-domain.com From: sip:caller@calling-domain.com The text now says that the proxy MUST process this modified request as though it was the original received request. In which case, the original R-URI is lost and the proxy will not be able to invoke the correct sript, unless it was written as a call stateful proxy and saved the original R-URI. So this specification has the effect of requiring proxies to be written call statefully thereby increasing complexity. "Bob Penfield" @ietf.org on 02/12/2002 01:42:49 PM Sent by: sip-admin@ietf.org To: "Keith Robinson" cc: " Subject: Re: [Sip] (no subject) For subsequent requests in a dialog, the contact provided by the UA in a 200 OK is what the UAC wants to use for the target URI (last hop in the route). If there are no route headers, the target URI is used as the R-URI. If this is a new request with a pre-loaded route, the UA will put the target URI (usually the same at the To header) as the last route header. This has always been to only way to guarantee that the last hop in the route would receive the R-URI the UAC intended. ----- Original Message ----- From: "Keith Robinson" To: Cc: " Sent: Tuesday, February 12, 2002 4:09 AM Subject: Re: [Sip] (no subject) > > Hello, > > I see a problem here. > > The contact address that the UAC would put at the end of the route headers > is the contact address that was supplied by the terminating UA in a 200 OK > response; this is not necessarily the same as the original R-URI that was > sent in the original INVITE, it may simply be an IP address. I think it is > the original R-URI that the loose routing proxies are interested in, either > for resolving to the correct internal state machine (along with the from > and to headers) or deciding which terminating services to execute. > > Regards, > > K. Robinson > > > > > "Bob Penfield" on 02/11/2002 07:02:22 PM > > To: , "Keith Robinson" > cc: > > Subject: Re: [Sip] (no subject) > > > ----- Original Message ----- > From: "Keith Robinson" > > > Hello, > > > > This question may already have been dealt with, so my apologies if > it > > has. > > > > Anyway, in 16.4 (Making A Routing Decision) the text states that when a > > bis07 proxy detects that the received R-URI is one that it would have > > written into the Record-Route header then it must replace it with that > last > > entry of the Route header and continue as if this was the received R-URI. > > It also says that this will only happen if the previous element was a > > strict router. If all the preceding elements were strict routers then the > > last entry in the Route header would not be the target URI as none of the > > previous element would have appended it; indeed there may not be a last > > entry as the list may be empty. How is this situation handled, or am I > > missing something ? > > > > In this case, the UAC will construct the route headers the same way whether > it understands loose routing or not. A pre-bis-06 UA would put the route > set > plus the contact address (the real/target Request-URI) in the route header. > A bis-06/07 compliant UA will add the contact address to the route headers > when it recognizes that the first route entry is a strict-router. > > > > > > > > ------------ > This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. --0__=80256B5F004C7E838f9e8a93df938690918c80256B5F004C7E83 Content-type: application/octet-stream; name="pic09961.pcx" Content-Disposition: attachment; filename="pic09961.pcx" Content-Transfer-Encoding: base64 CgUBCAAAAAC7AjkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABvAIBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD/iv+K/4r/iv+K/4r/iv+K/4rsiqbtitaKy4rGisOKisKKpsKKpsKKpsKK psKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKK psKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKK psKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKK psKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKK psKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKK psKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKK psKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKK psKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKK psKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKK psKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKKpsKK psKKpoqmwoqmwoqmwoqmwoqmiqbCiqbCiqbCiqbEiqbCiqbCiqbCiqbCiqbCiqbCiqaKpsKKpsKK poqmwoqmwoqmiqbCiqbCiqaKpsKKpsKKpoqmwoqmwoqmiqbCiqbCiqaKpsKKpsKKpoqmwoqmwoqm iqaKiqbEiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzH iqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzH iqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzH iqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzLiqzHiqzD iqzDiqzCiqbEiqzPiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzHiqzFisKKrIrDiqyKpsKKpsKKrKbC iqbCiqasiqbCiqbCisHHwoqmwoqmiqymwoqmwoqmrIqmwoqmworBx8KKpsKKpoqspsKKpsKKpqyK psKKpsKKwcfCiqbCiqaKrKbCiqbCiqasiqbCiqbCisHHwoqmwoqmiqymwoqmwoqmrIqmwoqmworB x8KKpsKKpoqspsKKpsKKpqyKpsKKpsKKwcfCiqbCiqaKrKbCiqbCiqasiqbCiqbCisHHwoqmwoqm iqymwoqmwoqmrIqmwoqmworBx8KKpsKKpoqspsKKpsKKpqyKpsKKpsKKwcfCiqbCiqaKrKbCiqbC iqasiqbCiqbCisHHwoqmwoqmiqymwoqmwoqmrIqmwoqmworBx8KKpsKKpoqspsKKpsKKpqyKpsKK psKKwcfCiqbCiqaKrKbCiqbCiqasiqbCiqbCisHHwoqmwoqmiqymwoqmwoqmrIqmwoqmworBx8KK psKKpoqspsKKpsKKpqyKpsKKpsKKwcfCiqbCiqaKrKbCiqbCiqasiqbCiqbCisHHwoqmwoqmiqym woqmwoqmrIqmwoqmworBx8KKpsKKpoqspsKKpsKKpqyKpsKKpsKKwcfCiqbCiqaKrKbCiqbCiqas iqbCiqbCisHHwoqmwoqmiqymwoqmwoqmrIqmwoqmworBx8KKpsKKpoqspsKKpsKKpqyKpsKKpsKK wcfCiqbCiqaKrKbCiqbCiqasiqbCiqbCisHHwoqmwoqmiqymwoqmwoqmrIqmwoqmworBx8KKpsKK poqspsKKpsKKpqyKpsKKpsKKwcfCiqbDiqbCiqaKrKbDiqbDiqbEiqzCiqbDiqaKrIqmrIqmiqym woqmwoqmworBx8SKpsKKwcfEiqbCisHHxIqmworBx8SKpsKKwcfEiqbCisHHxIqmworBx8SKpsKK wcfEiqbCisHHw4qKw4qmx4qm/4r/iv+K/4r/iv+K/4r/iv+Kw4qsiqymwoqsxYqmxIqmw4qmxIqs woqmw4qmyIqsyIqmx4qmx4qmx4qmx4qmx4qmx4qmx4qmxoqKpsKKiqbGisHHx4rBx8KKpsKKpoqs iqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyK psOKpoqsiqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqm w4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbD iqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyKpsOK poqsiqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qm iqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaK rIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyKpsOKpoqs iqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyKpsOKpoqsiqbDiqaKrIqmw4qmiqyK psOKpoqsiqbDiqaKrIqmw4qmiqyKpsOKpoqspsKKpsKKpsWKpsKKpsKKrIqmxIqmwoqmiqbKiqas iqbCiqbDiqasxorBx8eKwcfHisHHx4rBx8eKwcfHisHHx4rBx8eKwcfEisKKisKKrMKKpqzEiqas iqbFiqzEiqbCiqymw4qmwoqspsOKpsKKrKbDiqbCiqymw4qmwoqspsOKpsKKrKbDiqbCiqymw4qm woqspsOKpsKKrKbDiqbCiqymw4qmwoqspsOKpsKKrKbDiqbCiqymw4qmwoqspsOKpsKKrKbDiqbC iqymw4qmwoqspsOKpsKKrKbDiqbCiqymw4qmwoqspsOKpsKKrKbDiqbCiqymw4qmwoqspsOKpsKK rKbDiqbCiqymw4qmwoqspsOKpsKKrKbDiqbCiqymw4qmwoqspsOKpsKKrKbDiqbCiqymw4qmwoqs psOKpsKKrKbDiqbCiqymw4qmwoqspsOKpsKKrKbDiqbCiqymw4qmwoqspsOKpsKKrKbDiqbCiqym w4qmwoqspsOKpsKKrKbDiqbCiqymw4qmwoqspsOKpsKKrKbDiqbCiqymw4qmwoqspsOKpsKKrKbD iqbCiqymw4qmwoqspsOKpsKKrKbDiqbCiqymw4qmwoqspsOKpsKKrKbDiqbCiqymw4qmwoqspsOK psKKrKbDiqbCiqymw4qmwoqspsOKpsKKrKbDiqbCiqymw4qmwoqspsOKpsKKrKbDiqbCiqymw4qm woqspsOKpsKKrKbDiqbCiqymw4qmwoqspsOKpsKKrKbEiqzIiqbHiqbDioZrhmzCi2WLa4tlw4qm rMyKpsOKpsKKrKbDiqaswoqmw4qmrMKKpsOKpqzCiqbDiqaswoqmw4qmrMKKpsOKpqzCiqbDiqas woqmw4qmrMKKpsOKpsSKpsmKpsOKpv+K/4r/iv+K/4r/iv+K/4rziqbCiqbCiqasxoqmwoqLisKL weEZwuIZw+LB9cHitcKKpsOKpsOKpsOKpoqsxoqmx4qmx4qmx4qmx4qmx4qmx4qmx4qmxoqKpsKK iqbIiqymw4qmrMWKrMOKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqs psKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqm woqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqas woqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbD iqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKK rKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqs psKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqm woqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqas woqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbDiqaswoqmwoqspsKKrKbD iqaswoqmwoqspsKKrKbDiqasxYqsxIqmwoqmworCi7TB8sHzwfTB4hnB3LvB3Lu0wtzB9cHitMeK rKbCiqymxYqmrMaKpqzFiqymxIqswoqmrMWKrKbEiqzCiqasxYqspsSKrMKKpqzFiqymxIrCisWK wcfCiqbJiqaKrKbCiqbLiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzP iqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzPiqzP iqzNiqbDiqbIiovCtBnC9MHiu7WRi2WLiotli8H0wfW0iobCiqbCiqYGxoqmxYqmrMaKpseKwcfH iqbHisHHx4qmx4rBx8eKpsaKiqasworCiqymyYqmrMKKpqzIiqaKpqzCiqaswoqmw4qmw4qmrMKK pqzCiqbDiqbDiqaswoqmrMKKpsOKpsOKpqzCiqaswoqmw4qmw4qmrMKKpqzCiqbDiqbDiqaswoqm rMKKpsOKpsOKpqzCiqaswoqmw4qmw4qmrMKKpqzCiqbDiqbDiqaswoqmrMKKpsOKpsOKpqzCiqas woqmw4qmw4qmrMKKpqzCiqbDiqbDiqaswoqmrMKKpsOKpsOKpqzCiqaswoqmw4qmw4qmrMKKpqzC iqbDiqbDiqaswoqmrMKKpsOKpsOKpqzCiqaswoqmw4qmw4qmrMKKpqzCiqbDiqbDiqaswoqmrMKK psOKpsOKpqzCiqaswoqmw4qmw4qmrMKKpqzCiqbDiqbDiqaswoqmrMKKpsOKpsOKpqzCiqaswoqm w4qmw4qmrMKKpqzCiqbDiqbDiqaswoqmrMKKpsOKpsOKpqzCiqaswoqmw4qmw4qmrMKKpqzCiqbD iqbDiqaswoqmrMKKpsOKpsOKpqzCiqaswoqmw4qmw4qmrMKKpqzCiqbDiqbDiqaswoqmrMKKpsOK psOKpqzCiqaswoqmw4qmw4qmrMKKpqzCiqbDiqbDiqaswoqmrMKKpsOKpsOKpqzCiqaswoqmw4qm w4qmrIqmw4qspsOKpoqmwou1vMHiwfTB4rvCtIvFiqaKwosZwfS0woqmwoqLkcO0psSKrMKKpsWK pqzCiqbCiqymwoqspsOKpsOKpsKKrKbCiqymw4qmw4qmwoqspsKKrKbDiqbDiqbCiqymwoqspsOK poqmxoqmrIqmw4qmxoqmwoqmiqzEiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqspsOKpsOKpsOKpsKK rKbDiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbDiqbDiqbCiqymw4qm w4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqspsOKpsOKpsOK psKKrKbDiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbDiqbDiqbCiqym w4qmw4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqspsOKpsOK psOKpsKKrKbDiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbDiqbDiqbC iqymw4qmw4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqspsOK psOKpsOKpsKKrKbDiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbDiqbD iqbCiqymxYqspseKi7TCGcH0GZGui8KKpsKKpsWKi8HzwfS0a4rCi7S7wfTC9cHii8KKpsSKrMKK psSKpseKpseKpoqsxYqmx4qmiqzFiqbHiqaKrMWKpsSKworFiqasxYqsxoqmxIqsxoqmyIqsz4qs z4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qs z4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsxoqmrMaKpsKLtRnB9MHiGZCL xIqmxYqmw4pswfUZtKaLZbsZwf/B9ML1wfRspsSKpsOKpqzCiqbEiqymx4qmwoqsxIqmx4qmwoqs xIqmx4qmwoqsxIqmxoqKpqyKwoqmxYqmw4qmw4qmrMSKpsOKpsKKpoqsxoqmw4qmw4qmrMKKpsOK psOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbD iqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKK psOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbD iqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qm rMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbD iqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qm w4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzC iqbDiqbDiqbDiqaswoqmw4qmw4qmx4qmwoqmiou0GcHiwfUZkYvCiqbLiqaLwdzB9LtsirQZwvS7 ksL0wdyLw4qsw4qmx4qsxoqmrMaKpsaKrKbHiqbGiqymx4qmxoqspsKKrMOKisKKrMKKpsSKrKbH iqbCiqzFiqzEiqaspsKKrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqas woqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbD iqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKK rKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKK psKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqm rMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqas woqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbD iqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKK rKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKKpsKKrKbDiqaswoqmrMKK psKKrKbDiqbDiotsu8H0weIZtIqmi6bDiqbDiqaKpsSKu8H0GZGGu8HzweLB3GyuGcH1GYvCiqaK psSKrMKKpsOKpoqmw4qmw4qmwoqspsOKpqzCiqbCiqymwoqspsOKpqzCiqbCiqymwoqspsOKpqzC iqbDiqbDiqaKpsWKrIqmxIqmrIqmwoqswoqmwoqmy4qm/4r/iv+K/4r/iv+K/4r/iuCKpsSKi7TB 4sH0wdy1a4vJiqbDiqzCioaLGcH1tWy7GcH0u4tstMH0GYvIisHHxoqsxoqsxYqspseKpseKpseK pseKpseKpsaKiqbCisOKpqzCiqbNiqbEiqzCiqaKpsOKpqzFiqymw4qmw4qmrMKKpsKKrKbDiqbD iqaswoqmwoqspsOKpsOKpqzCiqbCiqymw4qmw4qmrMKKpsKKrKbDiqbDiqaswoqmwoqspsOKpsOK pqzCiqbCiqymw4qmw4qmrMKKpsKKrKbDiqbDiqaswoqmwoqspsOKpsOKpqzCiqbCiqymw4qmw4qm rMKKpsKKrKbDiqbDiqaswoqmwoqspsOKpsOKpqzCiqbCiqymw4qmw4qmrMKKpsKKrKbDiqbDiqas woqmwoqspsOKpsOKpqzCiqbCiqymw4qmw4qmrMKKpsKKrKbDiqbDiqaswoqmwoqspsOKpsOKpqzC iqbCiqymw4qmw4qmrMKKpsKKrKbDiqbDiqaswoqmwoqspsOKpsOKpqzCiqbCiqymw4qmw4qmrMKK psKKrKbDiqbDiqaswoqmwoqspsOKpsOKpqzCiqbCiqymw4qmw4qmrMKKpsKKrKbDiqbDiqaswoqm woqspsOKpsOKpqzCiqbCiqymw4qmw4qmrMKKpsKKrKbDiqbDiqaswoqmwoqspsOKpsOKpqzCiqbC iqymw4qmw4qmrMKKpsKKrKbDiqbDiqaswoqmwoqspsOKpsOKpsOKpqzCiqbCiqzDiou0GcH1weK7 i8KKpsWKpsKKrMOKrMKKppC8wfXB8MHtGcH1wdy7ima0weLB9LNriqbCiqymxYqmw4qmw4qmrKbD iqasxoqmrMWKrKbCiqzDiqymxoqspsaKrKbGiqymwoqswoqKy4qmiqymw4qmxYqsiqbEiqzGiqaK rKbFiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzG iqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzI iqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzG iqzIiqzGiqzIiqzGiqzIiqzGiqzIiqzGiqzDiqzJiqbCiqaLtMHzwfS7tIuKpsSKpsKKrMKKpsKK psKKppC7wvQZwfTB4ruLimazweLB9LuLxIqmxIqmxIqmw4qsyoqmx4qmx4qmwoqmxIqmx4qmrMaK pqzGiqbCioqKpqzCiqbCiqymx4qmrMKKpqyKpsSKpsOKpqzKiqbDiqaswoqmw4qmw4qmw4qmrMKK psOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbD iqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qm rMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbD iqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qm w4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzC iqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qm w4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOK psOKpsOKpoqmrMOKkbTB9cHiu8KLpsWKpsKKrKbIiou0wfTB9cH0wfUZtIuKi2vC9MHci4qmw4rD i8WKpqzEiqbFiqaspsWKpqzCiqbCiqymw4qmwoqsxYqswoqmw4qmw4qmx4qmw4qmwoqspsSKpsaK rMKKps6KrMWKpsKKpsOKpsKKrIqmxIqmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqas woqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOK psOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbD iqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKK psOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbD iqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qm rMKKpsOKpsOKpsOKpqzCiqbDiqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqbD iqbDiqbDiqaswoqmw4qmw4qmw4qmrMKKpsOKpsOKpsOKpqzCiqaKrIqmwoqsxoqmtBnB9BnCi8aK psiKpoqsiqbCixnD9RmLwoqma7XB4hmLiovCioaLusHcwd2LwoqmxYrBx8SKpseKpsSKpsKKrMSK psaKpsKKpsOKrIqmx4qmrIqmxIqmrMOKworDiqbCiqymw4qmxIqswoqmrMKKpsOKpsOKpsaKrMKK pqzCiqbFiqbCiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzL iqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzD iqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzL iqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzLiqzDiqzFiqzGiqaKpqzCiqaRGcH1wdyLwoqmw4qmxYqm woqmxIqmwosZwfTB9cH0wdyLimWLa7XB4hmLiqbCimy6wd3C9cHis6bCiqzCiqbFiqaswoqmxIqs iqymxYqmxIqswoqmxIqswoqmiqbEiqymwoqsxYqspsWKpsKKiqbHiqbEiqbCiqbIiqaswoqmwoqs psOKpsqKwcfIiqbDiqbCiqymw4qmw4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbDiqbDiqbCiqym w4qmw4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqspsOKpsOK psOKpsKKrKbDiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbDiqbDiqbC iqymw4qmw4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqspsOK psOKpsOKpsKKrKbDiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbDiqbD iqbCiqymw4qmw4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqs psOKpsOKpsOKpsKKrKbDiqbDiqbDiqbCiqymw4qmw4qmw4qmwoqspsOKpsOKpsOKpsKKrKbDiqbD iqbDiqbCiqymw4qmw4qmw4qmw4qmyoq0GcH0wdxsyYqsiqbGiqzDiovB4sL1weLCi8SKtcHiwfWL imvCioa7wfTD9bRsxIqmxYqmyIqmwoqmxYqmxIrBx8iKpsmKpsSKpsKKpseKwoqsworCiqzCiqbE iqzCiqasxoqmwoqspsqKrKbFiqbCiqymxIqspoqmxYqmrMWKrKbHiqasxYqspseKpqzFiqymx4qm rMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqas xYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzF iqymx4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWK rKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqm iqymrMKKpoqRweK7i4qLwoqmiqbDiqbCiqzCiqasiqaKhovC9MH1GcKLwoqLZbUZwfS7iqaLimy7 wf/B9cH/wfUZi4qmiqbCiqzCiqasxIqmwoqspsaKrKasw4qspsOKpsKKrKbDiqasiqzCiqasw4qs xoqmwoqspoqmw4qmxoqsiqbCiqbGisHHxIqmxYqmiqymwoqmxIqmrM+KrKbFiqbCiqbEiqasiqbE iqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqas iqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbE iqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbC iqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbE iqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqas iqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbEiqasiqbEiqbCiqbE iqasiqbEiqbCiqbEiqasiqbEiqbIiqbDiq27i8KKpsyKpsWKi5DC9Bm7i8OKpoq0weLB9buLpgaL tMH0xPXB3ZCLx4qmxYqsx4qspseKpsiKpsOKrMOKpsKKpsOKpsKKpsKKpsKKrMWKrMOKioqmiqas woqmxIqswoqmxYqmrMSKpqzOiqaswoqmwoqmwoqmxoqsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qs z4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qsz4qs z4qsz4qsz4qsz4qsxYqspsOKpsOKpsKKi8aKpqzCiqaspsSKrMKKpq67wfXB4hmRw4qmwoquGcH1 u4uKi2W7GcH/wfXB/8H1GYuKpsSKrKbFiqaKpsKKrKbHiqbCiqaKrMSKpsKKrMSKpseKi7SRxIqs xIqmiqbDiqaKpsKKyYqsyIqmzYqmwoqsiqaKrIqmxIqmwoqsw4qswoqmwoqmwoqmwoqspsKKrKbD iqbDiqbCiqymwoqspsOKpsOKpsKKrKbCiqymw4qmw4qmwoqspsKKrKbDiqbDiqbCiqymwoqspsOK psOKpsKKrKbCiqymw4qmw4qmwoqspsKKrKbDiqbDiqbCiqymwoqspsOKpsOKpsKKrKbCiqymw4qm w4qmwoqspsKKrKbDiqbDiqbCiqymwoqspsOKpsOKpsKKrKbCiqymw4qmw4qmwoqspsKKrKbDiqbD iqbCiqymwoqspsOKpsOKpsKKrKbCiqymw4qmw4qmwoqspsKKrKbDiqbDiqbCiqymwoqspsOKpsOK psKKrKbCiqymw4qmw4qmwoqspsKKrKbDiqbDiqbCiqymwoqspsOKpsOKpsKKrKbCiqymw4qmw4qm woqspsKKrKbDiqbDiqbCiqymwoqspsOKpsOKpsKKrKbCiqymw4qmw4qmwoqspsKKrKbDiqbDiqbC iqymwoqspsOKpsOKpsKKrKbCiqymw4qmw4qmwoqspsKKrKbDiqbDiqbCiqymwoqspsOKpsOKpsKK rKbCiqymw4qmw4qmwoqspsKKrKbDiqbDiqbCiqbDiqbCiqzFiqaKpsKKpsqKpsKKpoqLu8H1wfQZ kIbFiou7wfS7i4pltLvB9MT1GcKLw4qmiqbFiqbFiqbDiqbDiqbIiqbEiqbCiqbFiqbCiqaKuhnB 9Iqmwoqmwoqmx4rDisKKw4qmiqbDiqaKpoqmwoqsw4qspsOKpqzCiqbCiqzCiqbDiqbFiqbFiqbE iqzHiqbEiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzE iqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbH iqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbC iqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzE iqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbC iqzFiqzCiqbIiqzEiqaswoqmwoqsw4qLwfDB4sH1tIvDiqbCima7wfTB3IuKbLTB4sH1wfTB88L1 GcKLwoqmx4qmrMOKrMWKrMKKpqzDiqymw4qmw4qmrMOKrMKKpsSKrMKKtcH0weLGiqzDiqzCiqas w4qspoqmiqzMiqbHiqbHiqbKiqzDiqyKpsSKpsKKpsKKpoqsyYqmxYqsiqbHiqbFiqyKpseKpsWK rIqmx4qmxYqsiqbHiqbFiqyKpseKpsWKrIqmx4qmxYqsiqbHiqbFiqyKpseKpsWKrIqmx4qmxYqs iqbHiqbFiqyKpseKpsWKrIqmx4qmxYqsiqbHiqbFiqyKpseKpsWKrIqmx4qmxYqsiqbHiqbFiqyK pseKpsWKrIqmx4qmxYqsiqbHiqbFiqyKpseKpsWKrIqmx4qmxYqsiqbHiqbFiqyKpseKpsWKrIqm x4qmxYqsiqbHiqbFiqyKpseKpsWKrIqmx4qmxYqsiqbHiqbFiqyKpseKpsWKrIqmx4qmxYqsw4qm w4qmxIqspsKKrKbDiqbEiqbCiqyKpoqmixnB9BmRi8aKi7sZweK1a4a0wvW8kcH0wfUZwovHiqym xoqmwoqmrIqmxoqmxIrBx8mKpsWKrKbDiqaLu8KLiqbCiqbEiqbFiqbCiorGiqymwoqsw4qspsKK rKbDiqaswoqmwoqspsOKpqzCiqaswoqmw4qmxIqspsSKrMSKpsKKrKbCiqzEiqasxYqspsKKrMSK pqzFiqymwoqsxIqmrMWKrKbCiqzEiqasxYqspsKKrMSKpqzFiqymwoqsxIqmrMWKrKbCiqzEiqas xYqspsKKrMSKpqzFiqymwoqsxIqmrMWKrKbCiqzEiqasxYqspsKKrMSKpqzFiqymwoqsxIqmrMWK rKbCiqzEiqasxYqspsKKrMSKpqzFiqymwoqsxIqmrMWKrKbCiqzEiqasxYqspsKKrMSKpqzFiqym woqsxIqmrMWKrKbCiqzEiqasxYqspsKKrMSKpqzFiqymwoqsxIqmrMWKrKbCiqzEiqasxYqspsKK rMSKpqzFiqymwoqsxIqmrMWKrKbCiqzEiqasxYqspsKKrMSKpqzFiqymwoqsxIqmrMWKrKbCiqzE iqasxYqspsKKrMSKpqzFiqymwoqsxIqmrMWKrKbCiqzEiqaswoqmxIqspsOKpsWKpsWKrIqmxYqm Bmy7wfPB9Bm0woqmiqaKpmy0wfXB4rtmkRnC9MHcwevC9BnCi8KKpsOKpsSKrIqmiqzIiqbHiqbF iqaswoqmw4qmw4qmw4qmwoqLxYqswoqmrMOKrKbEioqmwoqmwoqmxIqmwoqmx4qmx4qmzIqmyIqm xoqmxoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqm woqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqm xIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqm woqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqm xIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqm woqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqm xIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmxIqmwoqmyIqmyorBx8SKpsKKpsOKrIqmisKLwdzB9cH0 GZCmxoqLu8H0weLB72a0GcH1GbttweLB9RnCi2uKpsKKpsSKpoqmw4qmwoqmwoqmxIqmiqymxYqm xYqmxoqmyoqmw4qmxYqmxYqmrMKKwoqsxoqmwoqsxIqmxIqswoqmwoqsxIqmrMKKpsOKpsKKrKbC iqymxIqspsSKrKbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzC iqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbE iqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzE iqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbC iqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzC iqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbE iqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqaKrMKKpsOKpqymxoqs w4qswoqmworCi7zB9MHitIuKi8KKpsKKi7TC9LuLkcL0u4tswvXB3JGKa8KLkMOLw4qmxouQi8OK w4uuwovCiqbCisSLkYuKpsSKyYvCiqbCisKLw4qmxYqmw4qmxIrCioqmxIqmrMSKpsSKrMKKpsWK rIqmyorBx8uKrMaKwcfEiqbCiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbC iqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzE iqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbH iqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbC iqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzE iqbHiqbCiqzEiqbFiqzCiqbMiqbDiqbGiou0weLB9MHitGuKpsWKi7XB4sH1u8H4GcH1weK7wq7B 4sH1GcKLZa0ZweLB88Liu4umwoqztMHiGZEZwfO6psKLwdzB4sH0wuK7wc/Diou0GcHiwxmRrcKK i7S7wfW7i7vB4sH0weIZhoqLs64ZweLDiqzCiqasxoqsiqbCiqbDiqbGiqzEiqbCiqaKrMKKpqzG iqaswoqmiqbEiqymw4qmw4qmiqbCiqymw4qmyYqmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWK rKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqs pseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzFiqym x4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbH iqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMSKpqzCiqbEiqymrMKK pqyKpoqsiqbDiqymwoqLtcH1wfS7tIqmw4qmiqbCi8HiwfW7wewZwfQZtIuQwfDB4hnCi2uLGcH0 wrSRwdwZkIrCi8IZwf/B88H0whm7iqa7wfIZwrS1wfTB4pCmi5EZvMO0wdzB9buKprQZwvXCGcHc wrQZwfSQwovCGcH1wfSLpsiKrKbFioqsisSKrIqmwoqmw4qmiqzJiqbCiqbEiqbCiqzKiqyKpsWK pseKrMKKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyK psSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSK pqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKK psSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSK psKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyK psSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSK pqyKpsSKpsKKpsSKpqyKpsSKpsKKpsSKpqyKpsSKpsSKpsSKrIqmwoqmyoqspsOKi7vB9MHiu4qm yIqLu8H1we+1GcH0GYtsrhnB9BnCi8KKtMLibIpmkcH1tYvCiovB78H1wfQZka6LiosZwfSRbIqL weLB9LOLaxnB4rVrimyLwfUZkYqLkRnB9MHyvIvCbMHcwfW7pouQwe/C9MOKpoqspsKKpsSKpsOK poqKpqzFiqzCiqbFiqbDiqbIiqymx4qmrKbDiqbEiqzDiqzEiqbDiqbJiqasxoqmx4qmwoqsxIqm x4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qm woqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqs xIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqm x4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qm woqsxIqmx4qmwoqsxIqmx4qmwoqsxIqmx4qmwoqspsWKpsmKpsOKpqzEioa0B8H1GbWKi8SKpsOK hrvB9cH0BxnB4pGLiou7GcHirsOKpouQrYqLZZHB9RmLiqaLkMH/wfS0a8KKi7TB8xmLworDi4qm bMH0weK0i6aKixnB9Lumi2UZwfUZi4qmi8HcwfW7wopstMH0weKLpsqKiqaswoqmworEiqbDiqbE iqyKpsOKrKbCiqymw4qmx4qmyIqsiqbDiqbCiqbGiqzEiqbDisHHxoqspsKKrMSKpqzGiqbCiqzE iqasxoqmwoqsxIqmrMaKpsKKrMSKpqzGiqbCiqzEiqasxoqmwoqsxIqmrMaKpsKKrMSKpqzGiqbC iqzEiqasxoqmwoqsxIqmrMaKpsKKrMSKpqzGiqbCiqzEiqasxoqmwoqsxIqmrMaKpsKKrMSKpqzG iqbCiqzEiqasxoqmwoqsxIqmrMaKpsKKrMSKpqzGiqbCiqzEiqasxoqmwoqsxIqmrMaKpsKKrMSK pqzGiqbCiqzEiqasxoqmwoqsxIqmrMaKpsKKrMSKpqzGiqbCiqzEiqasxoqmwoqsxIqmrMaKpsKK rMSKpqzGiqbCiqzEiqasxoqmwoqsxIqmrMaKpsKKrMSKpqzGiqbCiqzEiqasxoqmwoqsxIqmrMmK psaKpsKKwcfDiqymw4qmimy6GcH1weK0i4qmwoqmw4qmi8Hcwf/C9cHiGa7Cima0wfTB9ZCLxYqL ZcKLwdwZwfUZi8OKtMH0GcKLpsKKtMH0GYuKpsSKi7XB9Bm1a8KKZRnB9LvDisHwwfTB3GvCimvB 3cH0u4aKprTC9WvDiqbDiqbCisHHxYrCiorDiqbCiqymw4qmx4qmx4qmrMSKpqzDiqymw4qmxYqm woqsxIqmrMKKpsOKpqzIiqbHiqbGiqymxIqswoqmxoqspsSKrMKKpsaKrKbEiqzCiqbGiqymxIqs woqmxoqspsSKrMKKpsaKrKbEiqzCiqbGiqymxIqswoqmxoqspsSKrMKKpsaKrKbEiqzCiqbGiqym xIqswoqmxoqspsSKrMKKpsaKrKbEiqzCiqbGiqymxIqswoqmxoqspsSKrMKKpsaKrKbEiqzCiqbG iqymxIqswoqmxoqspsSKrMKKpsaKrKbEiqzCiqbGiqymxIqswoqmxoqspsSKrMKKpsaKrKbEiqzC iqbGiqymxIqswoqmxoqspsSKrMKKpsaKrKbEiqzCiqbGiqymxIqswoqmxoqspsSKrMKKpsaKrKbE iqzCiqbGiqymxIqswoqmxoqspsSKrMKKpsaKrKbDiqasw4qspsmKpsWKhrvB9MH1wdxsyYrCi7vB 9MH/wfXB9MHckcKKppHC4q6Kpoqmw4qGu8QZwfUZi8KKhpDB/8Hzi8OKhpHB9RmLx4q7wfW7a4qm woq8wfS7poplGcH0u6aLpovB3MH1u8KKbLTB9MHii8OKrIqmiqzGiqaswoqmiqbJiqzCiqbCisHH xYqmwoqsw4qmiqzDiqbGiqyKpsOKrMSKpsSKpsOKpqzDiqbCiqaKrMSKpsKKpsKKrIqmwoqmxIrB x8KKpsOKrKbCiqbEisHHwoqmw4qspsKKpsSKwcfCiqbDiqymwoqmxIrBx8KKpsOKrKbCiqbEisHH woqmw4qspsKKpsSKwcfCiqbDiqymwoqmxIrBx8KKpsOKrKbCiqbEisHHwoqmw4qspsKKpsSKwcfC iqbDiqymwoqmxIrBx8KKpsOKrKbCiqbEisHHwoqmw4qspsKKpsSKwcfCiqbDiqymwoqmxIrBx8KK psOKrKbCiqbEisHHwoqmw4qspsKKpsSKwcfCiqbDiqymwoqmxIrBx8KKpsOKrKbCiqbEisHHwoqm w4qspsKKpsSKwcfCiqbDiqymwoqmxIrBx8KKpsOKrKbCiqbEisHHwoqmw4qspsKKpsSKwcfCiqbD iqymwoqmxIrBx8KKpsOKrKbCiqbEisHHwoqmw4qspsKKpsSKwcfCiqbDiqymwoqmxIrBx8KKpsOK rKbCiqbEisHHwoqmw4qspsKKpsSKwcfCiqbDiqymwoqmxIrBx8KKpsOKrKbCiqbEisHHwoqmw4qs psKKpsmKpsOKrKbDiqasxIqmwou7GcH0wdxswoqmw4qmwoqmi7sZwf/B9cHikYumimuuweLB9LTG iqaLu8HiGbRskcH1GYtswoq0wfQZi8SKtMH1wfSLw4qmwoqGu8H1wd2Lw4qLu8H1uouKi8HcwfW7 w4prwd3B4rVrwoq0wfTB9YqmwoqmxYqmxYrDiorCiqzCiqbDiqbDiqbHiqaswoqmx4qmxYqmw4qm w4qmw4qmxIqspsSKrMeKrMKKpsKKpoqsw4qswoqmwoqsxIqmx4qmx4qmx4qmx4qmx4qmx4qmx4qm x4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qm x4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qm x4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmx4qmrMKKpqzEiqbCiqzHiou0GcL0 u4qmxYqmw4qLuxnB/8H1GZGKpsKKixnB9MHckKbGirTC9LRsipHB9BmLiqaKkcH1GYvCiqaLkcL0 tGXCiqzDirTB9cHitMOKphnB9LumimsZwfS7pouKi7vB/7uGioa0wfTB4ovHiqbDiqymw4qmrIrD iqbDiqzGiqzNiqbCiqbEiqasw4rBx8SKrMeKpsaKpsOKpsKKpsuKpsKKpsaKpseKpsaKrKbHiqbG iqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaK rKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqs pseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqym x4qmxoqspseKpsaKrKbHiqbGiqymyYqmrMSKpsKKpsKKpoq0GcH0weK1i8WKpsSKhrQZwf/B9RmQ hsSKrsH0GZGGBoqmwoqmi7XC4myKhpHB9RmLw4q0wfQZi8SKtBnB9RmLwoqmiqaKbMHiwfS1a6aK bBnB9LqLporB8MH0u8KKpmvB3cH0u8KKa7TC9YqmwoqmrMOKrMWKpsOKioqmxYqmwoqspsOKpoqm rKbDiqaswoqmrMOKrMaKpsWKpsOKpqymwoqsxIqmrMKKpsSKrMKKpsKKrKbDiqasxYqspsSKrMKK psKKrMOKrKbEiqzCiqbCiqzDiqymxIqswoqmwoqsw4qspsSKrMKKpsKKrMOKrKbEiqzCiqbCiqzD iqymxIqswoqmwoqsw4qspsSKrMKKpsKKrMOKrKbEiqzCiqbCiqzDiqymxIqswoqmwoqsw4qspsSK rMKKpsKKrMOKrKbEiqzCiqbCiqzDiqymxIqswoqmwoqsw4qspsSKrMKKpsKKrMOKrKbEiqzCiqbC iqzDiqymxIqswoqmwoqsw4qspsSKrMKKpsKKrMOKrKbEiqzCiqbCiqzDiqymxIqswoqmwoqsw4qs psSKrMKKpsKKrMOKrKbEiqzCiqbCiqzDiqymxIqswoqmwoqsw4qspsSKrMKKpsKKrMOKrKbEiqzC iqbCiqzDiqymxIqswoqmwoqsw4qspsSKrMKKpsKKrMOKrKbEiqzCiqbCiqzDiqymxIqswoqmwoqs w4qspsSKrMKKpsKKrMOKrKbEiqzCiqbCiqzDiqymxIqspoqmx4qmrMaKpou0wvTB3JGLwoqmiqbC iqzCiqaQu8H1wfTCtMOKpoqLwdzB9LtmbK20i8SKu8H0wfVmi2y7wfUZwoumiq7B9RmLwoqmiou7 wfXB9JGLZYuKi4qGGcH0u65ri2XB9cH0tMKKphnB9LumwoqLwdzB9bumiou0wfTB4ovGiqbDiqbE iqzCiqbEiqymxIqmyoqsyoqmworBx9KKpsKKpsqKpsSKpsOKrMaKpsWKpsKKpsKKrIqmwoqmxIqm woqmwoqsiqbCiqbEiqbCiqbCiqyKpsKKpsSKpsKKpsKKrIqmwoqmxIqmwoqmwoqsiqbCiqbEiqbC iqbCiqyKpsKKpsSKpsKKpsKKrIqmwoqmxIqmwoqmwoqsiqbCiqbEiqbCiqbCiqyKpsKKpsSKpsKK psKKrIqmwoqmxIqmwoqmwoqsiqbCiqbEiqbCiqbCiqyKpsKKpsSKpsKKpsKKrIqmwoqmxIqmwoqm woqsiqbCiqbEiqbCiqbCiqyKpsKKpsSKpsKKpsKKrIqmwoqmxIqmwoqmwoqsiqbCiqbEiqbCiqbC iqyKpsKKpsSKpsKKpsKKrIqmwoqmxIqmwoqmwoqsiqbCiqbEiqbCiqbCiqyKpsKKpsSKpsKKpsKK rIqmwoqmxIqmwoqmwoqsiqbCiqbEiqbCiqbCiqyKpsKKpsSKpsKKpsKKrIqmwoqmxIqmwoqmwoqs iqbCiqbEiqbCiqbCiqyKpsKKpsSKpsKKpsKKrIqmwoqmxIqmwoqmwoqsiqbCiqbEiqbFiqyKpsKK psSKpsKKpsKKtML0u4vKiqaKi7vB9MHitGyKpsWKwfLB9Rm6u8HctMOKpoq0weLB9Lu6wdzB9MH1 GYvDirTB4hmLxYqLGcHiwfS7usK0i4prsxnB9cHctLrB3MH0wdyLwoqLu8H1u4qLpmvB3MH1u8KK ZbrC9Iqmw4qmiqzCiqbCiqymwoqmworCiqymxIqspsOKpqzGiqbDiqbDiqasxoqmrMKKpqymwoqs psOKpqzFiqzCiqbCiqymxIqspsWKpsOKpsKKrMKKpsKKrMOKrMKKpseKpqzGiqbHiqasxoqmx4qm rMaKpseKpqzGiqbHiqasxoqmx4qmrMaKpseKpqzGiqbHiqasxoqmx4qmrMaKpseKpqzGiqbHiqas xoqmx4qmrMaKpseKpqzGiqbHiqasxoqmx4qmrMaKpseKpqzGiqbHiqasxoqmx4qmrMaKpseKpqzG iqbHiqasxoqmx4qmrMaKpseKpqzGiqbHiqasxoqmx4qmrMaKpseKpqzGiqbHiqasxoqmx4qmrMaK pseKpqzGiqbHiqasxYqmw4qsxYqsw4qLtML0weGLw4qmwoqswoqmw4qLwfQZtGzFiqbCisHcweLB 9cIZs4vCiqbCiou7weIZwfS7tBnB4YvDiovB9BmQpsOKpoqLwdzB4sIZweIZs6aKi5HB3MLiwfQZ wdyLw4qmwdzB4sHcZcKKi8HcweK1woqLtMIZw4qmxYqmxorDioqKpsWKpsiKpoqspsOKpsOKrMSK ptCKwcfGiqbKiqymxorBx8iKpsaKpsKKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqym x4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbH iqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseK psaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymxYqm x4qmw4qmwoqmiqa0wfXB9BmLiqbEiqbHiq0ZtGuKpsKKpsSKwotswovHiqbDi4qLisKLiqbCiouK i8OKpsSKwotsi2yLw4qmiotsi2yLw4qmworCi8SKpoqLwoqmiouKi8WKrIqmw4qsiqbEiqaKxYqm rMSKpqzCiqasxYqsxIqmwoqmw4qspsOKpqzCiqaspseKpsKKrMKKpsKKrKbDiqbEiqymxYqmrIqm xIqmrMqKpsSKrMKKpsKKrMOKrKbEiqzCiqbCiqzDiqymxIqswoqmwoqsw4qspsSKrMKKpsKKrMOK rKbEiqzCiqbCiqzDiqymxIqswoqmwoqsw4qspsSKrMKKpsKKrMOKrKbEiqzCiqbCiqzDiqymxIqs woqmwoqsw4qspsSKrMKKpsKKrMOKrKbEiqzCiqbCiqzDiqymxIqswoqmwoqsw4qspsSKrMKKpsKK rMOKrKbEiqzCiqbCiqzDiqymxIqswoqmwoqsw4qspsSKrMKKpsKKrMOKrKbEiqzCiqbCiqzDiqym xIqswoqmwoqsw4qspsSKrMKKpsKKrMOKrKbEiqzCiqbCiqzDiqymxIqswoqmwoqsw4qspsSKrMKK psKKrMOKrKbEiqzCiqbCiqzDiqymxIqswoqmwoqsw4qspsSKrMKKpsKKrMOKrKbEiqzCiqbCiqzD iqymxIqswoqmwoqsw4qspsSKrMKKpsKKrMOKrKbEiqzFiqymworBx8SKpqzDiou0wfXB9MHca6bE iqbDiqaswoqmw4prrceKrKaKpsOKZcKKpsaKZYqmi2XFiqbDiqbFiqaKpsOKpsWKpsOKpoqmi8SK pseKpovCiqbDiqbDiqbFiqbDiqaswoqKwoqmz4qmw4qmworBx8uKpsqKpsKKpsSKpsOKrKbDiqbE iqbGiqbFiqzGiqbCiqymwoqmiqzCiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbE iqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbC iqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbE iqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbC iqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbE iqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbCiqbEiqbC iqbEiqbCiqbEiqbCiqbEiqbCiqbCiqbNiqaLtMH0wfW7wouKi4qmi8KKi8OKhsOKi6aKpoqmiqaL popswoqLa6aKi8OKhsKKpsOKi2vDiqaLpovCioaKi4qLpouKi8KKbKaKbIqmioaKi4qmi4psw4qm i4pri6aKhsKKbMWKa6bJiqzGisKKporCiqzCiqbDiqaswoqmx4qmx4qmrMKKpsSKrMKKpsWKpqzD iqzFiqymxoqsw4qswoqmxIqswoqmw4qmrMKKpsiKrMmKrKbHiqasxYqspseKpqzFiqymx4qmrMWK rKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqs pseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzFiqym x4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqspseKpqzFiqymx4qmrMWKrKbH iqasxYqspseKpqzFiqymx4qmrMWKrKbHiqasxYqswoqmw4qmrKbDiqYGtMH0weLB3IuukK6LwpGu ka6Lka6Ri5GukYuRrpGuw5GLka6zrpGLka6Ri5GukZCuwpGuka6Ri5Guka6RkK6RrpCRi5GLkYuR i5GukK6Ri5GukZCRi5GukYuRrpGukYuRrpGLwpGui5Guka6RrpG0iqaKpsOKpoqmw4qmrMOKrIqK psWKrKbGiqymwoqsw4qswoqmxYqmrMKKpsKKpsSKpoqsxYqmworBx8iKpsOKpsaKrKbCiqbEiqbG iqymw4rBx8KKpsKKpqzCiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbH iqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseK psaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qm xoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymxoqmwoqmxIrBx8aKpoqLGcH1 u4tswdzCGcHi0RnB4vMZweLDGcH00RnB4sgZxIqspoqsx4qKpsKKisOKpsOKpsOKpsKKpsSKpsOK psSKrKbGiqzFiqymxYqmx4qmw4qmwoqswoqmw4qmw4qmxoqspsOKpseKpsmKpqzEiqbEiqzCiqbC iqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzC iqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbE iqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzE iqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbC iqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzC iqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbEiqzCiqbCiqzEiqbHiqasirvB9MHcwoum wdzHGcHixRnB4sUZweLNGcHi2xnB4skZweLNGcHi0RmKpsmKpqzCiqbDiqbEiqzHiqzFiqbHiqbH iqbDiqbCiqbEiqbEiqyKpsqKpsSKrMOKwcfGisHHxoqswoqmwoqmxoqmwoqmxIqmwoqswoqmwoqm xIqmwoqmiqzCiqbCiqbEiqbCiqaKrMKKpsKKpsSKpsKKpoqswoqmwoqmxIqmwoqmiqzCiqbCiqbE iqbCiqaKrMKKpsKKpsSKpsKKpoqswoqmwoqmxIqmwoqmiqzCiqbCiqbEiqbCiqaKrMKKpsKKpsSK psKKpoqswoqmwoqmxIqmwoqmiqzCiqbCiqbEiqbCiqaKrMKKpsKKpsSKpsKKpoqswoqmwoqmxIqm woqmiqzCiqbCiqbEiqbCiqaKrMKKpsKKpsSKpsKKpoqswoqmwoqmxIqmwoqmiqzCiqbCiqbEiqbC iqaKrMKKpsKKpsSKpsKKpoqswoqmwoqmxIqmwoqmiqzCiqbCiqbEiqbCiqaKrMKKpsKKpsSKpsKK poqswoqmwoqmxIqmwoqmiqzCiqbCiqbEiqbCiqaKrMKKpsKKpsSKpsKKpoqswoqmwoqmxIqmwoqm iqzCiqbCiqbEiqbCiqaKrMKKpsKKpsSKpsKKpoqswoqmwoqmxoqmwoqsw4qmxorB88H0uouKa4uQ i67Hi5DFi5HHi5DDi5HDi67Di5DLi5DDi5DDi5CLrsKLrsKLkcOLkcmLkMOLkMWLkMOLkMqLxIqm woqmworBx8WKrMKKioqmrMKKpsKKrKbDiqbCiqymwoqspsKKrKbDiqasiqaKrMKKpsKKrMOKrMOK rKaKpsKKrKbCiqymwoqspsWKpseKpqzGiqbDiqasw4qswoqmwoqsw4qsxoqmyIqspseKpsaKrKbH iqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseK psaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qm xoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbG iqymx4qmxoqspseKpqzCiqaswoqmweLB3Itlw4qGw4psiouKbIqLimyLiotliouKbIqLimaKi4pl i4qLa4qLimaKwotri4qLa4uKi2WLiotli4qLZYvCimuLwopli4qLZYqLimyKi4psioaKbIqLimyK i4pmiouKZouKi2uLiouKi8eKrMaKpsOKpsKKxIqm0oqmw4qsz4qmw4qmzYqmxIqspsSKpseKpsKK poqsyIqmw4qsiqbDiqbDiqasxYrBx8KKpsaKrKbEiqzCiqbGiqymxIqswoqmxoqspsSKrMKKpsaK rKbEiqzCiqbGiqymxIqswoqmxoqspsSKrMKKpsaKrKbEiqzCiqbGiqymxIqswoqmxoqspsSKrMKK psaKrKbEiqzCiqbGiqymxIqswoqmxoqspsSKrMKKpsaKrKbEiqzCiqbGiqymxIqswoqmxoqspsSK rMKKpsaKrKbEiqzCiqbGiqymxIqswoqmxoqspsSKrMKKpsaKrKbEiqzCiqbGiqymxIqswoqmxoqs psSKrMKKpsaKrKbEiqzCiqbGiqymxIqswoqmxoqspsSKrMKKpsaKrKbEiqzCiqbGiqymxIqswoqm xoqspsSKrMKKpsWKpqyKpsqKi2XPiqb5is6KptSKpoqmiqymwoqmxorDisKKw4qmwoqspsOKpqyK psKKpsOKpsWKpsOKpsOKpsKKrKaKpsOKpsaKrKbDiqaKpqzEiqbEiqzDiqymw4qmx4qmw4qmrMOK rKbJiqbDiqbGiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzE iqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbH iqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbC iqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzE iqbHiqbCiqzEiqbHiqbCiqzEiqbHiqbCiqzCiqbGiqzCiqbDiqaKpsSKwcfCiqbDiqbDiqbDiqaK psOKpsKKpsSKpsOKpsOKpsOKpoqmw4qmw4qmxYqmw4qmw4qmw4qmw4qmiqaKpsOKpsWKpoqmw4qm w4qmw4qmwoqmy4qspsKKwcfCiqasioqmyIqmxoqsw4qsw4qsxoqsiqaKrMaKrMOKrMKKpsaKrMuK psKKpsSKwcfDiqzCiqbDiqzFiqbGiqaKrKbCiqzEiqyKpsOKpsKKpoqswoqmiqymxIqmwoqmiqzC iqaKrKbEiqbCiqaKrMKKpoqspsSKpsKKpoqswoqmiqymxIqmwoqmiqzCiqaKrKbEiqbCiqaKrMKK poqspsSKpsKKpoqswoqmiqymxIqmwoqmiqzCiqaKrKbEiqbCiqaKrMKKpoqspsSKpsKKpoqswoqm iqymxIqmwoqmiqzCiqaKrKbEiqbCiqaKrMKKpoqspsSKpsKKpoqswoqmiqymxIqmwoqmiqzCiqaK rKbEiqbCiqaKrMKKpoqspsSKpsKKpoqswoqmiqymxIqmwoqmiqzCiqaKrKbEiqbCiqaKrMKKpoqs psSKpsKKpoqswoqmiqymxIqmwoqmiqzCiqaKrKbEiqbCiqaKrMKKpoqspsSKpsKKpoqswoqmiqym xIqmwoqmiqzCiqaKrKbEiqbCiqaKrMKKpoqspsSKpsKKpoqswoqmiqymxIqmwoqmiqzCiqaKrKbE iqbCiqaKrMKKpoqspsSKpsSKrMKKpsKKpsSKpqzEiqbKiqaKrMOKrMOKrMOKrMKKpqzHisHHw4qs w4qsiqaKrMOKrMKKpqzDiqzDisHHw4qsw4qsw4qsw4qsw4qspsKKrMOKrMOKrMOKrMqKpsKKwcfH isOKworCiqzCiqbDiqaswoqmrMKKpoqmw4qmiqbDiqaswoqmw4qmxYqmw4qmwoqswoqmiqbFiqaK pqzCiqasw4qswoqmxYqmwoqswoqmiqbCiqbEiqbLiqbDiqbCiqymzoqspseKpsaKrKbHiqbGiqym x4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbH iqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseK psaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymw4qm woqmyIqmyYqmrMKKpqymxYqmxYqmw4qmxYqmrKbHiqbDiqbFiqbDiqbDiqaKpseKpsOKpseKpsOK pseKpsOKpsOKpsOKpsKKrKbCiqzEiqbDiqbCiqymworHiqzXiqbIiqasyIqmxIqswoqmzYqmy4qm xoqsw4qsxIqmrMKKpsKKps2KrKaKpsOKpsKKpsWKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbG iqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaK rKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqs pseKpsaKrKbHiqbGiqymx4qmxoqspseKpsaKrKbHiqbGiqymx4qmxoqsxYqspsKKpoqsxIqmwoqs yYqsiqbEiqbEiqbFiqbFiqymwoqmyYqmw4qmyoqmwoqmxIqmw4qmwoqmw4qmxIqmwoqmw4qmxIqm w4qmrMaKpsaKpoqsiqbDioqKpoqmw4qmw4qmw4qmwoqspsKKwcfDiqymxoqspsOKpsOKpsKKrKbH iqbEiqymw4qmrMKKpsWKpqzCiqaswoqmwoqsxIqmw4qmw4qmrMKKpsKKrMOKrKbCiqymw4qmxoqs psKKrMSKpsaKrKbCiqzEiqbGiqymwoqsxIqmxoqspsKKrMSKpsaKrKbCiqzEiqbGiqymwoqsxIqm xoqspsKKrMSKpsaKrKbCiqzEiqbGiqymwoqsxIqmxoqspsKKrMSKpsaKrKbCiqzEiqbGiqymwoqs xIqmxoqspsKKrMSKpsaKrKbCiqzEiqbGiqymwoqsxIqmxoqspsKKrMSKpsaKrKbCiqzEiqbGiqym woqsxIqmxoqspsKKrMSKpsaKrKbCiqzEiqbGiqymwoqsxIqmxoqspsKKrMSKpsaKrKbCiqzEiqbG iqymwoqsxIqmxoqspsKKrMSKpsaKrKbCiqzEiqbGiqymwoqsxIqmw4qmw4qmwoqsxIqmxIqspsOK psWKpsSKrMOKrKbCiqzCiqasy4qswoqmrMKKpqzDiqzDiqymwoqswoqmrMOKrMKKpqzDiqzDiqzD iqzDiqzDiqzDiqzCiqbEiqzCiqbCiqbEiqasxorDioqmxIqsiqbGiqzDiqbHiqbDiqymx4qsxYqs psSKpsKKwcfEiqbEiqzDiqbDiqymyIqmxIqmworBx8SKpsOKrMmKpsqKrMKKpoqsx4qmwoqswoqm iqymxIqmwoqmiqzCiqaKrKbEiqbCiqaKrMKKpoqspsSKpsKKpoqswoqmiqymxIqmwoqmiqzCiqaK rKbEiqbCiqaKrMKKpoqspsSKpsKKpoqswoqmiqymxIqmwoqmiqzCiqaKrKbEiqbCiqaKrMKKpoqs psSKpsKKpoqswoqmiqymxIqmwoqmiqzCiqaKrKbEiqbCiqaKrMKKpoqspsSKpsKKpoqswoqmiqym xIqmwoqmiqzCiqaKrKbEiqbCiqaKrMKKpoqspsSKpsKKpoqswoqmiqymxIqmwoqmiqzCiqaKrKbE iqbCiqaKrMKKpoqspsSKpsKKpoqswoqmiqymxIqmwoqmiqzCiqaKrKbEiqbCiqaKrMKKpoqspsSK psKKpoqswoqmiqymxIqmwoqmiqzCiqaKrKbEiqbCiqaKrMKKpoqspsSKpsKKpoqswoqmiqymxIqm woqmiqzCiqaKrKbEiqbCiqaKrMSKrMeKpsWKwcfEiqbDisHHxoqspsKKpsaKpsaKpqymw4qmwoqm yYqmw4qmxIqmx4qmxoqmwoqmwoqmw4qmw4qmwoqmw4qmxIqspsuKpsOKpqzCiqbCiqbCigwAAACA AAAAgACAgAAAAICAAIAAgIDAwMDA3MCmyvAEBAQICAgMDAwREREWFhYcHBwiIiIpKSlVVVVNTU1C QkI5OTn/fID/UFDWAJPM7P/v1sbn59atqZAzAABmAACZAADMAAAAMwAzMwBmMwCZMwDMMwD/MwAA ZgAzZgBmZgCZZgDMZgD/ZgAAmQAzmQBmmQCZmQDMmQD/mQAAzAAzzABmzACZzADMzAD/zABm/wCZ /wDM/wAAADMzADNmADOZADPMADP/ADMAMzMzMzNmMzOZMzPMMzP/MzMAZjMzZjNmZjOZZjPMZjP/ ZjMAmTMzmTNmmTOZmTPMmTP/mTMAzDMzzDNmzDOZzDPMzDP/zDMz/zNm/zOZ/zPM/zP//zMAAGYz AGZmAGaZAGbMAGb/AGYAM2YzM2ZmM2aZM2bMM2b/M2YAZmYzZmZmZmaZZmbMZmYAmWYzmWZmmWaZ mWbMmWb/mWYAzGYzzGaZzGbMzGb/zGYA/2Yz/2aZ/2bM/2b/AMzMAP8AmZmZM5mZAJnMAJkAAJkz M5lmAJnMM5n/AJkAZpkzZplmM5mZZpnMZpn/M5kzmZlmmZmZmZnMmZn/mZkAzJkzzJlmzGaZzJnM zJn/zJkA/5kz/5lmzJmZ/5nM/5n//5kAAMwzAJlmAMyZAMzMAMwAM5kzM8xmM8yZM8zMM8z/M8wA ZswzZsxmZpmZZszMZsz/ZpkAmcwzmcxmmcyZmczMmcz/mcwAzMwzzMxmzMyZzMzMzMz/zMwA/8wz /8xm/5mZ/8zM/8z//8wzAMxmAP+ZAP8AM8wzM/9mM/+ZM//MM///M/8AZv8zZv9mZsyZZv/MZv// ZswAmf8zmf9mmf+Zmf/Mmf//mf8AzP8zzP9mzP+ZzP/MzP//zP8z//9m/8yZ///M////ZmZm/2b/ /2ZmZv//Zv9m//+lACFfX193d3eGhoaWlpbLy8uysrLX19fd3d3j4+Pq6urx8fH4+Pj/+/CgoKSA gID/AAAA/wD//wAAAP//AP8A//////8= --0__=80256B5F004C7E838f9e8a93df938690918c80256B5F004C7E83-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 13 21:44:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27134 for ; Wed, 13 Feb 2002 21:44:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA16840 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 21:44:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15176; Wed, 13 Feb 2002 21:05:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15140 for ; Wed, 13 Feb 2002 21:05:25 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25657 for ; Wed, 13 Feb 2002 21:05:22 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1E24mb08419; Wed, 13 Feb 2002 20:04:48 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7FTWCV>; Wed, 13 Feb 2002 20:04:42 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF32@VA02> From: "Peterson, Jon" To: "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?) Date: Wed, 13 Feb 2002 20:04:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Comments below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, February 13, 2002 12:27 PM > To: Peterson, Jon; sip@ietf.org > Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) > [snip] > > There are two "request forwarding modes" in SIP. > > 1) basic forwarding: take in the request, look at the Route header, pop the > Route header, and send the request on towards the target given in the > request-URI. > > 2) Change the request-URI to indicate a different target. This could turn it > into a sip: URL, a tel: URL, or potentially something else. > > The proposed sips behavior seems fine for type-1 forwarding. However, it > doesn't seem appropriate for the calling party to be able to dictate what > sort of retargeting can be dome in the type-2 scenario. Well, I disagree - I believe it is appropriate for type-2, we'd just need a rule for it (something that was missing from my proposal). I think it is perfectly reasonable to say something along the lines of: - An entity that is performing 'retargeting' (on the basis of a 302 it has received, or an internal location service) MUST NOT retarget the request to a non-SIPS URI. So, if three Contact header fields are available in a 302, all non-SIPS URIs should be discarded regardless of qvalue if the initial request is for SIPS; if no SIPS URIs are available, the request fails. So I don't see how SIPS is incompatible with option 2 - we can define rules for it. The question is whether or not this actually prevents intermediaries from doing their jobs, or reduces the functionality of SIP. The important thing here is that any entity that performs 'retargeting' does so because it has some knowledge about how best to reach the resource identified by the Request-URI - knowledge gleaned from their own location service, maybe, or from a 302. While it might seem weird for the calling party to dictate the sort of retargeting done in type-2 case (although I don't think it's reasonable for me to want to be assured of the security of my calls), surely it is appropriate for the -called- party to dictate that sort of retargeting? If not, this begs a lot of questions about why the retargeting is performed; is this retargeting occuring with the knowledge and consent of the called party? SIPS as an AoR is distributed by parties who want people to reach them over TLS - this entails a certain amount of support and compliance. You won't tell people to try to reach you with a SIPS AoR unless you will be registering SIPS contact addresses under that AoR. And these registrations, I think, should be primary cause for 'retargeting'. I don't think we want to champion a view of SIP in which intermediaries that are not associated with either the calling or called party are 'retargeting' requests arbitrarily. Ideally, 'retargeting' is the transformation of an address of record to a contact address (which may in turn be an address of record for another domain), and this should be driven by the registration process - although there are also a limited set of caller-related transformations that could take place at the caller's proxy, like expansion of a speed-dial address. 'Retargeting' by unrelated intermediaries could lead to surprising, undesirable, and insecure consequences, especially in so far as the originator may never know the new form of the Request-URI (unless intermediaries propagate the retargeting as a redirection all the way back to the originator). I fear that this is a general SIP problem that is certainly independent of the SIPS proposal; solving these concerns about retargeting would, however, obviously be beneficial to SIPS. > > It also seems reasonable that a proxy could retarget an incoming sip: or > tel: URL to a sips: URL. For example, consider my phone system. Incoming > phone calls tickle my gateway, which sends an appropriate INVTE to a sip:URL > of "sip:phone-number@defaultproxy." Let's say I have a sips contact > registered at defaultproxy. The proxy should be able to forward that INVITE > over TLS to the registered contact. This is a very reasonable application, > since my gateway and proxy are in a trusted private network, and my PC is > roaming on some public network. > > So if this is reasonable, why isn't the inverse? I agree the first case is reasonable. The use of SIPS as a contact address leads to the securing of individual hops rather than the entire signaling path - we detailed exactly this in the proposal. You can register a SIPS contact address under a SIP AoR. It's unreasonable in the reverse instance because there is a difference between an AoR and a contact address - AoRs can travel end-to-end in headers like the To field that cannot be transformed by intermediaries - but moreover, because we're defining that it should be different because we like the property of requesting security for the entire signaling path. Hence the rules we have suggested for the handling of SIPS. > > In the typical calling scenario, a proxy transforming a sips: URI into > another URI SHOULD prefer transforming into another sips: URI, but making > that a MUST is just completely bogus from an application capability point of > view. > > So, I would propose that we need a clarification that allows application > level retargeting of a request initially sent with a sips: URI to a new > target which may or may not be a sips: uri, and distinguish this from the > basic proxy operation, which requires use of TLS for requests conacting a > sips: URI. > > -- > Dean Willis > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 13 21:59:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27205 for ; Wed, 13 Feb 2002 21:59:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA17219 for sip-archive@odin.ietf.org; Wed, 13 Feb 2002 21:59:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA16079; Wed, 13 Feb 2002 21:28:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA16052 for ; Wed, 13 Feb 2002 21:28:16 -0500 (EST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26025 for ; Wed, 13 Feb 2002 21:28:12 -0500 (EST) Received: from srvmail.cablelabs.com (srvmail.cablelabs.com [10.5.0.15]) by ondar.cablelabs.com (8.10.1/8.10.1) with ESMTP id g1E2Rhb07435; Wed, 13 Feb 2002 19:27:43 -0700 (MST) Received: by srvmail.cablelabs.com with Internet Mail Service (5.5.2653.19) id <1FRAD4SY>; Wed, 13 Feb 2002 19:27:43 -0700 Message-ID: <4DF5E8A771ECD21187020008C7B1C5AF02E9D8BB@srvmail.cablelabs.com> From: Jean-Francois Mule To: "'sip@ietf.org'" , "'rshah@dynamicsoft.com'" Cc: "'klingle@cisco.com'" , "'drwalker@ss8.com'" , "'jmaeng@ipdialog.com'" , Jean-Francois Mule Date: Wed, 13 Feb 2002 19:27:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Approved: ondar Subject: [Sip] I-D submission: SIP MIB draft04 - WGLC comments integrated Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org We've just submitted an update to the sip mib draft, draft-ietf-sip-mib-04.txt. This revision addresses all the comments received during WGLC and we consider wglc done. It should be announced on internet-drafts shortly but in the meantime, you can get it from http://groups.yahoo.com/group/sip-mib/files/ Jean-Francois. > -----Original Message----- > From: Jean-Francois Mule > Sent: Wednesday, February 13, 2002 7:14 PM > To: 'internet-drafts@ietf.org' > Cc: 'klingle@cisco.com'; 'Dave Walker'; 'drwalker@ss8.com'; > 'jmaeng@ipdialog.com'; Jean-Francois Mule > Subject: IETF I-D submission: SIP MIB draft04 > draft-ietf-sip-mib-04.txt > > > This is an update to an existing sip wg I-D. > > Title: Management Information Base for Session Initiation Protocol > > Author(s) : K. Lingle, J. Maeng, J-F. Mule, D. Walker > > Filename : draft-ietf-sip-mib-04.txt > > Working Group: SIP > > Abstract: > This memo defines a portion of the Management Information > Base (MIB) for use with network management protocols in the > Internet community. In particular, it describes a set of > managed objects that are used to manage Session Initiation > Protocol (SIP) entities, which include User Agents, Proxy > servers, Redirect servers and Registrars. > > Regards, > Jean-Francois Mule > CableLabs > jf.mule@cablelabs.com > (303)661-3708 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 14 00:39:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03796 for ; Thu, 14 Feb 2002 00:39:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA29725 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 00:39:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27740; Wed, 13 Feb 2002 23:57:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27711 for ; Wed, 13 Feb 2002 23:57:34 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03117 for ; Wed, 13 Feb 2002 23:57:31 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1E4vo6Y000783; Wed, 13 Feb 2002 23:57:50 -0500 (EST) Message-ID: <3C6B439E.324E2FD7@dynamicsoft.com> Date: Wed, 13 Feb 2002 23:57:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: sip@ietf.org Subject: Re: [Sip] removal of 100rel from bis References: <475FF955A05DD411980D00508B6D5FB00439E8FC@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Just to further clarify; the removal of 100rel from bis will not delay anything. 100rel will go to IESG same day as bis, and get an RFC # along with bis. -Jonathan R. "Drage, Keith (Keith)" wrote: > > NO!!! NO!!! NO!!! > > I am frantically trying to juggle related 3GPP documentation and all I > see > here is a ploy to further derail manyfolks. > > I see nothing below which justifies taking it back out of bis. > > Furthermore, the additional delay of 100 rel that thus results is > unacceptable. It went into WGLC in bis and nobody is raising technical > objections via the list, which is what should be happening if this > change is > justified. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > ---------- > > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > > Sent: 12 February 2002 23:12 > > To: sip@ietf.org > > Subject: [Sip] removal of 100rel from bis > > > > It was out. Then it was in. Now it is going to be out again. > > > > The section on reliability of provisional responses is going to be > > removed from bis-08. The reasons have very little to do with > technology. > > Rather, it is in the interests of maintaining bis as an open and clean > > specification as it has always been; something that people can > implement > > without obstacles. > > > > There will be no change in the specifications, only in which documents > > they > > appear in. draft-ietf-sip-100rel will come back to life, and go to RFC > > along > > with bis and the other key drafts. Furthermore, the last call on > 100rel > > will > > extend backwards in time, starting with the last call of bis. > > > > Thanks, > > Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PH: (973) 952-5000 > > http://www.dynamicsoft.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. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 14 07:22:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16330 for ; Thu, 14 Feb 2002 07:22:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25163 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 07:22:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23995; Thu, 14 Feb 2002 06:59:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23964 for ; Thu, 14 Feb 2002 06:59:36 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15591 for ; Thu, 14 Feb 2002 06:59:33 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id g1EBx4U32423 for ; Thu, 14 Feb 2002 12:59:04 +0100 Received: from vies194a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.1/8.12.1) with ESMTP id g1EBx2kv010519 for ; Thu, 14 Feb 2002 12:59:03 +0100 (MET) Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id <18J37H2J>; Thu, 14 Feb 2002 12:59:01 +0100 Message-ID: From: Brazier Lachlan To: "'sip@ietf.org'" Date: Thu, 14 Feb 2002 12:58:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] CSeq question? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, probably awnsered long ago, but I couldn't find it :-( The reason I ask is, that it wasn't clear to me, if the increasing of the CSeq value in a dialog is bound to a request class (INVITE, BYE, MYREQUEST, etc.) or to requests in general. Do I read the draft correct with: INVITE ..... CSeq: 1 INVITE 200 Ok CSeq: 1 INVITE ACK ---- CSeq: 1 ACK --Dialog is established-- BYE ..... CSeq: 2 BYE 200 Ok CSeq: 2 BYE This means, in the BYE request ( or any other request except of CANCEL + ACK) a CSeq with value "1 BYE" is not allowed? But for CANCEL: INVITE ..... CSeq: 1 INVITE --Dialog is not established-- CANCEL .... CSeq: 1 CANCEL Thanks Lachlan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 14 09:40:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22621 for ; Thu, 14 Feb 2002 09:40:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA01183 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 09:40:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00176; Thu, 14 Feb 2002 09:20:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00145 for ; Thu, 14 Feb 2002 09:20:52 -0500 (EST) Received: from ws1-3.us4.outblaze.com (205-158-62-55.outblaze.com [205.158.62.55]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18625 for ; Thu, 14 Feb 2002 09:20:44 -0500 (EST) Received: (qmail 93519 invoked by uid 1001); 14 Feb 2002 14:20:15 -0000 Message-ID: <20020214142015.93518.qmail@mail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [212.208.74.200] by ws1-3.us4.outblaze.com with http for jfr@post.com; Thu, 14 Feb 2002 22:20:15 +0800 From: "JF Rey" To: sip@ietf.org Date: Thu, 14 Feb 2002 22:20:15 +0800 X-Originating-Ip: 212.208.74.200 X-Originating-Server: ws1-3.us4.outblaze.com Content-Transfer-Encoding: 7bit Subject: [Sip] REFER and Replaces with early dialogs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'm quite sure that someone already asked about this, but I did not find it in the archives. I try to understand whether a SIP phone can transfer another one when the target of the transfer is ringing. draft-biggs-sip-replaces-01.txt states that The to-tag and from-tag parameters MUST be included in the Replaces header, and If the Replaces header matches an unestablished call leg, that it, the INVITE request for the call has not received or been sent a final response, the Replaces header MUST be ignored. I don't understand the last sentence. Why ignore Replaces even if a match was found thanks to it ? In bis07, the to-tag is mandatory for 1xx (other than 100) responses. So, Replaces could match an early dialog as soon as a 1xx (other than 100) is sent/received. Did I overlook something ? Regards, Jean-Francois Rey -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Win a ski trip! http://www.nowcode.com/register.asp?affiliate=1net2phone3a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 14 09:49:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23162 for ; Thu, 14 Feb 2002 09:49:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA01461 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 09:49:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00970; Thu, 14 Feb 2002 09:33:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00939 for ; Thu, 14 Feb 2002 09:33:44 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19765 for ; Thu, 14 Feb 2002 09:33:40 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GRJ00L011QNA4@firewall.wcom.com> for sip@ietf.org; Thu, 14 Feb 2002 14:32:47 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GRJ00K471QMJ3@firewall.wcom.com>; Thu, 14 Feb 2002 14:32:46 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GRJ003011QERN@dgismtp04.wcomnet.com>; Thu, 14 Feb 2002 14:32:46 +0000 (GMT) Received: from ajohnston ([166.42.34.76]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GRJ00LN11Q3Y6@dgismtp04.wcomnet.com>; Thu, 14 Feb 2002 14:32:30 +0000 (GMT) Date: Thu, 14 Feb 2002 08:32:22 -0600 From: Alan Johnston Subject: RE: [Sip] REFER and Replaces with early dialogs In-reply-to: <20020214142015.93518.qmail@mail.com> To: "'JF Rey'" , sip@ietf.org Message-id: <001401c1b564$6bf5c330$66202aa6@ajohnston> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Jean-Francois, The latest version of this draft is: http://search.ietf.org/internet-drafts/draft-ietf-sip-replaces-00.txt and now allows Replaces to match an early dialog. The Service Examples I-D will soon be updated to show some of these flows. Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of JF Rey > Sent: Thursday, February 14, 2002 8:20 AM > To: sip@ietf.org > Subject: [Sip] REFER and Replaces with early dialogs > > > I'm quite sure that someone already asked about this, but I > did not find it in the archives. > > I try to understand whether a SIP phone can transfer another > one when the target of the transfer is ringing. > > draft-biggs-sip-replaces-01.txt states that > > The to-tag and from-tag parameters MUST be included in the > Replaces header, > > and > > If the Replaces header matches an unestablished call leg, that it, > the INVITE request for the call has not received or been > sent a final > response, the Replaces header MUST be ignored. > > I don't understand the last sentence. Why ignore Replaces > even if a match was found thanks to it ? > > In bis07, the to-tag is mandatory for 1xx (other than 100) > responses. So, Replaces > could match an early dialog as soon as a 1xx (other than > 100) is sent/received. > > Did I overlook something ? > > Regards, > > Jean-Francois Rey > -- > > _______________________________________________ > Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Win a ski trip! http://www.nowcode.com/register.asp?affiliate=1net2phone3a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Thu Feb 14 11:01:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25324 for ; Thu, 14 Feb 2002 11:01:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06385 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 11:01:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05096; Thu, 14 Feb 2002 10:45:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05065 for ; Thu, 14 Feb 2002 10:45:12 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24956 for ; Thu, 14 Feb 2002 10:45:10 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1EFWNH01464; Thu, 14 Feb 2002 09:32:23 -0600 Message-ID: <3C6BD887.5000306@dynamicsoft.com> Date: Thu, 14 Feb 2002 09:32:23 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] note: change in URI comparison rules coming References: <3C64894C.4B4DCA96@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The same argument applies to the transport parameter sip:user@domain;transport=udp will always resolve to udp, but sip:user@domain may resolve to tcp through DNS. The next version of bis will reflect sip:user@domain:5060 != sip:user@domain != sip:user@domain;transport=udp RjS Jonathan Rosenberg wrote: > Folks, > > There is a change in the URI comparison rules that is coming. It has > already been discussed in draft-ietf-sip-srv, but I suspect that with > the volume of material flying around these days, it has been missed. > > Previously, the following two URIs were considered equivalent: > > sip:user@domain > sip:user@domain:5060 > > The reasoning was that we figured that the default port ought to equal > an explicit port equal to the default. > > The problem is in the DNS resolution of the URI. There is wide agreement > that, when the port is present, you should use that port. This pretty > much rules out an SRV lookup, since SRV would provide an alternate port, > and there is no way you can use just the host and ignore the port. So, > you need to do an A record lookup. Now, presumably, two URI that are > equivalent ought to be looked up in the same way. So, we cannot look up > the two URIs above differently if they are equal. If we use SRV for > both, we end up ignoring the explicit port. THis results in serious > surprise; a URI pointing to port 5060 explicitly might end up going to a > different port, depending on the URI lookup. Very likely NOT what was > intended. > > As a result of these problems, pointed out to us by DNS experts within > IETF, draft-ietf-sip-srv is simple on this one. If there is a port, you > use that port, and do A record lookup on the host value. No exceptions. > This means that the two URI above are NOT equal any longer. > > This will be reflected in the URI comparison rules in bis-08. > > Will this introduce interop problems? I tend to doubt it. Right now, URI > equality is needed in (1) dialog identification, (2) matching > address-of-records into location service, (3) checking whether a contact > has been updated in a registration. In the case of (1), its the From and > To fields, which almost never have ports, and anyway, you're not likely > to see someone put in a port and then someone strip it in a request in > the reverse direction. Regarding (2), AOR shouldn't really have ports, > (3) will only be an issue if the same UA decides to send one > registration for a contact without a port, and update it with a port. I > consider that unlikely too. So, I dont think there are any serious > repercussions here. However, if you think this is a problem for you, > please speak up. > > 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 daemon@optimus.ietf.org Thu Feb 14 11:19:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25931 for ; Thu, 14 Feb 2002 11:19:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08136 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 11:19:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06469; Thu, 14 Feb 2002 11:03:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06439 for ; Thu, 14 Feb 2002 11:03:27 -0500 (EST) Received: from cvis22.marconicomms.com (cvis22.marconicomms.com [195.99.244.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25358 for ; Thu, 14 Feb 2002 11:03:21 -0500 (EST) Received: from cvis05.marconicomms.com (unverified) by cvis22.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 14 Feb 2002 16:02:40 +0000 Received: from cvdgwy01.uk.marconicomms.com by cvis05.marconicomms.com with ESMTP (8.10.2+Sun/cvms-34) id g1EG2lK20521; Thu, 14 Feb 2002 16:02:47 GMT To: sip@ietf.org From: "Keith Robinson" Date: Thu, 14 Feb 2002 16:02:02 +0000 Message-ID: X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at 14/02/2002 16:02:40 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Sip] routing query Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, What is the reasoning behind the routing rule that limits a destination set to contain only 1 member if the Route header is not empty, when resolving a R-URI in the administrative domain of the proxy ? Thanks, K. Robinson ------------ This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 14 11:31:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26356 for ; Thu, 14 Feb 2002 11:31:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09188 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 11:31:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06717; Thu, 14 Feb 2002 11:07:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06689 for ; Thu, 14 Feb 2002 11:07:51 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25514 for ; Thu, 14 Feb 2002 11:07:48 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 14 Feb 2002 16:08:05 UT content-class: urn:content-classes:message Subject: RE: [Sip] note: change in URI comparison rules coming MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 14 Feb 2002 16:09:47 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <45730E094814E44488F789C1CDED27AE012F8264@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] note: change in URI comparison rules coming Thread-Index: AcG1bx3f94ir4eQVRT67ARNTOkiTeAAAoyxA From: "James Undery" To: "Robert Sparks" , "Jonathan Rosenberg" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA06690 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Is sip:10.0.0.1 == sip:10.0.0.1;transport=udp still going to hold? James > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: 14 February 2002 15:32 > To: Jonathan Rosenberg > Cc: sip@ietf.org > Subject: Re: [Sip] note: change in URI comparison rules coming > > > The same argument applies to the transport parameter > sip:user@domain;transport=udp will always resolve to udp, > but > sip:user@domain may resolve to tcp through DNS. > > The next version of bis will reflect > > sip:user@domain:5060 != sip:user@domain != > sip:user@domain;transport=udp > > > RjS > > Jonathan Rosenberg wrote: > > > Folks, > > > > There is a change in the URI comparison rules that is coming. It has > > already been discussed in draft-ietf-sip-srv, but I suspect > that with > > the volume of material flying around these days, it has been missed. > > > > Previously, the following two URIs were considered equivalent: > > > > sip:user@domain > > sip:user@domain:5060 > > > > The reasoning was that we figured that the default port > ought to equal > > an explicit port equal to the default. > > > > The problem is in the DNS resolution of the URI. There is > wide agreement > > that, when the port is present, you should use that port. > This pretty > > much rules out an SRV lookup, since SRV would provide an > alternate port, > > and there is no way you can use just the host and ignore > the port. So, > > you need to do an A record lookup. Now, presumably, two URI that are > > equivalent ought to be looked up in the same way. So, we > cannot look up > > the two URIs above differently if they are equal. If we use SRV for > > both, we end up ignoring the explicit port. THis results in serious > > surprise; a URI pointing to port 5060 explicitly might end > up going to a > > different port, depending on the URI lookup. Very likely > NOT what was > > intended. > > > > As a result of these problems, pointed out to us by DNS > experts within > > IETF, draft-ietf-sip-srv is simple on this one. If there is > a port, you > > use that port, and do A record lookup on the host value. No > exceptions. > > This means that the two URI above are NOT equal any longer. > > > > This will be reflected in the URI comparison rules in bis-08. > > > > Will this introduce interop problems? I tend to doubt it. > Right now, URI > > equality is needed in (1) dialog identification, (2) matching > > address-of-records into location service, (3) checking > whether a contact > > has been updated in a registration. In the case of (1), its > the From and > > To fields, which almost never have ports, and anyway, > you're not likely > > to see someone put in a port and then someone strip it in a > request in > > the reverse direction. Regarding (2), AOR shouldn't really > have ports, > > (3) will only be an issue if the same UA decides to send one > > registration for a contact without a port, and update it > with a port. I > > consider that unlikely too. So, I dont think there are any serious > > repercussions here. However, if you think this is a problem for you, > > please speak up. > > > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 14 11:59:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27639 for ; Thu, 14 Feb 2002 11:59:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10929 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 11:59:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09551; Thu, 14 Feb 2002 11:37:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09506 for ; Thu, 14 Feb 2002 11:37:16 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26656 for ; Thu, 14 Feb 2002 11:37:12 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA12862; Thu, 14 Feb 2002 17:37:13 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA18665; Thu, 14 Feb 2002 17:37:06 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id <1DHMPJX5>; Thu, 14 Feb 2002 17:37:12 +0100 Message-ID: From: Mayer Georg To: "'Jonathan Rosenberg'" , Mayer Georg Cc: Gonzalo Camarillo , Hisham Khartabil , sip@ietf.org Subject: AW: AW: [Sip] PRACK holding the offer Date: Thu, 14 Feb 2002 17:37:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA09507 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hello Jonathan et al, thanks for the answer - I have another question on this issue. As you know I work with 3G and our scenarios up till now use the manyfolks draft as the basis for SDP negotiation. I am convinced that the new solutions as proposed in the unify draft will solve our requirements too and some 3G delegates (including me) will propose a complete change of the 3G flows to the new unify solution. Still I have a question ... With manyfolks we had a fixed three-way handshake and COMET was the indication that ressource reservation has finnished. The involved entities knew that after three SDP exchanges they are allowed to reserve ressources. With the new solution I do not see how both sides know when the "final" SDP answer was sent / has arrived and ressources can be reserved. In theory both sides can go on sending UPDATEs again and again. For 3G we need a very clear criteria that tells us that ressource reservation can now be done as (e.g.) SDP negotiation has now finished for the time of dialog establishment. I am aware that UPDATE can be sent at any time during the dialog, to change the media. But there needs to be an indication saying that for a certain change media can be reserved. Can you please tell me how such a mechanism will be achieved with the unified procedures? Thanks Georg _______________________________________________________ Georg Mayer - Siemens AG Information and Communication Mobile ICM N PG SP ST N 1 Hofmannstr. 51, 81359 Munich, Germany Fon: +49-89-722-33114 Fax: +49-89-722-62250 Mobile: +49-172-5371233 Email: georg.mayer@icn.siemens.de > -----Urspr�ngliche Nachricht----- > Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Gesendet: Mittwoch, 13. Februar 2002 21:15 > An: Mayer Georg > Cc: Gonzalo Camarillo; Hisham Khartabil; sip@ietf.org > Betreff: Re: AW: [Sip] PRACK holding the offer > > > > > Mayer Georg wrote: > > > > Hello, > > > > does this mean the PRACK will generally not be allowed to carry SDP > > information or were the comments below only based on the initially > > described scenario (no SDP in INVITE and 183)? > > No, we are only talking about the initial offer. > > It is allowed for the following to occur: > > inital offer in the initial INVITE > initial answer in the 18x > second offer in PRACK > second answer in 2xx > > Take a look at the rules about this in bis-07. > > > > > >From 3GPP point of view it would be of great value of > INVITE/183 and its > > PRACK/200 could carry SDP, follwed by COMET/200 after ressource > > reservation. > > UPDATE/COMET would also be allowed to contain offers after the initial > exchanges have completed, yes. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 14 12:39:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00909 for ; Thu, 14 Feb 2002 12:39:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14226 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 12:39:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13239; Thu, 14 Feb 2002 12:23:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13209 for ; Thu, 14 Feb 2002 12:23:15 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00172 for ; Thu, 14 Feb 2002 12:23:11 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1EHNU6Y001634; Thu, 14 Feb 2002 12:23:30 -0500 (EST) Message-ID: <3C6BF261.68759757@dynamicsoft.com> Date: Thu, 14 Feb 2002 12:22:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Undery CC: Robert Sparks , sip@ietf.org Subject: Re: [Sip] note: change in URI comparison rules coming References: <45730E094814E44488F789C1CDED27AE012F8264@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit James Undery wrote: > > Is sip:10.0.0.1 == sip:10.0.0.1;transport=udp still going to hold? Funny you should ask, I just had a call with Robert on just this. No, these will no longer be equal. I really, really, really don't want URI comparison rules to be specific on whether its an IP address or not. Effectively, since its possible that, in some cases, sip:foo;transport=udp and sip:foo won't resolve to the same thing, these are not equal. There are cases where they may, but the same is true for things like: sip:example.com and sip:192.0.34.72 even though these will also refer to the same thing after DNS resolution. The latter has always been declared to be not equal. Equality means "these are always the same". Inequality is the inverse, which is "these aren't always the same". -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 14 12:40:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00932 for ; Thu, 14 Feb 2002 12:40:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14245 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 12:40:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12717; Thu, 14 Feb 2002 12:10:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12686 for ; Thu, 14 Feb 2002 12:10:51 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27940 for ; Thu, 14 Feb 2002 12:10:47 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1EHB06Y001615; Thu, 14 Feb 2002 12:11:02 -0500 (EST) Message-ID: <3C6BEF74.730599C5@dynamicsoft.com> Date: Thu, 14 Feb 2002 12:10:12 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mayer Georg CC: Gonzalo Camarillo , Hisham Khartabil , sip@ietf.org Subject: Re: AW: AW: [Sip] PRACK holding the offer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mayer Georg wrote: > > Hello Jonathan et al, > > thanks for the answer - I have another question on this issue. As you > know I work with 3G and our scenarios up till now use the manyfolks > draft as the basis for SDP negotiation. I am convinced that the new > solutions as proposed in the unify draft will solve our requirements too > and some 3G delegates (including me) will propose a complete change of > the 3G flows to the new unify solution. Still I have a question ... > > With manyfolks we had a fixed three-way handshake and COMET was the > indication that ressource reservation has finnished. The involved > entities knew that after three SDP exchanges they are allowed to reserve > ressources. Note that, in the current manyfolks, the final exchange is only needed to negotiate down a codec set, for example. > > With the new solution I do not see how both sides know when the "final" > SDP answer was sent / has arrived and ressources can be reserved. In > theory both sides can go on sending UPDATEs again and again. For 3G we > need a very clear criteria that tells us that ressource reservation can > now be done as (e.g.) SDP negotiation has now finished for the time of > dialog establishment. OK, so here is how it works with unify. A session has state associated with it. That state is things like the set of codecs, the ptime attributes, sendonly/recvonly, etc. UPDATE, generally, can change these, just like INVITE can. The first step of unify is to review reservations as just another piece of state associated with a stream, NO DIFFERENT that the directionality. Those states inlcude things like "no resveration", "reserved in the recv direction", "reserved in the send direction" and "reserved in both directions". UPDATE can update this state. Independent of that, there is a notion of a precondition. This precondition states that "don't ring the phone until this piece of session state achieves this value". That precondition is expressed using Require plus an sdp param that indicates what the desired state is. Once the session state (in this case, the reservation) achieves the desired value as a result of an UPDATE, the phone can ring. SO, the flow would be thus. A sends an INVITE to B, with an audio stream. The reservation state is present, set to "no reservation". There is the require header in there, and a precondition of "reservation state = reserved in both directions". B gets this, doesn't ring the phone. It sends a 183 w/ the answer. Its SDP also indicates that the reservation state is unreserved. After this, both sides reserve (or, the may do another o/a exchange in PRACK/2xx to subset of the codecs, if needed). Once reservations complete, the state of the reservations have changed. From A's perspective, the state is now, "reserbed in the recv direction", so it would send an UPDATE to update that state. Once B learns that its reservation is done (assuming rsvp style reservations w/o confirmation), it can then ring the phone, since from its perspective, the shared reservation state then achieves the value of "reserved in both directions" and the precondition is met. Note that, the requirement of the mechanism is merely that the precondition is met; this is through local knowledge and a combination of signaled information, as needed. It is perfectly reasonable for any of the following to happen: 1. if reservation confirmations exist in the reservation protocol, the callee may know through those that the reservations have completed in both directions, and therefore it can ring the phone before receiving an UPDATE from A, which need not even be sent. 2. the reservations may exist before the call is made. In that case, the INVITE SDP would indicate a state of "reserved in both directions" immmediately, with the precondition, and ringing could take place immediately upon receipt of the INVITE. With this model, it is also easy to fix the (IMHO big) problem of manyfolks today, which is its strong bias towards e2e reservation. We can have parameters for any model of reservation state, and as long as those are defined, UPDATE can modify them. So, for example, we could have a segmented reservation parameter, which expresses a local reservation only. Such a parameter would have four states: unreserved locally and remotely reserved locally, not remotely reserved remotely, not locally reserved locally and remotely you can bump that to 16 states if you want to have directional reservations on each link. Then, the precondition is an expression of a particular state, such as "reserved locally and remotely". So, consider the case of access only reservations, and a case where the reservation is done on the calling side before the call starts (note that, with access reservations, there may not be a need to know the remote party address before making the reservation). So, the INVITE would be like: INVITE reservation state = "reserved locally, not remotely" preconditon = "reserved locally and remotely" the callee gets this. It does its link reservation. Thus, the state is now the desired "reserved locally and remotely". The precondition is met. The phone rings. The following is sent in the 180: 180 reservation state= "reserved locally and remotely" In my view, the precondition state is always represented by a value of another existing parameter. This makes it far broader in applicability than the currently documented mechanisms, and also allows for trivial definition of other reservation state variables that can more readily represent different deployments. Furthermore, the additional message exchanges may not always be needed, depending on the specific preconditions and the specific reservation capabilities. Sorry for the long note, I hope that helps. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 14 12:40:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00948 for ; Thu, 14 Feb 2002 12:40:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14261 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 12:40:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12942; Thu, 14 Feb 2002 12:17:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12913 for ; Thu, 14 Feb 2002 12:17:25 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29404 for ; Thu, 14 Feb 2002 12:17:20 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1EHHf6Y001619; Thu, 14 Feb 2002 12:17:41 -0500 (EST) Message-ID: <3C6BF104.8BC2FACA@dynamicsoft.com> Date: Thu, 14 Feb 2002 12:16:52 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson CC: sip@ietf.org Subject: Re: [Sip] routing query References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Keith Robinson wrote: > > Hello, > > What is the reasoning behind the routing rule that limits a destination > set > to contain only 1 member if the Route header is not empty, when > resolving > a R-URI in the administrative domain of the proxy ? Well, this restriction has actually been booted in the current working editors copy. So, good point. Let me explain why it was there, and why we booted it. One of the main purposes of record-routing it so establish a specific path from caller to callee. These are indicated through the route headers in subsequent requests in the dialog. If a mid-dialog request is forked, for example, we may end up creating new calls or other bad things, when that is not intended. Turns out, forking won't happen anyway. The reason for this was the very important realiztion that the r-uri in the mid-dialog reuqests MUST BE THE CONTACT of the far end. That is, you are sending the request to that specific endpoint, the record-routes specify intermediate hops. Noting also that proxies only rewrite r-uris in their own domain of control, things work nicely. A contact header of sip:jdrosen@1.2.3.4 is only under the control of 1.2.3.4, my PC. Thus, as this request traverses proxies on the route set, none of them will rewrite the r-uri (as it is sip:jdrosen@1.2.3.4, not under their control), none of of them will fork as a result, and we achieved the desired goal without explicitly mandating that there be no forking for mid-dialog requests. Now, we also came across cases where we wanted to fork when route was present. This was specifically in the service routing scenarios. Consider an S-CSCF that sends a request to an app server, and puts a route in there to force the AS to send the requests back to it. Now, that proxy should be allowed to fork, if its service demands it. Both requests would carry the route headers to carry it back to the S-CSCF. This is perfectly reasonable and breaks nothing if you do it. So, the ban is removed, resulting in yet another nice simplification of the whole route/record-route mess. This will be reflected in -08, of course. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 14 13:21:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05244 for ; Thu, 14 Feb 2002 13:21:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15893 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 13:21:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15390; Thu, 14 Feb 2002 13:07:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15360 for ; Thu, 14 Feb 2002 13:07:52 -0500 (EST) Received: from commserver.iperia.com ([63.84.167.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04633 for ; Thu, 14 Feb 2002 13:07:48 -0500 (EST) Received: by commserver.erictest.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Feb 2002 13:07:18 -0500 Message-ID: <1A69639B9B6AD511812B00B0D0DE19F6613092@commserver.erictest.com> From: Colleen Lashway To: sip@ietf.org Date: Thu, 14 Feb 2002 13:07:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] draft-mahy-sip-message-waiting-0x? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I just joined this mailing list... I'm looking for the latest mahy draft that defines message waiting. The 02 version expired in January. Is there a new one? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 14 13:21:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05275 for ; Thu, 14 Feb 2002 13:21:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15933 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 13:21:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15325; Thu, 14 Feb 2002 13:07:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15300 for ; Thu, 14 Feb 2002 13:07:22 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04601 for ; Thu, 14 Feb 2002 13:07:20 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id ACD953680288; Thu, 14 Feb 2002 13:07:21 -0500 Message-ID: <001201c1b582$55b3b0a0$2300000a@acmepacket.com> From: "Bob Penfield" To: Date: Thu, 14 Feb 2002 13:06:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] comments on draft-ietf-sip-events-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Here are some comments on the SIP Events draft. I found the draft well organized and easy to understand. The only trouble I had was with dialog & route-set establishment. It is a little tricky depending on whether one or multiple dialogs are to be established. As I understand it, for a SUBSCRIBE sent outside of a dialog, a new dialog can be established either by the 2xx response to the SUBSCRIBE or the first NOTIFY request. If the package and the subscriber are willing to accept multiple dialogs, the 2xx response or the first NOTIFY from the notifier that sent the 2xx response establishes one dialog, and each initial NOTIFY from other notifiers establish an additional dialog. Now, if the package or the subscriber requires only one dialog, either the 2xx response or the first NOTIFY received (using the matching rules in 4.3.4) establishes the dialog (which ever arrives first wins), and the route set for the dialog comes from the record-routes in that message. The part that might get confused by implementers is when the NOTIFY arrives first, and the 2xx that arrives later does not come from the notifier that sent the NOTIFY. In this case, the 2xx's dialog-id (as defined in bis) will not match the dialog-id established by the NOTIFY. This 2xx response DOES NOT establish a new dialog and the subscriber MUST NOT use the record-route & contact from the 2xx as the route-set for the existing dialog since they point at the wrong notifier. Have I got that right? Here are some specific comments: sec 4.1.1, 3rd para. The restriction on the server changing the expire period disagrees with that in section 4.1.6.1. You may want to just refer to that section rather than having the rule duplicated. sec 4.2.3: Why is record-routing a MUST on all SUBSCRIBE and NOTIFY requests? It certainly needs to be on the SUB & NOT that establish dialogs, but bis-07 does not allow the route to be changed (only the target), so it just seems like wasted bandwidth especially on subsequent NOTIFYs within the dialog. sec 4.2.4: I think you need a statement requiring a timely response to a NOTIFY similar to one for SUBSCRIBE in the 1st paragraph of 4.1.6.1. The statement "Once the notification is deemed acceptable to the subscriber..." might be interpreted as allowing user (human) input/verification. sec 4.3.3: I suggest adding "In accordance with the rules for proxying non-INVITE requests in [1]" at the start of the first sentence so it is clear that it is a basic SIP requirement. sec 4.3.4: 1st para: s/sent on an pre-existing/sent on a pre-existing/ sec 4.3.4: 3rd para, last sent: s/unless the have/unless they have/ sec 5.4.7: 2nd para: s/used to processes the/used to process the/ sec 5.4.9: 3rd para: s/forked INVITE/forked SUBSCRIBE/ cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.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 daemon@optimus.ietf.org Thu Feb 14 16:33:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10341 for ; Thu, 14 Feb 2002 16:33:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28411 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 16:33:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26756; Thu, 14 Feb 2002 16:03:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26729 for ; Thu, 14 Feb 2002 16:03:19 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09678 for ; Thu, 14 Feb 2002 16:03:15 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1EL2ZZ21769; Thu, 14 Feb 2002 13:02:35 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACM35444; Thu, 14 Feb 2002 13:02:42 -0800 (PST) Date: Thu, 14 Feb 2002 13:01:28 -0800 (Pacific Standard Time) From: Rohan Mahy To: clashway@iperia.com cc: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] re: message waiting draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Due to dependencies on the sip-events draft and a future statement about guidelines for new event packages, I will not be making any changes to the message waiting draft until the event guidelines are stable. I suspect i'll will have -03 out in time for IETF 54 in July. Please note that unless I receive unexpected comments, -03 will be mostly a process and organizational update to conform with the event guidelines. Please continue to use the -02 version until -03 is submitted. The -02 version is available at the supplemental website: http://www.softarmor.com/sipping/drafts/ and archived at: ftp://ftpeng.cisco.com/~rmahy/ 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 daemon@optimus.ietf.org Thu Feb 14 16:55:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10921 for ; Thu, 14 Feb 2002 16:55:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29353 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 16:55:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28673; Thu, 14 Feb 2002 16:38:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28642 for ; Thu, 14 Feb 2002 16:38:38 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10422 for ; Thu, 14 Feb 2002 16:38:33 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1ELavZ07814; Thu, 14 Feb 2002 13:37:54 -0800 (PST) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint) with SMTP id ACM35922 (AUTH rmahy); Thu, 14 Feb 2002 13:37:05 -0800 (PST) Message-Id: <200202142137.ACM35922@imop.cisco.com> Received: from 171.68.225.134 by imop.cisco.com with HTTP/1.0; Thu, 14 Feb 2002 13:37:21 -0800 Date: Thu, 14 Feb 2002 13:37:21 -0800 From: Rohan Mahy Subject: Re: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt To: "Rick W. Porter" Cc: sip@ietf.org X-Mailer: Mirapoint Webmail Direct 2.9.1.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi All, Can we PLEASE move this discussion to SIPPING! Henning, will you please resubmit your draft as: draft-schulzrinne-sipping-accounting-00.txt So that folks (including the author ;-) don't get confused and use the wrong list. thanks, -rohan the enforcer SIPPING co-chair ---- Original message ---- >Date: Wed, 13 Feb 2002 11:09:44 -0500 >From: "Rick W. Porter" >Subject: [Sip] comments on draft-schulzrinne-accounting-sip- 00.txt >To: > >Generally, I like the idea of standardizing the basic SIP- RADIUS Accounting >relationship, but there are a couple issues that should be addressed by >something defining that relationship. I have one "major" concern, and a few >smaller details. > >My major concern is the draft does not address branching scenarios. The SIP >Call-Id will be the same for all branches, and there is nothing in the >RADIUS message to distinguish each branch. The back-end RADIUS processing >may break down if the fundamental assumption of one Start and one Stop per >session is violated. I see two possible solutions: include the Branch-ID for >all RADIUS messages, or make the SIP proxy stateful enough to generate >RADIUS messages for only chosen branch (or the whole session if all branches >fail). > >My detailed concerns are listed by section comments below: > >Section 5.1 (User-name, p4) - >If the intent of this attribute is to establish responsibility for the >session, it does not work unless the SIP proxy is session stateful! The only >way to record responsibility is when the SIP proxy receives the initial >INVITE (or the first one that is Authenticated), because the SIP message >From, To, and Authentication username, will change based on who initiates >each SIP message, not who initiated the session. Therefore, I think the >attribute fails to meet the its intent. Furthermore, without Authentication >this attribute will be redundant--why include the information twice? Maybe >make this should be an optional RADIUS attribute that is include if >authentication is done? > >Section 5.5 (Acct-Status-Type, p6) - >It appears that the draft suggests generating an Interim- Update to report >receiving all SIP messages other than initial INVITEs, BYEs, and failures >for initial INVITEs. This creates potential problems for branching >scenarios as discussed above. > >Section 5.6 (Acct-Delay-Time, p7) - >By including this attribute, the RADUIS message must get a new ID and the >authenticator must be recalculated each time the message is retransmitted. >It would seem to me that it is more efficient to let messages age with the >"time sensitive" information included as part of the original message (i.e. >Event-timestamp). Or, do RADIUS servers do something useful with the >Acct-Delay-Time attribute? > >Section 5.9 (Acct-Session-Time, p8) - >First, unless your SIP proxy is session stateful, where do you get the >information to calculate this? Second, since the amount of time from >receiving the INVITE to receiving the 200-OK is not deterministic, it seems >to me that this time should be 0 for all sessions that never received the >200-OK; again, the SIP proxy needs to be session stateful to get this >information. You wouldn't want to get a phone bill for attempted calls where >the line was busy, so the reported time should be the time from the 200-OK >to the BYE. > >Section 5.10 (Acct-Terminate-Cause, p9) - >How do SIP events map to the RADIUS values? Some are intuitive (i.e. BYE = >User Request), but others are not (404, 482, 500, ...). > >Section 5.14 (Sip-From, p12) and Section 5.15 (Sip-From, p12) - >Why not use the Calling-Station-Id and Called-Station-Id instead of defining >new attributes? > >Section 5.17 (Sip-Remote-IP-Address, p14) and Section 5.18 (Sip-Remote-Port, >p14) - >First, I would suggest a name change to Sip-Previous-IP- Address and >Sip-Previous-Port, since there may be a inbound and outbound Remote IP >Address/Port. Second, where does this info come from (Rec- Route header? Via >header? or socket?) There may be minor NAT issues that may be intertwined >with your choice. > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Thu Feb 14 18:11:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12402 for ; Thu, 14 Feb 2002 18:11:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA02564 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 18:11:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01649; Thu, 14 Feb 2002 17:48:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01620 for ; Thu, 14 Feb 2002 17:48:17 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12042 for ; Thu, 14 Feb 2002 17:48:14 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1EMZIH02263; Thu, 14 Feb 2002 16:35:19 -0600 Message-ID: <3C6C3BA6.1060503@dynamicsoft.com> Date: Thu, 14 Feb 2002 16:35:18 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: James Undery CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] note: change in URI comparison rules coming References: <45730E094814E44488F789C1CDED27AE012F8264@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The current proposal is no. Those two URLs will resolve to the same host/port/transport, but making the URLs equivalent will require separate equality rules for when the hostpart is an IPv4 address vs a DNS name. RjS James Undery wrote: > Is sip:10.0.0.1 == sip:10.0.0.1;transport=udp still going to hold? > > James > > >>-----Original Message----- >>From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >>Sent: 14 February 2002 15:32 >>To: Jonathan Rosenberg >>Cc: sip@ietf.org >>Subject: Re: [Sip] note: change in URI comparison rules coming >> >> >>The same argument applies to the transport parameter >>sip:user@domain;transport=udp will always resolve to udp, >>but >>sip:user@domain may resolve to tcp through DNS. >> >>The next version of bis will reflect >> >>sip:user@domain:5060 != sip:user@domain != >>sip:user@domain;transport=udp >> >> >>RjS >> >>Jonathan Rosenberg wrote: >> >> >>>Folks, >>> >>>There is a change in the URI comparison rules that is coming. It has >>>already been discussed in draft-ietf-sip-srv, but I suspect >>> >>that with >> >>>the volume of material flying around these days, it has been missed. >>> >>>Previously, the following two URIs were considered equivalent: >>> >>>sip:user@domain >>>sip:user@domain:5060 >>> >>>The reasoning was that we figured that the default port >>> >>ought to equal >> >>>an explicit port equal to the default. >>> >>>The problem is in the DNS resolution of the URI. There is >>> >>wide agreement >> >>>that, when the port is present, you should use that port. >>> >>This pretty >> >>>much rules out an SRV lookup, since SRV would provide an >>> >>alternate port, >> >>>and there is no way you can use just the host and ignore >>> >>the port. So, >> >>>you need to do an A record lookup. Now, presumably, two URI that are >>>equivalent ought to be looked up in the same way. So, we >>> >>cannot look up >> >>>the two URIs above differently if they are equal. If we use SRV for >>>both, we end up ignoring the explicit port. THis results in serious >>>surprise; a URI pointing to port 5060 explicitly might end >>> >>up going to a >> >>>different port, depending on the URI lookup. Very likely >>> >>NOT what was >> >>>intended. >>> >>>As a result of these problems, pointed out to us by DNS >>> >>experts within >> >>>IETF, draft-ietf-sip-srv is simple on this one. If there is >>> >>a port, you >> >>>use that port, and do A record lookup on the host value. No >>> >>exceptions. >> >>>This means that the two URI above are NOT equal any longer. >>> >>>This will be reflected in the URI comparison rules in bis-08. >>> >>>Will this introduce interop problems? I tend to doubt it. >>> >>Right now, URI >> >>>equality is needed in (1) dialog identification, (2) matching >>>address-of-records into location service, (3) checking >>> >>whether a contact >> >>>has been updated in a registration. In the case of (1), its >>> >>the From and >> >>>To fields, which almost never have ports, and anyway, >>> >>you're not likely >> >>>to see someone put in a port and then someone strip it in a >>> >>request in >> >>>the reverse direction. Regarding (2), AOR shouldn't really >>> >>have ports, >> >>>(3) will only be an issue if the same UA decides to send one >>>registration for a contact without a port, and update it >>> >>with a port. I >> >>>consider that unlikely too. So, I dont think there are any serious >>>repercussions here. However, if you think this is a problem for you, >>>please speak up. >>> >>>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 >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 14 19:21:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13351 for ; Thu, 14 Feb 2002 19:21:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA05396 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 19:21:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04771; Thu, 14 Feb 2002 19:02:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04740 for ; Thu, 14 Feb 2002 19:02:11 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13044 for ; Thu, 14 Feb 2002 19:02:07 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1F018Z18135; Thu, 14 Feb 2002 16:01:12 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW93315; Thu, 14 Feb 2002 16:00:46 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA27829; Thu, 14 Feb 2002 16:01:15 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15468.20426.981872.401481@thomasm-u1.cisco.com> Date: Thu, 14 Feb 2002 16:01:14 -0800 (PST) To: Juha Heinanen Cc: Jonathan Rosenberg , Lawrence Conroy , Henry Sinnreich , "'Michael Thomas'" , "'Peterson, Jon'" , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: <15466.36777.821785.996536@harjus.eng.song.fi> References: <3C6A8999.51BDBCF3@dynamicsoft.com> <15466.36777.821785.996536@harjus.eng.song.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha Heinanen writes: > i have seen sip UAs that support basic authentication together with tls > and digest authentication without any transport layer security, but i > haven't heard of any that would do smime. > > is there any? if not, then does it make sense to have smimi in the bis. I don't think so. The addition of SMIME seems to be a solution in search of problem. Also: SMIME is a complete pig. I can't imagine any low end UA's implementing it. It certainly doesn't deserve "SHOULD" status. 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 daemon@optimus.ietf.org Thu Feb 14 23:46:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18964 for ; Thu, 14 Feb 2002 23:46:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA15479 for sip-archive@odin.ietf.org; Thu, 14 Feb 2002 23:46:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12852; Thu, 14 Feb 2002 22:43:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12730 for ; Thu, 14 Feb 2002 22:43:08 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17926 for ; Thu, 14 Feb 2002 22:43:03 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [132.151.1.176]) with SMTP; 15 Feb 2002 03:43:20 UT Received: from jolaptop ([80.3.216.239]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 15 Feb 2002 03:45:01 +0000 From: "Jo Hornsby" To: Cc: Date: Fri, 15 Feb 2002 03:46:29 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-OriginalArrivalTime: 15 Feb 2002 03:45:01.0976 (UTC) FILETIME=[25C94980:01C1B5D3] Content-Transfer-Encoding: 7bit Subject: [Sip] Comments on bis-07. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi. Okay, so first-off, a number of points to note: o All comments are initially based on the .txt version of the Draft. If I was supposed to look at the PDF, or PS, then I do not want to know. I will have to kill myself. o I think that this has already been mentioned on the list, but a lot of the Reference numbers (i.e., the "[xx]"s) seem screwed. o I also realize that PRACK is being ripped out. However, I have mentioned issues anyway, in case some of the text will be moved verbatim. o I have tried to trap each occurrence of the first use of a particular term. This may well be bogus, but I don't want to have to repeat this paragraph in each instance, so please forgive me if I am just being silly. o There are a number of places where there seem to be more blank lines than are necessary. I have ignored these since it gives me a comeback for when someone / everyone accuses me of being too picky. I will note occurrences on a later parse if so desired.... o A repeated error seemed to be that Call-IDs in example messages were missing the @FQDN. I realize that this is not illegal, but is it what was intended? o I have not noted some inconsistent terminology. I will write a followup email about that. Hopefully. And without further ado: * 20: s/the users/a user's/ * 22: s/ontop/on top/ * 300: Not sure to what "services" applies here. Should this read "applications"? * 315: First use of "URI". * 368: First use of "HTTP". * 369: s/"Method"/"method"/ ? * 399: First use of "IP". &:) * 402: Perhaps add "within a dialog" after "for each new request"? * 404: First use of "FQDN". * 406: Perhaps remove "for this dialog", since Contact now has "global" scope, right? * 418: First use of "DHCP". * 424: Also mention Vias here (since these days they most important in correlating responses)? * 431: s/Atlanta.com/atlanta.com/ * 441: Unfortunately, since the proxies returned 100s, they have to retain state. (But the inaccuracy probably doesn't particularly hurt.) * 469: Broken "Call- ID". * 484: I find the "is sent by Alice to Bob" slightly confusing, as it makes me think that Alice has been proactive in some way. Maybe "Alice's UA to Bob's UA"? Although this might be the first occurrence of UA. &:) * 488: Remove "and is the end of the transaction"? Since really it's two transactions, and explaining otherwise could get hairy, I worried. * 507: Broken "non- INVITE". * 524: Space between "location service" and "," (but not in the PDF; hmmm... is this because of the italicisiness, or something; I'll keep noting, anyway, just in case). * 532: How about "a set of zero or more URIs that tell" instead of "a translated URI that tells"? * 537: Change beginning of line to "on a request-by- request _basis, by a_ challenge/response mechanism, or using a"? * 563: First mention of "UAC". Perhaps s/UAC/user agent client (UAC)/ ? * 576: Perhaps s/UAS/user agent server (UAS)/ ? * 584: Perhaps s/UA/user agent (UA)/ ? * 619: I think it would be helpful if we changed to something like "A call stateful proxy is always _(transation)_ stateful, but the converse is not _necessarily_ true"? * 623: I don't think that UAC and UAS make much sense when talking about a dialog, since their role changes over time. Howsabout s/a UAC and UAS/2 UAs/ ? * 633 [Uber-nit]: Should this be "Home Domain" or "Home domain"? Approach is inconsistent in this entire section. * 666: Space between "sequential search" and "," in .txt. Could be the old italics. * 671: Missing a trailing "."; however, is present in the PDF, so could be the old italics. * 677: Perhaps "...when it generates a new request to _one or more of_ the URIs in the Contact"? * 679: To affirm the notion of logical roles, perhaps "A redirect server is a server that generates a 3xx response to a request"? * 697: Should this actually be "non-2xx and non-6xx"? (I'm not sure. But it would seem to make sense, given the suggested behaviour when parallel forking.) * 702-703: Spaces before commas again in .txt. Fault of the Italics? * 706: s/was a non-2xx/was a non-2xx to an INVITE/ perhaps? * 735: A small point, but perhaps this should be "If it receives a request later on, it _may assume_ the role of a user agent server"? Since the "piece of software" could also be capable of functioning as a proxy? * 797: s/SIP-version/SIP-Version/ * 852: Seems to be an extra space between "field-name" and "field-value" (certainly in .txt). * 914: First mention of "UDP". * Section 7.4: CANCEL requests / responses cannot contain a body, right? This is probably worth noting here. * 942: I'm not sure what the "Likewise" is pertaining to? Should it read "Like HTTP, however" or sommat? * 943: Missing terminating ".". * 950: Probably just me, but I'd find "zero or more proxy servers" a little clearer than "some number of proxy servers". * 975: s/register/a REGISTER/ ? * 978-979, Sentence beginning "Commonly": I find this a little confusing, since all the methods explicitly mentioned are non-SIP. Is there an "other" missing from between "some" and "non-SIP"? * 988: Perhaps s/SIP URI/SIP URI scheme/ ? * 997: It might be helpful to note that this is only an option when the entered string could actually reasonably be a tel URL; e.g., it's just digits? * 1003: Since this is the first use, it might be useful to explicitly spell out "tag" parameter. * 1008: "general-header" not good. * 1046: s/Cseq/CSeq/ * 1048: The "the sequence number value is arbitrary" assertion is not true for REGISTER. Perhaps "For non-REGISTER requests, and for requests outside of a dialog, the sequence number value is arbitrary"? * 1065: Perhaps s/protocol/protocol name/ and s/version/protocol version/ to remove any confusion with transport protocol? * 1070: "to this rule is CANCEL" -> "to this rule is CANCELs and ACKs for non-2xx" ? * 1081: Broken Section Link. * 1093: Missing trailing "." in .txt. [Suspect due to fixed-width-font.] * 1138: Seems to me there are other possible events, such as no DNS records, ICMP on all attempts, yada yada? * 1141 [paranoia]: Since this talks about treating Nxx as being equivalent as N00, do we need to say "this doesn't apply where N = 7 / 8 / 9 / 0, kids!" * 1153: Capitalize "responses" in Section title. * 1153: Should this read more along the lines of "for example, a 301 response"? * 1170: Why are "network timeouts" mentioned? I would have thought that these came under the umbrella of the "Client transaction reporting". * 1173: Is it worth noting additionally that some failures may be recoverable, as indicated by the following sections (f.ex., 401)? * 1185: I think that "<" and ">" need to be escaped. * 1196: Capitalize "responses" in Section title. * 1207: Missing a closing ")" after "25.4.14". * Section 8.2: How mandatory is the order of these steps? For example, I can imagine that a 405 might depend on the Request-URI. Or can this all effectively be modelled as virtual proxying within a particular piece of software? * 1242: I think "layer" should be removed. * 1248: s/those contact addressess/that contact address/ * 1250: s/TU/UAS/ * 1258: No like "general-header". * 1262-1264, Sentence beginning "Upon receipt": This sentence seems to be superfluous -- especially in this Section, which is about UAS behaviour -- since it is just a repeat of Lines 1210-1212. * 1317: Why do we no-longer recommend 1xx for non-INVITE (I'm presuming 1xx here includes 100). * 1324: s/Cseq/CSeq/ * 1325: s/Cseq/CSeq/ * 1327: Delete "in the request". * 1359: s/URI/URI(s)/ * 1396: s/Required extensions/any unknown option tags in Require/ ? * 1396: s/session/request/ * 1398: Is this sentence implying that a redirect server should understand all option tags in a Proxy-Require? If not, then I think its presence here is confusing. (Not that I think it shouldn't. I'm slightly ambivalent about this. But I'll rant later when we reach "Proxy-Authenticate". * 1405: Is "servers" missing from between "CANCEL requests to" and "which can take a long time"? * 1407: s/response/final response/ * 1409: Perhaps change to "CANCEL requests can be constructed and sent by both proxies and user agent clients", since that's pretty-much everything? * 1412: "Because a stateful proxy can generate its own CANCEL, a stateful proxy also respond to a CANCEL" -> "A stateful proxy responds to a CANCEL," ? I don't see how the very first bit of the sentence is relevant. * 1438: Use of the word "original" concerns me slightly here, since SRV-based failover may have occurred? * 1477: I would have thought that replacing "must" with "may be required to" is more appropriate, since proxies aren't essential. * 1481: Space between "location service" and "," in .txt. [Probably due to italics.] * 1482 [for consistency]: s/Biloxi/biloxi/ * 1482: Space between "sip:bob@Biloxi.com" and "," in .txt. [Probably due to fixed-width-font.] * 1483 [for consistency]: s/Biloxi/biloxi/ * 1483: Space between "sip:bob@engineering.Biloxi.com" and "," in .txt. [Probably due to fixed-width-font.] * 1484-1485: Perhaps replace sentence with "Ultimately, a proxy will consult a location service that maps a received URI to the user agent(s) at which the desired recipient is currently residing."? Specifically, the use of "host(s)" and "logged" seems a little random. * 1497-1499: I found the second sentence a little hard to parse. What about: "_A_ registrar acts as _the_ front end to the location service for a domain, reading and writing mappings based on the contents of __ REGISTER requests." * 1539: s/contact addresses/the contact address(es)/ * 1545: Perhaps append "for example" to the end of this sentence? * 1582: This sentence would seem to be more appropriate for Section 10.2.3? * 1587: s/to refresh/for refreshing/ * 1597: s/for REGISTER request/to a REGISTER request/ * 1605: s/chicago.com/sip:chicago.com/ * 1635-1636: Since we're talking atomically, I think it would be clearer if the text said "meaning that _a particular_ REGISTER request is either processed completely or not at all"? * 1650-1651: Having trouble parsing the sentence. How about "For example, a registrar might consult an authorization database that maps user names to lists of address-of-records for which that user has authorization to modify bindings."? Hmmm. Mebbe. * 1651: s/If not/If the user is not authorized/ * 1687: Did I miss some discussion on why the Call-ID is now significant to the registrar? I don't understand why the restriction on the client not being able to send a REGISTER until the previous one has completed doesn't force the necessary ordering. * 1694: Perhaps add "e.g., because the backend database commit failed"? * 1701/1702: Seems to be an extra space between "etc." and "without". * 1748: Is "Section 13.2.1" the right link here? It doesn't seem to fit with what the rest of the paragraph is saying. * 1799-1800: I think s/remote target/peer/ would be slightly clearer here. * 1830-1831: What if there is no Contact? There use to be the notion of that "CONTACT_SET" boolean. Granted, it was a little painful, but it did potentially solve the problem with a little cooperation from proxies, right? How about just trying the From? Can it really hurt? &:) * 1832: s/Cseq/CSeq/ * 1845: Same isse with Contact. &:( * 1847: s/Cseq/CSeq/ * 1861: OPEN ISSUE #113: I say yes. Interestingly, the resolution is already documented in the Changes Section. * 1875: s/Cseq/CSeq/ * 1877: s/Cseq/CSeq/ * 1887: I think convention might dictate s/lr/"lr"/ * 1888: s/MUST a Route/MUST add a Route/ * 1914-1917: I'm having trouble understanding these two paragraphs. I think a little clarification would be helpful here. Is the intention that each Contact in the 3xx could become the new remote target URI? Maybe I've missed some further documentation of the procedure (Section 13.2.2 didn't really seem to say so much). * 1921: I think s/UAC/UA/ (both occurrences) would be more correct. * 1931: Should this read "In that case, the UAS _first_ applies the same processing"? * 1950: Extra spaces between "request:" and "re-INVITE" and "Section" and "14". * 1955: s/Cseq/CSeq/ * 1957: Small point, but I would have thought that 400 would have made more sense here, since presumably it is the client that has erred. (Although, I might note that this will have to be relaxed slightly if OPEN ISSUE #113 is "allowed".) * 1960: s/SHOULD/MUST/ surely. Why the lee-way? * 1962: s/Cseq/CSeq/ * 1964: s/Cseq/CSeq/ * 1965: s/Cseq/CSeq/ You think I'd have wisened up by now, and just suggested a global search-and-replace, eh? Doh. * 1973: s/This request is forwarded/This request may be forwarded/ * 2002: Extra space between "Section" and "24.1". * 2002: s/content-types/Content-Types/ perhaps? * 2008: I might suggest "the UAC core SHOULD generate a CANCEL request for the INVITE, as per Section 9". Since "original" makes me slightly panicky in the face of SRV (and I don't see any ambiguity). * 2009: s/MAY also find useful/MAY also find it useful/ * 2022: s,PRACK,ACK/PRACK, ? * 2041: Shouldn't the "[2]" actually be "[1]"? * 2047-2048: Has there been a relaxation on the support of INVITE? I might suggest: "All user agents MUST support all the exchanges listed in the above rules, based on their support for PRACK." * 2085-2087: I think it would be more sensible if these two paragraphs were moved into their own section; say "non-2xx final responses" or sommat? * Sections 13.2 and 13.3: One thing I have failed to find, is a treatise on the explicit semantics of Allow/Accept[-*], etc., as possible mutators of dialog state? Is the intention that there be no normative text, or have I just missed? * 2123/2124: I would have thought that a 408 was more appropriate? But small Point. * 2146: Extra space between "Section" and "8.2.6". * 2168: "a Contact header field containing URIs of new addresses to be tried" -> "a Contact header field containing one or more URIs to try" (to account for the singular case)? * 2248: s/the same as for an INVITE/the same as for the initial INVITE/ * 2254: Again, I would have thought that a 400 was more appropriate, since the client is the one that messed up. * 2260/2262: I could find no definition what it means to be the "owner" of a Call-ID. * 2288: s/unbound/unbounded/ * 2327-2331: Surely just about any response to a BYE means that the dialog is down; more importantly, how useful is the response to a BYE in general, beyond halting request retransmission? I'm not sure why these cases are explicitly mentioned. * 2344: Could there not be other pending requests, such as OPTIONS? Or is this working on the basis that all other requests don't really pend as such. * 2375: Errr...I'm not sure how a CANCEL could be sent; or is it assumed that if one were (for whatever inexplicably good reason), the CANCEL would be sent statefully? * 2381: s/Server/server/ s/Client/client/ s/Transactions/transactions/ * 2394-2397: This list is malformatted in the .txt. * 2436: Surely s/MAY/SHOULD/ or even s/MAY/MUST/ since why bother doing LD otherwise? * 2464: Broken Section Link. * 2507: Does this forbid retries to the same destination with a different request (i.e., with different headers, or whatever)? This could be a shame, since it might get in the way of proxies acting oppurtunistically; say, with "Require". * 2521-2524: I find the distinction between when to return a 404 and when to return a 480 too subtle, and since we are talking MUSTs, I feel it needs to be relaxed a little. (Since location services are abstract, I see it as very difficult to determine which case should apply.) Why not just RECOMMEND a 404 in both cases? (I wouldn't want a MUST on 404, since may be the location service goes to pants, in which case 504, or similar may be more appropriate.) * 2575: I think consistency would have this as "(see Item 3 of Section 16.3)". * 2588: s/Section/Sections/ * 2593: s/must/MUST/ * 2610-2618: Is there any reason this little bit cannot be moved up, say to just before 2485? That is because this text basically results in the destination set (although constrained to being of unit size) being completely trounced. Moving this to just before 2485 sits quite nicely with the check in 2479; well, with me, anyway. * 2666: s/record-route/Record-Route/ ? * 2685: In any case, should not be "Section 5", and if the 2610-2618 move is undertaken, cannot even be "Step 5". Oh dear. * 2695: I would think that it should not be 408, and should instead depend on the result reported by the transaction layer (say 404 if no DNS records; or 480 if DNS records, but no servers responded; or 502 if ICMP; ...). I guess this is generic to client transaction behaviour, however. * 2705: I don't like this MUST. Smells like a DoS hole to me. (I, as naughtyJo, could forge a response with a whole lotta Vias in it.) * 2720: s/forward/Forward/ * 2721: s/generate/Generate/ * 2739: Should be Section 9? * 2740: Spurious ";". * Section 16.6, Step 4: There may be other cases where a proxy is able to be clever and try a request again, and thus the response should not be added to the context. Obviously, this does require the UAS to be well keen, and look at seeming Request Merges very carefully; however, it doesn't seem unreasonable that an extension could employ a wickedclever use of this. * 2768: s/all pending transactions/all pending client transactions/ (for clerity). * 2768: Should be Section 9? * 2780: Consider "Step 4" instead? * 2781-2782: Consider "Steps 7 and 8" instead? * 2784: s/exactly one non-2xx response/exactly one non-2xx final response/ * 2789: Does there need to be the addition of something along the lines of "...and there are no destinations pending in the destination set and no hope for further population of the destination set?" Just to be explicit about results triggering further proxy attempts (with SIP Servlets, f.ex.). * 2792: Hmmm.... 408 doesn't look right to me. Finally, I find somewhere where I'd really be happy with a 480! &:) * 2794: Isn't 6xx still considered better than 3xx,4xx, 5xx? Also, I would prefer a SHOULD for the lowest class here, since it enables a proxy to be a little more clever. It may get a 3xx to what it knows is voicemail, for instance, but know somehow that voicemail is no good to the client, so return a 486. I'm certainly no expert on CPL, but it seems to me that it would be possible to violate this MUST with the use of "reject". * 2802/2803: Again, consider "Steps 7 and 8" instead? * 2811-2816: I think it would be nice if the notion of this "virtual UAS" was opened up a little to explicitly mention how it could be used to generate candidate final responses. Coupled with me above rant on 2794, this nicely draws the story together (and gives a reasonable model for CPL to work with). * 2862/2863: Again, consider "Steps 7 and 8"? * 2892-2893: I would have thought we could do better than this; in particular, shouldn't it be the transaction layer that is reporting errors? (Okay, not if stateless, but things get really icky when a stateless proxy results in an ICMP, for example.) I would hope that we can come to an agreement of the set of errors that a client transaction (or set; I'm slightly confused to the distinction when failing-over via DNS records) can report, and the semantics of these within the SIP status code space. * 2905-2910: I think there may be a slight race here, due to the case when a server transaction for the request being cancelled has been created, but the response context has not. (Of course, that does depend on whether this spec is threaded or not...) Why not simply have the text search for an associated server transaction (in particular, the beginning of Section 9.2 appears generic to any stateful server, anyway), and then some notion of communication of the CANCEL action to the proxy core, such that it can CANCEL any pending client transactions, and do whatever else, as appropriate? * 2910: In any case, this should be Section 9. * 2912: Is the word "statelessly" missing after "CANCEL request"? And again, I think I'd rather a SHOULD, since I'm suspicious that there could be some attack potential here. * 2934: I'm not sure where the notion of a "random number generator" comes from. * 2935: s/Section 16.5 bullet 3/Item 3 of Section 16.5/ * Section 16: I think I might have come up with a slightly nasty case with a stateless proxy, that I cannot see is forbidden. Although it does look as if the proxy destination is fixed to be the same for a particular request, I cannot see anything forbidding inconsistent header addition / modification. In partiular, this opens up a hole where a stateless proxy can append a different Route set to retx of a request. May be I'm missing something here, and thus wrong about this; however, if not, I think this hole needs to be filled. * 3065: I thinking that s/gateway/P1/ would be clearer. * 3088: Space between "13.3.1.4)" and ",". * 3102/3103: "that server transaction" -- I'm not sure to what "that" is pertaining. * 3104-3106: I would propose changing the sentence to "Additionally, in the case of an INVITE request, the client transaction is responsible for generating any ACKs to non-2xx final responses." [I was confused by the "that includes" on line 3105.] * 3132: s/INVITE request/INVITE requests/ * 3176: Bunchup between '"calling"' and "state". * 3222-3223: Sentence beginning "The ACK request" I think this sentence should be removed, since its effectively repeated in the next paragraph. * 3269: I don't quite follow the "and it represents the amount of time a non-INVITE server transaction will take to respond to a request". How is that? Is it more "and it represents the maximum amount of time that a non-INVITE server transaction _SHOULD_ take to respond to a request"? It's fair enough that some figure is put down; I think it's the "will" that is bothering me. * 3290-3291: I don't see the need for this with non-INVITE; in any case, the text is buggy since it is explicitly addressing INVITE. * Figure 6: For consistency, I think that the topmost text should be "Request from TU". * 3295-3299: This matching logic doesn't sit quite right with me. My understanding is that both conditions would have to be true for there to be a match. Therefore, I would suggest s/under/by meeting/ on Line 3296; s/First, if the/First, the/ on Line 3296; s/Second, if the/Second, the/ on Line 3298; d/The method is/These conditions are/ * 3329: And now I get overly purist. Really, in the case of a proxy, I don't think that the 1xxs it forwards should be retx upon receipt of a request retransmission. However, it would be difficult to describe which response to retx here in a generic fashion. * 3332: s/Response/response/ * 3348: Space in "non- INVITE". * Figure 8: In the rightmost line, labelled "200-699 from TU", the join to the "Completed" box is missing a "<". * 3394-3396: Am I right in thinking that a possible attack was identified at the 52nd IETF with the new approach to transaction ID? I'm having difficulty coming up with anything terrible, but I guess if an attacker was capable of forging source address, and could guess branch IDs, it could cause a downstream server to see a particular client's request as a retransmission. I'm not sure that this is worth mentioning. * 3422: First use of "ICMP". * 3422: First use of "SRV". * 3475: "While this" seems to be missing from .txt. * 3478: "If the UAS is unwilling to do so, it MUST reject the" seems to be missing from .txt. * 3485: s/Responses/responses/ * 3491: Extra space between "100rel" and "," in .txt. [Fault of fixed-width-font?] * 3494: Extra space between "100rel" and "," in .txt. [Fault of fixed-width-font?] * 3515: Again, this seems more like a client error, so shouldn't it be a 4xx instead of a 5xx. * 3535: Extra space between "100rel" and "," in .txt. [Fault of fixed-width-font?] * 3562: First use of "TLS". * 3563: First use of "SCTP". * 3575: Extra closing ")". * 3581: I'm not sure what "that" is. * 3586: First use of "TTL". * 3587: First use of "MTU". * 3584-3600: As a suggestion, perhaps this could be put into a small Subsection on UDP and TCP, since it's very oriented towards these transports. * 3645: For consistency, I would think "parameter" instead of "attribute", on both counts. * 3655: s/the server transaction/a server transaction/ * 3671: First use of "SSL" (is this perhaps a mistake, anyway?). * 3718/3719: 401 being used with a redirect server. Hmmm.... I guess that I never read the authentication Section before (this would seem to read roughly the same as 2543). Anyway, it's probably just me being cl00ful, but I would have thought that you would use a 407 for a redirect server, because it's not actually the server you're trying to reach? Anyway, it really is but a small thing. * 3737: Extra space between "WWW-Authenticate:" and "Digest". * 3741: Should this be s/UACs/UASs/ ? Or perhaps just UAs? * 3806: Should this read "MUST increment the CSeq header field _if reusing the same Call-ID_ as it", since a UAC is free to pick a new Call-ID out of thin air? * 3811: s/UAS/proxy/ * 3862-3864: This paragraph might be better in Step 7 of Section 16.6? * 3880: Section number has gone a little funny in PDF? * 3881: s,HTTP 1.1,HTTP/1.1, * 4002: "." missing from end of paragraph. * 4017: Gratuitous Bracket Application. * 4035: s/All/Any/ ? * 4036: Paragraph ends abruptly with "with the" in .txt. * 4048: Some odd quoting of "inner". * 4324: First use of "STMP". * 4364: Perhaps remove "and that". * 4396: s/UACs/UASs/ * 4398: Would this be more correct as "Digest-based authentication"? * 4405: Remove the "an" before "S/MIME"? * 4424: Some of the text on this line in the PDF is missing from the .txt. * 4432/4433: This should be 401 (Unauthorized), right? * 4460: Just a quick query (this is probably more for my understanding than anything else): if Alice's UA had reused the TLS connection to the "local outbound proxy", then surely credentials are not really necessary when sending the INVITE. Or is it because paranoia says that such associations should be timed-out (because Alice may have left her UA "logged-in")? * 4465/4466: Again text gone missing. In PDF, not in .txt. * 4471: Again text gone missing. In PDF, not in .txt. * 4477: Missing "'biloxi.com'.". * 4501/4502: Text lossage (in PDF; not in .txt). * 4506: Text lossage (in PDF; not in .txt). * 4540: Would insertion of "thus" before "behaving" make sense? * 4564: Would insertion of "a" before "prevalent" make sense? * 4583-4588: Is there some conflict in this paragraph; in particular, it alks about a UA being registered as the sole contact address, and then mentions that a likely failure case is when forking occurs. Maybe if instead of "sole contact address", it read "one of the contact addresses" (Lines 4585/6). * 4680/4681: Surely just "Section 8.1.1.1" is more consistent. But I am not sure that this is the actually desired Section, anyway? * Table 1: Well, I guess some of the defaults may be disappearing from here (port:5060; transport=udp)? * Table 1 "heading": I find this a little difficult to read. How about "Use and default values of SIP URI components in headers, the Request-URI, and out-of-band links"? (Okay, so it's not much better. I do find "references" a little oblique.) * 4719: I find the ""%" HEX HEX" a little confusing. Couldn't the outer "s be dropped? Also, should this actually be "HEXDIGIT"? * 4720-4724: There's something very odd going on with these two paragraphs in the .txt. version. * 4761: ""%" HEX HEX" again. * 4764: Well, I guess the bit about 5060 will be going? * 4776: Broken Section Link. * 4778/4779: Won't match if new comparison rules. * 4785: The priority header seems to have gone missing in the .txt. * 4809: To aid clarity, I would suggest replacing "request" with "desire". * 4813: Should this read "SHOULD NOT"? Otherwise, I really don't follow. * 4830: "headerRequire"? Enough said. * 4873: Missing ")" after "24.29". * 4880: s/host name/domain name/ * 4926: s,servers,clients/servers, * 4928: s,servers,clients/servers, * 4939,4941: I am not sure what "not applicable" translates to in the table. * Tables 2 and 3: - Accept/R INV: Should be "o". [Section 13.2.1] - Accept/2xx INV: Should be "o". [Section 13.3.1.4] - Accept/415 BYE, INV, OPT, REG, PRA: Should all be "m". [Section 8.2.3] - Accept-Encoding/R INV: Should be "o". [Could not find any normative text about this.] - Accept-Encding/2xx INV: Should be "o". [Could not find any normative text about this.] - Accept-Language/R INV: Should be "o". [Could not find any normative text about this.] - Accept-Language/2xx INV: Should be "o". [Could not find any normative text about this.] - Allow/R ACK: For consistency, I would say that this should be "-". (None of the "Accept"s are allowed, for instance.) - Allow/{R,2xx,r,405} CAN: To keep CANCEL as clean as possible (seeing as hop-by-hop an all), I would think that these all be "-". - Error-Info/300-699 CAN: Again, I don't see how this could be useful. - MIME-Version CAN: Since I don't think that CANCEL can realistically have a body, does this header make any sense? - Proxy-Authenticate/407: CAN: Cannot be challenged, therefore should be "-". - Proxy-Authorization/R CAN: Hop-by-hop, therefore, should be "-". - Record-Route s/2xx,401,484/2xx/ - Record-Route/{R,2xx} CAN: Makes no sense to be able to R-R a CANCEL; should be "-". - Retry-After/[all] CAN: Makes no sense for CANCEL; should be "-". - Route I think should be "acr" under "proxy". ACK, BYE, CAN, INV, OPT, REG, PRA: Should all be "o". - RSeq/1xx Should only be "o" under INV, since 18.1 specifies that PRACK is only for 1xxs to INVITEs. - Supported/R INV: Should be "m*". [Section 13.2.1] CAN: Should be "-". - Supported/2xx INV: Should be "m*". [Section 13.3.1.4] CAN: Should be "-". - {Unsupported,Warning,WWW-Authenticated} CAN: Should all be "-". * 4986: Too many "w"s! &:) * 5006/7 Random Line Break. * 5011: Probably me being a cl00bie again, but what is the motivation for this sentence? * 5018: Disjointed "case-sensitive". * 5070: Random Line Break. * 5076: s/handling-parm/handling-param/ * 5080/1: This paragraph conflicts with 5070-2. * 5171: Not entirely sure how Section 7.3.1 is particularly relevant. * 5195/6: Perhaps this paragraph should be removed. Insertion is already a MUST, as per 8.1.1.6 and Step 4 of 16.5, right? * 5200: s/to a registrar/of a registrar/ ? * 5263: s/The Record-Route/The Record-Route header/ * 5263: s/session/dialog/ ? * 5267/8: It'd probably be nice if these were updated to look like they have been created by bleeding-edge. * 5275: Again, not sure how relevant 7.3.1 is. * Section 24.34: Table 3 also lists: 413, 480, 486, 500. * 5300: s/The Route/The Route header/ * 5367: I think this sentence would be a little clearer if "and, if not the default port number, the port number" were replaced with "and possibly the port number". * 5368: Mentioning "branch" here seems a little throwaway, since it is grouped with the network-related parameters, and also, "branch ID" was mentioned in the previous-but-one paragraph; perhaps remove? * Section 24.44: I think this Section could be a little better organized by moving 5372/3 to just above 5382/3; by moving 5376 above 5374/5; and by making one of 5374/5 use compact form (since all other Sections seem to give a "compact form" example). * 5425: I read this as saying that the examples illustrate new "warn-code"s; however, I can only see 301 and 307? * 5443: Remove "or proxy". * 5446: Do we need to add a "(typically)" before "transmitted reliably"? * 5456: Remove "proxy", since only UASs can generate non-100 1xxs of their own. * 5459: s/callee/server/ ? * 5541: s/section 22 and 20.3/Sections 22 and 20.3/ * 5587: s/host/server/ * 5595: How about replacing this whole sentence with "The server has detected a loop (Step 3 of Section 16.3), or a merge (Section 8.2.2.2). * 5630: s/INVITE/request/ ? * 5660: Perhaps s/attempt to forward the request/try/ ? * 5697: s/INVITE/request/ ? * 5939: s,HTTP 1.1,HTTP/1.1, * 5964+lineAbove: LBRACK/RBRACK talk about "square" brackets; however, I am seeing curly. * 5972: Superfluous "(" and ")" around "quoted-string"? * 5976: s/%x0A/%x0B/ ? * Just After 5980: url-parameter: "|" before "ttl-param" in .txt (not in PDF). * Just Before 5993: media-range: Should there be SWS between `"/"' and `"*"'? Else, why is it not just "/*" [in [H14.1]]? * Just Before 5998: dig-resp: I see (here and everywhere) usage like foo / bar / [baz] Is the meaning of [] in a choice documented anywhere? I turned up nothing. &:( * Just Before 5998: digest-uri-value: "1.1" is missing after "HTTP/" in .txt. (not in PDF). * 6002: addr-spec: Is "URI" really right, or should it be "absoluteURI"? (As I understand things, "URI" would allow for something like "/foo/bar/baz".) * 6030: Supported: Since "Supported" can be empty, shouldn't this be: [option-tag *(COMMA option-tag)] * 6035: Via: Okay. So I guess I never noticed when IPv6 properly appeared. My only concern is that this is a non-documented (I think) backward- compatability issue, since "[" "]" and ":" did not used to be legal in generic parameters, but using IPv6 addresses, means that they may appear in "received" and/or "maddr". Additionally, I think that one could assume that the "sent-by" was safe out of harm's way from marauding "[" and "]"s. Not that I care, but I think that this should probably be mentioned (perhaps in the bullet where the introduction of support for IPv6 addresses in URIs and Vias is mentioned?). * 6043: Naughty space nestling in "option- tag"s. * 6053: Space between "(" and "Section 23.2". * 6075: "n" missing at end of sentence. * 6077: "]" missing at end of paragraph. * 6133: s/THey/They/ * 6166: Add the word "made" before "vastly simpler"? * 6167-6169: I don't get the last two sentences. Surely, that _is_ "pre-loaded routes"; and I thought that we did have full interoperability? * 6172: Comments can still appear as part of {Retry-After, Server, User-Agent}.... * 6175: s/ACK/ACKs/ * 6219: s/so SIP/to SIP/ * 6234: s/mandating/mandated/ * 6236: Change last sentence to "Only 2xx responses to INVITEs are retransmitted over TCP.". Apologies if some of this Just Does Not Make Sense. In particular, I don't understand BNF or Security. Or the Offer/Answer Model. &:) - Jo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 01:43:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20743 for ; Fri, 15 Feb 2002 01:43:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA00269 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 01:43:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18904; Fri, 15 Feb 2002 01:03:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18874 for ; Fri, 15 Feb 2002 01:02:58 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20213 for ; Fri, 15 Feb 2002 01:02:57 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1F62nio022254; Fri, 15 Feb 2002 08:02:50 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15468.42121.676276.634429@harjus.eng.song.fi> Date: Fri, 15 Feb 2002 08:02:49 +0200 To: Michael Thomas Cc: Jonathan Rosenberg , Lawrence Conroy , Henry Sinnreich , "'Peterson, Jon'" , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: <15468.20426.981872.401481@thomasm-u1.cisco.com> References: <3C6A8999.51BDBCF3@dynamicsoft.com> <15466.36777.821785.996536@harjus.eng.song.fi> <15468.20426.981872.401481@thomasm-u1.cisco.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas writes: > The addition of SMIME seems to > be a solution in search of problem. Also: SMIME > is a complete pig. I can't imagine any low end > UA's implementing it. It certainly doesn't > deserve "SHOULD" status. then lets get rid of it completely. it makes no sense to have dead wood in the bis. if need arises, one can always write a separate i-d about smime. -- 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 daemon@optimus.ietf.org Fri Feb 15 01:46:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20767 for ; Fri, 15 Feb 2002 01:46:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA00315 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 01:45:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27303; Fri, 15 Feb 2002 01:13:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27259 for ; Fri, 15 Feb 2002 01:13:31 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20346 for ; Fri, 15 Feb 2002 01:13:31 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1F6Dh6Y002595; Fri, 15 Feb 2002 01:13:44 -0500 (EST) Message-ID: <3C6CA6E6.4C148A83@dynamicsoft.com> Date: Fri, 15 Feb 2002 01:12:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: Michael Thomas , Lawrence Conroy , Henry Sinnreich , "'Peterson, Jon'" , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: <15468.42121.676276.634429@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha Heinanen wrote: > > Michael Thomas writes: > > > The addition of SMIME seems to > > be a solution in search of problem. Also: SMIME > > is a complete pig. I can't imagine any low end > > UA's implementing it. It certainly doesn't > > deserve "SHOULD" status. > > then lets get rid of it completely. it makes no sense to have dead wood > in the bis. if need arises, one can always write a separate i-d about > smime. It was added in to fill security holes that were deemed sufficiently big, that sip could not pass without an answer for them. The nice thing about it is that we didn't have to invent anything new to do it. Perfect? no. Works everywhere? certainly not. Covers the holes and gives us additional capabilities with low protocol engineering costs? YES. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 15 02:09:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28235 for ; Fri, 15 Feb 2002 02:09:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01424 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 02:09:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28914; Fri, 15 Feb 2002 01:25:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28885 for ; Fri, 15 Feb 2002 01:25:47 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20506 for ; Fri, 15 Feb 2002 01:25:46 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1F6Pfio022270; Fri, 15 Feb 2002 08:25:41 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15468.43493.152768.556282@harjus.eng.song.fi> Date: Fri, 15 Feb 2002 08:25:41 +0200 To: Jonathan Rosenberg Cc: Michael Thomas , Lawrence Conroy , Henry Sinnreich , "'Peterson, Jon'" , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: <3C6CA6E6.4C148A83@dynamicsoft.com> References: <15468.42121.676276.634429@harjus.eng.song.fi> <3C6CA6E6.4C148A83@dynamicsoft.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > It was added in to fill security holes that were deemed sufficiently > big, that sip could not pass without an answer for them. it makes no sense to invent something just to make the i-d pass the review. what is included in the base sip spec, must have wide industry support and real examples of working products. -- 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 daemon@optimus.ietf.org Fri Feb 15 03:51:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00333 for ; Fri, 15 Feb 2002 03:51:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA06631 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 03:51:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05026; Fri, 15 Feb 2002 03:28:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04981 for ; Fri, 15 Feb 2002 03:28:18 -0500 (EST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29698 for ; Fri, 15 Feb 2002 03:28:17 -0500 (EST) Received: from jariws1 ([62.248.149.171]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020215082735.QIPI6990.fep07-app.kolumbus.fi@jariws1>; Fri, 15 Feb 2002 10:27:35 +0200 Message-ID: <011501c1b5fa$bc43dca0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Michael Thomas" , "Juha Heinanen" Cc: "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , "'Michael Thomas'" , "'Peterson, Jon'" , References: <3C6A8999.51BDBCF3@dynamicsoft.com><15466.36777.821785.996536@harjus.eng.song.fi> <15468.20426.981872.401481@thomasm-u1.cisco.com> Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) Date: Fri, 15 Feb 2002 10:28:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Juha Heinanen writes: > > i have seen sip UAs that support basic authentication together with tls > > and digest authentication without any transport layer security, but i > > haven't heard of any that would do smime. > > > > is there any? if not, then does it make sense to have smimi in the bis. > > I don't think so. The addition of SMIME seems to > be a solution in search of problem. Also: SMIME > is a complete pig. I can't imagine any low end > UA's implementing it. It certainly doesn't > deserve "SHOULD" status. I kind of like the opportunistic SMIME scheme in Bis. However, I do agree with you that it's not a low-end thing. My personal recommendation would be either a MAY or a separate RFC. Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 04:03:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00535 for ; Fri, 15 Feb 2002 04:03:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA07521 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 04:03:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06149; Fri, 15 Feb 2002 03:44:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06119 for ; Fri, 15 Feb 2002 03:44:33 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00178 for ; Fri, 15 Feb 2002 03:44:30 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1F8hsB24062; Fri, 15 Feb 2002 09:43:54 +0100 (MET) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.7]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1F8hrr6021858; Fri, 15 Feb 2002 10:43:53 +0200 (EET) Message-ID: <3C6CCA7E.D13E40A4@ericsson.com> Date: Fri, 15 Feb 2002 10:44:46 +0200 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: sip@ietf.org CC: Dean Willis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Comments to the Path header draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: Some comments to the Path header draft, draft-willis-sip-path-01.txt 1) Section 3. "UA1 discovers P1 as a result of a DHCP assignment." Although most of the UAs will discover P1 as a result of a DHCP assignment, I foresee other mechanisms, like local configuration (a la http browser) or external means (e.g., 3GPP PDP context activation). I will propose to replace the above text by this one: "UA1 typically discovers P1 as a result of a DHCP assignment, although other mechanisms, such s manually provisioning may be also possible". 2) Section 4, 2nd paragraph: "A Path header may inserted ..." should read "A Path header may be inserted ..." 3) Section 4, bullet point 1: "Path applies to REGISTER and responses to REGISTER. Record-Route doesn't." It should read: "Path applies to REGISTER and the 200 OK response to REGISTER. Record-Route doesn't." 4) Section 4, bullet point 3. Typo: "Regsiter" should be "REGISTER". Same section: "rflected" should read "reflected". 5) Section 4: I would add a new bullet point 5 to emphasize that the URI inserted in a Path header does not have any requirement to be the own URI of the node which inserts it. I know it is already written in section 5.2, but I guess the text will enlighten the reader. "Unlike Record-Route headers, there is no restriction on the URI that a node inserts in a Path header field value, other than it MUST be a SIP URI. Particularly, a node MAY insert a Path header field value with SIP URI that resolves to another node. This requires the inserting node to have some knowledge of the network topology". 6) Section 5.1: clarify that the Path header field is only allowed in 200 OK response for a Register, so replace: "When a UA receives a response to REGISTER containing the Path header ..." with "When a UA receives a 200 OK response to a REGISTER containing one or more Path header field values ..." 7) Section 5.1, 1st paragraph: "This list SHOULD be stored during the entire registration period of the associated public user identity." should read: "This list SHOULD be stored during the entire registration period of registered URI". 8) Section 5.1. The first sentence assumes that the Path header field values in the 200 OK will contain the SIP URL of the own UAC. However, this is not true. By no means the UAC SIP URL will be present in the Path in the 200 OK. See the examples, flow "F4 Registrar Response P1->UA1" for a correct example. Therefore, the text "When a UA receives a response to REGISTER containing the Path header, the UA removes its SIP URL from the list of Path headers, reverse the order of the list and save the resulting list of Path headers." should be rephrased to: "When a UA receives a response to REGISTER containing the Path header, the UA reverse the order of the list and save the list of Path header field values as a list of preloaded routes that will be used in subsequent requests. 9) Section 5.2. "... the topmost entry in the Path header before processing the request" should read "... the topmost entry in the Path header field value before processing the request". 10) Section 5.2, last paragraph: "It is also possible for a proxy with specific knowledge of network topology to add a Path header referencing another node, ..." should read "It is also possible for a proxy with specific knowledge of network topology to add a Path header field value referencing another node, ..." 11) Section 5.3, 1st paragraph: First, there is a condition on the existence of a Path header in the response, based on the existence of the Path header in the REGISTER. I believe there should not be such a restriction, because a registrar should be able to insert a Path header even when the REGISTER didn't include it. I propose to replace the first paragraph in section 5.3 by these others: "A registrar that receives a REGISTER message that includes one or more Path header fields MUST copy the list of Path header field values into a list of preloaded Route header field values. The order in the lists MUST be preserved. The registrar MUST bind the registered URL with the Contact header field values and the list of preloaded Route header field values. The registrar MAY add a URL as a Path header field value to the 200 OK response to the REGISTER." 12) Section 5.3: "The registrar can also act as a proxy as described above (in which case it inserts a resolvable identifier identifying itself in the Path header) before storing the list of preloaded Route headers." I don't clearly understand what this paragraph is trying to say. Maybe is trying to say: "Upon the reception of a user location query, the registrar MUST return the binding information associated to the particular user. This binding information is built upon the Contact header field values along with the list of preloaded Route header field values as described previously in this section". Therefore, I propose to replace the existing text with the proposed one. 13) Section 5.4, first paragraph, several comments already discussed above. I propose to replace the first paragraph with this one: "Any node generating or receiving a REGISTER request or 200 OK response (to the REGISTER request) that wishes to be included in the service route for future messages flowing in the direction of the received message may add a SIP URL as a Path header field value at the end of any Path header field in that message, or may add Path header field with a SIP URL as a Path header field value as the final value in the Path header field in that message." 14) Section 5.4: "So, P1 and will add itself ..." should read "So, P1 will add itself". 15) Section 5.4, flows. There are two flows F4. 16) Section 8: Typo, "Migual" should read "Miguel" ;-) 17) Somewhere in the draft we should add the following: The following table extends table 2 in [bis]: Header field where proxy ACK BYE CAN INV OPT REG PRA _______________________________________________________________ Path R amr - - - - - o - Path 2xx amr - - - - - o - 18) Section 6, security considerations: If we allow a proxy to insert a path header field value that does not point to its own resolvable SIP URL, I guess we are introducing a security risk, but I am not sure how to cover this in the text. Perhaps something like this: "Care must be taken when a SIP entity introduces a Path header field value that points to a different entity. Such a mechanism SHOULD be used by entities that have administratively knowledge of each other, typically because they are part of the same administrative network". /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 04:47:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01136 for ; Fri, 15 Feb 2002 04:47:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09708 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 04:47:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07897; Fri, 15 Feb 2002 04:14:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07865 for ; Fri, 15 Feb 2002 04:14:41 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00684 for ; Fri, 15 Feb 2002 04:14:39 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1F9Dfb30930; Fri, 15 Feb 2002 03:13:41 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4BMA>; Fri, 15 Feb 2002 03:13:36 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF3D@VA02> From: "Peterson, Jon" To: "'Jari Arkko'" , Michael Thomas , Juha Heinanen Cc: Jonathan Rosenberg , Lawrence Conroy , Henry Sinnreich , "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?) Date: Fri, 15 Feb 2002 03:13:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I believe there are reasonable threats against SIP (at least one of which is described in bis) that justify end-to-end confidentiality of bodies. I'm not sure that I want intermediaries to be able to inspect or potentially modify SIP bodies, especially SDP, for a number of reasons. I think we need a base SIP mechanism to address this concern. Originally, S/MIME was discussed in a separate draft authored by Henning. We pulled the S/MIME material into bis, and elaborated on its implementation because of the known threats against the protocol. There are, incidentally, numerous things in bis which have yet to be implemented by any SIP device to my knowledge. That is one of the reasons why SIP remains a Proposed Standard rather than a Draft. No doubt the S/MIME mechanism will be refined as we progress with the SIP standard. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Friday, February 15, 2002 12:28 AM > To: Michael Thomas; Juha Heinanen > Cc: Jonathan Rosenberg; Lawrence Conroy; Henry Sinnreich; 'Michael > Thomas'; 'Peterson, Jon'; sip@ietf.org > Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) > > > > > Juha Heinanen writes: > > > i have seen sip UAs that support basic authentication > together with tls > > > and digest authentication without any transport layer > security, but i > > > haven't heard of any that would do smime. > > > > > > is there any? if not, then does it make sense to have > smimi in the bis. > > > > I don't think so. The addition of SMIME seems to > > be a solution in search of problem. Also: SMIME > > is a complete pig. I can't imagine any low end > > UA's implementing it. It certainly doesn't > > deserve "SHOULD" status. > > I kind of like the opportunistic SMIME scheme in Bis. However, > I do agree with you that it's not a low-end thing. My personal > recommendation would be either a MAY or a separate RFC. > > Jari > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 04:51:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01180 for ; Fri, 15 Feb 2002 04:51:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09855 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 04:51:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08190; Fri, 15 Feb 2002 04:22:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08161 for ; Fri, 15 Feb 2002 04:22:28 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00770 for ; Fri, 15 Feb 2002 04:22:25 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 15 Feb 2002 09:22:41 UT content-class: urn:content-classes:message Subject: RE: [Sip] note: change in URI comparison rules coming MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 15 Feb 2002 09:24:25 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <45730E094814E44488F789C1CDED27AEC552A1@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] note: change in URI comparison rules coming Thread-Index: AcG1qeOPb5Hm+d0sSQ26HwLLvHSv5wAV8TJA From: "James Undery" To: "Robert Sparks" Cc: "Jonathan Rosenberg" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA08162 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Good. Well while we're at it can I suggest we remove all default values from SIP URIs. My reasoning would be, port and transport seemed the least arbitrary. The user parameter has consistently been abused; the method parameter defaulting to INVITE doesn't seem so convincing in these SIMPLEr times; ttl does this really justify a default parameter, if you insist on using multicast you should do it properly with some thought. This also results in a far simpler comparison rule, that's easy to grasp and apply. James > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: 14 February 2002 22:35 > To: James Undery > Cc: Jonathan Rosenberg; sip@ietf.org > Subject: Re: [Sip] note: change in URI comparison rules coming > > > The current proposal is no. > > Those two URLs will resolve to the same host/port/transport, but > making the URLs equivalent will require separate equality rules > for when the hostpart is an IPv4 address vs a DNS name. > > RjS > > > James Undery wrote: > > > Is sip:10.0.0.1 == sip:10.0.0.1;transport=udp still going to hold? > > > > James > > > > > >>-----Original Message----- > >>From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > >>Sent: 14 February 2002 15:32 > >>To: Jonathan Rosenberg > >>Cc: sip@ietf.org > >>Subject: Re: [Sip] note: change in URI comparison rules coming > >> > >> > >>The same argument applies to the transport parameter > >>sip:user@domain;transport=udp will always resolve to udp, > >>but > >>sip:user@domain may resolve to tcp through DNS. > >> > >>The next version of bis will reflect > >> > >>sip:user@domain:5060 != sip:user@domain != > >>sip:user@domain;transport=udp > >> > >> > >>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 daemon@optimus.ietf.org Fri Feb 15 05:39:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01684 for ; Fri, 15 Feb 2002 05:39:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12017 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 05:39:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10885; Fri, 15 Feb 2002 05:15:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10862 for ; Fri, 15 Feb 2002 05:15:23 -0500 (EST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01395 for ; Fri, 15 Feb 2002 05:15:20 -0500 (EST) Received: from jariws1 ([62.248.149.171]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020215101438.RGGG6990.fep07-app.kolumbus.fi@jariws1>; Fri, 15 Feb 2002 12:14:38 +0200 Message-ID: <018201c1b609$b1b562e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Peterson, Jon" , "Michael Thomas" , "Juha Heinanen" Cc: "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , "'Michael Thomas'" , References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) Date: Fri, 15 Feb 2002 12:15:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > I believe there are reasonable threats against SIP (at least one of which is > described in bis) that justify end-to-end confidentiality of bodies. I'm not > sure that I want intermediaries to be able to inspect or potentially modify > SIP bodies, especially SDP, for a number of reasons. I think we need a base > SIP mechanism to address this concern. I think we're in rough agreement about the above, though we may differ in the exact level of importance put to the intermediary inspection, hence the difference in SHOULD vs. MAY. I do believe intermediary inspection is an issue, but perhaps not as big of an issue as is actual media stream protection. Given that the latter can be handled e2e using e.g. SRTP without relying on security of the SIP signaling, I tend to think that the most pressing needs of the users are satisfied even if no S/MIME is present. Put in another way, if I had a budget to implement a single new thing in a multimedia terminal I would probably go for SRTP rather than S/MIME. Continuing this line of though slightly beyond the original scope of the discussion, my list of priority order for SIP security is: 1. Operators and gateway owners get paid: The only thing that appears to be able to do this over proxies etc. is Digest, possibly enhanced in some manner. This is a clear MUST for everyone (like it is in Bis). 2. SIP does not introduce new DoS holes that "Internet-Wreckers" could employ. This isn't as much of an issue in closed networks and under some sort of lower layer security, but it appears that people want to allow open SIP nodes for everyone to contact them, and here I think lies some danger. It appears to be possible to get at least small amounts of amplification by reflecting packets, possibly with spoofed addresses, through a proxy: INVITE, 180 Ringing, 200 OK etc. I'm glad to find the Anon Digest in latest Bis that addresses this. One thing that is still unclear to me though whether we should perhaps have a MUST somewhere where this should be applied. A proxy/b2bua that doesn't have TLS or IPsec at the bottom, MUST apply Anon Digest? Another thing that is unclear to me is whether we'd be safe after that. Maybe, but somehow I'd like to be convince myself better. 3. User's multimedia streams are secured. SRTP (and MIKEY) should take care of this as described above, or possibly IPsec in some circumstances. Clearly we don't need to have any MUSTs in Bis about this. 4. Some sort of signaling protection may also be necessary. The interesting thing about this is that there appears to be widely different requirements about this. Cellular folks scream about heavy weight public key crypto, kernel TCP state (may be easier in the app as you know you're going to have a million open sessions), roundtrips and here enhanced digest schemes appear the right engineering tradeoff. In some other situations either IPsec or TLS would do the job. The trouble is that any MUSTs in the spec have been known to cause a strong reaction from the group that feels their case was not favored in the selection, and are going to lead to dead code in products if something extra has to be implemented. My call here could be to have a MUST for enhanced digest and a SHOULD for TLS, MAY for IPsec and SMIME, leaving SIP with a scheme that can cover both h2h/e2m/e2e protection and UDP/SCTP/TCP, and room for the different groups to do their favorite thing in addition. Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 06:15:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01925 for ; Fri, 15 Feb 2002 06:15:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13428 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 06:15:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12337; Fri, 15 Feb 2002 05:48:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12306 for ; Fri, 15 Feb 2002 05:48:23 -0500 (EST) Received: from avgw.vxserver.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01776 for ; Fri, 15 Feb 2002 05:48:20 -0500 (EST) Received: from ridgeway.ridgeway-sys.com ([10.1.1.1]) by avgw.vxserver.com (NAVGW 2.5.1.16) with SMTP id M2002021510451107171 for ; Fri, 15 Feb 2002 10:45:11 GMT Received: by ThisAddressDoesNotExist with Internet Mail Service (5.5.2653.19) id <1ZJ5J2B4>; Fri, 15 Feb 2002 10:47:50 -0000 Message-ID: <00533D13955AD411AF3800A0C9B4263994D709@ThisAddressDoesNotExist> From: Phil Reynolds To: "'sip@ietf.org'" Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?) Date: Fri, 15 Feb 2002 10:47:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B60E.360466A0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B60E.360466A0 Content-Type: text/plain; charset="ISO-8859-1" > I believe there are reasonable threats against SIP (at > least one of which is > described in bis) that justify end-to-end confidentiality > of bodies. I'm not > sure that I want intermediaries to be able to inspect or > potentially modify > SIP bodies, especially SDP, for a number of reasons. I > think we need a base > SIP mechanism to address this concern. If you want your protocol to be capable of traversing multiple heterogeneous networks then you must pass the network control information in such a way that the routing devices can modify it as necessary. If you don't like this then you are stuck with the naive world of single uniform address spaces throughout the world or protocols that require all connections from the client to the server, and not from server to client, and no connectionless protocols. Whilst I agree that authenticating the "user identity" of the other end of the call is important, I don't care which actual address the call actually came from (anyway the user want's to hide this anyway -- hence the proliferation of NAT firewalls), or how it got routed to me -- just that it did. I would prefer that you added an extra body to the message that has the user's certificate or whatever, to prove user identity, and leave the routing information in-the-clear so the routers can do their stuff. It is a serious oversight in SIP that the control, identity and content of the message are intermingled in such a haphazard way. --------------------------------------------------------- Phil Reynolds Ridgeway Systems and Software Tel: +44 118 938 1211 Fax: +44 118 935 4444 mailto:preynolds@ridgewaysystems.com http://www.ridgewaysystems.com ------_=_NextPart_001_01C1B60E.360466A0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] 'sips' URI scheme (comments on proposal?)

> I believe there are reasonable threats against = SIP (at
> least one of which is
> described in bis) that justify end-to-end = confidentiality
> of bodies. I'm not
> sure that I want intermediaries to be able to = inspect or
> potentially modify
> SIP bodies, especially SDP, for a number of = reasons. I
> think we need a base
> SIP mechanism to address this concern.

If you want your protocol to be capable of traversing = multiple heterogeneous networks then you must pass the network control = information in such a way that the routing devices can modify it as = necessary. If you don't like this then you are stuck with the naive = world of single uniform address spaces throughout the world or = protocols that require all connections from the client to the server, = and not from server to client, and no connectionless = protocols.

Whilst I agree that authenticating the "user = identity" of the other end of the call is important, I don't care = which actual address the call actually came from (anyway the user = want's to hide this anyway -- hence the proliferation of NAT = firewalls), or how it got routed to me -- just that it did.

I would prefer that you added an extra body to the = message that has the user's certificate or whatever, to prove user = identity, and leave the routing information in-the-clear so the routers = can do their stuff.

It is a serious oversight in SIP that the control, = identity and content of the message are intermingled in such a = haphazard way.

---------------------------------------------------------
Phil Reynolds
Ridgeway Systems and Software
Tel: +44 118 938 1211
Fax: +44 118 935 4444
mailto:preynolds@ridgeways= ystems.com
http://www.ridgewaysystems.com

------_=_NextPart_001_01C1B60E.360466A0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 07:25:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03167 for ; Fri, 15 Feb 2002 07:25:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16585 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 07:25:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15642; Fri, 15 Feb 2002 07:03:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15538 for ; Fri, 15 Feb 2002 07:03:06 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02628; Fri, 15 Feb 2002 07:03:04 -0500 (EST) Message-Id: <200202151203.HAA02628@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 15 Feb 2002 07:03:04 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : Management Information Base for Session Initiation Protocol Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker Filename : draft-ietf-sip-mib-04.txt Pages : 92 Date : 14-Feb-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, Proxy servers, Redirect servers and Registrars. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-mib-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-mib-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020214105941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020214105941.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 08:10:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04290 for ; Fri, 15 Feb 2002 08:10:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA18987 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 08:10:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17791; Fri, 15 Feb 2002 07:51:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17768 for ; Fri, 15 Feb 2002 07:51:11 -0500 (EST) Received: from mailhost.wellx.com (mailhost.wellx.com [62.161.157.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03786 for ; Fri, 15 Feb 2002 07:51:08 -0500 (EST) Received: from mail.wellx.com by mailhost.wellx.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 15 Feb 2002 12:46:15 UT Received: from wellx.com (SIP [192.168.1.114]) by srvwellx.wellx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CVPQA277; Fri, 15 Feb 2002 13:43:52 +0100 Message-ID: <3C6D05EB.322E882D@wellx.com> Date: Fri, 15 Feb 2002 13:58:19 +0100 From: Aymeric MOIZARD Organization: WellX X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 CC: sip@ietf.org Subject: Re: [Sip] Comments on bis-07. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The following text is located at line 5925: "Removing the contact before adding the response to the response contact prevents the next element upstream from retrying a location this proxy has already attempted." The "response contact" should be the "response context"? Aymeric _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 10:57:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09039 for ; Fri, 15 Feb 2002 10:57:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27292 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 10:57:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25323; Fri, 15 Feb 2002 10:23:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25292 for ; Fri, 15 Feb 2002 10:23:54 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08019 for ; Fri, 15 Feb 2002 10:23:52 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1FFMuZ26887; Fri, 15 Feb 2002 07:22:57 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX03343; Fri, 15 Feb 2002 07:22:32 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA28128; Fri, 15 Feb 2002 07:23:00 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.10196.338294.88758@thomasm-u1.cisco.com> Date: Fri, 15 Feb 2002 07:23:00 -0800 (PST) To: "Peterson, Jon" Cc: "'Jari Arkko'" , Michael Thomas , Juha Heinanen , Jonathan Rosenberg , Lawrence Conroy , Henry Sinnreich , sip@ietf.org Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: <70565611B164D511957A001083FCDD56CAAF3D@VA02> References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > > I believe there are reasonable threats against SIP (at least one of which is > described in bis) that justify end-to-end confidentiality of bodies. I'm not > sure that I want intermediaries to be able to inspect or potentially modify > SIP bodies, especially SDP, for a number of reasons. I think we need a base > SIP mechanism to address this concern. As far as I can tell, only the authors and the AD have shown any interest in this. Nor did the security design team have any input on this at all. I don't call that rough consensus. This is trivially separable from the bis draft. Life manifestly will go on without SMIME support, regardless of any threatened vetos. The most likely outcome is that millions and millions of UA's will ignore this just like they ignored the PGP stuff. Forcing it in because of parlimentary reasons is oh-so ITU-like; as in, engineering for the sake of engineering, rather than for the sake of accomplishing something useful. 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 daemon@optimus.ietf.org Fri Feb 15 11:22:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09930 for ; Fri, 15 Feb 2002 11:22:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28903 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 11:22:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26572; Fri, 15 Feb 2002 10:46:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26547 for ; Fri, 15 Feb 2002 10:46:28 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08583 for ; Fri, 15 Feb 2002 10:46:24 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1FFkfq32525; Fri, 15 Feb 2002 07:46:41 -0800 (PST) To: Michael Thomas Cc: "Peterson, Jon" , "'Jari Arkko'" , Juha Heinanen , Jonathan Rosenberg , Lawrence Conroy , Henry Sinnreich , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 15 Feb 2002 07:46:41 -0800 In-Reply-To: Michael Thomas's message of "Fri, 15 Feb 2002 07:23:00 -0800 (PST)" Message-ID: Lines: 58 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > Peterson, Jon writes: > > > > I believe there are reasonable threats against SIP (at least one of which is > > described in bis) that justify end-to-end confidentiality of bodies. I'm not > > sure that I want intermediaries to be able to inspect or potentially modify > > SIP bodies, especially SDP, for a number of reasons. I think we need a base > > SIP mechanism to address this concern. > > As far as I can tell, only the authors and the AD > have shown any interest in this. Nor did the > security design team have any input on this at > all. I don't call that rough consensus. > > This is trivially separable from the bis draft. > Life manifestly will go on without SMIME support, > regardless of any threatened vetos. The most > likely outcome is that millions and millions of > UA's will ignore this just like they ignored the > PGP stuff. Forcing it in because of parlimentary > reasons is oh-so ITU-like; as in, engineering for > the sake of engineering, rather than for the sake > of accomplishing something useful. I'm not sure we have rough consensus but I also don't agree that only the AD and the authors have shown any interest. Let's take a step back: The current SIP security mechanisms have NO way to protect against a malicious (but certified) proxy. S/MIME provides such a mechanism (albeit, not as cleanly as I would like). SIP either needs to have something like S/MIME support or it needs a disclaimer to the effect that there's basically no security. For instance: "SIP security relies critically on the security of the proxies. In any environment where the messages may go through untrusted proxies, no security properties can be assured." As for the assertion that we're behaving like the ITU... what of it? My view of the situation is a little different. Left to their own, WGs almost invariably design protocols with weak security mechanisms. One of the jobs of the IESG is to exert backpressure on the WG when that happens. The IESG obviously needs to be sensitive to the claim that something is difficult to implement, but that doesn't mean yielding whenever some implementor claims that they just don't want to. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Fri Feb 15 11:34:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10356 for ; Fri, 15 Feb 2002 11:34:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00352 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 11:34:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28118; Fri, 15 Feb 2002 11:06:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28088 for ; Fri, 15 Feb 2002 11:05:58 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09415 for ; Fri, 15 Feb 2002 11:05:56 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1FG5GZ16900; Fri, 15 Feb 2002 08:05:16 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX03970; Fri, 15 Feb 2002 08:04:56 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA28132; Fri, 15 Feb 2002 08:05:24 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.12740.716729.637034@thomasm-u1.cisco.com> Date: Fri, 15 Feb 2002 08:05:24 -0800 (PST) To: EKR Cc: Michael Thomas , "Peterson, Jon" , "'Jari Arkko'" , Juha Heinanen , Jonathan Rosenberg , Lawrence Conroy , Henry Sinnreich , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit You seem into falling into a false dichotomy that if SMIME doesn't go into bis, we are now and forever resigned to inadequate security for SIP. This is bogus. A standards track draft could trivially be pursued by the WG and it would be far stronger if there were actual ROUGH CONSENSUS amongst the implementors rather than fiat by those manning the veto buttons. What is in bis now seems to have no support amongst those building UA's and since it's only a SHOULD there isn't even a penalty if you ignore it. Also: I have seen no evidence that the backpressure has even considered anything other than what is expedient to give this draft a new RFC number regardless of utility. Mike Eric Rescorla writes: > Michael Thomas writes: > > > Peterson, Jon writes: > > > > > > I believe there are reasonable threats against SIP (at least one of which is > > > described in bis) that justify end-to-end confidentiality of bodies. I'm not > > > sure that I want intermediaries to be able to inspect or potentially modify > > > SIP bodies, especially SDP, for a number of reasons. I think we need a base > > > SIP mechanism to address this concern. > > > > As far as I can tell, only the authors and the AD > > have shown any interest in this. Nor did the > > security design team have any input on this at > > all. I don't call that rough consensus. > > > > This is trivially separable from the bis draft. > > Life manifestly will go on without SMIME support, > > regardless of any threatened vetos. The most > > likely outcome is that millions and millions of > > UA's will ignore this just like they ignored the > > PGP stuff. Forcing it in because of parlimentary > > reasons is oh-so ITU-like; as in, engineering for > > the sake of engineering, rather than for the sake > > of accomplishing something useful. > > I'm not sure we have rough consensus but I also don't agree that only > the AD and the authors have shown any interest. > > > Let's take a step back: > The current SIP security mechanisms have NO way to protect against a > malicious (but certified) proxy. S/MIME provides such a mechanism > (albeit, not as cleanly as I would like). > > SIP either needs to have something like S/MIME support or it needs a > disclaimer to the effect that there's basically no security. > > For instance: > "SIP security relies critically on the security of the > proxies. In any environment where the messages may go through > untrusted proxies, no security properties can be assured." > > > As for the assertion that we're behaving like the ITU... what of it? > My view of the situation is a little different. Left to their own, > WGs almost invariably design protocols with weak security > mechanisms. One of the jobs of the IESG is to exert backpressure on > the WG when that happens. The IESG obviously needs to be sensitive to > the claim that something is difficult to implement, but that doesn't > mean yielding whenever some implementor claims that they just don't > want to. > > > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.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 daemon@optimus.ietf.org Fri Feb 15 11:38:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10546 for ; Fri, 15 Feb 2002 11:38:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00769 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 11:38:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28365; Fri, 15 Feb 2002 11:10:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28334 for ; Fri, 15 Feb 2002 11:10:44 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09652 for ; Fri, 15 Feb 2002 11:10:42 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FG9dN27272; Fri, 15 Feb 2002 10:09:39 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CP2W>; Fri, 15 Feb 2002 10:09:39 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011878F2@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jari Arkko'" , "Peterson, Jon" , Michael Thomas , Juha Heinanen Cc: Jonathan Rosenberg , Lawrence Conroy , Henry Sinnreich , "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?) Date: Fri, 15 Feb 2002 10:09:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B63B.2AE263D0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B63B.2AE263D0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > My call here could be to have a MUST for enhanced digest and > a SHOULD for TLS, MAY for IPsec and SMIME, leaving SIP with a > scheme that can cover both h2h/e2m/e2e protection and > UDP/SCTP/TCP, and room for the different groups to do their > favorite thing in addition. > I agree. As far as S/MIME goes, the only additional benefit that it provides to (enhanced) Digest is message body confidentiality. I'm not sure that requirement is strong enough to justify inclusion of a long and verbose section on S/MIME in bis. Like enhanced Digest, it should be separate from bis in a separate draft. ------_=_NextPart_001_01C1B63B.2AE263D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] 'sips' URI scheme (comments on proposal?)

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@kolumbus.fi= ]
<snipped>

>      My call here could = be to have a MUST for enhanced digest and
>      a SHOULD for TLS, = MAY for IPsec and SMIME, leaving SIP with a
>      scheme that can = cover both h2h/e2m/e2e protection and
>      UDP/SCTP/TCP, and = room for the different groups to do their
>      favorite thing in = addition.
>
I agree. As far as S/MIME goes, the only additional = benefit that it provides to (enhanced) Digest is message body = confidentiality. I'm not sure that requirement is strong enough to = justify inclusion of a long and verbose section on S/MIME in bis. Like = enhanced Digest, it should be separate from bis in a separate = draft.

------_=_NextPart_001_01C1B63B.2AE263D0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 11:42:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10787 for ; Fri, 15 Feb 2002 11:42:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01071 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 11:42:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28754; Fri, 15 Feb 2002 11:19:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28712 for ; Fri, 15 Feb 2002 11:19:29 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09850 for ; Fri, 15 Feb 2002 11:19:25 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1FGJXo32590; Fri, 15 Feb 2002 08:19:33 -0800 (PST) To: Michael Thomas Cc: "Peterson, Jon" , "'Jari Arkko'" , Juha Heinanen , Jonathan Rosenberg , Lawrence Conroy , Henry Sinnreich , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 15 Feb 2002 08:19:33 -0800 In-Reply-To: Michael Thomas's message of "Fri, 15 Feb 2002 08:05:24 -0800 (PST)" Message-ID: Lines: 44 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > You seem into falling into a false dichotomy that > if SMIME doesn't go into bis, we are now and > forever resigned to inadequate security for > SIP. I don't think it's a false dichotomy. Rather, it's a pretty accurate statement of the common pattern. To whit: WG produces a document with horrible security problems. Says, "we'll fix security later". Document passes. WG doesn't fix security. > This is bogus. A standards track draft could > trivially be pursued by the WG and it would be far > stronger if there were actual ROUGH CONSENSUS > amongst the implementors rather than fiat by those > manning the veto buttons. The problem with doing it as a separate draft is that the WG almost never has any incentive to push that draft through, precisely because of the kind of complaining from implementors that you're engaging in now. OTOH, if the IESG holds up the main draft, that gives the WG some incentive. [Disclaimer: Since I'm not on the IESG, I clearly don't speak for them on this one, but that's my view of the situation.] > What is in bis now seems to have no support > amongst those building UA's and since it's only a > SHOULD there isn't even a penalty if you ignore > it. I'd be perfectly willing to have it a MUST if that would make you happier. > Also: I have seen no evidence that the > backpressure has even considered anything other > than what is expedient to give this draft a new > RFC number regardless of utility. We'd get a lot further here if you'd stop accusing other people of bad faith. From what I've seen the authors are genuinely interested in producing something that will more or less work. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Fri Feb 15 11:45:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10860 for ; Fri, 15 Feb 2002 11:45:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01154 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 11:45:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29105; Fri, 15 Feb 2002 11:24:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29059 for ; Fri, 15 Feb 2002 11:24:44 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10012 for ; Fri, 15 Feb 2002 11:24:42 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1FGOZio022693; Fri, 15 Feb 2002 18:24:35 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.13891.206598.138858@harjus.eng.song.fi> Date: Fri, 15 Feb 2002 18:24:35 +0200 To: "Sanjoy Sen" Cc: "'Jari Arkko'" , "Peterson, Jon" , Michael Thomas , Jonathan Rosenberg , Lawrence Conroy , Henry Sinnreich , sip@ietf.org Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: <933FADF5E673D411B8A30002A5608A0E011878F2@zrc2c012.us.nortel.com> References: <933FADF5E673D411B8A30002A5608A0E011878F2@zrc2c012.us.nortel.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sanjoy Sen writes: > > My call here could be to have a MUST for enhanced digest and > > a SHOULD for TLS, MAY for IPsec and SMIME, leaving SIP with a > > scheme that can cover both h2h/e2m/e2e protection and > > UDP/SCTP/TCP, and room for the different groups to do their > > favorite thing in addition. i too vote for the above, because (non-enhanced) digest is what almost everyone has implemented now and there is also a considerable installed base for tls. by the way, if one implements tls, then i guess also basic would be ok or do we still require digest? i would vote for still requiring digest, because it would simply the ua not having to do both digest and basic. -- 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 daemon@optimus.ietf.org Fri Feb 15 11:53:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11134 for ; Fri, 15 Feb 2002 11:53:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01680 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 11:53:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29221; Fri, 15 Feb 2002 11:26:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29197 for ; Fri, 15 Feb 2002 11:26:19 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10029 for ; Fri, 15 Feb 2002 11:26:17 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g1FGQHa15113; Fri, 15 Feb 2002 11:26:17 -0500 Message-Id: <200202151626.g1FGQHa15113@minotaur.nge.isi.edu> To: EKR cc: sip@ietf.org Reply-To: mankin@isi.edu Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-reply-to: Your message of 15 Feb 2002 08:19:33 -0800. Date: Fri, 15 Feb 2002 11:26:17 -0500 From: Allison Mankin Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Eric Rescorla wrote (in this now mis-titled thread): > The problem with doing it as a separate draft is that the WG > almost never has any incentive to push that draft through, > precisely because of the kind of complaining from implementors > that you're engaging in now. OTOH, if the IESG holds up the main > draft, that gives the WG some incentive. > > [Disclaimer: Since I'm not on the IESG, I clearly don't speak for them > on this one, but that's my view of the situation.] That is the AD's view of the situation too. Thank you. Allison _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 12:01:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11373 for ; Fri, 15 Feb 2002 12:01:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03122 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 12:01:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00626; Fri, 15 Feb 2002 11:36:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00597 for ; Fri, 15 Feb 2002 11:36:05 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10465 for ; Fri, 15 Feb 2002 11:35:56 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id 8EF45A22E; Fri, 15 Feb 2002 18:35:55 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: , Date: Fri, 15 Feb 2002 18:35:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit Subject: [Sip] Comments on section 19 Transport in bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, I decided to divide my comments into sections, the earlier email I sent seemed to be too long. Line numbers refer to the pdf version. Section 19.1.2 - line 3634: "the response MUST be rejected". Better if it says "the response MUST be silently discarded". - lines 3635 to 3639: talks about how the response should be passed to the core if no client transaction is found. Is this a potential DoS attack? Section 19.2.2 - line 3668: "If that connection is no longer open, the server MAY open a connection to the IP address in the received parameter,". MAY? what other options does the server have if it longer has the connection open? I think this MAY should be a MUST. - line 3671: should SSL be SCTP instead? - line 3680: "If this fails, e.g., elicits an ICMP 뱎ort unreachable� response, send the response to the address in the 뱒ent-by� parameter." Is sending the response to the address in the "sent-by" a MUST or SHOULD?. Maybe better read "If this fails, e.g., elicits an ICMP 뱎ort unreachable� response, the response MUST (SHOULD) be to the address in the 뱒ent-by� parameter.". Section 19.3 - line 3689: "If the message is a response, it MUST be discarded. If its a request, the element SHOULD generate a 400 class response". which response exactly? the 400 itself? if so, the word "class" should be removed from that sentence and (Bad Request) should be added. Regards, Hisham Khartabil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 12:01:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11389 for ; Fri, 15 Feb 2002 12:01:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03159 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 12:01:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00911; Fri, 15 Feb 2002 11:40:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00883 for ; Fri, 15 Feb 2002 11:40:30 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10647 for ; Fri, 15 Feb 2002 11:40:27 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1FGdwhM011359; Fri, 15 Feb 2002 17:39:58 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1FGdvr6021070; Fri, 15 Feb 2002 18:39:57 +0200 (EET) Message-ID: <3C6D39DE.4512617A@lmf.ericsson.se> Date: Fri, 15 Feb 2002 18:39:58 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: EKR CC: mankin@isi.edu, sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: <200202151626.g1FGQHa15113@minotaur.nge.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > The problem with doing it as a separate draft is that the WG > almost never has any incentive to push that draft through, > precisely because of the kind of complaining from implementors > that you're engaging in now. I think everyone here agrees to this. There's no question at all that we need a mandatory basic-level security in RFCs. Same RFC or different RFC with a keep-in-queue-until-reference- is-there gets you the same result. But I think the current discussion has often the following pattern: A: MUST Foo B: Oh no, not Foo, can't implement it and not useful for me. A: If not Foo, then there's a security hole and IESG might stop us from getting through if we have a security hole B: $%%^1 This doesn't appear like a very useful discussion form. But A's argument above isn't always the right one. We are constantly reminded that the chosen security mechanisms do not cover all needs and threats, and I agree. But this invalidates the argument above on IESG stopping us if we drop a particular security piece. What *really* matters is whether we have the right priorities for the threats we intend to solve, not that we have necessarily solved all threats. Just the ones that we and IESG feels are the main ones. I'd like to see a list from the Bis editors that shows their priorities and justification, perhaps in a manner similarly to what I e-mailed few mails ago. THEN we could move on from this discussion pattern into a more productive one. Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 12:07:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11643 for ; Fri, 15 Feb 2002 12:07:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03630 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 12:07:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01341; Fri, 15 Feb 2002 11:47:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01311 for ; Fri, 15 Feb 2002 11:47:42 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10947 for ; Fri, 15 Feb 2002 11:47:39 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1FGlxU32673; Fri, 15 Feb 2002 08:47:59 -0800 (PST) To: Jari Arkko Cc: mankin@isi.edu, sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: <200202151626.g1FGQHa15113@minotaur.nge.isi.edu> <3C6D39DE.4512617A@lmf.ericsson.se> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 15 Feb 2002 08:47:59 -0800 In-Reply-To: Jari Arkko's message of "Fri, 15 Feb 2002 18:39:58 +0200" Message-ID: Lines: 41 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jari Arkko writes: > > The problem with doing it as a separate draft is that the WG > > almost never has any incentive to push that draft through, > > precisely because of the kind of complaining from implementors > > that you're engaging in now. > > I think everyone here agrees to this. There's > no question at all that we need a mandatory > basic-level security in RFCs. Same RFC or > different RFC with a keep-in-queue-until-reference- > is-there gets you the same result. Yes, I don't care which of these it is. > We are constantly reminded that the > chosen security mechanisms do not cover all > needs and threats, and I agree. But this invalidates > the argument above on IESG stopping us if we > drop a particular security piece. What *really* > matters is whether we have the right priorities > for the threats we intend to solve, not that we > have necessarily solved all threats. Just the > ones that we and IESG feels are the main ones. Agreed. It's my view that having no protection against rogue proxies isn't really adequate. OTOH, if that's what the WG group really wants, I'm not going to kick up an enormous fuss. However, I do think that if we're going to accept that kind of security hole we have an obligation to actually describe what that means in the document. The purpose of my suggested text was precisely to get people to think about what kind of security hole this is so that they can decide if they really want that. If people don't feel comfortable with putting that kind of text in the RFC then the solution is to fix the protocol, not just pretend the problem doesn't exist. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Fri Feb 15 12:08:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11687 for ; Fri, 15 Feb 2002 12:08:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03700 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 12:08:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01441; Fri, 15 Feb 2002 11:49:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01413 for ; Fri, 15 Feb 2002 11:49:00 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10972 for ; Fri, 15 Feb 2002 11:48:57 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1FGmQt08738; Fri, 15 Feb 2002 08:48:26 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX04641; Fri, 15 Feb 2002 08:47:57 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA28136; Fri, 15 Feb 2002 08:48:25 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.15321.73192.780819@thomasm-u1.cisco.com> Date: Fri, 15 Feb 2002 08:48:25 -0800 (PST) To: EKR Cc: Michael Thomas , "Peterson, Jon" , "'Jari Arkko'" , Juha Heinanen , Jonathan Rosenberg , Lawrence Conroy , Henry Sinnreich , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric Rescorla writes: > Michael Thomas writes: > > You seem into falling into a false dichotomy that > > if SMIME doesn't go into bis, we are now and > > forever resigned to inadequate security for > > SIP. > I don't think it's a false dichotomy. Rather, it's a pretty > accurate statement of the common pattern. To whit: WG produces > a document with horrible security problems. Says, "we'll fix > security later". Document passes. WG doesn't fix security. Are you actually claiming that SIP without SMIME would be "a document with horrible security problems"? I sure hope not, because if you are I think you need to get a grip; the current PSTN does exactly this today, and the world has not come to an end. > > This is bogus. A standards track draft could > > trivially be pursued by the WG and it would be far > > stronger if there were actual ROUGH CONSENSUS > > amongst the implementors rather than fiat by those > > manning the veto buttons. > The problem with doing it as a separate draft is that the WG > almost never has any incentive to push that draft through, > precisely because of the kind of complaining from implementors > that you're engaging in now. OTOH, if the IESG holds up the main > draft, that gives the WG some incentive. Oh, please. There has been *abundant* interest in the WG for various security pieces. Many of the security pieces are things that actual people have *actually* been asking for have been ignored in the bis draft in favor of things that nobody's been asking for. > > What is in bis now seems to have no support > > amongst those building UA's and since it's only a > > SHOULD there isn't even a penalty if you ignore > > it. > I'd be perfectly willing to have it a MUST if that would > make you happier. This is a perfect example of why most security protocols are complete failures. Making an unworkable and bloated thing a MUST or SHOULD does not change the dynamics of development, deployment or system engineering. If something is useless and/or harmful it will not be implemented, holier-than-thou attitudes not withstanding. If we actually want to acheive something that has better security than the status quo -- and that is an abysmally low threshold as far as the eye can see -- it is generally prudent to actual consider what is feasible in the real world and provide a gradient which doesn't make it an all or nothing proposition where "nothing" is the invariable choice. But once again, what we have here is security pixie dust thrown to the wind with no concern with whether it solves real life problems. In this case, the pixie dust seems to be aimed at making the IESG happy. C'est la guerre. > > Also: I have seen no evidence that the > > backpressure has even considered anything other > > than what is expedient to give this draft a new > > RFC number regardless of utility. > We'd get a lot further here if you'd stop accusing other people of > bad faith. From what I've seen the authors are genuinely interested > in producing something that will more or less work. Placing a huge new requirement on UA's with both dubious utility and zero working group input is an example of good faith? Who knew? 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 daemon@optimus.ietf.org Fri Feb 15 12:29:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12580 for ; Fri, 15 Feb 2002 12:29:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA04953 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 12:29:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03559; Fri, 15 Feb 2002 12:04:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03528 for ; Fri, 15 Feb 2002 12:04:39 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11491 for ; Fri, 15 Feb 2002 12:04:36 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id B88AEA1D0; Fri, 15 Feb 2002 19:04:36 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: , Date: Fri, 15 Feb 2002 19:04:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Comments on section 20 Usage of HTTP Authentication in bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Line numbers refer to the pdf version. Section 20.1 -lines 3746 to 3751: I believe this paragraph should mention something about the handling of ACK for a 401/407 response to an INVITE. It is recommended that no state should be kept for unauthenticated requests (transactions). Section 20.2 - lines 3774 and 3784: the first line talks about parameters applicable to the Request-URI and the second talks about credentials for the To field. So, which one is it for? or are they 2 different things and I am just lost here? Section 20.3 - line 3856: "When a proxy server issues a challenge in response to a request, it will not proxy the request until the UAC has provided valid credentials". Better to read "When a proxy server issues a challenge in response to a request, it will not proxy any new request from that UAC until it has been provided valid credentials". - lines 3869 to 3872: So what happens? Does the UAC include multiple Authorization / Proxy-Authorization headers in the new request for the same realm? I say yes. This needs to be mentioned. Regards, Hisham Khartabil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 12:32:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12766 for ; Fri, 15 Feb 2002 12:32:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05616 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 12:32:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03739; Fri, 15 Feb 2002 12:08:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03699 for ; Fri, 15 Feb 2002 12:08:17 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11682 for ; Fri, 15 Feb 2002 12:08:14 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1FH8I132697; Fri, 15 Feb 2002 09:08:18 -0800 (PST) To: Michael Thomas Cc: "Peterson, Jon" , "'Jari Arkko'" , Juha Heinanen , Jonathan Rosenberg , Lawrence Conroy , Henry Sinnreich , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 15 Feb 2002 09:08:18 -0800 In-Reply-To: Michael Thomas's message of "Fri, 15 Feb 2002 08:48:25 -0800 (PST)" Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > Placing a huge new requirement on UA's with both > dubious utility and zero working group input is > an example of good faith? Who knew? Michael, one of the things that draft authors do is put text into drafts so that it can be debated by the WG. As for the changes being of dubious utility, I know it's hard for you to believe, but people might have different opinions from you about utility. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Fri Feb 15 12:43:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13432 for ; Fri, 15 Feb 2002 12:43:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06204 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 12:43:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04003; Fri, 15 Feb 2002 12:12:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03968 for ; Fri, 15 Feb 2002 12:12:33 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12000 for ; Fri, 15 Feb 2002 12:12:29 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1FHCVio022760; Fri, 15 Feb 2002 19:12:31 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.16767.485618.726986@harjus.eng.song.fi> Date: Fri, 15 Feb 2002 19:12:31 +0200 To: mankin@isi.edu Cc: EKR , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: <200202151626.g1FGQHa15113@minotaur.nge.isi.edu> References: <200202151626.g1FGQHa15113@minotaur.nge.isi.edu> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Allison Mankin writes: > > The problem with doing it as a separate draft is that the WG > > almost never has any incentive to push that draft through, > > precisely because of the kind of complaining from implementors > > that you're engaging in now. OTOH, if the IESG holds up the main > > draft, that gives the WG some incentive. > > > > [Disclaimer: Since I'm not on the IESG, I clearly don't speak for them > > on this one, but that's my view of the situation.] > > That is the AD's view of the situation too. Thank you. if the ADs really want the wg to publish a document that includes unimplemented stuff that has no industry or user support and that is there just to please the process, then the only right thing to do is to publish the current document as "experimental". after that we'll have time to find out what the real solution will be that will gain wide industry and user support and once we are all convinced, we'll respin the document as a standards track rfc. -- 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 daemon@optimus.ietf.org Fri Feb 15 12:48:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13759 for ; Fri, 15 Feb 2002 12:48:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06755 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 12:48:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05058; Fri, 15 Feb 2002 12:29:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05030 for ; Fri, 15 Feb 2002 12:29:57 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12619 for ; Fri, 15 Feb 2002 12:29:53 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id 418F3A2D8; Fri, 15 Feb 2002 19:29:53 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: , Date: Fri, 15 Feb 2002 19:29:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Comments on section 21 S/MINE in bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Line numbers refer to the pdf version. Section 21.1 - All SHOULDs and MAYs in the last 2 paragraphs of this section should be lower case. They are not protocol related. Section 21.3 - line 4036: the sentence is incomplete in the .txt version. Section 21.4.1.1 - Its true that Via can be modified by a proxy, but at least the sent-by field can be checked. Section 21.4.1.2 - lines 4064 to 4067: So, are the outer headers used to identify a dialog (session)? Are the outer ones used to compute the Branch-id? this needs to be mentioned at the end of that paragraph. BTW, it should mention somewhere that the TU is the one who decrypts (if I haven't missed it). Section 21.4.2 - line 4098: "In order to eliminate possible confusions about the addition or subtraction of entire headers, senders SHOULD replicate all headers from the request within the signed body". "replicate" gives the false impression that the outer header values shouldn't be changed. It should read "In order to eliminate possible confusions about the addition or subtraction of entire headers, all outer headers SHOULD reappear in the inner message, some header values MAY differ". - line 4102: "or" should be "and". Section 21.4.3 - This section talks about tunnelling encrypted SIP messages with content-type of message/sip. It also talks about how a From header can have anonymous. Yet, the example does not reflect that at all, it only has a normal encryption of SDP. This example should perhaps be moved to section 21.3 and a new example put here that reflects the discussion. Regards, Hisham Khartabil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 13:02:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14190 for ; Fri, 15 Feb 2002 13:02:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA07854 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 13:02:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05886; Fri, 15 Feb 2002 12:37:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05852 for ; Fri, 15 Feb 2002 12:37:25 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13116 for ; Fri, 15 Feb 2002 12:37:21 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id 57C72A47F; Fri, 15 Feb 2002 19:37:22 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: , Date: Fri, 15 Feb 2002 19:37:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Very minor nits on section 22 Security Considerations in bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit These are very minor nits, but I'm sending them anyway to complete my review. Line numbers refer to the pdf version. Section 22 - line 4203: "is" should be "are". Section 22.3.2.3 - I thought we were still talking about Alice until Carol's name was mentioned. Perhaps Carol should be introduced :) Regards, Hisham Khartabil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 13:03:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14230 for ; Fri, 15 Feb 2002 13:03:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA07901 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 13:03:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05784; Fri, 15 Feb 2002 12:35:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05753 for ; Fri, 15 Feb 2002 12:35:11 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13011 for ; Fri, 15 Feb 2002 12:35:07 -0500 (EST) From: bernhard.honeisen@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1FHZXi24555 for ; Fri, 15 Feb 2002 19:35:33 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 15 Feb 2002 19:35:08 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Feb 2002 19:35:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 15 Feb 2002 19:35:08 +0200 Message-ID: Thread-Topic: Some Loose Routing feedback Thread-Index: AcG2Rxk5TCK5KiIoEdatVABQi80jQw== To: X-OriginalArrivalTime: 15 Feb 2002 17:35:08.0405 (UTC) FILETIME=[1CBB3A50:01C1B647] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA05754 Subject: [Sip] Some Loose Routing feedback Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Editors of RFC2543bis! I am really facinated, that the dilemma Loose Routing vs. Strict Routing could be solved even in a backwards compatible way. Great job! Studying the Loose Routing approach more deeply, I'd have the following feeback: (I am referring line numbers in the pdf version.) - 2464: LaTeX mistake. I guess the \ref tag is miss-spelled. - 2508-2509 and 2598-2600 might be somewhat confusing concerning in which situations it is allowed to push route headers - The example in section 16.11.1.2 maybe should have the following configuration: p1;lr, p2;lr; p3; p4;lr Then it would show a difference in the processing, if after a strict router, there follow two loose routers. The processing descibed in 3048-3050, would have to deal with the case, if there is a Route header present in the outgoing request. This make the example more general. I propose to modify section 16.11.1.2 to something like the following: ---BEGIN--- 16.11.1.2 Traversing a strict-routing proxy In this scanario, a dialog is established across four proxies, each of which adds Record-Route header field values. The third proxy implements the strict-routing proceedures specified in RFC2543 and the bis drafts up to bis-05. U1->P1->P2->P3->P4>U2 The INVITE arriving at U2 contains INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: Record-Route: Record-Route: Record-Route: Which U2 responds to with a 200 OK. Later, U2 sends the following BYE to P4 based on the first Route header field value. BYE sip:caller@u1.example.com SIP/2.0 Route: Route: Route: Route: P4 is not responsible for the resource indicated in the Request-URI so it will leave it alone. It notices that it is the element in the first Route header field value so it removes it. It then prepares to send the request based on the now first Route header field value of sip:p3.middle.com, but it notices that this URI does not contain the lr parameter, so before sending, it reformats the request to be: BYE sip:p3.middle.com SIP/2.0 Route: Route: Route: P3 is a strict router, so it forwards the following to P2: BYE sip:p2.looser.com;lr SIP/2.0 Route: Route: P2 sees the request-URI is a value it placed into a Record-Route header field, so before further processing, it rewrites the request to be BYE sip:caller@u1.example.com SIP/2.0 Route: /*** I guess this is the intended behaviour ***/ and sends the request to P1 based on the first Route header field value. P1 notices that it is the element in the first Route header field value so it removes it. Since P1 is not responsible for u1.example.com and there is no Route header field, P1 will forward the request to u1.example.com based on the Request-URI: BYE sip:caller@u1.example.com SIP/2.0 ---END--- I hope there no mistakes...:-) - I was thinking, whether a marking of the intended destination (e.g. ;fd ) makes the backwards compatibility mechanisms for loose/strict routing more robust. I am not yet sure, whether this really helps in anything. I was thinking about cases, where the final destination disappears due to a wrong proxy operation or is otherwise absent. Just something to think about... That's all for now. Maybe I find some more things later... Have fun! cheers, Bernie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 13:04:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14283 for ; Fri, 15 Feb 2002 13:04:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA07984 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 13:04:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06249; Fri, 15 Feb 2002 12:44:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06221 for ; Fri, 15 Feb 2002 12:44:29 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13515 for ; Fri, 15 Feb 2002 12:44:28 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g1FHiKs15165; Fri, 15 Feb 2002 12:44:21 -0500 Message-Id: <200202151744.g1FHiKs15165@minotaur.nge.isi.edu> To: Juha Heinanen cc: mankin@isi.edu, EKR , sip@ietf.org Reply-To: mankin@isi.edu Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-reply-to: Your message of Fri, 15 Feb 2002 19:12:31 +0200. <15469.16767.485618.726986@harjus.eng.song.fi> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Fri, 15 Feb 2002 12:44:20 -0500 From: Allison Mankin Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Juha, Only if this were going to Draft Standard, would we bar features that are new and unimplemented. But anyway, the specified security implementations are not new and unimplemented: TLS, S/MIME and Digest Authentication are all old specifications, widely used in applications of all kinds. There's a vulnerability assessment (required) in bis and the security solutions are needed to address those vulnerabilities. (Not all vulnerabilities for all time, but a key set). SIP is for the Internet. It will not pass with security based on closed system plans of some industries, even if those industries and vendors object to the Internet requirements of the protocol. Allison _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 13:26:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14859 for ; Fri, 15 Feb 2002 13:26:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA08988 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 13:26:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07833; Fri, 15 Feb 2002 13:01:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07805 for ; Fri, 15 Feb 2002 13:01:55 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14180 for ; Fri, 15 Feb 2002 13:01:54 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1FI17Z17949; Fri, 15 Feb 2002 10:01:09 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX06661; Fri, 15 Feb 2002 10:00:47 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA28146; Fri, 15 Feb 2002 10:01:15 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.19691.318099.69121@thomasm-u1.cisco.com> Date: Fri, 15 Feb 2002 10:01:15 -0800 (PST) To: mankin@isi.edu Cc: Juha Heinanen , EKR , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: <200202151744.g1FHiKs15165@minotaur.nge.isi.edu> References: <15469.16767.485618.726986@harjus.eng.song.fi> <200202151744.g1FHiKs15165@minotaur.nge.isi.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Allison Mankin writes: > Juha, > > Only if this were going to Draft Standard, would we bar features > that are new and unimplemented. But anyway, the specified security > implementations are not new and unimplemented: TLS, S/MIME > and Digest Authentication are all old specifications, widely > used in applications of all kinds. Can you please show where SMIME is widely used? > There's a vulnerability assessment (required) in bis and > the security solutions are needed to address those vulnerabilities. > (Not all vulnerabilities for all time, but a key set). One of the things being questioned here is how e2e body crypto made it into the "key set". To date, this seems to be an assertion rather than a demonstrated need. > SIP is for the Internet. It will not pass with security based > on closed system plans of some industries, even if those > industries and vendors object to the Internet requirements of > the protocol. With SIP, you can always do end-to-end INVITE's even with proxy routing. If you bring up NAT's and border proxies again, I'll point out that SMIME will not operate in those environments either. 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 daemon@optimus.ietf.org Fri Feb 15 13:29:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14899 for ; Fri, 15 Feb 2002 13:29:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09095 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 13:29:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08180; Fri, 15 Feb 2002 13:09:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08149 for ; Fri, 15 Feb 2002 13:09:20 -0500 (EST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14383 for ; Fri, 15 Feb 2002 13:09:18 -0500 (EST) Received: from jariws1 ([62.248.149.81]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020215180918.DQMI21965.fep02-app.kolumbus.fi@jariws1>; Fri, 15 Feb 2002 20:09:18 +0200 Message-ID: <002301c1b64b$e5fc3c80$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "EKR" , "Jari Arkko" Cc: , References: <200202151626.g1FGQHa15113@minotaur.nge.isi.edu> <3C6D39DE.4512617A@lmf.ericsson.se> Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) Date: Fri, 15 Feb 2002 20:09:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Agreed. It's my view that having no protection against rogue proxies > isn't really adequate. OTOH, if that's what the WG group really wants, > I'm not going to kick up an enormous fuss. However, I do think that if > we're going to accept that kind of security hole we have an obligation > to actually describe what that means in the document. The purpose of > my suggested text was precisely to get people to think about what kind > of security hole this is so that they can decide if they really want > that. All true, but we have to remember that S/MIME is not the only solution today that works against rogue proxies. In fact, the solution deployed today for that is Digest, and S/MIME does not fix *the* rogue proxy problem, it basically extends the scope of the protection to privacy, and allows a wider audience NxN benefit from the protection. Again, personally, I like the S/MIME solution *a lot* and would like to keep it in the draft. But perhaps as a MAY, and I would like to get more emphasis on the security solutions that people and certain networks also intend to use, such as digest. Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 13:45:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15211 for ; Fri, 15 Feb 2002 13:45:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA10048 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 13:45:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08412; Fri, 15 Feb 2002 13:13:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08373 for ; Fri, 15 Feb 2002 13:13:15 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14515 for ; Fri, 15 Feb 2002 13:13:13 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1FIDDio022817; Fri, 15 Feb 2002 20:13:13 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.20409.202796.938730@harjus.eng.song.fi> Date: Fri, 15 Feb 2002 20:13:13 +0200 To: mankin@isi.edu Cc: EKR , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: <200202151744.g1FHiKs15165@minotaur.nge.isi.edu> References: <15469.16767.485618.726986@harjus.eng.song.fi> <200202151744.g1FHiKs15165@minotaur.nge.isi.edu> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Allison Mankin writes: > Only if this were going to Draft Standard, would we bar features > that are new and unimplemented. But anyway, the specified security > implementations are not new and unimplemented: TLS, S/MIME > and Digest Authentication are all old specifications, widely > used in applications of all kinds. right, but who is widely using s/mime for anything? s/mime never became become popular for email and it is even less likely to become popular for sip applications. so including s/mime in the sip spec and pretending that we have solved the problem is nothing but fooling ourselves. > There's a vulnerability assessment (required) in bis and > the security solutions are needed to address those vulnerabilities. > (Not all vulnerabilities for all time, but a key set). > > SIP is for the Internet. It will not pass with security based > on closed system plans of some industries, even if those > industries and vendors object to the Internet requirements of > the protocol. i haven't has proposed any closed solution for this. i proposed that we publish the sip i-d as experimental until we find out what the popular, widely accepted security solutions will be. -- 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 daemon@optimus.ietf.org Fri Feb 15 14:08:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15979 for ; Fri, 15 Feb 2002 14:08:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11298 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 14:08:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09674; Fri, 15 Feb 2002 13:34:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09647 for ; Fri, 15 Feb 2002 13:34:27 -0500 (EST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15011 for ; Fri, 15 Feb 2002 13:34:24 -0500 (EST) Received: from jariws1 ([62.248.149.81]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020215183425.DTLF21965.fep02-app.kolumbus.fi@jariws1>; Fri, 15 Feb 2002 20:34:25 +0200 Message-ID: <007b01c1b64f$685a3b20$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , "Juha Heinanen" Cc: , "EKR" , References: <200202151744.g1FHiKs15165@minotaur.nge.isi.edu> Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) Date: Fri, 15 Feb 2002 20:34:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > There's a vulnerability assessment (required) in bis and > the security solutions are needed to address those vulnerabilities. > (Not all vulnerabilities for all time, but a key set). > > SIP is for the Internet. It will not pass with security based > on closed system plans of some industries, even if those > industries and vendors object to the Internet requirements of > the protocol. Can we please get out of this process discussion and to the technical stuff? I don't think Juha tried to argue that we don't make an Internet-scale SIP standard. The *real* question is if we have the right "key set" above! Let's start discussing that. Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 14:15:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16283 for ; Fri, 15 Feb 2002 14:15:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11548 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 14:15:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09830; Fri, 15 Feb 2002 13:39:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09798 for ; Fri, 15 Feb 2002 13:38:58 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15109 for ; Fri, 15 Feb 2002 13:38:56 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id 24CE9A4E8; Fri, 15 Feb 2002 20:38:56 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: , Date: Fri, 15 Feb 2002 20:38:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Comments on section 23 Common Message Components and section 24 Header Fields in bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Line numbers refer to the pdf version. Section 23.1.4 - line 4763: "A URI omitting the optional port component will match a URI explicitly declaring port 5060." will now read "A URI omitting the optional port component will NOT match a URI explicitly declaring port 5060". Just to save Jonathan some time. - line 4769: is now also wrong about the transport parameter. - line 4776: section number missing. - line 4778: example is now wrong. - line 4785: I thought this example was wrong also until I realised that the "&priority=urgent" is missing from the .txt version but not the pdf (in the first uri). There seems to be a few of those. Section 23.1.5 - line 4810: "an" should be "a". line 4830: "headerRequire" should be just "Require". Section 24.7 - line 5006: extra CRLF Section 24.11 - line 5070: extra CRLF Section 26.16 - It should mention that the method part of the Cseq is case-sensitive. Section 24.22 - Should mention the recommended value for max-forwards (70). Section 24.26 - is there a default value or behaviour if the Priority header is not present. eg: which message has higher priority? a message with Priority header of "urgent", or a message with no priority header? I suggest "normal". Section 24.44 - line 5373: "as shown in the second example below". This is talking about example in line 5382. But I was confused where the LWS is since I was looking at the second example of the via header directly below this sentence. Perhaps it should say "as shown in an example later in this section". Or simply add some LWS in the second via. Regards, Hisham Khartabil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 14:38:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17329 for ; Fri, 15 Feb 2002 14:38:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13086 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 14:38:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11536; Fri, 15 Feb 2002 14:15:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11505 for ; Fri, 15 Feb 2002 14:15:40 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16277 for ; Fri, 15 Feb 2002 14:15:38 -0500 (EST) Received: (qmail 2882 invoked from network); 15 Feb 2002 19:18:53 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 15 Feb 2002 19:18:53 -0000 Received: from stake.com (unknown [10.1.64.73]) by cam-relay.atstake.com (Postfix) with SMTP id 35CD822817 for ; Fri, 15 Feb 2002 14:12:30 -0500 (EST) Message-ID: <3C6D5EA3.1030704@stake.com> Date: Fri, 15 Feb 2002 19:16:51 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Review of section 22 "Security Considerations" of draft-ietf-sip-rfc2543bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Linked to this Email is a .pdf file which is a draft document reviewing "Section 22: Security Considerations" of draft-ietf-sip-rfc2543bis-07. [http://www.sys-security.com/archive/research/draft-ietf-sip-rfc2543bis-07_Review_of_section_22.pdf] Please note that this document is provided as is, and still needs to be enhanced and revised. The thoughts expressed within the document are my initial thoughts about some of the subjects mentioned in Section 22. I will be more than happy to receive feedback, corrections and suggestions from the list members. Cheers -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 14:45:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17598 for ; Fri, 15 Feb 2002 14:45:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13353 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 14:45:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11973; Fri, 15 Feb 2002 14:23:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11944 for ; Fri, 15 Feb 2002 14:23:42 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16595 for ; Fri, 15 Feb 2002 14:23:40 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1FJ2Ju01711; Fri, 15 Feb 2002 13:02:19 -0600 Message-ID: <3C6D5B3A.1000307@dynamicsoft.com> Date: Fri, 15 Feb 2002 13:02:18 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Aymeric MOIZARD CC: sip@ietf.org Subject: Re: [Sip] Comments on bis-07. References: <3C6D05EB.322E882D@wellx.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Yes - fixed - thanks. Aymeric MOIZARD wrote: > The following text is located at line 5925: > > "Removing the contact before adding the response to the > response contact prevents the next element upstream > from retrying a location this proxy has already > attempted." > > The "response contact" should be the "response context"? > > Aymeric > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Fri Feb 15 14:46:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17660 for ; Fri, 15 Feb 2002 14:46:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13388 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 14:46:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12043; Fri, 15 Feb 2002 14:25:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12014 for ; Fri, 15 Feb 2002 14:25:26 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16741 for ; Fri, 15 Feb 2002 14:25:23 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1FJPh6Y003679; Fri, 15 Feb 2002 14:25:43 -0500 (EST) Message-ID: <3C6D6085.8208F33F@dynamicsoft.com> Date: Fri, 15 Feb 2002 14:24:53 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, February 15, 2002 11:48 AM > To: EKR > Cc: Michael Thomas; Peterson, Jon; 'Jari Arkko'; Juha Heinanen; Jonathan > Rosenberg; Lawrence Conroy; Henry Sinnreich; sip@ietf.org > Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) > > Eric Rescorla writes: > > Michael Thomas writes: > > > You seem into falling into a false dichotomy that > > > if SMIME doesn't go into bis, we are now and > > > forever resigned to inadequate security for > > > SIP. > > I don't think it's a false dichotomy. Rather, it's a pretty > > accurate statement of the common pattern. To whit: WG produces > > a document with horrible security problems. Says, "we'll fix > > security later". Document passes. WG doesn't fix security. > > Are you actually claiming that SIP without SMIME > would be "a document with horrible security > problems"? I sure hope not, because if you are I > think you need to get a grip; the current PSTN > does exactly this today, and the world has not > come to an end. The Internet is not the PSTN, of course. My perspective is that S/MIME provides one really, really important security function. We have a monster hole right now, IMHO, in that an eavesdropper can listen in on an INVITE, and send fake BYE/re-INVITE or whatever to launch all kinds of attacks. An e2e TLS/IPSec solution is not sufficient, since it is too fragile - there will always be hops without security. True e2e authentication is unachievable without PKI. The solution is a self-signed cert approach, where effectively only the user that send the initial INVITE can ever send subsequent signaling. I think that this is terribly important, and without a sensible solution for it, the SIP security story for bis is not good enough. Sure, we could have invented our own thing instead of S/MIME to do this, but we would have gotten it wrong, it wouldn't be useful for other things, as S/MIME is, and so on. S/MIME therefore seems a good engineering choice to solve an important problem. Notice that since it doesn't require a PKI to provide this feature, I anticipate wider usage than S/MIME for email. For email, there is no equivalent problem as we have in SIP, and S/MIME is not useful without a client PKI. Thus, the application here suffers none of the problems that have hampered it for email. Lastly, Mike, I hope you seriously do not believe that the editors are acting inappropriately in our efforts to move forward with the spec. We are doing everything we can do move with speed and within the confines of the process. Getting consensus in this group is not trivial. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 15 15:18:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18344 for ; Fri, 15 Feb 2002 15:18:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15089 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 15:18:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14280; Fri, 15 Feb 2002 15:01:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14162 for ; Fri, 15 Feb 2002 15:01:24 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18024 for ; Fri, 15 Feb 2002 15:01:21 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1FK0gt01744; Fri, 15 Feb 2002 12:00:42 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX10515; Fri, 15 Feb 2002 12:00:13 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA28179; Fri, 15 Feb 2002 12:00:41 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.26857.822742.274406@thomasm-u1.cisco.com> Date: Fri, 15 Feb 2002 12:00:41 -0800 (PST) To: Jonathan Rosenberg Cc: sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: <3C6D6085.8208F33F@dynamicsoft.com> References: <3C6D6085.8208F33F@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Friday, February 15, 2002 11:48 AM > > To: EKR > > Cc: Michael Thomas; Peterson, Jon; 'Jari Arkko'; Juha Heinanen; Jonathan > > Rosenberg; Lawrence Conroy; Henry Sinnreich; sip@ietf.org > > Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) > > > > Eric Rescorla writes: > > > Michael Thomas writes: > > > > You seem into falling into a false dichotomy that > > > > if SMIME doesn't go into bis, we are now and > > > > forever resigned to inadequate security for > > > > SIP. > > > I don't think it's a false dichotomy. Rather, it's a pretty > > > accurate statement of the common pattern. To whit: WG produces > > > a document with horrible security problems. Says, "we'll fix > > > security later". Document passes. WG doesn't fix security. > > > > Are you actually claiming that SIP without SMIME > > would be "a document with horrible security > > problems"? I sure hope not, because if you are I > > think you need to get a grip; the current PSTN > > does exactly this today, and the world has not > > come to an end. > > The Internet is not the PSTN, of course. Yes, the Internet has conspicuously less security than the PSTN and yet it too still seems to function without news at 11:00. One thing we've learned, however, is that a sure way to keep the appalling status quo is to aim too high. Given where SIP is likely to be deployed, this is not only high, but aimed perpendicular to the earth's surface. > My perspective is that S/MIME provides one really, really > important security function. We have a monster hole right now, "Monster" is in the eye of the beholder. > IMHO, in that an eavesdropper can listen in on an INVITE, > and send fake BYE/re-INVITE or whatever to launch all kinds > of attacks. Still exists with SMIME. > An e2e TLS/IPSec solution is not sufficient, since > it is too fragile - there will always be hops without security. Fragile? > True e2e authentication is unachievable without PKI. False, false, false. First of all, e2e authentication in the small/medium/large is clearly achievable without PKI. Authentication in the large for complex cross domain relationships is now and remains a fantasy. It is pure speculation whether PKI's will deliver. Indeed, the mobile IP working group has been floundering for well over a year precisely because they improperly started from the false premise of global PKI's and the previous solution needed to be scraped once that was pointed out as a bogus premise. And *please* don't trot out the terrible web example again. You're talking about large PKI's in *clients*. > The solution > is a self-signed cert approach, where effectively only the user > that send the initial INVITE can ever send subsequent signaling. > I think that this is terribly important, and without a sensible > solution for it, the SIP security story for bis is not good > enough. PKI != self-signed certs. If you want a leap of faith solution, SMIME is an impediment, not a help. > Sure, we could have invented our own thing instead of S/MIME to > do this, but we would have gotten it wrong, it wouldn't be useful > for other things, as S/MIME is, and so on. S/MIME therefore seems > a good engineering choice to solve an important problem. I happen to think that scalable/flexible proxy authentication is a lot more pressing problem. I don't think I'm alone. I've yet to hear anybody who is clamoring for the e2e problem. Yet, we get e2e SMIME with no list discussion either about the prioritization, or the solution. What gives? > Lastly, Mike, I hope you seriously do not believe that the editors > are acting inappropriately in our efforts to move forward with the > spec. We are doing everything we can do move with speed and within the > confines of the process. Getting consensus in this group is not trivial. I think that this got put in at the last minute without any working group involvement, especially by the people who have expressed interest in the problem. I've seen no inclination to address any of the concerns brought up, or consider alternatives. Why exactly am I supposed to not feel like this isn't being rammed down our throats? 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 daemon@optimus.ietf.org Fri Feb 15 15:25:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18539 for ; Fri, 15 Feb 2002 15:25:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15457 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 15:25:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14436; Fri, 15 Feb 2002 15:05:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14405 for ; Fri, 15 Feb 2002 15:05:01 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18065 for ; Fri, 15 Feb 2002 15:04:58 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1FK2SoN010292; Fri, 15 Feb 2002 15:02:28 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 15:04:29 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F325F38B@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Bob Penfield'" , "'sip@ietf.org'" Subject: RE: [Sip] comments on draft-ietf-sip-events-02.txt Date: Fri, 15 Feb 2002 15:04:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > Have I got that right? Your explanation is spot on. I'll attempt to clarify the bit about a 200 response *not* setting up a dialog under the conditions you describe. > sec 4.2.3: Why is record-routing a MUST on all SUBSCRIBE and NOTIFY > requests? It certainly needs to be on the SUB & NOT that > establish dialogs, > but bis-07 does not allow the route to be changed (only the > target), so it > just seems like wasted bandwidth especially on subsequent > NOTIFYs within the > dialog. I think this has historically been a "MUST" for some version of bis, and I was merely reiterating it (because it was important for the NOTIFY messages in the case of a fork). I could relax it from MUST to SHOULD for messages sent inside an existing dialog, since it appears to be a SHOULD as of bis-07: If this request is already part of a dialog, the proxy SHOULD insert a Record-Route header field value if it wishes to remain on the path of future requests in the dialog. In normal endpoint operation as described in Section 12 these Record-Route header field values will not have any effect on the route sets used by the endpoints. I'm taking this comment under advisement, and may be changing the draft accordingly. I welcome comments from any interested parties. Thanks for the other comments. I will be incorporating them. /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 daemon@optimus.ietf.org Fri Feb 15 15:25:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18561 for ; Fri, 15 Feb 2002 15:25:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15474 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 15:25:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14676; Fri, 15 Feb 2002 15:09:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14645 for ; Fri, 15 Feb 2002 15:09:38 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18108 for ; Fri, 15 Feb 2002 15:09:35 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1FK8UZ19269; Fri, 15 Feb 2002 12:08:45 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX10766; Fri, 15 Feb 2002 12:08:09 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA28182; Fri, 15 Feb 2002 12:08:37 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.27332.878903.549127@thomasm-u1.cisco.com> Date: Fri, 15 Feb 2002 12:08:36 -0800 (PST) To: EKR Cc: Michael Thomas , "Peterson, Jon" , "'Jari Arkko'" , Juha Heinanen , Jonathan Rosenberg , Lawrence Conroy , Henry Sinnreich , sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric Rescorla writes: > Michael Thomas writes: > > Placing a huge new requirement on UA's with both > > dubious utility and zero working group input is > > an example of good faith? Who knew? > Michael, one of the things that draft authors do is put text into > drafts so that it can be debated by the WG. As for the changes > being of dubious utility, I know it's hard for you to believe, > but people might have different opinions from you about utility. Fine. Let's have a consensus call. 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 daemon@optimus.ietf.org Fri Feb 15 15:31:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18670 for ; Fri, 15 Feb 2002 15:31:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16007 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 15:31:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14956; Fri, 15 Feb 2002 15:14:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14925 for ; Fri, 15 Feb 2002 15:14:55 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18271 for ; Fri, 15 Feb 2002 15:14:53 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FKENN15265 for ; Fri, 15 Feb 2002 14:14:23 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <19H22KV5>; Fri, 15 Feb 2002 14:14:23 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011878F9@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: sip@ietf.org Date: Fri, 15 Feb 2002 14:14:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B65D.5B5C6480" Subject: [Sip] use of TCP in bis07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B65D.5B5C6480 Content-Type: text/plain; charset="iso-8859-1" lines 3587-3590: If a request is within 500 bytes of the path MTU, or if it is larger than 1000 bytes when the path MTU is unknown, it MUST be sent using TCP. This is to prevent fragmentation of messages over UDP, and to provide congestion control for larger messages. Although I agree with the intent, this would force terminals to use TCP in many cases - this may not be suitable for many smaller mobile terminals. This should be relaxed from MUST to SHOULD. ------_=_NextPart_001_01C1B65D.5B5C6480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable use of TCP in bis07

lines 3587-3590: If a request is within 500 bytes of = the path MTU, or if it is larger
   than 1000 bytes when the path MTU is = unknown, it MUST be sent using
   TCP. This is to prevent fragmentation = of messages over UDP, and to
   provide congestion control for larger = messages.

Although I agree with the intent, this would force = terminals to use TCP in many cases - this may not be suitable for many = smaller mobile terminals. This should be relaxed from MUST to = SHOULD.

------_=_NextPart_001_01C1B65D.5B5C6480-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 15:33:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18712 for ; Fri, 15 Feb 2002 15:33:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16054 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 15:33:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14999; Fri, 15 Feb 2002 15:15:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14968 for ; Fri, 15 Feb 2002 15:15:05 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18273 for ; Fri, 15 Feb 2002 15:15:03 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FKEXN15293 for ; Fri, 15 Feb 2002 14:14:33 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CSMS>; Fri, 15 Feb 2002 14:14:33 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011878FA@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: sip@ietf.org Date: Fri, 15 Feb 2002 14:14:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B65D.617D2610" Subject: [Sip] Clarification on overlapping transaction in bis07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B65D.617D2610 Content-Type: text/plain; charset="iso-8859-1" lines 1857-1860: A TU MUST NOT initiate a new regular transaction within a dialog while a regular transaction is in progress (in either direction) within that dialog. If there is a non-INVITE client or server transaction in progress the TU MUST wait until this transaction enters the completed or the terminated state to initiate the new transaction. What is the difference between these two sentences ? What's the consensus on Open issue 113? ------_=_NextPart_001_01C1B65D.617D2610 Content-Type: text/html; charset="iso-8859-1" Clarification on overlapping transaction in bis07

lines 1857-1860: A TU MUST NOT initiate a new regular transaction within a dialog
   while a regular transaction is in progress (in either direction)
   within that dialog. If there is a non-INVITE client or server
   transaction in progress the TU MUST wait until this transaction
   enters the completed or the terminated state to initiate the new
   transaction.

What is the difference between these two sentences ?

What's the consensus on Open issue 113?

------_=_NextPart_001_01C1B65D.617D2610-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 15:35:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18783 for ; Fri, 15 Feb 2002 15:35:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16122 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 15:35:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14478; Fri, 15 Feb 2002 15:05:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14444 for ; Fri, 15 Feb 2002 15:05:07 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18067 for ; Fri, 15 Feb 2002 15:05:04 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1FK2YoN010303 for ; Fri, 15 Feb 2002 15:02:35 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGFXX>; Fri, 15 Feb 2002 15:04:34 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F325F38C@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'sip@ietf.org'" Date: Fri, 15 Feb 2002 15:04:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Reminder: SIP Events WGLC Ending Soon! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The Working Group Last Call for the SIP Events draft is ending on Tuesday. So far, only two people have commented on it (thanks, Bob and Bert). I urge anyone with a stake in this mechanism to give the document a thorough review over the weekend, and post comments on Monday. I'll be kicking out a new version on Tuesday, which will immediately enter IETF Last Call. The latest version of the document is available at: and in a PDF-version (with changebars) at: /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 daemon@optimus.ietf.org Fri Feb 15 15:35:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18801 for ; Fri, 15 Feb 2002 15:35:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16152 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 15:35:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14771; Fri, 15 Feb 2002 15:11:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14738 for ; Fri, 15 Feb 2002 15:10:55 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18135 for ; Fri, 15 Feb 2002 15:10:52 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1FKAIb32638; Fri, 15 Feb 2002 15:10:19 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4GVN>; Fri, 15 Feb 2002 14:10:13 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF3F@VA02> From: "Peterson, Jon" To: "'Phil Reynolds'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?) Date: Fri, 15 Feb 2002 14:10:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B65C.C60CD220" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B65C.C60CD220 Content-Type: text/plain; charset="iso-8859-1" A brief note below, a bit on the need for S/MIME. Jon Peterson NeuStar, Inc. -----Original Message----- From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com] Sent: Friday, February 15, 2002 2:48 AM To: 'sip@ietf.org' Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?) > I believe there are reasonable threats against SIP (at least one of which is > described in bis) that justify end-to-end confidentiality f bodies. I'm not > sure that I want intermediaries to be able to inspect or potentially modify > SIP bodies, especially SDP, for a number of reasons. I think we need a base > SIP mechanism to address this concern. If you want your protocol to be capable of traversing multiple heterogeneous networks then you must pass the network control information in such a way that the routing devices can modify it as necessary. If you don't like this then you are stuck with the naive world of single uniform address spaces throughout the world or protocols that require all connections from the client to the server, and not from server to client, and no connectionless protocols. [Peterson, Jon] Everyone who wants to understand the motivation for S/MIME should be reading the MIDCOM charter. I disagree that we're approaching this from a 'naive' perspective - it is partially because we are mindful of transparent intermediaries which alter SIP bodies that we think S/MIME is necessary. Now, this isn't to say that the vendors who build these boxes or the carriers who deploy them are misguided - making address spaces commensurate, etc., is a laudable goal. But just as carriers have a prerogative to insert these devices, I believe users should be able to controlwhether or not intermediaries can alter the bodies of their requests. There are cases where I would like to see a request fail because a middlebox is unable to modify it - that way I'll at least know that it's there. Middleboxes make the same changes in signaling whether they're helping you through a NAT or simulcasting your call over satellite radio. The important thing is that this is not an abstract concern - there are boxes out there today that can and will modify SIP message bodies without the knowledge of either of the endpoints in a call. ------_=_NextPart_001_01C1B65C.C60CD220 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] 'sips' URI scheme (comments on proposal?)
A brief note below, a bit on the need for S/MIME.
 
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com]
Sent: Friday, February 15, 2002 2:48 AM
To: 'sip@ietf.org'
Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?)

> I believe there are reasonable threats against SIP (at  least one of which is
> described in bis) that justify end-to-end confidentiality f bodies. I'm not
> sure that I want intermediaries to be able to inspect or potentially modify
> SIP bodies, especially SDP, for a number of reasons. I think we need a base
> SIP mechanism to address this concern.

If you want your protocol to be capable of traversing multiple heterogeneous networks then you must pass the network control information in such a way that the routing devices can modify it as necessary. If you don't like this then you are stuck with the naive world of single uniform address spaces throughout the world or protocols that require all connections from the client to the server, and not from server to client, and no connectionless protocols.
[Peterson, Jon] 

Everyone who wants to understand the motivation for S/MIME should be reading the MIDCOM charter. I disagree that we're approaching this from a 'naive' perspective - it is partially because we are mindful of transparent intermediaries which alter SIP bodies that we think S/MIME is necessary.

Now, this isn't to say that the vendors who build these boxes or the carriers who deploy them are misguided - making address spaces commensurate, etc., is a laudable goal. But just as carriers have a prerogative to insert these devices, I believe users should be able to controlwhether or not intermediaries can alter the bodies of their requests. There are cases where I would like to see a request fail because a middlebox is unable to modify it - that way I'll at least know that it's there. Middleboxes make the same changes in signaling whether they're helping you through a NAT or simulcasting your call over satellite radio.

The important thing is that this is not an abstract concern - there are boxes out there today that can and will modify SIP message bodies without the knowledge of either of the endpoints in a call.

------_=_NextPart_001_01C1B65C.C60CD220-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 15:43:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18919 for ; Fri, 15 Feb 2002 15:43:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16445 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 15:43:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14526; Fri, 15 Feb 2002 15:06:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14495 for ; Fri, 15 Feb 2002 15:06:39 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18078 for ; Fri, 15 Feb 2002 15:06:36 -0500 (EST) Received: from dwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1FK66B11661; Fri, 15 Feb 2002 14:06:06 -0600 Message-ID: <011b01c1b65c$5b579f00$b3036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: Cc: , , Date: Fri, 15 Feb 2002 14:07:11 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0118_01C1B62A.1036E800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0118_01C1B62A.1036E800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The document draft-willis-sip-path-01.txt introduces the Path extension = header suggested by 3GPP in the Garcia 3GPP requirements draft in = SIPPING.=20 The basic requirements being met are to 1) allow a UA to REGISTER a = contact which requires traversing a sequence of proxies on future = messages between the registrar and the UA, with that sequence = dynamically discovered during the REGISTER, and 2) allow a UA to = discover from a REGISTER response a sequence of proxies between it and a = known proxy offering outbound services for that UA. The approach taken in the draft generalizes the 3GPP requirements by = allowing the sequences to be asymetric-- for example, the inbound and = outbound sequences might traverse different proxies, or there might only = be a sequence in one direction (A firewall proxy sits between UA and its = registrar, but UA does not use the registrar for outbound services). I'd like to poll for three things: 1) Do we want to address the requirements raised by 3GPP? 2) Do we have a general consensus on something like the PATH header as = an appopriate mechanism? 3) Is draft-willis-sip-path-01.txt a reasonable baseline document? If we have consensus on all three accounts, I propose to accept = draft-willis-sip-path-01.txt as a working group document, and pursue = future revisions as draft-ietf-sip.xx. If not, then please make a counterproposal. Opinions, please. -- Dean ------=_NextPart_000_0118_01C1B62A.1036E800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The document = draft-willis-sip-path-01.txt=20 introduces the Path extension header suggested by 3GPP in the Garcia = 3GPP=20 requirements draft in SIPPING.
 
The basic requirements being met are to = 1) allow a=20 UA to REGISTER a contact which requires traversing a sequence of proxies = on=20 future messages between the registrar and the UA, with that sequence = dynamically=20 discovered during the REGISTER, and 2) allow a UA to discover from a = REGISTER=20 response a sequence of proxies between it and a known proxy offering = outbound=20 services for that UA.
 
 
The approach taken in the draft = generalizes the=20 3GPP requirements by allowing the sequences to be asymetric-- for = example,=20 the inbound and outbound sequences might traverse different proxies, or = there=20 might only be a sequence in one direction (A firewall proxy sits between = UA and=20 its registrar, but UA does not use the registrar for outbound=20 services).
 
I'd like to poll for three = things:
 
1) Do we want to address the = requirements raised by=20 3GPP?
 
2) Do we have a general consensus on = something like=20 the PATH header as an appopriate mechanism?
 
3) Is draft-willis-sip-path-01.txt a = reasonable=20 baseline document?
 
If we have consensus on all three = accounts, I=20 propose to accept draft-willis-sip-path-01.txt as a working group = document, and=20 pursue future revisions as draft-ietf-sip.xx.
 
If not, then please make a=20 counterproposal.
 
Opinions, please.
 
--
Dean
------=_NextPart_000_0118_01C1B62A.1036E800-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 15:58:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19336 for ; Fri, 15 Feb 2002 15:58:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16860 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 15:58:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16255; Fri, 15 Feb 2002 15:37:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16229 for ; Fri, 15 Feb 2002 15:37:28 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18831 for ; Fri, 15 Feb 2002 15:37:25 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1FKavb23952 for ; Fri, 15 Feb 2002 14:36:57 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4HF9>; Fri, 15 Feb 2002 14:36:52 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF40@VA02> From: "Peterson, Jon" To: "'sip@ietf.org'" Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?) Date: Fri, 15 Feb 2002 14:36:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Some of the things that we can carry in SIP as MIME types that require confidentiality are: - Telephony signals (RFC 3204) - Instant Messages (in MESSAGE) - Whatever you place within INFO messages - DTMF, etc I don't believe that any of the current proposals for Digest include confidentiality. But leaving aside confidentiality for a moment, I want to be clear that the current state of Digest enhancements, like S/MIME, is also one in which there are uncertainties. Mutual authentication has some known challenges (especially in the backwards e2m cases). Some of the header integrity thinking (hBh vs e2e) has issues. How to handle keying is still up in the area - several alternatives to the shared-secret approach have been suggested, including extensible mechanisms. Some readers of bis have suggested that we abandon Digest in HTTP Auth altogether for Digest in SASL (opening the door to general SASL support in SIP). Whatever else you might say about S/MIME, we have suggested a mechanism for its usage, and no serious arguments have been raised along the lines of "if you're going to do S/MIME, you should do it this way instead". The authors would appreciate comments along those lines. Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 16:04:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19512 for ; Fri, 15 Feb 2002 16:04:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17600 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 16:04:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16572; Fri, 15 Feb 2002 15:46:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16541 for ; Fri, 15 Feb 2002 15:46:46 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18950 for ; Fri, 15 Feb 2002 15:46:45 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1FKkx6Y003853; Fri, 15 Feb 2002 15:47:00 -0500 (EST) Message-ID: <3C6D7392.B85C3409@dynamicsoft.com> Date: Fri, 15 Feb 2002 15:46:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sanjoy Sen CC: sip@ietf.org Subject: Re: [Sip] Clarification on overlapping transaction in bis07 References: <933FADF5E673D411B8A30002A5608A0E011878FA@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sanjoy Sen wrote: > > lines 1857-1860: A TU MUST NOT initiate a new regular transaction within > a dialog > while a regular transaction is in progress (in either direction) > within that dialog. If there is a non-INVITE client or server > transaction in progress the TU MUST wait until this transaction > enters the completed or the terminated state to initiate the new > transaction. > > What is the difference between these two sentences ? The second one helps clarify what "in progress" means. However, the whole thing is out of date, since we did decide, based on #113, to allow overlapping non-invite. We have already corrected this error. Thanks, -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 15 16:07:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19613 for ; Fri, 15 Feb 2002 16:07:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17768 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 16:07:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15284; Fri, 15 Feb 2002 15:20:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15259 for ; Fri, 15 Feb 2002 15:20:49 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18448 for ; Fri, 15 Feb 2002 15:20:46 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id PAA26917; Fri, 15 Feb 2002 15:19:26 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256B61.006FA2F4 ; Fri, 15 Feb 2002 15:19:22 -0500 X-Lotus-FromDomain: MITEL To: Michael Thomas cc: sip@ietf.org Message-ID: <85256B61.006FA142.00@kanmta01.software.mitel.com> Date: Fri, 15 Feb 2002 15:19:17 -0500 Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org From: Tom Gray@MITEL on 02/15/2002 03:19 PM The PSTN did indeed take the problem of signalling fraud very seriously and aimed very high to correct it. The PSTN was extremely vulnerable to fraud when it used in-band signalling in which customer and network signalling were intermingled. The PSTN rectified this by going to an out-of-band signalling structure with SS6 and SS7. One of the Internet's greatest assets is that it allows in-band signalling which allows end users to create their own applications This opens it to the type of fraud that were perpetrated on the PSTN before the deployment of out-of-band signalling systems. The classic blue box fraud was an example of a customer sending the equivalent of an false BYE message. Michael Thomas on 02/15/2002 03:00:41 PM To: Jonathan Rosenberg cc: sip@ietf.org (bcc: Tom Gray/Kan/Mitel) Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) Jonathan Rosenberg writes: > > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Friday, February 15, 2002 11:48 AM > > To: EKR > > Cc: Michael Thomas; Peterson, Jon; 'Jari Arkko'; Juha Heinanen; Jonathan > > Rosenberg; Lawrence Conroy; Henry Sinnreich; sip@ietf.org > > Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) > > > > Eric Rescorla writes: > > > Michael Thomas writes: > > > > You seem into falling into a false dichotomy that > > > > if SMIME doesn't go into bis, we are now and > > > > forever resigned to inadequate security for > > > > SIP. > > > I don't think it's a false dichotomy. Rather, it's a pretty > > > accurate statement of the common pattern. To whit: WG produces > > > a document with horrible security problems. Says, "we'll fix > > > security later". Document passes. WG doesn't fix security. > > > > Are you actually claiming that SIP without SMIME > > would be "a document with horrible security > > problems"? I sure hope not, because if you are I > > think you need to get a grip; the current PSTN > > does exactly this today, and the world has not > > come to an end. > > The Internet is not the PSTN, of course. Yes, the Internet has conspicuously less security than the PSTN and yet it too still seems to function without news at 11:00. One thing we've learned, however, is that a sure way to keep the appalling status quo is to aim too high. Given where SIP is likely to be deployed, this is not only high, but aimed perpendicular to the earth's surface. > My perspective is that S/MIME provides one really, really > important security function. We have a monster hole right now, "Monster" is in the eye of the beholder. > IMHO, in that an eavesdropper can listen in on an INVITE, > and send fake BYE/re-INVITE or whatever to launch all kinds > of attacks. Still exists with SMIME. > An e2e TLS/IPSec solution is not sufficient, since > it is too fragile - there will always be hops without security. Fragile? > True e2e authentication is unachievable without PKI. False, false, false. First of all, e2e authentication in the small/medium/large is clearly achievable without PKI. Authentication in the large for complex cross domain relationships is now and remains a fantasy. It is pure speculation whether PKI's will deliver. Indeed, the mobile IP working group has been floundering for well over a year precisely because they improperly started from the false premise of global PKI's and the previous solution needed to be scraped once that was pointed out as a bogus premise. And *please* don't trot out the terrible web example again. You're talking about large PKI's in *clients*. > The solution > is a self-signed cert approach, where effectively only the user > that send the initial INVITE can ever send subsequent signaling. > I think that this is terribly important, and without a sensible > solution for it, the SIP security story for bis is not good > enough. PKI != self-signed certs. If you want a leap of faith solution, SMIME is an impediment, not a help. > Sure, we could have invented our own thing instead of S/MIME to > do this, but we would have gotten it wrong, it wouldn't be useful > for other things, as S/MIME is, and so on. S/MIME therefore seems > a good engineering choice to solve an important problem. I happen to think that scalable/flexible proxy authentication is a lot more pressing problem. I don't think I'm alone. I've yet to hear anybody who is clamoring for the e2e problem. Yet, we get e2e SMIME with no list discussion either about the prioritization, or the solution. What gives? > Lastly, Mike, I hope you seriously do not believe that the editors > are acting inappropriately in our efforts to move forward with the > spec. We are doing everything we can do move with speed and within the > confines of the process. Getting consensus in this group is not trivial. I think that this got put in at the last minute without any working group involvement, especially by the people who have expressed interest in the problem. I've seen no inclination to address any of the concerns brought up, or consider alternatives. Why exactly am I supposed to not feel like this isn't being rammed down our throats? 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 daemon@optimus.ietf.org Fri Feb 15 16:20:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19908 for ; Fri, 15 Feb 2002 16:20:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA18300 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 16:20:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17551; Fri, 15 Feb 2002 16:02:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17444 for ; Fri, 15 Feb 2002 16:02:38 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19471 for ; Fri, 15 Feb 2002 16:02:36 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1FL2c6Y003878; Fri, 15 Feb 2002 16:02:40 -0500 (EST) Message-ID: <3C6D773C.8DDD3E9A@dynamicsoft.com> Date: Fri, 15 Feb 2002 16:01:48 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? References: <011b01c1b65c$5b579f00$b3036e3f@dfw.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > > I'd like to poll for three things: > > 1) Do we want to address the requirements raised by 3GPP? Yes. I think we need this for other scnearios, the infamous "hotel" case which has a similar architecture to the 3gpp configuration. > > 2) Do we have a general consensus on something like the PATH header as > an appopriate mechanism? Yes. Now that the loose route stuff in bis has been sorted out, the path header feeds nicely into it, as a way to learn a route set to reach a resource. > > 3) Is draft-willis-sip-path-01.txt a reasonable baseline document? Sure. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 15 16:36:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20343 for ; Fri, 15 Feb 2002 16:36:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19613 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 16:36:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17930; Fri, 15 Feb 2002 16:11:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17901 for ; Fri, 15 Feb 2002 16:11:09 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19713 for ; Fri, 15 Feb 2002 16:11:07 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1FLBK6Y003896; Fri, 15 Feb 2002 16:11:25 -0500 (EST) Message-ID: <3C6D7947.5775D8B9@dynamicsoft.com> Date: Fri, 15 Feb 2002 16:10:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brazier Lachlan CC: "'sip@ietf.org'" Subject: Re: [Sip] CSeq question? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Brazier Lachlan wrote: > > Hello, > > probably awnsered long ago, but I couldn't find it :-( > > The reason I ask is, that it wasn't clear to me, if the increasing of > the > CSeq value in a dialog is bound to a request class (INVITE, BYE, > MYREQUEST, > etc.) or to requests in general. All requests sent from A to B within a dialog, independent of the method, have increasing CSeq, by value of 1, with two exceptions: 1. ACK for an INVITE has the same cseq as the invite 2. cancel for a request has the same cseq as request So: INVITE (cseq: 1) ----> 200 (1)<-------- ACK (1)---------> INFO (2)---------> 200 OK (2)<------- BYE (3) ---------> 200 OK (3)<------ Can you point me to text in bis that would lead you to believe it was per method? I think the text is pretty clear: From 12.2.1.1: The Call-ID of the request MUST be set to the Call-ID of the dialog. Requests within a dialog MUST 1872 contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in 1873 each direction. Therefore, if the local sequence number is not empty, the value of the local sequence number 1874 MUST be incremented by one, and this value MUST placed into the Cseq header. If the local sequence 1875 number is empty, an initial value MUST be chosen using the guidelines of Section 8.1.1.5. The method field 1876 in the Cseq header MUST match the method of the request. 1877 -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 15 16:46:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20675 for ; Fri, 15 Feb 2002 16:46:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20031 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 16:46:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18401; Fri, 15 Feb 2002 16:22:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18373 for ; Fri, 15 Feb 2002 16:22:47 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19985 for ; Fri, 15 Feb 2002 16:22:45 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1FLEu6Y003900; Fri, 15 Feb 2002 16:14:59 -0500 (EST) Message-ID: <3C6D7A1F.CEFF04CC@dynamicsoft.com> Date: Fri, 15 Feb 2002 16:14:07 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Undery CC: Robert Sparks , sip@ietf.org Subject: Re: [Sip] note: change in URI comparison rules coming References: <45730E094814E44488F789C1CDED27AEC552A1@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit James Undery wrote: > > Good. > > Well while we're at it can I suggest we remove all default values from > SIP URIs. Whoa there partner. We didn't remove defaults for either port or transport; we merely said that an explicit value does not equal the default. We still need a default unless you want to force everyone to include them explicitly in each request. My reasoning would be, port and transport seemed the least > arbitrary. The user parameter has consistently been abused; the method > parameter defaulting to INVITE doesn't seem so convincing in these > SIMPLEr times; ttl does this really justify a default parameter, if you > insist on using multicast you should do it properly with some thought. > > This also results in a far simpler comparison rule, that's easy to grasp > and apply. Sorry - are you arguing for removal of defaults, or that the default should never equal the explicit value? That is: sip:user@224.3.2.2;ttl=1 sip:user@224.3.2.2 would not be equal? I could be convinced to go full court on this one.... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Fri Feb 15 16:58:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21008 for ; Fri, 15 Feb 2002 16:58:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20586 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 16:58:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18256; Fri, 15 Feb 2002 16:19:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18224 for ; Fri, 15 Feb 2002 16:19:42 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19889 for ; Fri, 15 Feb 2002 16:19:41 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1FLJCb26134; Fri, 15 Feb 2002 15:19:12 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4HX4>; Fri, 15 Feb 2002 15:19:07 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF42@VA02> From: "Peterson, Jon" To: "'Ofir Arkin'" , sip@ietf.org Subject: RE: [Sip] Review of section 22 "Security Considerations" of draft -ietf-sip-rfc2543bis-07 Date: Fri, 15 Feb 2002 15:19:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks very much, Ofir, for these considerations of the security of the SIP protocol. Communities tend to develop somewhat insular thinking about security, and it's definitely nice to have a fresh perspective. We probably won't have time to really digest this until after bis08 has come out, but I'll write some detail responses to your comments next week. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Ofir Arkin [mailto:ofir@stake.com] > Sent: Friday, February 15, 2002 11:17 AM > To: sip@ietf.org > Subject: [Sip] Review of section 22 "Security Considerations" of > draft-ietf-sip-rfc2543bis-07 > > > Hello, > > Linked to this Email is a .pdf file which is a draft document > reviewing > "Section 22: Security Considerations" of draft-ietf-sip-rfc2543bis-07. > > [http://www.sys-security.com/archive/research/draft-ietf-sip-r fc2543bis-07_Review_of_section_22.pdf] Please note that this document is provided as is, and still needs to be enhanced and revised. The thoughts expressed within the document are my initial thoughts about some of the subjects mentioned in Section 22. I will be more than happy to receive feedback, corrections and suggestions from the list members. Cheers -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Fri Feb 15 17:04:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21182 for ; Fri, 15 Feb 2002 17:04:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21464 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 17:04:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20077; Fri, 15 Feb 2002 16:46:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20046 for ; Fri, 15 Feb 2002 16:46:20 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20689 for ; Fri, 15 Feb 2002 16:46:18 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1FLhhoN011269; Fri, 15 Feb 2002 16:43:43 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 16:45:44 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F363005E@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Bob Penfield'" , sip@ietf.org Subject: RE: [Sip] comments on draft-ietf-sip-events-02.txt Date: Fri, 15 Feb 2002 16:45:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > The part that might get confused by implementers is when the > NOTIFY arrives > first, and the 2xx that arrives later does not come from the > notifier that > sent the NOTIFY. In this case, the 2xx's dialog-id (as > defined in bis) will > not match the dialog-id established by the NOTIFY. This 2xx > response DOES > NOT establish a new dialog and the subscriber MUST NOT use > the record-route > & contact from the 2xx as the route-set for the existing > dialog since they > point at the wrong notifier. > > Have I got that right? Actually, as I went to edit the document, I realized that this isn't correct for all cases. What you state above is true in the case that only one dialog is allowed to be established. Event packages may allow a single SUBSCRIBE message to establish several dialogs -- in which case, this 200 may very well establish a new dialog. I'll put clarification on this topic in the section which describes the two options from which event packages should select. /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 daemon@optimus.ietf.org Fri Feb 15 21:22:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25018 for ; Fri, 15 Feb 2002 21:22:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA01136 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 21:22:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00146; Fri, 15 Feb 2002 20:56:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00115 for ; Fri, 15 Feb 2002 20:56:17 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24749 for ; Fri, 15 Feb 2002 20:56:15 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1G1rjoN012784; Fri, 15 Feb 2002 20:53:45 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 20:55:46 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630063@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Schulz, Eric'" , Adam Roach Cc: sip@ietf.org Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! Date: Fri, 15 Feb 2002 20:55:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks. Can you tell I've done some of my editing late at night? :) /a > -----Original Message----- > From: Schulz, Eric [mailto:eschulz@cisco.com] > Sent: Friday, February 15, 2002 7:53 PM > To: adam@dynamicsoft.com > Cc: sip@ietf.org > Subject: [Sip] Reminder: SIP Events WGLC Ending Soon! > > > Not exactly the thorough review you requested but I did > notice the following... > > - In the 7th paragraph of section 4.3.4, "Expiration" > should be "Expires" > - In the 4th paragraph of section 4.3.6, "Expire" should > be "Expires" > > -Eric > > From: Adam Roach > > The Working Group Last Call for the SIP Events draft is > ending on Tuesday. So far, only two people have commented > on it (thanks, Bob and Bert). > > I urge anyone with a stake in this mechanism to give the > document a thorough review over the weekend, and post > comments on Monday. I'll be kicking out a new version on > Tuesday, which will immediately enter IETF Last Call. > > The latest version of the document is available at: > and in a PDF-version (with changebars) at: /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 daemon@optimus.ietf.org Fri Feb 15 21:23:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25043 for ; Fri, 15 Feb 2002 21:23:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA01172 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 21:23:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00037; Fri, 15 Feb 2002 20:53:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00006 for ; Fri, 15 Feb 2002 20:53:20 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24690 for ; Fri, 15 Feb 2002 20:53:18 -0500 (EST) Received: from e2k-sea-xch1.ecsbu-lab-sea.cisco.com (e2k-sea-xch1.cisco.com [10.93.248.22]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1G1qgE15033; Fri, 15 Feb 2002 17:52:43 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Reminder: SIP Events WGLC Ending Soon! X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 15 Feb 2002 17:52:42 -0800 Message-ID: <4D1E846548771F4AA7FAE28F4B358DB5D874FC@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> Thread-Topic: [Sip] Reminder: SIP Events WGLC Ending Soon! Thread-Index: AcG2jOoETYf+aG+5ScWA+YRGXQzK5w== From: "Schulz, Eric" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA00007 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Not exactly the thorough review you requested but I did notice the following... - In the 7th paragraph of section 4.3.4, "Expiration" should be "Expires" - In the 4th paragraph of section 4.3.6, "Expire" should be "Expires" -Eric From: Adam Roach The Working Group Last Call for the SIP Events draft is ending on Tuesday. So far, only two people have commented on it (thanks, Bob and Bert). I urge anyone with a stake in this mechanism to give the document a thorough review over the weekend, and post comments on Monday. I'll be kicking out a new version on Tuesday, which will immediately enter IETF Last Call. The latest version of the document is available at: and in a PDF-version (with changebars) at: /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 daemon@optimus.ietf.org Fri Feb 15 21:45:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26297 for ; Fri, 15 Feb 2002 21:45:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA02014 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 21:45:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA01258; Fri, 15 Feb 2002 21:27:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA01229 for ; Fri, 15 Feb 2002 21:27:50 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25090 for ; Fri, 15 Feb 2002 21:27:47 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id CAA09075 for ; Sat, 16 Feb 2002 02:31:21 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id CAA23545 for ; Sat, 16 Feb 2002 02:27:43 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <1J3XH7ST>; Fri, 15 Feb 2002 19:27:42 -0700 Message-ID: <17052388D394D411803900508BDFFAF6041376B3@n0214idc1.oss.level3.com> To: sip@ietf.org Date: Fri, 15 Feb 2002 19:27:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] A few more bis-07 nits Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Continued from last list I sent... 41. The sentence in 3222-3223 is saying the same thing as the sentence in 3225-3226. Seggest the first be deleted (the latter includes explanatory text following it). 42. Lines 3230-3231, "that that" should be "that". 43. Lines 3290-3291 states "As with client transactions, this is needed to ensure reliability of the 2xx responses to INVITE." But this section is discussing non-INVITE Client Transaction. 44. Line 3301-3302 states "A response which matches a transaction matched by a previous response is considered a retransmission of that response." This would seem to be false when considering provisionals then a final response received. 45. Section 17.2.1 Figure 7 title is too low, overwriting the page footer. Same for figure 8 under section 17.2.2. Reported for bis-06, bug opened. 46. Figure 8 in the txt version has it's title wrapped to the first line of the next page. John Hearty Level3 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 15 23:11:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28594 for ; Fri, 15 Feb 2002 23:11:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA05413 for sip-archive@odin.ietf.org; Fri, 15 Feb 2002 23:11:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04092; Fri, 15 Feb 2002 22:39:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04039 for ; Fri, 15 Feb 2002 22:39:11 -0500 (EST) Received: from lycos.com ([211.220.51.242]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27941 for ; Fri, 15 Feb 2002 22:39:00 -0500 (EST) Message-Id: <200202160339.WAA27941@ietf.org> Reply-To: kjoi_dj33@lycos.com From: 마케터 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 16 Feb 2002 12:38:49 +0900 X-User: 2.63-figjdliv-lilkhn-Ddigq Subject: [Sip] [광고]새로운 사업이나 부업을 찾으십니까? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org

▶ 허락없이 홍보메일을 보내게 된 점 사과드립니다.
▶ 정보통신망이용촉진법규정을 준수하여 광고메일임을 표시하였읍니다.
▶ 전자우편주소는 인터넷상에서 취득하였으며, 전자우편주소외 어떠한 개인 정보도 가지고 있지 않습니다


!!!! 지금 이순간 님께서 저희 다이너스티를 만나신 것은 대단한 행운이라 확신합니다. !!!!

 

반갑습니다.
저는 부산에서 직장을 다니면서 부업으로 이 사업을 진행하고 있는 장강민이란 사람입니다.
적극적이고 열정적으로 살면서 자기 발전을 위해 끊임없이 노력하고 있습니다.

사업은 물론 만나서 대화를 나누어야 가장 좋겠지만, 우선 서면으로 대략을 알려드리니 살 펴보시고 계속 관심이 있으시면 연락주시기 바랍니다....

 

사업의 개념이 이해하기쉽고, 네트웤을 형성하는 방법이 on-line, off-line 으로 다양하고, 듣는 사람도 너무나 쉽게 납득할 수 있기 때문에 누구나 하실 수가 있습니다.

특히 기존에 어떤 형식이든 네트웤 마케팅을 하고 계시는 분들이면 더욱 잘 하실 수
있습니다.

 

이 사업은 통신 사업 중 가장먼저 시작된 새로운 사업으로서 다이너스티 라는 회사로 별정통신1호와 2호의 회사입니다.

자본 없이도 자기사업을 하는것과 같으며 시간이 흐름에 따라 점차 그 규모가 커져 1년 후 회원 수와 매출액면에서 비교가 안 될 정도로 확장되는 굉장히 비젼이 있는 사업입니다.

 

아마도 주변에서 아는분들이 다단계 사업을 하시면서 같이 사업해 보지 않겠냐는 제안 한 두 번쯤 안 들어보신 분들 거의없으리라 생각됩니다.

그렇지만 다단계가 뭡니까. 기존 시장의 유통구조를 바꾸어 즉 중간유통단계(총판, 대리점) 또는 광고없이 구전에 의한판매로 중간단계에서 발생되는 지출을 줄여 그수익을 소비자에게 환원시켜주는 선진형 판매방식입니다.

네트웍 사업은 회원들의 재구매가 빠른 제품으로 구성되어야 한다는것은 잘아시겠죠?

우리가 하루도 전화를 걸지 않고는 살아갈 수 없다는 것을 님께서도 인정하십니까?
바로 이 전화요금을 현재 기간통신에 후불로 납부하는것을 선불로 카드에 충전해서 쓰는것이 사업입니다.

 

2000년도 국내 소비시장중 통신시장규모는 자그만치 약24조원이었으며 2001년도는 아직 통계가 나오지 않아 잘모르지만 훨씬 늘어났으며 참고로 말씀드린다면 쌀소비시장은 약 1조원, 자동차시장-약6조, 유류(석유)시장-약6조원이었습니다.
통신시장 규모가 얼마나 큰시장인지 짐작이 가시겠죠?

이 거대통신시장이 이대로 개방된다면우리나라 신경인 통신은 그대로 외국유수업체에 잠식 당할 수 밖에 없습니다.

그래서 정부에서 별정통신을 허용하여 개인전화국(1호사업자)으로 하여금 개방이전에 국제경쟁력을 갖추기 위한 국책사업입니다.

통합선불카드 하나로 시내.외,공중전화 통화는 물론 휴대폰 기종,번호변경없이 011부터 019까지 축기능으로 많은 버튼을 누르지 않고 온가족이 함께 간편하게 사용하실수 있습니다.


물론 상기내용은 아주 기본적인 내용이구요.
자기밑으로 2명만 둘수 있는 바이너리 구조입니다

이외에도 부가산업도 뿐만아니라  수익구조,전자상거래등등 하고싶은 이야기는 많으나 이정도로 설명을 해드리구요 더궁굼하신것들은 직접 상담을 하시거나 회사의 홈페이지를 둘러보시면 되겠읍니다.

 

http://www.dynastytel.co.kr(별정통신)
http://www.clubaqua.co.kr(여행사)
http://www.visiondynasty.com(전자상거래)
http://www.e-dynasty.co.kr(홈페이지)
연락처 : codejang@intizen.com
H.P    : 019-596-9808
수신거부 : e-dynasty@simmani.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 daemon@optimus.ietf.org Sat Feb 16 01:57:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00365 for ; Sat, 16 Feb 2002 01:57:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA19814 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 01:57:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18884; Sat, 16 Feb 2002 01:26:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18850 for ; Sat, 16 Feb 2002 01:26:53 -0500 (EST) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00184 for ; Sat, 16 Feb 2002 01:26:51 -0500 (EST) Received: from there (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.11.6/8.11.6) with SMTP id g1G6QDg32544; Sat, 16 Feb 2002 00:26:14 -0600 Message-Id: <200202160626.g1G6QDg32544@kevlar.softarmor.com> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: sip@ietf.org Date: Sat, 16 Feb 2002 00:26:12 -0600 X-Mailer: KMail [version 1.3.2] Cc: brian.rosen@marconi.com, jo@ipdialog.com, mankin@isi.edu, sob@harvard.edu MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] Change of Editor for draft-ietf-sip-manyfolks-resource Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit My apologies if you receive two of these. I clearly remember sending it earlier in the day, but it never seemed to show up in my inbox. --------------------- RFC 2418 defines the role of document editor as follows: 6.3. Document Editor Most IETF working groups focus their efforts on a document, or set of documents, that capture the results of the group's work. A working group generally designates a person or persons to serve as the Editor for a particular document. The Document Editor is responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the working group. As a general practice, the Working Group Chair and Document Editor positions are filled by different individuals to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed. The document draft-ietf-sip-manyfolks-resource was adopted by the SIP Working Group of the IETF as an official group effort following a request by the original editors that it be so adopted, and has been revised several times (currently version-03) under the change control policy of the SIP Working Group. The Chairs of the SIP Working Group and Directors of the Transport Area haved determined that the time pressure is too great for the document to be completed (given recent consensus on changes) in time under the present editorship. Therefore we are changing the editorship immediately, starting from the current (-03) text of draft-ietf-sip-manyfolks-resource. Gonzalo Camarillo has volunteered to serve as lead editor for further work on this document, and is asked to do so immediately and until further notice. The chairs wish to thank the previous editorial team, led by Bill Marshall, for their contributions in developing this document. Bill's name will remain in the authorship list. -- The Chairs Brian Rosen, Joerg Ott, Dean Willis The ADs Allison Mankin, Scott Bradner _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 16 02:30:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08465 for ; Sat, 16 Feb 2002 02:30:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA21224 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 02:30:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20358; Sat, 16 Feb 2002 02:05:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20329 for ; Sat, 16 Feb 2002 02:05:00 -0500 (EST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06955 for ; Sat, 16 Feb 2002 02:04:57 -0500 (EST) Received: from jariws1 ([62.248.149.81]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020216070459.GRNI21965.fep02-app.kolumbus.fi@jariws1>; Sat, 16 Feb 2002 09:04:59 +0200 Message-ID: <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Michael Thomas" , "EKR" Cc: "Michael Thomas" , "Peterson, Jon" , "Juha Heinanen" , "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , References: <70565611B164D511957A001083FCDD56CAAF3D@VA02><15469.10196.338294.88758@thomasm-u1.cisco.com><15469.12740.716729.637034@thomasm-u1.cisco.com><15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) Date: Sat, 16 Feb 2002 09:05:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mike wrote in an answer to Eric: > > Michael, one of the things that draft authors do is put text into > > drafts so that it can be debated by the WG. As for the changes > > being of dubious utility, I know it's hard for you to believe, > > but people might have different opinions from you about utility. > > Fine. Let's have a consensus call. Well, I counted myself, Juha, Sanjoy, and Mike already supporting my ealier priority list which concluded that S/MIME is not the highest priority. At least Jonathan, Eric, and Jon have the opposite view so at present the no-S/MIME group is slightly larger but we really don't have any consensus. But I have a compromise suggestion. Why don't we keep the S/MIME stuff in Bis but make it a MAY, and then move on to continue to the discussion about relative priorities of Digest, Enhanced Digest, TLS, and IPsec? Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 16 03:38:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09173 for ; Sat, 16 Feb 2002 03:38:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA24194 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 03:38:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22872; Sat, 16 Feb 2002 03:05:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22842 for ; Sat, 16 Feb 2002 03:05:01 -0500 (EST) Received: from localhost ([211.50.255.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08773 for ; Sat, 16 Feb 2002 03:04:57 -0500 (EST) Message-Id: <200202160804.DAA08773@ietf.org> Reply-To: pricelist@hutmail.com From: 컴정보 To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 16 Feb 2002 17:04:58 +0900 Subject: [Sip] {광 고} 컴퓨터가격정보 메일링 회원이 되세요 (^-^)~ Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 컴퓨터 가격정보 메일링 신청 받습니다.

먼저 허락없이 글을 올린것에 대해 진심으로 사과말씀 드립니다.
귀하의 이메일 주소는 인터넷 게시판을 통하여 취합하였습니다

컴퓨터 가격정보를
매일 매일 회원님의 이메일로 발송해 드리는 서비스입니다.
항상 최신의 가격정보가 회원님의 이메일속에 담겨져 있게 해드리겠습니다.

현재 일간(화,목,토요일 발행) 및 주간(목요일 발행) 형태로 발행중입니다.
일요일 및 공휴일은 발행을 하지 않습니다.

물론 본 서비스는 무료입니다.

구독신청은 메일주소만 써주시면 끝입니다.. 간단하죠..^^

컴퓨터 가격정보 [일간]



컴퓨터 가격정보 [주간]


한메일 사용자용 [일간]
  컴퓨터가격정보

한메일 사용자용 [주간]
  컴퓨터가격정보

지난메일링보기 ★

본 메일로 기분 상하셨다면 깊이사과 드립니다.!
수신거부 해주시면 반복발송하지 않도록 하겠습니다.
본메일은 1회성 메일입니다.

수신거부 <== 수신거부는 꼭 요기를 눌러주세요.. 감사합니다.

 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 16 05:07:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09927 for ; Sat, 16 Feb 2002 05:07:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA27142 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 05:07:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26078; Sat, 16 Feb 2002 04:33:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25973 for ; Sat, 16 Feb 2002 04:33:34 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09669 for ; Sat, 16 Feb 2002 04:33:31 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1G9X1b09314; Sat, 16 Feb 2002 03:33:02 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4KYZ>; Sat, 16 Feb 2002 03:32:56 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF4E@VA02> From: "Peterson, Jon" To: "'Jari Arkko'" Cc: sip@ietf.org Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?) Date: Sat, 16 Feb 2002 03:32:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org From an earlier mail by Jari: My call here could be to have a MUST for enhanced digest and a SHOULD for TLS, MAY for IPsec and SMIME, leaving SIP with a scheme that can cover both h2h/e2m/e2e protection and UDP/SCTP/TCP, and room for the different groups to do their favorite thing in addition. We have a MUST for Digest; I'm not sure what exactly 'enhanced Digest' here means. There have been a number of proposals for Digest enhancement, as well as a number for Digest replacement (I would group EAP and Digest-as-SASL in this category). Is there a particular draft that is the winner? Given that this matter seems somewhat contentious, I'm not sure this is necessarily a more expedient route than developing the mechanisms currently in the specification. Anyway, we do explicitly mention in the spec that there is work towards the enhancement of Digest underway that may increase the applicability of Digest to the threats facing SIP. On MAY vs. SHOULD for S/MIME, this is undeniably a contentious point. Note that we have paired the RECOMMENDED functionality down a bit, in so far as the support for S/MIME is broken into a MUST for support for signed-data and certs-only smime-types, but a MAY for the enveloped-data smime-type. Although this hasn't received a great deal of attention on this list, I believe this does represent a reduction in the amount that the SHOULD for S/MIME really recommends that one implement. Certainly, no one is saying that S/MIME is the highest priority, but there are genuine threats that it addresses. Overall, we have tried in bis to separate the normative strengths for supporting particular security components from functional description of the components themselves; today section 22.3.1 is home to the list of the protocol requirements. In the course of IETF last call these variables may be modified as the IESG sees fit. I think that they, ultimately, will be the arbiters of how these normative strengths shake out. We've probably tuned this about as much as we can in the SIP WG. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Friday, February 15, 2002 11:05 PM > To: Michael Thomas; EKR > Cc: Michael Thomas; Peterson, Jon; Juha Heinanen; Jonathan Rosenberg; > Lawrence Conroy; Henry Sinnreich; sip@ietf.org > Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) > > > > Mike wrote in an answer to Eric: > > > > Michael, one of the things that draft authors do is put text into > > > drafts so that it can be debated by the WG. As for the changes > > > being of dubious utility, I know it's hard for you to believe, > > > but people might have different opinions from you about utility. > > > > Fine. Let's have a consensus call. > > Well, I counted myself, Juha, Sanjoy, and Mike already supporting > my ealier priority list which concluded that S/MIME is not the highest > priority. At least Jonathan, Eric, and Jon have the opposite view so > at present the no-S/MIME group is slightly larger but we really don't > have any consensus. > > But I have a compromise suggestion. Why don't we keep the S/MIME > stuff in Bis but make it a MAY, and then move on to continue to the > discussion about relative priorities of Digest, Enhanced Digest, TLS, > and IPsec? > > Jari > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 16 11:46:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14005 for ; Sat, 16 Feb 2002 11:46:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09523 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 11:46:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08296; Sat, 16 Feb 2002 11:07:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08270 for ; Sat, 16 Feb 2002 11:06:48 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13536 for ; Sat, 16 Feb 2002 11:06:43 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1GG6xj39985; Sat, 16 Feb 2002 08:06:59 -0800 (PST) To: "Jari Arkko" Cc: "Michael Thomas" , "Peterson, Jon" , "Juha Heinanen" , "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Feb 2002 08:06:59 -0800 In-Reply-To: "Jari Arkko"'s message of "Sat, 16 Feb 2002 09:05:10 +0200" Message-ID: Lines: 127 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org "Jari Arkko" writes: > Mike wrote in an answer to Eric: > > > > Michael, one of the things that draft authors do is put text into > > > drafts so that it can be debated by the WG. As for the changes > > > being of dubious utility, I know it's hard for you to believe, > > > but people might have different opinions from you about utility. > > > > Fine. Let's have a consensus call. > > Well, I counted myself, Juha, Sanjoy, and Mike already supporting > my ealier priority list which concluded that S/MIME is not the highest > priority. At least Jonathan, Eric, and Jon have the opposite view so > at present the no-S/MIME group is slightly larger but we really don't > have any consensus. > > But I have a compromise suggestion. Why don't we keep the S/MIME > stuff in Bis but make it a MAY, and then move on to continue to the > discussion about relative priorities of Digest, Enhanced Digest, TLS, > and IPsec? I don't think the issues of Digest, Enhanced Digest and S/MIME are separable. In my view, they all serve roughly the same purpose, except that S/MIME is rather more flexible. The requirement here is for some form of authentication and message integrity that survives multiple trips through proxies. The requirement that it survive proxies produces two side effects: 1. It rules out the use of TLS or IPsec since those are inherently hbh. 2. It requires that we allow some headers to be excluded from integrity protection so that they can be modified en route by proxies. Pretty much every solution to this sort of problem looks roughly the same: a message integrity check over the headers (and maybe the body) but with certain headers somehow excluded. There are four primary design decisions to be made: (I) How to exclude content from the domain of protection? 1. specifically call out certain headers to be unprotected [this is the approach that digest takes] 2. protect everything but allow certain parts of the message to be modified in flight. [this is the approach that Jon et al use with S/MIME]. Approach (1) has the advantage that it's wire encoding is compact, since changed headers don't take up space. Approach (2) requires an audit trail to allow verification. OTOH, approach (2) allows the recipient to determine the original values of the headers, even of those which were allegedly excluded from verification. This allows the recipient to apply a stricter security policy than required by the standard, by rejecting certain modifications. (II) What kind of keying to use? You'll note that I haven't said anything about what kind of integrity check to use for data origin authentication. That's because it's an orthogonal question. The two obvious approaches are MACs based on shared keys and digital signatures based on public keys. S/MIME supports both (password is discussed in RFC 3211). Digest supports only shared key. (III) Anti-replay protection and challenges. This is the big difference between S/MIME and Digest. Digest was conceived as a Web security mechanism and so has a method for a server or proxy to tell the client or proxy that it would like authentication. The authors of the S/MIME section of -bis obviously conceived of S/MIME as something that the client would offer, not be prompted for, so there's no comparable mechanism. (That's certainly how S/MIME is used in the e-mail context). However, it would be relatively straightforward to adapt the Digest prompting and anti-replay mechanisms to S/MIME. (IV) Confidentiality Once you're in the message-processing business, confidentiality becomes an attractive proposition. S/MIME offers it. Digest does not. (Though of course you could add it.) Since Digest and S/MIME cover so much of the same space, I don't see much point in having both. We need to keep Digest around for a while for compatibility reasons but we should start to deprecate it and do either Enhanced Digest or S/MIME but not both. The question then becomes which is a more suitable base to start from, S/MIME or some Enhanced Digest. In my view, S/MIME is the better choice because it provides an upgrade path. In particular, there's no extra specification effort to provide public-key based authentication or confidentiality. You just get them when you specify S/MIME. It would of course be possible to add these features to Digest but it would be ugly and you'd essentially have reinvented most of S/MIME at that point. By contrast, using a Digest-based anti-replay and prompting mechanism with S/MIME is easy and requires no modifications to S/MIME per se. Accordingly, I propose we do the following. (1) Specify S/MIME support (roughly as in bis), as XXX (XXX=MUST or SHOULD. I'd prefer MUST but I could live with SHOULD). profiled as: (a) Support for password and symmetric key management as XXX. (b) Support for public key as MAY. (c) Support for confidentiality as MAY. (2) Adapt Digest's prompting mechanism to work with S/MIME. Essentially this means providing a new header to say 'authenticate with S/MIME. Here's the anti-replay token to use'. I understand that this will be somewhat more effort for implementors (since S/MIME processing is a little more complicated than Digest, but profiled down this way, I believe it's quite manageable). And implementors who want to do more can easily do so. I'm against proceeding with Enhanced Digest. Digest is already pretty messy and will just get more messy if we go further down that path. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Sat Feb 16 13:53:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15480 for ; Sat, 16 Feb 2002 13:52:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14257 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 13:53:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13970; Sat, 16 Feb 2002 13:35:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13937 for ; Sat, 16 Feb 2002 13:35:54 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15264 for ; Sat, 16 Feb 2002 13:35:50 -0500 (EST) Received: (qmail 7225 invoked from network); 16 Feb 2002 18:39:15 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 16 Feb 2002 18:39:15 -0000 Received: from stake.com (unknown [10.1.64.73]) by cam-relay.atstake.com (Postfix) with SMTP id 1411E22817 for ; Sat, 16 Feb 2002 13:34:44 -0500 (EST) Message-ID: <3C6EA751.9000406@stake.com> Date: Sat, 16 Feb 2002 18:39:13 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] A Problem with Section 22.3.2.1 (bis-07) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, There were a thing or two that I remember that bothered me when reading Section 22.3.2.1 and forgot to put in the DRAFT paper I sent to this list two days ago. One of them is the following: Lines 4424-4425: "...When it receives the TLS certificate message, the UA SHOULD verify the certificate and inspect the site identified by the certificate...". Two things here, the first is that the "SHOULD" is really a "MUST". Why do we bother that much if the certificate will not be verified? Change from "SHOULD" to "MUST" is a must in this case :P The second thing - INSPECT. Maybe more information here for people who are not familiar how, correctly, TLS is required to be implemented? Don't forget that people that need to implement SIP not always has the best security background. Just my 2c for Saturday -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 16 14:23:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15725 for ; Sat, 16 Feb 2002 14:23:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA15314 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 14:23:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15069; Sat, 16 Feb 2002 14:07:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15041 for ; Sat, 16 Feb 2002 14:07:38 -0500 (EST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15634 for ; Sat, 16 Feb 2002 14:07:34 -0500 (EST) Received: from jariws1 ([62.248.144.77]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020216190735.BKJN24910.fep01-app.kolumbus.fi@jariws1>; Sat, 16 Feb 2002 21:07:35 +0200 Message-ID: <001f01c1b71d$36c50260$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Peterson, Jon" Cc: References: <70565611B164D511957A001083FCDD56CAAF4E@VA02> Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) Date: Sat, 16 Feb 2002 21:07:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > We have a MUST for Digest; I'm not sure what exactly 'enhanced Digest' here > means. There have been a number of proposals for Digest enhancement, as well > as a number for Digest replacement (I would group EAP and Digest-as-SASL in > this category). Is there a particular draft that is the winner? Given that > this matter seems somewhat contentious, I'm not sure this is necessarily a > more expedient route than developing the mechanisms currently in the > specification. I believe most of the folks who have proposed digest enhancements have gotten together and joined efforts and there either is a draft in the directories or it will appear soon. James are you listening, maybe you can post a link... Not that digest or its enhanced version are perfect either, but nevertheless good candidates for a mandatory mechanism. And as you point out Jon, digest already is a MUST. That's good. Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 16 15:32:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16285 for ; Sat, 16 Feb 2002 15:32:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17787 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 15:32:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17004; Sat, 16 Feb 2002 15:12:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16975 for ; Sat, 16 Feb 2002 15:12:48 -0500 (EST) Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16174 for ; Sat, 16 Feb 2002 15:12:43 -0500 (EST) Received: from miner ([80.3.228.59]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020216201246.FRZF7206.mta05-svc.ntlworld.com@miner>; Sat, 16 Feb 2002 20:12:46 +0000 Message-ID: <003101c1b725$d2f30760$3be40350@miner> From: "James Undery" To: "Jari Arkko" Cc: , Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) Date: Sat, 16 Feb 2002 20:09:21 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > We have a MUST for Digest; I'm not sure what exactly 'enhanced Digest' here > > means. There have been a number of proposals for Digest enhancement, as well > > as a number for Digest replacement (I would group EAP and Digest-as-SASL in > > this category). Is there a particular draft that is the winner? Given that > > this matter seems somewhat contentious, I'm not sure this is necessarily a > > more expedient route than developing the mechanisms currently in the > > specification. > > I believe most of the folks who have proposed digest enhancements have > gotten together and joined efforts and there either is a draft in the > directories > or it will appear soon. James are you listening, maybe you can post a link... The first cut of draft is now at http://www.ietf.org/internet-drafts/draft-undery-sip-auth-00.txt . It covers mutual authentication between UAC-UAS, UAC-Proxy and UAS-Proxy; it has bid down protection, various levels of integrity protection and can be used by schemes other than digest (the bid-down protection needs nonces though :-( ). > Not that digest or its enhanced version are perfect either, but nevertheless > good candidates for a mandatory mechanism. And as you point out Jon, > digest already is a MUST. That's good. I'd like to echo that with Digest isn't perfect EAP strikes me as a far better mechanism, hence the flexibility we tried to introduce to the draft. 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 daemon@optimus.ietf.org Sat Feb 16 15:48:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16410 for ; Sat, 16 Feb 2002 15:48:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18063 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 15:48:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17175; Sat, 16 Feb 2002 15:20:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17144 for ; Sat, 16 Feb 2002 15:20:36 -0500 (EST) Received: from fep01.superonline.com (fep01.superonline.com [212.252.122.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16211 for ; Sat, 16 Feb 2002 15:20:30 -0500 (EST) Received: from sincap ([195.175.156.119]) by fep01.superonline.com with ESMTP id <20020216201545.TRIR21295.fep01@sincap> for ; Sat, 16 Feb 2002 22:15:45 +0200 Message-ID: <001b01c1b77b$9d1b5880$779cafc3@sincap> From: "Alp Eren YILMAZ" To: Date: Sat, 16 Feb 2002 22:23:25 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0015_01C1B738.8D3B7460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] Help Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C1B738.8D3B7460 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0016_01C1B738.8D3B7460" ------=_NextPart_001_0016_01C1B738.8D3B7460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0016_01C1B738.8D3B7460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_001_0016_01C1B738.8D3B7460-- ------=_NextPart_000_0015_01C1B738.8D3B7460 Content-Type: text/x-vcard; name="Alp Eren YILMAZ.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Alp Eren YILMAZ.vcf" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:YILMAZ;Alp;Eren FN:Alp Eren YILMAZ URL;WORK:http://www.cmpe.boun.edu.tr/~alperen EMAIL;PREF;INTERNET:alperen@boun.edu.tr EMAIL;INTERNET:yilmazalperen@ttnet.net.tr REV:20020217T062325Z END:VCARD ------=_NextPart_000_0015_01C1B738.8D3B7460-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 16 15:53:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16453 for ; Sat, 16 Feb 2002 15:53:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18207 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 15:53:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17915; Sat, 16 Feb 2002 15:37:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17884 for ; Sat, 16 Feb 2002 15:37:45 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16320 for ; Sat, 16 Feb 2002 15:37:40 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1GKbDh29635; Sat, 16 Feb 2002 12:37:13 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACM55568; Sat, 16 Feb 2002 12:37:12 -0800 (PST) Date: Sat, 16 Feb 2002 12:35:54 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org cc: rohan@cisco.com Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] nits/comments on bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org hi, more nits, comments, and proposed clarifications from the pdf version of bis-07 through section 15. there are probably many dups, so please just send comments on the stuff that doesn't make sense. more important stuff marked with ** thanks, -rohan 17: s/distribution and/distribution, and/ 22: s/ontop/on top/ 315: s/URI) regardless/URI) called an address-of-record, regardless/ 326: append: the real-time transport control protocol (RTCP) for 364: s/and defined/which is defined/ 369: s/server, and/server; and/ 380: append @pc33.atlanta.com to be consisitent with line 399 403: s/reach or // 487: s/so they drop/so the proxies drop/ 513: s/to the proxy/to the hostname or IP address of the proxy/ 533: s/programmed/configured/ 537: s/request-by-request,/request-by-request basis with a/ 563: note that UAC hasn't been defined or spelled out yet 567: s/an FSM/a Finite State Machine (FSM)/ 576: also UAS hasn't been defined yet 615: s/a dialog/some communication/ ***** 623: s/UAC and UAS/pair of user agents/ 634: should define address-of-record 644: s/adress/address/ 663: s/its outbound/an outbound/ and s/learn it/learn about one/ 692: should define route-set 702: s/the user name/the SDP user name/ 717: s/A stateful/A (transaction) stateful/ 728: haven't defined proxy core.. probably not a big deal 730: s/server to user/server back to the user/ 746-7: s/server for the duration of the dialog/server/ 889: s/they/the headers/ OR s/they/the formats/ ** 994: s/the domain the/the domain on the/ 1014: ahhs.aa -> something else (localhost?) 1081: bad reference to sec:proxy-response-processing-via 1081: append a Via example please 1088: append a Contact example please 1091-1093: nuke 100rel stuff 1105-7: nuke 100rel stuff 1118: s/proceedures/procedures/ and also 1119: s/proceedures/procedures/ 1124: s/configuring outbound/configuring an outbound/ 1134: s/passes it/passes the response/ 1137-9: its probably useful if the TU can map other events: ** some DNS errors -> 404 some ICMP errors -> 403 If a timeout event is received from the transaction layer, it MUST ... The UAC MAY treat other transaction layer events as if they were a relevant SIP response. This document does not define any additional mappings. 1171: s/Client transaction/The client transaction/ 1126: inconsistent with sections 25.5.2 and 25.4.6 re: use of 405 vs. 501 (btw: I think always returning 405 is much more useful than a 501, but...) *** 1250: s/the TU checks/the TU MUST check/ 1271 and 1275: use an alternate example than 100rel 1313-5: not especially helpful. please reword or nuke the paragraph. 1386: s/GSTN/a PSTN/ 1405: s/to which can take a long time to respond/which can take a long time before a final response is received. 1407: s/sent a response/sent a final response/ 1450: s/were anything but CANCEL, apply/is anything other than CANCEL, and applying/ 1478: s/process is/process is frequently/ 1484-5: s/into which a user is logged/where that user can receive SIP requests/ 1499: s/will then be/is then typically/ 1503: s/a proxy for/any proxy or redirect server for/ 1503: insert sentences like: User Agents MAY instead obtain location information for an address-of-record from a redirect server or by direct query of an appropriate registration server. Note that direct registration queries from third-party user agents MAY be forbidden by the privacy policy of the registrar. 1597: s/REGISTER/a REGISTER/ 1627: s/to proxy servers/to proxy and redirect server/ 1693: s/to the proxy/to the proxy or redirect server/ 1694: s/with 500/with a 500/ 1754: s/as in a redirect/as in a 300-class response/ 1780: s/a two/two/ 1799: s/the URI of/the Contact URI of/ 1800: s/, and/, and/ 1803: s/comes/arrives/ 1811-2: seems like a duplication of material in 1790-6 1822: s/and have global scope/and SHOULD have global scope/ 1888: s/MUST a/MUST add a/ 1893: s/the the/the 1967: s/on the method. When a dialog/on the method. An early dialog is terminated with a CANCEL. When a confirmed dialog/ ***** 1978: s/a provisional response/provisional responses/ 2079: s/a Contact header field/one or more Contact header fields/ 2122-5: under what circumstances will this ever happen with relative times? propose to nuke it unless i'm missing something. 2288: s/unbound/unbounded/ 2297: s/the dialog/a dialog created with an INVITE/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 16 16:26:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16773 for ; Sat, 16 Feb 2002 16:26:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19276 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 16:26:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18864; Sat, 16 Feb 2002 16:11:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18834 for ; Sat, 16 Feb 2002 16:11:19 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16658 for ; Sat, 16 Feb 2002 16:11:14 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1GLBZ6Y004839 for ; Sat, 16 Feb 2002 16:11:35 -0500 (EST) Message-ID: <3C6ECAD7.72F07EB8@dynamicsoft.com> Date: Sat, 16 Feb 2002 16:10:47 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] UPDATE draft now available Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, To rapidly progress with the unify proposal, we've decided to have a stand-alone UPDATE method, which defines that method in a general way. Then, the manyfolks draft will be rewritten to depend on bis and unify, with that work to now be undertaken by Gonzalo in short order. I have just finished the first, rough draft of the UPDATE method. Until it appears in the I-D archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-sip-update-00.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sat Feb 16 17:33:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17298 for ; Sat, 16 Feb 2002 17:33:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21941 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 17:33:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21109; Sat, 16 Feb 2002 17:08:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21078 for ; Sat, 16 Feb 2002 17:08:23 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17113 for ; Sat, 16 Feb 2002 17:08:17 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1GM7fZ05590; Sat, 16 Feb 2002 14:07:41 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACM55754; Sat, 16 Feb 2002 14:07:49 -0800 (PST) Date: Sat, 16 Feb 2002 14:06:32 -0800 (Pacific Standard Time) From: Rohan Mahy To: mat@cisco.com, cc: rohan@cisco.com Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] SMIME in SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Mike, comments inline... -------------------------------------------------------------------------------- mat@cisco.com..... >Eric Rescorla writes: > > Michael Thomas writes: > > > You seem into falling into a false dichotomy that > > > if SMIME doesn't go into bis, we are now and > > > forever resigned to inadequate security for > > > SIP. > > I don't think it's a false dichotomy. Rather, it's a pretty > > accurate statement of the common pattern. To whit: WG produces > > a document with horrible security problems. Says, "we'll fix > > security later". Document passes. WG doesn't fix security. > >Are you actually claiming that SIP without SMIME >would be "a document with horrible security >problems"? I sure hope not, because if you are I >think you need to get a grip; the current PSTN >does exactly this today, and the world has not >come to an end. That is the LAMEST argument I have ever heard regarding SIP security. - First, The PSTN has been successfully hacked on occasions too numerous to mention. While the world hasn't come to an end, people have actually DIED as a result of irresponsible parties attacking the PSTN. I don't know about your standards in this regard, but it is unacceptable to me to build a new system/protocol that mirrors such a crappy security model when that much is at stake. - Second, I would like to be able to use SIP outside of walled garden networks. - Third, hacking the PSTN in a major way usually requires more physical access and a higher chance of getting caught than cracking in the IP world. It is just easier to attack a SIP network that is connected in any way to the Internet, than it is to attack the PSTN. > > What is in bis now seems to have no support > > amongst those building UA's and since it's only a > > SHOULD there isn't even a penalty if you ignore > > it. > I'd be perfectly willing to have it a MUST if that would > make you happier. >This is a perfect example of why most security >protocols are complete failures. Making an >unworkable and bloated thing a MUST or SHOULD does >not change the dynamics of development, deployment >or system engineering. If something is useless >and/or harmful it will not be implemented, >holier-than-thou attitudes not withstanding. who are you calling holier-than-thou? TLS is neither useless nor harmful. SMIME is neither useless nor harmful, although I would prefer MAY strength for it. >If we actually want to acheive something that has >better security than the status quo -- and that is >an abysmally low threshold as far as the eye can >see -- it is generally prudent to actual consider >what is feasible in the real world and provide a >gradient which doesn't make it an all or nothing >proposition where "nothing" is the invariable >choice. [snide comments elided] Let's get specific. You have made no proposals to date which both meet your requirements above, and are useful in the deployed Internet at large. Your IPsec proposal would not work through most NATs, and your other proposals are all more complicated that the existing SMIME in bis. I believe that the TLS support now described in bis is the closest we are going to come to that kind of balance. I can implement the minimum TLS ciphersuite from open-source toolkits in 80k on a Palm or an IP phone, and I can use it from practically anywhere, even behind NATs. It is currently implemented on the most widely used SIP user agent today. That's worthy of a SHOULD in my book. The SMIME stuff in bis is heavy, but not terribly complicated. It is clearly suitable for use on general purpose computers, ISUP gateways, application servers, and high-end IP phones. It uses a practical key distribution model that most nerds are already familiar with. I think that's worthy of a MAY. 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 daemon@optimus.ietf.org Sat Feb 16 17:52:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17488 for ; Sat, 16 Feb 2002 17:52:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22534 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 17:52:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22227; Sat, 16 Feb 2002 17:36:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22195 for ; Sat, 16 Feb 2002 17:36:49 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17361 for ; Sat, 16 Feb 2002 17:36:43 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1GMOHj01751; Sat, 16 Feb 2002 16:24:17 -0600 Message-ID: <3C6EDC11.5030908@dynamicsoft.com> Date: Sat, 16 Feb 2002 16:24:17 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] nits/comments on bis-07 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit These are either integrated or bugs have been entered against them. This was the second comment on ahhs.aa - I changed that example to sip:completely@meaningless.uri You are correct wrt: INVITEs not arriving already expired. RjS Rohan Mahy wrote: > hi, > > more nits, comments, and proposed clarifications from the pdf version of > bis-07 through section 15. > > there are probably many dups, so please just send comments on the stuff > that doesn't make sense. > > more important stuff marked with ** > > thanks, > -rohan > > > 17: s/distribution and/distribution, and/ > > 22: s/ontop/on top/ > > 315: s/URI) regardless/URI) called an address-of-record, regardless/ > > 326: append: the real-time transport control protocol (RTCP) for > > 364: s/and defined/which is defined/ > > 369: s/server, and/server; and/ > > 380: append @pc33.atlanta.com to be consisitent with line 399 > > 403: s/reach or // > > 487: s/so they drop/so the proxies drop/ > > 513: s/to the proxy/to the hostname or IP address of the proxy/ > > 533: s/programmed/configured/ > > 537: s/request-by-request,/request-by-request basis with a/ > > 563: note that UAC hasn't been defined or spelled out yet > > 567: s/an FSM/a Finite State Machine (FSM)/ > > 576: also UAS hasn't been defined yet > > 615: s/a dialog/some communication/ ***** > > 623: s/UAC and UAS/pair of user agents/ > > 634: should define address-of-record > > 644: s/adress/address/ > > 663: s/its outbound/an outbound/ and s/learn it/learn about one/ > > 692: should define route-set > > 702: s/the user name/the SDP user name/ > > 717: s/A stateful/A (transaction) stateful/ > > 728: haven't defined proxy core.. probably not a big deal > > 730: s/server to user/server back to the user/ > > 746-7: s/server for the duration of the dialog/server/ > > 889: s/they/the headers/ OR s/they/the formats/ ** > > 994: s/the domain the/the domain on the/ > > 1014: ahhs.aa -> something else (localhost?) > > 1081: bad reference to sec:proxy-response-processing-via > > 1081: append a Via example please > > 1088: append a Contact example please > > 1091-1093: nuke 100rel stuff > > 1105-7: nuke 100rel stuff > > 1118: s/proceedures/procedures/ and also 1119: s/proceedures/procedures/ > > 1124: s/configuring outbound/configuring an outbound/ > > 1134: s/passes it/passes the response/ > > 1137-9: its probably useful if the TU can map other events: ** > some DNS errors -> 404 > some ICMP errors -> 403 > > If a timeout event is received from the transaction layer, it MUST ... > > The UAC MAY treat other transaction layer events as if they were a > relevant SIP response. This document does not define any additional mappings. > > 1171: s/Client transaction/The client transaction/ > > 1126: inconsistent with sections 25.5.2 and 25.4.6 re: use of > 405 vs. 501 (btw: I think always returning 405 is much more useful than a > 501, but...) *** > > 1250: s/the TU checks/the TU MUST check/ > > 1271 and 1275: use an alternate example than 100rel > > 1313-5: not especially helpful. please reword or nuke the paragraph. > > 1386: s/GSTN/a PSTN/ > > 1405: s/to which can take a long time to respond/which can take a long > time before a final response is received. > > 1407: s/sent a response/sent a final response/ > > 1450: s/were anything but CANCEL, apply/is anything other than CANCEL, and > applying/ > > 1478: s/process is/process is frequently/ > > 1484-5: s/into which a user is logged/where that user can receive SIP requests/ > > 1499: s/will then be/is then typically/ > > 1503: s/a proxy for/any proxy or redirect server for/ > > 1503: insert sentences like: User Agents MAY instead obtain location > information for an address-of-record from a redirect server or by direct > query of an appropriate registration server. Note that direct > registration queries from third-party user agents MAY be forbidden by the > privacy policy of the registrar. > > 1597: s/REGISTER/a REGISTER/ > > 1627: s/to proxy servers/to proxy and redirect server/ > > 1693: s/to the proxy/to the proxy or redirect server/ > > 1694: s/with 500/with a 500/ > > 1754: s/as in a redirect/as in a 300-class response/ > > 1780: s/a two/two/ > > 1799: s/the URI of/the Contact URI of/ > > 1800: s/, and/, and/ > > 1803: s/comes/arrives/ > > 1811-2: seems like a duplication of material in 1790-6 > > 1822: s/and have global scope/and SHOULD have global scope/ > > 1888: s/MUST a/MUST add a/ > > 1893: s/the the/the > > 1967: s/on the method. When a dialog/on the method. An early dialog is > terminated with a CANCEL. When a confirmed dialog/ > ***** > > 1978: s/a provisional response/provisional responses/ > > 2079: s/a Contact header field/one or more Contact header fields/ > > 2122-5: under what circumstances will this ever happen with relative > times? propose to nuke it unless i'm missing something. > > > 2288: s/unbound/unbounded/ > > 2297: s/the dialog/a dialog created with an INVITE/ > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sat Feb 16 18:13:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17687 for ; Sat, 16 Feb 2002 18:13:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23506 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 18:13:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22281; Sat, 16 Feb 2002 17:38:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22250 for ; Sat, 16 Feb 2002 17:37:57 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17372 for ; Sat, 16 Feb 2002 17:37:51 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1GMbFZ08946; Sat, 16 Feb 2002 14:37:15 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX24506; Sat, 16 Feb 2002 14:36:54 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA28526; Sat, 16 Feb 2002 14:37:22 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15470.57122.730272.48839@thomasm-u1.cisco.com> Date: Sat, 16 Feb 2002 14:37:22 -0800 (PST) To: Rohan Mahy Cc: mat@cisco.com, Subject: [Sip] SMIME in SIP In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit 1) I have said nothing about TLS in this thread 2) I haven't made a proposal for IPsec because Allison said that it won't go into bis regardless 3) Equating me asking that we postpone considering e2e mechanisms with people dying tops any claims of LAMEST I can imagine. 4) TLS doesn't address UDP. IPsec WG is working on NAT traversal 5) In order for SMIME to work in a large scale, you need a large scale PKI. Good luck. Mike Rohan Mahy writes: > Mike, > > comments inline... > > -------------------------------------------------------------------------------- > mat@cisco.com..... > >Eric Rescorla writes: > > > Michael Thomas writes: > > > > You seem into falling into a false dichotomy that > > > > if SMIME doesn't go into bis, we are now and > > > > forever resigned to inadequate security for > > > > SIP. > > > I don't think it's a false dichotomy. Rather, it's a pretty > > > accurate statement of the common pattern. To whit: WG produces > > > a document with horrible security problems. Says, "we'll fix > > > security later". Document passes. WG doesn't fix security. > > > >Are you actually claiming that SIP without SMIME > >would be "a document with horrible security > >problems"? I sure hope not, because if you are I > >think you need to get a grip; the current PSTN > >does exactly this today, and the world has not > >come to an end. > > That is the LAMEST argument I have ever heard regarding SIP security. > > - First, The PSTN has been successfully hacked on occasions too numerous > to mention. While the world hasn't come to an end, people have > actually DIED as a result of irresponsible parties attacking the PSTN. I > don't know about your standards in this regard, but it is unacceptable to > me to build a new system/protocol that mirrors such a crappy security > model when that much is at stake. > > - Second, I would like to be able to use SIP outside of walled garden > networks. > > - Third, hacking the PSTN in a major way usually requires more physical > access and a higher chance of getting caught than cracking in the IP > world. It is just easier to attack a SIP network that is connected in > any way to the Internet, than it is to attack the PSTN. > > > > > What is in bis now seems to have no support > > > amongst those building UA's and since it's only a > > > SHOULD there isn't even a penalty if you ignore > > > it. > > I'd be perfectly willing to have it a MUST if that would > > make you happier. > > >This is a perfect example of why most security > >protocols are complete failures. Making an > >unworkable and bloated thing a MUST or SHOULD does > >not change the dynamics of development, deployment > >or system engineering. If something is useless > >and/or harmful it will not be implemented, > >holier-than-thou attitudes not withstanding. > > who are you calling holier-than-thou? > > TLS is neither useless nor harmful. > SMIME is neither useless nor harmful, although I > would prefer MAY strength for it. > > >If we actually want to acheive something that has > >better security than the status quo -- and that is > >an abysmally low threshold as far as the eye can > >see -- it is generally prudent to actual consider > >what is feasible in the real world and provide a > >gradient which doesn't make it an all or nothing > >proposition where "nothing" is the invariable > >choice. [snide comments elided] > > Let's get specific. You have made no proposals to date which both meet > your requirements above, and are useful in the deployed Internet at large. > Your IPsec proposal would not work through most NATs, and your other > proposals are all more complicated that the existing SMIME in bis. > > I believe that the TLS support now described in bis is the closest we are > going to come to that kind of balance. I can implement the minimum TLS > ciphersuite from open-source toolkits in 80k on a Palm or an IP phone, and > I can use it from practically anywhere, even behind NATs. It is > currently implemented on the most widely used SIP user agent today. > That's worthy of a SHOULD in my book. > > The SMIME stuff in bis is heavy, but not terribly complicated. It is > clearly suitable for use on general purpose computers, ISUP gateways, > application servers, and high-end IP phones. It uses a practical > key distribution model that most nerds are already familiar with. > I think that's worthy of a MAY. > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 16 18:13:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17705 for ; Sat, 16 Feb 2002 18:13:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23522 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 18:13:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22958; Sat, 16 Feb 2002 18:00:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22911 for ; Sat, 16 Feb 2002 18:00:29 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17561 for ; Sat, 16 Feb 2002 18:00:24 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1GN0it40366; Sat, 16 Feb 2002 15:00:44 -0800 (PST) To: Michael Thomas Cc: Rohan Mahy , Subject: Re: [Sip] SMIME in SIP References: <15470.57122.730272.48839@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Feb 2002 15:00:43 -0800 In-Reply-To: Michael Thomas's message of "Sat, 16 Feb 2002 14:37:22 -0800 (PST)" Message-ID: Lines: 8 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > 5) In order for SMIME to work in a large scale, > you need a large scale PKI. Good luck. This simply is not true. S/MIME has shared key modes. Any form of key management that's practical for digest or IPsec is equally practical for S/MIME. -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 daemon@optimus.ietf.org Sat Feb 16 18:32:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17910 for ; Sat, 16 Feb 2002 18:32:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24409 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 18:32:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23394; Sat, 16 Feb 2002 18:06:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23370 for ; Sat, 16 Feb 2002 18:06:18 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17630 for ; Sat, 16 Feb 2002 18:06:14 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1GN5kh01422; Sat, 16 Feb 2002 15:05:46 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX24595; Sat, 16 Feb 2002 15:05:17 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA28529; Sat, 16 Feb 2002 15:05:45 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15470.58825.137948.175526@thomasm-u1.cisco.com> Date: Sat, 16 Feb 2002 15:05:45 -0800 (PST) To: EKR Cc: Michael Thomas , Rohan Mahy , Subject: Re: [Sip] SMIME in SIP In-Reply-To: References: <15470.57122.730272.48839@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric Rescorla writes: > Michael Thomas writes: > > 5) In order for SMIME to work in a large scale, > > you need a large scale PKI. Good luck. > This simply is not true. S/MIME has shared key modes. Any form of > key management that's practical for digest or IPsec is equally > practical for S/MIME. Uh, I said large scale. As in, anything that might take the place of the current PSTN. 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 daemon@optimus.ietf.org Sat Feb 16 18:50:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18068 for ; Sat, 16 Feb 2002 18:50:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24628 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 18:50:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23763; Sat, 16 Feb 2002 18:23:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23668 for ; Sat, 16 Feb 2002 18:23:10 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17782 for ; Sat, 16 Feb 2002 18:23:06 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1GNMch05915; Sat, 16 Feb 2002 15:22:38 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX24630; Sat, 16 Feb 2002 15:22:08 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA28532; Sat, 16 Feb 2002 15:22:36 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15470.59836.690123.189355@thomasm-u1.cisco.com> Date: Sat, 16 Feb 2002 15:22:36 -0800 (PST) To: EKR Cc: "Jari Arkko" , "Michael Thomas" , "Peterson, Jon" , "Juha Heinanen" , "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric Rescorla writes: > I don't think the issues of Digest, Enhanced Digest and S/MIME > are separable. In my view, they all serve roughly the same > purpose, except that S/MIME is rather more flexible. In fact, the way the draft is written, this is incorrect. Digest is being used for proxy authentication, and SMIME is being used for end to end. However, if we weren't in a headlong rush to cram stuff into bis, something probably could unify all of these. As currently written, SMIME in bis is not that something. This is why I would like to see SMIME taken out of bis, and considered separately. > Since Digest and S/MIME cover so much of the same space, I don't see > much point in having both. We need to keep Digest around for a while > for compatibility reasons but we should start to deprecate it and do > either Enhanced Digest or S/MIME but not both. The question then > becomes which is a more suitable base to start from, S/MIME or > some Enhanced Digest. I certainly haven't suggested that digest should be extended. In fact, I don't think that enhanced digest is all that interesting, and have stated so in the past. However, that doesn't necessarily imply SMIME. SMIME is terribly heavy and needs a lot more consideration than has been given thus far. SIP needs to run in very low footprint and very low bandwidth/lossy environments. SMIME was clearly not designed with those constraints in mind, and is hardly ideal. Indeed, the right thing here might be to do something that makes sense for SIP rather than relying on things which were designed for other requirements. Given how important rendezvous protocols are in real life, I think it's far more important to get it right rather than just jamming something into the spec at the last minute and hoping that it works. As specified now, SMIME is nothing more than warmed over PGP -- which had no support either. This is not encouraging. 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 daemon@optimus.ietf.org Sat Feb 16 19:22:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18624 for ; Sat, 16 Feb 2002 19:22:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA25754 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 19:22:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25080; Sat, 16 Feb 2002 19:00:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25029 for ; Sat, 16 Feb 2002 19:00:31 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18267 for ; Sat, 16 Feb 2002 19:00:26 -0500 (EST) Received: (qmail 7996 invoked from network); 17 Feb 2002 00:03:49 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 17 Feb 2002 00:03:49 -0000 Received: from stake.com (unknown [10.1.64.73]) by cam-relay.atstake.com (Postfix) with SMTP id E82E022817; Sat, 16 Feb 2002 18:58:51 -0500 (EST) Message-ID: <3C6EF34B.5050904@stake.com> Date: Sun, 17 Feb 2002 00:03:23 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: EKR , Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <15470.58825.137948.175526@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Guys, This begins to look like a big piss competition and not like something worth while. And sorry that I step into this. I am thinking it is about time to stop the personal accusations and get into real stuff. Just remember that this is more for the community than it is for any of us prestigious records... Couple of things I feel that are good to mention: 1. The PSTN today is not a good module to look at when we are talking about security. There is no excuse to say that if the PSTN today is having a lot of problems with its security than the something that will replace it needs to be badly designed. I agree with Rohan on this one. In my opinion we tend to forget too fast the other problems with a SIP based network (RTP Security?) 2. SIP and SIP Security need to challenge the worst conditions. Lab conditions or sometimes "best practices" are not enough. You just need to imagine what are the worst circumstances security wise and operational wise you can have and think if things will work (and try them). 3. IF and IF VoIP based networks will replace the current PSTN than my friends access to the wire will be THE number one problem with those networks. There is still a VERY long way to go in securing the ENTIRE infrastructure than anyone really understands (as one that was incharge of a 4th generation wanna-be telecom company's security I am familiar with some of those). 4. There is no client security, and we NEVER need to trust the client side. 5. What ever encryption protocol that is using pre-shared keys is NOT GOOD. I can mention scalability, cloning and other nice things. BTW - have you seen a good PKI Internet wise implementation? (and please do not say PGP and do not tell me that in a BIG network this works). 6. We need to understand that there are a lot of other things that needs to be written about how SIP proxy/registar/redirect servers handle things. Several things are so basic that it frustrates to read the drafts. Encryption will not solve everything. Examples like who needs to filter relay like traffic? firewalls or proxies? and other gifted things. BTW - who will pay the 5-30 seconds overhead with setting up the TLS session? you? me? the designers of the protocol? sure not, it will be the users... Do not forget that... 7. Wiretapping is another major thing that needs to be addressed and this is again and again thrown under the carpet. 8. Section 22 really needs help. See my other posts. 9. Encryption is not a simple thing. Proxies and especially stateful once, will have to deal will a lot of traffic and overheads. 10. If the UA's do not verify the certificates than what are we doing with TLS in the first place? 11. What encryption algorithms are we going to allow? This is too wide to interpretation... you really wish to use 40-bit DES? 12. AND what will you do with UDP? after everybody on the planet preached for its usage with VoIP now SIP cannot secure it? G. These are some of the points. There are a lot more... Now, are we going to start thinking on the correct direction again, or are we keeping smearing each other? Michael Thomas wrote: > Eric Rescorla writes: > > Michael Thomas writes: > > > 5) In order for SMIME to work in a large scale, > > > you need a large scale PKI. Good luck. > > This simply is not true. S/MIME has shared key modes. Any form of > > key management that's practical for digest or IPsec is equally > > practical for S/MIME. > > Uh, I said large scale. As in, anything that > might take the place of the current PSTN. > > 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 > -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 16 19:53:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18935 for ; Sat, 16 Feb 2002 19:53:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA26755 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 19:53:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25864; Sat, 16 Feb 2002 19:25:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25833 for ; Sat, 16 Feb 2002 19:25:35 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18668 for ; Sat, 16 Feb 2002 19:25:32 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1H0Coj01804; Sat, 16 Feb 2002 18:12:50 -0600 Message-ID: <3C6EF580.1090901@dynamicsoft.com> Date: Sat, 16 Feb 2002 18:12:48 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: seshashayi@hss.hns.com CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu Subject: Re: [Sip] Re: [Sip-implementors] bis-07 now available References: <65256B56.0055B233.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This has been corrected - thanks! RjS seshashayi@hss.hns.com wrote: > > Hi, > A minor typo in the draft-ietf-sip-rfc2543bis-07.txt draft. > > (Section 7.3.1, Page 23) > "The exception to this rule are the Authorization, Proxy-Authorization, > Proxy-Authenticate and > Proxy-Authorization headers." > The Proxy-Authorization is mentioned twice.I think, one of them should be > WWW-Authenticate. > > Rgds > -Seshu > > seshashayi@hss.hns.com > http://www.hssworld.com > > > > > > Jonathan Rosenberg on 02/04/2002 04:04:46 PM > > To: sip@ietf.org, sip-implementors@cs.columbia.edu > cc: (bcc: Seshashayi T/HSSBLR) > > Subject: [Sip-implementors] bis-07 now available > > > > > Folks, > > After much toil, bis-07 is now available. You can pick it up from: > > http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-07.pdf > http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-07.txt > http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-07.ps > > or > > http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-07.txt > http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-07.pdf > http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-07.ps > > It'll appear in the I-D editor archives shortly as well. > > The PDF and PS have changebars and line numbers, as always. > > Since there are no longer changes noted from the previous draft, here > are the changes: > > 1. single consolidated "changes from rfc2543" section, listing major > stuff. > > 2. BNF converted to rfc2234, countless bugs fixed based on comments > > 3. new loose route text incorporated. Please read this. The text is > different from what Robert had described on the list. Whilst > incorporating that text, we ran into a case that didn't work. TUrns out > the fix simplified the whole thing even further. Based on robert's note, > a proxy that wanted to route to a strict router would need to dig up the > first loose router in a route set, say A, and replace that route entry > with A, target, A, where target is the current r-uri. That is not the > case now; it simply appends the r-uri to the bottom-most route element. > This improves the backwards compatibility story, improves proxy > performance, and makes things much more self consistent. Proxy > processing of route/record-route is now shrunk considerably from bis-05 > and bis-06. > > 4. split references into normative and non-normative. > > 5. incorporated text on generalized offer/answer mappings to SIP > requests and responses > > 6. Reduced usage of 70 as max-forwards value from MUST to SHOULD > > 7. Included fix for open issue #58. When UAS generates an offer in a 2xx > to re-invite, > it uses the broadest SDP possible that it belives will not be rejected > by its peer. > > 8. Added some S/MIME error cases. > > 9. Fixed normative strengths of S/MIME support (MUST for signed-data and > certs-only). > > 10. Strengthened TLS/IPSec wording (fixing nits). > > 11. S/MIME should now be able to reuse root CAs used to verify TLS/IPSec > keys. > > 12. Added brief statement to start of threat model section describing > threat environment. > > 13. Added eavesdropping to threats based on body modification. > > 14. clarified conditions under which multiple headers can be folded into > one header with comma separated values. Also pointed out exception for > the Auth headers. > > 15. Max-Forwards needs to be between 1 and 255. > > 16. Added anonymous username and password for digest. > > 17. Clarified usage of timestamp delay parameter. > > > > THis document is now officially in working group last call! > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/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 daemon@optimus.ietf.org Sat Feb 16 20:17:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19229 for ; Sat, 16 Feb 2002 20:17:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA27806 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 20:17:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26933; Sat, 16 Feb 2002 19:58:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26902 for ; Sat, 16 Feb 2002 19:58:16 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19033 for ; Sat, 16 Feb 2002 19:58:12 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1H0wS140460; Sat, 16 Feb 2002 16:58:28 -0800 (PST) To: Michael Thomas Cc: "Jari Arkko" , "Peterson, Jon" , "Juha Heinanen" , "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> <15470.59836.690123.189355@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Feb 2002 16:58:28 -0800 In-Reply-To: Michael Thomas's message of "Sat, 16 Feb 2002 15:22:36 -0800 (PST)" Message-ID: Lines: 31 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > Eric Rescorla writes: > > I don't think the issues of Digest, Enhanced Digest and S/MIME > > are separable. In my view, they all serve roughly the same > > purpose, except that S/MIME is rather more flexible. > > In fact, the way the draft is written, this is > incorrect. As I tried to make clear in my original message, I'm not talking about S/MIME as it's currently wedged into SIP, which I agree could use some work, but about S/MIME proper. In my view, SIP needs some sort of message integrity and confidentiality protocol. The choices on the table are invent something new or hijack something old. I'd rather do the latter if we can get away with it. The prime candidate there is S/MIME. > Indeed, the right thing here might be to do > something that makes sense for SIP rather than > relying on things which were designed for other > requirements. I don't understand what features of this new protocol you propose to design are going to make it substantially more lightweight than S/MIME. Do tell. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Sat Feb 16 20:17:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19244 for ; Sat, 16 Feb 2002 20:17:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA27821 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 20:17:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27178; Sat, 16 Feb 2002 20:00:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27116 for ; Sat, 16 Feb 2002 20:00:25 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19062 for ; Sat, 16 Feb 2002 20:00:21 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1H10j740469; Sat, 16 Feb 2002 17:00:45 -0800 (PST) To: Ofir Arkin Cc: Michael Thomas , Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <15470.58825.137948.175526@thomasm-u1.cisco.com> <3C6EF34B.5050904@stake.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Feb 2002 17:00:45 -0800 In-Reply-To: Ofir Arkin's message of "Sun, 17 Feb 2002 00:03:23 +0000" Message-ID: Lines: 26 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Ofir Arkin writes: > 4. There is no client security, and we NEVER need to trust the client side. Huh? No known cryptographic system does not require some trust on the client side, at least to protect the symmetric encryption keys. > BTW - who will pay the 5-30 seconds overhead with setting up the TLS > session? you? me? the designers of the protocol? sure not, it will be > the users... Do not forget that... What overhead are you referring to with 5-30 seconds? > 10. If the UA's do not verify the certificates than what are we doing > with TLS in the first place? All of the public-key based key exchange schemes require the UAs to verify certificates at some level. There's no real way around that. > 11. What encryption algorithms are we going to allow? This is too wide > to interpretation... you really wish to use 40-bit DES? This seems like rather a side issue. It's always been assumed that once we settled on a confidentiality solution we'd profile a secure set of algorithms. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Sat Feb 16 20:59:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19588 for ; Sat, 16 Feb 2002 20:59:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA28892 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 20:59:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28586; Sat, 16 Feb 2002 20:41:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28561 for ; Sat, 16 Feb 2002 20:41:38 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19473 for ; Sat, 16 Feb 2002 20:41:34 -0500 (EST) Received: (qmail 8181 invoked from network); 17 Feb 2002 01:44:58 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 17 Feb 2002 01:44:58 -0000 Received: from stake.com (unknown [10.1.64.73]) by cam-relay.atstake.com (Postfix) with SMTP id BCD9522817; Sat, 16 Feb 2002 20:40:32 -0500 (EST) Message-ID: <3C6F0B21.5030001@stake.com> Date: Sun, 17 Feb 2002 01:45:05 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: EKR Cc: Michael Thomas , Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <15470.58825.137948.175526@thomasm-u1.cisco.com> <3C6EF34B.5050904@stake.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric, Eric Rescorla wrote: > Ofir Arkin writes: > >>4. There is no client security, and we NEVER need to trust the client side. >> > Huh? No known cryptographic system does not require some trust on > the client side, at least to protect the symmetric encryption keys. Who mentioned Crypto here? Simply, in any given system you cannot trust the client side. If you present crypto you need to ensure the authenticity of the parties. >>BTW - who will pay the 5-30 seconds overhead with setting up the TLS >>session? you? me? the designers of the protocol? sure not, it will be >>the users... Do not forget that... >> > What overhead are you referring to with 5-30 seconds? Setup time (on large scale systems), and reconnection if the session was shutdown and needs to restart... You can take banking systems which use SSL v3.0 today and see what happens with setup times when a lot of concurrent connections are opened. >>10. If the UA's do not verify the certificates than what are we doing >>with TLS in the first place? >> > All of the public-key based key exchange schemes require the UAs to > verify certificates at some level. There's no real way around that. Read bis-07 section 22.3.2.1. The client SHOULD verify the certificate. This should be a MUST (section 22.3.2.1). >>11. What encryption algorithms are we going to allow? This is too wide >>to interpretation... you really wish to use 40-bit DES? >> > This seems like rather a side issue. It's always been assumed that > once we settled on a confidentiality solution we'd profile a secure > set of algorithms. Don't forget to do it... -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 16 21:13:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19725 for ; Sat, 16 Feb 2002 21:13:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA29523 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 21:13:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28844; Sat, 16 Feb 2002 20:57:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28815 for ; Sat, 16 Feb 2002 20:57:38 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19574 for ; Sat, 16 Feb 2002 20:57:33 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1H1vv940543; Sat, 16 Feb 2002 17:57:57 -0800 (PST) To: Ofir Arkin Cc: Michael Thomas , Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <15470.58825.137948.175526@thomasm-u1.cisco.com> <3C6EF34B.5050904@stake.com> <3C6F0B21.5030001@stake.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Feb 2002 17:57:57 -0800 In-Reply-To: Ofir Arkin's message of "Sun, 17 Feb 2002 01:45:05 +0000" Message-ID: Lines: 54 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Ofir Arkin writes: > Eric Rescorla wrote: > > > Ofir Arkin writes: > > > >>4. There is no client security, and we NEVER need to trust the client side. > >> > > Huh? No known cryptographic system does not require some trust on > > the client side, at least to protect the symmetric encryption keys. > > > Who mentioned Crypto here? If you have some other way of establishing security between a client and server pair, I'd love to hear it. > Simply, in any given system you cannot trust the client side. If you > present crypto you need to ensure the authenticity of the parties. There's a distinction between not trusting the CLIENT and not trusting the NETWORK enough to verify who a given client is. Which are you talking about? > > What overhead are you referring to with 5-30 seconds? > > > Setup time (on large scale systems), and reconnection if the session was > shutdown and needs to restart... The only time you'd see such long setup times is if your system is badly overloaded. The handshake proper only takes about .1s of CPU time (if you don't accelerate) and maybe a second of network RTTs. > You can take banking systems which use SSL v3.0 today and see what > happens with setup times when a lot of concurrent connections are opened. If you have a system which can't handle SSL and you want public key then you need to invest in new computers or do without. SSL is pretty much the lightest weight public key cryptographic system there is. > >>10. If the UA's do not verify the certificates than what are we doing > >>with TLS in the first place? > >> > > All of the public-key based key exchange schemes require the UAs to > > verify certificates at some level. There's no real way around that. > > > Read bis-07 section 22.3.2.1. The client SHOULD verify the certificate. > This should be a MUST (section 22.3.2.1). I agree. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Sat Feb 16 21:39:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20870 for ; Sat, 16 Feb 2002 21:39:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA00416 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 21:39:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29686; Sat, 16 Feb 2002 21:24:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29654 for ; Sat, 16 Feb 2002 21:24:20 -0500 (EST) Received: from services.dasecurenetworks.com (adsl-65-65-112-127.dsl.rcsntx.swbell.net [65.65.112.127]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19840 for ; Sat, 16 Feb 2002 21:24:15 -0500 (EST) Received: from dasecurenetworks.com (main1.dasecurenetworks.com [192.168.0.151] (may be forged)) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g1H1mqX19817; Sat, 16 Feb 2002 19:48:52 -0600 Message-ID: <3C6F1757.1500B76@dasecurenetworks.com> Date: Sat, 16 Feb 2002 20:37:11 -0600 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP References: <15470.57122.730272.48839@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I am only making inline comments to some of the comments included in the original messages by both parties...not answering them.... :^) Michael Thomas wrote: > 1) I have said nothing about TLS in this thread > > 2) I haven't made a proposal for IPsec because Allison said > that it won't go into bis regardless > > 3) Equating me asking that we postpone considering e2e > mechanisms with people dying tops any claims of > LAMEST I can imagine. > > 4) TLS doesn't address UDP. IPsec WG is working on > NAT traversal > Also will break firewall implementations, that have/are being developed by many well known vendors, to address SIP....would require that they also decrypt to peform pinhole allocation. Would most likely also affect SIP infrastructures already built today based on UDP if we must suddenly implement TCP based SIP (Would have actually been nice from the start). > > 5) In order for SMIME to work in a large scale, > you need a large scale PKI. Good luck. > Yep, and require that the public sign up to it, in order to facilitate "psuedo-end-to-end" confidentiality for all calls. If you can only do it for the enterprise or carrier networks but not enforce the public Internet you may as well not do it at all. > > Mike > > Rohan Mahy writes: > > Mike, > > > > comments inline... > > > > -------------------------------------------------------------------------------- > > mat@cisco.com..... > > >Eric Rescorla writes: > > > > Michael Thomas writes: > > > > > You seem into falling into a false dichotomy that > > > > > if SMIME doesn't go into bis, we are now and > > > > > forever resigned to inadequate security for > > > > > SIP. offering SMIME as an alternative at least looks forward to future certificate (PKI) capability (As would TLS/SSL)...although as I state above this would cripple firewall traversal by requiring in path firewalls the ability to decrypt and encrypt in order to pinhole media. > > > > > I don't think it's a false dichotomy. Rather, it's a pretty > > > > accurate statement of the common pattern. To whit: WG produces > > > > a document with horrible security problems. Says, "we'll fix > > > > security later". Document passes. WG doesn't fix security. > > > Agree, life in general echoes this. Look at Nimda, after Code Red....admins still didnt take heed to update security patches and were hit hard by Nimda soon after. > > > >Are you actually claiming that SIP without SMIME > > >would be "a document with horrible security > > >problems"? I sure hope not, because if you are I > > >think you need to get a grip; the current PSTN > > >does exactly this today, and the world has not > > >come to an end. > > > > That is the LAMEST argument I have ever heard regarding SIP security. > > > > - First, The PSTN has been successfully hacked on occasions too numerous > > to mention. While the world hasn't come to an end, people have > > actually DIED as a result of irresponsible parties attacking the PSTN. I > > don't know about your standards in this regard, but it is unacceptable to > > me to build a new system/protocol that mirrors such a crappy security > > model when that much is at stake. > 1. SIP is not mirroring the PSTN model, it can if we arent careful, but right now it does not. 2. Who died, just curious. 3. You are correct it is unacceptable not to address security when developing a protocol.... lets find an acceptable solution. > > - Second, I would like to be able to use SIP outside of walled garden > > networks. > > This will still require SFP's/SFA's in the real world..even at home, due to the high use of NAT (these vendors even appear to working on SFP's/SFA's). If you dont want a firewall at home you dont have to implement one (but I bet even you will have your own little walled garden). :^) > > > - Third, hacking the PSTN in a major way usually requires more physical > > access and a higher chance of getting caught than cracking in the IP > > world. It is just easier to attack a SIP network that is connected in > > any way to the Internet, than it is to attack the PSTN. > Yep. But with the implementation of SIP Proxies, SFP's/SFA's, possibly some certificate exchanges in some scenarios (public) and IPSec in other scenarios (Enterprise/Carrier), SIP can be made far more secure than the PSTN. Where can I submit a draft that covers these items if it is out of scope in the SIP WG? Shouldnt there be a SIP Security WG where these items can be addressed directly...if you bring this to IPSec the SIP will be out of scope, etc...? > > > > > > > > What is in bis now seems to have no support > > > > amongst those building UA's and since it's only a > > > > SHOULD there isn't even a penalty if you ignore > > > > it. The ones that will succeed will be the ones that implement something viable and standards based...but I dont believe it has to be built into the protocol, rather it should be built into a SIP infrastructural model. > > > > I'd be perfectly willing to have it a MUST if that would > > > make you happier. > > > > >This is a perfect example of why most security > > >protocols are complete failures. Making an Which protocols are you referring to....? IPSec is great at the network layer (where I believe this belongs for the enterprise/carrier infrastructure) and TLS/SSL is great for clients (I believe this is good for the public scenarios), depends on the network type that we are discussing..if its an enterprise stronger mechansims can be used that dont slow the signaling/media, if its a public Internet scenario then I think the upper layer prots will work, and can be implemented at the SOHO level SFP/SFA's. > > > >unworkable and bloated thing a MUST or SHOULD does > > >not change the dynamics of development, deployment > > >or system engineering. If something is useless > > >and/or harmful it will not be implemented, > > >holier-than-thou attitudes not withstanding. > > > > who are you calling holier-than-thou? > > Geeez > > > TLS is neither useless nor harmful. > > SMIME is neither useless nor harmful, although I > > would prefer MAY strength for it. > Everything has its place, agree. > > > > >If we actually want to acheive something that has > > >better security than the status quo -- and that is > > >an abysmally low threshold as far as the eye can > > >see -- it is generally prudent to actual consider > > >what is feasible in the real world and provide a > > >gradient which doesn't make it an all or nothing > > >proposition where "nothing" is the invariable > > >choice. [snide comments elided] > > > > > Let's get specific. You have made no proposals to date which both meet > > your requirements above, and are useful in the deployed Internet at large. > > Your IPsec proposal would not work through most NATs, and your other > > proposals are all more complicated that the existing SMIME in bis. > > Let me go back and do some reading.... > > > I believe that the TLS support now described in bis is the closest we are > > going to come to that kind of balance. I can implement the minimum TLS > > ciphersuite from open-source toolkits in 80k on a Palm or an IP phone, and > > I can use it from practically anywhere, even behind NATs. It is > > currently implemented on the most widely used SIP user agent today. > > That's worthy of a SHOULD in my book. > > I think I can agree that TLS would be an easier and lighter implementation...but...... Can the pinholes creation/allocation be performed by these NAT's? Firewalls? or would the SDP be encrypted requiring the firewalls to be aware of the need to decrypt? What Headers are/are not encrypted? How many SIP implementations are implementing TCP? I'd like to know more > > > The SMIME stuff in bis is heavy, but not terribly complicated. It is > > clearly suitable for use on general purpose computers, ISUP gateways, > > application servers, and high-end IP phones. It uses a practical > > key distribution model that most nerds are already familiar with. > > I think that's worthy of a MAY. > > I dont have any beef about SMIME/TLS/SSL etc, as they all use some of the same popular algorithms....but I think the difficulty lies in the myriad of firewalls present globally......and the fact that they will need to address this additional level of complexity to decrypt each packet (with embedded SDP)... So you wouldnt want to encrypt the content header.....would you? Need to catch up on the latest bs now to see where I may have erred in my responses :^) Thats all folks, Christopher A. Martin > > > 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 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sat Feb 16 22:11:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21136 for ; Sat, 16 Feb 2002 22:11:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA01755 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 22:11:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00677; Sat, 16 Feb 2002 21:49:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00573 for ; Sat, 16 Feb 2002 21:49:08 -0500 (EST) Received: from services.dasecurenetworks.com (adsl-65-65-112-127.dsl.rcsntx.swbell.net [65.65.112.127]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20942 for ; Sat, 16 Feb 2002 21:49:03 -0500 (EST) Received: from dasecurenetworks.com (main1.dasecurenetworks.com [192.168.0.151] (may be forged)) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g1H2DfX19860; Sat, 16 Feb 2002 20:13:41 -0600 Message-ID: <3C6F1D28.B865ECF7@dasecurenetworks.com> Date: Sat, 16 Feb 2002 21:02:00 -0600 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas , Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <3C6F1757.1500B76@dasecurenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit By the way, forgot to define SFP and SFA..... many of the well known firewall vendors are implementing sip firewall proxies (SFP) and sip firewall ALG's (SFA)... and tehy are also working on proprietary MIDCOM-like models, and decomposed versions of SFP/SFA's. Chris Martin wrote: > I am only making inline comments to some of the comments included in the original > messages by both parties...not answering them.... :^) > > Michael Thomas wrote: > > > 1) I have said nothing about TLS in this thread > > > > 2) I haven't made a proposal for IPsec because Allison said > > that it won't go into bis regardless > > > > > 3) Equating me asking that we postpone considering e2e > > mechanisms with people dying tops any claims of > > LAMEST I can imagine. > > > > 4) TLS doesn't address UDP. IPsec WG is working on > > NAT traversal > > > > Also will break firewall implementations, that have/are being developed by many well > known vendors, to address SIP....would require that they also decrypt to peform > pinhole allocation. Would most likely also affect SIP infrastructures already built > today based on UDP if we must suddenly implement TCP based SIP (Would have actually > been nice from the start). > > > > > 5) In order for SMIME to work in a large scale, > > you need a large scale PKI. Good luck. > > > > Yep, and require that the public sign up to it, in order to facilitate > "psuedo-end-to-end" confidentiality for all calls. If you can only do it for the > enterprise or carrier networks but not enforce the public Internet you may as well not > do it at all. > > > > > Mike > > > > Rohan Mahy writes: > > > Mike, > > > > > > comments inline... > > > > > > -------------------------------------------------------------------------------- > > > mat@cisco.com..... > > > >Eric Rescorla writes: > > > > > Michael Thomas writes: > > > > > > You seem into falling into a false dichotomy that > > > > > > if SMIME doesn't go into bis, we are now and > > > > > > forever resigned to inadequate security for > > > > > > SIP. > > offering SMIME as an alternative at least looks forward to future certificate (PKI) > capability (As would TLS/SSL)...although as I state above this would cripple firewall > traversal by requiring in path firewalls the ability to decrypt and encrypt in order > to pinhole media. > > > > > > > > I don't think it's a false dichotomy. Rather, it's a pretty > > > > > accurate statement of the common pattern. To whit: WG produces > > > > > a document with horrible security problems. Says, "we'll fix > > > > > security later". Document passes. WG doesn't fix security. > > > > > > Agree, life in general echoes this. Look at Nimda, after Code Red....admins still > didnt take heed to update security patches and were hit hard by Nimda soon after. > > > > > > >Are you actually claiming that SIP without SMIME > > > >would be "a document with horrible security > > > >problems"? I sure hope not, because if you are I > > > >think you need to get a grip; the current PSTN > > > >does exactly this today, and the world has not > > > >come to an end. > > > > > > > That is the LAMEST argument I have ever heard regarding SIP security. > > > > > > - First, The PSTN has been successfully hacked on occasions too numerous > > > to mention. While the world hasn't come to an end, people have > > > actually DIED as a result of irresponsible parties attacking the PSTN. I > > > don't know about your standards in this regard, but it is unacceptable to > > > me to build a new system/protocol that mirrors such a crappy security > > > model when that much is at stake. > > > > 1. SIP is not mirroring the PSTN model, it can if we arent careful, but right now it > does not. > 2. Who died, just curious. > 3. You are correct it is unacceptable not to address security when developing a > protocol.... lets find an acceptable solution. > > > > - Second, I would like to be able to use SIP outside of walled garden > > > networks. > > > > > This will still require SFP's/SFA's in the real world..even at home, due to the high > use of NAT (these vendors even appear to working on SFP's/SFA's). If you dont want a > firewall at home you dont have to implement one (but I bet even you will have your own > little walled garden). :^) > > > > > > - Third, hacking the PSTN in a major way usually requires more physical > > > access and a higher chance of getting caught than cracking in the IP > > > world. It is just easier to attack a SIP network that is connected in > > > any way to the Internet, than it is to attack the PSTN. > > > > Yep. But with the implementation of SIP Proxies, SFP's/SFA's, possibly some > certificate exchanges in some scenarios (public) and IPSec in other scenarios > (Enterprise/Carrier), SIP can be made far more secure than the PSTN. Where can I > submit a draft that covers these items if it is out of scope in the SIP WG? Shouldnt > there be a SIP Security WG where these items can be addressed directly...if you bring > this to IPSec the SIP will be out of scope, etc...? > > > > > > > > > > > > What is in bis now seems to have no support > > > > > amongst those building UA's and since it's only a > > > > > SHOULD there isn't even a penalty if you ignore > > > > > it. > > The ones that will succeed will be the ones that implement something viable and > standards based...but I dont believe it has to be built into the protocol, rather it > should be built into a SIP infrastructural model. > > > > > > > I'd be perfectly willing to have it a MUST if that would > > > > make you happier. > > > > > > >This is a perfect example of why most security > > > >protocols are complete failures. Making an > > Which protocols are you referring to....? > IPSec is great at the network layer (where I believe this belongs for the > enterprise/carrier infrastructure) and TLS/SSL is great for clients (I believe this is > good for the public scenarios), depends on the network type that we are discussing..if > its an enterprise stronger mechansims can be used that dont slow the signaling/media, > if its a public Internet scenario then I think the upper layer prots will work, and > can be implemented at the SOHO level SFP/SFA's. > > > > > > >unworkable and bloated thing a MUST or SHOULD does > > > >not change the dynamics of development, deployment > > > >or system engineering. If something is useless > > > >and/or harmful it will not be implemented, > > > >holier-than-thou attitudes not withstanding. > > > > > > who are you calling holier-than-thou? > > > > > Geeez > > > > > > TLS is neither useless nor harmful. > > > SMIME is neither useless nor harmful, although I > > > would prefer MAY strength for it. > > > > Everything has its place, agree. > > > > > > > >If we actually want to acheive something that has > > > >better security than the status quo -- and that is > > > >an abysmally low threshold as far as the eye can > > > >see -- it is generally prudent to actual consider > > > >what is feasible in the real world and provide a > > > >gradient which doesn't make it an all or nothing > > > >proposition where "nothing" is the invariable > > > >choice. [snide comments elided] > > > > > > > > > Let's get specific. You have made no proposals to date which both meet > > > your requirements above, and are useful in the deployed Internet at large. > > > Your IPsec proposal would not work through most NATs, and your other > > > proposals are all more complicated that the existing SMIME in bis. > > > > > Let me go back and do some reading.... > > > > > > I believe that the TLS support now described in bis is the closest we are > > > going to come to that kind of balance. I can implement the minimum TLS > > > ciphersuite from open-source toolkits in 80k on a Palm or an IP phone, and > > > I can use it from practically anywhere, even behind NATs. It is > > > currently implemented on the most widely used SIP user agent today. > > > That's worthy of a SHOULD in my book. > > > > > I think I can agree that TLS would be an easier and lighter implementation...but...... > > Can the pinholes creation/allocation be performed by these NAT's? Firewalls? or would > the SDP be encrypted requiring the firewalls to be aware of the need to decrypt? > What Headers are/are not encrypted? > How many SIP implementations are implementing TCP? > > I'd like to know more > > > > > > The SMIME stuff in bis is heavy, but not terribly complicated. It is > > > clearly suitable for use on general purpose computers, ISUP gateways, > > > application servers, and high-end IP phones. It uses a practical > > > key distribution model that most nerds are already familiar with. > > > I think that's worthy of a MAY. > > > > > I dont have any beef about SMIME/TLS/SSL etc, as they all use some of the same popular > algorithms....but I think the difficulty lies in the myriad of firewalls present > globally......and the fact that they will need to address this additional level of > complexity to decrypt each packet (with embedded SDP)... > > So you wouldnt want to encrypt the content header.....would you? > > Need to catch up on the latest bs now to see where I may have erred in my responses > :^) > Thats all folks, > Christopher A. Martin > > > > > > 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 > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sat Feb 16 22:26:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21268 for ; Sat, 16 Feb 2002 22:26:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA01992 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 22:26:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00911; Sat, 16 Feb 2002 21:56:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00880 for ; Sat, 16 Feb 2002 21:56:28 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20987 for ; Sat, 16 Feb 2002 21:56:23 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1H2uh6Y004955; Sat, 16 Feb 2002 21:56:44 -0500 (EST) Message-ID: <3C6F1BB8.878EA44B@dynamicsoft.com> Date: Sat, 16 Feb 2002 21:55:52 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: Rohan Mahy , sip@ietf.org Subject: Re: [Sip] nits/comments on bis-07 References: <3C6EDC11.5030908@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert Sparks wrote: > > These are either integrated or bugs have been entered against them. > > This was the second comment on ahhs.aa - I changed that example > to sip:completely@meaningless.uri Actually, Henning found a nugget in RFC2606 which defines the .invalid domain, so we are using something like imsomewhere@totally.invalid -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sat Feb 16 22:27:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21286 for ; Sat, 16 Feb 2002 22:27:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA02009 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 22:27:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00852; Sat, 16 Feb 2002 21:55:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00821 for ; Sat, 16 Feb 2002 21:55:10 -0500 (EST) Received: from services.dasecurenetworks.com (adsl-65-65-112-127.dsl.rcsntx.swbell.net [65.65.112.127]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20977 for ; Sat, 16 Feb 2002 21:55:05 -0500 (EST) Received: from dasecurenetworks.com (main1.dasecurenetworks.com [192.168.0.151] (may be forged)) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g1H20YX19838; Sat, 16 Feb 2002 20:00:34 -0600 Message-ID: <3C6F1A15.E8FEF2F5@dasecurenetworks.com> Date: Sat, 16 Feb 2002 20:48:53 -0600 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Ofir Arkin CC: Michael Thomas , EKR , Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <15470.58825.137948.175526@thomasm-u1.cisco.com> <3C6EF34B.5050904@stake.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Just offering support here...inline Ofir Arkin wrote: > Guys, > > This begins to look like a big piss competition and not like something > worth while. And sorry that I step into this. I am thinking it is about > time to stop the personal accusations and get into real stuff. > > Just remember that this is more for the community than it is for any of > us prestigious records... > > Couple of things I feel that are good to mention: > > 1. The PSTN today is not a good module to look at when we are talking > about security. There is no excuse to say that if the PSTN today is > having a lot of problems with its security than the something that will > replace it needs to be badly designed. I agree with Rohan on this one. > > In my opinion we tend to forget too fast the other problems with a SIP > based network (RTP Security?) Exactly....need to ensure confidentiality of the media.... > > > 2. SIP and SIP Security need to challenge the worst conditions. Lab > conditions or sometimes "best practices" are not enough. You just need > to imagine what are the worst circumstances security wise and > operational wise you can have and think if things will work (and try them). > Right, set up a high threat enironment and go to work performing the worst case threats against the implementations. > > 3. IF and IF VoIP based networks will replace the current PSTN than my > friends access to the wire will be THE number one problem with those > networks. There is still a VERY long way to go in securing the ENTIRE > infrastructure than anyone really understands (as one that was incharge > of a 4th generation wanna-be telecom company's security I am familiar > with some of those). > Ya, even when warnings and threats are evident admins still dont pony up to fix the problem. > > 4. There is no client security, and we NEVER need to trust the client side. > Yep, worst security model ever is to trust the client to be secure. > > 5. What ever encryption protocol that is using pre-shared keys is NOT > GOOD. I can mention scalability, cloning and other nice things. BTW - > have you seen a good PKI Internet wise implementation? (and please do > not say PGP and do not tell me that in a BIG network this works). > Right, latency, DNS issues that slow down cert exchanges, it'll be fixed someday soon, but you are right...today its not. > > 6. We need to understand that there are a lot of other things that needs > to be written about how SIP proxy/registar/redirect servers handle > things. Several things are so basic that it frustrates to read the > drafts. Encryption will not solve everything. Examples like who needs to > filter relay like traffic? firewalls or proxies? and other gifted things. > > BTW - who will pay the 5-30 seconds overhead with setting up the TLS > session? you? me? the designers of the protocol? sure not, it will be > the users... Do not forget that... > > 7. Wiretapping is another major thing that needs to be addressed and > this is again and again thrown under the carpet. > > 8. Section 22 really needs help. See my other posts. > > 9. Encryption is not a simple thing. Proxies and especially stateful > once, will have to deal will a lot of traffic and overheads. > > 10. If the UA's do not verify the certificates than what are we doing > with TLS in the first place? > > 11. What encryption algorithms are we going to allow? This is too wide > to interpretation... you really wish to use 40-bit DES? > May as well not :^) > > 12. AND what will you do with UDP? after everybody on the planet > preached for its usage with VoIP now SIP cannot secure it? G. > > These are some of the points. There are a lot more... > > Now, are we going to start thinking on the correct direction again, or > are we keeping smearing each other? > Ditto.... > > Michael Thomas wrote: > > > Eric Rescorla writes: > > > Michael Thomas writes: > > > > 5) In order for SMIME to work in a large scale, > > > > you need a large scale PKI. Good luck. > > > This simply is not true. S/MIME has shared key modes. Any form of > > > key management that's practical for digest or IPsec is equally > > > practical for S/MIME. > > > > Uh, I said large scale. As in, anything that > > might take the place of the current PSTN. > > > > 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 > > > > -- > Ofir Arkin > Managing Security Architect > @stake, Limited. > http://www.atstake.com > email: > ofir@stake.com > Tel: > +44 (0) 207 495 7002 > Fax: > +44 (0) 207 495 7062 > Mobile: +44 (0) 779 630 8632 > > ----------------------------- > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, re transmission, 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 any computer. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sat Feb 16 22:30:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21666 for ; Sat, 16 Feb 2002 22:30:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA02318 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 22:30:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01552; Sat, 16 Feb 2002 22:04:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01524 for ; Sat, 16 Feb 2002 22:04:45 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21073 for ; Sat, 16 Feb 2002 22:04:40 -0500 (EST) Received: (qmail 8276 invoked from network); 17 Feb 2002 03:08:05 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 17 Feb 2002 03:08:05 -0000 Received: from stake.com (unknown [10.1.64.73]) by cam-relay.atstake.com (Postfix) with SMTP id 7BE1122817; Sat, 16 Feb 2002 22:03:04 -0500 (EST) Message-ID: <3C6F1E7A.9010602@stake.com> Date: Sun, 17 Feb 2002 03:07:38 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: EKR Cc: Michael Thomas , Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <15470.58825.137948.175526@thomasm-u1.cisco.com> <3C6EF34B.5050904@stake.com> <3C6F0B21.5030001@stake.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric, > If you have some other way of establishing security between a client > and server pair, I'd love to hear it. Maybe I should try to explain this one differently: Until you establish some kind of trust based on REAL things (like the usage of a good crypto scheme with good authentication of the two end systems - TLS? :P) you cannot trust the end-point hence the client. > There's a distinction between not trusting the CLIENT and not trusting > the NETWORK enough to verify who a given client is. Which are you talking > about? With security you do not trust nothing. Hope this clarifies what I say here, which I believe you say as well. -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Feb 16 23:15:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22617 for ; Sat, 16 Feb 2002 23:15:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA03772 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 23:15:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02906; Sat, 16 Feb 2002 22:53:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02875 for ; Sat, 16 Feb 2002 22:53:10 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22439 for ; Sat, 16 Feb 2002 22:53:05 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1H3qWE27854; Sat, 16 Feb 2002 19:52:32 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX25332; Sat, 16 Feb 2002 19:52:03 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA28546; Sat, 16 Feb 2002 19:52:31 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15471.10494.915214.197702@thomasm-u1.cisco.com> Date: Sat, 16 Feb 2002 19:52:30 -0800 (PST) To: cmartin@dasecurenetworks.com Cc: Michael Thomas , Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP In-Reply-To: <3C6F1757.1500B76@dasecurenetworks.com> References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <3C6F1757.1500B76@dasecurenetworks.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Chris Martin writes: > Michael Thomas wrote: > > > 1) I have said nothing about TLS in this thread > > > > 2) I haven't made a proposal for IPsec because Allison said > > that it won't go into bis regardless > > > > > 3) Equating me asking that we postpone considering e2e > > mechanisms with people dying tops any claims of > > LAMEST I can imagine. > > > > 4) TLS doesn't address UDP. IPsec WG is working on > > NAT traversal > > > > Also will break firewall implementations, that have/are being developed by many well > known vendors, to address SIP....would require that they also decrypt to peform > pinhole allocation. Would most likely also affect SIP infrastructures already built > today based on UDP if we must suddenly implement TCP based SIP (Would have actually > been nice from the start). I can't parse what you're commenting on. 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 daemon@optimus.ietf.org Sat Feb 16 23:20:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22652 for ; Sat, 16 Feb 2002 23:20:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA03854 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 23:20:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02824; Sat, 16 Feb 2002 22:49:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02791 for ; Sat, 16 Feb 2002 22:49:26 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22415 for ; Sat, 16 Feb 2002 22:49:21 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1H3meZ17858; Sat, 16 Feb 2002 19:48:40 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX25316; Sat, 16 Feb 2002 19:48:20 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA28543; Sat, 16 Feb 2002 19:48:47 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15471.10271.471629.721017@thomasm-u1.cisco.com> Date: Sat, 16 Feb 2002 19:48:47 -0800 (PST) To: EKR Cc: Michael Thomas , "Jari Arkko" , "Peterson, Jon" , "Juha Heinanen" , "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> <15470.59836.690123.189355@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric Rescorla writes: > Michael Thomas writes: > > Eric Rescorla writes: > > > I don't think the issues of Digest, Enhanced Digest and S/MIME > > > are separable. In my view, they all serve roughly the same > > > purpose, except that S/MIME is rather more flexible. > > > > In fact, the way the draft is written, this is > > incorrect. > As I tried to make clear in my original message, I'm not talking about > S/MIME as it's currently wedged into SIP, which I agree could use some > work, but about S/MIME proper. Well, right now that's what's in the draft which is rapidly headed for last call. > In my view, SIP needs some sort of message integrity and > confidentiality protocol. The choices on the table are invent > something new or hijack something old. I'd rather do the latter > if we can get away with it. The prime candidate there is S/MIME. In fact, my draft even used SMIME as an example. For some things it may be appropriate, especially for X.509 based things. However, dragging in SMIME just for symmetric keying seems likely to be overkill, and probably too heavy for people to justify making the jump from digest. Of course, the *real* problem here is that it was thrown into the draft without ever researching these considerations. > > > Indeed, the right thing here might be to do > > something that makes sense for SIP rather than > > relying on things which were designed for other > > requirements. > I don't understand what features of this new protocol you > propose to design are going to make it substantially more > lightweight than S/MIME. Do tell. Trivial. Requirement #1: no ASN.1 :-) 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 daemon@optimus.ietf.org Sat Feb 16 23:37:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23175 for ; Sat, 16 Feb 2002 23:37:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA04560 for sip-archive@odin.ietf.org; Sat, 16 Feb 2002 23:37:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA03833; Sat, 16 Feb 2002 23:17:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA03802 for ; Sat, 16 Feb 2002 23:17:12 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22633 for ; Sat, 16 Feb 2002 23:17:07 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1H44A301511; Sat, 16 Feb 2002 22:04:11 -0600 Message-ID: <3C6F2BBA.80208@dynamicsoft.com> Date: Sat, 16 Feb 2002 22:04:10 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Jo Hornsby CC: sip@ietf.org Subject: Re: [Sip] Comments on bis-06 References: <45730E094814E44488F789C1CDED27AE01122526@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Finally got all these incorporated. For the 500 vs 4xx below - as far as I know, the choice was arbitrary. Jonathan points out that 500 makes a little more sense than 4xx since a 5xx class response means "This request may succeed if you send it again at a later time". The current text still says 500. RjS Jo Hornsby wrote: > Okay, so here are my (incomplete) comments on bis-06; > like all the others, I wanted to get them out now > so that they might actually be useful bearing-in-mind > the Monday Deadline. > > As a general comment, every so-often, a paragraph > seems to be inexplicably all bunched up line-wise; > f.ex.: 1942 - 1944, 1982 - 1990, 2060 - 2064. > (Obviously, the only concern here is that it > offends my aesthetic sensibilities.) > > ( These are all comments based on the PDF: ) > * 619: I find "A call stateful proxy is always > stateful" just ever-so-slightly confusing. > Maybe it would be helpful to add a paranthetical > "transaction", a la "A call stateful proxy is > always [transaction] stateful"? > * 656: Just a corner case, but would it be better > to say something like: "A proxy that receives > all request from a client, even though it _may > not be_ the server resolved by the Request-URI"? > * 676: Should probably say "...the client to > contact an alternate set of URIs" for true > correctness. > * 693: Shouldn't 6xx halt a sequential search, > too? > * 711: Random Blank Line. > * 1040: I'd rather see something like "A UAC MUST > insert a Max-Forwards header field into each request > it originates. The value needs to be large > enough to ensure that the request can traverse > a reasonable number of proxies, and in the > absence of local / network policy, or otherwise, > SHOULD be 70". (Just slightly concerned at > the mandatory nature of such a magically random > figure.) > * 1059: Section Link appears to be broken. > * 1063: I think this conflicts with 1832 (and > List Discussion, as I recall). > * 1152: Isn't it possible for other types of > event; e.g., no DNS records, ICMP? > * 1177: Is the intention here really just > "until a server responds"? I would have thought > we were looking for a 2xx / 6xx. > * 1674: Shouldn't this be step 7? > * 1966: Random Blank Line. > * 1985: Small Point, but why a 500? I would have > thought that this would be treated as a client > error, and thus 4xx? > * 2251: Again with the 500 -> 4xx. > * 2282: s/unbound/unbounded/ > * 2328: Spurious Space Beginning Line. > > Finally, I feel compelled to do the atypical > syncophancy bit. Unfortunately, due to some > poor time management (and new seasons of Buffy > Angel, of course), I never got around to a > proper read of bis-05. So bis-06 is something > of a revelation. And it really is such an > improvement. > > Well, to be honest, before reading this, I was > secure in my employment before, such that a > Lego Desk seemed pretty inevitable; but now > things are so well explained, I reckon you've > made it such that any old Joe could walk in off > the street and write a Proxy or whathaveyou. > So thanks for that. > > Ah well, I guess it's back to TAPI. Damnit. > > > - Jo. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sun Feb 17 00:15:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23702 for ; Sun, 17 Feb 2002 00:15:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA06159 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 00:15:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04744; Sat, 16 Feb 2002 23:44:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04714 for ; Sat, 16 Feb 2002 23:44:15 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23246 for ; Sat, 16 Feb 2002 23:44:08 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1H4iQY40708; Sat, 16 Feb 2002 20:44:26 -0800 (PST) To: Michael Thomas Cc: "Jari Arkko" , "Peterson, Jon" , "Juha Heinanen" , "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> <15470.59836.690123.189355@thomasm-u1.cisco.com> <15471.10271.471629.721017@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Feb 2002 20:44:26 -0800 In-Reply-To: Michael Thomas's message of "Sat, 16 Feb 2002 19:48:47 -0800 (PST)" Message-ID: Lines: 47 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > Eric Rescorla writes: > > In my view, SIP needs some sort of message integrity and > > confidentiality protocol. The choices on the table are invent > > something new or hijack something old. I'd rather do the latter > > if we can get away with it. The prime candidate there is S/MIME. > > In fact, my draft even used SMIME as an example. > For some things it may be appropriate, especially > for X.509 based things. However, dragging in SMIME > just for symmetric keying seems likely to be > overkill, and probably too heavy for people to > justify making the jump from digest. What I was trying to argue earlier was twofold: (1) A minimal S/MIME implementation that does essentially what digest does would be of comparable size to digest. (2) A message security protocol that does what we'll eventually want will be of comparable size to S/MIME. Thus, we might as well bite the S/MIME bullet now. > > I don't understand what features of this new protocol you > > propose to design are going to make it substantially more > > lightweight than S/MIME. Do tell. > > Trivial. > > Requirement #1: no ASN.1 > > :-) I trust the smiley here means that you're not serious. The amount of code required to implement CMS EncryptedData and AuthenticatedData (which is all that would be required to replace digest) is quite small. As I understand it, you have two primary objections to S/MIME: (1) difficulty of producing a completed specification in time. (2) code size and complexity. I'm sensitive to argument (1) but I don't think that the code size and complexity argument holds up under examination. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Sun Feb 17 00:28:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23828 for ; Sun, 17 Feb 2002 00:28:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA06515 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 00:28:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04944; Sat, 16 Feb 2002 23:49:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04919 for ; Sat, 16 Feb 2002 23:49:45 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23367 for ; Sat, 16 Feb 2002 23:49:40 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1H4o26Y004995 for ; Sat, 16 Feb 2002 23:50:02 -0500 (EST) Message-ID: <3C6F3649.675AB6A7@dynamicsoft.com> Date: Sat, 16 Feb 2002 23:49:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] pre-release of 100rel available Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I have finished excising the 100rel components of bis-07 into a separate document. This turned out to be easier than I anticipated, and the resulting document is about 95% identical word-for-word to the text that was in bis previously. Most of the changes help the standalone document flow better. There were no changes in any normative (MUST/MAY/SHOULD) behavior from bis-07. I will be submitting draft-ietf-sip-100rel-05.txt on Tuesday, in time for the IESG last call to be issued on it. However, I have created a "pre-release", which you can look at now: http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-100rel-04.9.txt I will be doing another pass on this for minor stuff, typos and so on, before updating to -05 and submitting. If you have any comments on this document, please let me know. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sun Feb 17 01:10:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24170 for ; Sun, 17 Feb 2002 01:10:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA14656 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 01:10:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07327; Sun, 17 Feb 2002 00:37:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07221 for ; Sun, 17 Feb 2002 00:37:41 -0500 (EST) Received: from services.dasecurenetworks.com (adsl-65-65-112-127.dsl.rcsntx.swbell.net [65.65.112.127]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23958 for ; Sun, 17 Feb 2002 00:37:37 -0500 (EST) Received: from dasecurenetworks.com (main1.dasecurenetworks.com [192.168.0.151] (may be forged)) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g1H52FX20083; Sat, 16 Feb 2002 23:02:15 -0600 Message-ID: <3C6F44AA.B645E0B0@dasecurenetworks.com> Date: Sat, 16 Feb 2002 23:50:34 -0600 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <3C6F1757.1500B76@dasecurenetworks.com> <15471.10494.915214.197702@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sorry, To clarify, what I was trying to say was that the introduction of any of the crypto methods TLS/SSL/SMIME on any of the pertinent header fields can affect the way that firewall solutions that are being developed today by many of the major vendors, as well as MIDCOM-like vendors..will be broken, due to the fac that the implementation will be required to decrypt portions of the message (assuming that the message body is to be encrypted, which may contain SDP). These implementations parse the headers for such items as contact, call-id, SDP info (in order to open pinholes for media), to name a few. Michael Thomas wrote: > Chris Martin writes: > > Michael Thomas wrote: > > > > > 1) I have said nothing about TLS in this thread > > > > > > 2) I haven't made a proposal for IPsec because Allison said > > > that it won't go into bis regardless > > > > > > > > 3) Equating me asking that we postpone considering e2e > > > mechanisms with people dying tops any claims of > > > LAMEST I can imagine. > > > > > > 4) TLS doesn't address UDP. IPsec WG is working on > > > NAT traversal > > > > > > > Also will break firewall implementations, that have/are being developed by many well > > known vendors, to address SIP....would require that they also decrypt to peform > > pinhole allocation. Would most likely also affect SIP infrastructures already built > > today based on UDP if we must suddenly implement TCP based SIP (Would have actually > > been nice from the start). > > I can't parse what you're commenting on. > > 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 daemon@optimus.ietf.org Sun Feb 17 01:13:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24200 for ; Sun, 17 Feb 2002 01:13:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA16373 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 01:13:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06558; Sun, 17 Feb 2002 00:29:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06527 for ; Sun, 17 Feb 2002 00:29:45 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23843 for ; Sun, 17 Feb 2002 00:29:42 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1H5U06Y005013; Sun, 17 Feb 2002 00:30:00 -0500 (EST) Message-ID: <3C6F3FA6.E89701A@dynamicsoft.com> Date: Sun, 17 Feb 2002 00:29:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vidhi.rastogi@wipro.com, sip@ietf.org Subject: Re: [Sip] Re: To tag in 101-199 responses [bis07] References: <3C638261.B38B8A44@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline. Jonathan Rosenberg wrote: > > VIDHI RASTOGI wrote: > > > > Hi, > > I have a question regarding the To tags in the 1xx response.. > > > > Sec 8.2.6.2 of bis-07 states that > > > > "the UAS MUST add a tag to the To field in the response > > (with the exception of the 100 (Trying) response, in which a tag > MAY > > be present)...." > > > > This would mean that a provisional response (say 180) for INVITE > request > > would always establish an early dialog. > > But according to "Sec10.2.2.1" of the same draft, > > > > " The early dialog will only be needed if the UAC needs to send a > > request to its peer within the dialog before the initial INVITE > > transaction completes. This will be the case for all reliable > > provisional responses, which require transmission of PRACK." > > > > This section implies that an early dialog is not mandatory. But the To > > Tag > > present in the 180 response would always result in an early dialog. > > The text in 10.2.2.1 is saying that even though the tag is there, the > UAC need not construct the actual early dialog. Doing that would only be > needed if it had to send a request or some other such thing. > > However, on pondering this further, it occurs to me that we could be in > trouble down the road if the UAC doesn't always build the early dialog. > The reason is that the UAS might send a COMET/UPDATE eventually. If it > sends a 18x first, with a tag, but the UAC ignores the tag and doesn't > build a dialog, and then the UAS sends a COMET/UPDATE, that will not > properly match any existing dialog at the caller. > > The solution is to either (1) mdante the UAC to build an early dialog > for any tags, in which case we probably should relax the constraint on > tags in provisionals, or (2) allow for a COMET/UPDATE to create a > dialog, much like a NOTIFY can for SUBSCRIBE. In the case of (2), this > would be handled entirely within the specification of COMET/UPDATE. > > I'll need to ponder that one some more. After pondering, I decided (2) was the best approach. The UPDATE and PRACK specs have text mandated creation of early dialogs on 1xx when those extensions are used. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sun Feb 17 01:13:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24217 for ; Sun, 17 Feb 2002 01:13:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA16416 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 01:13:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07043; Sun, 17 Feb 2002 00:32:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06985 for ; Sun, 17 Feb 2002 00:32:11 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23908 for ; Sun, 17 Feb 2002 00:32:08 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1H5J2301636; Sat, 16 Feb 2002 23:19:02 -0600 Message-ID: <3C6F3D46.9000802@dynamicsoft.com> Date: Sat, 16 Feb 2002 23:19:02 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: ysong@telcordia.com, "gonzalo.camarillo" , Jonathan Rosenberg CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] Comments on bis-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ysong@telcordia.com wrote: > Hi, > > Few comments on bis-06. > > Section 8.2, UAS behavior: there is no mention on sending responses. It'd > be helpful to point to the sections for sending responses. Would it be > Section 17.2.4 (transaction layer) or 19.2.2 (transport layer)? For > requests, it is clear that UAC Core keeps track of the list of servers to > try for sending requests. For responses, it is not clear to me which layer > keeps the list. Normally a UA core would hand the response to the server transaction that passed it the request. Section 8.3 talks about cases where a UA core might not want to do that. We'll work to clarify this. > > Line 1931: Should the reference for 3xx response processing here be Section > 8.1.4.5 instead of Section 13.2.2? Yes - fixed. > > Line 1985: Shouldn't the "request out of order" error be 400 instead of > 500? As far as I know 500 was chosen arbitrarily. Jonathan notes that 500 makes sense given that the request would succeed if it was sent again as is at a later time. > > Line 2030: It states that Accept header MAY be present in the INVITE. > However, in Table 2, Header summary, Accept header in INVITE is m* meaning > the header SHOULD be sent. Which is correct? Similar comment applies for > Accept header in 2xx response (Line 2182). I think MAY is correct. We'll review and make sure the text and table are consistant > > Line 2337: It states that (when the UAS responses to BYE), "The UAS MUST > still respond to any pending requests received for that dialog, (which can > only be an INVITE)." Any pending request can be OPTIONS as well in addition > to INVITE although unlikely. I'll let Gonzalo comment on this one. > > Line 3063: It states "Eventually, the server transaction decides to send a > final response. For unreliable transports, that response is retransmitted > periodically, and for reliable transports, its sent once." I don't think > this is true for 2xx responses to INVITE over reliable transport. It is true from the server transaction's perspective. Retransmission of 2xx-INVITE is done by the TU. This is pointed out early in section 17. > > Section 17.1.3, Matching Responses to Client Transactions: This describes > the mechanism using branch id in Via. Don't we also need a description used > in the earlier versions for backwards compatibility, as Section 17.2.3 > does? No - the response will contain the id this client transaction added to the request. > > Section 17.2.4: Handling Transport Errors: I think this section describes > transport error handling for sending responses for responses to non-INVITE > and non-2xx responses to INVITE. I am not sure where the transport error > handling is done for 2xx responses to INVITE. If the first attempt to send > a 2xx response to INVITE encounters transport errors, is it Transport Layer > that is to try the next server or UAS Core that is to try the next one? If > it is the UAS core, when the 2xx response is sent to the next server, is > the timer reset starting at T1? Jonathan - could you comment on this? > > On Response code 482 Loop Detected: I recall a discussion in the list a > while back on using "482 Request Merged" or something like that. Is there a > reason why we are using 482 "Loop Detected" still? History - the reason phrase just hasn't been updated. I'll start a discussion on updating it. But remember that the reason phrase is just informational. 482 Eat Spam! means the same thing as 482 Request Merged. RjS > > Thanks, > YoungSun > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/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 daemon@optimus.ietf.org Sun Feb 17 01:40:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24373 for ; Sun, 17 Feb 2002 01:40:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA18641 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 01:40:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07631; Sun, 17 Feb 2002 00:53:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07604 for ; Sun, 17 Feb 2002 00:53:44 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24048 for ; Sun, 17 Feb 2002 00:53:41 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1H5rw6Y005020; Sun, 17 Feb 2002 00:54:01 -0500 (EST) Message-ID: <3C6F4545.E216CC4F@dynamicsoft.com> Date: Sun, 17 Feb 2002 00:53:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cmartin@dasecurenetworks.com CC: Michael Thomas , Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP References: <3C6F44AA.B645E0B0@dasecurenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think this problem is arguably a feature. If I am encrypting my SDP information so that only the desired recipient will get it, then the *point* is that intermediaries can't look at the information and modify it. So, if I try to make a secure call and hear nothing, or get a failure from one of the proxies, I will know that a secure call is not possible in this configuration. I can then try again without such security, or do something else (change providers, say...) as appropriate. -Jonathan R. Chris Martin wrote: > > Sorry, > To clarify, what I was trying to say was that the introduction of any of > the crypto > methods TLS/SSL/SMIME on any of the pertinent header fields can affect > the way that > firewall solutions that are being developed today by many of the major > vendors, as well as > MIDCOM-like vendors..will be broken, due to the fac that the > implementation will be > required to decrypt portions of the message (assuming that the message > body is to be > encrypted, which may contain SDP). These implementations parse the > headers for such > items as contact, call-id, SDP info (in order to open pinholes for > media), to name a few. > > Michael Thomas wrote: > > > Chris Martin writes: > > > Michael Thomas wrote: > > > > > > > 1) I have said nothing about TLS in this thread > > > > > > > > 2) I haven't made a proposal for IPsec because Allison said > > > > that it won't go into bis regardless > > > > > > > > > > > 3) Equating me asking that we postpone considering e2e > > > > mechanisms with people dying tops any claims of > > > > LAMEST I can imagine. > > > > > > > > 4) TLS doesn't address UDP. IPsec WG is working on > > > > NAT traversal > > > > > > > > > > Also will break firewall implementations, that have/are being > developed by many well > > > known vendors, to address SIP....would require that they also > decrypt to peform > > > pinhole allocation. Would most likely also affect SIP > infrastructures already built > > > today based on UDP if we must suddenly implement TCP based SIP > (Would have actually > > > been nice from the start). > > > > I can't parse what you're commenting on. > > > > 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 -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sun Feb 17 02:55:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02719 for ; Sun, 17 Feb 2002 02:55:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20902 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 02:55:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA19907; Sun, 17 Feb 2002 02:19:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA19876 for ; Sun, 17 Feb 2002 02:19:16 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02449 for ; Sun, 17 Feb 2002 02:19:14 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1H7IPZ11198; Sat, 16 Feb 2002 23:18:25 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACM56834; Sat, 16 Feb 2002 23:18:13 -0800 (PST) Date: Sat, 16 Feb 2002 23:16:56 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org, Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] re: SMIME in SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Mike, >1) I have said nothing about TLS in this thread > >2) I haven't made a proposal for IPsec because Allison said > that it won't go into bis regardless fine. >3) Equating me asking that we postpone considering e2e > mechanisms with people dying tops any claims of > LAMEST I can imagine. In the message I replied to, you implied that the PSTN model of security was sufficient for SIP. You didn't concretely propose anything. This is in fact the crux of the problem. >4) TLS doesn't address UDP. IPsec WG is working on > NAT traversal UDP doesn't work well in the Internet at large anyway. It's support is still around for backwards compatibility, and for use in specialized layer2 domains where RTT is expensive; these domains usually run what amounts to a private network. IPsec is probably a good thing in those networks, and the spec allows for that. 5) In order for SMIME to work in a large scale, you need a large scale PKI. Good luck. I'd rather that it work in a few identifiable scenarios like the ones that I described. If you want to propose something concrete for large scale use please go for it. In the interim, we have four choices regarding SMIME AFAIK: Make it a MUST: probably not very popular ;-) Leave as a SHOULD: leave the draft as is Make it a MAY: a proposal echoed by many Postpone Last Call: extremely unpopular among implementers Your arguments against SMIME seem to be: a) slammed in at the last moment b) not necessarily a high priority to the SIP WG c) too big to implement on a low-end IP phone/gateway d) uses PKI e) requires ASN.1 - c) through e) are not showstoppers for the uses I described. - while b) is certainly true, getting bis to the IESG certainly DOES appear to be a high priority and these appear to be linked by the IESG. If you don't like that linkage, you can/should go yell at them. - a) is absolutely true, but i haven't heard any concrete objection of the form "If you send this message under these circumstances the UA breaks". I'd like to concentrate on this type of analysis. 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 daemon@optimus.ietf.org Sun Feb 17 03:03:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02841 for ; Sun, 17 Feb 2002 03:03:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA21554 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 03:03:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20068; Sun, 17 Feb 2002 02:26:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20036 for ; Sun, 17 Feb 2002 02:26:10 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02480 for ; Sun, 17 Feb 2002 02:26:08 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1H7PdE04294 for ; Sat, 16 Feb 2002 23:25:39 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACM56849; Sat, 16 Feb 2002 23:25:39 -0800 (PST) Date: Sat, 16 Feb 2002 23:24:22 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] yet more bis-07 nits Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org hi, more nits, comments, and proposed clarifications from the pdf version of bis-07: section 16 through section 21. again, please just send comments on the stuff that doesn't make sense. important stuff marked with ** thanks, -rohan 2464: bad section reference 2643: s/that element/the next element/ 2645: ...MUST resolve to this element. what about proxy farms or clusters? ** 2723: append: "as described in step 6" 2738: s/the element/this proxy/ 2806: s/dialogs/of dialogs/ 2856: s/to to/to/ 2991: s/sends to/rewrites the Request-URI with/ 3011: s/obtained by/obtained, by/ (really confusing otherwise) 3093: s/example of/example in/ 3102: s/to that server/to the appropriate server/ 3104: s/out any/out any response/ 3132: s/request/requests/ 3229-30: normative language like NOT RECOMMENED shouldn't hyphenate 3231: s/that the/the/ pages 90 and 92: (figures 7 and 8) the Figure X:blah blah overlaps the footer 3604: s/UA/UAs/ 3744-5: s/the SIP standard today/this document/ 3846-50: now that Basic is deprecated to we still need this Paragraph? *** 3866-7: make language consistent with the "single header, mutiple values" rule 3868: SHOULD -> MUST ?? 3878: s/that servers/that SIP servers/ 3932: s/These certificates are/The keying material associated with these certificates is/ 3942: s/limitated/limited/ 3970: s?a S/MIME?an S/MIME? 3995: non normative ref to SSH maybe? 4056: s/Proxy-Authorization/Proxy-Authenticate/ 4057: append: "defined in this document" Section 21.4 general: add language reminding implementors of comparison rules in SIP (compress/expand whitespace, case insensitivity, equivalence between short and long header forms, etc...) ** 5440: have codes x80 upwards... what about some x20 response codes? 5585: s/logged in such/logged in in such/ 5649-52: inconsistent with line 1226 5695: append "Warning reason codes are listed in Section 24.45" 5699: nuke first sentence 6366: somehow "IEEE Communications Magazine" got lost from bis-06 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 17 05:21:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03985 for ; Sun, 17 Feb 2002 05:21:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25881 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 05:21:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25076; Sun, 17 Feb 2002 04:53:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25045 for ; Sun, 17 Feb 2002 04:53:16 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03769 for ; Sun, 17 Feb 2002 04:53:12 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1H9qvio024463; Sun, 17 Feb 2002 11:52:58 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15471.32121.779787.153989@harjus.eng.song.fi> Date: Sun, 17 Feb 2002 11:52:57 +0200 To: Michael Thomas Cc: EKR , "Jari Arkko" , "Peterson, Jon" , "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: <15470.59836.690123.189355@thomasm-u1.cisco.com> References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> <15470.59836.690123.189355@thomasm-u1.cisco.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas writes: > Indeed, the right thing here might be to do > something that makes sense for SIP rather than > relying on things which were designed for other > requirements. Given how important rendezvous > protocols are in real life, I think it's far more > important to get it right rather than just jamming > something into the spec at the last minute and > hoping that it works. i fully agree with this. we should not put anything into bis that the industry has not had time to carefully consider and form a consensus. we can't afford a third security round. so it is better to publish bis now as experimental including only what is currently widely available, i.e., digest and tls, and then keep on working on consensus for better security solutions. -- 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 daemon@optimus.ietf.org Sun Feb 17 08:56:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05838 for ; Sun, 17 Feb 2002 08:56:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA09401 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 08:56:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08441; Sun, 17 Feb 2002 08:26:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08410 for ; Sun, 17 Feb 2002 08:26:39 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05598 for ; Sun, 17 Feb 2002 08:26:35 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1HDPjhM008613; Sun, 17 Feb 2002 14:25:45 +0100 (MET) Received: from ericsson.com (ppp16.lmf.ericsson.se [131.160.102.16]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1HDPgr6000966; Sun, 17 Feb 2002 15:25:42 +0200 (EET) Message-ID: <3C6FAF91.3F27DEE@ericsson.com> Date: Sun, 17 Feb 2002 15:26:41 +0200 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org, roahn@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? References: <011b01c1b65c$5b579f00$b3036e3f@dfw.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Dean: I also agree with your proposals. I think we should take your document as a WG item. Definitely needed by 3GPP. /Miguel Dean Willis wrote: > > The document draft-willis-sip-path-01.txt introduces the Path extension header suggested by 3GPP in the Garcia 3GPP requirements draft in SIPPING. > > The basic requirements being met are to 1) allow a UA to REGISTER a contact which requires traversing a sequence of proxies on future messages between the registrar and the UA, with that sequence dynamically discovered during the REGISTER, and 2) allow a UA to discover from a REGISTER response a sequence of proxies between it and a known proxy offering outbound services for that UA. > > > The approach taken in the draft generalizes the 3GPP requirements by allowing the sequences to be asymetric-- for example, the inbound and outbound sequences might traverse different proxies, or there might only be a sequence in one direction (A firewall proxy sits between UA and its registrar, but UA does not use the registrar for outbound services). > > I'd like to poll for three things: > > 1) Do we want to address the requirements raised by 3GPP? > > 2) Do we have a general consensus on something like the PATH header as an appopriate mechanism? > > 3) Is draft-willis-sip-path-01.txt a reasonable baseline document? > > If we have consensus on all three accounts, I propose to accept draft-willis-sip-path-01.txt as a working group document, and pursue future revisions as draft-ietf-sip.xx. > > If not, then please make a counterproposal. > > Opinions, please. > > -- > Dean -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 17 08:56:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05855 for ; Sun, 17 Feb 2002 08:56:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA09415 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 08:56:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08938; Sun, 17 Feb 2002 08:32:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08906 for ; Sun, 17 Feb 2002 08:32:31 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05650 for ; Sun, 17 Feb 2002 08:32:27 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id g1HDVoU06979; Sun, 17 Feb 2002 14:31:50 +0100 Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.1/8.12.1) with ESMTP id g1HDVnkv008635; Sun, 17 Feb 2002 14:31:50 +0100 (MET) Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id <18JNF3JG>; Sun, 17 Feb 2002 14:31:48 +0100 Message-ID: From: Brazier Lachlan To: "'Jonathan Rosenberg '" Cc: "''sip@ietf.org' '" Subject: AW: [Sip] CSeq question? Date: Sun, 17 Feb 2002 14:31:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B7B7.72B61BC0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B7B7.72B61BC0 Content-Type: text/plain Hello, I used to be the opinion, that the Method name in the CSeq header was needed to say: "This request XXX is the request with number Y" Example: MYREQUEST ... CSeq: 2 MYREQUEST would mean this is my second request of the kind MYREQUEST. I haven't read all of bis07 (bis05 - 05 either), but I so far I didn't find a reason for the method name in the CSeq Header. It looks pretty redundant to the method name in the request line. If there is a reason, could you point me there. Concerning the paragraph you mention below (12.2.1.1), maybe the phrase _All_ Requests within a dialog _(except of ACK)_ MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction. would be better. ( I assume, when you are allowed to send a CANCEL, you are not in a dialog ?!, is this right? ) Thanks for the confirmation Lachlan -----Originalnachricht----- Von: Jonathan Rosenberg An: Brazier Lachlan Cc: 'sip@ietf.org' Gesendet: 15.02.02 22:10 Betreff: Re: [Sip] CSeq question? Brazier Lachlan wrote: > > Hello, > > probably awnsered long ago, but I couldn't find it :-( > > The reason I ask is, that it wasn't clear to me, if the increasing of > the > CSeq value in a dialog is bound to a request class (INVITE, BYE, > MYREQUEST, > etc.) or to requests in general. All requests sent from A to B within a dialog, independent of the method, have increasing CSeq, by value of 1, with two exceptions: 1. ACK for an INVITE has the same cseq as the invite 2. cancel for a request has the same cseq as request So: INVITE (cseq: 1) ----> 200 (1)<-------- ACK (1)---------> INFO (2)---------> 200 OK (2)<------- BYE (3) ---------> 200 OK (3)<------ Can you point me to text in bis that would lead you to believe it was per method? I think the text is pretty clear: From 12.2.1.1: The Call-ID of the request MUST be set to the Call-ID of the dialog. Requests within a dialog MUST 1872 contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in 1873 each direction. Therefore, if the local sequence number is not empty, the value of the local sequence number 1874 MUST be incremented by one, and this value MUST placed into the Cseq header. If the local sequence 1875 number is empty, an initial value MUST be chosen using the guidelines of Section 8.1.1.5. The method field 1876 in the Cseq header MUST match the method of the request. 1877 -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com ------_=_NextPart_001_01C1B7B7.72B61BC0 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTMuMTIiPg0KPFRJVExFPkFXOiBbU2lw XSBDU2VxIHF1ZXN0aW9uPzwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0la RT0yPkhlbGxvLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkkgdXNlZCB0byBiZSB0 aGUgb3BpbmlvbiwgdGhhdCB0aGUgTWV0aG9kIG5hbWUgaW4gdGhlIENTZXEgaGVhZGVyIHdhcyBu ZWVkZWQgdG8gc2F5OiAmcXVvdDtUaGlzIHJlcXVlc3QgWFhYIGlzIHRoZSByZXF1ZXN0IHdpdGgg bnVtYmVyIFkmcXVvdDs8L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+RXhhbXBsZTo8L0ZP TlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5NWVJFUVVFU1QgLi4uPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj5DU2VxOiAyIE1ZUkVRVUVTVDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0la RT0yPndvdWxkIG1lYW4gdGhpcyBpcyBteSBzZWNvbmQgcmVxdWVzdCBvZiB0aGUga2luZCBNWVJF UVVFU1QuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SSBoYXZlbid0IHJlYWQgYWxs IG9mIGJpczA3IChiaXMwNSAtIDA1IGVpdGhlciksIGJ1dCBJIHNvIGZhciBJIGRpZG4ndCBmaW5k IGEgcmVhc29uIGZvciB0aGUgbWV0aG9kIG5hbWUgaW4gdGhlIENTZXEgSGVhZGVyLiBJdCBsb29r cyBwcmV0dHkgcmVkdW5kYW50IHRvIHRoZSBtZXRob2QgbmFtZSBpbiB0aGUgcmVxdWVzdCBsaW5l LjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JZiB0aGVyZSBpcyBhIHJlYXNvbiwgY291 bGQgeW91IHBvaW50IG1lIHRoZXJlLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkNv bmNlcm5pbmcgdGhlIHBhcmFncmFwaCB5b3UgbWVudGlvbiBiZWxvdyAoMTIuMi4xLjEpLCBtYXli ZSB0aGUgcGhyYXNlPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+X0FsbF8gUmVxdWVz dHMgd2l0aGluIGEgZGlhbG9nIF8oZXhjZXB0IG9mIEFDSylfIE1VU1Q8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPmNvbnRhaW4gc3RyaWN0bHkgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIGFuZCBj b250aWd1b3VzIENTZXEgc2VxdWVuY2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPm51bWJlcnMg KGluY3JlYXNpbmctYnktb25lKSBpbjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ZWFjaCBkaXJl Y3Rpb24uIDwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yPndvdWxkIGJlIGJl dHRlci4gKCBJIGFzc3VtZSwgd2hlbiB5b3UgYXJlIGFsbG93ZWQgdG8gc2VuZCBhIENBTkNFTCwg eW91IGFyZSBub3QgaW4gYSBkaWFsb2cgPyEsIGlzIHRoaXMgcmlnaHQ/ICk8L0ZPTlQ+DQo8L1A+ DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGFua3MgZm9yIHRoZSBjb25maXJtYXRpb248L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPkxhY2hsYW48L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxG T05UIFNJWkU9Mj4tLS0tLU9yaWdpbmFsbmFjaHJpY2h0LS0tLS08L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPlZvbjogSm9uYXRoYW4gUm9zZW5iZXJnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5B bjogQnJhemllciBMYWNobGFuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5DYzogJ3NpcEBpZXRm Lm9yZyc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkdlc2VuZGV0OiAxNS4wMi4wMiAyMjoxMDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+QmV0cmVmZjogUmU6IFtTaXBdIENTZXEgcXVlc3Rpb24/ PC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+QnJhemllciBMYWNo bGFuIHdyb3RlOjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgSGVsbG8sPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBwcm9iYWJseSBhd25zZXJlZCBsb25nIGFnbywgYnV0 IEkgY291bGRuJ3QgZmluZCBpdCA6LSg8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFRoZSByZWFzb24gSSBhc2sgaXMsIHRoYXQgaXQg d2Fzbid0IGNsZWFyIHRvIG1lLCBpZiB0aGUgaW5jcmVhc2luZyBvZjwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgQ1NlcSB2YWx1 ZSBpbiBhIGRpYWxvZyBpcyBib3VuZCB0byBhIHJlcXVlc3QgY2xhc3MgKElOVklURSwgQllFLDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBNWVJFUVVFU1QsPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IGV0Yy4pIG9yIHRvIHJlcXVlc3RzIGluIGdlbmVyYWwuPC9GT05UPg0KPC9Q Pg0KDQo8UD48Rk9OVCBTSVpFPTI+QWxsIHJlcXVlc3RzIHNlbnQgZnJvbSBBIHRvIEIgd2l0aGlu IGEgZGlhbG9nLCBpbmRlcGVuZGVudCBvZiB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPm1l dGhvZCwgaGF2ZSBpbmNyZWFzaW5nIENTZXEsIGJ5IHZhbHVlIG9mIDEsIHdpdGggdHdvIGV4Y2Vw dGlvbnM6PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jm5ic3A7IDEuIEFDSyBmb3Ig YW4gSU5WSVRFIGhhcyB0aGUgc2FtZSBjc2VxIGFzIHRoZSBpbnZpdGU8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZuYnNwOyAyLiBjYW5jZWwgZm9yIGEgcmVxdWVzdCBoYXMgdGhlIHNhbWUgY3Nl cSBhcyByZXF1ZXN0PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+U286PC9GT05UPg0K PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SU5WSVRFIChjc2VxOiAxKSAtLS0tJmd0OzwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+MjAwICgxKSZsdDstLS0tLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+QUNLICgxKS0tLS0tLS0tLSZndDs8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9 Mj5JTkZPICgyKS0tLS0tLS0tLSZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPjIwMCBPSyAo MikmbHQ7LS0tLS0tLTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkJZRSAoMykgLS0t LS0tLS0tJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+MjAwIE9LICgzKSZsdDstLS0tLS08 L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5DYW4geW91IHBvaW50IG1lIHRvIHRleHQg aW4gYmlzIHRoYXQgd291bGQgbGVhZCB5b3UgdG8gYmVsaWV2ZSBpdCB3YXM8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPnBlciBtZXRob2Q/IEkgdGhpbmsgdGhlIHRleHQgaXMgcHJldHR5IGNsZWFy OjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkZyb20gMTIuMi4xLjE6PC9GT05UPg0K PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhlIENhbGwtSUQgb2YgdGhlIHJlcXVlc3QgTVVTVCBi ZSBzZXQgdG8gdGhlIENhbGwtSUQgb2YgdGhlIGRpYWxvZy48L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPlJlcXVlc3RzIHdpdGhpbiBhIGRpYWxvZyBNVVNUIDE4NzI8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPmNvbnRhaW4gc3RyaWN0bHkgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIGFuZCBjb250 aWd1b3VzIENTZXEgc2VxdWVuY2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPm51bWJlcnMgKGlu Y3JlYXNpbmctYnktb25lKSBpbiAxODczPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5lYWNoIGRp cmVjdGlvbi4gVGhlcmVmb3JlLCBpZiB0aGUgbG9jYWwgc2VxdWVuY2UgbnVtYmVyIGlzIG5vdCBl bXB0eSw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRoZSB2YWx1ZSBvZiB0aGUgbG9jYWwgc2Vx dWVuY2UgbnVtYmVyIDE4NzQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPk1VU1QgYmUgaW5jcmVt ZW50ZWQgYnkgb25lLCBhbmQgdGhpcyB2YWx1ZSBNVVNUIHBsYWNlZCBpbnRvIHRoZSBDc2VxPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5oZWFkZXIuIElmIHRoZSBsb2NhbCBzZXF1ZW5jZSAxODc1 PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5udW1iZXIgaXMgZW1wdHksIGFuIGluaXRpYWwgdmFs dWUgTVVTVCBiZSBjaG9zZW4gdXNpbmcgdGhlIGd1aWRlbGluZXMgb2Y8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPlNlY3Rpb24gOC4xLjEuNS4gVGhlIG1ldGhvZCBmaWVsZCAxODc2PC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5pbiB0aGUgQ3NlcSBoZWFkZXIgTVVTVCBtYXRjaCB0aGUgbWV0aG9k IG9mIHRoZSByZXF1ZXN0LiAxODc3PC9GT05UPg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpF PTI+LUpvbmF0aGFuIFIuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+LS0gPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj5Kb25hdGhhbiBELiBSb3NlbmJlcmcsIFBoLkQuJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDcyIEVhZ2xlIFJvY2sgQXZlbnVlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5DaGllZiBTY2ll bnRpc3QmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlyc3QgRmxvb3I8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPmR5bmFtaWNzb2Z0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVhc3QgSGFub3ZlciwgTkogMDc5MzY8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPmpkcm9zZW5AZHluYW1pY3NvZnQuY29tJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZBWDogKDk3MykgOTUyLTUwNTA8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPjxBIEhSRUY9Imh0dHA6Ly93d3cuamRyb3Nlbi5uZXQiIFRBUkdFVD0iX2JsYW5r Ij5odHRwOi8vd3d3Lmpkcm9zZW4ubmV0PC9BPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBQSDombmJzcDsgKDk3MykgOTUyLTUwMDA8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPjxBIEhSRUY9Imh0dHA6Ly93d3cuZHluYW1pY3NvZnQuY29tIiBUQVJHRVQ9Il9i bGFuayI+aHR0cDovL3d3dy5keW5hbWljc29mdC5jb208L0E+PC9GT05UPg0KPC9QPg0KDQo8L0JP RFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C1B7B7.72B61BC0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 17 09:38:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06381 for ; Sun, 17 Feb 2002 09:38:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11004 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 09:38:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10027; Sun, 17 Feb 2002 09:06:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10002 for ; Sun, 17 Feb 2002 09:06:40 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06043 for ; Sun, 17 Feb 2002 09:06:36 -0500 (EST) Received: (qmail 9336 invoked from network); 17 Feb 2002 14:09:58 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 17 Feb 2002 14:09:58 -0000 Received: from stake.com (unknown [10.1.64.73]) by cam-relay.atstake.com (Postfix) with SMTP id 3129A22817; Sun, 17 Feb 2002 09:04:32 -0500 (EST) Message-ID: <3C6FB986.2000400@stake.com> Date: Sun, 17 Feb 2002 14:09:10 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Rohan Mahy Cc: sip@ietf.org, mat@cisco.com Subject: Re: [Sip] re: SMIME in SIP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan, >>4) TLS doesn't address UDP. IPsec WG is working on >> NAT traversal >> > > UDP doesn't work well in the Internet at large anyway. It's support is > still around for backwards compatibility, and for use in specialized > layer2 domains where RTT is expensive; these domains usually run what > amounts to a private network. IPsec is probably a good thing in those > networks, and the spec allows for that. Umm, DNS? Streaming Media? Your own voice sampling transporting protocols such as RTP? Do not dismiss UDP that fast. It has it's usages :) -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 17 10:27:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07208 for ; Sun, 17 Feb 2002 10:27:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12534 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 10:27:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11967; Sun, 17 Feb 2002 10:10:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11937 for ; Sun, 17 Feb 2002 10:10:19 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06915 for ; Sun, 17 Feb 2002 10:10:16 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1HFAa6Y005219; Sun, 17 Feb 2002 10:10:37 -0500 (EST) Message-ID: <3C6FC7BB.447CF5AB@dynamicsoft.com> Date: Sun, 17 Feb 2002 10:09:47 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brazier Lachlan CC: "''sip@ietf.org' '" Subject: Re: AW: [Sip] CSeq question? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Brazier Lachlan wrote: > > Hello, > > I used to be the opinion, that the Method name in the CSeq header was > needed to say: "This request XXX is the request with number Y" > > Example: > > MYREQUEST ... > CSeq: 2 MYREQUEST > > would mean this is my second request of the kind MYREQUEST. No. Nothing in the spec says that. > > I haven't read all of bis07 (bis05 - 05 either), but I so far I didn't > find a reason for the method name in the CSeq Header. It looks pretty > redundant to the method name in the request line. The reason is to handle the exceptions to the rule, CANCEL and ACK. As they have the same cseq, the method name is needed to disambiguate the responses to those requests. > Concerning the paragraph you mention below (12.2.1.1), maybe the phrase > > _All_ Requests within a dialog _(except of ACK)_ MUST > contain strictly monotonically increasing and contiguous CSeq sequence > numbers (increasing-by-one) in > each direction. I will add text excepting CANCEL and ACK. > > would be better. ( I assume, when you are allowed to send a CANCEL, you > are not in a dialog ?!, is this right? ) No. Its not useful, really, but CANCEL is allowed for INVITE, either inside or outside of a dialog. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sun Feb 17 10:37:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07341 for ; Sun, 17 Feb 2002 10:37:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13101 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 10:37:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12292; Sun, 17 Feb 2002 10:20:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12187 for ; Sun, 17 Feb 2002 10:20:00 -0500 (EST) Received: from services.dasecurenetworks.com (adsl-65-65-112-127.dsl.rcsntx.swbell.net [65.65.112.127]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07033 for ; Sun, 17 Feb 2002 10:19:57 -0500 (EST) Received: from dasecurenetworks.com (main1.dasecurenetworks.com [192.168.0.151] (may be forged)) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g1HEiPX25956; Sun, 17 Feb 2002 08:44:25 -0600 Message-ID: <3C6FCD1E.95B03495@dasecurenetworks.com> Date: Sun, 17 Feb 2002 09:32:47 -0600 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Michael Thomas , Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP References: <3C6F44AA.B645E0B0@dasecurenetworks.com> <3C6F4545.E216CC4F@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I think this problem is arguably a feature. If I am encrypting my SDP > information so that only the desired recipient will get it, then the > *point* is that intermediaries can't look at the information and modify > it. So, if I try to make a secure call and hear nothing, or get a > failure from one of the proxies, I will know that a secure call is not > possible in this configuration. I can then try again without such > security, or do something else (change providers, say...) as > appropriate. > > -Jonathan R. The provider has nothing to do with the choice of security solution implemented by the customer... whether it is a SOHO, enterprise, or home user with a PC firewall to protect their latest and greatest OS....if the firewall cannot see the SDP the media will fail (Although in the PC scenario the problem can be solved far more easily being on the same box as the client). Carriers will have to be sensitive to customer requirements or they will not have many customers (at least not in the enterprise space). Now I must say that trying to build encryption methods into SIP is a good thing....but it can also present larger issues that we should probably address while doing this. How do we facilitate media traversal through existing security mechanisms if those security mechanism cannot determine what ports/ip addresses to use for media traversal, since these mechanisms were set in place to address security concerns? It would affect developments such as MIDCOM, firewalls, NAT, and even intermediary proxies wouldnt it? Christopher A. Martin > > Chris Martin wrote: > > > > Sorry, > > To clarify, what I was trying to say was that the introduction of any of > > the crypto > > methods TLS/SSL/SMIME on any of the pertinent header fields can affect > > the way that > > firewall solutions that are being developed today by many of the major > > vendors, as well as > > MIDCOM-like vendors..will be broken, due to the fac that the > > implementation will be > > required to decrypt portions of the message (assuming that the message > > body is to be > > encrypted, which may contain SDP). These implementations parse the > > headers for such > > items as contact, call-id, SDP info (in order to open pinholes for > > media), to name a few. > > > > Michael Thomas wrote: > > > > > Chris Martin writes: > > > > Michael Thomas wrote: > > > > > > > > > 1) I have said nothing about TLS in this thread > > > > > > > > > > 2) I haven't made a proposal for IPsec because Allison said > > > > > that it won't go into bis regardless > > > > > > > > > > > > > > 3) Equating me asking that we postpone considering e2e > > > > > mechanisms with people dying tops any claims of > > > > > LAMEST I can imagine. > > > > > > > > > > 4) TLS doesn't address UDP. IPsec WG is working on > > > > > NAT traversal > > > > > > > > > > > > > Also will break firewall implementations, that have/are being > > developed by many well > > > > known vendors, to address SIP....would require that they also > > decrypt to peform > > > > pinhole allocation. Would most likely also affect SIP > > infrastructures already built > > > > today based on UDP if we must suddenly implement TCP based SIP > > (Would have actually > > > > been nice from the start). > > > > > > I can't parse what you're commenting on. > > > > > > 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 > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 daemon@optimus.ietf.org Sun Feb 17 12:27:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08734 for ; Sun, 17 Feb 2002 12:27:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17993 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 12:27:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16017; Sun, 17 Feb 2002 11:50:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15993 for ; Sun, 17 Feb 2002 11:50:56 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08312 for ; Sun, 17 Feb 2002 11:50:52 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1HGoFS25732; Sun, 17 Feb 2002 10:50:15 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1HGoEU08676; Sun, 17 Feb 2002 10:50:14 -0600 (CST) Received: from lmf.ericsson.se (rmt160142.am.ericsson.se [138.85.160.142]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA24038; Sun, 17 Feb 2002 10:50:12 -0600 (CST) Message-ID: <3C6FE6D0.D36D52DC@lmf.ericsson.se> Date: Sun, 17 Feb 2002 19:22:24 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: ysong@telcordia.com, "gonzalo.camarillo" , Jonathan Rosenberg , sip@ietf.org References: <3C6F3D46.9000802@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] Comments on bis-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, > > Line 2337: It states that (when the UAS responses to BYE), "The UAS MUST > > still respond to any pending requests received for that dialog, (which can > > only be an INVITE)." Any pending request can be OPTIONS as well in addition > > to INVITE although unlikely. > > I'll let Gonzalo comment on this one. > I already fixed this when I marked bug#113 (non-INVITE overlapping transactions) as resolved. Thanks for the comment, 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 daemon@optimus.ietf.org Sun Feb 17 12:37:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08866 for ; Sun, 17 Feb 2002 12:37:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18825 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 12:37:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17636; Sun, 17 Feb 2002 12:16:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17604 for ; Sun, 17 Feb 2002 12:16:10 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08609 for ; Sun, 17 Feb 2002 12:16:06 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1HHFct10549; Sun, 17 Feb 2002 09:15:38 -0800 (PST) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint) with SMTP id ACM58177 (AUTH rmahy); Sun, 17 Feb 2002 09:15:38 -0800 (PST) Message-Id: <200202171715.ACM58177@imop.cisco.com> Received: from 171.68.225.134 by imop.cisco.com with HTTP/1.0; Sun, 17 Feb 2002 09:16:25 -0800 Date: Sun, 17 Feb 2002 09:16:25 -0800 From: Rohan Mahy Subject: Re: [Sip] re: SMIME in SIP To: Ofir Arkin Cc: Rohan Mahy , sip@ietf.org, mat@cisco.com X-Mailer: Mirapoint Webmail Direct 2.9.1.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ofir, I was referring only to SIP over UDP. No one was suggesting RTP over TLS for example. ;-) btw: the AVT WG is working on Secure RTP thanks, -rohan >Rohan, > >>>4) TLS doesn't address UDP. IPsec WG is working on >>> NAT traversal >>> >> >> UDP doesn't work well in the Internet at large anyway. It's support is >> still around for backwards compatibility, and for use in specialized >> layer2 domains where RTT is expensive; these domains usually run what >> amounts to a private network. IPsec is probably a good thing in those >> networks, and the spec allows for that. > > >Umm, DNS? Streaming Media? > >Your own voice sampling transporting protocols such as RTP? > >Do not dismiss UDP that fast. It has it's usages :) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 17 13:19:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09498 for ; Sun, 17 Feb 2002 13:19:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20886 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 13:19:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18763; Sun, 17 Feb 2002 12:36:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18737 for ; Sun, 17 Feb 2002 12:36:25 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08843 for ; Sun, 17 Feb 2002 12:36:15 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1HHNb001531; Sun, 17 Feb 2002 11:23:37 -0600 Message-ID: <3C6FE719.4090001@dynamicsoft.com> Date: Sun, 17 Feb 2002 11:23:37 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] yet more bis-07 nits References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit These are integrated (or are being tracked as bugs) comments inline Rohan Mahy wrote: > hi, > > more nits, comments, and proposed clarifications from the pdf version of > bis-07: > section 16 through section 21. > > again, please just send comments on the stuff that doesn't make sense. > > important stuff marked with ** > > thanks, > -rohan > > > 2464: bad section reference > > 2643: s/that element/the next element/ > > 2645: ...MUST resolve to this element. what about proxy farms or > clusters? ** Hmm - I don't think the text as it stands precludes clustering. If you've distributed your SIP element across a bunch of physical devices, any resolution to one of those devices is a resolution to that element. I'll add a motivation block to that effect. > > 2723: append: "as described in step 6" > > 2738: s/the element/this proxy/ I used element on purpose here. Its acting in the UAC role when it does these. > > 2806: s/dialogs/of dialogs/ > > 2856: s/to to/to/ > > 2991: s/sends to/rewrites the Request-URI with/ it had already rewritten the RURI - I fixed the logic of the sentence. > > 3011: s/obtained by/obtained, by/ (really confusing otherwise) I can't figure out what your source of confusion was - introducing the comma doesn't make sense - the location (address/port/transport) is obtained by resolving the URI. I'll restructure the sentence to make that more clear. > > 3093: s/example of/example in/ > > 3102: s/to that server/to the appropriate server/ > > 3104: s/out any/out any response/ > > 3132: s/request/requests/ > > 3229-30: normative language like NOT RECOMMENED shouldn't hyphenate > > 3231: s/that the/the/ > > pages 90 and 92: (figures 7 and 8) the Figure X:blah blah overlaps the > footer > > 3604: s/UA/UAs/ > > 3744-5: s/the SIP standard today/this document/ > > 3846-50: now that Basic is deprecated to we still need this Paragraph? > *** It does not harm that I can see and it helps future proof the spec against future schemes that might not have a realm. > > 3866-7: make language consistent with the "single header, mutiple values" > rule > > 3868: SHOULD -> MUST ?? same future proof argument as above > > 3878: s/that servers/that SIP servers/ > > 3932: s/These certificates are/The keying material associated with these > certificates is/ > > 3942: s/limitated/limited/ > > 3970: s?a S/MIME?an S/MIME? > > 3995: non normative ref to SSH maybe? > > 4056: s/Proxy-Authorization/Proxy-Authenticate/ No - it meant Proxy-Authorization - proxies can remove values from requests as the request is forwarded. > > 4057: append: "defined in this document" > > Section 21.4 general: add language reminding implementors of comparison > rules in SIP (compress/expand whitespace, case insensitivity, equivalence > between short and long header forms, etc...) > ** > > 5440: have codes x80 upwards... what about some x20 response codes? > > 5585: s/logged in such/logged in in such/ > > 5649-52: inconsistent with line 1226 1226 changed to "understands but does not support" > > 5695: append "Warning reason codes are listed in Section 24.45" > > 5699: nuke first sentence > > 6366: somehow "IEEE Communications Magazine" got lost from bis-06 > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sun Feb 17 13:23:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09536 for ; Sun, 17 Feb 2002 13:23:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20966 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 13:23:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19678; Sun, 17 Feb 2002 12:57:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19652 for ; Sun, 17 Feb 2002 12:56:58 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09227 for ; Sun, 17 Feb 2002 12:56:55 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1HHiO001561; Sun, 17 Feb 2002 11:44:25 -0600 Message-ID: <3C6FEBF7.6040207@dynamicsoft.com> Date: Sun, 17 Feb 2002 11:44:23 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: "Buller, Jeremy" CC: "'sip@ietf.org'" Subject: Re: [Sip] Last call comment, Re: bis-07, section 20.1 - example References: <153BDA136259D311859900A0C99B5263FA0E7E@boca-isbu-nt04.boca.unispheresolutions.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Yep - that's been fixed. RjS Buller, Jeremy wrote: > Example in 20.1. has INVITE with 'WWW-Authenticate:' > (Response header/Challenge), 'Authorization:'? > > Kind regards, > > Jim > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sun Feb 17 14:41:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10541 for ; Sun, 17 Feb 2002 14:41:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24704 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 14:41:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23137; Sun, 17 Feb 2002 14:09:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23102 for ; Sun, 17 Feb 2002 14:09:34 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10008 for ; Sun, 17 Feb 2002 14:09:30 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1HJ9o6Y005301 for ; Sun, 17 Feb 2002 14:09:50 -0500 (EST) Message-ID: <3C6FFFCB.14D4B253@dynamicsoft.com> Date: Sun, 17 Feb 2002 14:08:59 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] multicast restricted to ttl=1 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, As a result of IESG review, there were concerns about the multicast usage of SIP. In particular, for the things we were using it for, it was felt that a limitation of scope to ttl=1 was needed. As such, I have modified the transport chapter to reflect a SHOULD level usage of ttl=1. Comments or questions welcome. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sun Feb 17 14:53:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10638 for ; Sun, 17 Feb 2002 14:53:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24908 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 14:54:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23482; Sun, 17 Feb 2002 14:17:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23451 for ; Sun, 17 Feb 2002 14:17:52 -0500 (EST) Received: from relay5.kornet.net ([211.48.62.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10179 for ; Sun, 17 Feb 2002 14:17:47 -0500 (EST) Received: from vivi-41a7ime526 (211.227.92.32) by relay5.kornet.net; 18 Feb 2002 04:17:17 +0900 Message-ID: <3c7001bd3c886045@relay5.kornet.net> (added by relay5.kornet.net) From: =?ks_c_5601-1987?B?VklWSSBLT1JFQQ==?= To: sip@ietf.org Date: Mon, 18 Feb 2002 04:17:03 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C0F17A.93A03C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] =?ks_c_5601-1987?B?W7GksO1dIHNpcLTUILChsbiw+MDlv6G8rSDGr7qwx9LAzrCht84gsO2x3rv9yLCwobG4uKYgurizu7XluLO0z7TZLg==?= Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C0F17A.93A03C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 vsiz58fPvLy/5C4NCg0KsKGxuMD8ua6+98O8ILrxuvHE2riuvsYgwNS0z7TZLg0KDQqw7bHe ILv9yLCwobG4uKYgvsbB1iDA+rfFx9EgsKGw3cC4t84gxvfDtSCwobG4sPi03L+hvK0gwffB oiDGx7jFx9W0z7TZLg0KDQrA5bfVLCC87sbELCDEp7Trte4gMjAwMrPiILq9wMcgw9a9xbjw tai3ziC18MDawM7AzLOqIMDnwfq46b+hvK0NCr/svPbH0SDBpsewwLsgvLHBpMfPv6kgxse4 xcfPsO0gwNa9wLTPtNkuDQoNCrHiwbggsKGxuMGhwMcgNDAlfjYwJcGktbUgwPq3xcfPsNQg xse4xcfPsO0gwNa+xr/AtM8NCrLAIMfRufggyKjG5MDMwfa4piC6uL3DseIgudm2+LTPtNku DQoNCrChsbiwoSDHyr/kx8+9w7jpILChsbjA/LmusKHAziDA+sjxv80gwMez7cfYIMHWvcq9 w7/AIA0KQS9TILimILrxt9THz7+pILy6vcfH0SDA2ry8t84gw9a8scC7ILTZIMfPsNq9wLTP tNkuDQoNCmh0dHA6Ly93d3cudml2aS5jby5rci8NCg0KtOe757TCILHNu+cox88pv6EgsPzH z7+pIL7Guau3sSDBpLq4tbUgsK6w7SDA1sH2vsq9wLTPtNkuDQq02bi4IMDMuN7AzyDA2rW/ w9/D4rHit84gwMy43sDPuLggwKW758DMxq6/obytIMPfw+LHz7+0vcC0z7TZDQq89r3FsMW6 ziDHz73HutDAuiC/qbHiIGh0dHA6Ly93d3cuY3J1c2FkZS5jby5rci9yZWplY3QvcmVqZWN0 LnBocD9pZD0yMjQxJmF1dGg9YjZlMzIzMjBmYTZiYzVhNTg4YjkwMTgzYjk1ZGMwMjgmbWFp bD1zaXBAaWV0Zi5vcmcmbW9kZT13cml0ZSC4piDFrLivx9ggwda9yr3Dv8AuDQoNCg== ------=_NextPart_000_0047_01C0F17A.93A03C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 vsiz58fPvLy/5C4NCg0KsKGxuMD8ua6+98O8ILrxuvHE2riuvsYgwNS0z7TZLg0KDQqw7bHe ILv9yLCwobG4uKYgvsbB1iDA+rfFx9EgsKGw3cC4t84gxvfDtSCwobG4sPi03L+hvK0gwffB oiDGx7jFx9W0z7TZLg0KDQrA5bfVLCC87sbELCDEp7Trte4gMjAwMrPiILq9wMcgw9a9xbjw tai3ziC18MDawM7AzLOqIMDnwfq46b+hvK0NCr/svPbH0SDBpsewwLsgvLHBpMfPv6kgxse4 xcfPsO0gwNa9wLTPtNkuDQoNCrHiwbggsKGxuMGhwMcgNDAlfjYwJcGktbUgwPq3xcfPsNQg xse4xcfPsO0gwNa+xr/AtM8NCrLAIMfRufggyKjG5MDMwfa4piC6uL3DseIgudm2+LTPtNku DQoNCrChsbiwoSDHyr/kx8+9w7jpILChsbjA/LmusKHAziDA+sjxv80gwMez7cfYIMHWvcq9 w7/AIA0KQS9TILimILrxt9THz7+pILy6vcfH0SDA2ry8t84gw9a8scC7ILTZIMfPsNq9wLTP tNkuDQoNCmh0dHA6Ly93d3cudml2aS5jby5rci8NCg0KtOe757TCILHNu+cox88pv6EgsPzH z7+pIL7Guau3sSDBpLq4tbUgsK6w7SDA1sH2vsq9wLTPtNkuDQq02bi4IMDMuN7AzyDA2rW/ w9/D4rHit84gwMy43sDPuLggwKW758DMxq6/obytIMPfw+LHz7+0vcC0z7TZDQq89r3FsMW6 ziDHz73HutDAuiC/qbHiIGh0dHA6Ly93d3cuY3J1c2FkZS5jby5rci9yZWplY3QvcmVqZWN0 LnBocD9pZD0yMjQxJmF1dGg9YjZlMzIzMjBmYTZiYzVhNTg4YjkwMTgzYjk1ZGMwMjgmbWFp bD1zaXBAaWV0Zi5vcmcmbW9kZT13cml0ZSC4piDFrLivx9ggwda9yr3Dv8AuDQoNCg== ------=_NextPart_000_0047_01C0F17A.93A03C00-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 17 14:54:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10657 for ; Sun, 17 Feb 2002 14:54:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24959 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 14:54:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23426; Sun, 17 Feb 2002 14:16:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23397 for ; Sun, 17 Feb 2002 14:16:53 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10175 for ; Sun, 17 Feb 2002 14:16:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1HJHB6Y005305 for ; Sun, 17 Feb 2002 14:17:11 -0500 (EST) Message-ID: <3C700185.607C5D1D@dynamicsoft.com> Date: Sun, 17 Feb 2002 14:16:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] a compromise on S/MIME Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, After some discussions with Allison and the editors, we have a compromise solution on S/MIME that I believe will be satisfactory. The compromise was to keep S/MIME in the specification, but to downgrade its usage from SHOULD to MAY. Removing SMIME entirely from the spec is not going to be acceptable. The reason, simply, is that without it, we have no sufficient e2e security story. Not all applications will want to use it (and thus the downgrade to MAY), but as a protocol, SIP is not complete unless it can address e2e security requirements that other applications will have. SMIME is the only known, documented, reasonably complete, and thought through mechanism that can address the range of e2e security requirements that we need to address. Therefore, it is the only sensible solution to this problem for the forseeable future, and SIP, on its own, must be able to address the problem. What is most desired, therefore, is comments on the text itself, and we would still welcome those in the time that remains. I will note that some initial reviews of the SMIME text have been extremely positive overall, and I'd like to commend Jon Peterson in particular for the outstanding work he has done on this text. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sun Feb 17 15:54:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11363 for ; Sun, 17 Feb 2002 15:54:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27537 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 15:55:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26737; Sun, 17 Feb 2002 15:33:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26687 for ; Sun, 17 Feb 2002 15:33:38 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11075 for ; Sun, 17 Feb 2002 15:33:34 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1HKWsZ19714; Sun, 17 Feb 2002 12:32:54 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX27421; Sun, 17 Feb 2002 12:32:34 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA28854; Sun, 17 Feb 2002 12:33:02 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15472.4990.360439.39950@thomasm-u1.cisco.com> Date: Sun, 17 Feb 2002 12:33:02 -0800 (PST) To: Rohan Mahy Cc: sip@ietf.org, In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [Sip] re: SMIME in SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy writes: > >3) Equating me asking that we postpone considering e2e > > mechanisms with people dying tops any claims of > > LAMEST I can imagine. > > In the message I replied to, you implied that the PSTN model of security > was sufficient for SIP. I said no such thing. I merely pointed out that the PSTN relies on transitive trust and the world hasn't ended. I have said nothing about the rest of their security model. For many, many use scenarios reliance on transitive trust will still be adequate and widely deployed. SIP is not going to implode in a wave of security scandals if e2e crypto is not put into bis. > You didn't concretely propose anything. This is > in fact the crux of the problem. In fact, I have concretely propose something on many, many occasions. I'll repeat it for the hundredth time: 1) Choose a hop by hop mechanism for bis 2) Leave digest alone 3) Define requirements and create a new standards track draft which deals with *all* of the inside crypto needs; not just e2e, but also end to middle, and middle to middle In fact, the primary (only?) security mechanism we've had feedback about from the working group is the middle-middle case, specifically for RPI. Yet, there's nothing in bis which provides for that case. Indeed, there are even regulatory questions surrounding unauthenticated RPI. What does that say about the priorities chosen? > UDP doesn't work well in the Internet at large anyway. Where to begin... no, never mind. > 5) In order for SMIME to work in a large scale, > you need a large scale PKI. Good luck. > > I'd rather that it work in a few identifiable scenarios like the ones that > I described. If you want to propose something concrete for large scale > use please go for it. No, I won't propose something for the large scale because I don't think it is by and large *feasible*. Throwing SMIME pixie dust at things doesn't change the fact that large scale PKI's are a myth, and will remain a myth for a long time to come. > In the interim, we have four choices regarding SMIME AFAIK: > > Make it a MUST: probably not very popular ;-) > Leave as a SHOULD: leave the draft as is > Make it a MAY: a proposal echoed by many > Postpone Last Call: extremely unpopular among implementers There is a 5th: put it into a separate draft. > - while b) is certainly true, getting bis to the IESG certainly DOES > appear to be a high priority and these appear to be linked by the IESG. > If you don't like that linkage, you can/should go yell at them. In fact, I have asked and have received no response. The only thing I've heard is vague allusions to working groups saying they'll do something but not delivering. This sounds like a management problem to me, and frankly it's rather patronizing given that the chairs have done a commendable job of taking security seriously. 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 daemon@optimus.ietf.org Sun Feb 17 15:59:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11416 for ; Sun, 17 Feb 2002 15:59:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27686 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 15:59:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26859; Sun, 17 Feb 2002 15:35:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26830 for ; Sun, 17 Feb 2002 15:35:47 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11094 for ; Sun, 17 Feb 2002 15:35:42 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1HKNA001722; Sun, 17 Feb 2002 14:23:10 -0600 Message-ID: <3C70112D.2090707@dynamicsoft.com> Date: Sun, 17 Feb 2002 14:23:09 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: John.Hearty@Level3.com CC: sip@ietf.org Subject: Re: [Sip] A few more bis-07 nits References: <17052388D394D411803900508BDFFAF6041376B3@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit These have all been covered, except for the conversion to text errors. Those are queued for the next conversion. RjS John.Hearty@Level3.com wrote: > Continued from last list I sent... > > > 41. The sentence in 3222-3223 is saying the same thing as the sentence in > 3225-3226. Seggest the first be deleted (the latter includes explanatory > text following it). > > 42. Lines 3230-3231, "that that" should be "that". > > 43. Lines 3290-3291 states "As with client transactions, this is needed to > ensure reliability of the 2xx responses to INVITE." But this section is > discussing non-INVITE Client Transaction. > > 44. Line 3301-3302 states "A response which matches a transaction matched by > a previous response is considered a retransmission of that response." This > would seem to be false when considering provisionals then a final response > received. > > 45. Section 17.2.1 Figure 7 title is too low, overwriting the page footer. > Same for figure 8 under section 17.2.2. Reported for bis-06, bug opened. > > 46. Figure 8 in the txt version has it's title wrapped to the first line of > the next page. > > > John Hearty > Level3 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sun Feb 17 16:22:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11638 for ; Sun, 17 Feb 2002 16:22:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28935 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 16:22:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27570; Sun, 17 Feb 2002 15:55:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27525 for ; Sun, 17 Feb 2002 15:54:57 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11358 for ; Sun, 17 Feb 2002 15:54:53 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1HKsJh04324; Sun, 17 Feb 2002 12:54:19 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX27484; Sun, 17 Feb 2002 12:53:50 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA28857; Sun, 17 Feb 2002 12:54:17 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15472.6265.772803.672840@thomasm-u1.cisco.com> Date: Sun, 17 Feb 2002 12:54:17 -0800 (PST) To: cmartin@dasecurenetworks.com Cc: Michael Thomas , Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP In-Reply-To: <3C6F44AA.B645E0B0@dasecurenetworks.com> References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <3C6F1757.1500B76@dasecurenetworks.com> <15471.10494.915214.197702@thomasm-u1.cisco.com> <3C6F44AA.B645E0B0@dasecurenetworks.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Chris Martin writes: > > Sorry, > To clarify, what I was trying to say was that the introduction of any of the crypto > methods TLS/SSL/SMIME on any of the pertinent header fields can affect the way that > firewall solutions that are being developed today by many of the major vendors, as well as > MIDCOM-like vendors..will be broken, due to the fac that the implementation will be > required to decrypt portions of the message (assuming that the message body is to be > encrypted, which may contain SDP). These implementations parse the headers for such > items as contact, call-id, SDP info (in order to open pinholes for media), to name a few. I agree with Jonathan: this is a feature not a bug. Middle boxes are a cancer on the net. 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 daemon@optimus.ietf.org Sun Feb 17 16:34:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11774 for ; Sun, 17 Feb 2002 16:34:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29837 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 16:34:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28196; Sun, 17 Feb 2002 16:03:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28165 for ; Sun, 17 Feb 2002 16:03:47 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11464 for ; Sun, 17 Feb 2002 16:03:42 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1HKpE001762; Sun, 17 Feb 2002 14:51:14 -0600 Message-ID: <3C7017C1.6050402@dynamicsoft.com> Date: Sun, 17 Feb 2002 14:51:13 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: John.Hearty@Level3.com CC: sip@ietf.org Subject: Re: [Sip] bis-07 nits part 1 References: <17052388D394D411803900508BDFFAF601B371D0@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit All of these have been addressed or have bugs against them. Resetting timer C in a proxy allows the proxy to dynamically extend the transaction's lifetime, indefinitely if it wants to, periodically checking in. RjS John.Hearty@Level3.com wrote: > Here are comments on the first half of my review. Thought I'd send some > now instead of all comments at the last minute. More to come. > > > 1. Line 333 begins: "SIP does not provide services." Line 343 goes on to > state "The nature of the services provided by SIP...", looks like the latter > sentence needs to be wordsmithed. > > 2. Max-Forwards brief description is needed after line 406. > > 3. Line 429, 430 and 434 reference "IP address" included in the Via's, this > should be changed to domain, or just "address". > > 4. Lines 456-458, the Via headers need received= parameters. > > 5. Line 567, FSM not defined. > > 6. Line 644, "adress-of-record" should be "address-of-record". > > 7. Line 980, "this by done" should be "this be done". > > 8. Line 994, "the domain the right hand side" should be "the domain to the > right hand side". > > 9. Text version text corresponding to line 1093 is missing a period after > "100rel" similar to corruption corrected in other sections. > > 10. Do a global replace on proceedures with procedures. Multiple occurences > throughout doc. > > 11. Line 1124, "as way to" should be "as a way to". > > 12. Line 1137, is timeout the ONLY thing the TU will see? What happens when > an ICMP host unreachable is returned? Does that not get to the TU? Related > to this, should line 1170 > "or network timeouts" be "or network failures"? (Reported in bis-06 nits, > response was change didn't make it into bis-07, bug opened) > > 13. Line 1207, reference section missing closing ")". > > 14. Line 1407, suggest changing "has not yet sent a response" to "has not > yet sent a final response". > > 15. Section 10.1 of the text version has a space before a comma in three > places. PDF version is OK (lines 1481-1483). Reported this for bis-06, > response was this is a text conversion problem, but keep reporting when > seen. > > 16. Line 1645 indicates a registrar SHOULD authenticate the UAC, but section > 26.1 does not show this. Suggestion: if this is not included for brevity > reasons, perhaps just a note in section 26.1 indicating authentication > should also be done. > > 17. Lines 1653-1654 are indented in PDF version, but not in txt version. > Reported for other sections in bis-06, response was this is a text > conversion problem, but keep reporting when seen. Other instances of this > problem: lines 1679-1684, 1691, 2438-2439, 2553-2554, 2581-2584, 2592, > 2615-2618, 2623, 2628-2630, 2642-2644, 2749-2752, 2769-2774, 2822-2827. > > 18. Line 1655, "field of request" should be "field of the request". > > 19. Line 1662, "a Expires" should be "an Expires". > > 20. Line 1728, Via header not changed to Recommended FQDN. Noted this for > examples in section 26 of bis-06, response is bug entered, I guess this can > be added to that. Problem also seen on line 1762. Also, if these get > changed to FQDNs for responses, remember to also add received= parameter. > > 21. Line 1780, "a two user agents" should be "two user agents". > > 22. Line 1861, is this open issue considered resolved? Delete line if so. > > 23. Line 1888, "MUST a Route header" should be "MUST include a Route > header". > > 24. Line 1918, "recieves" should be "receives". > > 25. Line 1920, "for the a request" should be "for a request". > > 26. Sections 13.2.1 and 13.3.1.4 indicate Allow and Supported headers SHOULD > be present in an Invite and 2xx, respectively, but the example in 26.2 does > not contain these. If these are added, the example would no longer have the > minimum set described in section 4 which references section 26.2. > Suggestion: if headers are added, include a small note explaining the > difference with section 4. Otherwise, include a note that the headers > normally SHOULD be included. > > 27. Line 2035, "send" should be "sent". > > 28. Line 2037, "this means the a UAS" should be "this means a UAS". > > 29. The text version has indented text corresponding to PDF version lines > 2270-2272 which is not indented. Reported same problem in bis-06, response > was this is a text conversion problem, but keep reporting when seen. Same > problem for lines 2296-2298. > > 30. The text in section 16.2 of the text version corresponding with lines > 2394-2397 has the formatting corrupted, with ".IP" stuffed in three times. > > 31. Line 2416 has "a request." which is missing in corresponding text > version section 16.3. > > 32. Figure 3 on page 63 of PDF version has no title identifying it. OK in > txt version. > > 33. Lines 2438-2439, not sure if this note should be included when this > becomes an RFC. > > 34. Line 2464, bad section reference. > > 35. Line 2604, "unless it known" should be "unless it is known". > > 36. Line 2856, "to to" should be "to". > > 37. Line 2889, what is the point of resetting timer C when it expires? > Expiring timers normally invoke some action other than simply resetting the > timer. > > 38. Lines 2968-2973 have both bullets and step numbers. > > 39. Line 3058, "U1 receives" should be "U1 sends" > > 40. Line 3061, "P1 its location service" should be "P1 uses its location > service". > > > John Hearty > Level3 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sun Feb 17 16:45:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11903 for ; Sun, 17 Feb 2002 16:45:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA00144 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 16:45:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28839; Sun, 17 Feb 2002 16:20:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28709 for ; Sun, 17 Feb 2002 16:20:27 -0500 (EST) Received: from services.dasecurenetworks.com (adsl-65-65-112-127.dsl.rcsntx.swbell.net [65.65.112.127]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11611 for ; Sun, 17 Feb 2002 16:20:22 -0500 (EST) Received: from dasecurenetworks.com (main1.dasecurenetworks.com [192.168.0.151] (may be forged)) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g1HKj4X26398; Sun, 17 Feb 2002 14:45:04 -0600 Message-ID: <3C7021A7.B2C6B1BF@dasecurenetworks.com> Date: Sun, 17 Feb 2002 15:33:27 -0600 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <3C6F1757.1500B76@dasecurenetworks.com> <15471.10494.915214.197702@thomasm-u1.cisco.com> <3C6F44AA.B645E0B0@dasecurenetworks.com> <15472.6265.772803.672840@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Chris Martin writes: > > > > Sorry, > > To clarify, what I was trying to say was that the introduction of any of the crypto > > methods TLS/SSL/SMIME on any of the pertinent header fields can affect the way that > > firewall solutions that are being developed today by many of the major vendors, as well as > > MIDCOM-like vendors..will be broken, due to the fac that the implementation will be > > required to decrypt portions of the message (assuming that the message body is to be > > encrypted, which may contain SDP). These implementations parse the headers for such > > items as contact, call-id, SDP info (in order to open pinholes for media), to name a few. > > I agree with Jonathan: this is a feature not a bug. > Middle boxes are a cancer on the net. > > Mike I agree with Johnathan as well, but I think that with the direction of security in the world today they are a cancer that will prevail, and are required by policies and by necessity.... I also like your proposal to develop an individual draft to address crypto and other related issues. I am not against making the protocol secure but I believe that the other mechanisms that you have described are valid and should be addressed as alternatives. Alternatives are good, and I dont believe that middleboxes will disappear, even when IPv6 becomes mainstream, due to security concerns of business and private users alike. Chris. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 17 16:45:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11921 for ; Sun, 17 Feb 2002 16:45:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA00159 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 16:46:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28580; Sun, 17 Feb 2002 16:15:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28535 for ; Sun, 17 Feb 2002 16:15:39 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11574 for ; Sun, 17 Feb 2002 16:15:34 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1HLF4h08883; Sun, 17 Feb 2002 13:15:04 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX27546; Sun, 17 Feb 2002 13:14:35 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA28860; Sun, 17 Feb 2002 13:15:03 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15472.7511.138421.728770@thomasm-u1.cisco.com> Date: Sun, 17 Feb 2002 13:15:03 -0800 (PST) To: EKR Cc: Michael Thomas , "Jari Arkko" , "Peterson, Jon" , "Juha Heinanen" , "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> <15470.59836.690123.189355@thomasm-u1.cisco.com> <15471.10271.471629.721017@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric Rescorla writes: > What I was trying to argue earlier was twofold: > > (1) A minimal S/MIME implementation that does essentially > what digest does would be of comparable size to digest. > (2) A message security protocol that does what we'll > eventually want will be of comparable size to S/MIME. > > Thus, we might as well bite the S/MIME bullet now. This is *far* from clear. It does not follow _at all_ that SMIME is the right vehicle for shared keys, AAA or Kerberos. Ie, the usual suspects for authentication. Kerberos, for example, already has standard mechanisms for integrity/confidentiality (krb-safe/priv) and doesn't need extra kruft around it. Dragging in SMIME for simple challenge protocols is also equally debatable. And I'll bet that the people who want AAA based authentication would probably like to see something more EAP like so that it integrates with RADIUS/DIAMETER. > > Requirement #1: no ASN.1 > > > > :-) > I trust the smiley here means that you're not serious. The amount of > code required to implement CMS EncryptedData and AuthenticatedData > (which is all that would be required to replace digest) is quite small. The smiley was because I know it's not realistic. I'm perfectly serious that ASN.1 is a pig and to be avoided. > I'm sensitive to argument (1) but I don't think that the code > size and complexity argument holds up under examination. Yes, you keep asserting this. You're a hardware designer, no? 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 daemon@optimus.ietf.org Sun Feb 17 16:48:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11952 for ; Sun, 17 Feb 2002 16:48:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA00184 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 16:49:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29178; Sun, 17 Feb 2002 16:26:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29149 for ; Sun, 17 Feb 2002 16:26:30 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11693 for ; Sun, 17 Feb 2002 16:26:25 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1HLQMio024704; Sun, 17 Feb 2002 23:26:22 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15472.8190.233199.278726@harjus.eng.song.fi> Date: Sun, 17 Feb 2002 23:26:22 +0200 To: Michael Thomas Cc: EKR , "Jari Arkko" , "Peterson, Jon" , "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: <15472.7511.138421.728770@thomasm-u1.cisco.com> References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> <15470.59836.690123.189355@thomasm-u1.cisco.com> <15471.10271.471629.721017@thomasm-u1.cisco.com> <15472.7511.138421.728770@thomasm-u1.cisco.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas writes: > And I'll bet that the > people who want AAA based authentication would > probably like to see something more EAP like > so that it integrates with RADIUS/DIAMETER. yes, it is very important that the sip authentication mechanism integrates well with eap/radius that is already used for ras, ethernet switch and wlan authentication. -- 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 daemon@optimus.ietf.org Sun Feb 17 17:02:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12175 for ; Sun, 17 Feb 2002 17:02:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA01362 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 17:02:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29751; Sun, 17 Feb 2002 16:32:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29717 for ; Sun, 17 Feb 2002 16:32:02 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11756 for ; Sun, 17 Feb 2002 16:31:57 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1HLJP001828; Sun, 17 Feb 2002 15:19:26 -0600 Message-ID: <3C701E5D.3000904@dynamicsoft.com> Date: Sun, 17 Feb 2002 15:19:25 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Hisham Khartabil CC: sip@ietf.org, jdrosen@dynamicsoft.com Subject: Re: [Sip] References in bis-07 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It looks like this was another conversion to text problem - I don't see it in the pdf. We'll make sure the next version gets it right. RjS Hisham Khartabil wrote: > Hi, > > It looks like whenever text refers to a reference beyond [18] in bin-07, it > refers to the wrong one. eg: Line 828 references [20] instead of [21] for > RFC2822. (It could be a result of adding the S/MIME reference). > > Regards, > Hisham Khartabil > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sun Feb 17 17:22:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12357 for ; Sun, 17 Feb 2002 17:22:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA01978 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 17:22:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00222; Sun, 17 Feb 2002 16:49:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00196 for ; Sun, 17 Feb 2002 16:49:13 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11965 for ; Sun, 17 Feb 2002 16:49:07 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1HLnJe42097; Sun, 17 Feb 2002 13:49:19 -0800 (PST) To: Michael Thomas Cc: "Jari Arkko" , "Peterson, Jon" , "Juha Heinanen" , "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> <15470.59836.690123.189355@thomasm-u1.cisco.com> <15471.10271.471629.721017@thomasm-u1.cisco.com> <15472.7511.138421.728770@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 17 Feb 2002 13:49:18 -0800 In-Reply-To: Michael Thomas's message of "Sun, 17 Feb 2002 13:15:03 -0800 (PST)" Message-ID: Lines: 72 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > Eric Rescorla writes: > > What I was trying to argue earlier was twofold: > > > > (1) A minimal S/MIME implementation that does essentially > > what digest does would be of comparable size to digest. > > (2) A message security protocol that does what we'll > > eventually want will be of comparable size to S/MIME. > > > > Thus, we might as well bite the S/MIME bullet now. > > This is *far* from clear. It does not follow > _at all_ that SMIME is the right vehicle for > shared keys, AAA or Kerberos. Ie, the usual > suspects for authentication. Kerberos, for > example, already has standard mechanisms for > integrity/confidentiality (krb-safe/priv) and > doesn't need extra kruft around it. Dragging > in SMIME for simple challenge protocols is > also equally debatable. And I'll bet that the > people who want AAA based authentication would > probably like to see something more EAP like > so that it integrates with RADIUS/DIAMETER. I think you're confusing key exchange with messaging. The purpose of S/MIME in this context is to have a generic messaging protocol which allows multiple key exchange mechanisms. Obviously, you can save some space (though surprisingly little) by tying your messaging protocol more tightly to your key exchange. I consider that to be generally a mistake. In view of your oft-voiced desire not to pick winners, I'm surprised that you don't as well. > > > Requirement #1: no ASN.1 > > > > > > :-) > > I trust the smiley here means that you're not serious. The amount of > > code required to implement CMS EncryptedData and AuthenticatedData > > (which is all that would be required to replace digest) is quite small. > > The smiley was because I know it's not realistic. > I'm perfectly serious that ASN.1 is a pig and to > be avoided. I hear this a lot from people who don't really know that much about ASN.1. It's true that generic ASN.1 engines such as OSS are pretty piggy. However it's quite feasible to write small targeted codecs for specific protocols. > > I'm sensitive to argument (1) but I don't think that the code > > size and complexity argument holds up under examination. > > Yes, you keep asserting this. You're a hardware > designer, no? No, I'm a programmer. Moreover, I have extensive experience writing ASN.1 based systems. I've worked with at least four separate ASN.1 toolkits of various stripes, from compilers to table-driven engines and written hand-rolled decoders numerous times. I'm quite confident I could write an EncryptedData and AuthenticatedData codec in less than 1000 lines of C (Actually, I expect that 500 lines is feasible.) For reference, I'm currently looking at an X.509 engine (much more complicated than that needed for symmetric key S/MIME) that consumes about 1500 lines of Java. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Sun Feb 17 17:22:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12376 for ; Sun, 17 Feb 2002 17:22:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02060 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 17:23:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00341; Sun, 17 Feb 2002 16:51:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00304 for ; Sun, 17 Feb 2002 16:51:27 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11986 for ; Sun, 17 Feb 2002 16:51:21 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1HLpia42117; Sun, 17 Feb 2002 13:51:44 -0800 (PST) To: Juha Heinanen Cc: Michael Thomas , "Jari Arkko" , "Peterson, Jon" , "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> <15470.59836.690123.189355@thomasm-u1.cisco.com> <15471.10271.471629.721017@thomasm-u1.cisco.com> <15472.7511.138421.728770@thomasm-u1.cisco.com> <15472.8190.233199.278726@harjus.eng.song.fi> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 17 Feb 2002 13:51:44 -0800 In-Reply-To: Juha Heinanen's message of "Sun, 17 Feb 2002 23:26:22 +0200" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Juha Heinanen writes: > Michael Thomas writes: > > > And I'll bet that the > > people who want AAA based authentication would > > probably like to see something more EAP like > > so that it integrates with RADIUS/DIAMETER. > > yes, it is very important that the sip authentication mechanism > integrates well with eap/radius that is already used for ras, ethernet > switch and wlan authentication. As far as I know, it should be possible to use S/MIME messaging with a key established via these mechanisms. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Sun Feb 17 17:39:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12537 for ; Sun, 17 Feb 2002 17:39:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02959 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 17:39:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01654; Sun, 17 Feb 2002 17:11:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01623 for ; Sun, 17 Feb 2002 17:11:09 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12241 for ; Sun, 17 Feb 2002 17:11:06 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g1HMB2q23836; Sun, 17 Feb 2002 17:11:02 -0500 Message-Id: <200202172211.g1HMB2q23836@minotaur.nge.isi.edu> To: Michael Thomas cc: Rohan Mahy , sip@ietf.org Reply-To: mankin@isi.edu Subject: Re: [Sip] re: SMIME in SIP In-reply-to: Your message of Sun, 17 Feb 2002 12:33:02 -0800. <15472.4990.360439.39950@thomasm-u1.cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Sun, 17 Feb 2002 17:11:02 -0500 From: Allison Mankin Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Mike, > SIP is > not going to implode in a wave of security > scandals if e2e crypto is not put into bis. Sip bis is not even going to IETF last call if it does not have a strong end-to-end encryption and integrity capability envisioned in the specification. I hope all of the IESG will* be talked into this being a MAY this time, and not ask me to insist on a stronger level. > >Are you actually claiming that SIP without SMIME > >would be "a document with horrible security > >problems"? I sure hope not, because if you are I > >think you need to get a grip; the current PSTN > >does exactly this today, and the world has not > >come to an end. > Yes, we are. The PSTN is not the Internet. Users in the Internet world need the capabilities that S/MIME is specified to provide in the bis draft. MIME is intrinsic to SIP; S/MIME is a good match. Allison _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 17 17:56:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12678 for ; Sun, 17 Feb 2002 17:56:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03454 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 17:56:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02147; Sun, 17 Feb 2002 17:24:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02116 for ; Sun, 17 Feb 2002 17:24:42 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12394 for ; Sun, 17 Feb 2002 17:24:39 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1HMNvZ06348; Sun, 17 Feb 2002 14:23:57 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX27753; Sun, 17 Feb 2002 14:23:38 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA28875; Sun, 17 Feb 2002 14:24:06 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15472.11653.897841.940168@thomasm-u1.cisco.com> Date: Sun, 17 Feb 2002 14:24:05 -0800 (PST) To: mankin@isi.edu Cc: Michael Thomas , Rohan Mahy , sip@ietf.org Subject: Re: [Sip] re: SMIME in SIP In-Reply-To: <200202172211.g1HMB2q23836@minotaur.nge.isi.edu> References: <15472.4990.360439.39950@thomasm-u1.cisco.com> <200202172211.g1HMB2q23836@minotaur.nge.isi.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Allison Mankin writes: > Mike, > > > SIP is > > not going to implode in a wave of security > > scandals if e2e crypto is not put into bis. > > Sip bis is not even going to IETF last call if it does not > have a strong end-to-end encryption and integrity capability > envisioned in the specification. > > I hope all of the IESG will* be talked into this being a MAY > this time, and not ask me to insist on a stronger level. A paper tiger is still a paper tiger. > The PSTN is not the Internet. Users in the Internet world need > the capabilities that S/MIME is specified to provide in the > bis draft. MIME is intrinsic to SIP; S/MIME is a good match. You still have not shown where SMIME is actually being deployed widely. Surely not email which is arguably as if not more important. 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 daemon@optimus.ietf.org Sun Feb 17 18:00:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12732 for ; Sun, 17 Feb 2002 18:00:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA03867 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 18:00:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01919; Sun, 17 Feb 2002 17:21:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01888 for ; Sun, 17 Feb 2002 17:21:38 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12343 for ; Sun, 17 Feb 2002 17:21:34 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1HMK6E28668; Sun, 17 Feb 2002 14:20:06 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX27742; Sun, 17 Feb 2002 14:19:37 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA28872; Sun, 17 Feb 2002 14:20:05 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15472.11412.937773.152878@thomasm-u1.cisco.com> Date: Sun, 17 Feb 2002 14:20:04 -0800 (PST) To: EKR Cc: Michael Thomas , "Jari Arkko" , "Peterson, Jon" , "Juha Heinanen" , "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) In-Reply-To: References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> <15470.59836.690123.189355@thomasm-u1.cisco.com> <15471.10271.471629.721017@thomasm-u1.cisco.com> <15472.7511.138421.728770@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric Rescorla writes: > Michael Thomas writes: > > > Eric Rescorla writes: > > > What I was trying to argue earlier was twofold: > > > > > > (1) A minimal S/MIME implementation that does essentially > > > what digest does would be of comparable size to digest. > > > (2) A message security protocol that does what we'll > > > eventually want will be of comparable size to S/MIME. > > > > > > Thus, we might as well bite the S/MIME bullet now. > > > > This is *far* from clear. It does not follow > > _at all_ that SMIME is the right vehicle for > > shared keys, AAA or Kerberos. Ie, the usual > > suspects for authentication. Kerberos, for > > example, already has standard mechanisms for > > integrity/confidentiality (krb-safe/priv) and > > doesn't need extra kruft around it. Dragging > > in SMIME for simple challenge protocols is > > also equally debatable. And I'll bet that the > > people who want AAA based authentication would > > probably like to see something more EAP like > > so that it integrates with RADIUS/DIAMETER. > I think you're confusing key exchange with messaging. > The purpose of S/MIME in this context is to have a generic > messaging protocol which allows multiple key exchange > mechanisms. > > Obviously, you can save some space (though surprisingly little) > by tying your messaging protocol more tightly to your key > exchange. I consider that to be generally a mistake. In view > of your oft-voiced desire not to pick winners, I'm surprised > that you don't as well. Note: I'm not saying that SMIME shouldn't be considered. I'm just saying that SMIME as the ultimate answer is not a universally shared sentiment, and there's a lot of ground to cover before there's consensus on that point. > > > > > Requirement #1: no ASN.1 > > > > > > > > :-) > > > I trust the smiley here means that you're not serious. The amount of > > > code required to implement CMS EncryptedData and AuthenticatedData > > > (which is all that would be required to replace digest) is quite small. > > > > The smiley was because I know it's not realistic. > > I'm perfectly serious that ASN.1 is a pig and to > > be avoided. > I hear this a lot from people who don't really know that much > about ASN.1. It's true that generic ASN.1 engines such as > OSS are pretty piggy. However it's quite feasible to write > small targeted codecs for specific protocols. I'm well aware of that. I had to code up a BER parser in the late 80's for SNMP. It's still a pig. It takes quite a bit of effort to hand code ASN.1, and even then you get messes like MIT's Kerberos code which is not only hand coded, but bloated on top of it. > > > > I'm sensitive to argument (1) but I don't think that the code > > > size and complexity argument holds up under examination. > > > > Yes, you keep asserting this. You're a hardware > > designer, no? > No, I'm a programmer. > > Moreover, I have extensive experience writing ASN.1 based > systems. Well, I've had extensive experience developing software for embedded systems. You are grossly simplifying their considerations. For one thing, it costs lots of $$$ and time to market to deviate from off the shelf code. For another, simply saying "add more ram" belies the reality that for many low end products this far easier said than done. Moore's law eventually catches up, but adding transistors costs money and for consumer grade gear, pennies matter. The object of SIP is to be the protocol of choice for those devices. Doubling (or worse) the flash/ram footprint is going to be a bitter pill. While I have no sympathy for those who would use that as an excuse to do nothing, I have a lot of sympathy for the plight of engineers trying to cram things designed with no consideration for space/money tradeoffs into miniscule amounts of memory. 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 daemon@optimus.ietf.org Sun Feb 17 18:25:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12894 for ; Sun, 17 Feb 2002 18:25:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04573 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 18:26:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03247; Sun, 17 Feb 2002 17:48:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03216 for ; Sun, 17 Feb 2002 17:48:32 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12633 for ; Sun, 17 Feb 2002 17:48:28 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA15412; Sun, 17 Feb 2002 17:48:31 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1HMmVNB013103 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 17 Feb 2002 17:48:31 -0500 (EST) Message-ID: <3C703338.D0AB634D@cs.columbia.edu> Date: Sun, 17 Feb 2002 17:48:24 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sip@ietf.org Subject: Re: [Sip] Comments on Resource Priority Header References: <141.8518925.298090d7@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mike, thanks for your comments. Mpierce1@aol.com wrote: > > I have the following comments on draft-polk-sip-resource-01: > > General: It is suggested that statements regarding the use of the header > (i.e., definition of a service which uses the header) should be deleted from > this draft. Some of these procedures may be different for various situations > or services or depend on network policies, so this document should not state > MUST or SHOULD NOT provisions for these procedures. Agreed; see http://www.cs.columbia.edu/~hgs/sip/drafts/draft-polk-sip-resource-02.txt for the about-to-be-submitted version. > > Section 3: > > 2nd paragraph: Is it necessary for the priority values to be assigned by > IANA? After a namespace is registered, would it be sufficient for the "owner" > of that namespace to assign priority values without IANA registration? The owner should pick (so I updated the wording), but what's wrong with having them documented in the IANA registration? > > 3rd paragraph: "As a response header ..." - It is unknown where this function > would be used in the required procedures. Current requirements are that the > priority level is specified by the caller and the called party has no option > to change or reject the level. It is okay to identity that this header may > optionally be included in the response, but it should not state its actual > meaning (procedures). The following paragraph is suggested: "The resource > priority header MAY be included in a response, either with the same or > different value than the one contained in the request. The meaning of this > response value depends on the application and details are beyond the scope of > this document.." See new, slightly less wordy, wording. > > 4th paragraph: "If the header field is missing ..." should be deleted, since > this relates to the procedures for use rather than the definition of the > header itself. In some networks, this could be cause for rejecting the call > rather than defaulting to a specific value. Noted, although purists would argue that this is not SIP behavior. In SIP, you reject calls based on the explicit or implied value, not because an optional header is missing. Resource-Priority is an optional header. Suffice it to say that this difference matters. > > 5th paragraph: "The values are adopted from RFC 791 ..." and following 2 > paragraphs should be moved to go with the description of the specific levels > for the "dsn". It would probably be useful to include all information > regarding the values for the Defense Switched Network in an Annex, with a > reference to it in the IANA considerations for the initial registration. (See > final comment.) Good idea; so moved :-) > > 8th paragraph "Proxies MAY downgrade ... SHOULD NOT reject requests..." - > This should be deleted or changed since the procedures to be followed depend > on the network policies and the service being provided. For example, in the > equivalent ISDN standards today, the call is released (rejected) in this > case. The following paragraph is suggested: "Proxies MAY downgrade the > Resource-Priority of or reject unauthenticated requests. Details are specific > to each administrative domain and beyond the scope of this document." > Avoided use of 'administrative domain' and simply called it local policy. Administrative domain is not a SIP concept. > 4. IANA > > Why is a restriction needed that an existing list not be extended? If the dsn > wishes to later add a new level below "Routine", it should be allowed to do > so. The reasoning is simple: If my implementation believes it understands namespace 'foo' based on an IANA registration at the time I built the system, I shouldn't be surprised by some new value in that same name space. How can the implementation deal with this sensibly? If you say that any new value has to have priority below the current lowest one, that would indeed work. Having new values added later that fall somewhere in the middle is not possible without risking interoperability surprises. Is that what you had in mind? > > Other: Since one of the uses is "carrying information from one multi-level > domain in the telephone network, e.g., using the facilities of Q.735.3, to > another, without the SIP proxies themselves inspecting the header field", it > would be useful and efficient to preassign a single standard "namespace" of > something like "PSTN" with values of "0", "1", "2", "3", and "4" to directly Added, with slightly different wording. > Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 17 18:36:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12991 for ; Sun, 17 Feb 2002 18:36:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05240 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 18:36:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04077; Sun, 17 Feb 2002 18:08:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04046 for ; Sun, 17 Feb 2002 18:08:53 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12810 for ; Sun, 17 Feb 2002 18:08:49 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1HN8u242205; Sun, 17 Feb 2002 15:08:56 -0800 (PST) To: Michael Thomas Cc: "Jari Arkko" , "Peterson, Jon" , "Juha Heinanen" , "Jonathan Rosenberg" , "Lawrence Conroy" , "Henry Sinnreich" , Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> <15470.59836.690123.189355@thomasm-u1.cisco.com> <15471.10271.471629.721017@thomasm-u1.cisco.com> <15472.7511.138421.728770@thomasm-u1.cisco.com> <15472.11412.937773.152878@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 17 Feb 2002 15:08:55 -0800 In-Reply-To: Michael Thomas's message of "Sun, 17 Feb 2002 14:20:04 -0800 (PST)" Message-ID: Lines: 57 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > Eric Rescorla writes: > > I hear this a lot from people who don't really know that much > > about ASN.1. It's true that generic ASN.1 engines such as > > OSS are pretty piggy. However it's quite feasible to write > > small targeted codecs for specific protocols. > > I'm well aware of that. I had to code up a BER > parser in the late 80's for SNMP. It's still a > pig.> It takes quite a bit of effort to hand > code ASN.1, and even then you get messes like > MIT's Kerberos code which is not only hand > coded, but bloated on top of it. How bloated things are depends on the ASN.1 you're writing to. I'm not familiar with the SNMP ASN.1 and only vaguely familiar with the Kerberos ASN.1, but I'm VERY familiar with the S/MIME ASN.1 and it's perfectly possible to write a small codec for it, albeit while taking a little care. X.509 is a different issue, but we were discussing manual keying, so X.509 overhead isn't relevant at this moment. > Well, I've had extensive experience developing > software for embedded systems. You are grossly > simplifying their considerations. For one > thing, it costs lots of $$$ and time to market > to deviate from off the shelf code. For > another, simply saying "add more ram" belies > the reality that for many low end products this > far easier said than done. Moore's law > eventually catches up, but adding transistors > costs money and for consumer grade gear, > pennies matter. The object of SIP is to be > the protocol of choice for those devices. > Doubling (or worse) the flash/ram footprint > is going to be a bitter pill. While I have no > sympathy for those who would use that as an > excuse to do nothing, I have a lot of sympathy > for the plight of engineers trying to cram > things designed with no consideration for > space/money tradeoffs into miniscule amounts of > memory. I'm sorry, but I don't see the relevance of this. Anything we require will force the embedded guys to change something and I'm certainly in favor of making that something as minimal as possible, consistent with the requirements of decent security. What's presently at issue here is the actual impact of adding S/MIME as opposed to some non-S/MIME messaging system with similar functionality. Your argument about the piggishness of ASN.1 notwithstanding, my experience implementing such systems leads me to believe that the footprint of such a system will be roughly the same as S/MIME. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Sun Feb 17 18:49:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13088 for ; Sun, 17 Feb 2002 18:49:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05578 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 18:49:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04251; Sun, 17 Feb 2002 18:11:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04148 for ; Sun, 17 Feb 2002 18:11:19 -0500 (EST) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12828 for ; Sun, 17 Feb 2002 18:11:15 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Sun, 17 Feb 2002 15:11:15 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Adam Roach'" , "'sip@ietf.org'" Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! Date: Sun, 17 Feb 2002 15:11:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Adam, Comments on SIP-Events-02 draft: The Subscription-State header is a great improvement! Okay here are a few comments regarding error-reasons. This continues on from a discussion of error reasons from last year. Unfortunately I went away for a over a month in late December-January before Jonathan posted his response to my last email and the discussion was never concluded. I have included the last post on the thread "Alignment of sip-events and watcherinfo" on the 19th December 2001 at the bottom. Basically I disagree with Jonathan that all of error-reasons should be clumped into the "rejected". Currently "rejected" covers: - initial authorization failed - authorization failed at a later time due to change authorization policy - Event resource does not exists - Event resource no longer exists Now of course it is just an error-reason and so nothing is technically incorrect however I feel "rejected" is overloaded and that some subscribers would benefit from knowing the difference between these categories. My suggestion is that the following error-reason is needed: -- "noresource": The subscription has been terminated because the resource identified by the request-uri and/or the SUBSCRIBE request's message body is unknown or is indefinitely unavailable. Clients SHOULD NOT attempt to re-subscribe unless a "retry-after" parameter is also present. -- This reason is _quite_ different to the "rejected" description - it has nothing to do with authorization. A notifier is not required to send a terminate a subscription because a resource does not exist _NOW_ but in many cases it does make sense to do this and it needs a proper error-reason. I don't see that what Jonathan was saying is contrary to this however I disagree that the notifier should report the termination as a failure due to an authorization policy change in my mind - it has nothing to do with authorization - it is a function of the resource. I think this distinct IS important and should be included in the draft. Other comments: This is only a small nit but I think the "rejected" reason comment in 4.2.4 should be changed to state that the termination is due to a initial authorization failure OR a change in the authorization policy. It currently only says that the error-reason covers the later reason. Cheers, Robert. ---- Reproduced email .... From: Jonathan Rosenberg [jdrosen@dynamicsoft.com] Sent: 19 December 2001 19:56 To: Brian Stucker Cc: 'Fairlie-Cuninghame, Robert'; sip@ietf.org; simple@mailman.dynamicsoft.com Subject: Re: [Sip] FW: [Simple] Alignment of sip-events and watcherinfo Brian Stucker wrote: > >> -----Original Message----- From: Fairlie-Cuninghame, Robert [ >> mailto:rfairlie@nuera.com] Sent: Monday, December 10, 2001 6:48 >> PM To: 'Jonathan Rosenberg'; 'sip@ietf.org' Cc: >> 'simple@mailman.dynamicsoft.com' Subject: RE: [Sip] FW: [Simple] >> Alignment of sip-events and watcherinfo >> >> Thus both the terminated & pending reason causes should be Subscription-Expire >> reasons and not solely contained in the Event package bodies >> themselves. >> > > A subscription can be pending to an active resource, or pending to a > pending resource. The two are distinct. They are separate finite > state machines, and thus should be processed separately. The state > that the subscription is in has nothing at all to do with the state > of the resource on a basic level. The resource may cause the > subscription to be handled differently, for sure, but at a generic > sip-events level, there is no coupling in my mind. Right, I agree with Brian. Another point to show the decoupling. Robert, you used the case of a concert which has a finite start and end time, and argued that when the concert ended, so should the subscription. However, I can think of a few cases where there are useful cases for subscriptions to events that have ended like this: 1. for periodic or recurring events, I may want my subscription to be maintained until the next occurrence. I see no reason to differentiate subscription processing for objects that exist just once than for objects that exist periodically. 2. Even after the object has expired, I might like to know that, and so one could imagine useful cases for fetching the state after the object has expired, to learn just that - that is has expired. Fetching is nothing more than subscribing for an infintesimally small duration, so we are talking about subscriptions to an object that "does not exist anymore", but it still sensible to have a subscription to it. Robert suggested some more reason values: > > I made a couple in my last email (some of which you have already covered): > > - Terminated/rejected because authorization failed Thats covered by "rejected" > - Terminated because subscribed object terminated See above; I would argue that if the server wants to terminate the subscription because the object has entered a state that will no longer generate events, thats really just a change in authorization policy and would be covered by "rejected" as well. > - Terminated because subscriber requested termination. Since termination of a subscription is done through expires=0, this is the same as "timeout". > - Expired. Subscriber did not refresh subscription. "timeout" > - Terminated at request of notifier. > Changes in authorization policy -> "rejected". -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Sun Feb 17 18:52:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13129 for ; Sun, 17 Feb 2002 18:52:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05734 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 18:52:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04630; Sun, 17 Feb 2002 18:28:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04596 for ; Sun, 17 Feb 2002 18:28:54 -0500 (EST) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12930 for ; Sun, 17 Feb 2002 18:28:50 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Sun, 17 Feb 2002 15:28:50 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'sip@ietf.org'" Cc: "'adam@dynamicsoft.com'" Date: Sun, 17 Feb 2002 15:28:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Warnings headers in requests. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi all, Warning headers are currently only allowed in SIP responses. However Warning headers relate important information about errors or unknown entities in session description bodies. Given that an SDP-offer may appear in the INVITE 200 OK, doesn't it make sense that Warnings can also be placed into requests, for instance, in an ACK request. Also, are Warnings restricted only to errors stemming from application/sdp message bodies. Is it reasonable for Warning's to be used for errors stemming from other message body Content-Types? If so, given that a NOTIFY request is effectively the only reliable response to a SUBSCRIBE request, Warning headers should also be allowed in NOTIFY requests. [Here's another Last Call comment for you Adam. :)] Regards, Robert. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 17 19:06:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13289 for ; Sun, 17 Feb 2002 19:06:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA06645 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 19:06:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04691; Sun, 17 Feb 2002 18:29:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04662 for ; Sun, 17 Feb 2002 18:29:28 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12934 for ; Sun, 17 Feb 2002 18:29:23 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1HNGo001975; Sun, 17 Feb 2002 17:16:50 -0600 Message-ID: <3C7039E1.501@dynamicsoft.com> Date: Sun, 17 Feb 2002 17:16:49 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Hisham Khartabil CC: sip@ietf.org, jdrosen@dynamicsoft.com, "gonzalo.camarillo" Subject: Re: [Sip] comments and nits on bis-07 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The points below have been addressed or are being tracked. Responses for the 100rel comments will come separately. Comments inline (along with a request for Gonzalo and Jonathan to answer a couple of the questions). Hisham Khartabil wrote: > Hi, > > Line numbers refer to the pdf version. > > > -line 568: should start in a new paragraph after the full stop. > > - line 644: adress should be address > > - line 722: "is" is repeated > > - line 739: definition of UAS says that "If it generates a request later on, > it assumes the role of a user agent client for the processing of that > transaction". I think this confuses people who are trying to understand the > separate roles of a UAC and UAS. It is the UA that can act as a UAC or a > UAS, not the UAS. So a UAC is created (or something like that) > > - line 788: definition of SIP-Version. "The SIP-Version string is > case-insensitive, but implementations MUST send upper-case". Maybe I missed > earlier discussion, but if its a MUST for uppercase, why make it > case-insensitive? CI is important (we don't want sip/2.0 to mean something else). {\MUST} send uppercase improves robustness. > > - line 855: "Proxy-Authorization" repeated. > > - lines 1160 - 1161: same info is repeated in lines 1163 - 1165. > > - line 1162: why is it a MUST to try ALL contacts until a server responds? > Can a user just choose to try a subset? A subset may be used - the text has been modified to reflect that. > > - line 1207: a closing bracket is missing after (Section 25.4.14 > > - line 1211: I think a should is too strong, a client puts a Require header > there for a reason, and possibly doesn't want to or can't retry without > these required extensions. A MAY could be sufficient there. We want to encourage a retry if the request can succeed ratcheting down the requirements. In the case that a client doesn't want to or can't retry without the extension, it's got a good reason not to (hence doesn't violate the SHOULD). > > - line 1263: same as on line 1211. Actually, this statement is just a > duplicate of line 1211. > > - line 1366 - 1368: "A redirect server does not issue any SIP requests of > its own. After receiving a request other than CANCEL, the server gathers the > list of alternative locations from the location service and either returns a > final > response of class 3xx or it refuses the request." Why is the request refused > after locations have been gathered? on some occasions, requests can be > rejected before any alternate locations have been gathered. > > - line 1404: "CANCEL has no effect on a request to which a UAS has already > responded." should say "CANCEL has no effect on a request to which a UAS has > already responded to with a final response". > > - line 1407: "a UAS that receives a CANCEL request for an INVITE, but has > not yet sent a response, would "stop ringing"" should say "a UAS that > receives a CANCEL request for an INVITE, but has not yet sent a final > response, would "stop ringing"" > > -lines 1512 and 1527: line 1512 says "The following header fields MUST be > included:" and then lists the contact header in line 1527. Although it says > that zero or more contact headers, the above sentence gives the false > assumption that a contact is mandatory in a REGISTER request. > > - line 1697: why is it a MUST for a contact header to contain an "expires" > parameter? This is how the registrar communicates how much longer the binding will last back to the client. > > - line 1731 and line 1765: the call-id header in line 1731 is missing the > host part in the example (or the call-id in line 1765 has a host that > shouldn't be there). > > - line 1757: "(application/sdp if the Accept header was not present)" should > say "(application/sdp is the default if the Accept header was not present)" > > - lines 1811 - 1813: are a repeat of line 1785 to 1789. > > - line 1833: does say when the local sequence number would be set. > > - line 1847: "(it is established when the UA sends a request within the > dialog)", this needs to be more specific; which UA are we exactly referring > to? how about "(it is established when the remote UA sends a request within > the dialog)" > > - line 1861: open issue > > - line 1872: "Requests within a dialog MUST contain strictly monotonically > increasing and contiguous CSeq sequence numbers" why MUST be contiguous? its > can be a SHOULD. I agree, but this has been brought up on the list several times and the group has consistantly chosen to leave it as a MUST. Helps with debugging I guess. > > - line 1875: should say "MUST be placed into the Cseq header". ("be" is > missing). > > - line 1888: should say "MUST add a Route header". ("add" is missing). > > - line 1951 - 1953: this is a general statement about Requests within a > dialog and not just specific to UAS behaviour. I propose for it to be moved > to section 12.2 (before 12.2.1). > > - line 1967: "When a dialog is established with INVITE, it is terminated > with a BYE". I propose "When a dialog is established with INVITE, it MUST be > terminated with a BYE". Ugh - not as easy as that. The text has been changed to reflect that BYE is how termination is defined in this document, but extensions may define other mechanisms. (sip-events is one such extension). > > - line 2021: "In this specification, offers and answers can only appear in > INVITE and PRACK requests and responses". What about ACK? an answer can be > there. > > - line 2064: "excluding the tag" should be put in brackets instead of > between commas to show that this comment only belongs to the To header. > > - line 2166: section 13.3.1.2 does not talk about what happens if a 3xx is > returned with no contacts. How would that happen? The sections on generating 3xx specify returning a different response if there are no alternate URIs to try. > > - line 2189 - 2195: is that INVITE server transaction destroyed as soon as > it receives the final response or as soon as it sends the final response? > does the UAS core then directly pass retransmissions to the transport layer? > > - line 2278: what would be the reason for a UAC to send a re-INVITE with no > SDP? 3pcc among others > > - line 2285: why terminate the session, this is just a re-INVITE. The UAC > can re-INVITE yet again. Gonzalo - would you comment on this? > > - line 2296: Sections 13 and 12. Make it sections 12 and 13 :) > > - line 2327: "Once the BYE is constructed, it creates a new non-INVITE > client transaction". Who is it? maybe it should say "Once the BYE is > constructed, the UAC core creates a new non-INVITE client transaction" > > - line 2364: choose instead of chose. > > - line 2375: "The proxy SHOULD NOT send a CANCEL." Does it really mean that > a proxy SHOULD NOT initiate a CANCEL? > > - line 2394: in the .txt version, the numbers there are screwed up. > > - line 2416: in the .txt version, the words "a request" are missing after > "forwarding". > > - line 2454: "is" is repeated. > > - line 2464: section number is missing. > > - line 2475: "Otherwise, if the Request-URI contains an maddr parameter, the > Request-URI MUST be ..." could instead say "Otherwise, if the Request-URI > contains an maddr parameter the proxy is not responsible for, the > Request-URI MUST be ..." > > - line 2712: this section 16.6 contains 5 then 3 processing points, yet the > details show 10. Also the numbers for detailed steps don't follow the > numbers above. > > - line 2806: should say "1xx and 2xx responses may be involved in the > establishment of dialogs". ("of" is missing) > > - line 2811: "Since a proxy may not..." should say "Since a proxy MUST NOT" > to be precise. > > - line 2856: "to" is repeated. > > - line 2910: should the reference be to section 9? > > - line 2941: "The proxy examines the branch ID of the received request". > Which branch-id? the one in the top-most via header? there could be more > than 1 via header. > > - lines 3099 to 3100: "The transaction exists between the UA or stateful > proxy on one side of the stateless proxy, and the UA or stateful proxy on > the other side. As far as SIP transactions are concerned, stateless proxies > are effectively transparent" doesn't make sense. Should it say "The > transaction exists between the UA or stateful proxy on one side, and the UA > or stateful proxy on the other side. As far as SIP transactions are > concerned, stateless proxies are effectively transparent"? (remove "of the > stateless proxy"). > > - line 3186: "transaction to" is repeated. > > - line 3212: "Whenever a response is received by the transport, if the > transport layer finds no matching client transaction (using the rules of > Section 17.1.3), the response is passed directly to the core." Is this for a > 2xx response only? If so, it should mention that. It should also mention > what happens if transport layer received a non-2xx final response and no > matching client transaction is found. > > - line 3233: "These rules", which ones? all from the start of this section? > If so, this sentence starting from this line should be at the start of the > section. Other wise specify which rules. > > - line 3258: "what" should be changed to "to" > > - line 3275: "...SHOULD move to the "Proceeding" state." It should go on to > say that "Timer E MUST be reset to T2". > > - line 3287: why is T4 so low at 5 seconds? (maybe I missed this > discussion). Jonathan - could you answer this one? > > - line 3464: "PRACK is a normal SIP message, like BYE. As such, its own > reliability is ensured hop-by-hop through each stateful proxy". I failed to > find where that is mentioned about BYE that it is hop-by-hop. The reliability for _all_ non-INVITE transactions is hop-by-hop. That's covered in the transaction section. > > - line 3475: "...100rel. While this specification..." The .txt version ate > some of the words here. It says "100rel specification" > > - line 3478: "option tag 100rel. If the UAS is unwilling to do so, it MUST > reject the initial request with a 420 (Bad Extension)". Again, the .txt > version ate some words. it says "option tag 100rel initial request with a > 420 (Bad Extension)". > > - line 3512: "It SHOULD cease retransmissions of the reliable provisional > response". Why isn't this a MUST? > > > > That's all for now. More comments are in separate emails. > > Regards, > Hisham Khartabil > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Sun Feb 17 19:25:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13428 for ; Sun, 17 Feb 2002 19:25:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA07078 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 19:25:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06762; Sun, 17 Feb 2002 19:08:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06729 for ; Sun, 17 Feb 2002 19:08:42 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13332 for ; Sun, 17 Feb 2002 19:08:38 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1I08bh29961; Sun, 17 Feb 2002 18:08:37 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1I08bU03559; Sun, 17 Feb 2002 18:08:37 -0600 (CST) Received: from lmf.ericsson.se (rmt160211.am.ericsson.se [138.85.160.211]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA22843; Sun, 17 Feb 2002 18:08:35 -0600 (CST) Message-ID: <3C704D7E.213DA203@lmf.ericsson.se> Date: Mon, 18 Feb 2002 02:40:30 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: Hisham Khartabil , sip@ietf.org, jdrosen@dynamicsoft.com Subject: Re: [Sip] comments and nits on bis-07 References: <3C7039E1.501@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > > - line 2285: why terminate the session, this is just a re-INVITE. The UAC > > can re-INVITE yet again. > > Gonzalo - would you comment on this? > We had some discussions about this some time ago. The result was that if a transaction within a dialog fails, it means that the other end is unreachable, and thus the UA terminates the session. Therefore, we treat re-INVITE as any other mid-dialog request. Trying to re-INVITE again would probably trigger the same error as the first one (481, ICMP error ...), and we would only increase network traffic. Regards, 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 daemon@optimus.ietf.org Sun Feb 17 22:53:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17466 for ; Sun, 17 Feb 2002 22:53:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA15344 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 22:53:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13638; Sun, 17 Feb 2002 22:13:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13609 for ; Sun, 17 Feb 2002 22:13:01 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16061 for ; Sun, 17 Feb 2002 22:12:57 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1I30Q002186; Sun, 17 Feb 2002 21:00:26 -0600 Message-ID: <3C706E4A.3020009@dynamicsoft.com> Date: Sun, 17 Feb 2002 21:00:26 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Penfield CC: sip@ietf.org, Jonathan Rosenberg Subject: Re: [Sip] bis-07 comments References: <005a01c1b4a4$17a65ee0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit These are handled. (except for one point with an inline question below) RjS Bob Penfield wrote: > First I would like to express my appreciation for all the hard work of the > editors and the authors. Given the effort required to review this spec, I > can barely imagine the immense effort that has gone into producing this > document and incorporating the massive amount of comments and last minute > changes and features. This spec is truly light-years ahead of the early bis > versions in its organization and understandability. It is making the jobs of > all of us implementers easier. Thank you. > > Now that you are sufficiently buttered up (: , here are my comments. I > apologize for any repeats. > > Sec 8.1.1.3: (very minor nit) line 1011 says that the From should not > contain FQDNs, but the example at line 1025 has a FQDN. > > sec 8.1.1.7: line 1070 says CANCEL is an exception to the unique branch id > rule. Isn't ACK also an exception? > > sec 8.1.1.8: line 1103. Should the standard-track RFC rule also apply to > Proxy-Require? > > sec 8.1.3.2: lines 1140-1144. 1xx needs to be an exception to the x00 rule > since 100 has many special rules that should not apply to 101-199. > > sec 12.2.1.1: line 1888. change "and MUST a Route header" to "and MUST add a > Route header" > > sec 12.2: line 1857-1861. If the open issue (#113) of allowing overlapping > non-INVITEs is still open, I vote we should allow them. > > lines 2698-2702 describes Timer C as being a client transaction timer, yet > it no longer appears in the INVITE client transaction FSM in figure 5. Is > this really a TU timer? Would the removal of 100rel affect this? > > line 2700 and 2731 (nit) The text indicates the minimum value of Timer C is > 181 seconds. Should it be 180? > > lines 2880-2881. The text should point out that the proxy should send a > CANCEL if and when it receives a provisional response on a branch whose > client transaction is in the "calling" state. I'm not sure I know what you're suggesting. Maybe your talking about the edge where a client transaction is in calling when a proxy decides to cancel outstanding transactions (so it doesn't send an immediate cancel), but a provisional arrives before the transaction is torn down? > > sec 16.7: lines 2889-2890: A little bit more is needed here. Does the proxy > generate a 408 upstream? or just silently discard all state? CANCEL can only > be sent on branches that received a 1xx. More text added. If the branch gets torn down without sending a CANCEL, the proxy would act like the branch received a 408 (but not add it to the response context). If it is able to send a CANCEL, the final response for the INVITE (hopefully a 487) would go into the context). > > sec 17.1.2.2: lines 3275-3279. What should timer E be set to when entering > the "Proceeding" state? T2? Let it run from whatever it was set to while in Trying. Remember that this is a non-invite Client transaction, you're not really supposed to be getting provisional responses anyhow. Non-invites should complete quickly. If you _did_ receive a provisional, reset the timer, and the final response got lost, you'ld be adding T2-(however much time was left in E before you reset it) to your recovery time. > > sec 19: line 3576. This is the only mention of T3 I could find in the spec. > What is it? A vestigal feature from previous versions of the spec. It's gone now. > > sec 20.4.0.1 (line 3880) should be 20.4.1. > > sec 25: line 5440 (really minor nit) in the 4xx class, values in the 42x > range have been defined so its not just x80 upwards. > > line 5610: The startline of the example is not formatted properly > change "485 Ambiguous SIP/2.0" to "SIP/2.0 485 Ambiguous" > > line 5990: response code 409 is listed in Client-Error, but not described in > section 25. > > line 5990: response code 421 is missing from Client-Error. > > line 5991: response code 513 is missing from Server-Error. > > sec 28: lines 6047-6050. Does there need to be a provision for the case of > an I-D expiring and never becoming an RFC? If I understand the way this works this would be asking the folks who let the draft lapse to clean up their garbage. I suspect it would be wasted effort. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.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 daemon@optimus.ietf.org Sun Feb 17 23:56:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18493 for ; Sun, 17 Feb 2002 23:56:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA17447 for sip-archive@odin.ietf.org; Sun, 17 Feb 2002 23:56:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA16988; Sun, 17 Feb 2002 23:31:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA16955 for ; Sun, 17 Feb 2002 23:31:37 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17718 for ; Sun, 17 Feb 2002 23:19:23 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1I46K002295; Sun, 17 Feb 2002 22:06:31 -0600 Message-ID: <3C707DBC.1040209@dynamicsoft.com> Date: Sun, 17 Feb 2002 22:06:20 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: bernhard.honeisen@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Some Loose Routing feedback References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit responses inline bernhard.honeisen@nokia.com wrote: > Hi Editors of RFC2543bis! > > I am really facinated, that the dilemma Loose Routing vs. Strict Routing could be solved even in a backwards compatible way. Great job! > > Studying the Loose Routing approach more deeply, I'd have the > following feeback: > (I am referring line numbers in the pdf version.) > > - 2464: LaTeX mistake. I guess the \ref tag is miss-spelled. > > - 2508-2509 and 2598-2600 might be somewhat confusing concerning > in which situations it is allowed to push route headers This might be less confusing with the latest text that more clearly distinguishes determining targets from determining the next hop in the route. Retargetting (2508 now talks about adding URIs to a target set based on the abstract location service) and pushing new routes are independent. > > - The example in section 16.11.1.2 maybe should have the > following configuration: p1;lr, p2;lr; p3; p4;lr > > Then it would show a difference in the processing, if after > a strict router, there follow two loose routers. > The processing descibed in 3048-3050, would have to deal with > the case, if there is a Route header present in the outgoing > request. This make the example more general. > > I propose to modify section 16.11.1.2 to something like the following: > > ---BEGIN--- > > 16.11.1.2 Traversing a strict-routing proxy > > In this scanario, a dialog is established across four proxies, each > of which adds Record-Route header field values. The third proxy > implements the strict-routing proceedures specified in RFC2543 and > the bis drafts up to bis-05. > > > U1->P1->P2->P3->P4>U2 > > > > The INVITE arriving at U2 contains > > INVITE sip:callee@u2.domain.com SIP/2.0 > Contact: sip:caller@u1.example.com > Record-Route: > Record-Route: > Record-Route: > Record-Route: > > > > Which U2 responds to with a 200 OK. Later, U2 sends the following BYE > to P4 based on the first Route header field value. > > > BYE sip:caller@u1.example.com SIP/2.0 > Route: > Route: > Route: > Route: > > > > P4 is not responsible for the resource indicated in the Request-URI > so it will leave it alone. It notices that it is the element in the > first Route header field value so it removes it. It then prepares to > send the request based on the now first Route header field value of > sip:p3.middle.com, but it notices that this URI does not contain the > lr parameter, so before sending, it reformats the request to be: > > > BYE sip:p3.middle.com SIP/2.0 > Route: > Route: > Route: > > > > P3 is a strict router, so it forwards the following to P2: > > BYE sip:p2.looser.com;lr SIP/2.0 > Route: > Route: > > > P2 sees the request-URI is a value it placed into a Record-Route > header field, so before further processing, it rewrites the request > to be > > > BYE sip:caller@u1.example.com SIP/2.0 > Route: > > /*** I guess this is the intended behaviour ***/ Yes! > > and sends the request to P1 based on the first Route header field value. > > > P1 notices that it is the element in the first Route header field > value so it removes it. > Since P1 is not responsible for u1.example.com and there is no Route > header field, P1 will forward the request to u1.example.com based on > the Request-URI: > > > BYE sip:caller@u1.example.com SIP/2.0 > > ---END--- > > > I hope there no mistakes...:-) Nope - I'm making the suggested changes to the example. > > > - I was thinking, whether a marking of the intended destination > (e.g. ;fd ) makes the backwards compatibility mechanisms for > loose/strict routing more robust. I am not yet sure, whether > this really helps in anything. I was thinking about cases, > where the final destination disappears due to a wrong proxy > operation or is otherwise absent. Just something to think about... Well - there's a whole universe of ways that things can go bad if some element starts violating protocol. In general, we don't address these (because it truly is an unbounded problem). Further, with the exception of dealing with strict-routing elements, any time something puts a URI in the Request-URI, as far as its concerned, it _is_ indicating the intended destination, so I don't know where an ;fd would get introduced. A variation of your suggestion is making URIs provided by endpoints as the Contact in a dialog initiating request/response syntactically special. I haven't found a compelling reason to do that yet. > > > That's all for now. Maybe I find some more things later... Thanks for the feedback. > > Have fun! > > cheers, > Bernie > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Mon Feb 18 01:16:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19300 for ; Mon, 18 Feb 2002 01:16:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA00159 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 01:16:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18661; Mon, 18 Feb 2002 00:29:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18631 for ; Mon, 18 Feb 2002 00:28:57 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18799 for ; Mon, 18 Feb 2002 00:28:55 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1I5GH002356; Sun, 17 Feb 2002 23:16:17 -0600 Message-ID: <3C708E20.70808@dynamicsoft.com> Date: Sun, 17 Feb 2002 23:16:16 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Hisham Khartabil CC: sip@ietf.org, jdrosen@dynamicsoft.com Subject: Re: [Sip] Comments on section 19 Transport in bis-07 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit These are addressed or are being tracked. One comment inline. RjS Hisham Khartabil wrote: > Hi, > > I decided to divide my comments into sections, the earlier email I sent > seemed to be too long. > > Line numbers refer to the pdf version. > > Section 19.1.2 > - line 3634: "the response MUST be rejected". Better if it says "the > response MUST be silently discarded". > > - lines 3635 to 3639: talks about how the response should be passed to the > core if no client transaction is found. Is this a potential DoS attack? In and of itself, no. If the core unduly creates state based on these messages, maybe. The sections on the cores discuss these cases. Proxies statelessly forward the responses for example. > > Section 19.2.2 > - line 3668: "If that connection is no longer open, the server MAY open a > connection to the IP address in the received parameter,". MAY? what other > options does the server have if it longer has the connection open? I think > this MAY should be a MUST. > > - line 3671: should SSL be SCTP instead? > > - line 3680: "If this fails, e.g., elicits an ICMP "port unreachable" > response, send the response to the address in the "sent-by" parameter." Is > sending the response to the address in the "sent-by" a MUST or SHOULD?. > Maybe better read "If this fails, e.g., elicits an ICMP "port unreachable" > response, the response MUST (SHOULD) be to the address in the "sent-by" > parameter.". > > Section 19.3 > - line 3689: "If the message is a response, it MUST be discarded. If its a > request, the element SHOULD generate a 400 class response". which response > exactly? the 400 itself? if so, the word "class" should be removed from that > sentence and (Bad Request) should be added. > > Regards, > Hisham Khartabil > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Mon Feb 18 01:28:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19423 for ; Mon, 18 Feb 2002 01:28:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA00413 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 01:28:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20411; Mon, 18 Feb 2002 01:01:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20380 for ; Mon, 18 Feb 2002 01:01:40 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19119 for ; Mon, 18 Feb 2002 01:01:37 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1I5mn002394; Sun, 17 Feb 2002 23:48:51 -0600 Message-ID: <3C7095C0.3040403@dynamicsoft.com> Date: Sun, 17 Feb 2002 23:48:48 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Hisham Khartabil CC: sip@ietf.org, jdrosen@dynamicsoft.com Subject: Re: [Sip] Comments on section 23 Common Message Components and section 24 Header Fields in bis-07 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit These comments have been addressed. One comment below. RjS Hisham Khartabil wrote: > Line numbers refer to the pdf version. > > Section 23.1.4 > - line 4763: "A URI omitting the optional port component will match a URI > explicitly declaring port 5060." will now read "A URI omitting the optional > port component will NOT match a URI explicitly declaring port 5060". Just to > save Jonathan some time. > > - line 4769: is now also wrong about the transport parameter. > > - line 4776: section number missing. > > - line 4778: example is now wrong. > > - line 4785: I thought this example was wrong also until I realised that the > "&priority=urgent" is missing from the .txt version but not the pdf (in the > first uri). There seems to be a few of those. > > Section 23.1.5 > - line 4810: "an" should be "a". > > line 4830: "headerRequire" should be just "Require". > > Section 24.7 > - line 5006: extra CRLF > > Section 24.11 > - line 5070: extra CRLF > > Section 26.16 > - It should mention that the method part of the Cseq is case-sensitive. > > Section 24.22 > - Should mention the recommended value for max-forwards (70). > > Section 24.26 > - is there a default value or behaviour if the Priority header is not > present. eg: which message has higher priority? a message with Priority > header of "urgent", or a message with no priority header? I suggest > "normal". Added SHOULD be treated as "non-urgent" to align with callerprefs. > > Section 24.44 > - line 5373: "as shown in the second example below". This is talking about > example in line 5382. But I was confused where the LWS is since I was > looking at the second example of the via header directly below this > sentence. Perhaps it should say "as shown in an example later in this > section". Or simply add some LWS in the second via. > > > Regards, > Hisham Khartabil > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Mon Feb 18 01:51:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19631 for ; Mon, 18 Feb 2002 01:51:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA01558 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 01:51:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29242; Mon, 18 Feb 2002 01:14:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29105 for ; Mon, 18 Feb 2002 01:14:17 -0500 (EST) Received: from hotmail.com ([207.68.163.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19268 for ; Mon, 18 Feb 2002 01:14:14 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 17 Feb 2002 22:13:47 -0800 Received: from 64.156.36.18 by sea1fd.sea1.hotmail.msn.com with HTTP; Mon, 18 Feb 2002 06:13:46 GMT X-Originating-IP: [64.156.36.18] From: "John Hearty" To: sip@ietf.org Date: Sun, 17 Feb 2002 23:13:46 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Feb 2002 06:13:47.0167 (UTC) FILETIME=[6CDA9AF0:01C1B843] Subject: [Sip] Final bis-07 nits Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org These are probabally too late for bis-08, but here they are. I included my previous lists of bis-07 nits for a full reference. >1. Line 333 begins: "SIP does not provide services." Line 343 goes on to >state "The nature of the services provided by SIP...", looks like the >latter sentence needs to be wordsmithed. > >2. Max-Forwards brief description is needed after line 406. > >3. Line 429, 430 and 434 reference "IP address" included in the Via's, this >should be changed to domain, or just "address". > >4. Lines 456-458, the Via headers need received= parameters. > >5. Line 567, FSM not defined. > >6. Line 644, "adress-of-record" should be "address-of-record". > >7. Line 980, "this by done" should be "this be done". > >8. Line 994, "the domain the right hand side" should be "the domain to the >right hand side". > >9. Text version text corresponding to line 1093 is missing a period after >"100rel" similar to corruption corrected in other sections. > >10. Do a global replace on proceedures with procedures. Multiple >occurences throughout doc. > >11. Line 1124, "as way to" should be "as a way to". > >12. Line 1137, is timeout the ONLY thing the TU will see? What happens >when an ICMP host unreachable is returned? Does that not get to the TU? >Related to this, should line 1170 "or network timeouts" be "or network >failures"? (Reported in bis-06 nits, response was change didn't make it >into bis-07, bug opened) > >13. Line 1207, reference section missing closing ")". > >14. Line 1407, suggest changing "has not yet sent a response" to "has not >yet sent a final response". > >15. Section 10.1 of the text version has a space before a comma in three >places. PDF version is OK (lines 1481-1483). Reported this for bis-06, >response was this is a text conversion problem, but keep reporting when >seen. > >16. Line 1645 indicates a registrar SHOULD authenticate the UAC, but >section 26.1 does not show this. Suggestion: if this is not included for >brevity reasons, perhaps just a note in section 26.1 indicating >authentication should also be done. > >17. Lines 1653-1654 are indented in PDF version, but not in txt version. >Reported for other sections in bis-06, response was this is a text >conversion problem, but keep reporting when seen. Other instances of this >problem: lines 1679-1684, 1691, 2438-2439, 2553-2554, 2581-2584, 2592, >2615-2618, 2623, 2628-2630, 2642-2644, 2749-2752, 2769-2774, 2822-2827. > >18. Line 1655, "field of request" should be "field of the request". > >19. Line 1662, "a Expires" should be "an Expires". > >20. Line 1728, Via header not changed to Recommended FQDN. Noted this for >examples in section 26 of bis-06, response is bug entered, I guess this can >be added to that. Problem also seen on line 1762. Also, if these get >changed to FQDNs for responses, remember to also add received= parameter. > >21. Line 1780, "a two user agents" should be "two user agents". > >22. Line 1861, is this open issue considered resolved? Delete line if so. > >23. Line 1888, "MUST a Route header" should be "MUST include a Route >header". > >24. Line 1918, "recieves" should be "receives". > >25. Line 1920, "for the a request" should be "for a request". > >26. Sections 13.2.1 and 13.3.1.4 indicate Allow and Supported headers >SHOULD be present in an Invite and 2xx, respectively, but the example in >26.2 does not contain these. If these are added, the example would no >longer have the minimum set described in section 4 which references section >26.2. Suggestion: if headers are added, include a small note explaining >the difference with section 4. Otherwise, include a note that the headers >normally SHOULD be included. > >27. Line 2035, "send" should be "sent". > >28. Line 2037, "this means the a UAS" should be "this means a UAS". > >29. The text version has indented text corresponding to PDF version lines >2270-2272 which is not indented. Reported same problem in bis-06, response >was this is a text conversion problem, but keep reporting when seen. Same >problem for lines 2296-2298. > >30. The text in section 16.2 of the text version corresponding with lines >2394-2397 has the formatting corrupted, with ".IP" stuffed in three times. > >31. Line 2416 has "a request." which is missing in corresponding text >version section 16.3. > >32. Figure 3 on page 63 of PDF version has no title identifying it. OK in >txt version. > >33. Lines 2438-2439, not sure if this note should be included when this >becomes an RFC. > >34. Line 2464, bad section reference. > >35. Line 2604, "unless it known" should be "unless it is known". > >36. Line 2856, "to to" should be "to". > >37. Line 2889, what is the point of resetting timer C when it expires? >Expiring timers normally invoke some action other than simply resetting the >timer. > >38. Lines 2968-2973 have both bullets and step numbers. > >39. Line 3058, "U1 receives" should be "U1 sends" > >40. Line 3061, "P1 its location service" should be "P1 uses its location >service". > >41. The sentence in 3222-3223 is saying the same thing as the sentence in >3225-3226. Seggest the first be deleted (the latter includes explanatory >text following it). > >42. Lines 3230-3231, "that that" should be "that". > >43. Lines 3290-3291 states "As with client transactions, this is needed to >ensure reliability of the 2xx responses to INVITE." But this section is >discussing non-INVITE Client Transaction. > >44. Line 3301-3302 states "A response which matches a transaction matched >by a previous response is considered a retransmission of that response." >This would seem to be false when considering provisionals then a final >response received. > >45. Section 17.2.1 Figure 7 title is too low, overwriting the page footer. >Same for figure 8 under section 17.2.2. Reported for bis-06, bug opened. > >46. Figure 8 in the txt version has it's title wrapped to the first line of >the next page. 47. Line 3396, "header field the request" should be "header field of the request". 48. Line 3391, "the the" should be "the". 49. Section 18.1 and 18.2 in the text version has missing/corrupted text after "100rel" in several places. 50. Line 3565, it is not clear why square braces are needed here. 51. Line 3634, suggest "rejected" be replaced with "discarded" or "ignored", as rejected implies some action to the sender of the response. 52. Line 3696, sentence starts out singular, becomes plural at end of line. Suggest changing "A host" to Host". 53. Line 3890 in PDF has section 20.4.0.1, txt version correctly shows 20.4.1. 54. Line 3894, "that the" should be "the". 55. Line 3942, "limitated" should be "limited". 56. Line 4036 text "뭆MIMECapabilities� attribute." is missing in the txt version. 57. Line 4405 text "an S/MIME certificates," not clear if this should be singular or plural. 58. Line 4641 text "These tokens, and some of the tokens in their expansions," missing in the txt version. 59. Lines 4677-4681 and 4697-4700 are indented in PDF, not in txt. 60. Line 4771 missing a leading dash. 61. Line 4776 has bad section link. 62. Section 24.22, since Max-Forwards is now a mandatory header and rather long, it should get a compact form defined at some point. 63. Line 5301, I believe the section 13 reference should be 16. 64. Line 5342, not clear section 13 reference is correct. 65. Line 5595 reference to section 3 is incorrect. 66. Section 26.2 needs received parm added to Via headers of forwarded messages with FQDNs. John Hearty Level3 _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.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 daemon@optimus.ietf.org Mon Feb 18 02:01:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21283 for ; Mon, 18 Feb 2002 02:01:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA02466 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 02:01:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00455; Mon, 18 Feb 2002 01:29:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00426 for ; Mon, 18 Feb 2002 01:29:53 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19461 for ; Mon, 18 Feb 2002 01:29:48 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1I6Gs002422; Mon, 18 Feb 2002 00:16:55 -0600 Message-ID: <3C709C56.7000107@dynamicsoft.com> Date: Mon, 18 Feb 2002 00:16:54 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: John Hearty CC: sip@ietf.org Subject: Re: [Sip] Final bis-07 nits References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gaah! No - not too late. I'm on 'em... RjS John Hearty wrote: > These are probabally too late for bis-08, but here they are. I included > my previous lists of bis-07 nits for a full reference. > > >> 1. Line 333 begins: "SIP does not provide services." Line 343 goes on >> to state "The nature of the services provided by SIP...", looks like >> the latter sentence needs to be wordsmithed. >> >> 2. Max-Forwards brief description is needed after line 406. >> >> 3. Line 429, 430 and 434 reference "IP address" included in the Via's, >> this should be changed to domain, or just "address". >> >> 4. Lines 456-458, the Via headers need received= parameters. >> >> 5. Line 567, FSM not defined. >> >> 6. Line 644, "adress-of-record" should be "address-of-record". >> >> 7. Line 980, "this by done" should be "this be done". >> >> 8. Line 994, "the domain the right hand side" should be "the domain to >> the right hand side". >> >> 9. Text version text corresponding to line 1093 is missing a period >> after "100rel" similar to corruption corrected in other sections. >> >> 10. Do a global replace on proceedures with procedures. Multiple >> occurences throughout doc. >> >> 11. Line 1124, "as way to" should be "as a way to". >> >> 12. Line 1137, is timeout the ONLY thing the TU will see? What >> happens when an ICMP host unreachable is returned? Does that not get >> to the TU? Related to this, should line 1170 "or network timeouts" be >> "or network failures"? (Reported in bis-06 nits, response was change >> didn't make it into bis-07, bug opened) >> >> 13. Line 1207, reference section missing closing ")". >> >> 14. Line 1407, suggest changing "has not yet sent a response" to "has >> not yet sent a final response". >> >> 15. Section 10.1 of the text version has a space before a comma in >> three places. PDF version is OK (lines 1481-1483). Reported this for >> bis-06, response was this is a text conversion problem, but keep >> reporting when seen. >> >> 16. Line 1645 indicates a registrar SHOULD authenticate the UAC, but >> section 26.1 does not show this. Suggestion: if this is not included >> for brevity reasons, perhaps just a note in section 26.1 indicating >> authentication should also be done. >> >> 17. Lines 1653-1654 are indented in PDF version, but not in txt >> version. Reported for other sections in bis-06, response was this is >> a text conversion problem, but keep reporting when seen. Other >> instances of this problem: lines 1679-1684, 1691, 2438-2439, >> 2553-2554, 2581-2584, 2592, 2615-2618, 2623, 2628-2630, 2642-2644, >> 2749-2752, 2769-2774, 2822-2827. >> >> 18. Line 1655, "field of request" should be "field of the request". >> >> 19. Line 1662, "a Expires" should be "an Expires". >> >> 20. Line 1728, Via header not changed to Recommended FQDN. Noted this >> for examples in section 26 of bis-06, response is bug entered, I guess >> this can be added to that. Problem also seen on line 1762. Also, if >> these get changed to FQDNs for responses, remember to also add >> received= parameter. >> >> 21. Line 1780, "a two user agents" should be "two user agents". >> >> 22. Line 1861, is this open issue considered resolved? Delete line if >> so. >> >> 23. Line 1888, "MUST a Route header" should be "MUST include a Route >> header". >> >> 24. Line 1918, "recieves" should be "receives". >> >> 25. Line 1920, "for the a request" should be "for a request". >> >> 26. Sections 13.2.1 and 13.3.1.4 indicate Allow and Supported headers >> SHOULD be present in an Invite and 2xx, respectively, but the example >> in 26.2 does not contain these. If these are added, the example would >> no longer have the minimum set described in section 4 which references >> section 26.2. Suggestion: if headers are added, include a small note >> explaining the difference with section 4. Otherwise, include a note >> that the headers normally SHOULD be included. >> >> 27. Line 2035, "send" should be "sent". >> >> 28. Line 2037, "this means the a UAS" should be "this means a UAS". >> >> 29. The text version has indented text corresponding to PDF version >> lines 2270-2272 which is not indented. Reported same problem in >> bis-06, response was this is a text conversion problem, but keep >> reporting when seen. Same problem for lines 2296-2298. >> >> 30. The text in section 16.2 of the text version corresponding with >> lines 2394-2397 has the formatting corrupted, with ".IP" stuffed in >> three times. >> >> 31. Line 2416 has "a request." which is missing in corresponding text >> version section 16.3. >> >> 32. Figure 3 on page 63 of PDF version has no title identifying it. >> OK in txt version. >> >> 33. Lines 2438-2439, not sure if this note should be included when >> this becomes an RFC. >> >> 34. Line 2464, bad section reference. >> >> 35. Line 2604, "unless it known" should be "unless it is known". >> >> 36. Line 2856, "to to" should be "to". >> >> 37. Line 2889, what is the point of resetting timer C when it >> expires? Expiring timers normally invoke some action other than >> simply resetting the timer. >> >> 38. Lines 2968-2973 have both bullets and step numbers. >> >> 39. Line 3058, "U1 receives" should be "U1 sends" >> >> 40. Line 3061, "P1 its location service" should be "P1 uses its >> location service". >> >> 41. The sentence in 3222-3223 is saying the same thing as the sentence >> in 3225-3226. Seggest the first be deleted (the latter includes >> explanatory text following it). >> >> 42. Lines 3230-3231, "that that" should be "that". >> >> 43. Lines 3290-3291 states "As with client transactions, this is >> needed to ensure reliability of the 2xx responses to INVITE." But >> this section is discussing non-INVITE Client Transaction. >> >> 44. Line 3301-3302 states "A response which matches a transaction >> matched by a previous response is considered a retransmission of that >> response." This would seem to be false when considering provisionals >> then a final response received. >> >> 45. Section 17.2.1 Figure 7 title is too low, overwriting the page >> footer. >> Same for figure 8 under section 17.2.2. Reported for bis-06, bug opened. >> >> 46. Figure 8 in the txt version has it's title wrapped to the first >> line of the next page. > > > 47. Line 3396, "header field the request" should be "header field of the > request". > > 48. Line 3391, "the the" should be "the". > > 49. Section 18.1 and 18.2 in the text version has missing/corrupted text > after "100rel" in several places. > > 50. Line 3565, it is not clear why square braces are needed here. > > 51. Line 3634, suggest "rejected" be replaced with "discarded" or > "ignored", as rejected implies some action to the sender of the response. > > 52. Line 3696, sentence starts out singular, becomes plural at end of > line. Suggest changing "A host" to Host". > > 53. Line 3890 in PDF has section 20.4.0.1, txt version correctly shows > 20.4.1. > > 54. Line 3894, "that the" should be "the". > > 55. Line 3942, "limitated" should be "limited". > > 56. Line 4036 text "'SMIMECapabilities' attribute." is missing in the > txt version. > > 57. Line 4405 text "an S/MIME certificates," not clear if this should be > singular or plural. > > 58. Line 4641 text "These tokens, and some of the tokens in their > expansions," missing in the txt version. > > 59. Lines 4677-4681 and 4697-4700 are indented in PDF, not in txt. > > 60. Line 4771 missing a leading dash. > > 61. Line 4776 has bad section link. > > 62. Section 24.22, since Max-Forwards is now a mandatory header and > rather long, it should get a compact form defined at some point. > > 63. Line 5301, I believe the section 13 reference should be 16. > > 64. Line 5342, not clear section 13 reference is correct. > > 65. Line 5595 reference to section 3 is incorrect. > > 66. Section 26.2 needs received parm added to Via headers of forwarded > messages with FQDNs. > > > John Hearty > Level3 > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.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 daemon@optimus.ietf.org Mon Feb 18 02:34:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27863 for ; Mon, 18 Feb 2002 02:34:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA04121 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 02:34:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02571; Mon, 18 Feb 2002 02:02:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02540 for ; Mon, 18 Feb 2002 02:02:09 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22543 for ; Mon, 18 Feb 2002 02:02:06 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1I6nZ002473; Mon, 18 Feb 2002 00:49:35 -0600 Message-ID: <3C70A3FF.1010402@dynamicsoft.com> Date: Mon, 18 Feb 2002 00:49:35 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: John Hearty CC: sip@ietf.org Subject: Re: [Sip] Final bis-07 nits References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Done - two comments below. RjS John Hearty wrote: > These are probabally too late for bis-08, but here they are. I included > my previous lists of bis-07 nits for a full reference. (trimmed to the new nits) > 47. Line 3396, "header field the request" should be "header field of the > request". YM 3386 :P - got it. > > 48. Line 3391, "the the" should be "the". > > 49. Section 18.1 and 18.2 in the text version has missing/corrupted text > after "100rel" in several places. > > 50. Line 3565, it is not clear why square braces are needed here. > > 51. Line 3634, suggest "rejected" be replaced with "discarded" or > "ignored", as rejected implies some action to the sender of the response. > > 52. Line 3696, sentence starts out singular, becomes plural at end of > line. Suggest changing "A host" to Host". > > 53. Line 3890 in PDF has section 20.4.0.1, txt version correctly shows > 20.4.1. > > 54. Line 3894, "that the" should be "the". > > 55. Line 3942, "limitated" should be "limited". > > 56. Line 4036 text "'SMIMECapabilities' attribute." is missing in the > txt version. > > 57. Line 4405 text "an S/MIME certificates," not clear if this should be > singular or plural. > > 58. Line 4641 text "These tokens, and some of the tokens in their > expansions," missing in the txt version. > > 59. Lines 4677-4681 and 4697-4700 are indented in PDF, not in txt. > > 60. Line 4771 missing a leading dash. > > 61. Line 4776 has bad section link. > > 62. Section 24.22, since Max-Forwards is now a mandatory header and > rather long, it should get a compact form defined at some point. Deployed things wouldn't understand the compact form. Bad things would happen. > > 63. Line 5301, I believe the section 13 reference should be 16. > > 64. Line 5342, not clear section 13 reference is correct. > > 65. Line 5595 reference to section 3 is incorrect. > > 66. Section 26.2 needs received parm added to Via headers of forwarded > messages with FQDNs. > > > John Hearty > Level3 > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.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 daemon@optimus.ietf.org Mon Feb 18 02:47:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27952 for ; Mon, 18 Feb 2002 02:47:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA04531 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 02:47:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03182; Mon, 18 Feb 2002 02:18:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03153 for ; Mon, 18 Feb 2002 02:18:32 -0500 (EST) Received: from yourwebsite.com (adsl-208-189-133-219.dsl.hstntx.swbell.net [208.189.133.219]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27718 for ; Mon, 18 Feb 2002 02:18:28 -0500 (EST) From: WC-4128@myhealthyamericacard.com Message-Id: <200202180718.CAA27718@ietf.org> Reply-To: WC-4128@myhealthyamericacard.com To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Mon, 18 Feb 2002 01:21:39 -0600 Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Medical
 
Medical Problems?
Pre-Existing Medical Conditions?
Smoker?
Overweight?
Can't Qualify For Health Insurance?
Lost Your Job?
Do You Need Immediate Coverage?
 
Can You Afford $50.00 Per Month To Get No Out-Of-Pocket Family Coverage from the best PPO medical provider based discount services in the country? 

Click Here To Check It Out

Note: This e-mail is a one-time advertisement for an affordable PPO like health program sent from the source provider. It is not a bulk mail advertising program and is only being sent once. There is no need to remove this from any mailing list.  

 

The HealthyAmericaCard - The Next Best Thing To Insurance
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 18 03:03:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28141 for ; Mon, 18 Feb 2002 03:03:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA05576 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 03:03:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03516; Mon, 18 Feb 2002 02:28:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03485 for ; Mon, 18 Feb 2002 02:28:34 -0500 (EST) Received: from web20104.mail.yahoo.com (web20104.mail.yahoo.com [216.136.226.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27779 for ; Mon, 18 Feb 2002 02:28:31 -0500 (EST) Message-ID: <20020218072833.59274.qmail@web20104.mail.yahoo.com> Received: from [63.253.86.32] by web20104.mail.yahoo.com via HTTP; Sun, 17 Feb 2002 23:28:33 PST Date: Sun, 17 Feb 2002 23:28:33 -0800 (PST) From: Danyuu Wuu To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] SIP-TLS Travesty (another perspective) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Here is what I don't seem to understand about SIP and TLS. SIP is trying to make TLS a 'MUST'. I feel this prevents individuals from hosting their own SIP domains. One has to go through hoops to get a certificate from Verisign etc. etc. Actually as an individual you simply cannot get a security certificate (type 3?). Even as a business there are some requirements before a cert is issued. Once issued you must pay $400/year maintenance fees. I can host an SMTP server and a web server BUT I will never be able to host a SIP domain for myself without jumping through hoops and paying dearly. Is that not a SIP travesty. I think SIP-TLS cannot be a 'MUST' in the base protocol. In fact TLS has no business to be in the base protocol. Please keep that for "sips:". Remember SSL is an exception on the Internet, not a rule. SIP is making everyone run in the opposite direction by making TLS a 'MUST'. Please do not create requirements that create second class citizens on the Internet. Internet is meant to level the playing field! My SMTP server at no cost will work with Yahoo/MSN etc. Why not SIP? Why do I need to be a business to do SIP. On another note regarding TLS: When I communicate with a brokerage account I simply do not want my transactions to be decrypted and re-encrypted by proxies along the path. It creates a problem of accountability. I guess not one is thinking about accountability when designing security for SIP. Too many un-thought out stuff is being rammed into the bis :-( I would like to see all of security stuff out of the SIP base protocol and security as an extension. Please don't force security on the protocol. -Danyu __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.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 daemon@optimus.ietf.org Mon Feb 18 03:30:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28500 for ; Mon, 18 Feb 2002 03:30:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA06671 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 03:30:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04776; Mon, 18 Feb 2002 02:55:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04746 for ; Mon, 18 Feb 2002 02:55:20 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27998 for ; Mon, 18 Feb 2002 02:55:17 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1I7tc6Y005688; Mon, 18 Feb 2002 02:55:38 -0500 (EST) Message-ID: <3C70B342.B41FDE48@dynamicsoft.com> Date: Mon, 18 Feb 2002 02:54:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Danyuu Wuu CC: sip@ietf.org Subject: Re: [Sip] SIP-TLS Travesty (another perspective) References: <20020218072833.59274.qmail@web20104.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit please note that at 3am in the morning, my sarcasm levels are extremely high. Responses inline. Danyuu Wuu wrote: > > Here is what I don't seem to understand about SIP > and TLS. SIP is trying to make TLS a 'MUST'. > I feel this prevents individuals from hosting > their own SIP domains. One has to go through hoops > to get a certificate from Verisign etc. etc. > Actually as an individual you simply cannot get a > security certificate (type 3?). Even as a business > there are some requirements before a cert is issued. > Once issued you must pay $400/year maintenance fees. > > I can host an SMTP server and a web server BUT I will > never be able to host a SIP domain for myself without > jumping through hoops and paying dearly. Is > that not a SIP travesty. I think SIP-TLS cannot > be a 'MUST' in the base protocol. In fact TLS > has no business to be in the base protocol. Please > keep that for "sips:". What I think is a travesty are people who don't read the specifications carefully before whining about whats in them. TLS is mandatory for proxies, yes. However, what you are complaining about is site certificates. For proxies, site certificates are a SHOULD, not a MUST. Thus, you can build a compliant SIP proxy that doesn't have site certs if you have good reason not to. > > Remember SSL is an exception on the Internet, not > a rule. You must be kidding, right? So you think secure web sites are bad?? > SIP is making everyone run in the opposite > direction by making TLS a 'MUST'. TLS itself is easy on a server, there are many free implementations. Please. > > Please do not create requirements that create second > class citizens on the Internet. > Internet is meant to level the playing field! My SMTP > server at no cost will work with Yahoo/MSN etc. Why > not SIP? Why do I need to be a > business to do SIP. More whining without proper reading. > > On another note regarding TLS: When I communicate with > a brokerage account I simply do not > want my transactions to be decrypted and re-encrypted > by proxies along the path. It creates a problem of > accountability. You really have to be kidding now. You know what I hate, when I communicate with my brokerage house, and someone modifies my transaction mid-stream, so that it is not accounted properly at the server. It creates a problem of accountability. > > I guess not one is thinking about accountability when > designing security for SIP. I guess you are not bothering to read specifications before you post snide remarks like this to the list. > > Too many un-thought out stuff is being rammed into the > bis :-( Funny that, TLS has been in bis for a very, very long time. Even funnier is how much un-thought out stuff is being rammed into late comments, taking away my time, and those of the other editors, from the many hundreds of other useful comments :-( > > I would like to see all of security stuff out of the > SIP base protocol and security as an extension. Please > don't force security on the protocol. Ah, so you want to: 1. guarantee that sip gets laughed off the iesg agenda, right back to the working group 2. standardize a technology without sufficient security, so that when attacks do come, people suffer because of your irresponsibility 3. standardize a technology that people won't deploy in useful ways because it cannot be properly secured Sounds like a plan! Sign me up! Thank you, Danyuu, for your fine comments. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 18 04:49:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29302 for ; Mon, 18 Feb 2002 04:49:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA10285 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 04:49:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09081; Mon, 18 Feb 2002 04:22:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09054 for ; Mon, 18 Feb 2002 04:22:00 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29055 for ; Mon, 18 Feb 2002 04:21:55 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 18 Feb 2002 09:22:13 UT content-class: urn:content-classes:message Subject: RE: [Sip] note: change in URI comparison rules coming MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 18 Feb 2002 09:24:07 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <45730E094814E44488F789C1CDED27AEC552A2@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] note: change in URI comparison rules coming Thread-Index: AcG3QYU3oBsRGJuEQbqmtxh6uJcaRQBG30Qw From: "James Undery" To: "Jonathan Rosenberg" Cc: "Robert Sparks" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA09055 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > James Undery wrote: > > > > Good. > > > > Well while we're at it can I suggest we remove all default > values from > > SIP URIs. > > Whoa there partner. > > We didn't remove defaults for either port or transport; we merely said > that an explicit value does not equal the default. We still need a > default unless you want to force everyone to include them > explicitly in > each request. Sorry, I did mean just the comparison. > My reasoning would be, port and transport seemed the least > > arbitrary. The user parameter has consistently been abused; > the method > > parameter defaulting to INVITE doesn't seem so convincing in these > > SIMPLEr times; ttl does this really justify a default > parameter, if you > > insist on using multicast you should do it properly with > some thought. > > > > This also results in a far simpler comparison rule, that's > easy to grasp > > and apply. > > Sorry - are you arguing for removal of defaults, or that the default > should never equal the explicit value? That is: > > sip:user@224.3.2.2;ttl=1 > sip:user@224.3.2.2 > > would not be equal? I could be convinced to go full court on this > one.... Bingo, exactly what I intended to say. With the additional change to multicast ttl this appears to be making more sense, to me atleast. 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 daemon@optimus.ietf.org Mon Feb 18 04:54:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29373 for ; Mon, 18 Feb 2002 04:54:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA10418 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 04:54:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08931; Mon, 18 Feb 2002 04:17:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08900 for ; Mon, 18 Feb 2002 04:17:43 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29005 for ; Mon, 18 Feb 2002 04:17:38 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id g1I9GtU20363; Mon, 18 Feb 2002 10:16:55 +0100 Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.1/8.12.1) with ESMTP id g1I9GIl1013035; Mon, 18 Feb 2002 10:16:54 +0100 (MET) Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id <18JNF5BJ>; Mon, 18 Feb 2002 10:11:24 +0100 Message-ID: From: Brazier Lachlan To: "'Jonathan Rosenberg '" , Brazier Lachlan Cc: "'''sip@ietf.org' ' '" Subject: AW: AW: [Sip] CSeq question? Date: Mon, 18 Feb 2002 10:11:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B85C.3A6DC920" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B85C.3A6DC920 Content-Type: text/plain YES, woke up with the awnser this morning (knock my head...) Thanks anyway Lachlan > > I haven't read all of bis07 (bis05 - 05 either), but I so far I didn't > find a reason for the method name in the CSeq Header. It looks pretty > redundant to the method name in the request line. The reason is to handle the exceptions to the rule, CANCEL and ACK. As they have the same cseq, the method name is needed to disambiguate the responses to those requests. ------_=_NextPart_001_01C1B85C.3A6DC920 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTMuMTIiPg0KPFRJVExFPkFXOiBBVzog W1NpcF0gQ1NlcSBxdWVzdGlvbj88L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05U IFNJWkU9Mj5ZRVMsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj53b2tlIHVwIHdpdGggdGhlIGF3 bnNlciB0aGlzIG1vcm5pbmcgKGtub2NrIG15IGhlYWQuLi4pPC9GT05UPg0KPC9QPg0KDQo8UD48 Rk9OVCBTSVpFPTI+VGhhbmtzIGFueXdheTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+TGFjaGxh bjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IEkgaGF2ZW4ndCByZWFkIGFsbCBvZiBiaXMwNyAoYmlzMDUgLSAwNSBlaXRo ZXIpLCBidXQgSSBzbyBmYXIgSSBkaWRuJ3Q8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg ZmluZCBhIHJlYXNvbiBmb3IgdGhlIG1ldGhvZCBuYW1lIGluIHRoZSBDU2VxIEhlYWRlci4gSXQg bG9va3MgcHJldHR5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHJlZHVuZGFudCB0byB0 aGUgbWV0aG9kIG5hbWUgaW4gdGhlIHJlcXVlc3QgbGluZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj5UaGUgcmVhc29uIGlzIHRvIGhhbmRsZSB0aGUgZXhjZXB0aW9ucyB0byB0aGUg cnVsZSwgQ0FOQ0VMIGFuZCBBQ0suIEFzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj50aGV5IGhh dmUgdGhlIHNhbWUgY3NlcSwgdGhlIG1ldGhvZCBuYW1lIGlzIG5lZWRlZCB0byBkaXNhbWJpZ3Vh dGUgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5yZXNwb25zZXMgdG8gdGhvc2UgcmVxdWVz dHMuPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C1B85C.3A6DC920-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 18 04:59:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29413 for ; Mon, 18 Feb 2002 04:59:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA10625 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 05:00:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09942; Mon, 18 Feb 2002 04:35:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09913 for ; Mon, 18 Feb 2002 04:35:14 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29187 for ; Mon, 18 Feb 2002 04:35:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1I9ZP6Y006229; Mon, 18 Feb 2002 04:35:26 -0500 (EST) Message-ID: <3C70CAAC.D739F93D@dynamicsoft.com> Date: Mon, 18 Feb 2002 04:34:36 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Undery CC: Robert Sparks , sip@ietf.org Subject: Re: [Sip] note: change in URI comparison rules coming References: <45730E094814E44488F789C1CDED27AEC552A2@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit James Undery wrote: > > > Sorry - are you arguing for removal of defaults, or that the default > > should never equal the explicit value? That is: > > > > sip:user@224.3.2.2;ttl=1 > > sip:user@224.3.2.2 > > > > would not be equal? I could be convinced to go full court on this > > one.... > > Bingo, exactly what I intended to say. With the additional change to > multicast ttl this appears to be making more sense, to me atleast. OK, I'm game. I'll log it into bugzilla. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 18 05:46:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29842 for ; Mon, 18 Feb 2002 05:46:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12827 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 05:46:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11620; Mon, 18 Feb 2002 05:23:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11509 for ; Mon, 18 Feb 2002 05:23:00 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29653 for ; Mon, 18 Feb 2002 05:22:55 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1IAMPJ14833; Mon, 18 Feb 2002 05:22:25 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4PVK>; Mon, 18 Feb 2002 04:22:20 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF6B@VA02> From: "Peterson, Jon" To: "'Hisham Khartabil'" , sip@ietf.org Subject: RE: [Sip] Very minor nits on section 22 Security Considerations i n bis-07 Date: Mon, 18 Feb 2002 04:22:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for your comments, Hisham, for this and the other comments on sections 21 and 20. These are really quite helpful. Some notes resulting from all three of your mails on the security sections below. Jon Peterson NeuStar, Inc. --- On 22: > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@pp.fi] > Sent: Friday, February 15, 2002 9:37 AM > To: sip@ietf.org; jdrosen@dynamicsoft.com > Subject: [Sip] Very minor nits on section 22 Security > Considerations in > bis-07 > > > These are very minor nits, but I'm sending them anyway to complete my > review. > > Line numbers refer to the pdf version. > > Section 22 > - line 4203: "is" should be "are". Actually, "is" refers back to the "the set", not to "of security services", so I think it should stay singular. > > Section 22.3.2.3 > - I thought we were still talking about Alice until Carol's name was > mentioned. Perhaps Carol should be introduced :) I would hope that by this point in the spec Carol would be an old friend. :) I think it's clear that a new agent is introduced in the start of 22.3.2.3. --- On 21: > Section 21.1 > - All SHOULDs and MAYs in the last 2 paragraphs of this section should be > lower case. They are not protocol related. Well, agreed that they are not protocol related, they are normative guidelines for the implementation of user agents. I do believe that we want to encourage particular ways of acquiring certificates because they are conducive to protocol security. > > Section 21.3 > - line 4036: the sentence is incomplete in the .txt version. Fixed. Damn those single ticks (`). > > Section 21.4.1.1 > - Its true that Via can be modified by a proxy, but at least > the sent-by field can be checked. Agreed, but we're discussing the end-to-end rather than hop-by-hop procedures for the interpretation of these headers. None of these procedures override the typical UA behavior for evaluating Via headers. > > Section 21.4.1.2 > - lines 4064 to 4067: So, are the outer headers used to identify a dialog > (session)? Are the outer ones used to compute the Branch-id? this needs to > be mentioned at the end of that paragraph. BTW, it should mention somewhere > that the TU is the one who decrypts (if I haven't missed it). I believe it's clear that the outer headers are used to identify a dialog, and that they are used to compute the branch-id, from 4065 specifically (which says that the inner headers are not used to identify dialogs or transactions). I don't think we really have any vision for where S/MIME fits into the SIP component model - you're probably right that it is the transaction user (it certainly isn't in the transport layer ;), but I don't think we especially need to detail that. > > Section 21.4.2 > - line 4098: "In order to eliminate possible confusions about the addition > or subtraction of entire headers, senders SHOULD replicate all headers from > the request within the signed body". "replicate" gives the false impression > that the outer header values shouldn't be changed. It should read "In order > to eliminate possible confusions about the addition or subtraction of entire > headers, all outer headers SHOULD reappear in the inner message, some header > values MAY differ". This section (as the title suggests) is intended to be specifically about integrity and authentication, rather than confidentiality. When the message is created, if it is only to be signed, all header field values from the "outer" message SHOULD be equivalent to the header field values in the "inner" message, I believe. So I think the text should stand. > > - line 4102: "or" should be "and". Actually, I think these two options do point to two different circumstances, although I am a little concerned if this is unclear. Sometimes the integrity violation will be associated with a response rather than a request, in which case it will not be possible to 'respond' to the response with an error. All the UAC can do when it receives a response with an integrity failure is send a BYE, when appropriate, to terminate any existing dialog that might happen to be in place - if there is no dialog, it can report the error condition and presumably have no further congress with the remote endpoint. So I think this is properly a disjunction rather than a conjunction. > > Section 21.4.3 > - This section talks about tunnelling encrypted SIP messages with > content-type of message/sip. It also talks about how a From header can have > anonymous. Yet, the example does not reflect that at all, it only has a > normal encryption of SDP. This example should perhaps be moved to section > 21.3 and a new example Good point. We have already restructured the examples a bit, actually, in preparation to bis08, and I think they are better now. The new example in this section actually shows a (properly) encrypted and signed application/sip (yes, it is application/sip rather than message/sip in bis 08) body, which 21.4.3 currently does not. 21.3 has an example now as well, of an encrypted application/sdp body. And fortunately, the example in 21.4.3 now does show the Anonymous usage. --- On 20: > Section 20.1 > -lines 3746 to 3751: I believe this paragraph should mention something about > the handling of ACK for a 401/407 response to an INVITE. It is recommended > that no state should be kept for unauthenticated requests (transactions). I'm not sure I follow. One always needs to send an ACK to a final response regardless of whether or not the respondent is actually keeping any state. This paragraph is about whether or not someone can challenge an ACK (we say it shouldn't be allowed). Agreed, though, that one should not keep state for unauthenticated requests (we discuss this in the DoS Solutions section of 22). > > Section 20.2 > - lines 3774 and 3784: the first line talks about parameters applicable to > the Request-URI and the second talks about credentials for the To field. So, > which one is it for? or are they 2 different things and I am just lost here? Well, 3774 is talking about how the WWW-Authenticate gets generated by a server sending a challenge. 3784 is talking about how credentials are cached in the user agent after a request is retried once a 401/407 is received. Clearly between the time that the UAC sends the request (when the Request-URI and the To field SHOULD be equal) and the time that the challenging server receives the request, the Request-URI may have been retargeted by one or more intermediaries. To make a long story short, I do think the two are separable issues. > > Section 20.3 > - line 3856: "When a proxy server issues a challenge in response to a > request, it will not proxy the request until the UAC has provided valid > credentials". Better to read "When a proxy server issues a challenge in > response to a request, it will not proxy any new request from that UAC until > it has been provided valid credentials". Agreed that my version isn't that great. How about "... until the UAC has retried the request with valid credentials"? We talk about retrying requests a bit back in the General UA Behavior section; I think this is the right language to use here. > > - lines 3869 to 3872: So what happens? Does the UAC include multiple > Authorization / Proxy-Authorization headers in the new request for the same > realm? I say yes. This needs to be mentioned. This may follow from 3843-3845, where it talks about credentials being 'consumed' by proxies. That would suggest to me that you need on Authorization/Proxy-Authorization header per challenge (which we say explicitly in 3866-3867). It's a corner case; I'm not sure whether we really need to say "yes" or if it will be obvious. The fact that you weren't sure which way to take it does suggest that it's not obvious. We'll spell 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 daemon@optimus.ietf.org Mon Feb 18 06:12:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00198 for ; Mon, 18 Feb 2002 06:12:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA14101 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 06:12:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12969; Mon, 18 Feb 2002 05:49:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12938 for ; Mon, 18 Feb 2002 05:49:25 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29879 for ; Mon, 18 Feb 2002 05:49:15 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1IAmgB23000 for ; Mon, 18 Feb 2002 11:48:42 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1IAmfr6027211 for ; Mon, 18 Feb 2002 12:48:41 +0200 (EET) Message-ID: <3C70DC40.88E2A75E@lmf.ericsson.se> Date: Mon, 18 Feb 2002 12:49:36 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Bis-7: Question on brackets Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A long time there was a discussion (it has also been discussed at bake-off/SIPit events) on how to separate URI parameters from header parameters in the To- and From headers. To my understanding, it was agreed that if header parameters (eg the tag) are used, the URI MUST be inside brackets. example: To: ;tag=3545883477 In this example brackets are used since the tag parameter is a header parameter, not a URI parameter. However, what bis-07 does say for the Contact header in chapter 24.10 is: " If no "<" and ">" are present, all parameters after the URI are header parameters, not URI parameters. The display name can be tokens, or a quoted string, if a larger character set is desired." Now, this would be different behaviour from the To- and From header handling. If the tag was a Contact header parameter, the following would be allowed: Contact: sip:12345@myua.com;tag=3545883477 Regards, Christer Holmberg Ericsson 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 daemon@optimus.ietf.org Mon Feb 18 10:06:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04439 for ; Mon, 18 Feb 2002 10:06:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA23684 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 10:06:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22516; Mon, 18 Feb 2002 09:37:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22485 for ; Mon, 18 Feb 2002 09:36:58 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03909 for ; Mon, 18 Feb 2002 09:36:54 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1IEbEL43565; Mon, 18 Feb 2002 06:37:14 -0800 (PST) To: Danyuu Wuu Cc: sip@ietf.org Subject: Re: [Sip] SIP-TLS Travesty (another perspective) References: <20020218072833.59274.qmail@web20104.mail.yahoo.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 18 Feb 2002 06:37:14 -0800 In-Reply-To: Danyuu Wuu's message of "Sun, 17 Feb 2002 23:28:33 -0800 (PST)" Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Danyuu Wuu writes: > Remember SSL is an exception on the Internet, not > a rule. SIP is making everyone run in the opposite > direction by making TLS a 'MUST'. I think you're failing to distinguish between MUST implement and MUST use. The MUST for TLS is of the former category, not the latter. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Mon Feb 18 10:41:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05235 for ; Mon, 18 Feb 2002 10:41:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA25428 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 10:42:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24156; Mon, 18 Feb 2002 10:19:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24129 for ; Mon, 18 Feb 2002 10:19:45 -0500 (EST) Received: from mail1.telekom.de ([62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04684 for ; Mon, 18 Feb 2002 10:19:40 -0500 (EST) Received: from g9jbq.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 18 Feb 2002 16:17:33 +0100 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id <1Z4J86Y3>; Mon, 18 Feb 2002 16:19:04 +0100 Message-Id: From: "Beck01, Wolfgang" To: ekr@rtfm.com Cc: sip@ietf.org Subject: RE: [Sip] 'sips' URI scheme (comments on proposal?) Date: Mon, 18 Feb 2002 16:18:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Eric Rescorla write: > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Michael Thomas writes: > > I'm well aware of that. I had to code up a BER > > parser in the late 80's for SNMP. It's still a > > pig.> It takes quite a bit of effort to hand > > code ASN.1, and even then you get messes like > > MIT's Kerberos code which is not only hand > > coded, but bloated on top of it. > I'm sorry, but I don't see the relevance of this. Anything we > require will force the embedded guys to change something and > I'm certainly in favor of making that something as minimal as > possible, consistent with the requirements of decent security. > > What's presently at issue here is the actual impact of adding > S/MIME as opposed to some non-S/MIME messaging system with > similar functionality. Your argument about the piggishness > of ASN.1 notwithstanding, my experience implementing such > systems leads me to believe that the footprint of such a system > will be roughly the same as S/MIME. > When I had a first look at the TLS and S/MIME RfCs, I had similar feelings as Mike. Both protocols appear as huge tasks, which require a lot of extra development time. Your [Eric's] code size estimation indicate something different, but for someone less experienced in security protocols it is hard to decide what can be left off. It might be helpful to write down the minimum TLS and S/MIME feature sets with respect to SIP in some informational draft. I fear that with TLS and S/MIME a lot of implementors will balk and end up without any encryption. -- Wolfgang Beck T-Systems Nova GmbH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 18 10:44:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05287 for ; Mon, 18 Feb 2002 10:44:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA25519 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 10:44:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24320; Mon, 18 Feb 2002 10:22:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24287 for ; Mon, 18 Feb 2002 10:22:18 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04720 for ; Mon, 18 Feb 2002 10:22:10 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id DB00AA108; Mon, 18 Feb 2002 17:21:42 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: "Robert Sparks" Cc: , , "gonzalo.camarillo" Subject: RE: [Sip] comments and nits on bis-07 Date: Mon, 18 Feb 2002 17:21:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C7039E1.501@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, 18 February 2002 1:17 AM > To: Hisham Khartabil > Cc: sip@ietf.org; jdrosen@dynamicsoft.com; gonzalo.camarillo > Subject: Re: [Sip] comments and nits on bis-07 > > - line 1697: why is it a MUST for a contact header to contain > an "expires" > > parameter? > > > This is how the registrar communicates how much longer the > binding will last > back to the client. You misunderstood my question. Anyway, from your comment, I gather that an Expires header in a 200 response to a REGISTER is Optional. Is that correct? Can an entry in table 2 be added to reflect that? > > > > - line 1967: "When a dialog is established with INVITE, it is terminated > > with a BYE". I propose "When a dialog is established with > INVITE, it MUST be > > terminated with a BYE". > > > Ugh - not as easy as that. The text has been changed to reflect > that BYE is > how termination is defined in this document, but extensions may > define other > mechanisms. (sip-events is one such extension). Ok, with some sort of NOTIFY, I guess. So how about a SHOULD or a MAY instead of "is"? > > - line 2166: section 13.3.1.2 does not talk about what happens > if a 3xx is > > returned with no contacts. > > > How would that happen? The sections on generating 3xx specify returning a > different response if there are no alternate URIs to try. > I was referring to the "SHOULD", the spec in that line says "301 or 302 response SHOULD contain a Contact header field...". The SHOULD gives the impression that a 3xx response with no contacts is possible, hence the question, how does a UAC handle this? Table 2 also specifies it as Optional. In any case, it should read "301 or 302 response SHOULD contain at least one Contact header field..." ^^^^^^^^^^^^ 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 daemon@optimus.ietf.org Mon Feb 18 10:45:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05314 for ; Mon, 18 Feb 2002 10:45:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA25551 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 10:45:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24256; Mon, 18 Feb 2002 10:21:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24224 for ; Mon, 18 Feb 2002 10:21:25 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04704 for ; Mon, 18 Feb 2002 10:21:16 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id 35D7BA063; Mon, 18 Feb 2002 17:21:16 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: "Gonzalo Camarillo" , "Robert Sparks" Cc: , Subject: RE: [Sip] comments and nits on bis-07 Date: Mon, 18 Feb 2002 17:21:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C704D7E.213DA203@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Monday, 18 February 2002 2:41 AM > To: Robert Sparks > Cc: Hisham Khartabil; sip@ietf.org; jdrosen@dynamicsoft.com > Subject: Re: [Sip] comments and nits on bis-07 > > > Hi, > > > > - line 2285: why terminate the session, this is just a > re-INVITE. The UAC > > > can re-INVITE yet again. > > > > Gonzalo - would you comment on this? > > > > We had some discussions about this some time ago. The result was that if > a transaction within a dialog fails, it means that the other end is > unreachable, and thus the UA terminates the session. Therefore, we treat > re-INVITE as any other mid-dialog request. This scenario is not talking about a time out error, its talking about a re-INVITE with no SDP from the UAC, a 200 with an SDP from the UAS. The SDP in that 200 response is not acceptable by UAC. The UAC has nothing else to do but to generate an answer with a valid SDP. The spec says then that the UAC should send a BYE to terminate the session. My question is: why terminate the session? UAs can continue with the session unaffected. It was only a re-INVITE to an existing session. Also, the UAC can re-INVITE with a new SDP acceptable for it? I guess terminating the session is an option, but shouldn't be mandated. > > Trying to re-INVITE again would probably trigger the same error as the > first one (481, ICMP error ...), and we would only increase network > traffic. Not if its a re-INVITE with SDP this time. Again, the scenario was about a re-INVITE with no SDP. Regards, Hisham > > Regards, > > 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 daemon@optimus.ietf.org Mon Feb 18 11:02:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05973 for ; Mon, 18 Feb 2002 11:02:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26933 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 11:02:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25366; Mon, 18 Feb 2002 10:39:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25337 for ; Mon, 18 Feb 2002 10:39:57 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05100 for ; Mon, 18 Feb 2002 10:39:53 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1IFdHS15400; Mon, 18 Feb 2002 09:39:17 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1IFdGU19356; Mon, 18 Feb 2002 09:39:16 -0600 (CST) Received: from lmf.ericsson.se (rmt160131.am.ericsson.se [138.85.160.131]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA03097; Mon, 18 Feb 2002 09:39:14 -0600 (CST) Message-ID: <3C7127B5.B54E9D0B@lmf.ericsson.se> Date: Mon, 18 Feb 2002 18:11:33 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hisham Khartabil CC: Robert Sparks , sip@ietf.org, jdrosen@dynamicsoft.com Subject: Re: [Sip] comments and nits on bis-07 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Hisham Khartabil wrote: > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Monday, 18 February 2002 2:41 AM > > To: Robert Sparks > > Cc: Hisham Khartabil; sip@ietf.org; jdrosen@dynamicsoft.com > > Subject: Re: [Sip] comments and nits on bis-07 > > > > > > Hi, > > > > > > - line 2285: why terminate the session, this is just a > > re-INVITE. The UAC > > > > can re-INVITE yet again. > > > > > > Gonzalo - would you comment on this? > > > > > > > We had some discussions about this some time ago. The result was that if > > a transaction within a dialog fails, it means that the other end is > > unreachable, and thus the UA terminates the session. Therefore, we treat > > re-INVITE as any other mid-dialog request. > > This scenario is not talking about a time out error, its talking about a > re-INVITE with no SDP from the UAC, a 200 with an SDP from the UAS. The SDP > in that 200 response is not acceptable by UAC. The UAC has nothing else to > do but to generate an answer with a valid SDP. The spec says then that the > UAC should send a BYE to terminate the session. My question is: why > terminate the session? UAs can continue with the session unaffected. It was > only a re-INVITE to an existing session. When a UAS receives a re-INVITE with no SDP, it has to generate an offer that somehow overlaps with the one in use, so that it is acceptable for the UAC. A UAS that fails to do so has probably crashed and re-started. as you suggest, we could recommend that the UAC re-INVITEs again, this time with SDP. However, our assumption was that if the UAC sent the re-INVITE with no SDP to begin with, it was because it has a good reason for doing so. Otherwise it could have included the SDP in the first place. Anyway, what this sentece means is that receiving an incompatible SDP in an offer in a 200 OK for a re-INVITE implies that an error has occured in the UAS. That's why the UAC SHOULD send a BYE. If you want to implement some kind of recovery mechanism instead of terminate the session, it is up to you. Regards, Gonzalo > > Also, the UAC can re-INVITE with a new SDP acceptable for it? > > I guess terminating the session is an option, but shouldn't be mandated. > > > > > Trying to re-INVITE again would probably trigger the same error as the > > first one (481, ICMP error ...), and we would only increase network > > traffic. > > Not if its a re-INVITE with SDP this time. Again, the scenario was about a > re-INVITE with no SDP. > > Regards, > Hisham > > > > > Regards, > > > > Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Mon Feb 18 11:17:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06828 for ; Mon, 18 Feb 2002 11:17:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27642 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 11:17:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25669; Mon, 18 Feb 2002 10:49:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25639 for ; Mon, 18 Feb 2002 10:49:49 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05400 for ; Mon, 18 Feb 2002 10:49:43 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id 85809A03B; Mon, 18 Feb 2002 17:49:45 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: "Gonzalo Camarillo" Cc: "Robert Sparks" , , Subject: RE: [Sip] comments and nits on bis-07 Date: Mon, 18 Feb 2002 17:49:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C7127B5.B54E9D0B@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Monday, 18 February 2002 6:12 PM > To: Hisham Khartabil > Cc: Robert Sparks; sip@ietf.org; jdrosen@dynamicsoft.com > Subject: Re: [Sip] comments and nits on bis-07 > > > Hello, > > Hisham Khartabil wrote: > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Monday, 18 February 2002 2:41 AM > > > To: Robert Sparks > > > Cc: Hisham Khartabil; sip@ietf.org; jdrosen@dynamicsoft.com > > > Subject: Re: [Sip] comments and nits on bis-07 > > > > > > > > > Hi, > > > > > > > > - line 2285: why terminate the session, this is just a > > > re-INVITE. The UAC > > > > > can re-INVITE yet again. > > > > > > > > Gonzalo - would you comment on this? > > > > > > > > > > We had some discussions about this some time ago. The result > was that if > > > a transaction within a dialog fails, it means that the other end is > > > unreachable, and thus the UA terminates the session. > Therefore, we treat > > > re-INVITE as any other mid-dialog request. > > > > This scenario is not talking about a time out error, its talking about a > > re-INVITE with no SDP from the UAC, a 200 with an SDP from the > UAS. The SDP > > in that 200 response is not acceptable by UAC. The UAC has > nothing else to > > do but to generate an answer with a valid SDP. The spec says > then that the > > UAC should send a BYE to terminate the session. My question is: why > > terminate the session? UAs can continue with the session > unaffected. It was > > only a re-INVITE to an existing session. > > When a UAS receives a re-INVITE with no SDP, it has to generate an offer > that somehow overlaps with the one in use, so that it is acceptable for > the UAC. A UAS that fails to do so has probably crashed and re-started. > > as you suggest, we could recommend that the UAC re-INVITEs again, this > time with SDP. However, our assumption was that if the UAC sent the > re-INVITE with no SDP to begin with, it was because it has a good reason > for doing so. Otherwise it could have included the SDP in the first > place. > > Anyway, what this sentece means is that receiving an incompatible SDP in > an offer in a 200 OK for a re-INVITE implies that an error has occured > in the UAS. That's why the UAC SHOULD send a BYE. If you want to > implement some kind of recovery mechanism instead of terminate the > session, it is up to you. Ok, the text should be changed to say SHOULD, or MAY preferably. The current text sounds like its mandatory to BYE. Thanks for the califications on the assumptions. (Maybe they should be mentioned :). Regards, Hisham > > Regards, > > Gonzalo > > > > > > Also, the UAC can re-INVITE with a new SDP acceptable for it? > > > > I guess terminating the session is an option, but shouldn't be mandated. > > > > > > > > Trying to re-INVITE again would probably trigger the same error as the > > > first one (481, ICMP error ...), and we would only increase network > > > traffic. > > > > Not if its a re-INVITE with SDP this time. Again, the scenario > was about a > > re-INVITE with no SDP. > > > > Regards, > > Hisham > > > > > > > > Regards, > > > > > > Gonzalo > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Mon Feb 18 11:18:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06854 for ; Mon, 18 Feb 2002 11:18:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27662 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 11:18:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25823; Mon, 18 Feb 2002 10:51:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25788 for ; Mon, 18 Feb 2002 10:51:54 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05579 for ; Mon, 18 Feb 2002 10:51:49 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id 8E80BA053; Mon, 18 Feb 2002 17:51:51 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: "Juha Heinanen" Cc: "Robert Sparks" , , , "gonzalo.camarillo" Subject: RE: [Sip] comments and nits on bis-07 Date: Mon, 18 Feb 2002 17:51:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <15473.8874.120264.404481@harjus.eng.song.fi> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Expires header is different that expires parameter. br, Hisham > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] > Sent: Monday, 18 February 2002 5:50 PM > To: Hisham Khartabil > Cc: Robert Sparks; sip@ietf.org; jdrosen@dynamicsoft.com; > gonzalo.camarillo > Subject: RE: [Sip] comments and nits on bis-07 > > > Hisham Khartabil writes: > > > You misunderstood my question. Anyway, from your comment, I > gather that an > > Expires header in a 200 response to a REGISTER is Optional. Is > that correct? > > no, it isn;t, line 1696: > > 8. The registrar returns a 200 (OK) response. The response MUST contain > Contact header fields enumerating all current bindings. Each > Contact value MUST feature an expires parameter indicating its > expiration interval chosen by the registrar. > > -- 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 daemon@optimus.ietf.org Mon Feb 18 11:20:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06987 for ; Mon, 18 Feb 2002 11:20:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27802 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 11:20:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26092; Mon, 18 Feb 2002 10:55:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26063 for ; Mon, 18 Feb 2002 10:55:47 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05677 for ; Mon, 18 Feb 2002 10:55:42 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1IFu16Y006444; Mon, 18 Feb 2002 10:56:02 -0500 (EST) Message-ID: <3C7123E0.B0DE1893@dynamicsoft.com> Date: Mon, 18 Feb 2002 10:55:12 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sanjoy Sen CC: sip@ietf.org Subject: Re: [Sip] use of TCP in bis07 References: <933FADF5E673D411B8A30002A5608A0E011878F9@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sanjoy Sen wrote: > > lines 3587-3590: If a request is within 500 bytes of the path MTU, or if > it is larger > than 1000 bytes when the path MTU is unknown, it MUST be sent using > TCP. This is to prevent fragmentation of messages over UDP, and to > provide congestion control for larger messages. > > Although I agree with the intent, this would force terminals to use TCP > in many cases - this may not be suitable for many smaller mobile > terminals. This should be relaxed from MUST to SHOULD. That is not acceptable based on IESG feedback on this question specifically. I think that is a fair position; we really want to make sure TCP is used for messages that would otherwise fragment. As an alternative, I reduced the "buffer" space to 200 bytes, and that was deemed OK. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 18 11:20:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07030 for ; Mon, 18 Feb 2002 11:20:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27818 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 11:21:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25715; Mon, 18 Feb 2002 10:50:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25688 for ; Mon, 18 Feb 2002 10:50:08 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05409 for ; Mon, 18 Feb 2002 10:50:03 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1IFo2io025343; Mon, 18 Feb 2002 17:50:02 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15473.8874.120264.404481@harjus.eng.song.fi> Date: Mon, 18 Feb 2002 17:50:02 +0200 To: "Hisham Khartabil" Cc: "Robert Sparks" , , , "gonzalo.camarillo" Subject: RE: [Sip] comments and nits on bis-07 In-Reply-To: References: <3C7039E1.501@dynamicsoft.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hisham Khartabil writes: > You misunderstood my question. Anyway, from your comment, I gather that an > Expires header in a 200 response to a REGISTER is Optional. Is that correct? no, it isn;t, line 1696: 8. The registrar returns a 200 (OK) response. The response MUST contain Contact header fields enumerating all current bindings. Each Contact value MUST feature an expires parameter indicating its expiration interval chosen by the registrar. -- 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 daemon@optimus.ietf.org Mon Feb 18 11:32:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07674 for ; Mon, 18 Feb 2002 11:32:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29008 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 11:33:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26249; Mon, 18 Feb 2002 10:57:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26224 for ; Mon, 18 Feb 2002 10:57:55 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05786 for ; Mon, 18 Feb 2002 10:57:50 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 18 Feb 2002 15:58:08 UT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Mon, 18 Feb 2002 16:00:04 -0000 Message-ID: <45730E094814E44488F789C1CDED27AEC552A7@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Reminder: SIP Events WGLC Ending Soon! Thread-Index: AcG3Qj4s2q2EOm9yTNemZQ/NA/vsMgBR/dQw From: "James Undery" To: "Adam Roach" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA26225 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, Here's a hodge podge of comments sorry it's so late. (I've tried to avoid duplicates of previous posters but they may crop up) 3. State Agent; s/Agent/agent/ in description only for consistency. 4.1.1. 3rd para. Requirement of a Expires header in a 200-class response not reflected in 7.4. 4.1.1. 5th para. Using Expires of zero is also a fetch operation because of 4.1.4.1. (same comment for 4.1.4.3.) closely related to 4.3.6 might be worth bringing these sections together. 4.2.2 1st para. s/is/are/ to match rules 4.3.4. 7th para. Inconsistent placement of punctuation wrt quotes (and won't get into the quotes as it's a style thing). 4.3.5. 1st para. Inconsistent quoting s/"NOTIFY"/NOTIFY/ 5.2. 4th para. Inconsistent placement of punctuation wrt quotes (Although this is a confusing case to use the American version) 5.3.2. 4th para. State Deltas if a subscriber has missed sequence numbers surely the subscription will have been silently cancelled ala 4.2.2. (Not sure this is a nit or me thinking aloud) 5.4. 2nd para s/changed/weakened/ 5.4.7. 1st para. It may be worth noting explicitly that "fake" or "neutral" state information isn't required 5.4.7. 2nd para. Missing ".." ;-) 5.4.9. 2nd para. Inconsistent quoting, the header values haven't been quoted 5.4.11. 1st para. s/"State Agent"/state agent/ 6.1. s/user/resource/ (also section 3 might do with a consistent name for the entity the state describes) 6.3. 3rd para. s/of notifiers/accepting subscriptions/ 7. Ensure first bracketed sentence goes 7. last para. Inconsistent placement of punctuation wrt quotes 7.4. s/"NOTIFY"/NOTIFY/ s/"SUBSCRIBE"/SUBSCRIBE/ 7.4. Should Allow-Events be mandatory in 2xx responses to an OPTIONS 7.4. Why isn't Accept "m*" for SUBSCRIBE 4.6.1. Reference [4] rfc2616 might be a better choice 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 daemon@optimus.ietf.org Mon Feb 18 12:04:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08961 for ; Mon, 18 Feb 2002 12:04:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA01178 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 12:04:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29231; Mon, 18 Feb 2002 11:40:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29200 for ; Mon, 18 Feb 2002 11:40:09 -0500 (EST) Received: from rjs.dynamicsoft.com (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08022 for ; Mon, 18 Feb 2002 11:40:04 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1IGRLe01773; Mon, 18 Feb 2002 10:27:21 -0600 Message-ID: <3C712B68.4000400@dynamicsoft.com> Date: Mon, 18 Feb 2002 10:27:20 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] Bis-7: Question on brackets References: <3C70DC40.88E2A75E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline Christer Holmberg wrote: > Hi, > > A long time there was a discussion (it has also been discussed at > bake-off/SIPit events) on how to separate URI parameters from header > parameters in the To- and From headers. > > To my understanding, it was agreed that if header parameters (eg the > tag) are used, the URI MUST be inside brackets. > Its the other way around - without brackets any parameters are considered header parameters., so if URI parameters are used, the URI MUST be inside brackets. > example: > > To: ;tag=3545883477 The brackets are allowed there, but not requried given that URI. To: sip:12345@myua.com;tag=3545883477 > > In this example brackets are used since the tag parameter is a header > parameter, not a URI parameter. > > > However, what bis-07 does say for the Contact header in chapter 24.10 > is: > > " If no "<" and ">" are present, all parameters after the URI are > header parameters, not URI > parameters. The display name can be tokens, or a quoted string, if a > larger character set is desired." > > Now, this would be different behaviour from the To- and From header > handling. If the tag was a Contact header parameter, the following would > be allowed: How is this different? > > Contact: sip:12345@myua.com;tag=3545883477 > > Regards, > > Christer Holmberg > Ericsson 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 daemon@optimus.ietf.org Mon Feb 18 12:46:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10866 for ; Mon, 18 Feb 2002 12:46:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02922 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 12:46:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25964; Mon, 18 Feb 2002 10:54:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11795 for ; Fri, 15 Feb 2002 05:33:55 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01631 for ; Fri, 15 Feb 2002 05:33:43 -0500 (EST) Received: (qmail 31938 invoked from network); 15 Feb 2002 10:37:13 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 15 Feb 2002 10:37:13 -0000 Received: from stake.com (unknown [10.50.1.35]) by cam-relay.atstake.com (Postfix) with SMTP id A9EA122817 for ; Fri, 15 Feb 2002 05:31:39 -0500 (EST) Message-ID: <3C6CE48E.6000708@stake.com> Date: Fri, 15 Feb 2002 10:35:58 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: multipart/mixed; boundary="------------010408030501050905060009" Subject: [Sip] Review of Section 22 "Security Considerations" of draft-ietf-sip-rfc2543bis-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------010408030501050905060009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, Attached is a .pdf file which is a draft document reviewing "Section 22: Security Considerations" of draft-ietf-sip-rfc2543bis-07. Please note that this document is provided as is, and still needs to be enhanced and revised. The thoughts expressed within the document are my initial thoughts about some of the subjects mentioned in Section 22. I will be more than happy to receive feedback, corrections and suggestions from the list members. Cheers -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. --------------010408030501050905060009 Content-Type: application/pdf; name="draft-ietf-sip-rfc2543bis-07_Review_of_section_22.pdf" Content-Disposition: inline; filename="draft-ietf-sip-rfc2543bis-07_Review_of_section_22.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjE3NTkgMCBvYmoNPDwgDS9MaW5lYXJpemVkIDEgDS9PIDE3NjIg DS9IIFsgMTc4NCAyNDc2IF0gDS9MIDQ1OTg4NyANL0UgMTI0MjMyIA0vTiA5IA0vVCA0MjQ1 ODcgDT4+IA1lbmRvYmoNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB4cmVmDTE3NTkgNDcgDTAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMTI5 NSAwMDAwMCBuDQowMDAwMDAxNjM4IDAwMDAwIG4NCjAwMDAwMDQyNjAgMDAwMDAgbg0KMDAw MDAwNDcyMiAwMDAwMCBuDQowMDAwMDA0NzY0IDAwMDAwIG4NCjAwMDAwMDQ5MjcgMDAwMDAg bg0KMDAwMDAwNTA5MCAwMDAwMCBuDQowMDAwMDA1MzM5IDAwMDAwIG4NCjAwMDAwMDU4MTgg MDAwMDAgbg0KMDAwMDAwNjQwMyAwMDAwMCBuDQowMDAwMDA2NjI5IDAwMDAwIG4NCjAwMDAw MDY2NzIgMDAwMDAgbg0KMDAwMDAwNjg4NSAwMDAwMCBuDQowMDAwMDA2OTE2IDAwMDAwIG4N CjAwMDAwMDc0ODUgMDAwMDAgbg0KMDAwMDAwNzUwOCAwMDAwMCBuDQowMDAwMDA3NzQwIDAw MDAwIG4NCjAwMDAwMDgxNjMgMDAwMDAgbg0KMDAwMDAwODgxOCAwMDAwMCBuDQowMDAwMDA4 ODQxIDAwMDAwIG4NCjAwMDAwMDk0NjEgMDAwMDAgbg0KMDAwMDAwOTQ4NCAwMDAwMCBuDQow MDAwMDEwMDY5IDAwMDAwIG4NCjAwMDAwMTAwOTIgMDAwMDAgbg0KMDAwMDAxMDMxNyAwMDAw MCBuDQowMDAwMDEwODI3IDAwMDAwIG4NCjAwMDAwMTE0ODQgMDAwMDAgbg0KMDAwMDAxMTUw NyAwMDAwMCBuDQowMDAwMDEyMTM5IDAwMDAwIG4NCjAwMDAwMTIxNjIgMDAwMDAgbg0KMDAw MDAxMjc4NSAwMDAwMCBuDQowMDAwMDEyODA4IDAwMDAwIG4NCjAwMDAwMTM0MTMgMDAwMDAg bg0KMDAwMDAxMzQzNiAwMDAwMCBuDQowMDAwMDEzNTE2IDAwMDAwIG4NCjAwMDAwMTM3MjQg MDAwMDAgbg0KMDAwMDAzOTA2MSAwMDAwMCBuDQowMDAwMDY3NjgwIDAwMDAwIG4NCjAwMDAw ODI5NzEgMDAwMDAgbg0KMDAwMDEwNjcyMCAwMDAwMCBuDQowMDAwMTA5Mzk5IDAwMDAwIG4N CjAwMDAxMjMwNTYgMDAwMDAgbg0KMDAwMDEyMzcyMyAwMDAwMCBuDQowMDAwMTIzNzg1IDAw MDAwIG4NCjAwMDAwMDE3ODQgMDAwMDAgbg0KMDAwMDAwNDIzNiAwMDAwMCBuDQp0cmFpbGVy DTw8DS9TaXplIDE4MDYNL0luZm8gMTc1NiAwIFIgDS9Sb290IDE3NjAgMCBSIA0vUHJldiA0 MjQ1NzUgDS9JRFs8YWUzNmY2MmJiNDIyNDRjNTE0NzE2MzI1MTU0MmM2OGM+PDQ0YzZhMWJj MjAyNTJkYjI2NzQ1MzZhN2E5ZGYwOThmPl0NPj4Nc3RhcnR4cmVmDTANJSVFT0YNICAgIA0x NzYwIDAgb2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDE3NTggMCBSIA0vTWV0YWRh dGEgMTc1NyAwIFIgDS9PcGVuQWN0aW9uIFsgMTc2MiAwIFIgL1hZWiBudWxsIG51bGwgbnVs bCBdIA0vUGFnZU1vZGUgL1VzZU5vbmUgDS9QYWdlTGFiZWxzIDE3NTUgMCBSIA0vU3RydWN0 VHJlZVJvb3QgMTc2MSAwIFIgDS9QaWVjZUluZm8gPDwgL01hcmtlZFBERiA8PCAvTGFzdE1v ZGlmaWVkIChEOjIwMDIwMjE1MDkwMzM4KT4+ID4+IA0vTGFzdE1vZGlmaWVkIChEOjIwMDIw MjE1MDkwMzM4KQ0vTWFya0luZm8gPDwgL01hcmtlZCB0cnVlIC9MZXR0ZXJzcGFjZUZsYWdz IDAgPj4gDT4+IA1lbmRvYmoNMTc2MSAwIG9iag08PCANL1R5cGUgL1N0cnVjdFRyZWVSb290 IA0vQ2xhc3NNYXAgMTM1NCAwIFIgDS9Sb2xlTWFwIDEzNTMgMCBSIA0vSyAxNzAxIDAgUiAN L1BhcmVudFRyZWUgMTczOSAwIFIgDS9QYXJlbnRUcmVlTmV4dEtleSAxMyANPj4gDWVuZG9i ag0xODA0IDAgb2JqDTw8IC9TIDE5MjUgL0wgMzc2OCAvQyAzNzg0IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlIC9MZW5ndGggMTgwNSAwIFIgPj4gDXN0cmVhbQ0KSIncVmlQU1kWPu9lIQuELYZF lgCGHWUTo7T6QERAxChbVHQiikZkCYsKLeoVUaOgRgRFGukoICgiiKK4jB1oRNzREUQbMSja ttqKrSI9Tttzwarpmaqpmf7T3VV9Xr3K/c6995zvfKfqvAAADYA5CGy8MAMj+MWMgIMfOrCM EVjUsYZ96eT6mRB2wOkDvbfJTzOT4h7HTsZ61dLljCaVWEBq4H+YqQ4Jaj6dtl7iLeA0Ilc2 W6xAIp1BSY4dO3v0SCWNUpsyCFBUsWjrZRFsslmitGaJJXk27EbZrs1B+Yb9q4ONPN5ZWt9s yRROu9hXsGq60YmGMZb5vb0OVvmL9zuHTCtI1LNp7/PTt1E1i1h+7QWuSn9lxEITodKIMA+c FWtoFDDLO2LDVGOGx3Sz1rjxM8z5KYcCZ/MrRi0LbxXNiYzs2LlRatphWCiJKJwaujhqV8ol nzDj8r6UGeGjWlZY6njf9LLgi+iJI5kNhlMkzLevfWeGvz49yXbrIvEN75Bw6ppnXn55ldPV r11v+YQYy+6N06tHd8bqearKHLctimgbnZuvqR3DrW9pcL3i39XodsX2bbWHrhf/onNebN1X LrmPoNk95FbWzkn6u16oJu1Ia38jYnsGDUyc2aKbR6kCzBi27caDP9m1PRwLk2/YqR45sOvl T8aH2Wb0jJvxJmefmJcqfekb9qal8DN2WvneCbyyuuf2fMk7tXyu++sDS++2JkzW3/tkRTnP /GBNjd691oqDy6bUPR0fb55CbDPseuK3w7CoSaRc2LXbNSg2JyrGf4nZfke/uJzA4J2L787S K1heUim6kkYt9WhLsXCvc0npXsrXIfdNi7yzAm0OZaR1f+t3K52axvJKHBnV7Zn4hU9Trd4G yc36hHno9PnkboMGTfK8g30euuTA67NLohnvVhpfiNyYJZga91Oy8caOH5dJTRq0s6R3Umal zumcqpZI94zoi1mw0SYxJ5p+LFRq0tlwInrOJsbNTVEXKo5tlLV0MpKiCweIOJM9Hh7xssKO 2zwapRotWPnYbNKMVeVtArNVvcr53QXCDPOwVXFyf11Wxd1Ubo5/cIKwSPhdjmhDnHbtXzY8 PjSbXyjbs4S1skIc2ZVdURRkv1vkGGpT2Hux6R9bFsk7PmTFym++Wh07rn7C9gVPe8TrYoOu O+d+uadjYM3Dxnq3tbbvn3lueeBw7e3WRaxWx3WlwWaP8vuid0/ZadPFoWUsrMwOyV/gZBW0 3qYx85lyQdHfJyrLTtX8vMPufSmRWe7EBKWVci11uD50h+2l1JIy+0s/WCSbt6Zc3WB9MeVF tc+1tNAHvteP533rdSX1au3oq8ctvnJvded+/KhRxBiTmlff9Az8NTn3hw/nk4+MNGpJ0Z1p cuFYaLR+syLPmvN1XfcY3Rs+948v/+aU28Xkbp+aXYu6Ts6vlN89uebGugenemg52kErbtb9 U/P/tqrnfc2jzK70bdaBt9Lve4Xcehvz86Qb6XrGU9rT3XzndTbsS5PdeXd/tfR2g+Vkye13 a+ZFdCSHhOWXLwuJ3VOxLN5/6wH51tE7yqou++w9FB+y/WDR4eLSqqpDl5OKK+PNs0srn2ae SfzC/sfrqSUOZkfj9tqPL44vXpJ5IF0tZ3/M3l81l5fzZeWWnhX7KvcOZJVWnjnaffL76pW9 jW7P19498b1L4O2TbqujOhuPPj/54uwr38v955LO7u5rfLn88HenX+b6n6qpnvvw3NHnxc9O VB++V1975Llz87HahGr7tvoXHyZcPZ6wmqmprf7AaT2W4GvA5CCFkPNQXOpKJ6i6USI2yXO0 7s0Wbt78SCzx5hFILdQhqDChM8NPhgcUaZAlYpFJJpt7s92VTAKQI95VuVqz/UFpwwaZwfBI G8HIPirkkv4SlVCn2WrosDCPiTcs2GRTf8Eolv+n+WcYoMQGYBsQELlkaKlEQ25CIFd+2viT Gs3nU4F/RkPwHw20tf2ls0z58A/Ny0f+yUMTK5X/9QOKQzwGel4JXjjjC9uGXSagT0uCULqM pbGgUgkzuAKO5CBQtkIAb6qNzABgRwDYYeiJ3mR/jmEOgAhn3Inf8URabu6asjPTC5uLzPeT ORAGJXREaGhIB3hgAWJQgPZXQIqHLGECpMNTop2m/q3hZ5AB/YSWptFB+mD1h0Aesvr96v01 cIgV9Uep8bvCCRj+5sL+fxox0EhIScSQccAcHDE8QihJiok4YIocQY6hmkRMLUdjCRPhc3hL Dv1H1hjAKBQImwhTUkZXsbXGGgcUCYcJGalh1HFlAo07WgzXiSqamKnQ1ZojLxQP90gW3YBF GQhtIACUBJ90pyOWwlBmpwlCBYQPSdGVOJDaiZoBB4hQspxBcdwFyImSQj0RSzYytFyFidAV FkAdkU62MBBXMYJyQVJMMIg8wQjiUHytA4SifYQ3GUovYoORRgTT0CaChxPJMWOZEPmhJOgk jtAcmUgPzCgPiIMWIousY8i4aARyQhI4SFCkhK5maQ2HbmOaBqSQpmUhnsYSiWElHhNdpEYH OJQFOEE8nMO5++lqrkYArjB7GGoYQi4IYAxIMVEZqWIIOZQAH/43yEciDAsw7B86bIKGdofv Mik2ZQZjcag2nEjCVPOAj4bGU/nQeGII9XBeEWQTdKKfTrGEBpQdCoHthOMQZw7wcf/CsR6L yTaGiisUUGNQLC5QQTNgSnTV5nhwLoduXL4U38RqTEFbcRdMcSCJgdYOBWPoTIrpiN1vpHWC cFRMSMhyehdHPULtoonATYnFSmVwVHzKFUWiakJMltAH2f18cKKCQU1MIoPoT9kSQ8pWE4w5 8bFwCla7odBG4w2fZP8XjRg4j2XXYpLIBFwgCssuJYv+KVYGzgVCDWpAH4GCPQCYWBr4GxQa 7MDBfoD5AcsCXmDgqAJDAxhWzAGsDzgdpBp0gLEwBRgAwJDkBIazKjDolgBDcgJrAyicNcHh DAweSLBDYsEDFgvQSOEoEDqg6RDKsJkxg+kM6wpuBeEGjQY/oCPEmCSYC9ge8DIYeD9jOMck xWTAqMCxgaWBHq0IdMB2C1jD2gIZTEAcCOyFejCwHvcGVqWTGBgWfAIpAPZeG+y0Ox9bbAAI MADp9ponDWVuZHN0cmVhbQ1lbmRvYmoNMTgwNSAwIG9iag0yMzQ2IA1lbmRvYmoNMTc2MiAw IG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTc1OCAwIFIgDS9SZXNvdXJjZXMgPDwg L0NvbG9yU3BhY2UgPDwgL0NTMiAxNzcwIDAgUiAvQ1MzIDE3NzIgMCBSID4+IC9FeHRHU3Rh dGUgPDwgL0dTMiAxNzkzIDAgUiAvR1MzIDE3OTQgMCBSID4+IA0vRm9udCA8PCAvVFQ1IDE3 NzMgMCBSIC9UVDYgMTc2NyAwIFIgL1RUNyAxNzY4IDAgUiAvVFQ4IDE3NzYgMCBSIC9UVDkg MTc4NCAwIFIgPj4gDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdID4+IA0vQ29udGVudHMgWyAx Nzc3IDAgUiAxNzc5IDAgUiAxNzgxIDAgUiAxNzg1IDAgUiAxNzg3IDAgUiAxNzg5IDAgUiAx NzkxIDAgUiAxODAxIDAgUiANXSANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BC b3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDS9TdHJ1Y3RQYXJlbnRzIDAgDS9Bbm5v dHMgMTc2MyAwIFIgDT4+IA1lbmRvYmoNMTc2MyAwIG9iag1bIA0xNzY0IDAgUiAxNzY1IDAg UiANXQ1lbmRvYmoNMTc2NCAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGlu ayANL1JlY3QgWyAzMDUuNjQwMDEgNTkzLjQ5NjIyIDM2My4xODgwNSA2MDkuMDEyMDIgXSAN L0JvcmRlciBbIDAgMCAwIF0gDS9IIC9JIA0vQSAxODAyIDAgUiANL1N0cnVjdFBhcmVudCAx IA0+PiANZW5kb2JqDTE3NjUgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xp bmsgDS9SZWN0IFsgMjM1LjYxOTcxIDM0MC44NDM0MSAyODkuMTcwMDQgMzU0LjQ5MDUxIF0g DS9Cb3JkZXIgWyAwIDAgMCBdIA0vSCAvSSANL0EgMTgwMyAwIFIgDS9TdHJ1Y3RQYXJlbnQg MiANPj4gDWVuZG9iag0xNzY2IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9B c2NlbnQgODYxIA0vQ2FwSGVpZ2h0IDYyMyANL0Rlc2NlbnQgLTI2MyANL0ZsYWdzIDI2MjE3 OCANL0ZvbnRCQm94IFsgLTEyNCAtMjUwIDEyNDcgODQ1IF0gDS9Gb250TmFtZSAvQ0xNSU9B K0dhcmFtb25kLUJvbGQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTMzIA0vWEhlaWdodCA0 NTcgDS9TdGVtSCAzNiANL0ZvbnRGaWxlMiAxNzk2IDAgUiANPj4gDWVuZG9iag0xNzY3IDAg b2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMy IA0vTGFzdENoYXIgMTIyIA0vV2lkdGhzIFsgMjUwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDMzMyAyNjAgMCAwIDM5NiA0NjkgNDY5IDQ2OSA0NjkgMCAwIDAgDTAgMCAwIDAgMCAwIDQx NyA5MjcgNjU2IDAgNjc3IDc4MSAwIDYxNSAwIDg2NSAzOTYgMCAwIDYzNSA5MTcgODQ0IA03 OTIgNjE1IDAgNjk4IDUxMCA2ODggMCAwIDg5NiAwIDAgMCAzNjUgMCAzNjUgMCAwIDAgNDc5 IDU1MiA0NjkgDTU1MiA0NjkgMzAyIDU0MiA1NTIgMjgxIDI2MCA1MzEgMjYwIDg0NCA1NTIg NTIxIDU1MiA1NTIgMzQ0IDQxNyANMzEzIDU1MiA0NTggNzA4IDAgNDY5IDQ2OSBdIA0vRW5j b2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9DTE1JT0ErR2FyYW1vbmQtQm9s ZCANL0ZvbnREZXNjcmlwdG9yIDE3NjYgMCBSIA0+PiANZW5kb2JqDTE3NjggMCBvYmoNPDwg DS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0 Q2hhciAxNTAgDS9XaWR0aHMgWyAyNzggMjc4IDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDI3 OCAzMzMgMjc4IDI3OCA1NTYgNTU2IDU1NiA1NTYgNTU2IA01NTYgNTU2IDU1NiA1NTYgNTU2 IDI3OCAyNzggMCAwIDAgNTU2IDEwMTUgNjY3IDY2NyA3MjIgNzIyIDY2NyA2MTEgDTc3OCA3 MjIgMjc4IDUwMCA2NjcgNTU2IDgzMyA3MjIgNzc4IDY2NyAwIDcyMiA2NjcgNjExIDcyMiA2 NjcgOTQ0IA0wIDY2NyAwIDI3OCAwIDI3OCAwIDU1NiAwIDU1NiA1NTYgNTAwIDU1NiA1NTYg Mjc4IDU1NiA1NTYgMjIyIDIyMiANNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgNTU2IDMzMyA1 MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAgNTAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDEw MDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjIyIDMzMyAzMzMgMCA1NTYgDV0gDS9FbmNv ZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0NMTUpBQStBcmlhbCANL0ZvbnRE ZXNjcmlwdG9yIDE3NjkgMCBSIA0+PiANZW5kb2JqDTE3NjkgMCBvYmoNPDwgDS9UeXBlIC9G b250RGVzY3JpcHRvciANL0FzY2VudCA5MDUgDS9DYXBIZWlnaHQgNzE4IA0vRGVzY2VudCAt MjExIA0vRmxhZ3MgMzIgDS9Gb250QkJveCBbIC02NjUgLTMyNSAyMDI4IDEwMzcgXSANL0Zv bnROYW1lIC9DTE1KQUErQXJpYWwgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgOTQgDS9YSGVp Z2h0IDUxNSANL0ZvbnRGaWxlMiAxNzk4IDAgUiANPj4gDWVuZG9iag0xNzcwIDAgb2JqDVsg DS9JQ0NCYXNlZCAxNzk5IDAgUiANXQ1lbmRvYmoNMTc3MSAwIG9iag08PCANL1R5cGUgL0Zv bnREZXNjcmlwdG9yIA0vQXNjZW50IDg2MSANL0NhcEhlaWdodCA2NzEgDS9EZXNjZW50IC0y NjMgDS9GbGFncyAzNCANL0ZvbnRCQm94IFsgLTEzOSAtMzA3IDEwNjMgOTg2IF0gDS9Gb250 TmFtZSAvQ0xNSUpIK0dhcmFtb25kIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDAgDS9Gb250 RmlsZTIgMTc5NSAwIFIgDT4+IA1lbmRvYmoNMTc3MiAwIG9iag0vRGV2aWNlR3JheSANZW5k b2JqDTE3NzMgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9G aXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxNjkgDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDcy OSAwIDAgMCAwIDAgMjE5IDMxMyAyMTkgMCA0NjkgNDY5IDQ2OSA0NjkgNDY5IDQ2OSANNDY5 IDQ2OSA0NjkgNDY5IDAgMCAwIDAgMCAwIDkxNyA2NzcgMCA2MzUgNzcxIDY1NiA1NjMgMCAw IDAgMzMzIA0wIDU3MyAwIDAgNzgxIDAgMCA2MjUgNDc5IDYxNSAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCA0MDYgNTEwIDQxNyANNTAwIDQxNyAzMjMgNDQ4IDUxMCAyMjkgMCA0NjkgMjI5 IDc3MSA1MTAgNTEwIDUxMCAwIDMzMyAzNjUgMjkyIA00OTAgNDY5IDY2NyAwIDQxNyAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgDTAgMCA0NDggNDQ4 IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA3NjAgXSANL0VuY29k aW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvQ0xNSUpIK0dhcmFtb25kIA0vRm9u dERlc2NyaXB0b3IgMTc3MSAwIFIgDT4+IA1lbmRvYmoNMTc3NCAwIG9iag01NzMgDWVuZG9i ag0xNzc1IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgOTA1IA0v Q2FwSGVpZ2h0IDcxOCANL0Rlc2NlbnQgLTIxMSANL0ZsYWdzIDMyIA0vRm9udEJCb3ggWyAt NjI4IC0zNzYgMjAzNCAxMDQ4IF0gDS9Gb250TmFtZSAvQ0xNSkZNK0FyaWFsLEJvbGQgDS9J dGFsaWNBbmdsZSAwIA0vU3RlbVYgMTQ0IA0vWEhlaWdodCA1MTUgDS9Gb250RmlsZTIgMTgw MCAwIFIgDT4+IA1lbmRvYmoNMTc3NiAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBl IC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDEyMSANL1dpZHRocyBbIDI3 OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIA0wIDAgNzIyIDcyMiA3MjIgMCA2NjcgMCAwIDAgMjc4IDAgMCA2MTEgMCA3 MjIgMCA2NjcgMCA3MjIgNjY3IDYxMSANNzIyIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYx MSA1NTYgNjExIDU1NiAwIDAgNjExIDI3OCAwIDAgMjc4IA04ODkgMCA2MTEgMCAwIDM4OSAw IDMzMyAwIDAgMCA1NTYgNTU2IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFz ZUZvbnQgL0NMTUpGTStBcmlhbCxCb2xkIA0vRm9udERlc2NyaXB0b3IgMTc3NSAwIFIgDT4+ IA1lbmRvYmoNMTc3NyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDE3 NzQgMCBSID4+IA1zdHJlYW0NCkiJlJRLb5tAFIX3/Iq7bBcM8x5GiqI4dlpVatTKZtkNwYM7 jQ0REFv59x3Gjg0uUEXejMVwzse5j+gn3NxEj/NvC8Bwe3u/mAfRfEUhq93/9gd1VgQELATR 0mzTxu7NvNyWld2ZprIZVDaIvroXNnVwnwRRkgggkOQBYUjHXuF40hgUVkhzSHbBJ/ic/Ake kuDh0fldEMgJYVKJYYG0dkJSU0TEtCL9mKKSiLNYTymyIUWMMMYUkgyIPmv7E8UE8RikEEh4 2XWV5k1oTZOHtX0JqzyjgrMnW4dYjVjyUUvWWrYn532A6+8iSnlvFiMivfnS7K05QJlDbbLG lgVQCr8oZSuTvVa2eYN5WdR2baq0fVq7R3wESgxCeR7PQo8g1KUrQVKOSIzJVLBysFRnGaoE crCSYCTflRbL2ZcE9hiREU01rUm0qwoHodWFLinhycBrbdZQFts3ONjmty16+quXtDhbxCcL L3kcl5E6dSMRSF75uma4a7sCldWmY3a+KhGNQaiWN3QRQGWCvPupusOBBzhC3ybxVW0kcwR9 ENildmuLDWxt3YwNKv5I9UXMLjUbUxye/b6Owv/tItKfeNkpAm/xfAxEDI1L22Ft1IK/r6kf ua1g1hr9szIIRZx071bD1xSihInuxeerbuqws1F2MhAtlcQXj2N03Filw71Lm7pJnw3Kyt2Y TX+fqE7xrvKmEkk6mfbgFvAZu/dPu6k99bndWqIgXERS6CP6rAGPDd/tzln9FWAAu7p8rw1l bmRzdHJlYW0NZW5kb2JqDTE3NzggMCBvYmoNNTM4IA1lbmRvYmoNMTc3OSAwIG9iag08PCAv RmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDE3NzggMCBSID4+IA1zdHJlYW0NCkiJfJTd attAEIXv9RRz2UI13p39hxBoHF+0NFCoXkCxV7Xa2jKSUtG370pOkNasgi+8oG/P0TkzdsYJ WPiEL0EGySkLigvUyjkoTtmH+mPxK1tAgiFTysVQ7w8wcrsi2z1ts813uLvbPG2/PALXcH// 8LjNHopsUxQKOBRVlgcRxgiKPbydBphNyCi0BIox5G8WOrfwtTz5Dn70uGZmUmazV5400xId SKvnON+a86E5f4Ld+eef8rwaza5Hk1O0WyOFgkAaMacahgHLvuvL3x73zWnNyUVO5jXX6DHL OwZSWbTmVXpFi1hKK5aRCpl9V4SnooeNcPaqM50E0yDDvoTQ72lRpKUXQ1NTwhtVNz0Kylyi Ek5O2p+fu74t9/2ah0gWGC8G6Wle4fhaxnQa+2Ac9dWnONYdXMrpN3EDciI01solfvFJUohx TGpJthCEk7B06LjTS7iE1v+t/QBNBf0xdYuYQ8mEWN7y0CVfh8giaeOW7P6lrft/UPlkVNJh z1R8o0+CJjznLurkpfXdyE7ti7l9k2qfHEcSYeoLgWtqD5eU4/gnJiRFwdskGBbTsLDIC7C5 NElUBk1to3mlqxTKoHXxsA5waMuqz2vfV3lXp67JsNlKsHh18rbaU5IWDjkTUScqCUqJmng0 Jime06+gwyswikS7nCVRE+owIgppkqAldIrHwxuOSf/xv15bsajgvwADAPj3aQ8NZW5kc3Ry ZWFtDWVuZG9iag0xNzgwIDAgb2JqDTUwMyANZW5kb2JqDTE3ODEgMCBvYmoNPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNzgwIDAgUiA+PiANc3RyZWFtDQpIiYSUS0/bQBDH 7/4UcwyHTnZn9mUJcSBQKQckVHzMBUJo3Aa7it3Sj99xQukuTFT5spJ/8/rPo5qtz5pvlTVo CIx8x5c3HkNgB85YDA6a52q2hYn8JP+NEM0aDk+S5wu8t68NcG3Q0sHycTOs960Wx9og7iPn 9IMKEiGRdzm40cGI0bHPwUEFmTAmDjkI41Z36mp01tcF221+j/Brsx/avgPNikzC5E3Krfqn KcYBnzdNAgvNU2UmNY2mI7HoU9dF4LtX4/hqLE2wfvLwwdgxcpBHrtkg6arJhoDRc8zhTgUj IbMtqtLq+Wjn0RpTNGZZlnKcLdatI6ZgbJFeO7b341/1/xOerYSnMvytoqR7m2xOWkeYrIxN 2dR9P2pKMTM6GbGi/zpYo/GhGO51v1sRkYp7hyZQOeKwmpUqHLfTnRwtDl42qhTkbqlIYsI/ SVRHySJPVOZodaYmnhwGUzYRvnxe4KGB1011fbOo5rdwfj6/WSyvZIDh4uLyalFdNnlOJ0ua rk5M6KeFeRtLxa1X3b67a+FUhBDRHi9is20HeFRbOt2rmJLL8fVP/Q7JltqSfD5xhQRIPge7 ESSFYWx3O7iHF32zjdwQscnt9t+h7eCHiks+iVJB69yUTSzc9l9V0iUkEaNwqVZIXgD2WYl/ BBgAgatiJQ1lbmRzdHJlYW0NZW5kb2JqDTE3ODIgMCBvYmoNNTc1IA1lbmRvYmoNMTc4MyAw IG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDkwNSANL0NhcEhlaWdo dCA3MTggDS9EZXNjZW50IC0yMTEgDS9GbGFncyA5NiANL0ZvbnRCQm94IFsgLTUxNyAtMzI1 IDEwODIgMTAyNSBdIA0vRm9udE5hbWUgL0NMTUpNTStBcmlhbCxJdGFsaWMgDS9JdGFsaWNB bmdsZSAtMTUgDS9TdGVtViA5My44NTYgDS9Gb250RmlsZTIgMTc5NyAwIFIgDT4+IA1lbmRv YmoNMTc4NCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0Zp cnN0Q2hhciAzMiANL0xhc3RDaGFyIDE0NiANL1dpZHRocyBbIDI3OCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAzMzMgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIA01NTYg MCA2NjcgMCA3MjIgNzIyIDY2NyA2MTEgMCAwIDI3OCAwIDAgNTU2IDgzMyA3MjIgNzc4IDY2 NyA3NzggDTcyMiA2NjcgNjExIDcyMiAwIDk0NCAwIDY2NyAwIDAgMCAwIDAgMCAwIDU1NiA1 NTYgNTAwIDU1NiA1NTYgMjc4IA01NTYgNTU2IDIyMiAyMjIgMCAyMjIgODMzIDU1NiA1NTYg NTU2IDAgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgDTAgNTAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDIyMiBdIA0vRW5jb2RpbmcgL1dpbkFu c2lFbmNvZGluZyANL0Jhc2VGb250IC9DTE1KTU0rQXJpYWwsSXRhbGljIA0vRm9udERlc2Ny aXB0b3IgMTc4MyAwIFIgDT4+IA1lbmRvYmoNMTc4NSAwIG9iag08PCAvRmlsdGVyIC9GbGF0 ZURlY29kZSAvTGVuZ3RoIDE3ODIgMCBSID4+IA1zdHJlYW0NCkiJdFXLbtswELzrK/boAinN t0ggCIo4OfQQoEB17MUPOmGhhyHJCfL3XUpGJKoUfDANzA6XM7PrbNN1cGqO1+pb8TdjlFAO FD/jiVtLrGAGhM4Jk1BU2cbV/R3s6xNc2ubdn1JlQmvChLZR2Qn2SaxRRGmez7FdEmgp0TQG gu8IQEA/F9nzyy7b/oL7++3L7ucTcA0PD49Pu+yxyLZFkQOD4pxRKI5IWXzAkt9SEEoRzawd uVdo8yQtoRQ5kPt7OOLdKzdISai93VC8OZQ+9VbGGWFcsBi/YhITaJLJ8xjsklAZxFYmhtZJ qGKEGrGA9mmoIEYqEUPRm1tE0PpkHccvxbiM65KCcKYRQdXiih4VnNv0+7KvJ6fMzamBBqA7 1rFpg1WMryaCiyEOC2GT4eQSw6mWUJ+GcmJys/D28iOJVYZooRYKedefSdO+zl4+tIozIkUo Qz/QY3xezqF12TnKr52pQtdUoforyzj9KW2MJXxoi41WVHtf+voVSt/1ULnq4NpuWBMYg9Do SGsnWpWilUwRESZwYvZ17+ohQw0cHFw7PB4+Z5xq4rQpTuwUlUMNBSda0pG1f8O+pp7Tw4J7 RhsTF85e19TlJ/zZnJt2CGLvKzdrS0zbgCUVzC2ReYjMnP7gQkPXuvclnK/9tXV3UDWtw17H H+94c7JdibkSGo2L+Jp6lP8/tGaEh3magz98WQaNQ8HwBrY6G1+iDptqjPA47Ol9hpnHbTKH J/85GDdEGK0m4D8BBgCYR3gvDWVuZHN0cmVhbQ1lbmRvYmoNMTc4NiAwIG9iag01NTAgDWVu ZG9iag0xNzg3IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTc4NiAw IFIgPj4gDXN0cmVhbQ0KSIl8VMFu2zAMvfsreGwPY0VJlmSgKLCkHdBDgAD1bd1ByNzEQ2sH joqgfz/aSbNJkwdfBPu9x6dH0sXV8zXCdf2reKiLh9WyuFnD7e3Navl4D0rA3d3iflks6uKm ri0Q1C+FgHoDJFBIEPycTq7Cqqo0Uyo0UL8VV3OalNOck5OVQ9L/6n0dQvviNwEWq1TpLCOh EiCdRmsE/deQjAyZk8wXtiHYCF91OvLLI5C6uJxOYwUrsBLnClLCU7N5H+ukUFKEmu3EhKEN H7Dsu0P7sxl8jieFQ+vIxbyQhZJEZ1wCbVkdvq/9tgEi9WMuBDUfAo0hfJ6OEAdcWjzV+dYO hwB7P/jt4Pe7uTo61/2pjlSTejIIYw2t0bjzdZ6C59Z3Wwi7Bg6fYSckMiUKq0xMncJmSmj7 kXS6nL50WObKS2FRjd8ipQ6ObdiBh0Pwock5kMYgWZXw3rJQq7EkWcXQpgt8RR/gWUo10jit Kj+aMutckUahhUrie1xDe4CuD+A7aHzOkOKlMSTKmHn4gH0OrYXkYTOUZJ2HGpSmTG7ahz4L lgJJmaSHmzy05LCNTXRfYUaZUYLjieHTMA3NOepoMN1lAXQuaW0NOpcmzX3T2epOoNQiyYub kgVXDFYukZ7aN8L/rOfJaDm3QUqhlOPIjK3Jd52EHn9QMTZrivgXr42jBPo+tFk0N6fUtozR 3Rah5g3e9v4V8jzHG6RI/c37LcAAsdNw0Q1lbmRzdHJlYW0NZW5kb2JqDTE3ODggMCBvYmoN NTQxIA1lbmRvYmoNMTc4OSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3Ro IDE3ODggMCBSID4+IA1zdHJlYW0NCkiJdJXBbtswDIbvfgoe28MUiZIsCSh6aNpDDgUCzNip Fzdx2myOHdjKir39KG/DIJVBLkLw/RT5i6Srm/m2+V4pKSSCpN+fkwpKKKcsoNYCkf5pTtUN xBFO7Y8OzpwGtRNe15hruvHcs7SthVOqpOEy7DuW906gC3XOT3NsOVpLLYLWKqeHPcR3Fsda KKN9mczMpqKNFVLWLqd3l+kYf8F5GlmNTzfIwtBXFiXvnfJF+L47zcDhRllhXV0a0/VtZLM3 RgrrQ47veZJylk59boKvmy283LTJz3FJ6gsJZAJ2sByRjh9QBgwSEKk4KdUS6tu42b7cQooz jJHtQ0t9iFLnunTrZe7oMTs4dO0Eh3YXWdvRoMDa+Vw/8agVNTqbowKW+p6a6ul5Xa22cHe3 el5vHkFbuL9/eFxXD021ahoHxB8qmRyQ12qnk/L/argStmbDJnfVf3ftlRtU8MLh3xsacoef JUUVKhVszs+76XiOR1ZgaPjIl1wwDvQCbYTD2Pfjxwxvx5/dDC2wXY3WpMxDHoIfdRuoQ1Vx W4zdlLYDqwhaGO91EZy2Q6KXR/k0ZekxjDS5pB349aCofNo9Gbs/Dm8wHpYupKl/pQkFtgnT hKI0RT1sExrlha1pEWUokMl9184RZv6CuhY+IOaqUwcTvwECCoO2yIfdoyY4EYwuIrOfDCtR BF+iI2uoVdQMDgvzl/32W4ABAAKKalANZW5kc3RyZWFtDWVuZG9iag0xNzkwIDAgb2JqDTUy MyANZW5kb2JqDTE3OTEgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAx NzkwIDAgUiA+PiANc3RyZWFtDQpIiYRUu27bQBDs+RVbJoB9uvcDMFxYdpHCQAoCadLQ9Mli IJECeYSRv89SkuXcYZVAha6YnZ2dnWXFGedcQt3C7fKUFup3EPiUwPF3egV8eMck5wLqffVl M4yQthHSOMwvu6/1r6qsENoyYfOqCD8l8u+b/jfMU0OVSW4XfMgL3yJMbezJAi2YlMrlBc3Y DSTaOOZdKOgnILHWMBOUyrFp2yRoxgiv3WYTl7qjgeLTQEMZqCTKDMHnZGPsE3T90cpDMyZK hvKGOWtMXtnRUMeC1zmy7Q6k0xqdVqJ0uk/TzYK+LadS1FRaSqZNKMxHe9otKVBjKLwtBJJT ax2YlaaAxjbNaD1Z4DnmzRTjNP0rZnSeElw2dYw6vxZyZ5j1593smtQNZOgEzu3FMsgnfmLH Hk919fS8rlbf4e5u9bz+9giYzfv7h8d19VBXq7pGs6DeVHyRQSmwGvP84eQVRk8xUmRGMvdP ppAx2bO2xSd12T0/7f7MfSLW6PaHyT/i8SD6IUEa4GXX7OOVdpqTViw93KWdEteWIx2afW5a 48lMkV4OZ8ZLmeNb8nsglGBCOJVjMTQHEm2Q2aiCmbwuYfDzp0RBPDZvJNghrxMF70hDFQtq udr/S3CB4RnlyMMWRtI1ySXmztscvieh+Ge4FzmUPHgpMIDS2tLfCWYSrhxD2eZv+B8BBgAO Y2mGDWVuZHN0cmVhbQ1lbmRvYmoNMTc5MiAwIG9iag01ODUgDWVuZG9iag0xNzkzIDAgb2Jq DTw8IA0vVHlwZSAvRXh0R1N0YXRlIA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIyIC9EZWZh dWx0IA0+PiANZW5kb2JqDTE3OTQgMCBvYmoNPDwgDS9UeXBlIC9FeHRHU3RhdGUgDS9TQSBm YWxzZSANL09QIGZhbHNlIA0vb3AgZmFsc2UgDS9PUE0gMCANL0JHMiAvRGVmYXVsdCANL1VD UjIgL0RlZmF1bHQgDS9UUjIgL0RlZmF1bHQgDS9IVCAvRGVmYXVsdCANL0NBIDEgDS9jYSAx IA0vU01hc2sgL05vbmUgDS9BSVMgZmFsc2UgDS9CTSAvTm9ybWFsIA0vVEsgdHJ1ZSANPj4g DWVuZG9iag0xNzk1IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjUy NDQgL0xlbmd0aDEgMzYyNTYgPj4gDXN0cmVhbQ0KSIncVglUE2ce/3JCErlMwNql+AGlcoQw AYMC2hpCwFguSYjxXJIwkGiSCZkBpKiQaBG8SlvEE0VtvV2P4rG+1aXPrgcVildF11ZXlq3W o2oVFUH3G1hFbd19b9/bfft25n1v5n9+v+9/zH8AAwDgCcoBC+QkqVUpXYubOxHnBgCi0Ax1 VHTxKfkdAHxFiKc1WvX2qhQHBsD8MQAwvjIWUdBp0TYhuQUAdk6ePd/a1TmlA4DBJxD9fr6l JC90QstMAKJ0AGQuNuH63D8F+q4GYJEJ+Ys1IYZnmvskAALeQPTbJis1o+bAdjaiRwLAn2wh jHpwMPkYAGVXEZ1j1c+wu+WwbyJ7tD+ANr0VH0Rs2QTAQjHCM9hOkBQ6B7oWDqDldgduDy3t 8gMgdBkA3IOIx+i96ScQ+aAnfS76wcNcIg6XF14xpuKBB8ONWe8SdmIu4V0mgyH1xAZw3fsk TA4HYDlcfgSXwWa4hjMZ7PosLBMTv8DxXxdQ7g9G9t4ZwABIQAALwAGF1rv0jcGX/bG96xqP d3QM7lKVPPHMWzXw7IN6l9d7mIvZiFYYUySsajg5/+rGrw7Kjq5cVNk0pEmt/RjzeI6VwUaQ nKulQ7C3uKxsNl/op8UdZrU53wY1jkKSguk4VUw4pksHYb60gkDo+UxBDFU2o0QqxsL7BMH9 lmYrDtWU3mo32/KhGncUmY04zCIISjoMi+7TjkjPgKkqeaIqVaWZAOUKhTJTo0wSw1BjWNxw +PIeWMAgj7jhmEwajQ3H0DURkXHS6BjpP8j//QM417wYcwYHsJyLUNyrmE4nOC2Bt00zxZES p/8u7u6Ngn0+HuMvqNsK24/HhO8+08mbNOzna9VPeANa//ybib9v/qGzcldd47yQ67N03uS0 GV8X+PYc0XWGbdVNrWX3RBp8dE7/poKas0G6qLMnRJy5sQdqtjSkjb12KyFou3b57MBVlorG sSlLpzVsiD3bzYs83RC3kslCRf1KSbAQrnifVR9y3j11rfxx6dnN97aVdHO6l4wqCN4cEXpp oRCveiKex/ho4gpDk8/G8nv7Don2ndQun+5uUB5Z9/kFWRkn6HtHJLuCs3Emz+9TkeL2A7+0 b90Wr/S26J7wZUubqtZcYttXhc/SL/7yqqBgxaajeYbEUUtqgqKXBVXN78p1f/v+qS5Uv81o xTJ9wUGfFRcUNwMfJ+vmVjUlV1aH3BLl/P8V8TbpUCykz3HAP4fx7KSC157034L4LD78X8TH B/OiBW5Cd5WNwh02nMKcdb8o6QUoC/Pokt6qv9mwfVF1SvXFBp+p5ov8MkM1V9rc8rTy4+Rz qviaa2e479VtXzdj4o1H3UZlxn6BDftpXezWSN6lO8TQrR7jcjiyjLIWTUbrPnFim6B10f6p T/eWt7bXNpQFqRK9LaeX7WRo1x/+RrIm/l7ZJt2Gc0F4x8KtM1b94XxKomlS5KyePUwG61cK 2przePlvPzN/cbrUHmEIDkiC43YE+x6lmI9Ud4e+OXlbRYHMPaLzo+8v76m9umDj++3ksTG8 up0XFlzw/aSJ1cEL0XJ/SP8s5fOT45PPjNDeD2w+/E5CZEh0y8orfxyd8mObNaWooxFb71Xe UtaWMLv+0ZJwaYRv1zHRze92XsuW25MjxbMxF28DWl71LCaDyfQuyau1zdnZupcx0FbX2IAX vIiYiQpa/ytRf32GYjBpX8LDn1eEgrBacYfRrLdANZFHFesdOMwsNFjMpAl3kFAh7y3JEdgw aSyGPS9JmoyOkcXJ4iZiLsaU/zgIaTKW1Gc0qri4WFKEDElkKDES1ig0gQnSTBGOkihFppre g3DYJdBQArPwPImYrmtJqiaJruVY6bvYyD4/siRzvplCG6qSoMKiJ0kYAyNhmtnoIEgEoR+H Vm8x5+opM2GDRdFSAcaj7blCZrZaKsR8aMJdyB+vJ02o9SjCJvXGPPtC4ZaF51oJW640APOn OSyRb797BcJIOHrdPpMLXiNHAYavdpGL4QEQ353pYjBAQ/Wpdzbl/u267+Gn1lJ5Bv8REV7Q InlDvSE69vIZ019kPaqBbbXd+DdqETzEPv7B/eN2a82NE1/sCMdWROtm7t08PSR/eeOV4h85 HT+11z7YLhi84Xcj59qvPCQmZ8wivLKU833P4RcTIKd91FrL0nhPQYjwZuDXcHHcB4Y5nOPB b3Zn1W2rS609NzJdN8pVeosn0+4xNSYq1yVI1z9uW/I4+6h40/rDYRkt9z69zRpSesc3fvPD LZlzOFbD7QXCyhHn2/09yS+5ow+EHr7e/EnB0UN5u9dqgr4V5M98OK+kalsef8u4rh5HYHfF lCP3xnre0OmD01p3xedeFq6eeuxDa6rfjlFuqJHXuzjfYS7O+d7svCVkMzGACehXLzabxeTU Y85KmmKwneXY7HLv0tq/nlT0mJb9POKELeGuwLXW+F9oJBeH2YD+CrFAGgmbwXjKHoSJMPrP r//Pzo/FdCsHKNtIhc/mYgg8dzTmYse+oMOnTV3sYMQeUh9WPtREUXYyPirqXzTGWhdrv9PF atCYzCQ04g7KnGc26ikcmnsbhi42nKS7xoHn4Q7cZsTFUG/LhWaKhIUkUiMhSTnMRspSwicL DdNwIwUpQgwpEw77g/DcL90vmQ69kaIHIhpNFG7FbRQMRUjC+AgmSStIJRjapEhvtugNFhrJ y976DwD1VDz/dQdNoFErI63IDdKDaIdIB15QiJMUOfplPcLBR6rPFF/OqRhGy+JiUBr1aELK i3DESCMKbZQeodKa8WIxSiGMG4YNi+Fnq+VIz17iMOebKHpISuPiYl9xB6HcYoFZtAaJPkQk msl4rgQqlFkauSqdP16elSVP16iUapikUitS5ao0ZRKUpye9MIdTVWkqNIYlfFo7XZWeEg81 Y5QwW62EGcnoVaXudadKVinkGiVEpFqTpVJoUidAdXbiWKVCAzUZtAlfq/w781UaFdWRhW/V e/1YBSWoIBofNAiaBppFQEFC2zR2a9sgTYOOqLRsotDNLiKjgIoBXEDjidtRUXGJE0WdUYS4 wBnN0bhPRhMdk5wYl/GISsRd6LndyCKJ58yvOVPFO3Tdd2+979767q2qaAVevFS99BWRKj4q WiKNUUhlaIcTTJapYhC28RMKtVqD3+Mlmhh5ZDRisewCqe7ygFdMjlIq3mGWTY2KlqnVfI9X GASVVKkJN87SI7VE3JNl0VI5Dru8jIzmIxQxKqN5BP6W8FESxCjVKCXRfJQmOipSLROZPhKn UCp5VWSM5XiZKUhKmclAGqlSy6ZoELxCohShiUoRo4h9Z9MFNhK9iubDJZMlE2RqL14tk1ka /TTuF8Y5wmWopVRjpKV6zH0dLpk+pS8XU9NysCwkJ/E6vc5Iq5S05CR1ZyJIcjEzZudhAlkm F6C9idz52vS8ZD5njhZ5oNPn8rOT+UQ9vkoyTaLN4bWJiXnZnRmYos/OMOWMZX7ndoMayFQj AoXEy3JHQLH/f5PmXfJ0fareKzUtRVxywFhJeLZkt7hYXMxZJZTJSdlLGTEjBAUenDlWFYEA K+igoR+cH4Mknt2tScWx4oGD+tRDMR5WyJBxXUL3HFNk03p24u6awqenaWd78em5mAvvny7B 1MSDelU6J9ZczGG1w78+5x7jSW2dcvsCzY3c+Eq35l38k/T6wwsjFm7ZWtiQxckH2iWfnzHy 5ZTg8qyDbfZBBTdW77cqDqiaIf/iNARZqk+GBRoqPnLPgAn+L+RKr+zfzvxjUXu43mX1lTVb b3/ecs8AZ5sfZQ/9YTOjO9KUuNC3IDx4y7KKN0vLAj287u0KCgxtePu0VOiDZRlrsC+6Ls77 H+wff3AYtObMO4NCBQLYVnJK7NgdJQvGp/fGwuIZo2dk5dNn2xEP7zFkfezY/qXndxsOUs3W Lw4bXg0/l6cQJ/VSt/aJFcdsExWPggmghWx8MkAPOkgCHqIhGVIhD9JNb3hIMb3JrXEtdjEy 7B3BMroOOiaG5WbnJecuyEz27nPMYUsJxIt4l7Bf6TTptc0JL541tbcGKsf6aFa1rqpd+O08 2+zrTRebl0gvxq7a9SxhldD++fjDg5fsK1H0O1UbsXj+3pNzZ8VHuO9WXxU5/xwk2eOiro7Z 9Ej2dr9e+5u3xPGZrmrA1X9dD7DN2nxNdHrCBbdqVaxM2b5WSQdn3nPYqa1tGJYV8G8nZYZ0 5cSC/XvjHq9u/fJecmNUeFPojGcv7vbf0NRy1mHII9Fn3wR+3Xgu05WxqZr18klLaOKox/sU tVGLK940vbj/Y0PzsDnTAgff/CpVrzvyFOrjjyWzp+fK59RQUmkmCdfa6fJtbOJPR/pM2cuq 5iU+1Nb2s1gv8qgwv6SMr2zzrCkll/Gkd75nfTifUnIcRceMxCup/7+/09KBcHzAxhvSFuc3 EVOXlp+L+KzK7ZF9Qh/yThM79OauVffAjCB1u98IfGxN15HRvj6+Yr/RPv5/+h11sxaXvXld Wag6cHeD2WurjCt9SVVSvK5815bqdk3IgqPc4HzbMxaF35fb2Xq2771e8za26NUdJ/6rsrXr r24/c3Nz9UNh9jI/q7PHHDrWt6UOlCvWvrg8f/gK5cyjIa/aLocdzT3HeTndinKARpuV7uVJ l5qr42qynPIm1R/8oXClIkuXNP3ur7EnLuWOoHNmHZ8Wx9bajXEJszYWOsI4kioQgLlgo8AP x8c7/5N/Qgq1w5sfxYMrQ4g5A0CXQ682OVIVCWHAv6GC4PY7ZAx3hzqheOtP141vBSEA7GsQ Gh9mAAgBDLe6nvY2w1uUl3e4ATAc6lrD71slPt90/jR8oP2BVZ/WS2/jB5UY7CehCDzAHXYC xT6a+IEIK8haYgHjIB6OoMwDq8g28IcTUAE2KPszbAAW3FDuBX4wE+3/imMPkMIOCIZkmgqe EEztmaHgir9GwxSIg93QAN+RFiDgi1VJD+txjhqUnYMWeEUWoNwexDAWQrGeTcXaVQTL4RIJ IS+ZYgiAQJgIsVjH5sAKuEWG0eH0DDjDJzj7GAhBm/GQgDVPDyWwFNbAJjgKFwlH8kg+qaJh NIcW0h0Mx9izekGxQYcV0R19FOOsRttpMAOtMyALrdfCVvgSDsAvxJ/kkgKynKwnD6g9vUuf MDOZVtaVHckqEKs1zsGjdx6IQIwYPgUZTAIVRKKvsdinI9K5MA8yMXL5UAALYBHOvhxWQzXi WwN7sO/D/heM3N+w/x2uwE14AA/hKbSDgTiRYcSZBJNwEkViyAqykuwgh8jX5BRpIg/IY9JK HaknFdN4mkqz6Tq6kx6g9bSRtjISppC5wXqzYnaD4FNBkuCQ4Cy3m/vZTG7QGxoNbbiaDKLv D47wMbjgGrqjB2MxDmEQjj5ocDVn496RiYgLYTFiLsVeZkK9CTEfgnpohgtwES7DL3Ab7hKK SF2IBwklEqLAHkPiyHSSROZh7OeTJWQZWUc2ku3kMLlCrhmRk+fkORKNUrxWoRdDqAcdR5VU i56k4UotoRXY99Dv6S36knFl3BlfJogJZzKZYuZzpgZ7HXOU+ZEF1gF99GOL2Ab2PPsd+xPb ynYIOEGFoBJ7B2fGTeeyuSJuG3ffzMMswFwIy2A7+vJ+2wTmYM++RXYD3QzpVAkHcQWXk/Hw lNjQduYOOMEkOprUAke9kf+hAgU9Dc/gPFxCbTlnBjmkQ7CIBEAsicFotpKHMJXcZxzIeNab K4ItiLqY5gDBlcqBE4IKzI3bdAcyxI1aMN/CYWR/Jea6ztBmaEF+jEEWWmG+ToQ1HTaIbiXu 20uRSymgQLY2YgY5gyYsaExQoL+fr4/Y28tT9MmokR7uI9xchS7O/PCPhw11GuLoMHjQQPuP 7Ab0t7XpZ21laWFuxgnwFktAJBNGJPB1IxLq2BFCudzTOBZqUaDtJUio41EU8b5OHZ9gUuPf 1wxDzZQ+mmGdmmHdmqQ/HwIhniJeJuTrLoQL/8N5tcc2dV7x892HbSAhhjaMxbS+5pJkjZNC m7ZJCSsOiQNJIA/AxWY8nJCsQLo1qJTBpA2D0k0ymdaVpt2r28Qfi7RM07Vhnak2zfmjarVp IZOSVq00QQR0XQMtIJi0tXD3O599o5BNeyF+Pud7n/P7zjnfjZER2zuj0L/VaMYM66rUN0ld K5ONQjQCAawwwkv3NhqWiBthq+nQ3mQ43oj9UgvmN5gNvfOrKik1fwHUBdCsJrM/JZqeEFJR msKrUwp5CmGV1WI2hq1ms5FNsNTScFeP1dEZDTf6AoFYVaUlGvaY3RaZ66yioJxCDfIYy9Vg ueUxxj52h04YqcpscjDjpe54sKDH7OnaEbXUrhifsShorTcbrfVfvbS0qjIjfro1as1ryAja Gj1LLXYi1ZxobIxhZlINJ5PfvHt6VWXr5mgA9pjhQYMN3ByVtmG6WLoSx3MfO5BzpdcMc098 v2HNM9eZe5P747iGkqRFm48E0iUtobP2BWoJG8mtUTNgrfWZsa7GZal7Kbn5yOnmkNF890hV Zcq7KMdhamFRXikonK30zoxJTU5nDVY7JAq2yGzG5VvGHgOWRE1LKa3ln95aSu6pxTT8iwlw tQ/MxJPe1UyxXuo1jeQtwhWbV6/c3dOV73GVem8RqxwIM8GEcUe3gkGrooJjwN2AS4NlT8j2 o1WVh6xWs99rWK2gjDqiWBRbvRKUBwJ8fycyIepGw0p0RnNtg7p9aQqtDMYsJc4jWWekOMIj CWdkZnncRKCewZtAVGx5ymb+F3mX3BPeu9oSS/7NcG9uHIkRNlKaXprsiJZ1JU/4yuLJwRiu pglJlkw2mUZTMp7sytiJbtPwmslUa2uyPxx3XMrYr5/wWU2DMcsb3yvAq1WdI8S6pyGq+pRY TlN8KrTWLWZr5/Zorbw3YsNcl29fJvJcvHPpzieeY9LUWf+UV1yOlofI0tfUED2v47VQhyji GqIWfZJqRB91KhF6VYnYE2of1WH8O5i7VUnQRsjDGtFBNUsbgO8DVUA7UAPsA3qAXQDP2Y75 zwHbsMdJB8o0xdwR6tL77OvaNPn0Yoq5grRED9FDWoLqoO92FVO5MklBZcTeok/Tam2IFrhG aCHGSlwh2oV5ZdC7dKIKdZI2adP2p/oIlWLPj93F9hV9iObrIcgQbVCCNA6bDyhBexJynUb2 TWWE3oTv67RiWq5GqA39DSyVIYqDi0L034/vR/6GrIAfj0DOx3kr0G8CzcBSdZqasE8p/DkA vmrRDqhZ+6YesT9UR2gZ9nODv8fUSeHTSEzAzhT8f5n9loDf7LPjE9vPNv1LwLa5EJP27Vn4 dJZtd0HaNRt9+GAMUjf2aAeva9A+CK771SH7BngoAvdhhnuS7od/zBXHyEnXpH0sb+dDHBPA ixLgGetWYu81+hkKIo4e1EJUCb5v4w8WH3OEO3xcG6EW2NMGvgKIiSO8Vuujbbi7O7w/YuE+ jBUAwkP0IceowxWf607QbtxrG9+fB8A9xYAN2Gsf8EWthz6j3oQd4J1tEok7l/Q++p0YooXA Ii1CMWAn/PVzHAM7sb7eE6RmeQ7uYkYCMv5mgW1wIGMtD+YfPp4EokAX86WMCBPyHUAAPwfO Ai9pk7QYebSLY5bjhuOTY4TjA3FQpAVpB9vOPnCMc5zleX4D6w4C1cAGF3QJ+I891nDOcNyy nTN7I744ThzJMc45nIt/pQj64+wvx9eMjNg3pJyzVuZnkBrYRuZGjv0H6dj0TxK5zfmVk/Yt thkcXszL6by8nZOIgQT7xBzbW9D2cT3gnARMrgucm7Ml/syTUvmxzNkSzou5EnzGdRu16i30 cT1BnsyVXFtk7M6RDr+O5NrD+c8SHNfm2+UynxHr/62UdQu1w7l/JzYcqRyldueeOBc5n/K2 tiHeNNj2AI9zzdXfsMddz9rjah9kyB7Xd9oTLMWE/QOn7jJHOudYLt438H3wfsw7cyzzLl9z 9S+jJnDs850hLvVltEb6ewrvziHkA+qtq5AKXI/QU7ye+9U/Id7uUIf6ET0sJsBXhCLch/bz 6iYqUN+lJ+V4QW6O+m3qkPN+iNq6m5Zq9TSoumiFHL+OOnYOteoGNStT0P8I+Xe0ec+P0R6n VZqCevcS3qgJ+wPZz2sguU/W2QWwt5MqZEzz3Tm5jbhy/8y+7v4z/C/EO7Ievofgu4I7ZK4+ AVfMF69dY5/jvTzFRFo7VYCPGoZc4/CV55HXS65wnnyfsKd+Kc+VG3u34rXuoXJPA+YvJ3JD 8lmY3+S5iHGyz+ffqI3q06gb79JixHyBzDE3+C3GHURpMUM9jHy4jprxSyqQfVz7c3KpfC+a 8RYhplzLEEt4m+TYvbBjOy1maA/af9PuyH0Wq5+nta46SNgn197G9wKfHZG1+0DuXeQ3B3w8 hzj9BdYXYC7bwHWL7bmCuv8meZ2YniudGHehFnE94votgqgbRL14m46p37A/4PqNmC7kNwp8 l7pi9BXcW4+nBn7/gbaj/vWj/rUBO4FteDPakX/fmyO/y3BPiv16lrLI+9+jBr8q355JZbk2 KXR9xP6LPqJ8PQdHny3nQmRzYywZs8f+1/7/B8rbqBnkAP68yFDeoR0M+E3uabEKMByJ8XQe CaAC89o8JI4z8C3mxbfhTeAZxPbrQA1wFODvpVL0R5y3E/eRRa3hN6wZ2AZsxTfP5YyyMr2v 3J9RHnitv9o/9KVqqGXpXhal6cPV/vpCpVIpJ4P8yucgqyHLlRVSrkif4mmBdA8L47VTT/i7 T22E6k8/+ZQ/I95PX9uE1n3pWA/EslDx0yX+Xc+G/Oe6z/WfO6We7z7ff/6U+hvFJ96jQ9iv RLyXPuQ3fiv+SquAEKCKM6I+Xe3/KCPqT1f7a436RaKessA4cA3QyItfK9+j0guiPlQuvGPG WGisYywxdm3MZUjFGrswphtjgqa8Ux1TF6auTekZURwqGHzY/wowBLTXF4k67FCH/eqwF+F3 JTAuW0dFXWijMIZfGLaGx4evDes07B1eNRwa7hiOD7sor/RjnEc9BjriaGjz6Lh4zDqePa7Q gHdg1YBKAz8ZGB9QvfWfFQGcFsA3fQK/gorEFXzgXMGZV2gt0A7sBp4BjgIecTVU8qO3/DU0 KrKj46MXRq+NajS6alRhTfm1eF+8TY9ii/2/6q727+vt8ddkxOLTX3iZ5T/orvrYpq4rfu97 fl/2s5+f8/zsOJBnx8QJcYjz7RhI8mISkmIChkBi45iEYL5TkU+RVkoTVCjbEMxtNtRNrSgO fyDBNpMWatAGmYq09p+p+2Ob6LSBWqpNmqJNdIrWrQk7z49N1br56Xd/1+eed9+595xzP8T3 gZuuzLnAM49V+xx0Mzdfq8wnNivHErVK02jiQ2gxqRxw8FLCpTTliBLVdsinHEqVKcEp6LFp JLNV60pW14Pnm4a0gkMZa4YIpzPvZLKZxczHGWowM5KZzaQzhkwC2nOYWhguhp4damUipUwD gpyQEIaJzmHtsyiBs4nFxMeJx4m/JqiXXtwMouPW44/bePwQHPwQHIygxPghRIkZxvZQbQCl 45qilbOarGY35za5zbTCBBiCoSuUoEAH6AF6hv4J/Yh+RjMBeidNYJRj0W0FEU6FIqC6oBg0 Ur1KUCEDJEES8GIrcZK4TNwn/kJQaOtWSEabyKpd7hweX+iqBXpRp6M6HdHpsE4unRw6yTrZ dBJ14nUy6UTrZFB7gP8AWAT8FPAjwDwgA7gCuAT4HmAO8AZgGjAFGAWMAIYBxwBDgAQglu/3 uN59SqdBnQp1cuok6SToZNSJ0olUvcCPAY8AvwPcB9wDXAXMdNWKnMil24x4HjEQw2/ny9Z8 GVBVJv0Bk/4Bk36TSb/KpGeZ9EEmPcCk+5h1bAnrZovZNayLdbIyK7E21spaWJ41sixLswaW YBEsbZHs4kEUGXJnl3u8YNqufVnKG8ZZWwRF9oSdOFtARohITzjb5I+AF3dng/5IlosmYjcx vhgHaZb4Vg6jPTEYsiY6W5S1bYndgSgaO3uhSOP02QvxuOz/5s/59T84En3pDsTciduM8gmj HGZAFukBUVoTpT9h0nmREy+kUCpy4PzgWvSNDvH/+Mh/q3Qc6wnDt2I3WRSOb+nX+V3CZASr B4s88bBsHWnJD2GTx/lK0V24dFxDJn88y3vDWTNAa9rQtqFNa4KE0ZosIBaeNzlf2eQpuouv PW+ygliE+UTjfj+azJuAJvL1/B+s1fH4hN+/f3z/cwsnJ/5T///DGJ+YmMzT5MT4JOgDjU9q nfnRONZk+TqeQFmy42iOcHQczarnB7Nub3uW0QTO54ISbzvM2sSEPnc31UzHIOwvHeeh8LZ/ /YuQoki7bMKY4TxMQvh5VcHwBWK+wARcJZ4i6il5By/AFXf1c+vnqLUVyprqGtEjlnpEjwF9 5SYXv1Ip9E/kNizC+8Fnn1K3DD9HL6BeONW0q1OYhzXHggRkRT7TVrQNTh+9lhizj0mYkhZK wKJxH1mMe6OIF0tDff2MK+irTH3pwUYP9sSLHXFXcbHLFa2sjHam+lKHUsspQ+pGCxddXqYx XX6jlvMVe0jF5ZDE0mCojyrkEN/bb+jGPbBdvkeS3QOFd/E/kIS/fFdRqrpzeFkVEIerOcxx VQPDqApX5fDfVUkJB8Kt4Z3hgfDJ8Ez4u+HLYS4cSC6NroihQHJ0yRYKrDwRoVwKiY6QaAOE QlCi1iXQal1Jghq01gWsS9al0SRohnQdSMPyaGyh1+eD1e5WEEvBID5HVfmnrQ/ikd0x1VJa 6hX5bb29Phg7whbrA/idyxP7IF5TDSfOUVyFG+ob62plu0QzskNWcAsIfGW+hlaoBR0SYyGY YlxXGwQlB83Q3hJohIdmLNhbor0Nao3w5N/zltB2ySHjACZ9ZRZsl4qJutpGfG9/wxvnpr/d f9zb7TJf37urdIOBGPfOjhGGrQc/6po5sqmt2m2heLlge6LpQH1x5wZLtKxj/tjp692VXc32 3XW/b1Jj7c3by0N4G0s+Wn9y+rSn98zeocvEh1NjdbEzswP7pgI1fWvFXw++XbG2gjdSnIky cDxtKu7+88E3O8oKDfuFVm+p3FHJR9fWbRy+sWPzyZ0VlvWF25xj6sChF+oaWmMr3zcZsLHu 5cCPDxQNJeu7YcPfs/oWPoMuoEK0+xZG3FW1IIcv3l5E9CkZNiy8QxXTckYmkDwiz8pp+bFM yTk8pYojAnYL1YIqRIVBISvQgubm0eRqyLqEAq4V15IYqqkueD5nZVVYm9CG+qDuBgveg3n+ WKckHRCMgrGg3L99JJpZfUuhqdoTFWvsdjttsNoLAqJ3MtZ8MQbbL9zMBol6fA/ZUZdaZaAI poBErKVfpPrJfnRd7DcWIInZy/4xKg1KI9Ks9I6UlWirFJUIKTCWhOALhVDgbytPnlifaCFo 06yrcwQdwVoFg8PLfF7N7wFcv9uy47Whus4SosXnXVdtrLAVTgcIfBdTJMHtpEgSY9NaUbNo 6tlnuAvdRyZU+h55lTPSsAOrFgR56kZwrcQImXkt5EeTSxDmNdXBf8cghNdUm79iY7O/omVX ZbglEFDbYA3pevYpOUs5YYRlaEzdUnT6oYhFynv6CPs+bEnmsjmEQrAs7EEpNIteRxm0gH6F /oSeIh52qyhKI4IDszoBjSrCHyDNfddU4Rdu7J4L8p18L3+YN/CQbsmV5Oj+JDxjedMg/5Jg HoY0wPmA9xEN9bYWyAfIFcYHvoOIZ2jRKkOY28rIWaFoMFw93HTw5pnoq6e3n/hoc/klLK6Z 2ds541w/M9M3E8TEqSPR79xVA/4zuPqXV3D5fNe1m6eyy7HXJ/qHLq/+bHXx2TAuvQ0W/hAR xG8pG6pHuxY8BfYcflk1e6naOBXHvNNpbqiH8/FtA6xkvnlSOyrbBHPWTCBztVk1PzIbzObG Bm2Kk6NPVkLJ/AIDUw3rSQjcW+qBgNOytrEZQ+AVBMvqg9rca1GYj0s9GEnwiJbPCobh2onf rDZiS+nGdUZwNEEQn8msjbE0sM0H9hklk8vMEByttFcajMCimeFFuaDF9C+mqz22ifuO3+93 T5/t3NnO+Rw/4+QcOw5nO3ZwfCGxzwFCINAECI+kuEnGS0BpHjAKGQVCKRBa0UA6OrSlkHaC raxb1m1dJjEp1dhQhTqpmrRRVVpAy1C1Khr/UFUTIfv9ztlDJzs/+85/5PP9vL7dFYD6atR/ 7V0bxzNWP5XcuIMBtuVPX9tenhcUM2suMVMmB+aMSkDyPPp/m4g/6bWz1bNROBGdDc9GyInw RGSimpQiUrUUJR0mB+8wk2aT6Vw0XBqNht3usNmGwKA/ipliUZKN3QY0waKqTYA/fwgtNnRH bwvSpqg5TJWY2DK2nl3D9rD97En2ByzHsr4sUfckoE1pUNMaj5WAknFdGVCuKzMKlVP6lLfw QfmH6Cv3JXy6j/LFMUfmC7YUootmIFw069zco3mkHnEOGbQWXzJi5LKFAhgaGgohEYURYwzQ 7UWrZI3LgN2gFPZgxDOn4bZyMp0DSQQ7fobcd+Xp530bLLLdu/n6g4tj+3JHFLlKohiOE57/ +bevfvrG080t+6++4ilfwb8uJ6pdNE9DjqEgwyBVUtHKPZMPARjcP7ZC9W1LUKzNqv5h4O6F gw+/XN96lIGQXLYHAJ7mfBtUNIn2xTlyN1JbLfGq7ghXKW6QIIiE2XL/qAIUxZHANZSi3dPA pC/3jzis5ir0q3AYAFkd57hMsDV4NEgGxx+IAG1/veKYOCV+IlLiPV2ekeGsDGSk+4XC0OBC AYUeSjecbwg0Ircwl8NxiHHF3+GoQ1YUxuDIBjr1ST8KFQJ7khFbMtadASZbRNY43wrmfnr4 xXzfzuOu5y51Pvv7FzfaayrdwXj/puMzIzvXdbiSkeHGmoHnr5CP7VdfSbR2r31rB2i/2fvx s/lEWZVUoWz57NqZH7dEavxdW7Px9oO4xdQvfkneRJhkiXXEHX1vS3NLy7kMUZrJEM1EayZ3 33K/dtjp9CWGW++rqo+gfVZ7iUhxgHe5KfZ7CFS6zEuRejAfCDeTOSbjzFRlyHhtMlWXaWFD aZJk87nQxSB7Mfde8L0HHOC4KRGI0+B9XTiZfjM9kyZz6X50INPIsucLGKR55NdiI8ILd4aC 0R2wfReMdmDgmcOtAtl7fG5+Ad/FpKQQK4kY8rQUI8msLKGIl5HZI3gRFcMIWUZmBFARRlAa qVQMAIQvvooG4chCsj5sw+xNp+gkvBYDJOIalNasykCYpZMRsQZChs2WVhurm2wRdlutqb2Z qoQJQm/b71q/1RsBYNPlm4FlTmD3064AM35m/PA7oTZkLAFBCJAAXvwK8RIeSamhVby9igY0 UgHDs06z2RkaBJ4DJy49/ecPT4P2F7/4Vx1EjZvYtzhLdtEeokBc18vIKODXrmlZmectlnP5 ttJ8vi2/Ikta8MKrW44IZ4W3BVIQ/G0QpRexDWz9cCMVngZ/1WOJb/xWC99G5vMK0d3dtXx6 OVw+TrhmXNDl6hGVciWpNCNLoE2EAnJKHIeFQVk0EsxaOWW47Ny8ViSynFxyghKx8c6dRow8 6l3/ARVLu8hu2Q8wxUtI1igEBrsN28UUz8KiYQjoh8YMkEEX+Y4fqi8aBjqh+/DrgdUpLcAM myhAymrn6lpHT7RhbcBZo5+45bvU2C2Y1KBgb/dEGFcD7dzfnf/olNZnEyy0FXEQ8OhFiqyN FZmTW6tf0LwCI5IcDajTJhKiZiE+uyU7mECZsqNLb1n/6vaeJLDyqmSVxCpTyiWRFKdse23j pdtVMkOTdhNXWrsvmghVPKoQIQC01Q0t0ZUsdvtdyGMO0H5CJz7+DdG0+Fj3yC7tCgNgHZ+B tAUmIcXRZpgWnS7NNw069H53wD1SsZ3aR12gSOoboqLiZawqx8ix9Ggapq2BgCjAGyrijDzO qrIaVnerl9UpdUZl48YfskcF6r202CJuEUlxvFxLaLq2S/u1dlf7i8b2agPaKW1Mu67RPzOy II4bQGEBvS+gQdpweuI2oKEaXhDnkc3XJmrA4OBggahBY1rycmzfaEqleGbFPoylhCe8NEt0 sf/1fYgzGGctCjWKsUY3Ofpqmja3ejmSfHtwxd7Gk10eibOWuNeZ2U5foiym2P3QQksOb3NF ev2Wdx92bqj7RcdB2i/YzZQ5zm/2b3rpgzciu0OnFlt/MnzjGgd9NqdQIpSGMr4uZtOubqU+ H5R8gPx69Mme1e8sa8BzeGHxEXmIekLkiZd+6XI5eX4azOqWiLc0EvFmMu4IH8OKUSHldbqt EafXy9c96eB7+SmeDPAnebTHAf5eeTaR1bMzWSqe7c/CLK51GD28tSA5pFK5eQ1rY0kJIOmK I1sv2nd9ynAedJGY3qhtYG0YsDiKjs5WhiuwM4WrlmBD1oT7Svrgdz7rGV4n98mcbN4abTqh WuUSmyXqsDHllgbvUG1M5CSr+QzTav9+vLnBBwFrps12AEkKUo9xW+VYS6z0LmpdE8OJQrVD KBfFFX2Vf2wH6TP9ISHkAhQFIPA1CiUkV2bx17eW8WgLPYyY20/biACRQt7/N/1KTsw1QyZB 1551kA1ig72pmewmjtZBGCfqykVbc53JFRmRuVHuKoektLfp5SbYNOJynXVdcZEuqwJPwP97 VNdqJmla8yiTZrM+yUk7pTFpSpqRaEJKSLrxAR11qReVs3vapOABCc+YB4qeck/Co3soE+EB OY9n1UrcTLA5DQ3OYxLP46i1G28oIjCXC+iFz0trpC0enwYPfgWbSyFsPlfcInF7GQQFgIvu /9ZEvCjiGC42FzSikBG8RheWSpdobmgBd8diQIPTfZXJlb9/c/J2pj7UPepOr/v8Rx98mtaW AbEzmNYPZHeeqgi5tluTQkerb1ky/tyJQ+PfhSfrAjXn1xz/5P3hVQNqILZWil7onLj/29fb R2KVo7HajXs7DiXP72zYEHRqnI0+VuWLHt5zoGn35UOvXMbc7kZbw795LvPgJs4zjO/37aXV 6lwdax22hGzJtqTY1mHLwmCtTS0bH2DwgddG5og5DESywZijk8RAEnDqeAgN1xAIbRNmgA6l JXHsMIHQ0jQM06GZZshk0mmAOKH84ZB2IAMhyP12ZUc7u99qZiWNvvd9nvf3rEQToQx7TVhz MBsQGBuCPm+RZ2furqIitsP22AZtuwbDe8MwTOoeRViRhawaUwO12hHweh3ISAieyCfKiXpi DXGAOE98RDDF8oIT1x2/LgkIgbWBQwFif+BkAP4hAAKyaTxFp16aysg3ZiKE5B9PJ2WcAf0J maaNUAN9YBbDZSaUdpCmMps2w35y5shsPbxe7/StHD70r3qFSmlyd2yPbeyte2l+c3lTXUh0 ahRKhYo1R3N/+fFXxxasJS42L0q+/vY0dnFHD6PWKgHum1e3E4Qvv/VxR+OGT050CRSu1OoY pfLWmXP3PBLhrErHaT85inq6FXV1Lww1L60iqoMohfQFq43BYLXVymurscqqpaEg0Zi14PEC uKDzYiWorNSW0T0Pi0DR8sbeMgWjzdJ2aHFGC7Q9Nk+5B3rMvIc/xJ/iH/Ik35NjPWGztXth NYYHg+zYQrBwHDoFczRq+JEF7AnBC/q8Q979XvwfXuAdB38VND8YgGGb01XigitcwFU868ry nk5Js5cPyY2NoXdo4vYnYlMPEnKvI8iUqCgqU7pkPhrJfSQByACESw0qB7fSMMzLdRHQZOSI kBMzhCA2x5UHS3Uchv4rh2o1E45mysHJ8YiP0PIEN2XsXoZPcmhrtc3nqP/7gXfS/xy7mx64 ex30fQZocHpgbmfak/70u/T6O4/A5Sc3QNO53/003NjEvfpuY23yw+ObuxaIujlXmhb1La6o 9c99ccQxdyF+Kd0/OeB2+A+Auj+dBa5jD9PhR9+m910BVqBNf5f+/W1w/BFQgGsAnE2/P/F+ +ujbdUK069S2F3sPgN6+lpqapGHJwF/2i5WLl42Jv11XtQiD0//FMLKLjGE92DYAhZqOTTf5 extwrLSD6ajC6+u2rdnSTzVU927clCRTsVRDrN9uNtrRyTC7G1LGhoZUyrROxGp0Nc01eE1N pwnHxZXj4OaFzqVix0UUuzoxL7gpRP3lYsAlBtr9CqPJjHsUqaxUQQofT4FUarXFXmAvtdfZ O+zb7e/YaXtsRXg4/Fb4evjLMImSXPC9/Z4PUeOMgxqB39twuAE2MNmt7a1rW/HWUytXA+dq sBopDSFXFJX4qbRYUIX75SCWhdhLN6WbLH4wpXswFZPbQB+dGT17i7J8CqkJeImUUQ8kEvll FSAYKfv5kKZODMgmZpCgLEe+l+nYVQxolweJVpo+MSC7nkxrKNq55AkmaRdN+szTGcJDa2kY SIjmyfcUQxkSoBR7eVrfpMm1hKscCgvfbW415WTn+uZwhUeWCAV6skpdxBG4Ux3a1bNDZWHM LEOqlL2FJsrK2RKFjpsxV6Ga6ChnTLn7WPyZrOYNAZMp7NJmecDtjcOLKpTqKrpLSXkEu9pO 004FoGlD8dqLomFeNaAr/13eDUHb6vC69JqvLi3TEDpCzbAUiVwC8TogNWoK0JDhGK4h2PmE hoDMUaenjusYE0WqGBo9R6KRhVM07KHIfNc57i6n6npzWX6TQ4dcV5z+hrhBOrAItlOwYoQC Z6lsZx6eY6aonBwzK5biZrGA4cYR84WMZkRhICfbiZ7LIzinU4DNsA/uh/cheRICeJ/kTNwy Duc2lRQdLpKCRlHGAPoTweKMthM+BNyxTIyUpC2dqLCzNZA9VYMjZSPWQFgBJWP9mcCK8NJw JZTVTPxGBTQ0xXovjdSHOvd1R3bf2VLcnL1wRZdThf4x8Bp0WVuvnjg+MdL+i9Ergy1HUleJ T5qW6Gw43PqC3vHc4c/7bqbvbQNKxhRdX0NQWfTpSkJR4Os69M3eoctXd9u4CsllzdP3yb+R JjSTWrAvJ7CW6e8v6C3RlvHp/1wwWqJRaVd43hIV/cP+0/6xnAn/Nf+1+Bd+BRBDSGRjwahY 4Ad+dPteUKETzTkfQAdmRnrLL49/Eb8XfxwnlPF9cRgXrVBwoi8SnGYzuhgM6KLWRd3oBy4Y TfIquJAvtrmBUjgmQGGT2e10C+4+N4GhZch9w33LTbrHwcTYki5shBuhJsAdrFX3w+SkPOAS CZ/8Qpvfn5ic1E3FkOkiwSV8aPN9mC+jpvkop0RwFCQlmSChRSTkC2bcMwfZLVLCrFBIFGzc ctaZkVVe7oy7SnMQxQB3oDbXJvWdjn+2kIM8U+t2P7N8lT386rwdn2+uPdjUduTNk9Vn+2vt TpJKr4cQTDcuWvPngyuN9ojncvqnw+uDFEUBHLiNOlJhjdw+sSK+C9RE9BYTozWRQEHhipKq wj9+umfrt6fbHCqaALSCpMqssS2vz23bt/uVxJnFPKWwmNTcQPzrtKof9Xpg+n+kjvgRO4yN C/nttxeLz952JpuTQ8nzyY+St5LfJ2lnsiQJk0lHIOBo3gP27Bl1fYA8Mh/Vb77o0Is26V0O qp/SAV9rf14cheIbqLiCb7R1cHmie93gqkR390BoeHjX4MsvH/WGnKHB4oTXezSeGEBVMY2U MIApRvsvwQVyvHJp0qG88ry0ZskOiElGODUZm5QX6bHNEpxIdok+FSiZNb7SfKlUyKOkA426 GTzng9JNBB1m3ijjOS2JStYVqhs5QywmcwWYra0M78GMZ6LZKC0+GSERH/oASkQ8LcfaSHBm boYyijTSuWQ+mfFMT2lQSesLV/EagBCcBCpO9GSrSYbWGCti9edfesPKd43qW5QkZGhAsgzr dlvsfmap2ZT+2hJh9SSr1uvnhDkVs+lMKaPVWtUshCSL+JvWaa1RQVO/sOpXPiC9VProfMVz zVeGWmIGA8NmEyzUmdN3X0h/tpM3vtumZXUMJHFKZcyLp7c/Adlr1QbkkTSrYEnkgwRFINck FYxmLr2+joL4/8ku+9gm7jOO3+9efHd+OZ9fL3FinxMndl4g55xjB8fGcRwGCQkxzgtwMQ6h vJUWCiHBdB2ItIxBSdYXWhpK6Rpp1Zg2DVVLKaFUYmhSpU1Ty9g6pm4a7RZtEiIS0qr+UYaz 52eHatIU+3dR7Iut5/k+3+/nsY22N8CyqxPKDhsXpij49jRvtJ7XMxzLirW/bplkeDNdGdsV onRV8xNju0UnoqoGp+q5HfLa7ionhWjE6fWgrdjSfXqAEYjDxGxS5tj1X3ZomS83Dk8OfzH8 YJgeHi7z+pHfPxbSDFoFSOb9MpLUDuMgHturHcB/GOO68r3z6E4y0J/3poPpZHo0TafTu+rz 1dVe7xF233Q8tysrnCPOJVl0kEXsNdJJ5MWvxop6WsASCimLx7CScosgpPZSoi4s4sUO0xcW EBLjzUGptTi1VGtLE7ksHVBCaCUKYR1Au5fzsPTjw+scdNkNJk3ZZdQaKuYvBCqWnGSDV5ff h4VTfKNdouzFJMb7RylWY8i5J2DiBcr9nJMyCeamSqFjCsmwDjVaBR1CPCmaeIYj6QqTJ/5S 54SpLygDq+jcq26Mr/SYGbvJqGMMNLSfN4jVRrPrj6nyuFHvMcHOxzkONFdy+v5XN2yK9ZrL DRaLsGKc0j9f5ykX4X9yICUj0ots3ZzBApEhN67xGiUWCXy1OZQoPKirAZMyONmuAR0jKYVX ICejdgqshzMy3zFuKVwRHBaDwySyRsoi8LCpLA08+oaM0kvEBmJ7EoTKH+2q0GqatHpsBUIN 6U2n05PpV9KzaaZxHn2WrEpl5Wmxt7fPKwZF0iyKcHlZnBV/JeoIEYliug83DyDZElJEaFKu 2LtF5ZGqNAepYplljCR4UmHuWwJUawTmU0HQo/Bjj8YDbYcFBIYY5hX3oDTRNhYuAon7GW55 0WZuiukZpszl75VkN5QOSq/Xye71Piik05uIVTb5hNfkGnJTkwEcFTKdREbSX3n2pXy731V4 3RTmacbe0pScPXTx6f3/QPmbLptehPkyc0ZgEZKSTLQo8K4ny62hOl9FHcf7DVzh3tzEzrkX PuvzOHwNeNMzLH1Dvwk+jOun35hCqVS3q1arwtPgsmkSXK+6yFatm9QIXFJ3N9fV1ZE3p+SU kkqntqWYVCpdOxPMEjOOaV7B8ofK5RajCtH+9SLONqz8Yk1B7N+SYqA1HClFGzZMVSahdGqJ L4pls7MOyWGjJKicFMKmWLovVMKPWi+o2IDYvvXNgp5kwYkoxLp8UwjZGs9vcTFlMX5jpgrp DB8KEpSNQvry59b8Yk3bmnqJMdq8VTrWDVIpnCl4hitlndnoYGmraQBxc/cSf2jRW41cuYHR 6UkG7kU6yuogWc7UKTbHr7UXrhT+mfDAJ+pIaVWNnxNdfTXeH47YLQaexIwysnSf+RtjJCqJ FuIHyZoP1I9Vkogg1s3Vk+frUf34HTALasZ9yU26x/8sIYlXME5EgSt8Ihy8r9yn+X5ipn37 8uYLZtL8CaM4lEHlkvInhdEpSNknE0HiWeINgp4lHsAHXkMjRFj8egxvb4+ALTBWwAU/xwAn xoicbRnTHtN4EaMRBjikJijMCyBIjHkeaqR54t1Xd1/c+5t3+6NufyiuHOr9+4mTt6Ze6yU/ GLwynQ7WydMfH8xePjiqqpuP/4g8vvudD48Fq1btfLJrYP/E9y8PpTa1rUtol28XBGX/1Of7 T5/c9c7meO7nn6QHbl840g5ft2HpIVPF8EQ/sYf4XbLC5/cfU8N2VQ1DavlWtVG+IS0aregh tDQWYE9KW4cF2MM1aE0ql8aJvw5E6O3hLNpvR9GoVkGGffGsv0ztVjV1r/pd9VP1rsqq8+hE 0mluQA1a9qnsX7JUdl+7fEMmb8hInkcLSQdPdKLOcwO5eNY6ncEkkMQwsOzeObFIaQrekkC4 UeC0HHj3Qnv8f9S8CKwMry0vR8ssgA28CAORkpm3qmAFtVB5PP0sGIeHlL7dcAIUxDob0Dks OvBnvPqUeA4vRAoq7T0JsshzRVKQWPuqszaTgSMpEhRfe0Gk9DXMSns/Yu/OPXWzyla9+nhv 28ATCL04b5LWjb7uCXiHKinEc4FcPVdhGK61GU+f5PvtJHqhwtQ1kupvbax6+5mKRppBHgvL lBvKL65oOHLq4fuHVIfewBp4xFCpt7fPb7eYunZ9/uzqOqtep+NJ8vSPkdDgQMi7o/AzW7VN kvR6S3FUKFrPkxeQxRSbSKzpbeujWiqvb+gDj9mwdJc6ztQQHcSdX9oslnkkJY9GwvZIJCyF kRZGEYstTCfucYjjXAlP063AQoAMBFzTBmQYT1AnYHUZd/ERS9hGqwK9An21AjXkfT6Z59BD uCc/Q1wirhLUAfgkQnXajwhIuG6OpWM3Yp/G6FhMVq8Tzo3OUeekc9bJBJ3IOY8uXX0ZBHFX pmRlDHcbOgrt7unfclQr8h8WwBgYGT6h01gC8CgFuhWrAlJciubGTi23H7pXXItKqIbBuwTp qLhHFbUQKbE7xjdAN+irv6bEi8VQoSo4mqR4He9985lDZ0Oh27Nn1h746K1TR7u9pIBIhgZQ Iw17dj+fPtkTjRZ+2jLYIP/12u71Efp2Sq9FRZqcnpwc6ohE9g3sPTP09EfbGl1eq8GS71U4 1mT93vbtqWOxTGfnXH1nT9uGqZuSFWfnf5b+Rf+eCRFPEP9O2vQNumFy69bB2tqOwU0rlcFy mp5HKKkMarzZiLbiYws+NuNjCB8D+NiIjz589BjJbq0Tz21HTEvgsOjt4HR5hIbz27Zldkj5 ujwhi/JBeVKeld+Tb8lfyJxXDsqj0AV55+oZNbt2ZiCnZomMmElmKG8mmJnNvJehRzMok9m5 YzmXF5eJHX4rDSI06TFfESO5Efz8/8fifTFOiPF4HN8CD2yNNsgVKD34YquMakOPw7uE7w5M XsVJ9Qf8j0fQZmdhCos9lBzwZzOqVhCEUymfViMqQPlLq5evtAjU1NMCb5X+S3TZxzZx3nH8 nnvufHd+Pdvnl7MTvyU5m7OTOImTOImJj7zgJEDiBvIGcQkmJCkVI+FlW9dWrCptEEMU2AaU DjFF3QuZ1lKKmmj/jG1lAiZEOmlAU0XppFCoukhIQ1un4WTPcw7aPX/4TmfJ8u/3/X5/n5/Z btOG/wEc3e9pTS28iYMegxUBDQCorSyr5wSPsOnkgVqSpQBwVg96rfqThxvOvFyqNZJGj3zA oqU4igLJ7ClvxS6fk6N4gdp7zmMOe82IeSGApEZLKYWUwId6vJd1HGMKbg+Kdirkz/24ZPSt jiKP0UGTGg8FKEZDahAWaLw8Z4u8MQ0OpoGOsRQcqyI1tD6xBSV00+pjWAUriCaiG9DK8RvF 4Iz9rIO8bbhhu9Fxu5uabp+xfdIBL7Rf6J52wAuGC46zUdhh72h/uwIutC90zHfCB/Z5x0Lz fBt1q/lO+52Ov3RSt/S3rXdscEH/ufULGySIRn1zV6pcSkrkXWlRIiWpLDVmEr1iuQh3ivvF 34vwiHhXXBWhSQSiGG/cw+q6Zkm/Ipl1nuEyJpCdlM/JpCyjMCO36adiqR5x6lJsMUaaYkqM jM2Cxwr3x81gc/aIAITyA8sTucxEbonHNle9ixSzjI+qo0ze/hmc9cjyFVFiAl8ZfBEHwESJ GtlroZ2/wa5VN7/YWr/zb6tjWFEqbKvgjnOgCmFNTQn6ZjAPNqrGYKnG6ZWccluxnRtHAbWx quHy6REHmWpqTZRYNeawy27R7r+c7N2mMKjBiGusLsmtp1e+YWDz2YivOuSN1B8zaExSpcMU cTV3BjjD+mjr9fVhvT94ZHtN4EWXp8DAcK6ZHd7OMvvkpUMOvtDoFwSJh/4jMXeZM6uUrQvG 7IWo44HVv8EbdCtRQ6SIO8q6hQQwJYth7fphZVT4nnBfeCT8W6AZVEiGGPPBGYaoHfbrJJ0b g0vYKdbdpGnZUFxsaJoi9slt9f31s/U366n67Ij7u+5J9zn3nPsrt8Z9VJoFLyjlp+QrMpmW h+Rx+YcyfvhSfiKzhMzLPjkqK/LzVxxHyKBGLkfexabHaINwPPEaCmDcQZTU19YFq8pk7OnE AIIe1M6nLnHZmZzIuHIom5HDM9Z88FbZbWZsXMeaufPbkAriuH0Y3PHQrkY0j6kUVK711QjU ILcH2H2vMiZkV5LsNrRnTMPpiiFHyBjIXtm9Y0rrjRZSmM2Rd6GlELx6/tK1o0MbgpzWXJqi vqa1FmsQ8PTKvZ17e+lCL2U3+YRMbGfrPnn4UHdLN2jO/nTzvDzaX6zbnPjAHf5v+jeX37vu tfr+/E2o0R3GhN65+nfog1HCT/zkY6UIWGcBq+icw3oGjTse9Q8/BxYR2uxB+fEtMrkuBfrA KGJiwBelCvoKRgruF1AFs6RPqVL4ND/EH+Tf5s/yczyjrjx4ExrnKf4qwfKswqZZ6gkLFPb7 7EMWss8C/L8yEweWcRMyqncQX6KR+TRTl8wt4SKXOFSaBHnxq4SpDj01MbHca6AXdJ4fHb+2 6/AfzpxoXyf7KxMliZKBhu5fj3e+MrNha9Phe6MTt3ZHCyI+uVEqbB+7OHW9CtN08+oX8BHd QlQTLcSHSjzI28U6dkw3YyACRCV6XxOATQlxrHDGr2va85L0inRMOi99Ln0tfSsxrAQkXWJ7 JXMzgIVXH8f/7oEM2b1ET3xK3DdnAZajqWRfkkxmsfzSMrwrLyIxQpPslcvlpDwhP5Y18rPW fAEQXS/lniI4fIi1xxvNVkteezhKUHGSmAsREqBPlCBEGCBFxfDswBpMIj6AVgarqdKB08QE NEXVamrgwtWoEwQXz4qkt4YQuHLkPPJ+aBdjIo9lqyiKgVqhxegEXv9pn9Vc/LM3u97vry/3 fKd4wDPZ5zZR/qPdB3/+2zc6fkDeKzy8MFjpIimdVm/0g5ZtK0dWOh+lOAGQFoZlNAWaIdrU NDo71HsxFmjmHCFD7nTzZx9ltl794N1PQrj2natfwWJYQ0SIBuIzJdZqA/f194z37GixpAhi kIoOlo4RlEJdp6CPiqIbSFFiUCDMvNlnjpoVM23GwszOG4BhD4diXBffHsQ/TZXSXCwbCQlx ISX0CiMCLQjrlUg6MhQZj8xFaBBZiJB8xBeJomcqcnWEO8Q95P7JUVyW8PAexZP2UE88QPEc 85z3QM+zxPP+IImakT75ZbMKbMm8Sl9XeU6N/6VJ4+ufforzPQPoPFPbGAGlQSNIApTXOKDX eK3mObChsLCV5LEg3xlGA50r+zeXoaUBbHnn5bqWxjYNKD2eCnSmWkcO+8OFcqJ0Q2+mId2V +2t5VS7EWUJbaw9trCF5SHl0Wm3F+o8yENpDDSGGresVuMLIn34UOd5ZHYha3YHSkw12ntRY Td6ucF8T8v7Q6iqsoxuIXuIXii8Wi+sqNKXTcc00ORjXzG0Cmza9sOdCy3QL2QJcA26MXr6S gQBGr2qf9mZbWz9BgXGUCFS/60Oix9JomQpXVgb2xXvGwyAdHgqPh78MU0Q4HT4VhuFwf98a Yy09rSvnl+v4pae4oJiDkeY/JkxmVfIDz3Erk6ssn8D3OXNdnWhWqcpepU7LMAjkx58NqhGK jmACUjlgioJrta3mkTkQP62xsXpUlvp/iCD7oNUUpTAY/w9PQtElvRYlAU1adR5re60VGqNb Op75gYnpFbUUSbtqhDCppdJeA4PQSs9YehKR/amdEY/slSJbdVahdocT6jR2ncFFcQ49rb3o X1mtk+wGjmOhTYc4CrJeSPICa9MPg8JpFtlHz1KS0aYr4oOjzua3KouLvTZ/Qcjqh/TGkasK AQlD7gm8AmNEG9FDvESsKn3v915+8UEjfLfxbO8vu6Bm+4ns8d0nhilaC4jh7O8m4+fiv4rD eFwpu1u0WEQWzUnDBYPvINpZFOH/mK7amDbOO37PPffcm8/2+R3Mi42BA0MCBhvDEcDnJJBA AnZSJ2CCKXGSxhAohpbFXdqUNNuSptqWaqtWaVoSsUlNpanLpk1xJk3KJBatjSZSTdPW9AN8 QFU3jS4fskhdF9jznE063XHcy+MD+ff/vcVI2rHkxQ/Fv4mfi1+KKCAOjnqbwAPcgPLgx5r6 3KiFOz1yduQ3I3BkVDPXuxpOUqGAGO/PLO3dO4Xueh94aa937CzVBbq6znwYB3Gsbas4KeXB p1rJSv9qP92f+6MJrOCKZArl4gisIoBIltYDNWbMRkqvQsHmOT1c65lI3wsViHQlVSVrUnM4 h+uLUk9V4rZzmFYppBTqDgby625T6DzhZ7gSb3UWy1FxTNB2WyqSD2JaBos+zMJiY2oChYkg HwEmKXqw3ux8o8FY/s7vfrinwxup52S75aLkMksWufyCCZkaR68dYsvHBmtrngfCS4vRF9fe vvFBf/x8rTs8Hhh+KXfk+XTVsbdO/OGYt32nd9dN5UwiupstawlUuGVXg12wjP30O3dsYn0p RBbB3izL1fTRffvejYMml91hD/JM51zXoStHh8Z21i1oNnrP6Cu7vn35ze9f/urPfZGFkDfi lwTGuL9jaD/mceXWl/A/KESdpm5r9XcG7vvuH4Dv+94/cMcHJyYXJ+lP+kB3Rh0LtWaCYyHR nLHexiqf31rT7EOedD+VOTGWTmbGx9Ji/6karisPPtEMe5daZ677waof+PNgl9aAxqY8iSV5 5vTMIgIBpKE4mkBZdBWtoUeIp5CMAvjWVYTQHfAilZGfEKLjSLUuY1AxlkQydV4TzDvwaeGK IJuiUimdsnXtkMSkoq3ptSdIsi52tvA2c/EVxscDnC6OoNsIlG6ADTBMXDBcyAV6EiYf4lxO vNADSNGq0/UhpCxYDThpASgYS6Zpk1s6G26hAWDoSEXoG9FzQztx5WFoVfWAv1jjLbwTmZQu iWYQzThNJ6LhQNWYVQI0dilAf9fghKjCPPTzC6IdlDgMXOnuBdAwGzu+njS4ShFnpFng85a/ 8/rPPrI6+0saWjLd2RfUE+dc7h1GSfSwDC2wgpU1iQb35wMLg20RlyVRaW/q6xde1vrMnA8K BkT+V5z8OJ54JrX1FbiHKikDFaHuag3LlffaP+qBUsb7KTbB3wtmR8xBh687gNkBVhyrjn85 thyMgwsmm4hy+6uStfj3r/yikAd2zXYL3oUP4Bp8BBEEK+wqbm554NQ6zJSH/KkW1Vztwfox Vb60Iq1KtDTT8gqlympWXVQZTY2rE/iUkdWAekOFqhrVtrV9HVth6tWCK27MUZG5ItCRufl5 nLZLH8+5SYKZsxHyFgkL24sRRQ/ODhtkdVLj8yIhOV+h8OpTEraEMM7fC9bUdnTU1rYmQBTV xMokTsI5GQK3Vm+HqK77uTLjDyrLkQHZmLRXtOAC2sj8qSoQ9njaWzd9FTYo7/bTIOBE9W2b a5srtRVWA88hVsAlFuHWyyETTztYk6NpECR7LZIHsyy0tQk/Rl3U66BBC/QdAJPx3t7s9KR9 enoy2ts7ofjtiuLvVaJ+pr12ejIOT9Yma2fB7Oyx9sPJYYLB6MlkimAwKuby4KFmWUiC5HnR krHfLqFakz3JNmKt7nbWPl0zHZreO830TitwLuo3Bz3BWBAG8+DvGtbK+KSULk/XpyNppjIN 0nmwQ9tzKfGjxHuJ24kHCbSYWEmsJmDiW4jKyTlvLpDTcvEcm5vxHZlbwmloEcxkEdB0+j5C DKEujdCFxSKCxJTlp+s4imLi4l1VsVDjI449GM71DYJnZGNj/Rmbcd/FyZSk00umpkbmNXn5 Emoqabz02jLJ78G6Hthmqwvp9A4V8irhNVsBMJVdHOFyazvRX6K+dYru2MFCjC1sZsx10qm+ 3hyc0giQbuHdoGDtIeIMjYCovb5WH5tqX5jmTcNOmib9yTMO1B2ucQ8g1QUCg6/6J3FjZa3B aJVodG1h9wFk9vZ4Bw+31NQwAlPimQ5ZHEPG8na3jQH7PNbNf8isaIAsOiELfOfLA42KwtgN hyWe7vLvHmous1ewkK3Kgbf6hM4y5YN32z1GiTVIVjHkQsONsbP3nhw0YQPOHrIaLDJLQ0SL nJGFRg6/U7T6B3ZUejiRKa+a77GXDItWETESJ7I4JPAsJ9A8ogXLwQuHy2ou5Hw2UWSdOE/g mRS3noKPUQu1k/qlZv+MecLQFRAYIaAy4DYLLEkXmbtSb9JNRstYKl5vvtFMm20eG6H7Q03g OJ4XjJJk+C14SIn4jmqbEpZIEqYrpxRIzVCKrGSVGwqjKXFlAp/eVZCsBPDFLYURKAWE8U+n ojQ3kVHADE+NkyHC6S71dP3x4y65sK2nUtu5riD681TK1hYuKLzMbeOm6wGOcSzhew+tD02h 6ITKfa3pZoCgIJ0z8ILEpS/elHnWeNEGGYwmdNaEmb86BVGuCnD/vX8txWaNVhPHiAYBMhzg kCAKTrO75r3PvvhiodpjduLvrmZrk+XhCHUZODTL8s7lPctnobtqcJ5JzbYkQ/oXFk12iolk OpkSQfIyvvPrxW8mtfPkUc+iaMp4zf8nuw7u5kB+gB7AFjp7qpJrvhK7cvUKbO6OdNPdU73Y TtcagJfEpWwDaCCeWtp8PHKcPj41VTW1NDK1FgPe2GqMzsZAjDwN869OuY4sLGHpf9M0o/Fx foLP8ov8Vf4Gz5G26eUD+OYv+Fs8J5h5ECGHAzyBQMdgm8cyaS7rGzog87oVEyg2SN4qCLJ7 oySCD/K//4lpHdkoFE0i0du5uUjNNizRuKo4C3ZM1NtV8GQXNlvWRUiKSVutKzbeiWD30DiG 64XTDApdqCDr1XVV+Pn2+yOAQIwX4TGwPVuDb5hBNXlNvVxe77SynNFZbaje1R9lWSOPAH3m SGf/8AtNybcHsvv3YQ8HNr6tSmK5U9a6wNGgwQu4snEXJ/2P8bKPbeK84/g9z735fGf7bJ99 iePEb4md+JI4doITExNfyAt2UkiABsgbhPfACI0RStqyrlnpxso2wTataAUJFKnb2FoNtpWF dX8gBFM7pMH6IoYEgkmgSpusIa2l7bok+z3ntNmfixLb9/iJ5fv9vs/39/nuXZc+1AyuXtZe LkuCPbFwrx8jd9oX4OAIshjtemrNiRhikFqtOwV0KFLtT/gmcUhkWNHmrbzzYRsMAiFgT64H SjgUqt4e8azetKU713Ni4/Dfa1y0DYQl2jj4AIE3SZIt8h0UifUOZDIlP5m+lFAFhjHLFhZB ioBDxkqsybr68NHckXx3q1dduHDQxwkWTjKJJgQyZVlQZWhxnqHoXmqMKujRy57LuRueGznm TO6853yOPu45njvjoW+IV2vw2I6ZHfhR75NezPUildDcil51OFs7HhuJN483jcSp8dGRTeP6 4NCwZdxvBaU6+hygVAdy8NndeyumK05BwOVXGLinz9ZOnA2j+2EUJuKLsVv2O044181SEzcB Lv4v5tteZD4A93RhmfpGC8syi8lpD+grtsyB+VEyIwjajxoMAJpYQRO5GdagusuRuoQGiQpU jhSD5oniiIZ4rhjvyPuGRoEdI0s6Usm+CgwPsBEoMdIULg1kSgHb5LJcLpKKBGkkyelvxH2R DVMhcHXXmMw5X34pu4rjy+LlblkikNfUtLljJk28mjU1ZMwKj/b9tVcpxX7wkxKtEkZXY5vD K1Yq/rq1KKasdpikupRo2jJ98RTXWdvttFgsDpPZhjCmXZwZAMUklci8q/53Tf3fjMdbWxuC 996MyJzJ7MCsTaGxhSecl1t8RN+AzCcDiu3Q/SZcgvG7DCod4nj7kCTuc+0px++47rhw1vWs C7vmsF8Xrwj3BSz87HY5KifXyiSFblKPCcnJVAPVTzHUf/zyAvSnADO9kF+yAIO+nU3FAjtc CgMjtR6hpTgUClrhRLtzqcPtw0ff/mLh83e/fnDDFPr9U99/uv3Y8OpXtr2Ofth5+khFdJH6 7bkv2uNXFj7Z8Nb0uj/vbbswe+ltcicl8/+CO3meaob8+gc9GfYmvdjbkl7VFuX0bse43wmi VFHyrIpUvnv3Xt+077bvI9+nPpb3IR+vD4XFuAFFv0kyg82EnJJW9xxar3d4B5p+VTuQnhVz HYMdcx3vdDAdO/YEp4LHgqeCt4IfBbngy9SEY+KCiCbFGfGkeEF8LLINoi72i2MiWeLEIq3O Q0GISz4sfDmegFT/R7PEC0GjTrAhI2SsaBKRwSkRkF0GJVSQGnHBLwNnOMK55CVO4SO8c+nq q7BZivCuEhtrorHAmkt7uQO5gMRbEOo5t+m1D6b/sn/osNOG7UKs32Njdw69ehTz1mj7cy+8 cenHmf3zT0SBNyuS3eF4DV1EBzerEu+0VNQ31tNcRjnY0nznly/+aVfcxPW3LdyoUhjOLpRh jJjnrdLCaa3P3/jm8Z9eraHAY6oW5/HP6e1UN3VeT3hicbpLu1KNqqs127hfhp4ofQoYhQLB qUHTtX6NljW/hr+nndHwXQ1pcziomwP8qsH2kS56kCKN6TIr0Ji3qIycwZk5NKWXJ6hKVFmZ VQcSs+g528Sk8E8B9wsnQaVCdo3BmqT8D+FFHkbTcvnzh/L55fI3lsTyxXmkRpoymHRArkek /EWDcJFhZHTG6AFhvmJi4FwkIy4jo8IDVoT4GkZo3WhmOJN3ZVBh9lUmoCcIh1Oq1dIdrG1R ykLyVptX9Fb7WDj2jHxAsfKaXTA9E121pxlgzSrZWMGio6f3eU2sqULz1eVQ4g07Z+laqcpC tFULOkuDgruzUXv9j0EzbxYgvSGRNXNmeKZJ7fOLD/CP6DTVgpD+6w/CtyLvVd+pZa5GrlVf 125bmKvSNcu1MP2++L6Ev2u5bsWoBm43PGmRFItFsoSlCFPf50EeT71O3aIeUPCZSgM7VC+q /iGFvyQh2AHhNiSXT53woM1kZ1SgptRkOJlMdieZZDIl/1tAZgEJ0zPRxSjuj45FZ6K0HJ2M 4ujF0DQly7JfbpDXy2PypzLfIOsy7pdPyligZNQhX0bbIQc+KWJegRAFuEkxBRiPefJUzAqF FPy+YCRBYJFRWDxWr0E8IJafp/Lw00ygAZjCsO9Kg/nIWVLdPgSebYADAUP6q8PVRPYkf1Dl DO9vS7VUx2ILn9fV9bzUvCZfA4RsEawVR9LpnoqKe7sbhl9Jvvg1M/i9eWGbN5WJV8Xbm5M7 W1qyneMr3GrjTj/auD3XWhcKDa09mOh6Nh4zuQXlWKlkgh61LP4Dj9J3qQy1S5cS8Qa6cQRy l/0XIPVy3c1zJ/zI7y/bFRErKydhPFra6QGK+JLDPVubTOp6LZqsnanFtbXterEoDsJiBSL2 0cYYlZlPxEYhSsHix0TayId4NykDoSky2mwYbIVWVGOxmSibJwWoh/kIASqGbChI6mBMvuYk qvAx2Ml6cjFNqcac/fRaB/hLmafJk3VXCYKItGdG2gdKGITtG0yiaAt7ukokt0zfRduOQNRF imTxshiXBl5d+Gw8GJJZL/hMTEtvOP63A9VeL9C1mZdssriqSmmpgeoEFgv0fdpOjVDv6XV1 cp3eI/foQ/KQzl1Pfph8lPwkydi2ItvW2Na+rbS9rVMuKU11ypItZZ1b/Ewvcaspq3cwEBgZ pLkriVuJB4nHCSYxDj5P6d6UaN3dKbYN2Cp8kECeUwGbz0YeRPD9CIoQMGk0z96ErzBxNnsu eyVL+7OT2ZnsSeOCa8jq2f7s2NISfyGLBCqLVmYJEh8y0KRQpJLRh2T6fVzIZwppueDQNC2V WhLlqLNRbU74wPlAeUSbhueTP8P1gU8aVWgT6NNmgGorjACgFBJUIYs2RYzESqRa/CdDrqRj QCZgW4HegGdvKdRcHUjnvhVjaeTfH5JNtKf07AArmjGPMCPwUpVgWYW+vTGgsshi79vyX6qr P7aNq47fu5/23dl3Pp9/XS62Y8dnJ3ZiO77Y8ZI0lyZt0x9x0x9JY8seblKSQFFzSdVVgm4E hFSmMihCldiALnRMyta160/m0sIiUaFuIC3AOqn8syANxK+gClUCJOrw7pLCemf5Pb17Op2+ 38/7/OjOfW7rADSYALoXwPdFOcwBA63zpa8VmCvjnb0Jpf2cGvBcaGVwM01Cyt/53dV9X+cx grSRTGMjQ4Qt+wg3fGlrY6Fwh5ZSTioCvXCfzWHrlHmbgyARsP5o/SPsN5iEDCN/12ihVx5C ZY/gR2vrL2ot0uBAcGhwUJdcoiS5egcGqpIfzvyuIanXTwzuzhaVYoq0FSlDq9HdpiRoEZQc WBkEg8yre8HggCQN+3u52N7YdOxk7Fuxf8bIZOzLMTRWA3/W3Iiqqw9VDFF5dUStqosqcVYF MIFd1STXEALlepHBeAYgTBCK9+vMfeYPUMBr4MxNbXhhGB1Ozq1V5ufy+U02yud98KDl8xXE 2zfX80RXTCk/TZgMdLrdawxxo+kVzO0xjp6pEyJlNtBwmYZ8bJyvzd5HjZZm4F4j8oic2XN4 GxMsrCQBZuhSJzN7oLvBSegeO0mQDmF3hoJtPTKQj27VBB5rCFIHKRJ4mefYtleDcEeApcZE Lsg1qozte36rbc/1rPsEiUmAhIkGnlgrzRDAwhEE7SKcD1+f23X+zdQOO802WoEdp6AEYQDD UBhBLABYeKbctu2FhmD9Fa/0Q/DaF8UgT8HO/mX918Q05kLmwLc1ZUaYSU90YB8dvD96f+z+ ofvjD6bIe1MPnA/EB2lcEPhqdeLZsrO2/sp1fmoiWFv/vnZSLfcEneWyriZFVU12HSiVqmoX nHYxM1NTOs+IPM9UJyaqvABnQknlZxgn3CZUmZGVMiiXS8zEyhSYYkaKW4rbSE+xpRggyeKx IkIGjieP9x2fPY6Xyj5VLfimJnSeV/SuA1w/6K+Br2oiWugrDBQWC8sFQi+sFlC+AAo1cEkT TgnAmRSqOOfb4yv7PvDhvhpIaDKi9CmLyhVlWSFSiq4swMmKsqqQvBlsLmlRZgbBv4NfwK/h qziB/wLReV3TR/SqTiD6WR3V9QX9oY7pSQiotcoGpB5XoAc0sWVAyyB0GF02BwNja2ubPwNs c46nUHb6+U8PBubip+13LfA2vPdcBSNM22IYbY+pe9lctB0zc03Gk8lBtEFN+D8oPU63J/sp TEJIZnIdhkxk/MB8D4WRlB01xVKJoiYXPXGscLcLLDAWbnsIxaTQoZNTfb10wPF5GpBee/55 5Usc7SAZlAtvDTMs7jia9LXuaWhrDG2JCATD7SP2R/3RDpLA0l2p674t0I1AWZCrkvtHGTtF 2X56SaAdca8NYCKwWJxWwuuirWz33qv/uPbyonuc81sokiENEgNBK04JrNXdRKv1P77QMXxv ++HehCdot0BAQ7mCDEZSjI1s2lXf33NKCtJ47l8DyfrFAmS2M2B/gGIoHOUshOGmqDqFzWFe ZBKyViOXAr8tAr6Slxskr5c/NDYmj5e8GK6NFZkDNUBryk57ptgVBuFiC8kWDxdxcs8eekwr YTNe4PVO5mUuEoigkRr4ihZTUrnU9tQXUidSBJICqb/ylRUaaPQCfY5eou/SKzQZpHUapQ0C syKTAJmsTqKThgGaqxhcZOBmg4kgfLzQACEmSuaNhJHPQy4Cu6/ERsY1sVIq6V5ehB+c17Tq mCzCz36ap4qn7fxdS4/9bg/SDq+N1JbtBjmPwUWuDRYSN61udjOnKIbgQPPg2dz1P8ayAw5l wBPuCodMqeoD7ozhJ6BkYQqmJFGlk3Vzqf7RbbkEDlyJLQ0oJBv3zs42uXlU5kgpuoMFpGXL wBGNp3jaKj4TcLC4lXByLHjzFMsrlN+d4RxtrQGathXdLjq9XZr1zFPMoMuBiSiKoRQNcy9O OBiYaLy7Pnz5WE95rVAICJxkFawclEZ4oVAULZjFzSp2N9ulyERdq7/ti+ygIpwbj4aCEkZA XeB23giE+oGSB90i7cMpGzTF29Z/T6wQRxEOCSD9yFXNmk61c6FACA0ZFo6PlPrL+TzffiST 8TI84H8C1iCafnYT927zot4aWNMaLEwqHkt3pdF0Wm7qD8WDo01N8mh8Ko7C/BPUuGxWfg4m pPPsKRHI5/EaWNY8VVZnF9hF9gq7zK6yD1nLCHuWRVkYdR4bMdOwwebfI8cGgVSEPESF8RAu rsEFw5w4TDPSgQsuEcXDoWa0UxWaPSEcdYkCnuloFjpVtNnjDJv22GQO4/x7YCeRThUx7bNh WzD6Ojj47p365Vqt/vadd8HBa6/V3798EahLS6Dz4uX6+7fFaPMPju1faPHHfnzu5yciZx7d q/8beH/X3lvwsbybIY6+U794q1a/fPs22F+7BUbf6V2qv/fGUv1Xb70F3/IGyC0t1/908sRg Pv7NvR++d8H5S4DdWgYcK1kcMoKgSBELYyXChQShj9Y1RwQXkPR022pOmLavarlpWOa0xi73 TSNYpKkPC89DwW+6Fpt9pga+cVPGEXTeBRc0Fz2bkjV5RL4iL8vEIhxWZExOGuHjP7CFj+Dg gVX8RHps/PjHn8DCGgU00+AT3tww13CJNF00tM7ZyBPedT/92DTW2Qw4ZcHHfZ0+B0/biXaC jKR6W1r3Znblq2gjwPXPsCxPEW7W3tKWjw9NPLv9sEy4BCvBJFytcX8wINoxkIxE863l9q0v hp8RWNpiU+fTfKONILB4JNH92crgS7EsrNIQFseGiQgiI1lk5gbSyMpZozBCcpmdtnwstkxH Phankxg+64HVuAErO++ABbqeaJrtMMrjzjbOf5BYSaBUwpPQEiMJPbGcIBOQh/6W/2/7ZRPT RBDF8f9uS1us/QBaPlooldalCC5QUypYUFKgFApUxI8aE8AAShQwRSUaNfHiRUNMVOhJLx70 oEGiF8/EGE+GMweiHDwaozExQn3dWYImQP04qMnO5vfyduZ1due/M503y5T5fK2lgwfJI0lj My8H2PRiS11wlaR2CGlrkAUgxbbXsNRVblxtor2FF+MuwZBp0uqt1myHweLzRId9UW/vSta4 aDPqDRmCVldS6feGBwNTzapYjzNUSn8LHKfXO4vLvEPhhvFgmShG611iscWk5ardpTWDHf7L E3aslrb08M/XR3Wc+AiomxgZuwGNB9DOAroXwJaTwNZcwHAXML4GzBeBrAcbk3MTsL5n5BmB /AXATn0WuX/EMcAonl3DOb9GyUvA3QcIZ38dzxCwQwOU09ArLgEiD1TeB6pfAbtmAF8Vwz8H 1FLMnimgPgE0kBZ7vzAazwNBG9BE795C4wi9IxnnGJGF/5fOvn+frmtAdFJBQUFBQUHhb0G5 NiflmBY6H5LHUU7EaZC2qCSbKVmTOQs5FmtuXn6BzV7I2l1uCKWeMvJ2ohLwUkZW4/++g6bm llBruK09gs6u6P7uAzh46PCR2FEc2/CRT5+tV3s9/bv+VlFjhqxA5zQ1NGQFiJRMNqKFsu0I utCDYZzBBC7gNh46C51FySTFp+IqUIV9CMpx3ejHKcQp7tZqXPLtxhe2Jd8sJhYT8lf5maJK G6HDkNyfCiaynDxCE13M15DnSM0AdSbVOOijMZ+HEe2yr6L6mOyryZ+QfQ35d4KRjnBba3mo P94/MjY6sPktiRNBB8IkUStl8SGSKE6MYAyjGCDJBnEC53Baqt889k9amRL8ND4ggHlk0GjN NFnrSJo6/rO0HlLq8AWJyccryV5T4BPsOkmuR8Z7km5PrmRPrSwt39Bd1S4htRzYL/ANkX0y 6gplbmRzdHJlYW0NZW5kb2JqDTE3OTYgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUg L0xlbmd0aCAyODUyNiAvTGVuZ3RoMSA0MDk2MCA+PiANc3RyZWFtDQpIidxXCVQTZx7/Jhck kasJunYRP6BUjhAmYFBArCEEjMtlEiJVa0nCQKK5yAxXUYFoEbRaahUvUETriStaPNZtXfrc eqBSvCq6trqyrlqPUu8DtN/AKmrr7nv73u7btzPvezP/8/t9/yP/CcAAAO6gDDBBVoJamXQ6 JuGPiHMdACFMU4dHFHUlDwbAewDiaQ0Wnf029gWia2sBwNYaCihYsie3GsmzAWAl5thzLTve l/gDMLgR0bNzzcU5W1MrzwAQfhIAvdFI6LK/vsLrBGDVQeQvimZ4CLguAPjiiH7LaKGK5IVN yN5XAwBvstlm0IHLk64AsHAUorMsuiI752vWLWS/AelDq85CeD4QTgdgZRbCk2i3kRQ6B7pW jqHldgdhv7Tz8EIAgpoAcPFDPKz3pp9AyEdPIei9hEzcKXjK4YZUjK2474a5MOqdgi7Eus7A MIk7PoDj2idhsNkAz+LwQjkYC3OOYGCsehWejote4Pg0+Jb5gFG9dxrQAxLYgBkQgEJrNH3j 8GV/LM/SCu6wgPqGARlRQUNOXYvdWe/0eAd3MlrQCmYIBVXNx+ZeWf/nL6UHVsyvbB3aqtZ+ grs9x4qxEKTylZKh+BAOM4PFEwzUEg6T2pRrhRpHPknBVIIqtDmmSQbh3rQCX+D+TEEElVaD WCLCQ/oEAf2WJgsB1ZTOYjdZc6GacBSYDARU2WyUZDge0acdmpoGk5WyeGWyUvMulMnlinSN IkEEgwzB0SPgy3vgvoPcokfgUkkEPgJH10RERksiIiX/IP/3D1C+6sWYY2zALJ+P4l7FKC8H J8SwyzhdFCYu99nG2b6ev8vLbcJZdUd+56HIkO0n73EnDb99tfoJd0D7X3478Q9HL9+r3FbX Mifw2oxMT3Jq0eE87579mfeCN2dOqWH1hOm9Mst9WvMWnfLPDD91RMieHbVn0abmlHFXb8b6 b9Eum+lXa65oGZe0ZGrzuqhT3dywE83RKxhMVNSvlAQT4Yrxqv2QPfr41bLHJac23mks7mZ3 L47LC9gYGnT+IwFR9UQ0B/t44nJ9q9f6sju79gp3HdMum+aqV+xv+OystJTt/70jjFXBXj+d O/BTobzr/sCUb10WrPA0Zz7hSZe0Vq06z7LXhszQLfjqCj9v+YYDOfr4uMWL/COW+lfNfZTt +tbd449Q/R5FK4rhDb70Wn5WfsPvcWLm7KrWxMrqwJvCrP+/Im6UDMMD+xz7/nMYz07Kf+1J /y2Iz+LD+0V8vHAPWuAicFVaKcJhJSi8vO4XJT0PZWEOXdKbdTeat8yvTqo+1+w1xXSOV6qv 5kiOtj2t/CTxtDJm0dWTnHfqtjQUTbz+sNugSNvNt+I/NkRtDuOe/8k2bLPb+Cy2NK20TZPW vksU38Fvn797ytOdZe2dNc2l/sp4T/OJpU2Yds2+b8SrYu6Ubshcd9qfuPTR5qLaL84kxRsn hc3o2cHAmL9S0Jasx8veX2v6/ESJPVQf4JsAx28N8D5AMR4qbw17c3JjRZ7UNfTex99f2FFz Zd7633WSB8dy65rOzjvrvbCVeYkbqOVcTl2b9NmxCYknR2rv+h3d93ZsWGBE24qLfxqT9EOH JangUgu+xqOsrbQjdmb9w8UhklDvRweFN75rupohsyeGiWbiTu46tDzqmQyMwfAszqmxzmpq 34m9Ya1raSbyXkTMQAWt+5Wovz5DkbikL+EhzytCbrNYCIfBpDNDtS2HKtQ5CJierzebSCPh IKFc1luSI/Hhkigcf16SNBkRKY2WRk/Endh7/3EQkkQ8oc8orrCwUFyADElkKDbYLOFoAttI E2VzFIfL09X0HjaHXQz1xVBF5IhFdF2LkzUJdC1HSUbjo/r8SBNMuSYKbahMgHKzjiRhJAyD KSaDw0YiCP04tDqzKVtHmWxWWBAh4eNc2p4jYGSoJQLciyZcBbwJOtKIWo+yWSWeuHtfKFxU RLbFZs2W+OI+NIcp9O53L0cYbY5et8/k/NfIUYDhq13kxNwA4rsynBgGmquPv70h++/XvPc9 tZTI0ngPbSF5beLfqNdFRF04afyrtEf5RkdNN/GNWgj3sg59cPeQ3bLo+pHPt4bgyyMyp+/c OC0wd1nLxcIf2Jd+7Ky5v4U/eN3vR822X3xgm5w2w+ahUsz1Pk2ci4XszrjV5iUx7vxAwQ2/ w3BB9Af6WexDAW92q+oa65JrTo9KzYxzltzkSrU7jC3xioZYyZrHHYsfZxwQbVizLzit7c6n XcyhJT95x2x8sCl9Ftui75onqBx5ptPHnfyKM2ZP0L5rRxfmHdibs321xv9bfu70B3OKqxpz eJvGP+px+HVXvLf/zjj365m6gJT2bTHZFwQrpxz80JI8cGucC2rkNU72d7iTfaY3O0MELAYO cD796sFiMRnsery8kqYwVnkZPrPMs6Tmb8fkPcalt0cescbe4jtXG/4LjeRkM5rRVyHuRyNh YdhT1iBciNNffv1fdgOZDJcygLKNVHgsDo7Ac8bgTlbUCzo82tTJCkDsofXBZcOMFGUnY8LD /0VjrHYyd5c7mc0ao4mEBsJBmXJMBh1FQFNvw9DFRpB01ziIHMJBWA2ECOqs2dBEkTCfRGok JCmHyUCZi3lkvn4qYaAgZRNBykjA/iA890v3S7pDZ6DogYhGE0VYCCsFgxCSYB6CSdIKEjGO NinQmcw6vZlG8rK3/gNAHRXDe91BY2nUijALcoP0INohzEHk5RMkRY55Wc/m4CHVZ4ov51QE I6TRkSiNOjQhZQUEYqTY8q2UDqHSmohCEUohjB6OD4/kZahlSM9e7DDlGil6SEqio6NecQeh zGyGKlqDRD9EJJrJRLYYyhUqjUyZypsgU6lkqRqlQg0TlGp5skyZokiAstSEF+ZwsjJFicaw mEdrpypTk2KgZqwCZqgVMC0RvSrVve6UiUq5TKOAiFRrVEq5JvldqM6IH6eQa6AmjTbhaRUq Jfrj9TPzxRrW1JWcc+694ekqCPhCvBIe6iImgIBFhRCCREMCBORRsEQIiCIgoKaKlIdKfVAr tfqVIirLaquuIFKqCOuqxYqfulJcXZHP1bquqxZbXxVqhZ0EeYj1+/bXfnsm9+bcOTNzZubO zJmrHEQvVyn5kDCJNFwulSEfCgiWKcNRbf0WcrU6AvfjJRHhQaow1MW0T0l1nwW8PDhEIX+l sywqJEymVvMDVqETlFJFRIBeygDWFPUOloVJg/Cxz0pVGB8oD1fq2QNxLuFDJKijNEIhCeND IsJCVGqZi2GTSLlCwStV4ab+MoOTFDIDg1SlVMtCI1B5uUThgixKebh8/iuePmVVaFUYHyAJ lsyRqV15tUxmqrdTf17oZQTIkEqhRk9L0zH30/CVpScNjcXklCwsC9pEPi09TR9WSSnaRHVv IkiyMTMWLscEMtXqkN8Q3Cs0qcu1fNYiDcZBWno2v1DLJ6TjUqJBiCaL1yQkLM/szcCk9Myl hpwxXdF73CAFRqpeA7nE1fQPnnke/02a9+FT05PTXZNTkkT5VfpKwrP5+0R5ojyBWfz6ILK+ U0aMCEHEJIExVhWOwwpqY/tW+egk0cJ+SiqaL7K2GVIPRdiskLGz+pDOWQbPpgycxP01hU9N 0Sx05VOzMRde7y7BMEQ2gyrdONZYJMBqh78hfY++U/tUUfF+RFt27CbHU3v5n1KPHlkduLp8 16r6ZYIga0vt+bjJnaE+G5YdfmrlrWvbcsgsz/PjuKAdTeBtqj7h59WzcaTzUpjj8TxI4Zr5 +Exr7suAdPstLSW7bm/ruNsDzaceZtpeK2PS6k4mrHbTBfiUr9v4Yu16r0mud/d6e82u//VJ gVBcwIqwBrug6aLl/4Pz4zeaQXOBca9TKMfB7vx60Zh+L5kw4sEHC4s9xsCTmXjIsSOaMMDI ii3ZET4VMx2MC9ptSjxlrWxQVINowSByc3GISLnbKc8B5oAGMvFaCumQBonAgz/OUg2zJAMu e49Dnr0+tl6F1tK+FscQW9mZy7XZ72dopw1pcNgCAqXv+L8Mja64cX7U86sNMW0rc4o3aL9W nIw7cXO0jtkeWVgY+k1PSNWX3TFLy14+OdtcV/hPqfEm70tlFaMfnX/klZB7b1jJVo8rUePr nn3knXsuo/Fblwxdo/MTdcPnh7eYnfxiX6N1TehzRW50rWDK5PZPrexqjGpqrFZNAKFJ7M9H DrrdurDa+trjU6ZCy0Ue5apf5SX7CxZYnyh6Osvuo4cHpLt/cawvuBPoUmwxahaj3ZU4OiFl m+9st8qOJVk9TJGqxP+TZ4897c/KJlyOVid4f3Xd16Z9bnnl0/ibt0zO2VRrb6bp7h/IWtGm GlP5XdeVTUWhTp12UY8qCzu8m00Pbl7z/aUFeQF7Csgl7PHOD7wZgbiANCLqmD7k8o/+33/N UmtotChtk3ZMfBEYtXbDucAPP3Z8aBU/JGyjRaMHR61Z/4MRwaDtX+HEww0fItPdxG4i9+ni 6TFvBO3tzVc6r+VPKb9avdfW1fbkrqFBlZ+3zN897v7mh7WSzg2RidLaKs81RSJV3P2ulhZd 4bw4XbPy9Isa7VrrMJNvtbL94R/8ePjeyHqHpBj10/xJxUzmo8qsTZd1gqbV+Tdbml7utPSw 2yEISfq5q7rhIlMuW2AbubXx1Mbu44vrZr10HGvXmP8g8r2MFR5+89dM+Wxl4ekuzWMW+z9G QxuAA2OulHPHgnek95+0QBK1xC8+aswyjBExZgBoEQwawSqlCrOKf0E5n5d3yAzBHToO0bv+ cVW/yrkCw40HR84IHJnp4AjQc73v6jbuec5ZQEz3dAAGV7hp8OYIx2tS77TnLeM3uIaMQXSl byWicBX24N0ELyUZAVJiCXHwb4glDvAMLpBmxLfDO7ATtgEDc4kVxOJ6CiyGYvgTHIKvoJUw ZCL4wjxIgAxYAR9CFFK8h+v61aPI7wx/Jr7kDhBQopSjZALRMjnIsQ1akVuH/pFDPCTjHpXI Uw1fI/0UMo9cIQ+oNePC7AAvUEE07rwStsDnSLfTIPsv8Bh+oRZsEJfLlcI4sAcHcEVdFbhP AmqYDWvgAyiE4/A3eEJMsFefSOyJjtwnL6glTaXrGH/WnL2OelEQIq8Y/HCXaLSuFGtlC1yG f8EP8Bw6oYsAGU5GEZ44kdkkgCwjtaSJNJNL9AZjz/gyZcxFdiLrxsax5zg1ysPIADeQgAxC IQwiIAbexQqcDEtQ/x0GC3ZDBeyHA1AFx1C/ZoQLcA3uQwc8gU7cjSECYk5siJDMIBLyLokn GpJMFpEUkklWkh0I+0gLNad21InOpWoaSxPpErqKFtBSWka/oE30Cr1Bv2fEjA+TwOQzz9hA 1IsYbB2DHndHn3qjr3xQS3/0fwREGrRcgJ7LRM/pEHLQf7lQAOugCLZCCcJnCKWofxlCFRyG GqiDJjgDZxH+Ct/B3+EOxs5DeApd8CuWDAv0VxCREwVCMAkh0WjFEpJB8kgBKSafkApST1rJ T6SbCtAWHzqTzqa+1I8m02yaQwtpCd1O99NahOO0nT6gjxjCmDGWjC3DM87MVCaWWYyQw+Qy 3zCtzD2mmwVWwAayOewf2Sq2lr3AtrI/sN3cOC6Ak3PBnIrbyG3ivuQaBMMEtgInwXbBPkG7 4EejUUaORu7GQrS0Au19YxAjVgO5zH5IIu2sFPzoRThNbuG9jtQxLmjxbZDCLLgHPtxGOKiP amjDTOiEI5gVZ5BmDCyEZGYdihJDEPp/M4wFJ+JKbKBQbx0xhbsYbWqEY5ht6zAyDqHPwW/G DG8vTw93N7FomutUl99PmTzJ2cnRQWg/kZ9gN9523Ngxo0fZWFuNtLQYMfx3w8zNTE2MjQQc fqYScJEJA+P5aqf4atZJGBQ0Vf8s1CBCMwgRX80jKvB1mmo+3kDGv07ph5RJQyj9ein9+inJ CH4mzJzqwsuEfPWFACF/lMSERuG8OEAYzVd3GObBhjn7H86rNTaK6wqfea7XmOwCMXUwYWYZ DKnXBofyMITAGHsXbBP8qBd2iQnrB4nBjXClBkEfsK3SUAbUokpuilqpqK/8sFRml6iykahW kfqriWQpMk1StUUqEAeTiiTwo6rw9Dt3d7aOU/WF+Pbc9z2P75w7Xi06C9GJRLDDjFUNtZiu lDZjbvz4kBNLt+C87ILyZqv5cHl9HWXLF6C5AC03bo1kpfh2STTkeGxrVqayhdDKbbNaYm6r 1cIquEpNrG/Q7exKxlqqI5FUfZ0rNQ9Y/S5ZO91QVCyhZnGNqze7AXGNeYTNoXNmti7vnB8P U386WjFoDfb1Jl2lL8V3LIq6u6wWd9dXb1bV141Lv+xJusHmcYl6khPU5mWyrZmWlhTftrg5 eWbu8mrFiVUdMbnrOGdM91JXcu5shH9TKRxaX9fenYxAayt23mQzupPCAhwqVa2DkjzGZhYM PmzFeCR91HSD1k5ryDmaRrCWOS51n4zklrXZE94NaouZTk/Sirg7qq1UX8vy7KPkdJ+80mqb rZ+eqa/LhhcVPJ19JFRsVCyc2zhcmhMtsZxb0Np3tcQaWa2giGsOmNAkablyTSP/HG4kZ6AR y/AvJcGjR+C/tBPeyoHQasKW6TwgEMH68O6nR/qKI3pN+AFxk+lSohzm/bYbjbq1tcyUQDNC C822i/7G+rrjbrs1EjbddriMOpPYlNq6Di6PRDjK58Zt6kfHzXQlC32T+qtzZK+Lplw5zTN5 f6YywTMZf6a0PW2Bzq+j0BJVumWrS/9D4aVLYkNbXWnpv5k+XJhH+sTMrKrVOJ3J1X3OuerV aed8CqGJIxUdJ26ZcSft9I17mX7LDFtOtr3dGYmlfZPGvavnqt34+ZQbTg9J8Kv7hYJD2r9o tXcdSJoxJ+2nxJLmpFItF1tytZIqrWoUK1hT/dbDW0TB7Ozbs+8Gk0L3uZ8Qr+qlj4kiKumU OkyulqCEkqcufYya9GE6KNt0Xp4SqFJmaCfmX8Hag/IY7SrueQnrtyhR2gC5BngceBJoAp4G 4sB+YDvWvwQM4Izv+FASNBAYpl7N9m5rw9QKHNRtWq+N0Sp1hrZpU/ScPkM2zu9WyDuL+U1a Ja0JJOjzep4COl5qrGtgqY1Sl1pJz2sZb1avpFVawvsgEPVmtQyV4/z3cF+9PEN/h84nIGvV MfqBSt592HJSmaJBjNdCzw7IvZC7ZdylJmg9+qvhhxXQvU61yYAM4O5ajD+hRqldHfYeot0h 52kV7DkgZ2iLOGvM+1gb8z7BV+sSJe99JPwRpV+oCekPkM9CH0fYXbD9INvs28T6s07/EtCR 9ZsL6BcpogIIlXSbj2Gh9z9BtAK6PMUxhA5p9HsQ62dgtwSsAk+eYpSR9xB+mgFiHLdAwvu5 8PkYPcmcAM4IwM/KGG3AOQntdYrqo7RWZb9HsX+Y1slsYwJ3jVIP9GmDv5Lw5wneC3324zwJ 7W8jpo/jHA2wyojeYI76vuJ7AzM0BG60cfyg231wMw20YN1zQJzPU+7TOvY76ySNzr4NHrwG 31QBa9VRxHYUdhLVMY+xpxv7D5TZZIt7oGdJAoJ/cyBi5AOx8iFiMEY7gaXA88AwcBu4DBwA Xi2O2xrR5+RR713mLPOG+ckcYX5wDsA/MeFP2MAcZ54V/eyCYymgAahFrqaBQ0ADfNLIOcO8 ZT1LZ4NfzBtfMsc5hwv8lzfinE1sL/PrM3LeXtYNnNjj5ynz7z/Kok7zJec255cvofNe2fZu se7sy3lyhc42jYKzqAVyJXKbcxQ5qUrUwnWBc3OuBH8K0hY5G+C8+Iy0qV1vpQU4t1/UE+TJ fMm1hfN7vvT9W/Izag/nP0twa5PfZ25wvv23UtQt1A4//j43fMm1yY8P5yLnU1HXNsT1HXnM +5O2w5vkmqv/yJsM/MabVN73JnUXiAPveJPSTe8Vv+6qb9Ea7ShyjPmOOzgefB77XdTcbd5t v+ZqL9MzgvccM/BSw1+SbKe2kSiwmfq43gZUqtB/Sz1iP8aVWYopKcQuRMulm/QV5RTtEGN/ o7PKz6gC8WvneaUVOYk1yq+oU6z7kB5TvkvV6i7U6A5arOyhTrUKdWwPbWOpWNSp/AX1cCl4 dgpzazC3DLmyjZoR93bY+FcxzmsheUzUWRfxmYLN4LSInZ/b4FXgfe922Tdg/xuw6TXh5/fY 1jlvVCvv1csL/irbTqRep23CZ7yusKfgr6IfS77iOs++wpmBJXSMfSX2PKCK4JfIDvZgvUtU trJwD9AUvID573nT4o3aAPuCZChJ4Cb8itzS22Djl+GPnyIPGMgH8faUFftc91mifoi34yLv 8z7S99MefpvUH2PuBcQrT4Y+gfZd1JmPIfkevAv6y5CfePf4LnU/9ibFeId46/hdtCnMb6P2 Ne8ebMU98AfrwHWL7z2EWG8gw+f0fOlzXEctEvUI9Zu/O/h7BOd8E3PXuX7jXQryG1WWoTp9 N74riJYFs+D8W/Bvsf4BcWA33owO2HZxnvwhIzAlHdXylAfPf4e9F8XbMyWvVKckDfp8oI3J pwrw23PlfEj5whxLxty5/3X8/4F8HRwkH+Dl9xny76mXAbspMCM1AKYvMZ8rIgPUYt3eMpK+ xQBnw6jt94Fjmk1Xgc3AaWAKvqvBeMJ/O1Fn3gQyqG9rgd3AHsTqjxNky0bu0cpNE15eXpYL lm8ahxhYbozLj+UGTKOpUg7JFTSIL6nFkN2Qi4rykaJcWJRBO/j1QePGyL0R+cZV6Q7dk+78 WqaR8IhM19ANA7JcjsFjhvGicdwYl0w7pBj7jF5jwDirhl4MHQ/xWKUS2hfqDQ2Ezqqn9dMB +c0TlcZm95q0Fl/GYf6V1toLelcYL+xbYZzoXQ9NFds6/oSx+Se5yzl5R64jdyinnH621mik ickJ2ZiQaCI/IYeanpbukgk0ADbQCWSAC0BA9NLAyJzRS0BezBJ+w4CM3dPYPY310/ijaRrz 06SVRi8VR1XcNC1G4QLpzpUVMKEpAhfkgUngRsFD2EpF55hAA2CL0U5Zw5eDhu1/xq8nWmFZ y0nBY1fRuYymvIWaDBk3AS6gIJYqNqo0AmSAC8AlQMdWlU4X1+WBSeCGrOb0IF1DUxKH3MMA H7pS5rtkjMFcwAY6gTRwAXCBPFAuVvGoTDtQCTqAQ4Aik+RdqTA2m02LJO8ffJdrbFPnGcff 91x8jo9vx3cTJ/hyiB1iwvE1xrn52HFIUnPxEgpxYycGl3Ibg+BAWgQtGiUiQ4CjqepQJxHt w9ZqYzWX0dB1bbS16zStK9L6FRVV7j5Ui+gmhDStafYcH1ombdqxf+//vBefy/N/3+ccw02t okngPeBj4FPgAbAKsHhV6jihc8WD96R7uXule1TuNH7/1CeniFPFJldxMuLaJM2X5qvzd+ep u/Or84SYasKP0EtAFVgAKHQVyiXgAUDC4R/B/SSxG20HJgESZpW4M+KKX76BT5T3unYC8Vz5 4zIhlpPl98rk1GTANQ5Mfjfg+mC8ybXpb4VFFklwB/xMdYY4M3N3hlgkLDfm2mG2maX1cxtd M4WI6zAwV+hwxV0FLBYWCoSoEhkCbd4MC9lkZKUh9yKeuTEUBjmhyBFFDitySJGDijynSFmR PYo4FVmjiF3aB/oZcB/4FPgD8CHwe+B3wG8BeewvgV8AC8BrwCvAReA8cA44AUwDFeAYcBQ4 AMjH39k412nllCcVeUGR5xWZVqSiyFFFDiiyX5G9ipQUsSliUcSsiEkRoyIaKQ76AfA+cBO4 DtSAN4FrwI+BHwLfB04BU0NhnVqnrr6Lh2CFVnGmUfZIXUz1ElPdy1T3MNUSU51gqruYdayX dbNr2Wa2iXWwNtbCmlie1bNalmNZVsVSLMEiSKo1M5klsqPpbG2pjLJ73LVHo8Ii5r7zTI0W 0rhmyqLsjnRtUyAL82OkFg9ka+rc+Nh1jC/lobVGnF/EaMcYGCY3nXPWTP1jdyBjxc5ddMq6 79zFfB7ZAv+9Ob7dw9ncC/Bkx8/eZFxnmUAgOwrVqlytylUHvpFDC9ndF0ot6H8c58mG/2/v t6MGDoym4ZRj11mUzvcXFL1JaDi49JLTk0/b+KN9jfvo9jhedL4NyeJ1pAnka1ohXdMBcldH qiMld8FjR+7SQ7PhcZfjxW6P8238+uMuHpqNEEpUwZXpwHWpMFCqzQ1cqM0JGeV6po9/c2XQ L9cbbdOV6QrU0DQ+jipyX6O/MgFf6JtolPIIDApfQP5Z5cmBKvKGauTA/pobkC6Uam4hU2Ng 3/u47hUyOHD8+PQ0CjyJLCxlJP+hhVuDVE3CFOt4B1EYy89qjG9hyILUu3IN0VCS+DcIiV9/ zn+OkkkoQ8GQ0WNs9Rg9FPrKTS59BX8k/4Xc1BJkqEGcIQ5B1jUj7y0KE8+hRfz321p4vdZQ zB0cQ3px2Z5A4ko9kQgFzZ542G5zYUbVgmlfLBrvjPm34O4FTzNJYgqvfIYJjAmCoES7Mao1 mXCLYY2LZ8JwnhdXH+Cr2IAMyCtZ0WVGQz7v5oKcxF3l3uRojjPyRlNCLC6j5HIoiMM2q4VR Cd7GOeKdWJ3c5QxmpBGLocOEDblIvycxklzvaVqrgwcXiiKG+AfdhnLoizvwAv9PqW94mBgY HM5SqNk83j7uQxRJkxRNEfa8L99M0M1au9lKabSkCum7+pMD8VCiJ+JrD5JiWzIu9aQc+K+o H0WgDKF+KEWkglKP4o19K3YgPST0ENSysN+GHdIGJPKiWwyKknhUPCNWxZp4V7wvfilq5aYc NHwp0vKYnEiK4rGpYr1eX6nz33we9vA9RpM9ATF4/E3ItUQCDOTrdVMimUjyPfzysjwI4tSI UdyFG2EyYDtptdjs8IGq4PX7BC+jCmA/4/cySgT7cMwfF7FsWNQfh7Yk9jf2VYyK8fk7G0F+ jU66kzCpwESmudcxRBCBDTsiZscVo8bU4gxzLoJoiw17wGjwmKRgtoDreHCcy7nVB33JYRft A/vdBrpJX3x1cqWYWNukJnWcWtMK4ZenBWnTamwajaHFkXnqR3426rTqMomU1mBYk3FZBW8o FlMJQUe8aUO6BVz1I5K8Qq9DEvqTFNCJXIggzISF6I4kosawWk/zWKfjPZ5oqKvLmVDP0lo6 zKMETixi/Y3QbBgeE7d4La9ywsNA0vtplRZ1dZO97SG7G4bk3+rlecFgx3Z42bvZ3t4LuX9M cnsOoV7c+0lQkIScUBKOCmeEqrAg1IQlgeMFLIjHisvFhytGcKBojIj8csMtu2zTsjGRXHlY L0JLsi7PZb5HRvb1saewgHCx2NowiFFMEvyMEOvDsj/RjVjwynYIDcsijSWgh6XG2OP2MPiT xLK/ekzu399q9TAZk0Pw5Hzs3p9Ily6/XBgIHJZS+x2t7DCZnf5L7Y9m59Zrp985cvvgjrid 1qV1NKcD30jZMoLI3Lr802O30k+dyEihwa2Blt35H3z4ak9s6OC10z8nKGJdP++mKJbhg98D H1pW6+QZ8CGGLkhckw1rNEZIRRC3vW+5ozgaNbp8v8ZW1IHU2ChZjB0vuYy0S2cPIUKjpYSP VFgFIf6VxfJRCIfkN2uN5Kw6iQXnkpMAbwYlzRHhqkDwEHAC4ju1MlVcmYL4ThnlBSDP/2X4 1JXsEBEjoHIccWPWxqJyGP0QQSVgKqYheiwHORaVG+VlEQnLAYahePta8+3etkL3yWeTweLO 1O6zl/acts6+Mfn1nZsTPV0dPine3LTRGqtkZgajRMlne3k01idNvOI9cKC1+Wx52+Wn/3xy 3/0rybZO36a2zes489DPjszMybk5tPoFOQ85aDMq4/PSWJpWMaya02h1en2qWBh/Jj+2a+fT O0Y1/7k/MjHxhj9k8ftD69tDsc6RsXE2UpoopwWfn8y46TVeEjfreR1vNevMpDWNyrPN8tvL 7tkSiKR2Z2aRe5achZRtlLZhbI3QVt2mWGdXojdJpiSaVacpjgltHyH1uW1bh21bBtdY17eP jU/Qdp+31U+uEziuh+nsxF3xeKqrC/f09Um5YelQasuhf1NdrsFNXFcc37Or3ZVWst6rlx96 WrItybusZMnCa1nGxjLrYBebh40RJjgzhSEQTCcJGUohaYCQx5B+aTslGaaPSQmZFAJJMOkU mI7bTjp58KGTIWUyfKhLOmk8Ia1Dm2kteu7KZKhW0t3HvZrRuf/zO/+zZhZuvSn29gKPJxet 3l1iELmAu/VWfFdsV1QkOxq0XrPS1ll49eLV6LXo7SgTlSpLFWTZ4kIFkfYVJol9kcBNJQdu G74d33y8et4g4QjrCt9c1xhItp1QTl++tLgwr2dRD8HgfbPIcIxtTxoO2ucAcxCvrHZ1bm5O xRerqigTEWtIghO9vBc5ySeiEQkifD6RzXP3OJnI45HLu4iEyJFRsLzhfIQqGXjFm1Gaic46 yESykCPE5Uhq5jLejJf5QS7YmGZopCENGztEs4O3YQ7JU6s27AgLtiDeZmip7q9rJ50NYtDU ZXNl8TFDIyrJi4lmffbqqxyD04A2uq2mhLy5zl4/5G8yy9uOwvxphvGxaillketzCF7Dbw+y VlwGdN1qT6txwgXb9j3emA4k7Axj0QKtrdPJzmy5fwTzWPELeeNw3+sjQrPF5zXL5Rfd9al9 OVyKWd2Let3NRqjN1PVSaqxcfk10uEXRwVCwyeYYY8YF0dfbV2ZUyXxU2GSwCXBT+EK4KzDC LDSUbOOGcbCpcFP9Qr2rMuosHHp7xAc+H0izIJYaOg61ANtSx1BhR6FXdI2Wy6nBweHU6OjY mAvZ+/btYRgeThUIDWxUGMJ3pNTh1IupcylDimgIUYq5XpBqWqlJhlTEWjlcWtQfV2ZQDvjd Q9hAlHRPO0QSqAjcfTQr+nYlgV8uiqINirAMhRpN+ftY8X+o0HdZf+TK6uLQ3Q4hM9KYvtXM N7a5LJb9fH3JHlofN3vQXiSnMkMnci3xesYS3pvuP/WdY5O5nvbymqQnkizsXn1iOhN3ZZMW s03gLQZ9v7FcOk7cygfZMMC7ITeNZRJz3vLUVlFc2dHSJ/vG2bWHXmpqb+5NdCWLk3mLa/UL 3Tt/ZOGiDayRt0C3GDrWmGxwu+q4Zq/AMjYk0fTdBQbYLNWCvuixksnWEmyhz8YgNguxUtFi oDdbbgO0uk97P21sPSE1gmSmDhh+YzKlFMfNkC0VTNGp/YoSOBu6EqJDoZwtEAycCpwNXAmw AalCKEwys6KXPmlxoQbopXk9XQv2hYoO5ygJeCKOjiPXhUalxuman8M4U3rg9RTSoV27D2sC MucCr5mBeOfuHxY6nxiKv7SiUBzd8jF4h48+in/eppTWre9W12+EYwDce9vtgiOQTq8b218o dBSHql++++2Taz1mTmh6c7TYNTqmdo1hPLZUB/h+dhe1ihqjLpcca1wgRtoa6ZFvrWIoGRhm Fv5TysqUW5YpeRXD9A2hpYSevhDRMz/0Ri7HVyRsY4SkVeyrSD3Q0yNaK1Gxgh3Zx6WGBt9l vx+tCjCybHYOTsvoQApO8+WE82ZiFv50QQ5CENWKNUxXLQmaN4PWYYGS7r/ZU1lQa1dkRka6 xzaCNnK+QqYqGNc8w6HTyyg5Z4edCkcMtIhDiMpnaDI47M5YWDE4RTdtqHlnXf76qVNnm8eb iFiB1n8jjz+STcQNJxcvBuXQwI0T1Zerf7lT3fM5XIIN4IfLle791Y7qteqhquVruAL2T2Do lQvVr34yvcM3lu4ptmYHHjx8fqfS2bmm7jFR3flgXGxYsfFIwMW8LCw9vyPXJJ2CxC/BDdOf Vgf/W32lWob2r6t/rv4BvoSDwMGVf7xRvXr+w+qZn28fKmx8NlsOe2Ye/hm0/K6rYWDThuRs 9frWpCytg+4jfbF6ir57i+LZnWw7GnMNmktzrJm1+I1+2xHzUQtnLkBW4fplRZPKmpY2Ck9q RnPI7HbvTmvudFozctxeRXMrisaZ+8saKwy400rJIIVWxv0M8zCFXDMOFKlY40RsImSU5YEp 4uLPSVclAyWBJFFGpmQU0s+nabe/MZ5MS2VjvVl7Tvux9nfNIGhtmqZNars01mjWmNhGBThZ ya4slvqNEIvVq88C2OpHid0JUYepc9RV0qGWUJrSDHKsIBE/iW6ngp+ZCm52pVb+ZggDe+bn 9fqI/n/Jq9yrfkQaVtQGjj6ikSRlV3nWrqq8qqJeluWS0J1/vh48XeB1NUGNet4m3UjyEUxJ G42dgO6jJLoZpSK675ERExiVA55Mvh0SAdolrw37/rgQbkqbftW1NeKOOpvdgnOdxIJ2vjwS PbOCeUQxCmzLSPUpcZXL6u01FYEuftaq9cHcZ23+pm1NfD9nsvnaaQe9B5zVh77/r2Fpa2Zt G28TnGE7b7PSJjoa8tXxQl2ddfscyL/ucAXMLiNtilnNFgdvoRUGJhaKpN+r3P0n28YqVDu1 v9TnF45zJxOvJQyC8I7tIxNDpYxef9AdeY4F9oOU/4OIcSrlnoqkmOsRiJgo1hs0GAx+y3G7 f6//qp855wf/LMxd+LAVWi/B59ii3ZmZRwuKW0JsfaVmP/GY0buy5dhWgIQpSiw7zzmWg5Yh Lp2knI0mRSWeaKdJlioew/t1LU6Y3Pbe905OPemJ5dv6xx/a8/7WZtVgYtwma/cnPz1wY3jf Uz1wHFZ89wZLNb1QGnzm8Sd+Ub1xZvBRrTOcPv4MD/FW+yNNkiS1K4Onf38A2uBpP/GdCmbF PNuGrF9LvVMq+YPjTRPhCe0tP9vsH/DTrS2pRMcDdnoy4530TNipzKqpxETqgSn76/VMZuLf KUgZuwe7OjpVplgwYquGdq8kWjKUx8N5vVxhPN81XhSEfHGLiTyx57dYLNzgcSkCQYzmR9wl +Bs1bL+ztG+GsGthcYH0PWjaEHB4phZ0375cmDGY8z3IvEWcil/LvRPpiqiZSs185XOuRJ7J Z2vFmjg2vBXW6zKBGgpSAl5vazkeW1sgzs4joktzk+jni3RHlsal/2O66mObOO/wvffx3p3v w2ff+c7fduzYzhf5Mo4XEnCAkBgQixMSesYOSWAhEFZCKW5QBwslQFvWUW9lTKid8JShadFa 6EBoWisVaXSr0LYyCU3aP2N/eKD9wR+ToqqaRLr3PQc03fmV7u59faf3eX7P73mS9rbxgJNB GoOyqsyGvZGWKJRAz9E7wPaPmQ/2Ly7evH7ij3/uHXaPzsHJ8PqwQoJ/1QwYmdxx9kDb/ld7 3/jnjw6aNKf4HO0iiB09D8YavDILSQhIU3UGPYldM6v/qdxfffTSJh6ZORKwqJnr9E9C0vLl bNfEtf1vdwyo8e8/+d59QLyBONv7zTf0DcZHzANvX7tTl2JJqjWxo7u/d2TPPqo46iioBw4V yALROqHbR0Oj5Oi1YjZP9Cv9ZP815K+e9LVumigW9eNEQkkcS1CJp+G8mtfJuTyRP87tiEV3 7hrZQ+X6k937Dr/MHJnswnC1p3kbzQgSLeKW5nSWxMa5iGmPhqIL0RtROhrdmUofKU2y3GTR ZuMQtmjRLa5/bidebCNySm4i92WOzn0CPiY4hPRJhPT4CkbQiTo9cvXYlyfbxqvoFupZSSxi zu41P/bCyVermSqKBLivPauuoIBQHcf19KwTM6A2qWbgOtqTSK6QHm0E2JVTloFIYWQzwEgn 06i89BDQWMuVJVDtWRTBHEDwh0BSr8ldJ250BnpiyVhtcnzN/qk6nolP9AgRybobjfSS+sGk aqMBTYr2ES3uPnfy36UFtUNruiUmHJC0w3qHJkJHU8+bF82k4JIoiuXh4MmG3d2S28UwuswI dRCgAABUgQvxguFrX411sAxwCH3auoiPptTQJfcX6c4hdnOW0SSxoQk+mXp3GQzJMi3CAUZE XAWQBsHgp0GF4WFiOkYDnuSM+vm3DrnxQxvLKx0TyPlXkjHddpF30VCtH5LcbFN69eFuZEVJ yga9st0AgAWQxzrZR/DwZ0yQ+D34cV+98jloDbXsv371/YudhZbZwp7C3nLhnY8w5xYLFz5Y chfq3v8EPCGWiJ2IbVp2wr60sPRoiXq0BJaWPmtBotKAaSgczO/NT5AX8u/kL+LrHxD53+Y/ 44jPwey5lxdPHzt1cm7+9dyJnw7tujI8svcydbVsXmrtTH740W/usO2/Tmeub+vduGFZgoIo k4zq9oUgF2i/nVruzRw6dO6EOb+4eK50+op59dSphUulq6dPL9hNYJaGzbni0NXiUHHeXCDM wC/NZc4UTHmrmTHT5obbpeUNxeWibNGWDy2A7oW/BUqWON1Tvqo+3Te+bwUJD2IeDpQ4U6KU it3XSnUc8RfT2FItrF342gqsNU5a5Kwl1G6H8X/jiyfWMI5pvoKZjkfE9OOvPMNvwUWC3vN0 bahxHUseGE/jzpsBKFeiWJFOYCuGOI0pH8dxBJM4rRudllHD0cSloTziCgE7cCHJs6jtqvHe wJTPAGshOrDRqxWNZfkM7LPRIlQRAaAHUKyFhsvQWKsSrOpANRBJdGXIrrT1PfFErA1EcGqK WO9yaCHyuSnA8yPoRVbp9cHTRliiAc6yPGA51ZZosftkCmr19fLrPb60q+6MyxPzAPqmTgEc dtCP8quXs7dvROIkICFLCdHDqoOEOjM1PqlLZ52O+nigEdDF7gC0VpCoJEmXc1871cC2bxq5 M3JW1gC9a1hUBVQvsebVdp5lea/Tr7ppVADvCVDiKbreo6s898POva4mdpMt2Kgzwn/f3Opu vB4Yfal5w7dZB/pklqIpJsCJLhpIgLIxtItXDL9NjSktEU7gFpw841Mc9m8xAKUpNnJ+3fIA CzUPDaM6ACJqLICjEmHVYdccXskleNYxC5MLLW9deq2uDdKaawDVoARbVadEweFPx1I70L+g DQDsTsnHrd73+qCBdg4anGTgykfBD3C4ZkcImvwrEyC2ER/2HSAGQcSrM85YB62lQHKLltcL RrLQHcwbeS9J5Dfmt3Btg7lBMhIMxxpbOlLdMN3cmlgnt0minVcYzuakWT3RnC61FVlWMUy9 JCqm3RTDpeYiUbohAhEXyYDy1XgV8XUFn5ZMP6d/jftrLby7RvPM46qV+CwyGzVHhOicsvo3 pjIe1sjYBhiLwGlMHpz5EGWRCtc69nOjWdNoi3MjWuvmsBPgbkqh7YKNRV2iQDAl9ZxFuY1s mKmDFIV1lt7Yya9HyLFhhlXl+Y9T01tgFgqKI5R+rdr1B3i+63izTVfRtpoiyTFAlRw+2SN5 O5p9vyqsfn3hizhnlxjABjXBACRFiqQNot1PEDRjZ+qIWeLrvuirY4tj740tjd0aYwYGiCwz kN1N5waJ7TPmNChMtWiF4CBWwJ7tE1O5vxTjeWS8yOl8MT/FHTPPmGWzYt40me1mkRrNdjQN JDNT/YIs8gzn9tMsMT1DeQ9v3SyBx0Q/waORJfrRmCFYNMpEBjy+3eUtyWnckruaSsnfodtd SN/4nqKcmxs9XJIxckeQvLUhMFZWaqr24rAAw93YYaFnoWis4Vet4afgDux8ga4TBVcLyE0g WQMylU5kQAprUu2oiZKRNl4oErK6wPK7WFAsObJkidJCwJqF2zGaiW9iPUEyE6/H0oHxTq1v Db1iS0iWpaIBKyWZOo8WlZGW2NxX3p3d9t0wY4ecAOOnGJFGwoEOEoFP2yZ6Mj8vbnNFmn1h d9DJsgaMreePaqvLv/jTazN2KJF53gFEt3Lm7O79hx5Ny4ddCinZaF70yhyqCUDyFCcEDJFl AkiCGH/GKTCdkqTEe9et3+ppWI0HeRqQMb8/ODBM+7O3swoNOCBCigMC14RY0kgQbILxEOfI vX1fnomCCjqNirviqXgrvoq/EqgEK6FKuFInVCJL0bvGXfddz13vPd89P+edfWA8cD/wPPA+ 9D30s7Ymutk2C496vsMwAe9sU6BslN1lz9+9bNlb9pX95UA5WA6Vw+U67sHB/zFdLrBN3Hcc v/89fHd+nO/O58fZ8duJbRIcE5OEhARfDIlDDCEk5HGJQ0oCrKYxEKgJaZrGIwUaqaittk4q QmNbqaYyulaiaDC0lmWBDapu6cQqjVXrNAFSV6K9UqRJw+x/Z4N255f+9//7pPv/vr/v53v7 W7efXcp8tm/puaXxP2epm7lbR25M3jx6e/ftPZqFskXnonvRs+i9NaGZ378gLFgWrAu2X8L7 LjgoySrZJLHVfsJz3KfJW/O2vJi35x35srwz78q78568N+/L+w101nD58Slp1J8d9/iZ7BTg fF6P2+Usc9hFm9Xqb8pJ4/3ZWam9PZseE9LpMXEqm33gh9vmF6emp7LTBwlaIAj646kvp1D/ 1JhYRUTnUnK/PCuDIWSb3Cd3j8tZOS93K8KpQuQ5qklmhkx1chQ1yVb0ph9kx/1V+NhU9Yn4 CTSVazf2u/vR/lxaugr6kHZkDNy/1J5+Pw3Sl8FXkplAZtnZL2ax2dw0yBFMjr4zBaZ+AZUy rUpqGvxNYiWii7hGLBH4lwR4HWZCaM3DyyqEqkIZZleGl+8Xf0EaKIkkDtWhNDpFV7DdKfpS L51kIpXUDLt4kojYKk8yM4twwFbJwBGQ+qCia0DSVY2Nj1/wV8EnUvV0kgx4qDIbe/ekMlM5 mtQDKSagynVIBCpvQj2G1QMZnlDtu94B6mrXquprBnUxQiFXxbchx7pQazExQY3VxYpiU1VJ qmpzwjkK7ZpdoNhli5FKnaayBsRrTFMkaPJpt4ZjQR0Q4B3MSrYNYzM+i95gRL0Hy1i0vAaU a/kIx5U3684QOqPHzzKGUEVigu/BaYfWvHZzZpbSMrB771wf5jADpkWB6TwAjjsjb8zzHBre FLVDE+Qw/D80b6W2uih2a52t0WeicT1A3xyiyIad0cbj+63kJtZv2wN2g31e8lSVWYOLnBvT QhgQvJtPOQrv6a2Blk6XzZne+gqwrb4EJQ0dQYcylIvmmTLBZSz8dlVhfse3WdrGxFjKbLbq UdDK6qiKfq+YuQp2pZyPFoWKNfyVUTEE3mp6IVnF0yKk75ZfFYKFT7e0WPWbgVFxY/LxPc3L hBXJgVeknINlJyvZXumIRAjGt6SfOD5chZNGIkFs1GwiWjVtmjquIdnG9XF4ctPmpJzE3Bzb xiYfcv9NEnccy5VfJ7EMd/rwOQ4TWCvXxGEMh7QhSYxLgrjEcB2pToljmAdJSUgmpV55dGhn XJYug20/69sJlSNTFT+HeO6GwqlAhkC5DKUpMz4UyIxMosjka5NnJ7GKXNSdE3tznaO5jAit 4xLt5kADdxkKoTzOxj3x1nhf/J345fgf4qQUPxG/FL8Xx+OfZ5DcAZrtBA2dykz9gYGvMuDz DLBkQEZxmSPsQyiau48gR8Myf7Zr4AoEk/t3HReTyUynkutkqJ9HE8NPLkbVi9EoFy9eVBY+ dSYor5W7cXalRlnzzT3FjVYUtRUXy1A0lSdnFoFqTA1IkZYRVRQTE+DQ8LApGCvaT6xG+XIB UBuMoEGFW5UzjkH6LdW1akgKZphU7oUfZDUGq9wERQJHFWUoYoK2xICiJan/DHMmjKCmJ7an w3udTVZ9o4Gmx0mdcHoBHcNhaWv0wGBOQYHar39hEYDVJmljOA2RlYS1CDAMPzz57/MzL+x+ m4Ycg1Gohg7O0Rwe9Jw/u4/Qm1FQxmu8O9woJB3AaDh/pR2/0aaiDXj11qMfic/vnXxn45zQ wlh0NLMe02hAi15j1Dg1elET4BNv7HD4Cj8sN06vrQtTtfj0P8/njw59p/CqL5Cc637GbhYY EiW2AyNK4VZOJxKoWH/WXw9aP3l+tZUL8DoEQZHBxyvEN0Q14kAakR1Sw6B5j+u08N3QeeFc 6MPQLfw39A2DdhAdFO80YmUjJFY9YqSjTQea0Ng8qwfXFHj0zf8OquQKeICsZx9OLMMaWIb7 uxxfVkgCGTatrd+AxWpwuA0s4vWpz7PIE8CnxBJziQLVzYjVKJ1J6UERMBj1v/TRjReWQM3A ocJs4d3ejnWrttDZlyOix4y+23/C1xAlUejolbxrvetQw/iVgzoCI8s/Q7//4szg93KxM8ff +6hwrzCuoxgR33CsO3J0K/rm9jU910/1leudHb5ZV6zGXrnnXwtd8ybKe+6CovUoguAXCRfS g3wq9fcMAUugAvMJIlfbuHHNUL1vhHpd/IH4gXhNXBL/Iv5DJBERiNc5rpGSgYyh9fIGuZGK 93b1osKaWiwWWB3FLFWhYHJDohVLSQAgFkuV8ypqgnC3DQrTyOQZFCbWry8iuVSVklwNwXQq lZRiuUhayiUV3e2AdKdytkLkd5eHIbdxDdUwoZaArQR5T6gczls+NKGwXQ1fSqos3AhT0Fpf CpEu1CxA2FZYTnne9UVvUY0BMrkqEohupaBXHIeiUJ1I8YxaHSju3xrw9+eCzcc6TC9Jo4d7 /vTjxkyEsAWNvY1bN0akrpSHwpWqhgHv1zghGtwX9r940BTG0eZ4BIoB05E46Qv14L/fYgQk wQgDb7f99I9lZc4YilY3z4/OWFwWg74QDq1iHN1zZ7zrRBtjdOBGFkOdDG0STA6nTWtwrwMi aP4r7/SSjFLL2xGMeJ/wIM/AXt0ufWLxA3a7J4DqwnwL24UlAonyREUimAgRfIAv5yv4IB8y hYVVQiVVXhEM4YFw+EFzQmhuTgTGQuFE+xairT/ShbJDluyIHR1Ks0P2sRGabQMNbW32/hhM XusoCyR+O5qWu+V+6lgARGrWYtFAKNyMexN7u7sOpCYOH2o/uGtLB20wajFKwEh+GDGNkCTP m0zakV0dBycGDqcNhg7t3nmj9zXvWe/HXtzt3eZFvd6otivXkdZGCyM5bakDr5QyVzXUWLEk mpSU1lCtnGoWUzMaX0xtxXeDWgT/B/7wpSyB/XiZLZ1cLFZcqXReBWSsSgyA/R7qV+H3UqhT KuB/bFdtbBPnHb/nXny+F/t8Pr+eE9vx2bFjh9jYSRzHvvMZJUCAkMRpQrxwJARI0pA3Stem JWWUlSYpqNAV7UM7qUxaP6xVRSXWNmwggap9W1s27UXqB7axiL20fNmiaVKFs+fOUA1puvPz 3D3P+Xy+5/f/vcDaTNbMhisDQZFJQ6SYSINga1wKgSORUalRiurQeUygOo6cbuM6B9kowT0E Y0MCQGgBncUfGRx91A3NPPmUONkEgxvAURgC8wM+FE/H3Tt3m9pe+u7Zz/75/VXWERevFCKd 2zwm4HO0NgWTR5m8zxaK883H0w5/jyOF4UTdtv0duEA0/SEmMq8VWxMo+GXK9d7rkhgpNB9u aYDghFuX1cI5KGv5j0ta+9zYnU6WIAqMGdK1if31yrF34866Qrz6cEpy8jxvoWB+hYkRQ3fs jRz+7YTFidbH7t7gKZtruxegAqBIL8mgb6MvThYXfFEHRwgr5bmWHsgsk1v/wu4QGSiamPo2 7SGUgMultCm/D5o4B+fkXJwbj9i7VdQlCF8rskNRZCDb5KCMOZVueUg+Jh9XiGflt5T3lI/l 6wpBy6L8O/nvCh6Rs3K3vEfB6xQgKy5MaI9GLSEOCSBJGCTxPmQB+R5yEcERpMuS+jxEfm4Z 68Lax0LUrR6gCLILF0uphSS1gOOdVxARiOvgI1UsNY0kk7Yrl0oflr4oYUjJVlqEh7dKREmn +d22f2snHuSSut4/XM4lPTqCagCDrG+c5JKaprf68DOGn9Vds+58oZDDc2AAhQOG6ZRChkrr WuwHRk60olKo5kd1ypFBVre6NW2A6bEFdob6Y720mcXp3Wxz876piZO5jo/lD7YVtklC3H96 ZWbn4aW0hcAJ9GDKGtg7Lbef7euOVy+9Xt64mzqUw/8T6p7K2Z0Ygb6S7J/ap+bz7fb+pHJy +NBoKuEfCMMYyuAcw5wu+RrRBXemGGl5urCnGD07+X7fO3d5GgFbVcg3O4h+ZByY1fCzI1/5 0WQlqc1jmNMuWBmEoFmtMewbre+Qd6VHO8NDozDx/KweqQik7uJo8NdrQ2Ns/TpIq/F+AQgC i3ZWShXZbJv40wRqtTt9uLMx0dLaQbQ39+wvIYDAujS7Hm3qwQHEiXwHHFCtWqm0v6t9I9Y8 Eu/agNbt/ie9sVjvghM418GDj+IH+3tBLzxSOeR2UEtpVzWsU1M1VIMLtLmpPdzQ4Crp5gtu +oLpynH//0lLJqnBld2oGbjCt/KSe9QaFg1AZ5YxpDyTLqLuBp03ikDPI24jkNRkv0YFvEB+ K/z/ozUSZJc2I9Nk23ms1VAaQ4PgTBSOHVdIrI6zLPcWHC/cA215C4eTzbQDAIA3BUTZzNo8 N+riJmigWFvCvMPvJjCXderSTf8Pcjy8yCVPx2iUJEwoTQXePxRMDHvZFksgayN6GSLF4QAD KEVFKRsA3ecrGVGwYNHLZgtO4FHvq9Uvq5+e7ZZIE+BIKmymeMCxOGd2m+utXocQWAIm8OKP GigK4HbvQtDDlT7NITpKtu6R2wkeeQMdVadgqT8D1vDzPrdYL0wHkaaVFwvPnX6twL6au7h4 8cTVxasniIg77kvUNdfH/TMF0x7vztExaSw8PDqzasJEpLMnf86Dq4WKOFjAxLyYL4iip5Qf yY9kNfGceK5u2ePJr61vvXnNs7YaXN96RZ3Ulk8F65aXn9eyDk3LXlhbe94jODweYenUqcPa OBwb9ygeQVkcXnUMD6+Cmbl5PNyPsBYp1T1QHhyeZGKCR6zL5gtKaUQbnziydO4Cf2ptlVpd o9aW06P0XOV4ZbYfYlu19lT20hWsQoYr8Ups9gZEeQx+SDh1bC+6TM3NL2GL5fGj4+hvxsH4 kckZfGK6f+CANqOd136h4YgGBoe1U3i5oHT3jCyb1PyuZg9gPHs9KHyAeHOqLXtudY1pCVeE GQGlWQsvXDAhiATC4RZpYGC63LIOWtUAJ81Kn0mYJIFdt1UVqAeTZaCW75TRchlM355YB8+p FnVxfPHM4juLeN8iWFwHX8L6AC7QCC4BXAVnoCxAiYVOFqptzjjS+5rmPv7AwtAL5ITG52p1 ckKrlQwcceeQIiwaWCrGvmm00LcVc0VbwbhYv1AXWzOkRNh7dNVdeaJLJPTgA2rxB+Se6PVR 40SPRcDgVyHanqkVHuTWx8EHbtC3YYblRqNZPTDB6Yy7RrKPrXfWyDqG/sL08yhVuTkAtc6E BWBScvuAbgD0WtSdoDtbK9nahmKk/lXjR0woB+9TuxVGsOTgYIgOp86SqFmwx2gTzfcBLDP7 ZpOfJk2OeB8e7BhwX/iAgBXDR0Snk+LSvp0pDmNpbwHFGt4a9TqDdhRDZ+NCegVX53jy9Id1 KBZK2DDS9sMjTowkuCaOcRy4/skxmq0nFnw8pPMvUpPhp6s3My6zy4z/SoH/AWAmnGxhKZfV 4mDrt998+JOxP0P4qU6BjnqFAgbZAIRYE03gqJ31J4TomfwbR5PwGS0Ewwk04yIwYN5GBOqC I9W/UZerW412sAfcfsps5hmGbjCbLajJhNmtdoYkHHY2+4/q/mojCHtLPEDUAEER1RfmwfwG unnSZaYwPWd8U02j1wkr0oq8rO73z0pQAmdRNBTyBwWRtztdMWZ7Y6Ip2hTZLjHDqVQEwYeC f3Emhl1D/JBzSByyDUeGpKEgzCsqAvUHOYPcQkgEnqAIhOvm5kMIvo0HEHg6Uh9Avi4U+Bph P6ZtJFl8oM/BbNDekHEaS1kPXAHgIKEBI51PsHOksQ26v2ibYCSALGy+6QATYcJ0zWHBAE7C NwyJEwD/8TYHjlX3wUM4YDQEgxUZ0GRjmqmer37seffensujL/npsMVrEWgiZLXY0BB59Kfz Mxn0/kRMjBODRE6EbyhebQNfQ9bMIz9X0/8lutpi28jK8JyZ8YzHE9vj+8Tx/dKxM3bsOPH4 koudJm7cOGlCunYuxGmL29XSuk3T3e5SlJQIIXYpD71oEQIV2hXaAkKr9mFXKrsComV5oDwQ IcoLqlaCUMRDaAUVUgVJ+M/Y3dX4HJ3xeB78f///XTq0frKpk5oBvz+gIwMddrfodHS6/JQp nyZ6+xOKHKe1PVSMsZrsXodJifeCEL6fZ6ohA2DwmLDAMhFx2POwYgT+zkl4sZISCYhd5pjT XYsFqrG/3g0hIvRpiAxBGWFmdweFluK1RrilferV8ssvJLCtl7iqLRHdaQnii6FS+nxQSIpl HLiwFK4wo1ZWA09bcof9NZQWzLXUj4024nq+HLFSKBNFXXmKBCsMXhiRsKDie4cQ77ni7oAa w3yoO6LftpgZRrToLYgKaPb+eFi47/qLa3LvRnJsboYZNOrNNuRyGHVMl1VrufnxsZGfrAf9 yRO/kycigh4a5+T+f6lNahZc4xHi30U5zKW5Evd6/wc6zVfTvz5AFgkHchC0zjFcYIzRY9GV 6N0oHY26B7/OYurXCWVfOVkulunyfZIrOvXueorV88RwgaKVjC43VXR0RkvCVGcO59xYZ035 Qwl5S75SskSVGoIgz9DwD2d+pfxe2VeohDKjbMCRLihIuY+eFkM+uSjfkqkZ+Z5MHpfPy9fk 2/KmrJmWN+AbyignZFJOXFgFLty9gDk5gddOfRU8ixqRTO04ZFa5GQBafbaLf+WA1aea0rAD ut+AwIhI6p7ux8kHMg5uehhQle4wJwYxosNqCAK/ygKbqrQbxs/UcwYbVeoHDo5E4pH8QDUo 31x95UvukTI/8pzyW1OplywGYBfjtEHxGcTQ9UJtbebVOEU6zLzWs/cgd9Vl7Q9kpbT5YyOr 0yyMjsxOTs2N+8dGI4zr5AHpzV7PAY99KMZavKyzw56L5s/aXQOvfffdS95uL5N4YlmI+5Ny 1if3vREDXLv3n9ABTZxIExPEnWKFdn3P9tBJAV+lm8QjKuTjzUp5QOIlX6S8ZmYH6j6eIiK8 MpahGC4kafhETJYj6fWErspnanwtYRzzjpFjDfF6BCPpIhK+xK0EdTdxL0FeS9xObCaoDXw2 JlCiBciz3Z26ALkApgdH1fa0AAo4LsCpgOHpM/UJz/AdljQLzAM2+DbWwiqfldqhRk0VgYCE QTKifpxLlbRJNYqIFTwItKvlHtP9PYAi0131vRkz6RHSIHdSt9iVDDfWVw6IUsx3cTJ1aeVK SLD2cikNokiW5E+gKdTZHIzNO4KmLpYbvTQe+wr9oa9jnHTz0b23rvmCrMzwqTPHh+ZzV8d6 l12WWbvWPatHYso+4RQi5J/P+XVcaI+/ubf7ciVk94fzyYPS7DvTKWC06f2n1HeoJUImjhZT 3+T+xJGPued+8iHxN4KkibB41Vs3h9dYM8vyhC3Q2LQhwrZhI2/bntpI2x39z0kNERP+s1Ov r0LjQvUwy4CnyNVxxdRE5Wh1L85HwxCXcLnw/YuIhTsTV5OaF7QOQ9fWrZOf5OPx7Dd+e/m9 tzLJaMlhdrmk5bc/eDUX6ZT5IcRzlM548sZLpfT3lZF3b9SaSnpIKfbYrO98+8e/0XMe7SHo riP7/6AXNVmiRjSJfxVPCefQwzPI0DQ+sjPUUqaRqyyMlxbWZhpNmp3hc82ZwvHC+cJGgb5X 2CxsFahCoUSzdlTiA5mBAj2U9sUjEW9SdFXGDy8tawFtpzPs8vr9kXB3dzIeqaYNl1nXL4G4 0+AqHxOHiST0oHu5drg2dDlNnBZOk6cb6eveKipUp6vHqreqdBUX7ixE1gs70IbbOzvbbUrf Hvycy1VLBxyhbi9kUmWKgppld1TKMOfMLRLJQauq1quOoDmhU4G71RZMD6MCqbRaF9yVTSV6 fFC3lilzI+vnsUdNNgEJcwxubThi9JBdbeO0IKk93LJzdqTt/eLR7NmTIAVOY8VhGZwLNDys hmdAERBWCJxeQCLMh+wmDRuNfyvv4nkDooz20XPjlysrVfRPm9Ff6UZcR3MqNt0ZtjivUJqA R1sRR8/8NN5F80lGlX/SpjOaXZcUd+qVoUjNwIcFrdGVsbn7+rtNhkooxWsQDRHIrNOYvAJp 1oxZtHpA7dAnFx/sPiddXX4tGhqZW/Z5YtkjYz96D7qkvP+EWqMWiF5Ql2vvGwWDffij/adE mAjubxYnOH0u+MhjMhoo++BwispbFm02ez2/mCPA47KetYhSZ9kIHzSk7DkxkUKphsEQzjXE BhHeCN8Ob4XplfCTMBm+k8RYF2FIVus7uyr/t2W5Dd9qYhsrusnRBx/hf3Iqm81iA9SmGLvD QzqkgJo4g1BxD+lFmMwzrcnCHhqoP9xDYkwcKfxKzWnNfq3vYHT5NSk7JpMrPTfzdvZUjXT2 T0XzU87k4f6QOP+Li9Op0eYRSyd5FHXPx0eb7LY94u7gSLHqml0yWtxd0kxziuRoZNClLy4U DRaNzguG+MScwTxxLj/ZM7eafTn3+inwU8AjCkFTYU0v0UBi0Xvagx70IFcmO0DnRpzlCXvJ Oo9qx8fKpkVradH6EaSvMuEEfT5Y3sgxteZS999v9aLetSBaWiAWjuvOn0IDI1+YX9Iszs5M TFeUzFEqzXXoGZPgtLvEdbSu13NMujK9uD7LfAgDx8G46YTZaqVQHfphxYUVwFSpCYJRuiZt SVRR+lQipfvoZ0UvIfrEe+JTkRbgkBQpQtwQN8UtfL8FeU6VBsAJQGq5K3VrD+P2M+C1z6bw hW7XCchUhfWdCyKAWdhpO7LB1mN1QbBSpTwjYUCHsHSDn0onyIAUbKcbgLMAQ6tKN6ZHNdUE AxCGWC/KtAeXZWTEwjsBI55VW8uttUc2GEigAMtkkLDC8DRYLwYmLlhgeGTwzFPjivPgyuTE ifDBiMdtzQmC09tjRsjyBmfRI4rr4CYtOk5nBcMGF2V1L5kMNP1/pss2Nq3rjOPn3Hfu5XJ5 vWAwXAL4YowNGAwYGxuMY5vYxE4cYxsnBIhdJ0tumrhd0y21u3xY5mnrlKjdqq7btGpdtZdW SqVqU7ZpiqVm1TRNaqupmjQpaj9Eq1QpyqR5/VLZ2TlcZ6t4O+IertDz/M/v/3/KBi0zG3XS OU5hBbtcFwxmo2h4a8eGtnjMnRb22Q8L3sG+xIy/e9wuNURjYmX7SS9Sg5GzeRgLDSHVz0o5 x0sXFk/avDxkXOg2LEWRgATJvUfUcZTqZkELPAMeFXtU8fraGyIZZ+aiIK+Frt2S78iE/Ev/ ptstTUnanNbUbmjUDQ1qtwlYrF7L38kTxfy1PJHPT83Vo1Hpq/Wpal1ip6SQrMbnGZBaWQU8 5PkUefnpSoWUpXllnphfldS4ekcliypU1fX3QMlfIkolr5RSUkTqNsEUg0UvvOaF3o8MCglz BXKObJCXyLdRBGUUtCQ+RkNFfOOp+un6aXyc65jDe7k4XqKsEMdRIV7H/oeAnUo9PuFx/MJ7 NjbxBteD3foDnQHtYEFjumayuhawCnDmk52Z9unX9aCG2zFDX+rgxZ1PtY87VoCJaJsqug9M IoFhWCD1YKb7CNtB8ECSCmPLxXkEHtpeSby72pVwD7776mifo19NqYvpLo/d5TMz3sMRV3X6 7NmSK1ioBizBCGdKLwt5i/FhszH+1N+fu/63fOwo/PF4o3qUjybmWNJo6R4/+f35ATkXSi08 97NLoy8uuK4FTiJ1XBrOlicLU+tPcJTV5A9YrEKgkI2aFGJi9Mj1cJakTPFDZtnuR3ZBkbBS eXJ4Y2pwYLg32X8U/vnpr7/2JG24suo5FugIRz17/ZZCpFvuiXA8cawUnOhG3FEBoE7QveA8 +Kw4adPke94TyrHGRD9JaOuZ1azPe2wzwHrBudpqbZ0v1LK1Yb6/JxMpT8yMnWqski2fd5kX Be6czNgymVTk/Hmb+AdEFAb4EETMy7YtZmGR45aZ1FZkvDp2myCKvplIJOpvJVrFFtnaWl5k pBllhphZ/GkUvh+F0dvw83d2GMj8DsWnC+bPN/Zw38179+tIHm2aYAU80L0effVll7d8CSy5 XJsr6Fl40FaK+YETB4G2x+tZcgRBBFm8La2b/AAaCtoXnKROEmzqTlY+YATSDKubCBZROqwP CwV4kEjbfNH10o60LNrK4pBmPuLneGTlBMUzfSeIhQ7nYFUSM8TJl48f3RgVDZCmaGPcI3GQ cEq9C7mu0d7DgoGgnSMeCtKuSqbwbA+JXMTa1S8R1KVC8oUzvDBBcRQvDU7NzNuTFnih8/e9 bp/okGQrSxtVA0Pt/bqczx4fCl8qfu+vBpI20JRk4AQZop8RpEvkTAJL2egX/3PxaP9w962b 5agw4Taif0l18CY7TbPQFEL+7gMModI9wAgGwSvFnrjJrx2618Xyn5ImTSRBoibWMjwYKgxd HiKjandXRHZZ/X4gerACZNCNFCBGwCrDRBLVuFg1WbGxOOT4VmTRtGW4JcPcjgx35E8QqXC3 cyjObSAw3N87iHKWg0bjHj8e93S7wCm5gAYLNOPZBvRT3k7JZBh1ZQQPEAPh/6U33NOU7CD1 gKYzAHXsrcns8KwyHkwcf4HY6LCRuEeMMFQ+O5seHadYSpn0mKFHlJT1N/tPUbcyE0digcOR +S9ujkmsJy4YCy5bJhl/XTkkyfQg0+Ua2Xxv/1xPQBAoZCMEzQJUwd79HvhDOgoEkADfLsb6 QkGjJt4zs4ZPSRA0FZJzyTtJ0q3IHqfZEQkFgdHjUZzRasTnYxQFO7MT19CBa+hY7DNWxecj qIa/3emD6NmHi9aPi3YfnYu9JCrW7m4cFU2v2GP3xGWrY5LigmFgPq4Y0y4YUrETIRCFWrsC WTuuExrGwjg9peMwTSIJvzIzEps5ks1PXIDrc19zCQxH4HBKw/EfjWcMzimFhjRjUKk3B8vF 0cGZqf3FjBhcgdA6njuf8Q5tTPn3bx757g+6EqJvZe2dN6YOw2dE0gQQfRQ0JB2n42AL/qr4 kTKpNJSmt/WP5mfNfzfYaPA7Y6+O/WWMEoLSMD9pnDZVaL651CTEhrVJnG6USuVms9EawZ8t tCiWmsVWQFWvFlv2Il51o3hUbzRbTwgDgKxNkxe0q5IVEc7tAR53f++Ilq0lagOztYXaPLny lcu1q7UrA8wV3g3mebW7N5EbHimWp2frDbFSiy0ulJYuNi9dJjVPp7/lPsPTklWmuKtg027f jMUWFqSl95c+Xnq49GiJlpbg0lLl4pnqWqDa+UfURD96rSE3/WcxxF6sAs2s+bWERmlba69V diofVD6p/KtCgwqsfLG5tbbI4rY+j+LuLnJI825dT1EHxwBHK9TaVBw19/+sszj1NrdXeLwp 6CkKv+3uJdG1ghl9mvecSUzI7Vh0y3wXzrwdOrZc5JuNxpVyyV4ul7bpmCtqQpdqAN94mzPf 5e5uc3nuLsQnDdQ3YL1eb3MPPWzprGUgrLajFvLdNjltGIKsQ+doe0bFWE3iwUe3WQniuUdW KD126UBFcW7g4BcQcVSBOnMdTrRd1XM7G2bRrfzWEDdkYAkGspCxqyOQCP8mGe4m0ISU/Elm vFM0S2oaktOGajT4Dcnsh9TcWODEn1xu9/Trpx2jEAoZxfnBSwSkO3osdkne38tAaBcscVGA BHsq47UYgrlF9zBVMDAEQzn64C9yUais9wmyRWRFVnCICZOF2D9MDztGX77hOxfKyCaWMjhM LO+ANEcING/tsNni3+rocE3//LTU2UlzZgR4iZNYCU0CpMcJ7d4PDa4uE8XQkOyw0gJJUgTk IGkxCehEsIAkHHQMpME3ixWiR4tZNMe9DhCrpWtJvpCdy97JPsxSsZ7ekMflZ0SLg+RtNt4b SFeBvxrgq0yoGmD+S3a5xrR13mH8vO97js/dt+ODwRibmzFxsHEAG8zNLhAMhHtsJ4Y5UCBQ hFtCl0RRg5VUjUpE02y0UViqSuk2KZPWfZimrkt30TJpmrR1Unb5NGnRVCnSpEmo+4AyaVLI /u+xSVoNmdeHg89BnPf5P8/vSQtNhdoMU3ggIJERUBzeBaqqKOQpGGzuucNai6wda/5KbhYd dn8PHOUwKSM2CDyw1AZqnQZjwaY67bCButPm1B3PMdogJNitsvrjgMNErWss1wme+GHQLVKg RWbFr/dyeKJvyRfLD7dYWEF1TSJX/x/+2Tjt17kKRZDEeA1CB/euNjhN2sHx98qP2lWCBV2V 7CwH/w1iAgxv+pi8weyiTxKjAe+I9+PhXwx/Psy5qpv7JtauvHVNvLjKtEYS2ZXrPN4x5y2P 9NFNH4/zNzuyPdmuM9mz2YWb2VvZndMzq/mdi5tVXdKO5OPL9PvYlhiq4nMzC9L8nR/feXCH tDZHAz2JPjIYn5g6nc1xs9WpjbNr58j68lvXrt9gtwuu8ssVon6FOKVbjMSbzfztQCAYjUaC kzTqpNTlNzfS63NxFKfgUzYYKQxm7gbRXBAlgg+DWLQEUTIIwJMIrldvh7cT25Pb89vcduHN tLN6NjybmJ2cnZ/lZgupirSzkHFm+OX03ApaoTersqx71/F6RrQwKHk3heZSKJF6mIJ7plAy Bff82e3CBP8tHht28h3Y+MdPYeuL6P00t//6Y+ueEa45cAngq+LvaP16nUqi6DbFFIHsjX2t spWObc+PDM3E97up8YBuisZjvKDRAXEdXkQ9xFBUr4FegNnFdIZ8hvxxUuyi2F5E+CoE8ipJ y0htagQNkZIiSYhAhlsA0HTeYfA+lV+dv4H2uOYSyUUjRQagfGbSQai85jy0F8prxdYHNtXW LJi76ngCze/orOb6Rnco2A6mMndleuL9Y8lwzTdb35maIorf7bCD2bgVYap3N8sjdVjFHIcc /r76jvNBhDFSHeNega1q1JOja/55O/KMc4KMOYRlc7Z36pIIqQn35dwOn0YEKy9nXx1fr8J4 iEWsjTh+1LmyVt4cdB3hTFpdZdQ66bOfCA9MHndrVan0zt1jl8Ycmo0jsl1xcKJUYTHzblWq mEauZC5SG09UXV1dyvYpmiA7Vd6GwCSxSLpEqAaq6Oj5PPqhL9wz5lFMkiRqB1/cFuxgSYJk 49VyJCIZWXWRZjK0AnaSbDErKJiwHPX9a/S/o4QNOAL41Onw/Wf/TtSR+qlxprklzmY77Hnt kSebPxPNdmU7zmSXsgvjm42eGe99rCZaGvkFqUNqbomStqYTya74MBnpSWdzZDYzdTI17a2v llQPqRWWGG3Zbtc0eXmEDo0rKaTlTPpkOlUcATJb8KbB2toKTRQrg0wPxj9NpjK1GZn+LDDD cJHZkvQmcZIO10MAIyr/VGa5cOh7r1D570GTeAppul/UPRzsG+I/JMxDYnIWg9T+QurGSmP1 CQj6UNiHso7FnB2g642isIu1wvBKKsVSVEZpUTDqgdFJPciA0ZJmwS7rDgPUKJr+9qgBqFTc QGVf0yp88IirrF20cLCrEqu7+5GqD7ZbOVmxeAIRjNDJgezkmZtNsLHBYyL6bWfoWi3C5g6L 3UEA21Blw2jHpQQolcWuDOG9uh5cm9xlYwormkTVMXAquRqPN1osDi3MErtDIKAWvY3dsElC w5Dbl3vjs4OfOy0CL6qaopuxpPJ2nfCYEwRbOBU8/9e2E7FOW7z/o4rvBypsglKBTJiXZAFY +MSzL8kXZIZxgMLOJ07eFm/b7on3bCwvmbwNnnbflo+7YLog/Ud64mXrc5o7J1zXkMZvwR7K +qJiqfHW4JrFBJkn58hV8hH5EzHRtwdwwJIfTChI+QxzzBHg4WJl3GPiG/EN2hSK6LKB4Lk7 eNoTQtDaYGuozxhm4IED49E3GE5BFhLxI71/eefDv+WaxkL9W/N/PpgWWdWtne4ZXiozX1oY O+tQ8T96v5t8e3rz4o2fXOvfWqoNHzk4uqn1h73h3OJLtz7dzaSi0ACePT0QWC+5xUwxryJz 4qUPav++hJ2Vq9MroZkA6ssn1bw5mZ3Kjpgf2WdERkNTdJmkywRdxukyRpdRupzQ7mNzonpl s5KfyQXkucWeeN8gOxCNhFrDq9N5p2NNs+u8ROfIyhREVRXNrbGBQpTnBZ1OyxpjxtaES4ym Y/n0WkZMC+F0LCNYFr2LeHHRt2NMy2vWJ0/h+YGN73+liRmgQMPg8WNjToA/Yy8SAcYDrL6w Xw458v+v/cfNxsgYKGpcSbeERGAq4LH7ZRRChmXHQfGlGSn5Pi12mFKHH/ybzoHzeSh4kHGC zkWd34JgX0vcWGZsZmmWaGjApQ5iF8bCJiuIkTRm0EL/sVQr8MipjunF5QmT3OJsKbNFr+2e nK7r74MmCCbPsaokeptdIrJ3Ond9dXVRz5AVvcYi2eZt7A62LXpYgWcb5/svD+cIOZCCMuvW ZM8ouom+jIYq2jS3owO586byiK28jeXra5LH28Zf+fZ7vZLms5oqZSs/9KmpVvbZJIXlTAor 22Udqwj+uID/qJhCWr1ia/JxolUYP/299YkG/ye/4WGKJg4ImyPvMklmjvl1IvJBDP1uDo0z mZaRaGNFvspf48MmTAZ82apsTSY3MLIZlQd4YqoxW19GVRWVMIjhZioPMSSRqVBlQeF+CbrA CLgTzipKOB0azyj+Qiij0Y85FCZnzeHcorIT757onuu+28120zmbhznbA5VQiVA/fbJnoGSJ HEpMAF97hmPSBgLfzwVAtx/lEHVF8DhoDNQbIfEJ/4Ili+QPvudvN2bVyHKTcSKEjfktCYXQ NdoegT7QRrMeCoYZJr2MrPN8GmGIZfA9QnRLzKdi3Nm7OnRmRhN5M2ttcXS6EcFm2/mtZHDk 7dGu5WTrwtHB+EzX78tU2drRjdwvj3k7/QFP4H382H0DaZmuC+eOL7R5qqubAjXPmF+V2xWr LKj/Y7raY9vG67h//vkRx2ls55c4cZ3ESdPYTV9OkyZpmjZxm/W9rt2xdZewdI+7cdxRqZfq buxOK6tgsOO5iqfE/bGhAwQItKHpoGyITYhJPP7gqDgJjn8QlJs4MU3axh9jt5Wfk7V3cWzL siUnv+/nyTsVHP95CIZIHjoTz7/ypei4w7VfUJZ/cmxmfUUPtrrC6NFH8M8wvPHg5N3PT6KW zvCZymuXbMdtJxzkDbhGTBJ/spRQrIfMLxVbcG71FitjFStxq+dKzFvF8dRjBWOs5SxNz02T vbkiHMqEcKZRKcY9RggTKZvgGUIF777pFwT3hN+e30DG7WYmhlbFDMgsmHpJn9PP6Od1ehmf LujX9T/qNCfomr6sX9KpvKgD/XsTqzcYwNhCMNWwTTswNpyzyf7mUdzaqZ75fNMp7XHfb4ZK 22Obo94tEA0/3HHEUsP4ntihPUN8aY9Vj7GNnCYjzG5oc9suEw3TM1p86V6OJ91Kl5eC06fC omvcLhQJxHW3dWX2Ffq6zKDE+qQgSZFQ9MQPe5nF65MFiT0GczzNhwJfeFQRXS1OWoo793f6 XdAv8GLMz0+OB3hdmTTNmXYZsFoqq04/vqMobpdDQrzHydCiw2HPqLp9h3wMDxF7wR+s2xFk hk8FoFgwPIY3MhgpRIYZ2kcUfD4xLw7SXD4bThfSQ98YptV8ZCiJ+gdnB94ZZF4ePst82Txb 2CzQvkJGyISgsA8Qg6nBtDUTHrPo/CAWHkgR7VESedAB9CyiPol+JP9ehnG0B11Bf5EfyvSf 0dvyv9At+R6ifyb/Gt2UYQIl5CEZOmQfmkLTMhVHZ9Hb6B2Z0mRTfgp9FVHccbQsX5JhfnBI RlRLqqc6lwClxFyCTCRGo1Q1SVjEReIyQa3hf0qMpmpRtqU2yq/vA0ikr2FtIIgewFpq0rCM eeNFg1oz1o2LxlsGdcMAhnFGBOIGeHzlgl10QOnKi1mQxddWl3qQMwmQTxJAI0rEeWIdv4Oe I9aIvxPQfuc8AY/iq8sEJH4BDhOzWFNq9frKYn3x/u36o5VH9dN5sx6o17GISOlaw2Iw+upN KNbqWzbuMDpX6vV6zf40kxqYuRyff9pyDg0OnpSRV5bROXdvl3tV/E1FSvclQa1ONB8HNYTB p33INuxG0gvsL8Zcs4jYRtPMX4ZuNOVl14CewLZxw9CrYTfr5rJSrM3fF42Xqm1p5Xc+cwq1 dneEXi4fWU8xMmyVnIgTkidGx8y29tihzxSrU5d+INc68+4Cz3EiCDPAecSbUETJtd+M9Mh8 yuGxOvKJvcfiwd7WVv/3BdbhIN3BylRHKBVti3lCoc6VmZded9ICpTDSzKs2VvPb75MvwP8R OeLrVivhbe2neEXTO/ooORHtltNquqpUU2v8VXCLoMBpKyQy0dPdvOjVoYdnKE4NwWCSSPdD Mxs8yF3FqsKAd3/u+aeoAnUhiVXlzezqDROYtkQM2BJxH4vD1tbWBxXRTtD+RiTA97a2hhrJ QdrpgAhrQBpTXgC4i6VyqdyTfIvbG3aqXf/G+djOarjxSQZrz6Nw8vmhAQ5A4Kcr7B6GjUqO QL8nSQLe4w+qrRrTEhCo2JnJ2kuUNtnCkO+nji61hvpDBdqD067q82sUNoPHn17OKbwzQHMI uXKlk6cvgxDWZc7B4JXr3L5DzcAscZj4hzU5Mk5Q0XgH3al5g9ncATqcIRmtGl7qdJ8e5zMf ny8cLbxYWCtQhUKpkynxpZRfi8bhSIylGG7+AEkQs1X6ILUwb+uwj+BEjuQWZs1YKTYXg7FV /8BqasSJF7cT792NZmPho9/2Zu+HiozVQjhEB+lYqK7emAWz9qLXmrps95n7dhmxGwnOuzW8 1o0i05zAk3FgWbbJgqmDE11pt9NgIqBsLqrZBozxbCfgpjTbHMjkbKnWjUYtSftTOWzSuI1g 4MvpXLOO4M0ETCNNN5Q984HIN7hj8izolLH7Al4oJ3sGppwhnsWxigx0lRmagtHAt4tVEuKB AMrjOOyCMOP/xJkO4PI//amxp04FfSwJaAg4N7JEGsIkRZLl4+lvPXdisLvHk+Ij6gNDaZ2j 47JA0ZDyOl0yTZIzR0/9eLa/n1UCkIzRrEDSAZN8w+nbl9uTMqbQTyPHzXm1RWIg74ROxou5 sn13+y78JRwgpsGo1ds10j1qln9Y2vBdLV4tXbU2RjhhRBgVyu0ytTmyObpZ3hyjzgubxc3S pkVtbJ+zvqsUhyOCBLlo3wRNSooaSmfKY47icDGypNMVokJ2VfRKgmQSTJE/shd8Uf2bSirD aobay0bjoZ6+NGPG6PJ7EklLIemItCydkc5LzHUJENiYpWJ5bIJju5UXlDeUa8pvlb8q/1VY TmlVPqp8Vrmp/Ed5qLCKMhX7psne85lx86B50lw3N8x/mw9Mx0XM0QdrU2DKrN/GjUi8rTTE E/OwtlLfAUK9RgRwTNtttUM2TXc11FsuFk8qkldRpOFM5lVV8aqqco7u7cJieq43YJ8qQEp3 YVW1JRjmtCa1G/jY0Ul7swmtdzVkFYf8NIZRagdHAoYRtJ+P6QbcBRDnf6t41s9QSOlzcS2M zAVmIsg1vt8HC2mXSDpih/p6+uadHgA+ZrAk1XFoyefEmml0vpayHPR+FwkzgAY0croUCFmO YSXFmQskX19IB77zYKSDIz1iwAUBRQEPz0sBn5vmTt18/DCF2pTyUZB85XMSJbtcArIxcm/7 Hv0rmCGWwTUrrrVr1eCJ9yKU1qbFtLimawatRbToJe91LxVpDy2GFsPVje2vXVFPPBPZ2P6K dSFbrUS88nzvntmEu728RE15ZTUUjvRlCwcWn3P1PnPi2f+zX/WxbZxl/HnvfOfz+eP8fXZs J65j56P+/sh5id3UabK6aW036ZK658YpSWPaaZ4rZRCgEK38BULV6D/rmDToNI2ygZgKmqaM VZqQNgR/gIYQEh9Cm7QIDaQhIZgIfyThuTtnWf9gHULiD5T39Lt77n3f+3re3z3P75EbiXZs xViVj8vTMTkiD3PIHGYaScOwLWPD6ChkC1ThyMycrjZll0ak56VXJJ0sTcYL6Up6vvXb1p/S 2y1Wl34kTal3bixe5BJh4C1Od+tSmzN1Juen4vOJvqnXp6ipmzXT3zrB2ss1qvbWywmS2CA3 S/GF8K0w9Vr45+G3w7QQJhfCJPwW04l0Wh16rfN052cd+tnOnc47Hfpah3SSSvr8+yruMfBj 4MHQoynCPUqp8n9PFO6za3PzqMowNRdo0cmW7TItNifLV6WCU5IKvY3GmpRGK+32+dZal5wt X6B1yRfwuQNXFy86FxcvKgzkFApyyEFmn4sfpWQUlLcgSqWq5HyFnJjMMbVkP2Qebm4t+0v5 buga0dJPgWBkw0H6HvmqStVsBg/d6zXa0jik1J8CwUp2oCsejHaB+2Ju6IbV7KF0gjNmY2jO sJwKO/WLqbi/1+6K9J30xeXYNUuaNtZ6M1bTI5HBlCHAJF3sVMrGCDz3bctALeQmy15W/43B pll/6nt2zmj4vC9p75eeedFq8RzhCJ0hJhNxmHgz3p+njb3iO1fG48LtJy+MZxnGwOcJrWNG CWf4UsD955mzD4unjBdTZovOxbI5yszRAU4M2HXCzgtn/thnI+uDdod1a+xsApV1hbQDWJPq HbxF+Qf+uuOl36RzsAy7pSZ7jggLQhOWexr+BYaXhYZwnja6hZLxHMpXgRdctFf2yr76giyv eV1Or1z3uooTE1frAWe9HnC4vIFDY0V5wTArRRKmpbapzU3M1+nHZ78+S81ukPVSuZyRY3KC kjmZTbAsW7bkAiSA6fVwRhorGnKydyjuytYfrNOcyeGaqC/o+aUq8Hy1CkM3c/+8A0QVnpBE Kdncft+GSTGp0a6pCJQuMfeCXlMcxbpFoQuSci+67VFrj0YaiZrQVMtNd4Hk3SKrlppdGvWR Pa4kSJLSUqeib6T8Pt0w2BmJami6UZ2UEVVS5WmNO4MDQr9oEs6P5p7gWJoSONFtFiiWTY0W H2DL86gu3P5skCZ0r3lWCs3leihid4d9AmPLnfjOYwNZh3c4x2SGe13Jw8540W+z8XXvq5fz ftFjRhLGsLbjWH0MYx/NUDreY12+vvaY6dXf+wUjL1oNLGfhGc5OMRTPEq+ZNRkYA2fiBq79 eGd1Z6uSdxmtev6Qx5dP9iRFx4tl8tQHyxm7njaIivI8Ahz9MP0kFOHd0pHhQrRIsb3GsWAw eChZSBbZaIGAPxRay4Mznwebxe1ShJtX5wGKC8WCeZLvz8Vi/cEoiW6QcMmW5Rp6yx88VFvs b2dlKScqklVPvlwSPWyOj8b8nh5wuUO6tN5iox15LrtBXir5Y7cdn+m5/bj0rHRHoq9JSAU3 Gb0gkbexLEmq1QVmQ2zFol3NdQojssiH9zetxU0MZkoss25jMaFQRq0purPsKjm+sv6GygVo kgGlGsDfXl34vLKQorOPiuwlNkrMaPED9ZOFwq4IMzgiHaUkajJ3+mvxyeHAJDG4E4LFZe5h CG/KUkmGXPc98YIz1D/xfMnhqVgMJV6nM+pQti7uvB5xWe5+s0ptUmLo5CCKjfwt6RBxeoIu hjZ6zIzlu5E3fi0OUS7ObF33mMlc+PD4kE1ACTYasL/3ixXQ2tx/ibu40J59UH8B0K0BMM8A cBUAfuCTwSgBmHYABE6DFeWY7a4GZ0qDuAngXd6H76sAfasAoRmA/kWAiF/D4AbA8HWA6A/3 kfzJvUi9pyHTuBe5DMDIjwCkGwAPvAIwhsK9iM8ex1KqdBNg4jcAx7YAjvMA5RjASXxOBd+r +juAmcMAs/gNDz0HcLYGUMf3k/G6898CWHxOw6d+CrB8+QAHOMABDnCAAxzg/xNAYQ2gNCfQ ikV6ECzct9EfPbHa8HqXW/R82BPqD8PAIAxDFPVXMpXOZGFEyqNUw7FxKOF+6sHj5RPTJ09V qrXTM7NnHpqbP1s/JzdgoXn/h/8vmg5u4L4XrPipFghCAkZgAqbgOEzDDKrqOpyHJnwOru7u 4rwgxCENR2ESx09ABc50x5fgC7u7u+/++63r/Y9r9H1ncPDp7n1oXEfo2jq0nV2bRWtIWWGd AXt6sdrTbAq/rdG1aZxxuWvr0L7RtVm0NyYr1enTE9Hy0urSo1c6K/FjV9orn7QPvVKBKvrt NHowCmX0yiriUbgCHVhBX7XgEnwW2mr/x8+NwzG02nC/e/7n81SvUU/BFvrml8CgZ6yQVPhK 36L+of4biicp79OviZ43LwjFD8DHqa79vuWlbeX4g/WtmZ1fbbOGc/otPDV0r4B/DQBF2coH CmVuZHN0cmVhbQ1lbmRvYmoNMTc5NyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAv TGVuZ3RoIDE1MTk4IC9MZW5ndGgxIDIzODg0ID4+IA1zdHJlYW0NCkiJjFZ7cFTlFf+d77u7 mxfJBgJ5YbnLJSGyCVEqr4AQSXYbCKQJD7uJwdkNefEIrBAxoVRB6tBeUh516ggNijxCHRi5 C4EGRJQWWwoTpei0KFrQAYpVUCgMZTrZ23M3IRL/cHq/vfee53fO9zvn3FkQgH5YBYnSH8/K HVUV9IWAyhMsLZnXEAh6X/CNBMo3ArR33vJGdcJN12nWfQLYSmqDdQ3pHT9aAtizmZ9Ut6i5 9kL/zkWA+jLw8N76mkD18aeu5QNzk9hnTD0L4hKi0oFYtsGw+obGpi0vhaOY5/3j9UVL5gUc C7tmAzMLAce0hkBT0F5HLZzPTrZXFwcaat47Pfhz4IlKzscTXLKs0bzFGjwx0dIHl9YEWzfX cOy0wZzTT21HkBq525CmZCIFMP/J91XrHZ5vXrd04SXm54J3xMGeu/s6irfRggNo4xWCkxRU oxnreB3Hv6BjOzZRO5ZhBXYy/Sa9JYKoYBSTEcQf8RBJ8wz24mfUD3b0x1/QicexydxAAxCL VBRgKQ7Lk/Lv5nXy0mIIpKMQM3FIXsc5UsSjthTbMjMHNkTjT+gU0znvRAzEWExFCSo5p92c 67s4T1m2AvMCXMjHLI7cjPXYgVO0QdSIp8VOedI2x9xichTeKQqZ8GI+Wy3DM9jC5/iaYmgA HafLMkVpDd8M3zUtlIfjETwGD57m05zAaXyEy/gPzaFa4RazZVCxKXXmILOdc34AozCN1wzM gR8r8RwjthUhsUO2hE+E74C4pyRyOOuxyOPzVzBWnfiYEimVMmg4FdEsmk/b6L/CIcaL1WKn uCNtMovXGLlDHpSfygvyhlKkNClX7LFmllls1ptN5qvm2+ZnjOkQZGE671mJJxHgUz2D1ViD X3C1WnltxavYhUPowGEcwQe4gM9wE3conkbRBJpItbSImugNOki/p/fprJgrAmK76JSarODY OxUohUqpskw5G0Z4XLglHAq/Z8ab+80/m1+ZXYzmEMY8gxHNgQ81HPkFbMJmjrgH+2DwOoLz PCNfMHLRvJyURMk0jB6kHMqlMVRKZVRBddRIzfQ8raeNtJlayaADnM0xepc+pqv0Dd1kZBhm ESsSxBAxVGSLHDFSlIg6sVZsFHvFQXGU1xnxoTgnzovL4oa4KxNlEq+hMlMWyWmyUi6RTbJZ Piv3MJ6n5UVF4folKFlKtvJzZZeyT3lf+VK5a4u1rbe9aHvZdtl22Q670/6ovdReb/+NvcP+ kUM6yhy1jmcdzzmedxyKQpQWtRf7eTpCfNL7LlGJ1/ABHcM/qE0miT1UKnbTSxQvU7BQ/pb+ aivGL8VEYdAMMUj+m5bTcgyUr9Mt3MIhoYhz5FZ20zYc5UlqEQtFk5JAP1FeV7qoUTmrSHEJ beK6FceepOzmaMt5/htoElN1aMArIgmnxU6uwlP4A16xR4uNXPcNyBRFGE1TrdqIr/ElT0ci TcYCnpMu2mFrFK/RCnlVxOFx6hIXaIKtEbV2J1bTAVEiT9Mlnryj3C/FVC/GUxW6cIW20xUx BzPEGuxQ6mwf0qfkphJbPfcflItyqqwVA8Sb+O61D+08CZ2YLk+ikn7N098p3JgqlmCrfIu+ QDutVOpkPWfZJBRaw7OwFwdkkRKLKWiX7ThGv5N/Izf2KU20mF40PV1zcdveprwhQ7YxymDz VPgT2kVnzCPiBsaap+SccB21Kqk8lyt5epcyQrHYw/6t/MVoQxRTGTyP67lfB/K3LZqn3Mtf rul4km7yxKxhlMZQFkrEUCwUjzlUO3+9HcOB/Pz8yZMenTghb/y4saMf+eGohx/KHZmT7R7x YNbwzIxh2lCXOuQHDwxOT0tNSR40MGlA/0RnQny/uNiY6CiH3cZFJGR7NK9fNTL9hpKpFRXl WLwWYEHgPoHfUFnk7WtjqP6ImdrXMp8ta79jmd9tmd9rSU51IibmZKseTTU6CzW1gyrKfEz/ qlArV41rEXpGhFYyI0w/Zlwu9lA9KfWFqkF+1WN4l9frHn8h7xeKjSnQCmpicrIRiollMpYp I1kLhih5EkUIkezJCwlE9eOsjDSt0GOkaoVWCobM8ASqjdIyn6cw3eUqz8k2qGCeVmVAm2Ik uCMmKIiEMewFhiMSRp1vHQfr1FD2O3pLhxNVfndctVYdqPQZMlBuxUh0c9xCI3nFpZRvWd68 f4Fv7f3adKl7UuarFqvra1VjW5nvfq3LepaX8x7sKzK8ft3LoVssFFNyORErfeso3Yeq0TyW xL9ANaK1KVq9vsDPBUnTDcxsdu1PS8s/bF5EmkfVZ/s0lzE5XSsPFA4OJUGf2XwgNV9N7avJ yQ45E7vRDMUn9BBx/e4nanp1ESpiblHFM3vhJCsjbSq3gaHOUzkTn8YHGWc9asZBnzeOzfgq J/YyqrkM843oAr/uzLPklr9hy3Bqqn4bXHbt2ld9JYEeiT3DeRsWaTVHb4Ox/h5tuN3GiBFW XzgKuJCc46QIPzone3mHGKMFnSq/GD6U+titPC+XMXe5rKqu68hHFTPGqjJfN6+iKn0/8nPd 5YbwW5p37mkGzrE0q+5pet39GrdvO6x/dwONqMzeX4Jz0ABPfZ5Bg75HXdOtL56lFZdV+FSP 7u/Btnh2H65bP65X10MZAwp8Ml30UCJdRrTciZW9xhbjizOUDP7ZI51c3eGI4laMSEj1Gk5/ UfezPMbl+j+dOsxvLK/I61u3njSNPHdffkIfvk96cbrkhJVMUTy7Qtdj+ui8/N3Rda+menW/ HugwV1VpqlPTD4tdYpce9PjvVbTDPLIu3fgf69UCVOVxhc/+b0QE8ZlaZzGj1iIoQnybcKlg jBipMYISDQlQa3zEB43FqIC1rbZWc9XGiqa1KjUVTKRg9BptJJ2mVCc2YxrUmZg0M2okgJJk TNUq/v3O3od4dRrb6dz59tt/H2fPnj17zt5xv5iOTcwWoxJhapjbfuTWJBrr1N34qC3TeRWv CLt9otB3WOpMkNdGhlCknRaRRhHlAc/ZvanezKYdYjXeiZX0mlbpbtJ7U4uxl3wYOwRteeAl 2kh3C8ZvMIrEYHAxsBCYCawHqoBrQDnwc4x/geeyjBCKhOFIWmBmu6ex3nSznt4EnkJ9hnGO ZlojoUc9ZfNcgygd7U9B1hNWJeWivRD9h9E2DfxHfD+DuhfzXNT/gvote50gyD6KeivakyEn Cngdeq/R38bYIrdEqxTxkJkLpGONIvA8YA7G8T6Gcruop4dFveugfxzqw7D+WDW+iAoho5lt Bpvw/ElsS3yXob4Temw3yG1DnYAByLhz8Yo4ou11n8T+K/z7BurpCO85tCfoH9Dpbvh1nNMe WHNFe9zW7S6UheFNPUV0Bm8FPMAj2gmab0zE+Z2jCeYFmsJwSPSEnXKxx0tGIS13yH0Ner5u 7sc8fIdQRJnGK9RRv0Ij0PeitZm+QDtpQ4B/0qtaC71k9aPD8K8cyC8H9kLmEuULhfQk5g9S ci7gv1QR7QB47f5BO7Ft8Eeuwl5HK2H3mw77cCWdAU6JeuEAhPllWL+Ybc7nLrLbGiFnMsY8 C/RB+wKFIoqErQ7hXL+Af5+BrDUBP5xxm2lGwG9DYB2CUH4WgLJ9Jd5clVQHHAM+hM3WA+NR fxyoBjBGOFi7J/yov/JX+Azs0F/5B3yD/Z/PSvmsfw/TlI+pOyNMzO8BOVuAPdZeWgZUAXsw ppHvC/ss6xmUzXeKfSbIyr/n0htapdaF98k+FWK+e0QLQ3cQvhVkvnfs+8yah0aAs/UUGsk+ y/4WZLaL0h/3ke9EiG/v1YV+zypuoPkBXy8LMt9TtkWIvZSj7F1D+1GfZSymfP3HlGH8nQq1 W1RtjsBZznVLeG9aM/3QqaMHcJZZ+C4P4y0Mu0HMMevosrJnA/0avMho0B40GoRpVrmfmSSO mVVaiarfxeEQdf4+Zkb7vv+2/X+BdsqsolmoN5kNrov9bOQ7YTeLJCAuyGivAcqAeGeg2OLM FT57KsVYRFcsvgseGmV6aLhRR6lGN8QBon5on2p+TC/o62i00UzfE2XIBQ0i0u6GHLCZHuC1 tFO0isHywQvb+dEdPhfuS0EO+ms4c8wP+JTiwN1bcQ8eCZ8UnBs4Pqv8gBitoPzVfT7kn8co H/xY0D/v9FO3vp1/tkBuz3C/DGeVWxDfg/eU70Zw/xwfOcZxjOQ4h392A4Ljw/n2fJGCe1Ku 4vAJyg3c7V8Cm4AC9PWHnp/g/i/jWIa1PrCyqMB6h2br36R8KxfrtdAzVgr1wr4vh3Lq025L IJ8mB3Mp2wn9LcE8aiaRo+LZu5Sj4s27lKjyKHTj/Gn9jtqs7mQH5rbyPVR3cBFlcG40ZtFm Y6P7GfbxG/0N2BvtRg79SPURjdE/d08Y+W4j50R9k4pBhcbL7nn9PHyP5z7tzjffp1es0VQY ksdjwNzG+ltv0UUDezT3qJzvDcZjPntntdtkn8X+36YLxkGM6U0XzeO8F9hgqNrTdDV3p1vK suxs96DxGRWYh9AGqDnL3eaAPbLb20L5MNsCMq0ZKmcfNU+ir4A+tGdSjp2PdRfRRbsH2nit dTj/QeAfuMdVvi5DfkukQv1L+NY85YtzzJXuO7qPZDAP6/W4d6vcM+Zy8PcB3rtixH3cH/Xe gI9Y+/A+4/fEJuT4vvQrq4KWWu/RUuMaLTXPYfxQStVbcY8M1Me5jYG4naFbaL+KmAv/9r9l /O8Ze7x7xtqu1stQOvA7pYhW6J9TjnaQUhFLJjuV8JUZKk+vhf/9A7jsB/0JSA3gMT+0jug7 CR99Ed/b9RjxMOqbtRT6m1ZpdEdbNOdcYyU9Z2RTsj4EcaQz3hQnaae4Ttv0aHKN47TN8NFp cR15sgt9pVfTFH0/3VTt79ECjEvX3qcxxhbE7zGw4RpqNPKoVP8D3dA/wB5mIdZjnrmeLpt9 KRF236Z/KRyGOEdNejY1WT+lbbwejwOOQH4+wxhPiWpeOyhdgwjTWcukYn0C/QT6fop6+R36 QteQnmvoU6XjPfRTerBczOMxxjZaReSeBfr5+dbkdtz9PnC2Hccx40wrOC9YJYh5pxD7puPN EktlkHmFqC0NOIhx08AtaBuN+iBgBOoRaFsCrgV3AmahHWPcP6Mt3eiFu+KPU8vQNgf9PrQf B/8V3/g30lZPdPMS0MmPtq7gDcByYCMwDiA/3/jIr4/7XXAJ2iDv5suYcxXfKaiXA9eBVmA7 sBZzPkZ/ApCJ72JgNvv2Xe+a/zvfO5/dL3PcYj3BI3APG8Nz0n1z8Dy/hsNzV/D8v47bvUHD 2G+H4D7a5dL/mDODDBFJgR+lxVKptpv2AUeBVsCgJJRZQB6gk0fbXfNSiscHylNUO2lychnz xMeT1bdnvJ87RPk5YpSfk1J4XEVtRjF/V9Qmj/J/xw/xf/ftl1yaFqNVkMDCXEajHAykAqWA gcUrarv19k+L6MrTdtV+o1dy9FFtF0bswrxdSsVdng7ojs2ysmytNW24aIa07aosVWWeKlNV OViV0YHeJl5dlUdVuU+Vg1WZqsosVS5QpRovLuHXgl8zfk2iyRNLCYKkiEkQMVJ4EoRHikMi QkTWPCQ3+ESkZ/hDclDcWJkMpMQ9KhPAElgWP14mAn3i0+VwAbkUITRyqEcPHFFsZ8fjE3sP 3lod1bY6iiJ8IrUmfqJMixCjkBJ5uWHAVsCoiV8s38LsOPVJFKdV1cgbiT6RXSP/JX2OqJHX pU8Tni7ymjwvr8rD8is5QR6Lr5KHMGprjfRJn4FRv433aVWeaLlWPgHlzstiOU8+H6e65vUB eSJlASblxufKaXE+XmVSnFrlUQkxB2QGOtPjfUIckB75M5mSqKYm89QDcohcLAdJtVyCf7lv +3UbwHRAfguLPahWyZBToyKiIoZ7z9re39ve3ba3xPam2d7RtneY7R1qe5Ns72DbO9D29rO9 ve2uTqwT43RyOjodHMexHMPRHHK6+txPPAPxsqOuVgwT0jJKQ9VjNC41fvjhP6xwNJpA1V30 TC1zyndEZnVdAWXmx1X/m/Hqj23iuuPvx/20nfOdY8fn/LB93AghR345mdMUF5uQOB0hFAia YoJVGoltKaughVRACtNaoXQ/GIxWsK1qgyYNKFvAIUvruFuHWLT+Rf8YFa1Uda2mMDZ1oeuW MQ1iZ993Dr+mTdud7/343sf33ud9Pu/eu5u9ZhY7Nm7J8GY7zni6Uffmdj3zkNWdFRc2ZVqt 7oy4ob9vHOPvpSCaIS9mMdrcl8UBFjpUkfGs6ZsCVQOHDlewfOHQ4VQKlT0b1+OeVVpbsuM/ JNsWU+veoVsPHN0b9k2Byn0TYugREaq9UD3KqkdZVa/KHO/u7cucrUplIqywUJXqzrzUG97a N4XP4Z91dkzhMZal+qboCnyucxOL0xUdqVQ3SGPjwPbnGO4cywAnXUVxhoMdyVUbx+EizrRx YLsiriyMTBtnloUfwAXxGMPVsgxw/k9Q0MYF/Z/chxvPmZ0d46Z551k5G5MrPisTsyGhEECM kA2BqRKyISFMbEjyHqRuEVJ/F1Jvt0TxPUyoiCkJ38GUsJas/+vY3m5ZnYPMKxv6xiXUnlqz tZiXqbtW2bqXBFb9pCKHfks/RU4rlXGY7Rmn2Y7icd1SY7hBcGUECIlwMfRKQz9YAR9r+IyN dkG4ZPFW3eq61ewWuJfdUiDsXrylH1xpVOTwmcVbKoQ1aOO+fu7ZMwQH0jsHO+7+di8eQ4v5 HtSdqe3tzsQ3bukbF8XOTGJbRwpijXdiTmdnduFiMVgPwRgLUnoXeDcmy4tAGI03HluBHwvh VuhCytoNXYGG7h/BPbvZxGOrGZzwChfR2nGC3wLFBPjSab2AeC6L639OkUNkhUmMApLAs/sE UbxmQu5/G0byZiwfW6/OxXryMRSHsjoPSVOjoRnaUkhguqP5ML04n+DRbRTmLiJ7KciSMfIU tBlOqHgYkfP0Rzw+D/vKZ9t1C57WM6PenEENs02Npa2G+Hg1qVmKs5OTrL8w0txz/BVUicJo e2LZM4HnAyTp6uO+xlG9PMBzvBLsrKqsrFIc9RouOa8IVQ7fejGHB1AJxglVCYB3g6+gSGWl saQfWtM8bQ35uVnWaP7mLLhjJj7LYuqsx9/W1IjTaRyNtka/EP1iS7W5RBCXRaPNkbIyn1cU REEQcWuziMccq1ZX4/LeQ4PPnAhMWv/I7HvnK2tbL76wQS3MW5ctvLP/8Nraa4djG/YdORO8 +t7A2f6d29f98Mm9A4XvX76MyML7wOkzPgcKKOhkIikJAhEkSeRlh4sTJMXlEgXJzcuq64QL kzBIFhRdXlF0ERfHBSnxUkqw6OYooarrNsFElgxeyOK3EooochylSHK97n7hed0KqHNIj8dU ds6BTvHYLNb8bVpb20i9NXJgeqRetw6o02xQ2uA3oirT/PT0iJ2KamxEnW5qNHFzqUkNig1a vUwQl9P49b++3ZU//ymO42tthhTZxuduJfGpwhbyCN714bGDY6B4buE6/wGoVoFGJ45LuBRW hgm31mKvEIqitahhVWvRwiVai85CTU6thdO9Oqn2xtUk3atyquIt8wVUj7tNOebEbUfZqsF5 6pw0UMfJaBgM9UTC6x5WymobRdwgYrGlUllT1bKG2ekP6lz66Z5ZdXYO9J2Nz4K66Rk1P6cB R+yBxJbZnhMojf0CMsNIU0ujRoTzi9XVZlgUNG9ZcyTKXbm0tXDyw8LfC+/ceA+v/BM2/G9W TR4p/O3U0d9d+MFNwlUUCvM4iRvxdzG9fuuKNvrqZ+8Wrv3+xm/AuagfZtoFUNkNzj2WWOsP A8lKliBv2NvozXg5N3aHCWxaKkO4ojIUbsANYbGLx2FVDSIMHw44FDYwriGktE01atxIKq+V Ni5Rs1hMaG7UAG0kjV0YYxUlN+pWgxVLY/B1ugfcfbMHuMesPJqJWzE1j2I8KH6A6QmU0+mn LasZGxF/kPi8BGwtmEubI61RdjLjL6s2jX4cwbnRzXvPfnnH2C+/OXCk8P4fX92/Ltr18Lr+ 57Z1HS/k+Zw/NHrj5fHCRx8dCPpPVXnMurUDt09e+FXID2ptBfbjwN6JphOPWGQ5fZgkxAHC OyghTl6SOanExcnyIlGBN2ACiIhyRg0Y2iEbNU4kiZeQgIUsefxNnudkeokQKCeqZA7+KA/D 1g3LxWFASZcMo+BP7mBLdwxb+9erf8F6QxrKDdb+HvVzqBTLLDxjLwhz6ZniEMWKKdgERio2 wtsDhWFOiDE2BaaZXWC0RIMWr624mVtizv94G33UnM8+SV8x+dzpwkOnC7B5B+ZpYP4oMJfR TxPREA5xFRJtplFhgdwWOMacl5yO/0pdrgHeWTw0oTLq+NIbPK9yQB2KCZ3jVHl4D1N8UX4H 036Hrb0tPbNATx4q6tyMyrIZRtKKoQcoLnqBUWQc7elwj2AaR+iUmXc+Qak5n/8O41Z3Ov9V YDYEtt4BzCh6OSGrPOy34zzhYQGaqK5tsXPdtPPEMq+vhVC6SJHUYEKBFyEypSdt3VDCY8YR YlitfEmLCk9/jbM1fO3EfRqmLSbcv6tYZGTdkaqpEf5gU2jGQ7j514V32RsJnrgJ3hkR6C+P hhL6g93hqFHDI4m/BEvd8kSFaHftQUsJRUtN4eXof7iKTbe7XrqvW6xDhrgJR6YLn5N/gktu /dl2yBaEhFvQL51wicRoOY7SVrFVjqpdYpecVL/kSdF+z9fpU9ygtEMedA2W7PQMlu4s3+f5 Rvm36CHt257XPR94Pi6vGC3/uJy44f15QQkLv1i4iHi4OBhRk3I8TwRRknhXiaI43aqmKaVe n89T5td134uKJIezC9sneI8GHxM1iU0+WGYIzwc9Pq+Hlzw+Ccqa4tV4oimywxF0Kl6nU2EL ke7zwhN4rPu2EFkZlmpAVEx0T41H05xOhwNUlmWHLIGDJ3n2eQXGXZlQYcMxrMs+n6zrL/Gy ojCv/IvucgFu4rrC8L13tbtediVdaa23LEuWbb2QbWxZlonBIiSUR6GQl21cEbdQwCEFq8Pb JAGG8EhKgcG4Q5gJNEOAtNA4GKgxUCBAQjqdTJLJpE1oA+0QOu3EzZDwmBC87rkrxZBOa3l0 96HZx/m/c85/IrGEvtrK9DXdYKIJU6W8W35d5hbJz8mXZU6udDe6ifsPI+AhOiVZ3i75+a08 aeMxz7vcJtnmpLLD6ZhwUHfsrM1hF2vmUN/0RI+t/Bv7pl9mV9JM9izDxAUHae7cmdwO+4mL 6jXhvg3GF21A7JpwADXq60ADHUBwg7zC+fa5oQBW/v4NuBHrpef/7xdKpVI4lYLMy2Z+Bpio dkeyDmgJqkkVTEZQb7XcTFx9vatIGrOFkJvau2d31s5uzAx+emp7oeRynuP7704+cbBrkPv5 nQnkndu4Zsurd8dxB9ccPJu928IomwOUmYAyFU9Jty/mlvIrTFy9qcU0l283raZ8SKlT5liW jlgqbyCbjGIBhFg0mSk1WqwqpSo1qvl0UWTZN0IshNOEGo0+kYAVISA1YeVKnKmoRjqThI2K AtobjX34TtqtSIR0YhBMYVeVFOUbSUyLq0UClW19OoIkuIHE6FDVzuF8k8TCMAbzCUknOuB+ uqoQ9ZywMXqGJWAu/1ZOzemq5yHN63g9o6/6GXbw3g/yh/6elxXpUlKmZWODfnGm5z07xJYC tn5HMlYlkV5kQCwmlwpyYV2nObjm97ezD5ZXeyJHTmvvvql1/ShpjvXz/YOf3D0459fHL3Cz 7kzgfnDlN1veu/s8vOuJoX8IFeCOKCpG3Wl3iIRlskJdV0iczB7cMwq6bZJpwsc8kg8OCKrk taseryGMJzqbVK4oznG2uFFyRwWWSaWphL56SvQ1DY+ZWA1tZEbAEq1CUDcxSvgTM3TLzRwS 1C1mg6bmbNI9VwTvqVIUAFdUKOrmoKSU1BXamSVKWmsTJFiCTuALeDy24pamcW9luw/0aJd3 nF3w4ZLsH3+VuXnkmraHzMUb8WfaLu3Dj3636e3kxAM4vmfNn1cuOI0dGy5hg7aMOaRm6JQ7 dIfkRrvSqQOG/SoZqY5Wl6ubrAYTdZtVaqI2j0osbrM5T6OFBqCkIZdb75ZmYM7dh0+nS2zR SqFRmC60CR3CakEQ2sFULcZkuFO2Q5PM5BzSrczUwWv/1RWHmyJLb70xWr5tjYj1Rn0EMBGI RYBTA9W6SwKT1IxryJzdu+dPzi5+cPNWbduq3Xj8yZ6nUnO3aRv5/klvLGw9uXKsOTB4iHw9 Y19mYmsMHuXUULNQBeo7UQX6Kl3YEmnn57rXuQ1JVxXUOj+44wDTnebWtAQHfIyGMrb3EOAg lHncHp+9bHU5HzZFLCHHc5E7iC9H8MiRTvfSwD+R0IBGkwbXwzFDfGSMC7oiHLF7DRziXZHQ yHisD9emLSEuTurF4rjKheKi5I3a8wTZ8wTZhwmyY/uMqmC0SsGVClYSlf+DoEGdIHpjgN4a sLBZIh9Ea71Fn6qymW8NdzZTZgeXHWJQlZPaRB2btmoYaqQsD5cBTKkDYKsrD9XZ7YaPJj/b 9PxTOzY8rWm/nT1pzLnFOw8z8Pq0ayu6b7zRpf1770vLN/20qbXte+PalzY/srhp1YRH9mH+ 5dOvb32/fgpD8K/ai4ZZeNLhTzF/SDt84faG9pJHq1d6pzIG24DBPwGDDlSKvkivCbDBpMiv WBJNMma9k1qtZruz1OFx2lWJLy5T7aUOR55FK1BpkgvhV1azzJWZyotlq0Nab/e0OQPAiw0F S3VKHeawGZgtKC2VHI5vTQZ006NlUnHUL1TB+De+nJmNLeNzTgPCCsGFkvXlPbtxn/sZ7kn3 PN1V+hmEm8Ucxlgg2cTqF5+rZ0gXw5Gzsya9mjGucyMA41rgWUVTWdcBqIMM8LqxJEd4GxA+ 79jJBf/Svpke+WGq41J7/aTq+UuubnwNm0/WL/rFtNGzsloJ3z/mwOrez4MP1K95QfscW7qe nlI5uISL8vK0dd9PP1nC+tFWmAmfBO7r0MfH0UggHKa/KGPaCRsKC/niirURkjQkC1IBTkpi AzuZgJMBNiiK7KusMhnvkjmzUY6OrBDstUX1XlSPi4rsGNcG43ZOiNdKuBMxz2EMRf3WKisx WzusxNpHanpTUnQUg3oE3GrU20VRd5uX7dKScMLvrfKSSu973itezttHXuytvwhS0JtgJG4M 3ogB1pnsfeOkpb6SXqVXWVBzkWQlky1qnZirk7WJUDn7lNcmkskaPcqimAhVAN6iYCtk8YYP i70BEmHrGTLtyKqe46OqLx9qnD1r1RfdvbcW4VNy4WPbW/e0PJSalDj3csP0J7YNoVe/1i7g T6w1j2+e+tLsh+tTbVPC43b+OHusbfnFVslmHhsc81jNxLrW5OORoicmhGt/2bbsnYUfs+gP Aed7gXMR7U4nPQT7kV9MchzhpAIscCQsiGKeap4EDBwRobIKgiSKjNdizCw7KwyBkoRu2hWv L1GJqlAPDAMQ7gvHCnS3vOU4JsNuOU9vjFXd7wKsl97hUStmyaOrBzMTwIE6mEMwfh+bteKg YW1QC2rXeXX//jsD7E3eGromSMw9Q++slqhkSYSo391qa7ctw8ttAiStT1bAryrYYPDZEeiB jApGJCzGrVIYDMoDR03R9VDJGCVSWp4uEyRjuY/MS5vc+BVDdD3CHXCfV+zgZXpdibUAwq2r mSzkGNS8q7DGGtFArLEB0slUkTN+przx02nANRyTmHVLMAmcQEBiBkId7j5/0tG/ueNsR/y1 870V3dqtnn1frYiAk+vsSC7dOu/iJS50d+9ftKFdC9/snHoSgUNCqOBZeFcfLkz/JOzAE9Ek VzNqcbWjdtcKtMK1EW1yjXC5PR5ngSjwIBuRzCajkcqKIlnB8NMin+Lx+XySUihJioPabD67 AyLi8Hkkh596qMT57DajQojP6SiwdabhnZ85TP2OPjy21xmgEKOxR40BD/HhPvxBLwpI/n48 H1H8wVHPCWl7MeidBr3pjUGIzsDgAB28Bv9uFx10O5m7amBRaoA0YfIy4zzss2DJ16LzG+7f 0P/0jSk9rkebjyPP0JVj1C/54VnRM5WV/yG7zIObOM8w/n37rXe1K+1qda5k67QOBDIRPrAw GFuAi4m5ITbiEOaywaHU2JxxuIK5gg2EpJRJMgFDUwjJhGTAgD0pIaTlMKEhzWTS5J/Smbqk k4GhkzKZDkGm77eSCdPaY+2OpRl73+95nvf3bIoBN4+am1nMfqLBGHiL0rMG0RmM1vgZ43nz ruUTnsFtpfjjG4U6Yn7m2QA+fj1t/7KQZ8cOHWAB0aIldxK5plkPG8mURydfu1Xc8NuJZDTg 2sbWEx1TH02iirsPJB2DUzCgE4lZK4QVIgO4LHB6HNEb9KIh6xtOL3JE9AgcjJrjMMMJjIdw VkI4gWMIK0t6DhNRgDPCCyDuwF96xfAiuKYHXz8vwfXADWAUMIjyI7ykMxUXRnnPQQdZrmZC HCaog9nlaJD65Ia6CKY7yKl+y8+VgjDl6wfGfvlN9YSabTj5fbpqDRMn7QPPdXbtOYY/ePSr 9DewBec9/idbylagIWgkupyYOX84DokhfcAQKhiNazAX05Xp5viX+9mSgmF6NhYJS8SIQp5A JEoskliUG4lGC0QJKoJkD3pVrM6yeHP5sFjkJXo1aQR+6MF/SHhiPi5cavR5UFIJrA4wgcee hMlcgjyKp9lDPL9nNsJqCMMrpYs7qejUH1P3FCCMB1PTcEejt/JeOtVPPSdnQa1sMDnoZLJh DEEc4oAutOSNlwbjWhYH8jl+CE1iTS3Un2ogbAG4lZmsVYmy8PTS17pn7lo8FtfW2J6pfKH1 oP/CqH/3XlmTdI5x2S8Yx4bnNB7ZPr5p8bwTi3bMnPz+7rkvzzYbZHdNYWWwqCGlHHln4cTV tasH/rNletHCEnzHqAhydGHZlCX171LSqIIZT6J9DAXQo0SjRnoe+sL6p4fW2faaTpl6TdxQ UyxUGaq21dkabVybHxOwcb4F/kkzcQUJ57UwTAAjK6aBhhEJer0cb4kg0eE16gWfudKFkSvm qnRNd9135bhclI0NCOrYYN/qwaUJp6C1gUo0HdUjFqG6oBbedQ2DyT1N0XpW6/8VLa1Hae+1 TFiQPLvahePR1FysnQ4VbLofLtlYz5I0SDbj6sIRKKU1DKhQRFuKQNQEDmoIb+G1MwD80w6K q8JF51bVdU45dG3G+i07xjZ1DR+2Cm9fXH+08aX6JW/HITHTD6aP++tX+74/Wh9rbu3D3fl7 9u/EuRt2/frwW+vAsWtg1nbQcx7qTIhlpMm6PO8wxzooUNQC4JWJHSZmQV6Tskl4QXldl8NZ 7dahwgScZJI6zhiUZ+txcASg4St0u7Fmr553elk9SvrwCKgU/5LtPj7sMiaRrMiMPNk9ajKV LNQKTa2AwaknpJDqBzbT1loqCo+vZpVpDtLH58P0cbMCJP5zVT91vf+XvRj/7r3rZ/Cahau6 5m9MJo/hdsu1y3/rO41nfHD5qKGhde/Ad9v37NkFivolPGWf1p+86J1e5M60BjN9ynrQlUA4 mXU7SZOhRzov83bZ6h7KB2zV8hyZs6o4hv1iga1ObBRzRuMisdw2GY8Xa2ycw2g06PVWwYDy vAJvlEWrl9FLN+Wk4aZirDc2G7uMrLEHB8/7FV9O2BfuxSHNsg8ydWBqf7qfPn05/IACYhBK m7WzT9EWEI2GshOgXrRAVGMNmKhLYRgyQ5Q3Tx3uO3p/49WGjd0Dn58cGFHwfM2Ly3btWDZu ZdOkN87c/upTPK7rEjPm4UR8sXlb7bZ3H27ZP7rja+qw52Ee4+DUnSgffdKL/LQ9wUC8lOnt dCpJOhUukt/h6HCyDmd1LsOjc84rThImBfoNubtzWUQ/i/JyETFjk9GNggpeBEiDFTwDblg8 m83LLTC9Yu4CpjSzPq+BV0EZgJevJvKsPl044PYZE6qvBBkV42rjbZhURTBckZFHNKOPzHg0 cQADKWlgikxXUsv6olQqrS0UmkArWW7IiMXK+7NUgf2ZYXFkxofhgfsX119ZfgyjQx//XX70 A/vy0lT3QJB5Du9ZufYSbjK33131xc7TuPro3ZvTZnmdh95qw20uw56DXeCSFEJkAhC5HX2a WB7gcQQP1Zfxty23rTkOHDaXmgkLEcPaiNlmt5vgHuUY9Aaih0pqtwdQDmy9HNknYCtTQCww DpZwdogiy1orWatA7zGvtdkEuz2JBHYtAGSMdp4extqtCp91QtQ8VW/6n8LDfjBNrD8LiQr9 ToOWaKgMxr65TOnjc5Tych5+6MRaIPWLLYF4MdQWkBWvpQhfzAdI6vJx93Gvo3jN0l+0+xdU jIxbHTfcNy6TNzoPtywb5z7iGLm0tfNRI1XPyIE57A5QTz4qxu5eFM64CRqDdi2i+qmkaV1o LWRYR5lQG24IbxuZE4qOGMmEzCFbJSr3soD0Baoqis6IFHE4nQFRha2o4iBCCvyJHmZ/oliK ea28I6JyEa8kcl630eEQnM6kAJ+DYQnqVhV71Zi6Tb2lsvUqRrBPe5hQtxDwUVS4lXAxvgPA yFeUcKWIkYjFkoiqiKpYIobrYarQDaNQDz9JteA7sDf/oaSjbT+kUi2t2AnhnY3wL7SLNnH4 lTOGHFSS2shp1+kfBFsNzXfLyh91mfjWHBxVVQ6oi5o2Hn/KzfFiIjMZyVqsqv3nRJeZ0ReY /FDhtLcnxSLmfUePffve3c1/bgme+DrQ+tnObb3zv7N5mqvmfrjq4Mrxm1bGF5kqKkz22rJL dQfufXsWF7x+9fRPj09dXDF+6ywnM3tVfOrMzZjb0P5m9cEblM6qIKLH0D4AjLyhmsVhHnsN XokRcEj3LJ6om0N26z438cv5Nl0b7NiPdB+ZOFbPyoxVb4W8UR0M43AEMgwnGAwBSbECQVtg r9INK4GgBWBnQ1ISDihYUYSYVCltlW5JrCJNl+qlZomVpB5mc2J4LqxZweEAuZsxLUz/s2Sd AkaKBHtWUusq6KaNUnE/vW1B/ClYuU+c8GTXZt9RBg/Mke1Q2nkNOgOuDrp3eTljCvhqRamW p7YtTwKWbHRwPKFLdl3D6QU7XvW1n9vtnlS15EzDsHpYrX9aUtvROuo36X1Me2ewZPzys9cG RoF4x4JJgjBngngcS4gnyVXyX7arBbap6wyfcx++vn7de/12XteP2Am2wVnjxAlLyQ2QQEpD Ch0mgALhWVI6SFJIQzMgkQoBlYlCeG5M6SZG6SY1IyElwLbQqlNBQGHVNKmTxjopG5sQI+uo tIHs7D/32iRsdZRzzj12rJzvfP/3ff89+mua4Uk/+GKsIt7I9/B3eFrmY/wAP8iP8ZO8DrEM g2mAEmG6mOK4AIPtZGc9wVbH6rhixgCocdxWhhdV1EBGyBe64Qt7mDsMxShGIc7sIP0lkwEu A1qkPQJIQA4ZYZSGWdXqn/HVoWpGmRNUn4YXhbRdS40Pdu3FMFgD2lv5JdqcF9NmV+ajvJ18 NL9IfRry+Koj018r/u+OMjpFxgfT+lmOnaZOkXacKOUw9IK4NnIhkp5/d+Qu8+DWrSc2JvTk DwDrpD69nAqo2FrRLWXBAR7H7MtJX2owYNpkNlMsQwBkJNbIUWZzwIDt5B0VRaOO80oCgGg2 ew08Qjw2Ao4GHnDElxU/b1CEyjUgE6IhZqg2NBoYQ5I32Iox0QybITk8TTMIrhPNqijDGb/U ol8zzpJx6syQxdUDZ2RCE2VybgTKLMLZ+8RPNBKqJ08QLUjA+SHbBfwAwnAkJXrnlMyuDf5p 5K+RikX7FhA8/vPWD6SGQabkyeDtRRugsssBmnwVlbSyrIXFjWwPe4el9VhmY+wAO8iOsZMs R9F0pnrVRAz1CljQ9NZsGVrRGLqNqB50B0isGKHj2MxoeXdNlkyESx0alZDitlajLJUQoZL6 ZMlLwBNQCBEKka1hX0KbgTooSx1EqKPuAnVQhoNkvlhD3gxYn+XTU0L9D5+ehmiVPx1Qw7gc yjX9GXv5cR0gMw860h7wqjCuV56vk3BU4Q3xgeiVwFj0tut64B6lO+U6FfjA+YF/MHrFpau1 JPXLLMutmyx7ojoe+/V+S5m+1FKn10XJP95oFuP0jDBFhcMESewVK8GvAdD8goKA7LV7yYYX y7JXsFoDNrvdTjbs2GazB2WdRzaZVK3UheUC0opER/Hnitku8NYmu4hsoo2CrmOLYpbzxYIm MDFZlCmZ7MiIEsNNWJxSyWQELsYrynbRRkpdI572C9GJRIWGFAzacvrqEyyqkQFe2eQAzSPb NwuYTMQRVu5nl1NKGSFSGYEAUcqpQun6Rrmcvp53dyS4caB5/V7HkuH1e/e6Do0csc2tWnKu OfDayHGxJt7w/qv+ViY02J5sXb1h/e6Ob7WnvkP9OhmMV60b+GkqRd2ql+PKusGfpA0Z/6qE u3Shh8pLhVwZRwWoQn05VadPUstNm6id+i7pZ9IY2NZN/XXJQjtdFKOjKZdLvStFrGxT7ypj XSJsdIg442D0KE4rEkVhXbHJZTZDWiAWxI/ii0OmJhEmBcwMTxnZFWoXpGcKXx5yNWEiH7Zp d+Oesi5yGSTow9QOk+pkalqrilRXIY847lZ9KYM4cSYNcSIUpB0ktEZTiD+DNTjT3TNFWy6v 7e3P6Rv5vqO+9u0vSl9hQpe+u+Hgjm/vSe2ifrwuVjb32r/SVijoDZD5lwJ6FuRFXZeQBCnt ZUhpuV4Yinjc4m/zUzo212EvoFfYVzqSBUl5m6NF1s1j8Xax096d82bBBZrNkxkO2jyj4EXK zFgchXweL+JEro2judf9oY3T+jtI8Wp+J3moHQSOhHWbmNCOQamRPUFi+hzqaU+z4eKJr6/e P5p+eOJ7N7aMvLNtdse6Wod8eOuyg+1luB8nbp6buHkx/Ztzr358+PgPYy3dC9avemdgyenb xBnup1uZhXA+CfnQY8VfKyeZ1cJKxxaBne0ok2uZBqHewQaZWULEkWCqBFYcnZxQlsDh8wgC K9xdeKf7AD6B/u3TedwhUwVeiF8RN7t1eh+2ShSd76IkKSOfomjJ11KPziVbjFIxsvDeHJSz JofKGaV8SiEiAUeSIODsV5VVJIH+RR75i4mcIr/hxpxnzeSf2Xz/bHghgktc5kEmwahjSoJe URO9DEuAJGrehNaxmcZPqULpwEOK6EzEzCZMBy59T27uX3ry2tZ3zyTHWrvOS56ORaev9rbU dm6cm25lf3V07aI/fnY2/fDs4o9TY3T9G7NqXsJrLvb11x/+XKtCehXgLKBHSjdP7+P79Yd5 Rmd2ms/qP2X+zjymdSGqmKnA5dRCvBMfwJxFoGgjJQjZ6Nik1xkz8AmaCQlCE1IsYhwsGWwI hA2VgJeRTqAFtYEdTUBVafVFo6SoetKNS7gKPbWlr1Qvbu8AY7qEEJiJ3ZexGosL3MTs1Cxm pkudhwoy7rIi49eRb8yL1dmcgrIoA4mzpaj1TjSU4Lszl/5oaXnjC7GKNdcqVzKhL7o7i875 f5d+kE6S1L0Y6o4GvKLoqxFjWJDi8ujk74dhpkmj5IHFMfNp32k/3Um/6TluPGZijISQXtJO wewjn5oPi7302+4zxrNmpo7eadxvpMOmQp8/UGFivCYjnQ9OBTODXYXOpTZUiPGMHNnGsfIM Y75XgTS+HUdHqSMKj5u8JGxj0l4q4kwZeqYJvRcFxSAVnHASxKTCGXHkFJ3Ul07s/GhW8iOt pNsjDY+aU+PNsOx4AHLWrhW3tTI2LqbGJVclliqtrkoodq31wepogwonkaYsXhQqLCINj+ob XIiA5wBikh+HXSVqaNlISW+yq6swmP5z8bz51y5c+y1znunZsXrzzIJdd8qTaz/tG+3txVuM i7fWtdTEwuFuz4xtC3dfuHTC1NKWfO65UE75yvjLbzSeXLVqFRzw9cl/UEfYcygH7VfCLwib hE6hTzhpOWV7j/9F3tW8v9nAUjCNPAKyGqOSCdyZNgoTEvjAkLjdehmnkY3KHbY38aZRKnfI vN34SyoXyJqLeADJWBgFsor8IZ7mR6lDw7kVkA4Bmsij8UeABxnHCT5VqapqwKVSvE7YE+TU c5bFE7ZAotSWoEu5AA0wAEL4fkHN868pJTm9h/IPJW4vGSo43+0Khqv6j0plxbWB3VTrQczu Su8+mBppc3r9cL4e4FUnEwIXSis7PHoPf8z4Ifeh4Z7jL26O1/P8W6Z97mPcMcPP6fd1+iJD wt3JdRq2m3a4dVEcEyuleolxeNxgjk6P3QleuAeu2+kh5sjq7foSMEc9Zlk90v+X/WqNjaKK wufOa+/MbGdnH93dWQpuW+iDVlvZ0m1JtUtKi30sFAiwpTZQSgtFsLYiSBRtSEQkIFqiNCQE FRXjD16lAo0INDVRUeMfBTUKkUrxxxI00ERxW88dtkmD4fGDP5res3PvuXfOzsz9zrnnYbhl 6pEybA9wquFVRF+G26Ci7om4WdizeSPFBtGN2cZio8UQDKzvusbhCWcRM8nqzxXJN+IF8arI 54jFIicaHtEj+pSC03H3N4sd2nD0WpTFRxzM+IgukRUKUYyQmKSYLo4FSJY/szTFrN00lvFB HSveJiGoJqaBOJb5+UEzh07ljZOfPbczpb37VUf5zKrXm5Pd45d0/7zv1LltTSV7ucZYzfyc opKKFxYEt5AzWF4QeAczjPWIqQK7Q5WOdN5vLVNC1mrrK5bNcrv1PfK+cpSokigqbiFdKQAR C94AFV2Uirg3ygUIuDDFkClliYQCihwBqlMO0UjE5CLiJ7nkKuFbyHbCkWG1h4S5Z8G0m7bY 9boo23QRA4C5HTqqUDX9O7q2I1RxePJIVk0yH3Bi9hXEbJdU7z9Ya3PnzSENJ2NvCWmxo0u+ b+3gXjT3swez3yDux4fvT/vVILak80lcpjHTWOfcxLerm6wbnS9523075W9dA/Jl5bJTSzJL vuQ8NoZKVD1Pt2maPcGqqlqi2+NxeQ2fzyNTiyQposBzGGJ8oDk9LofdrqqeBkVhO3dqDS6X T2rwgeLs4ZaBi2s86kvyeHyOiL2HHAeVW9Z1CgutY+R4FxchGDOXddmYTyKnQ7INA6YxbttW 5nb6W8ODrZf02GDdkDHojRmzShtnXPKG9cEriFUUoYreRCxqwkYchfZCZi66tqGvrw+Hkf6W jqWyWXWtUMdwZEAyczEBdQZIKp+WLlkI0Vr25zo5YcLkh2KfplJuSmt/d+zPjzMELrNgaEBI G0odujahtml1Izc5Fl3/xaYr5JcbP3At0z544vnYm8zvw9AcYQNi74LO0Dy/O1cNWUPulxVR tqoJbtmjTFYLEiRK5QRNswBJBCehvE3XAxbNZbFoCZpi0fkEiugriixRhfc7MUrqGsGfpkRk 0sN1QCLhDyFQen9ONAfdsllumlAwJNAjm0dnVOFpruhCHy0yTcrOyk08K0HTnNCYmB9WC6YG U7Lzph06XO21kx9PxGqXdjYUDzV9qBvJtSuEzNjAnj38whvhg224SywjP+GC4hGQoQYjh5Qv cRZJ5inaBkgrLce4jV1QSvhj3K6QDS0DVDQC/gBXSg6gsiu7lNotzPyvxfpNzaJSw1iNxAaj LJ44CuGm2yTBANqbBT+UPJr19aSU7fX2tenCwFdH3n7DOjsZ4z1MuwtF7oF6oZew8rGby+MO 8RNMWmtSr3Bd7JXKpNOWzfQR+rdcL5+Vzyq7lF3qre2E9WnrpYQnNUnbZmvWx+tn7AuQLjo+ d65wnnNtdW1NnJh4wV3t/suz1OtH2vEfpO/GaIzGaIzG6P9GwBrHchdsLuAZR3x4SXDXxo+e 6P+6nQITIS09IxMgGyAn9+Epgbyp+cECjM1FcYkZpWUzHyuvqKwKw+zqOXPnwfwFCyM1i+Dx 273xo7t/1P1sAnRi70cSzPFBKIbpUAblMB8WQg2shKdgHayHDr8xPDxKogQlqkyJelgFbSMS wxdvRzDxwu64Du7cEPLh3+8oQaEp/iQenABxXkDeGecl5NKYpgUZV9KgMM5zoMHiOM/j+uo4 LyC/I85LyB8vqQpXhMNZ09ua61dll6+pX9XccG9LCEwVhKECrzBkIVBt0GxClI2ArTG5ZmiA udAIy+EZnNWjxL39535K3USNfxe7YlgEIiKjQw6KA5eJeuZxjqCQ1/AOFUzTEGBkhCbOwZLk kXareoqxQQgtpYOyx3xJA3xnXEs4/aNyU+tiW9F1alBTem9b70k2Hq48/9uNn2LL6T4awKk8 Yiv/DAA10MOtCmVuZHN0cmVhbQ1lbmRvYmoNMTc5OCAwIG9iag08PCAvRmlsdGVyIC9GbGF0 ZURlY29kZSAvTGVuZ3RoIDIzNjU2IC9MZW5ndGgxIDM4NDE2ID4+IA1zdHJlYW0NCkiJXFQJ WFTXFf7Pve/NIAyIBmXRxDc+IcpAVKxxo4jCoKmCLBoHq5ERkMGIDK6YuMYFO67xQ6rGmFpj xFj1YVHRamtitn4KWJMmmqZuSapZjLTfZ0xjnNczo7Xad7733rnnnvW/5x4QgHAsgUTumILe KVO8rhZg0yqW5hRXuL1LMlypwMblAJ0pnjtbq/Oem8t7nwGWPlO9ZRXzntxzC7DaANUomz5/ ar/QJzxAUlcgv4en1F3y/ohvctjfebZ52sOCjhUd1gO247zu4amYXT3+yIwSXl8GogZPryx2 0+pTPYFF6bzOrHBXe9sdoU1szz6hzXBXlG4+IK4DtV5e/+CtnDWb8+anNjew751Z6v1mX9VV wM7xQ++qxxDLb5y6G7FKAmIA8xq/1wN/f7l5PbAf+Iuv2brp/gvUYx+VYx/+hLepja0O4Cga 8QGikYltWIBa1MCCCSz5FfKZVJbXUqzZiN7YwfnsQDPrjsciHENnijG/wmKskB+y1QpGujuG IReVWEujzTmYiEvKMgzAaMyAl5aYLnOdudF8HbtwVH5g3kUY4lDM1Gx+p543P0MyW2zCFlyi je0OIZ2jLGHNVzETW+Ukhcwy80fOwI55nIOCbDTTSeFg76W4RjG0QGawl52mYb7DWl0xCR5s xTHqTyOEXZ1oZpvN6MwxqtnrFhzEYaYmnMCnZFPbzNfNNsQiCc9wPY1ooZPSf3epfygjpjJK vTCIdyrxR7yPs6TTW6JStakparr6gvkRotAX4zjb3Wz5D7otFjEtlu8pWeZwRDAuLwfQxru4 QnHUm8bQs6KXqBTb5UyEcMS+TCUoZ7w3s/eL5KDDwiZa5U5lr3LH8rj/shnBJ5KAV/Aq3qJw rlSjWfQSfUyfiwwxWbwirspaZY9yzurmqp9DBdZiL25TRxpIefRL8tACqqGXaQs101m6LoaJ seJ5cVN6ZJU8oQxnKlBmKcvUlepqy3W/y/+O/y/+22aKuRJ53A9LOftN2M6VHUUrLjBdwlVS KYwimDSy0zh6kWkRraXfUj3toUaOcpau0lf0L7pFdwSYLKKLsIvuTLqYKeaJWrFNtDKdFd+K f8to2V06ZH+ZKgtlJWdVIzcwHZJXlDilVTEZ5xS1Tn1NrVf3qm+rbRab9aUQhJz5aefdxLsX /fCv8tf5D/obzSvoxGcYxyh0Qypn72aaxuddxx13AB+SjbGLo0RKo9GMzGSaRlVUzUgup620 K5j7fjrOKH1CNznncNE1mPNTor8YLsYwPSdKRZXYIDaKRvGx+FFaZZhsLzvJRDlCTpKlcrac L+ukIc/Iv8ur8nv5E5OphCrdlO5KguJQRiiTlTnKduWack2dqJ5Wv7SEWiosKy1Nln9an7am WXOtedZJ1vXWw9aPQoq4O0/hEI7goYcuy6XSKQ9hneinxIoW0cL9PBklMltwp4p6WiUWUqPo oVZbhoghlIM2JYGxfk+8Jr4XQ2Q2jaICTBN973mzRClv8i9VOYUbynGurYU9V1tstEjctNhw kCAGccx3ZR/FIU/jU3mJrMoO/E0JpWi6IXbLXO6CE0qa6oJdbsN+WUULcUg4eTrdCVnDfZxD b/JcGEsp9IM0IUUOd9EA+TmW4XlxHjf4Hq/Cr6lEKcM69KMFuIY3+Fb0UmdYEi2d6M+iXPGJ x6gRQtnD1Q2iHiTVKCynSXKr5aa4gDloVUJxUf6Os28V+2W20qbmk4dvwEKsRJW5FPNVl3KO yiDpWcQrl3m6LZApip3/i3mqTOSZdphv9zGeA8NkNktiuHNGc1+M4wmxlWkzzwmFO6ic7/h4 nmItaLSMFU0oUyOIpw6gnPbnY4L5BraYZZhhbkQyz4MacwF7rMeXWI96WuF/EV48wTfnIo1W s0SrmmUmC5+4IApE3aPny2jHUwy+ZtqPLKSpf4BP+QQFGGquMf/K3d2TJ+wWTMEv8AVX+R1H GClPop8/RzSYWdLL9V5Cnrnb7Eah8JjTMQbHscuqwm11pA8blj407eepQwYPGjig/8/6pfTt 0/up5CRHYq+eTybE99C727VuTzzetUtcbEx0505Rj3XsENk+ItwWFtouxGpRFSkISU49q0gz EooMJUEfOTI5sNbdLHA/JCgyNBZlPapjaEVBNe1RzXTWnPp/mun3NNMfaFKklorU5CTNqWtG c6auNdGEPBfzazP1Qs24EeSzg/yGIB/OvN3OBpozxpOpGVSkOY2suR6fsyiT3TWEhWboGaWh yUloCA1jNow5I1r3NlB0GgUZEe0c3CAQEs5JGXF6ptOI1TMDGRgy3ukuMXLzXM7MLnZ7YXKS QRnF+hQD+nCjvSOogoxgGMOSYViDYbTyQDVYrTUknfStaYrElCKHrUQvcU90GdJdGIjRwcFx M43oF76I+d+SnXfMcNU8vNtF+pwx5Vpg6fPVaMZv8lwP79oD38JC9sG2Ij6ryJfFodcwiKMK NI4mVhS6DFrBIbVAJYGq7tVXqjsDkqJpmtFOH657fNOK+GjifAby59sPxsWlHzUvI86p+ca6 dLsxtIte6M7s2hAFX/7838ema7GP7iQnNUR2uAdsQ0T7+4wt/GGm9MFekAuqB7hR+Q+QpUBG +jPcEIZWrHEmLp1rGhj4lA6Er3ggq/FTSGxllPCJlBvtMop8kYMD8oC9ocZH6prvFrgD9Bvf Pipx35dY4iNvIcAG+uRBq/H+f3nD4TASEwMtYs3gM+Uc04Lr/slJc5uErnsjNf4xfMhlbN2F g3sz/HZ74IBXN6VjCi+MJXmue2sN/+G+WoOruqrwOufsc+6FggTihUKGkhBSoBASEnlFkMsr BSLQEPK6pRIeVkpAsNiKTlsuEx7hkmhFYVKgNIkgMcHhAqkNTJXATBupU9COoWrx0UdmbONY 2qGdKZQcv7XPPpebA9Ng1T9m7pdvr7Vfa6+99tr7rEg6QcGMMaVRvYxrWt2aQCHXhN2aWPey VERyM/FDNhD13xv79UsYmDhndU5UG/gZ1V936vMKUvPyQyXJcyJlyrd5S7pJTv3kWJ0qRRNn lRhJuirpSYasRVAujTVmoaRPVKThZ8mgXtXi8yMqpUZLzo0mlM11/pf2Tkm5w04t9hXuJelm N2VmNGdMd/nL3eRu5vWJGDAYl2DeklAk0rtbHULNmXCeIkQ8LSlJSZ4VpUKczDT8WuzWyYzS pGgQLpvFDRB/jkqJ3RomqXIp/jg608fmItFFIrmpybmRssjyFju8IjU5ITVySj+nn4tsmFPm Bk6LfXpXUjS3qhS+Wq3lpPOe+r7StZBmJdC1Y13ZCTlyl+P+zL6WUvE9rRDVX6eviY0UAOb5 htJ3zCIq0XZQSG+kJxjGUAqKo/Qo2jZCngE+zX3RvhD4KzAVKAKGKN0CYDlQwDLanuK+GGMD jyN5I4X8w2i9WWTfwHx7zTZ6GDiIcr14mxqsKbQO8iH0OyOIJnEb9NlrNVIN9AdQvxK6g+AS yHUoL0W/TFXu5avGtw4YsKAfjXF2qfWONM7SRLHRfhNrKcWY84HtmOMBcC6QhzaJ4JnADq2N KrU2ux71YKrA/DtYD8xWPBfjbEP9dPQbAbkC5SGwwwL3A1KAUfpRmqJ/kV4EZ2D9xc66gTZa zWuOrQn2K5tuhWNjXjww5y+BVH2K3QHuFWebFxUezDOyKQwuB5KAfP1VWie+Shr89YzZQQbD T8R++gswTayihZA12FlgNtM+loEFEhvtG+IA1RpXaTLqvmftxTrwJcsvR/1jytD/QelWGm1G fM3G+FuAgxjz7zIeVtESzD8OnC06ZAxtB6ow1/uun9g3kLdgXxdjrk/9HMONVADcj30JA2vZ HsyfwT7nfdeKuqag7Ttos5QB/SAJrJ1jkvtwf4yVpuKw/iZTPdpUw69/AwsgwDa4kHGmgLqX Mc5gwAKGAuOADqAeKAdygBeAUZibMK8h4xUxw7Ep4wOxYbbBh7BNxqyzhoNyP50zU6fG4nlS rKNUrpDCY/J54ZiFLcfdsflMccy4LOO7nONe+4DXyTEVY5w90Un3sw3yDCK2XOZzB5v5POzV C6kSvA9xXMExy/a5zH7hWJM+wZlQPDVurZnyjIANolQV6xUuu76I8Wo6hDHLrBXIKbU0V3wb b9cf0gpxhWYbo2mcmQkd1oO2Ub2TFvvxrsVeLoL8jIdrGL52bY3ZinU2wZ/t9Cx8+i3Rrg8X 7ZppNtnvmqSdN5v0p2T5FvZCa3XqmBnxdf+u/vNAv2Q2IWc22e+Z7baN9ezmM+Hr1DKBZJeh PwGEgfv8Y7Qaf7nW4iukBIvoKrBeBCnHDNIk0Yr9CSDP4yxAX2i+SWeMatop2u0/amEK6+20 3Reg5fj+6Mdz6ZeogsHjgzfExVG3mPPGkstuvHqZc76KqWFgC+fvgsI7Ch8DHyGOfqI5c0zi /CzvB+RoYLsTr/a1WHyep8PgXW58euK03BOffbxx6WV5tyC/u+cUdux018/5kXMc50jOc5xn 3PZejusf0RsRx5yHX6WQOtfDFebDxrfU2Ucexn4X27aVax+xmu0GY4DdYGWh/AfAtI9g3Zti d2qJ3aXu09HuXero6S73HjWzaZ3KZ4dkvvmQfizv0SJpXy/rGG02r2PfkQOlvbXqDMKfsLtc lMHn+6gK6xhs7MB5hB5Yyj6Re0F0N98LfCcae+BnvouqqcJ4A+8F7ptN/eV9MZ2KYft5qcOd ysw6s5jqrU7KEoXIta20iveK18H28N77H6O+/gDyRDuNFz9DmwD1Rrta6YMgHZFxwX3L8fqB L3wryYeYXYg2PF6d7BOkAcofh6QvZH+8RTi+2BcY0wrQYvme6KTnzEIqxhmq84WpzirEmQtQ A8Y4jH6FbAv6DZH39R56EOerErmpEjmHZPyH7OtGE9azCXkdMMLwURPdbYbhw3K59tnCybE7 +PwYjXQvx4i1B3mY3xN7KCLG0ByrnKqhqzaRJzHvLui24vxm4uzuRP9hKm8T5t4JPfedzm8Z fiPwefEFKdEKy3cASRv4nYL5jXepzphPlYjjGf498MM2Ssd9oSH27gHGO5DyUwpVDqQuwWEt xUigJ6U+m17TG427ELd8h54SW+gRUURZxngaLPpTuvgdzuontN/oR8vEK7RftFAVyyKRRhl4 5xrNeFuy/iI9wHr9Ncg1FBJT0b+SvimW0UbjOGLv99RbPIy9Rj/z+4iTEej/IcZV0N6mkFGE s7Ud5U/so9xOztFsFzPEXEqX/eIgbXXhsVnPg9/mY09hL5e72QtbY3a6Nt7GPrlOHhf9uI3Y T1OJ7MtAmsNd+Xo1NQG1+p9olrGAvqs1IMEcoFytAzig8HOaK/k4kI87foL2BDBOTKAXgC0o jwX/CjjmyHi7TaA3gG0Y+yz4JH8XMPSZNJEZuoNADfAbty4ePNft9PEwk6i7/DyFGdpV+wbD 2x5+noj5Jopp8CeAWHyaYW2mkO9x7N9I6O/BmB4Z82SJ52lNT/b0BO0iZUofOgjGr9HdD/DA O8DlOE5mVnfDf2Tf5wH2dzPwkPTvPymgYugL2iUaDi4CFxmP0SYG5HTIpa4/tauINUYD/Ujq Y/vn6BErhHfcNK/eK3v3tSdZP0mH4+HGQSwedtNWhpiO9oBX9p+nrQzrJdS9dKssjvSAEN1n 7JM2kYwxj2wtwp0J6CNg6xDZp4oRky/iLAPcVvbvS9UMeXYBvZkeYcTqJyB/A3F+nch+xZyy 3t0fd1+8+wP7guICEMJdcYEywQXgGS7H4lvli24xn+/Ee0zmXNLhaXPzTNw8Gxf5rrn9mP9P wNl5BWgDXv5fz8VZhnNEAueJy3iHTMc7sh3vkwepgugGcsmnGcBPkYeWgF+HDrd312igL8r9 ofsG+Fmi6x+h/Cj07Q5sXSRRrXpXDobuF6qvX41X4PS//muia4ioa8ec/tcbgTUofwA8ifKf wWfBNWj/HvptBZ9z6m8sg/w48CLkTshrgRKUnwYHwGOBRGAA+u9l8Hvklu/Q/zrf/vvjThlv lpWwcxj4NPgJ7zfEHbO7nz2w91vD3f+e2FTfErey4wd8M72Fd180/tvns75xXMZ+qj88CFOp nzGI3gdswKBh+J8BLAKWAT8AngMs2Y4164HNwBngiqwJGoNO7M4OtoB2STq5Zm2WFJc74tKH pHiyuNThBfkOz57nNMtxmo3/kqMeN9PhkWMdHpCWFWbu3TerdcZAYyD9FtD/xXi1xzZ1nfHz nevY1w6Jrw2E0Di+1zi5UEwbSFIcEoOvQzy6WjThsTZOUwiPSF3bqUzmoVUbvdGGNPqAqttY YdrCOmma+hA3Tpc5jylM2bo1bUrVsk6iD2gXbesfgRVVtAiS7HeuDYyNSbvHv+/77vf9zvnO 6x7fy3ZBEv898xIxlR2X5jML4JKz4DEkf3+VXts7KjkYSVwitpOpsyclypb4ahMePssvMD+2 wXk+lY/wqf5SX21v4h7+CTsBjAIS/wTlY/4x/nPP4XH2QsaBXmAUOAVcAJz8HMpZlI/4R2B9 yGqAOLAV6AVGgQuAi38IqfAPxOFgS2HHAc4/gFT4+xjW+5BevCESP8PPoGvvZqOragdtI1JT MNTqgrGgomD4y2pz/J3s5dvVHP9rvxZRjyeW89PMAjiSnUbjp5kGtAFdwC7ACes9WO8xE3gW OA5YAL48IBVA4+PAm8B7bDlgAG2AzN/OIk2On8rqzWqijL/F/8gWYFIn+J9s/SZ/zdZv8D/Y +nXoIPQ4fy0bVFmiGHGGOgq0Al2DeBH/XX+VX51N+PgopkeFrAHiQCuwFTgMOPkoX5TdqfrR yDAbx7mn8iz71Na/ZC/IzHhYNfS12GOaEHrjalgQvVqvzg39yFHcCqEfeg6WEPr3noYlhP54 Dywh9Ef3whJC3/kwLCH0jq2whNBbN8OCyPGf/aZqsRptfYS0hJfvwyztwyztwyztYw6+TxR2 2SH69pPs0qWYsWNG5PalqjlE5giZG8l8gcxuMveT2UNmjMwtZEbIDJAZJNMgc5gaMBUmGa/e dLvKKCdznMxXyMyQqZNZTWYVmRpFjRwPZb9aZ6ukrfoT4rmCXr2m1os+hjCjIWzrEB77UchT wKx9Z4CkLcqTFwaFXtS/NJ6/v7Ox9rHE3XwMFcewDGPsLODAAo1hG42hkTE04IWMA1uBk8AF YBZwgr0IHT9sSy9kDRAHtgJPABcAp92dCwBnjxW6eMLuWE2h063ijo+hLEIJ8ZBRqQSUiHK3 dDhA3iC1BmeDPMrK8L7O/D7Zl6OSgS9KvvyihLkTbn6IH2aVWIhnC/pw9nKlmqPns/qwmphP P2ZBB3YdrWI6VUM34NVP3N/FArLQ9SzAX4KuzQbuQzVvVl+mDlGpqDWgXg5Mqp8GchzmPwLD 6l+0nIOy6p/heWlAPR04qL5ek5PhGdFzBDWk2dTBQIP6yrhN7UHgWFbdL9SA+p3AOvWRgB3o zge2ZHBneNWNeod6N9prCWxXjQzaHFDjgS1qLM+6S9QZUJejC5G8uRSdvT1gJw0H7Qa/Fs3R Q8Yy1xFXu6vVtdJV61rmCrlUV6WrwjVP9suKXCrPkT2yLDtlh8xlJs/LzZ4zInhDZfOcilDi /wgfIbatcCEh7HONZM7uYdZcKcVTm5opZZ3cwVLbNevSpnCOPBs6rKJwM1n+FEttbrYaIqmc a3ajFY2kLFfbA+19RIfS8Fr8+zlim9tzNCtcByos/9r2QUbkO/BMhdBLDjyTTrPysr3x8rh/ jW/VV1puIboKMnLjKr/JrrSOpDa1Wy9Wpq1aYcxWplPWDzZpne2DdJH+mWwZpM+ESrcPSmvo YnKj8EtrWtLpVI7us3lMo8/Aw475zObJQaYJHtPkYJ53LM+rRn3wqoQCz+1m1Tav2u22eQ4S vL5MVbKlr6rK5izQWMbmZBZo/84ZrwanutrmlJls3OaMl5mCY62xKYEAKMGATaHbWMCmBOg2 m3LfDUpNgXLwOuWgnUmiG5xAnlNy7hqn5Bw4kf/36m6ORKi/Kb2jM9kdTnaFk91Al/XU3ofK LXO7pvXtSIuAZkl61/YdDwm9rdtKh7tbrB3hFq2vqfMW4U4Rbgq39LHO5Ob2vk6juyXbZDQl w9ta0v3r2uqjN+U6eD1XfdstGmsTjdWLXOuitwhHRXidyBUVuaIi1zpjnZ2L2Xu8rb1PZs3p tZ153c+LPdivXRWhdHOZsmuNvXmbQuX7K4Yc4qOxOJK25oSbrRJAhO5I3JEQITxTIlQKt7cQ Kt/fFKoYol8VQgrcvnAzi+zek9nDypNfb8n/Mrjg2r1HTHheRjL/60IsaRnbWjK7GUtZSzel rPiGjvY+lwveLjEkq/Gar7g4mZs9mXfeCWejcErSdaLwxYTP7S4Q/3v99xT0WvEUmHy4n4wg 7WaZtGQFU5s5joLNHRhrZ0f7EF6XxN9DJo0BZihCmWtt2N1meZuJ8V7D7j0FqzAPuws6XwtV Mtem4/qFOjiqcFBBFKHg38XFml/lNOl05fhRYy4rckxKzONyTBJbKDuLJrk0wlcwNx2lO1l5 RLkUm47dq3weWz8dY3HYylWIFctDvpCvGgLHIruqSSevGkXsCtMcJ5GLWTgcDxcNIZ2b3d8X KMrxE4Yux5ycOT3Fb0juxqIGR4w1OBtJinGuEdEbHk9xT+jnz+PEQrIHY+uVKWVycnpyUjnP 4vH1yvTfcGL1F2FDkRJTYukVy+dKvjqfJN1VN//v0bP1vzhFj0puSs4MX/1i5ocTE+J0/vbM Bt5V9C4+SlcbnsVeHN1+l6woOarrZ72lMrThc/WWbmGSImmSJL3s++nTYsAPTl+aUi5NYbRx DJQeJJ376qMro3VOF8p8hejsj95a3zHS863Fq8MRisxsGKEvqfT8mekrb6efPDL82xl1RvuP /HOW8CUKd3sUYn636IGnVyLRAy8+O7Z4S9VSXvqy/9b554aZr36xjlJXtqBsvsKneygSWbR6 8eM9Ix3rT81soHP08cjgkSc73rkyfeb8zMUZGdlfnPmIvssmmIfd+2sPFv0lZ47aDN2ecfJQ jHnwqSDFmLPB1djKtrLH2BPsOFbseLFYBazB55PKFKaaxYXEckxPkc+/asXyOkz5PKdr8cqV 0YGJtvtrV62UJia++ZS+fuG2B5A3QTn+MP8G9tkyY+Euvkvi/2K7bGCbOM84/r7v3fn8cWef z9+Oc1xiMFBDEsin1aw5NtDGR5qqfBQmrBSIgMZMEAy0hEBoFhIIAcI6PgVdYDAaREobkmIS WmiLYESbti4IibJ+bILAWNMyLcumQuw9r50Akxb57iL7ZL/v//n9n+d/pbgUftKPiJdbAzd4 2DW73FDlO2GpH2WXDkzJQVWwyfwMxzQyEce6umjtuuHUCKtn0DjNTehii1NLPIvYVvi8lU2u cigcBp0GUovq/n2q7ihxj4RAdwbNvYCYxJcd9hCJJb7UVHvoAIMJ8yvmLDwmbUDYDneDMYB+ 5j4i96EebfDj7Llq+OZiaXBAStWgkcsKhjdLV2gtgkEHzsW4rSW+0MN9872d0j4/cY+1cpeh zumoq1OneiRfLPGwg6imjxJfIyccMhwWyBRLWV0j2W7abrlu5gy8yU1m2OY4Znl+lDbPttix 2PNyWoSPmJbZVjkinlfTNpLXdRtM1ZZG3UF+v3Td/Tm5qbtpum3xehWWsyui6IoatAx/Xo4B I4NkIIaWMdYogr6kmeFdFWmwtBbl2s6kTEEgKlwVpGJRuXC4CoVREf3DcNgkuSB3qtMpA1w6 f+b4gE1y5k4tsEoBfyavmx/pa93Qse6HlX3Hbmzce6GtpqatbUvNrDDpwyz+wZnyc/HE5/F4 /NP2g+fx0fiB7x7ilbjy29caaC2+AoEegTZGFNVURhOteRG2luwhh/TsGRYbkI4jjIHDAsG9 xuTaZbojhKl/vAKniZY8bnRLORxWOY0jnMfUjYvxNpSiqCoYTO4t1aFKXCFsDdEdonAww2/V 6fh8IDWXPOqc1jfvwF+z17GbXqgZ8+6Pe8vp+oqh3jysT0H3tILnued1PdwlXQ9/TX/dx88U FgnzzBGhwlwtV9t2yBflu967aQ+9wiXTeRtJgySeLimS7qPEQ8RDgfVwNSQeal7FKOl1ul6f 1+7zefU+LzCn9/oYUZFi5MS5MiuGnO7uEhU7h5QY6dEsmAjGqKsP1kPriXvIm0hFEi7SBGtX CSknq0ktYUk3GQtpfM/7qYICnUNBCmmyKZcMDIfvWGW6dzg1mrOCZgA25Vc0WuUiFMbhteMc GYFCUKSgID8Pyps0MtQeLA3NTcez/ONC4hr368PfvXNoU90RfMH2n8/6hn5y6pPji5X29mnF yy5vuXJ3eeStI022P9x60L7w9MUT25dMASUXJPpZJygZRH3aBE50ijPEBpGdYX3FuiGNedm5 Sqq0VzjXixvtDWKTfUfaSdHIqQwN2iaTIJpZHvtFAVOBNPiyHuxGE5GI8zsFwcG6u8kJ5CEr tbEOxcexykRRjparq1WibuWjgaQHAhgFpAAJtEx2x3BRh6cPd8MDDQJyTE/NMCmGf/H+qB8G RxwxGE6ZYhj0C2VDm6NCpnQEikA5AAlX2Qqd1BFJyfjCJ/+Oqkfl4+kZ+TMDCzrH7IvUnj2+ OXeOXTZFYw2VrzXbOzMevPtGb2R5RV1L/P7NjxP45+5Dje/V1Ryzv03e2Lysrr5e7bq2oqOi /EiW8uHuy/F/9cOKvUCnBHPUiEQ0qBXIC4WVwmGhTbgucHOYOeIvWUYGtpCgY3jOaGJ4JAii 2MuwdoZhGRERQWR5pof0ID0EgFbNiFgWbkG9RjZGlp/nOKOWPibPGMOFmshrmf48fmtGPt9i IdRxomjPQ0QiKmFIlzmGm5PKfRMG9YLBQUCvX0r6DaLBULE1RBULhRqzgiyAZ7FYQLtkBBKh /8ohMZa4oZlyQ0zm5BDDpqcX02iyCJSFezS7oJlCwtaXQoIWCAmZPrhODiXDyyIIGPk415rr 8FsZKyb7h+vJ0beuXu2M5+Pyk8wHj2edjB8Da+wbjgA0tA9ncL8BLz/Q0md7N6Y3pe+3nbJ9 KtwUbqfpDTa3+TkvY8jhckzdYFcG0JNsRodss/WaLXazzW62iMCfZjMbFYdmboWJbLZoDuxw +GSw6XkLi/som2Bezc8qPtFaLq2WaqU9EisBh+4kh26M3JKbuFtU+SLORxa8Dygu6jB3/T8e x/wvj0+JpEMXOCwZACLDVjhoGmrUZwU5EBclXZ00NK4KPwsm0GjLcGQwQCRy2Hno5IH5HzoO rarrbG9+pXlC225ya/h8Wf3ey1i/btfgb4fxVqlp55XjhzvKSpzkH2fiGxbHhz67trfjazrV SkFNB/g5HT2HOrTxEQ+ezmuO6Z7p6k/leWqEqeAr9JVyhbpOv963Td/gu6m/4bTyYOjO8apf zaDOtk5QNPElkQBKabivnGoHJjZwShqXqdhFmLdFmgN1jYtKSe0gG0mSRKSWSUYqloJDmrHE Ve5a7ap1sa4YGXsuODLNBkaVGrFu0rLZ4YFRWahleQhMdHrpeOpQmfY3fyaySoXUr9j+jGrM o3PuSTMjC6bNX0qmXVzROfz6H+v/Er9zdMf99i+GC8t2v7j2xPFN1afZuebKnNKcF77987JX 4//+U9PAFjwb1+C2j9/55PEX4dOLYm8fPHuWzpQl4Fondwo8u0YzXxExCy+iZw3gSNrucwhm DYIYZRhCt12WbPAM8Vr0UcPfURkux+WEKYHLalwLA9ZjHqGE5uKq4tLBgRelITrtaDqhvT9k DaUaPaUBUpQOMTreXyDLhUuYrub4wOwCywWm7p872O/bm/fF5fij2O12/ABfO0KfBeZClT1Q ZRfyoxz0lVaY78QTnTOdMwP9wt9yOEMO3ow24xp2nb7KtFZYL1a7dqIm3Mw26N801QsN4i7X 76xXbXImlLvDp3rpRVWz6WWyGqAMKBNVASluJKQpWa1ZOEvOUHTcBEUWleglAzbEyApNCkYt mgoAQES3SBZiieG9H0x1R9+DfAqfd4yNOp6kGofmII6WKU9SDXRvKsvTNi6HwtkDI91oBIcU EmurIGYGAvl5I9NutF0jeMdmf4aGZ9HAlWtW9V+6/CDys8Zd8aFbt+JDe5c2RFZu27F8xfb/ cl01QE2cafj7vv1LsslmE2AJgSwbEhKTeEVAfo0lHRR/EItKg4CxogUVfwrotVeqVRSKVm7E c6oVOxS1KtTSaksdAe+qHtOORznvZzg9PfWuRXs6w7SetvWusN63G7Add7LZzc5Ovvd73/d5 3ufJntOyqL6ja9uW40Ss562q9qs32yv3eyb37zj7CLuUc7vPw6JVDdufX9HUMPqooOXZY1u3 vdcxrhZjVMXhBb8LTM22zhMCjjKh2FFJrBXWWVc66qybxWbrLrFV6LSetd4VbkvfSxHThTah SyCyPS/QyK3QlwPn1mKXaGmS+Cz3vMJVcRhTFPxrYRhm3QpDxffCLMBilJmeYKfJCva6FeiZ HqfWFDAhU4vv8ycH5MjPyWgCYiCkaHaVe55GaVPdCrjwFeDcmk2qiHRBNYNRamqru4RN5Ys2 F6bD9L51p0ch89nukVfr7h1+/yoaOLrxVx91btp8CC7i69bP23KlWm8JroGaKzch3yp/hd3M 1/LHH3xKTD14uv/tZgVhCPRgmL1OulQvmxmQSArQjBbRfpLwQ5rEXiEJ5ACkaMhDmnE3U6Og BSt6tTHU3ojAlkGxjz3YNhAlg4Ojx7F9QGHfpP43BxoDSRvY7exe9gj7LUvhTLp0Gbo8XVBX oftE96WOYXUco6zJ+Gma4kj2hE7xWA7KT6ph1ANA0Yyf1GWy2VQSmUMiiYTkIeNESH5sscZU c6XM0bGxET7stNQgAX9RgTSorZkI9LHpGhy3XRNRT5gvHH0p5h499j4iSAANgSTcR7Fok3VT LFpurYhFa/TlHCrFohalczM4FBujYUjAu00mYPBEQhH3zYcBhz3B7o/XxfsTEiS/3S6CpeJ6 3dLoKie/VMLStcpRXBrmYGxRHygRY3s4pprE7/1qjwybVOUUwgcIhSBGXEZ6htIkP+klUtkL hxhlV/AKFIVkZ1/muy9vaLX0xPwwcBmC0u2L063ozCBc7TRXFWRP8x1dnr36nZYDwuDVu8eW Hd44f+6ytfJ+tV4vyguYIWoIzALF4IdAMWnnJcFuT0wzpHIzuTmWGfY8Z96cWcEirs7DCYke 6NJ6bS5PmjU9KzcxaCmxldmDnuCckmCFpSKx0vOStc5W62y0NFibbbvsTa4Yji/kALFIIW6d 0T2FLWQRywh9aDbIBfmorzs3m9DFK/IgG0q+ah/y9cIC4EZ9p5NmO40MZM6g7QEjX/g0cJrb jc4pfDUecL2wE8Situ6cTK8Tv68FDtQW0EppMC1mcXFzmOkLRsYUSRAaeTCGmwSTW9LISAgT 3DBuj5zQME70OOsroj5RgZ/CbaqNi85IJcK4y0g3p01FTkcCiaIizWSq5MxIpWnSkeB0upW6 mIE9hYwWonhVK7hdMHIcz7hUHCJ3PnNoQUnH6iP/qS1uy0r4uEX02NKCtY0n5K7Bu/LmoSG4 9ztIw+WLP0l9KL9374a8U36YW/RCHTwPAw/hrtryL05fmflcpEEWthVlbqqZ3VQeqKkKHMkv W3Wl/h2Y014WOjhW3myMdU8vhIbdx2HCB9fklXe/k9s6T762+uqW2ltv/vbag+vQCKWBi10D 8o1//cHrjoHzdr6V2zBQuWPfMy1/xB3/aAyDrARrZAZwUAysSOKn8Cs1q7TL+B1EC3+R+ow+ x3/LsxqqBAZRIb+KPcnf19833Oe0pJ40kBzB6rQUSWILoqEZRo/vNbSegQBIjD4SP0AEIZH6 SPyGVqQojUgT9BlUHdACjf5OAEGEeiGL6Z4NmPUSqGCIhYXkJfImSbRgpJ+BMMAW6s8xN/VE ix7qld+8kbnEoC3MVgYxe41/uxxmghh84o8FF9caw2PKteT4rbjYKrpGmqinfFj4NT1l8Y27 Ojzzs5r4/n6uv7+JCl8x5PJPsovyT4oLShd3k0ZCw/RiRwoePVT4ugTW1oQcMBU6CDsRYSdc bpohUOqf0eLrJ8YOHvo7vHcgLyEuler9Xx48K89ApXBfz8u/3oVZcB9mlDs4vyZVCdYHCkky zxF0VDo2aBu09GrrL6lqLSZJajtLuwUtYXF7RcGm1UaYRa/X4wFxNhFnKV4UTUBjcdFFiS69 dbJNlKDCziHftCUqmWAZg1VNwciEncUnZhJMLP6sJFOW4sfCdgwzSqrJ/jO/xSEHtKeEzazL ge1CSphq8P0+5OoY2FC5snF38dbzzfJeOL0+c25+3rY2+Rpct9SVW5pd9Gaz3EX1lvRULD2W 6j67deWpZcnEQpNQWTDnRc+P7Yw+c03ewleSFU1X+ehr6iXMqzZwJrBsBaqy4emSYlgBqsFG 21bQYGsBrdQJ4qihh+g2fG74Exi23beZOLPNZLMRXnqSyRsnxc8yBCOLo4Ixq6g1tlfNu8yt xAGuNa4Dvos6TENcBIgEVj6St5LYft34aFIWVCaze1IWbwSQjI0Q9USsSGp5l3EucEkQQmt8 tEvSQE2MuGLJBGfgJIYKJmRxmId9vlCoBpNELYxWkY+zY3ZiCo5mXAohK8SgTGiy+8J0+fe3 RuTLBz+EuRf+ASdP+zT1wt7Or5asu/36kS8RSv7mx/Nw/V9uwedO/XPgF+2/OSx/s6dPvvPG WczBbRiDpbhHjDg/DQGXFA9zNeHCm3jRCDQ4UKz1rPE2frzu4k91V0bJ46InT8l9JZBOxDIa WkNpSA1Jx1isFkSzOr3OoMOsJkQKEQJBxxLRdmjm8JdFE2eHgs5kBz4f3qsXH/VQbZJoIVrA sh/hFkm0p6SHewR7Ansb/O+J0tdKNm6YX7dnsFE+BbP2HE2eWbB/7fwu+QuqN8o2b7l8qf+4 LHeWp3SlJ8+8c+z2D15R6YLDGAv/xvtkQVkgiqZEjYZhAEEqG9VpRRZoGKVmcbx5KlNEzJV0 kgHprAZSO75r/bSycKH8BWq/hwoeDPuebPjkKTj4KPv4eZh0jrYRvtEhooHq7ZJz3pcNXUok HTiSRhyJFuQHvGoku/GwmQgGB/K2hCQWISv7eHXdtCVPrD4cNhCKrnty5Q7i+ugtdHKsUFk1 u2us8v9UVw1wVFcVvve+9/b97fvdTfYvm7zN/gXDTyCbhKVB3gikQkhBOhACbEnN0HZoowkp WNCWbctPQGZasENhRAlabapVoIG4pCo007FI1Xa0E9KpUnRqURwcpjLIALvx3LdLipu975x7 38u+9+75vnO+A7/QDRw4DRyIo3F7YcgbKiOdSfyQ4MEmE4uhiOkjcQR3xy5fpcqAzBcxTiTj MQsyKLGSndDjbMwmcTKcsCQsBRJda+6itk3PABTa4BFoG1eS8TOanSnlPgxa6QAaC9hoqCJY EahgXO6EHi9LVCWEOJuIxv1KOILKNU8ELvZ6LB5m1Vw8gitkwIjXgEOlGImgGAMHQIqDFaq2 au9+KGqAJQ1x4/9YUu7jpxOgiYt3ORUUcGQwS0j3C4X3B8YLR04O4WUfHcF4f+JY5KvDX98x +o3I7F2Y7Hvm2hfJvNdx/tLGvtP4ofEx3Hfy0dxLdT3Ztq9sX9p/5O3CzezDTdigkXwFuFPt YOqx00ihlPeUpVimUpQGpPclInGEyAKQweJ5VyarYIXIxYBSqJXBtYArS8GWskzpVHoU9r4O f22mV79R65Arc4NGFjA2rxkaI4dhuLbegEDDiMLxlVFya3Q07+JG8j8mq2+1kKF8G/z4GXi0 Z+GpGPTSKYonwsHthmbPTTm2PlW00+qKtmZK0UbjRRuuLFp/0LH2DEVPWdyL3DEOsAC19QU0 gI4jdgay0TL0MbqGONOCxRfhdj9gxzqc1DB/7ao3slBZMx29G5vzmbtxgneZR4Fab5wZpdUK nrVp4jLzsFOh2mx9PXnU9STZ5OpX+g2XSKDPCdoRtlITxYQkCQk5Y3mw5bE9yzydHtaDE6jV HHZueFXP9N646mjxq1fnUV1VbG8gbcDNvI7Cuu8Y39O1aEPNaMdbz731ezzgH/zW/L5nmM/u BHLnN1yk0YRqyS2n0cQ77JlMdVNaEOckpQZXo3S/1M7sZC4w/GbpQ+ZDianh9rJ7uJ+wVwRO YnEDO8YSMQdNnWhGUoxFD1AGhtxpk64OwVwoWZbasGPPDpnldP2iPTcAd4rH5wpiIDAX0CpK oiBxDMtanOTlOJgBgFwgaFyShDjCYsLLAhIkhsgYsTkyx9bqODzAHefOcpc4llss0DW5jscW SJXjPANCdqcty1YpkQ06ugX6wt6rtLeiVGqmMGtupgPYSzWLSkULB6qFBYcX9GahGTSKHzRK CDTKacROjM/ucEqU84GI24ZYDW8yNZBm6agOpQE/F4fLwS1Pu+iLymZaqPamWdubpi9+Kg5u Wbr2808HpTfu3ZhBvQAaChQcwfDljQOjZBzz+UPkuQmUv3ENED+FXMj//M5B8umVAluKHvsF iB6H6m03JsBCDgm0Z8uRV22VJ0wplbruKV+fZooZvAjKSBnc5Y8AzP/8DC48iJBLg9/T8SZ7 GyKa4CUhgd3s3uk+52ZE9yL3Io2ZwsaVqeoqZg27WXlK3aUIMuGEtNKoLiWtzALeFtqUL6nS QXKIOcAfEAaZV3mXSTRVreMIBJYIbkWp4wRwBfdybTm2QZIKgijJsqKoqo4EkXSaWZOYI2QQ KXjmG5wl5PBMW3KLkmW7t8lYHiErQTvLcIbkQMiKGkaW1qNjPUdW/sLiOrksx3A5Mjhk0NwS gLhDDfHDqztaFfzg5OSTDChXQIB+z18Q9CxFw66nHQULBsj1uVT9FXJP3EbCxBho+TFHqbYe d8O5GgciysTNE6pEVwEddPrBcCStTo2klRy4TWl1VpPjnpoGq9NKOOgArQvRd2QALvc1NuEI 5DocxcZBHMNr6soDDXgd5t4srDxWWMWN3P5s35eXfZe5c6uFffd2A3vptkWxcBiYXOVU2Csn TJlmsQZItgLtB3gBiCRA+8oIIkuIyAssY7lcXMaSsQUdYqfcI2dlThag9Dpp2g3/WarBxeRW 6+Tm3uuTydlp50DTs9OLG4QpG04Kdksa0sDZ4Za0YM8qurPSPFCEasThALizii5djTquLUfT vOqF4aHz68MecMNFNwxuGXVvnpjkTIl9TlHsAAhjWhiwcfgdhoy8c6cA2/Msuw22Jns7C0qv CzTAX7gPkIpCaJvdGdSwV/d6Q75QiGV11iv75BD7mm9Y/Y3K+Hz+ELHCtrHUs9RnB1dxq8R2 fYWxzrPat86/Mtge+rbvENEDlQxjVspiWcICARPMhnFYS9C9ClTcK2szVNc6yoB2AaBnQdR6 dNq+UonnVOwmHdXPQkaKgKxFXbgfN76LW356sjB85r3CyOA5HL7wEQ5t+ee+PxQukPO4G39v tPCjP39cGDh1Dq/+deG/hfdwCoeGsPydwt9RUdOyeYi/gvyo3W5YbzzuJa16q3eNvsbLyu5K oCDy+Ytqy0wIQSuI4Rv0K6UcEbi3tenN3KCPf1fmOWW41Mv4KkGCk0jEAH9SoZIp+9ue2N/x 78JvC/34m7/8fmbJzO2F3dyIaq4f7n6zkM+/zuC929Y+X6bAkx4FpEIbA89ZjZfYmimr2Gys WF31iNBdxZq5ib8NmcEU2GtD1cmUQefhZEovWa1k4fz4UDhRPA/X6yVLz9t94MTVxRWLrQfl tRXdFRvFp9Qt2g6pX3tZeU3Laf9QL2u66nZbhuY1DM3Q3KIZIpFgueQyDV1xc35RLPcFA5U+ H4pUO3vm92uaKlQm1MOujBXriWVjTKzaX9q7KK0vd6UqxD7wiZ/2CDSblLYQlqE1hKYQQ5ez S51ey0GJoZs6WQcQVRC2JNhaWtPnGOYcim/c66QRFWgSDKQNIJIJQ7Ur0joUFb26CsYkMzru aTWhmfBEmekEohN1IkVDFY0cJXve/t3W839qq1mxZOL66IqvtU+LtP4VH91x4IGXf1io40aW nttyeCwcjz2wqdCLZ27fO1vm85uY+qYt9z+2k2aZtROX2X+Bpq5DBftwF9PF9jFPsmw82cCk K+Yzi/gl4YVVC2ItyQeZDn5tuL1mt0etURIxEmOS8UYtFV0QXzhjtbUyuiL+hLxBeVx9xLve v0XeqmzVntY3xfriO5k98m5lz//YLhugKM4zju/77sft3u3t7R73sXcc3AF3x3EnggLCRQzr B6JGBGOtGL2IjkbQBD1JqG1ji8n4FVToBzaJY01qmlbrB4oiVTta6ySx1uo4HVOc0bYpMdpI YyM648cdfd49NMlMgPeDvbudved5n//z+1u2yOv8rwd+at5m2WbPDPgls4nNAoeWzhs4hsYc Cviz4RoYifT8djjFAw4qX0Y+VIvq0UrUgTjgqC4tkJ+Z6aDZzHwhPeieJgSpPJTnHp0VtKKg 9Tt6zY56AvX9A/I33aiciPXDGFQgaZAzhSielThUKhaHik4rzcRFo4c9mj83GCwpHjOmCMI/ 7FPtNqeDcerZABLzB+cfNS/4aM2KPbNq549NvjizcemPvvz5rvvr2WOWfbu73o2Wob661h+s f7jjw+Sdt9DHctOWOROaJ1UuzXEujJTuWrLij4sb/7JWatu6dl5NUdHy0NgjLa9caH75JnyH Qqj7Y1BNBqpGM7M4E8IDdopjGaEXN3frMIDQUc6HcAGNaNgfQSkch1f5nrdSNU+Orpzoj10n RzZV96MKwVmVEG+F05IZzBvJdNa8b9+DO+QUvAuqSjyAjYprxqCljqnjz/KMg7QOB7SOYmYs P5mZxrdY3mdvWAwihZVefFzzcIItiGM+B/I5ah243rHS0eqgHWbdX5HPCvBZY8xOeg7kJBIj RgsgNyWkugRBlSCA25SA6pyrI6/C1J9enHz4t78mH6w8XbVvzeUe9tijg1eTj3ZtReabdM2j QyePLDqNbOTZBVCfyfDsRuquNqWARWEqRAeMBWKhWC9u4jcJHeIp8bZo8om1ImbAymCjIPh4 1gaeBujeh1kbxqyAMHvTZwRaWcKjJZgnT28KRWt51Mp38PA/QpoZa6HoAoza8U6MMbmi+Nha FhcCoXQAtt5mWaCUjd2m+t+mKCXeH4tHyFDlAYL15W7XgFpRTliEgCmwCCwoRSI2oI1DlAXC 9r9DghWRBWCtd+i/ZfoPgZIQvG2MDiXU0CmdW2OAGbEsVJRijCKExyc+uoTWjPRm56PNHyTA nzz8uHXl6tVMnu5TXBRlaCE6jTZrk/KooJJnDapRaowStY5Rp1JVylRrlVpHzVHqrHNU+U3+ TQumGUA8zgCxMppEUTBLFotoS7Na7Q6nqtp7h8q7WUr1kVW0KmTVnrMDdQDhY0APG0KUyvJ8 pl212e2qVRSETLsVtlZFtFh8smKTZcUqiLxqZy2KDOeKtYssrcoWsEs8j0GnVatVUSje7XS6 5fECmkn5KBFmOwyNYtHMHp8PIeRy9aK2g8Oa7XZVJ4AIE25XQp1RuWTS9SfK/ZgIiWxD+SuP B3BP9df58JsLKPEGST5zBqbyM493X58gNxbIjUJSaDWqvUP3UgkLwMXwVwkbZk4JrnSLGquV 6TlcRRKYlkpgmhWWtCIAxWAuZ0Dol8kffvgPv7vMiJz/uVST48m//qdk0/HkuVyD05Y8CyVR 8YvOz/30tYQ7eetO22F6P2BSbLNvSdXDXaQyuOHKEFFxD9hAmhkLVu6zbquTWLbPNAk2jAsm mkwC6b+q7vL+rk2GDROCyRpk8viwsUBiGlAD12C6xjEsQ9McbxA4TuBowWc02YxGE0dzAu3D CGoJcaKJQyBayNSLXZpgNAo0BgmTerGqCaLwrGZsNWJjLzqimU0m0UfRz9bgdr2ijhxCRMfU HrN0OotUUeQeUTKQ7tRynSgZwP1guZJK4YaRER5qiCWZIpsNEqREhumZLieE2gOhPsyLgsgc Gxqk6KFBpNcSkXykd2dBd3swwMteO+gijXfukwaepXxVWQoemzh3C2XVVk54Hnk+SRzFL9HV ycmvvtrcgQ486k78jMS7LdmIVV25yzQvQ0cQllkuQhms8P0N3H6GDehCvZff0fCYzAbLdX0m /k2X6DQwcDlKkb0NbenrSzYaZnbe7+sk985NNqLD+r2LNQ/DRgycTOMIhawcyyK8n6EDBmqv sP05uPHgt9wXZZUAVZdkocPJ5r4+tCXZ2MnldlJo6F/JRmgFn1M05QbHWUFhN0u5mInjSSn1 Q8ALqgF4aWgbXmZ3svG11wiZThu6wXiYp6kQVYoytK2CWQi7zO5wnjkcBt9oL01/Kjw1HDPH wsvMjeH6wjfM6/Pedmx37zbb33ftCfW4jofOuC6ELtmvhvhJDuR1etXIiHBxlImOmMpMGfFd fm7kBb4x0iJuEM+K9833I0ppsYQYucBf7BydZVMX5K3Iw3meAqlCapd2SkMSu1M6IH0h0ZLk oZ29eI/mUDttHo+Bqsw1jvbQpryF8kIqkOXvxfM0OVejgnLQFywMHgiywVFRovTezJziwuip KH4niqLOgJpd4D/JXeCwl6vgMDeqDHIVB4wAwxS5FxuA+H76Kelg/RUDiX4QkAJ4NQ6rjhTK MFMgYgEDhBV0kijVf0uKcwlLGHKfxjpaOOx2m8OZE6Q5gwQUTlofvIkuX/z7ZQdOVDVPKVl+ ZSkqqtz44+9ndKlNFzdt3FMrC87sEx7nojMr5o9+qbHhV8GM12dP/t26GWtn2CSz2x8wNuWP mxtX423PaAunjVx9++G6cWXoasgjh6oLptTPqxn3Pcjgesgg8ZYylUFd1vYiVrT42RK2kmUr vF1e7PVme4o8EzwrvR1e7qm0cke5e7pjujvGx8x1lpjjefcy/kVzg6XJ0eQ+5e0TrzivuD5J u+W85fp3xj+9Q16Xjy2wFNgK2QqLxk631LIvsFcy7jIPZFG2SwyHqXQPqJvR7pFMqv+iCckm DSxrq4kxvQzmjyqiAxifQkB976AudBsxXlSBahCNXJlVpSmJj68qr5YTg4Tn4jpMwJ9C4p8q 7fgqKp4FZaQAwIG7kamc7Fwa+K1INziQAJT/m8OrDi46ENeSX/7hxHJcPPsnLXt//UrLXvZY 4m57Tfufm5NfJC/vQNtOzm47f+7iB+ehAmuHbtADcOrd1HmtShCR1zMxbaJzVtosZ31avXM7 3k6/bX5Pfs/9f6arPSiK+47/fru/fd/e7t3t7XLH4XHAgXpXFe942Ztw1ohjERDfWK8h9RGD bQOMGqMhYk3UtCTDOJOHbVqwpo55GAFJq9ap1+r4R8cZtNXMlMRHJzjVpESmTUl8AP3+9nwN w37ZvVt2f9/f5/t5OETVJzcxz7JN3CZHs9quHnR8LP1e/tjhMB27HJ8zrDPvKe05bbvGapiC df4MULKFqBE1o07Uja6hEbA0mqaADXQHFCErQJSAhrUCZ142vEWBEgkCSYLmzQ94CwYEHBQq BUYozo6fsTmlZRgOrdWL86tt4cFUeIZbvx5utT0wYNVVMV0HI5waemB8sUVBCrnVTe3uQ7dL m8UmenNufTQ4/k3rzVcPfxY84tu+cs/7777c9Dp+xfrDAM7B8oeY2XFkf/aGH5/++yd/+Rkg qwq6dBWQ5bKR9YHMEDWsxtUnVa7EKAksZ5bIi4zFgWeYNdxaabXRGEgHL3KXPJd91z3XjVvW l77rNoLMYDDip7Cr9lMMCtOYAnWaOYspUauZuWqVMT+wXF6mPqNe5/9l3sFfO3XsZZ2KrgGy FMGFAFqskhXDKOzSwrp+3oV1V9LV6Gp3EddGd8EpYUC4KkwIhPauTmAF36T4wvvAqhkGSCV0 KjlDtkulv4+gRYc6VEKHGqY60zCAGTYeQYstX3tm+6VNTRd3Nr45/ehY7oebNv/u0LYt+3f9 puPugS7M/rx+NuO8U8W4z/31z2cHz52BnlXDNE4CZHmhZ1eSa4Io4GWWsikuJS1V1rIbuOek tYqoIx3rTJH7H9wdY9QvFLtn+YoDs901/tmBevcq36LA0+6f+J8ObOG3eEeZ0SwdmVhTLWuh SW05awa0Tr1bZ3SdZAdkAVHgSfgND4DLSqq2Vy+aGu9RseoPwtnRcGGc1mQOZcYgDpoxvUBI FkyNP9ay+7MYqRkbqtVbQKtbIrazHxuygQby1pLAlBNp73CKdq/1Adh0FJuJXIYQsu0+DhXa vMj+8ET0q+M3x29h47NL2Inv3ZD7XlndMTbI1DvKl7364nt4mXWgHweBCxx48viV8dt67pET 6/Ebu+asP0hV0gPy1A5p1kJHk5MMCWu+6b4ZvqSv2fcrxzvqe6roVyerPb60j/jo6ib7g/Ec UWUdWkDGXiZieAjLI7nLwMaEJ0msMEEss5d6EmhJcXmc1qQcCMY74VkHsnwn8QkUQqNYRtSq pCIRak30BJj94VTGqoD+DoO/LJ4x54Wkobt4SeBFkBRdcmcjF69l4wiOTN2xA0cAWK1UoWMl 8TKaO2EO6Rh6Y2AH+rq6PP6dmxesyi6fuejJgQH2lx0tG+JVy92/lqsaf9Rxbx1g6Hvj9ewX gKFJaCoaSTYqCmdElbCxQJlr8FKOLyeqFBrR/Aql1Pi+UmUsE1Yo65U78v+8zmn50aIn8p8o WlDUGe2OCqWh0imV0SqlKjR3ypLQkinPCqtDq6c0Rtujg0U3Ql/l3ypyWSbvPcb09k8OeASb wfRcCK2Uv9pRGp1HFF1tydlcIKDJc/MCDtn0xsIxOZyVdd7CupW0Gq12i1gbNRxGecGCU9qA dlWb0EhQq9TqgBV9kejGEB3ISK09kCC89kyODY2CpRmmqpsaotVOkC3AYpZlWhntLAJ0MZnJ tMDxGLb+eh4bz3VHlJlzNrbtyXLizT2fjvz0wmsntx5c+2n3n77Yd7DtxUOHt245tMJfH565 ZmVZzy9w4vLbGHe83X6v6duBLR+wUy+kT507ffY07P5uhNgbwHMG6j2OTICF6rXiYVLCzmVP qIQ9NnEtWWD54pbocrgMlsNIC3CCociOsJSMlcYnJJyWsFRrUkRZ8dJ4jzliMs1mt9ljTpjE ZIywjbqkF748As+D3HMetIGgWu+8hRmmjwC6qCWBJkVousxoILXFNtycvFMIO3lHNlZFABoC pEV2oEgKR2IZZTRNryvfZXeF97p297+U3vxRdf+mDQtfS4AM/mdv6t13xp5i9u/etvj1trE/ Asb2wIjBR+AVBdSWTNVJnVK31COlpavSiCQgKSg1S+1S1/1L16QJSQ5KoFUCYVjICi9BIuF4 IvNCmEOki3STHpIm1wifJiOEQSSXnIczQmrFBytshRXSOaocxg+yGt3y1hZPSczLwir29Pf3 ky8HBu56SeHdQRj+id+O1+NZ9ju60b5kDXhu7rskxu3iOEvkOIEQhnAehFWFYQ0HcXGKQN9L 4YWAS+uEuYec6XCoYVnuVHBQqVTqFFbxeYzDoXkPAEmdR6JWp8GyBVXWUO8BL+auePiKrlhs ty4mMpsg6lqhqMvZWHIK2SizCThF3x+X2aiEVRgCoHRX//j6vNJgWWl/bPZb88nNCxdub9vn nL+XrLrbfaZmDWU36D/7LaxNweeSfoFfxq+UWE39LzfKs0vZ52XGzed67AA3ctRdRAPdSD9U N2dfCNkXki/DFZ5AiOPLpHnQHf478gr5eXaTPMh+zgsHeZzPFwphsYIvlyrVOrWBNPArhAap jbzA7ZPO8n8jn/BD/E3hG/626HXLMseyhOF5QZJEOJFEMSzwhiDwLCFhTjY4DtIfnIgY9pfj BVFUFCSTY1jr4/JEKMn8XNu/+DtBepQwYsLg+xDkkDrAm8+h/jM0b92jvgOxgtKMpignAOB1 +AFwJFxWxW5uWoTQAMhBEnTCHwLsgJhg7SNghoY9WYrmVEhiTk6Ch7TXl1MB5WJfrl16QxV2 5msAfQedQpEI3HEc8RPpvlAFTHO6z6TlSp9ewWeKfeawS6+SuTnSALtLb0y6LxMsGiY8zTAS 9gHuGu3Lojf/uzc783WcarDNKh1HiJg4HwsAaPz+zfEmfOrK+P7t3Il7J3HP+OaxNUxw6/gP AAE7AQZlNro7jiMORKmsPM5RcYqXZOqM4kzNC9s1GQZW0rgg18Vd5UgdHEY4Nsg1c+3cBEeA VWSGzRAN/U824fhBgboQToMNZR5jHfJwJiORzFTa5Ntqr4SuYCek0ztVGWbkC0GJ/k932cc2 cd5x/Hken+2789m+89nnOzt2jF+DHQI4DizhxYaGJiUQCikMggMRL+0SkpaEl4GAKhRo2pVC CkOhU7eGl8G2dgKSsEI3tmwDqvIiMgFdWYWgaspoUTQ0If5Y52S/xw6MqptkPXdnn2U/v/t9 v7/PN4DOn0bc8KepaSYzOOMAM8B97vzSp7+uf+gjTtYX4FS3j9PpAt48gyPPBBLEhoBLE/n+ EO4IdYVICLRoCXVIWDqF606qoQ43dsNZSkOkOBDC/QhTXib5iHaLDmnB0Cm8oee/QoWMkBkA QBl8UJepzsoVIBhmMhhKtpWgbXBWuTmlCnY5bBckN7aZHY/sklIL3Z1jQhb16JLzzOxwftI9 D8SPNK7vzH/5ws9+1RNIT139496FK2ZtLWPC+6qXLlv44bHfZCLkp01Ly/YdznSS7g0bnv3J W5kbI3PkDlRLQZdSsl5nkMkvxFPiF7q/y/d1D2UDQzU7Hgq4UcT7xX71tjqsMj7WbrErNhgo 2KCYebNFsARN2aliwvAyVavZB0mninpfJavVLvW42qcyqo4UO5SRwWL7zmBxPhoqDybnki6M FVAYnSxgcY/nimKQOJ7ljbzOIIYlg8WNrbxtpGDRrXQgx7I97ZgwEnGfKFj7wXU36w88K/K9 0VWVa44y4c5jM1bPjm/JrCGvvtg8bc+lzO+g68qBhyNQEzPS0B9TdTYjrwkVhkp2gWER+4Kh gWUTYpmtTClRZ4hVtiplhprWp7l5Yp2tTpmnNuubuRVis61ZWaH+EDs4g968WPec/jl+sdCk W6lfyTcJvDOPMUrQcvagkZZCDoYS44wYGUWjD9B2/C3aaPC+RuEXzi1BlIJbaKMRNN5FwRdK FRsE6K17WFcXyybQQdADTQdU/lyNvoZbpl/GMaBxWZwIlUCOLIugJ1mk/PDr5z7DyqZ7b9wa Gjzd3f5qd8+O9m4i48iu9UOfZy7fewV7sfnSxUt/OXfxAvx0+1ADMwrqYgPKu5L6uSCOEaeI VSKT9B33kXzfaCHgiTvinume1b4OH1vmLHPPdM50L2IXC2ln2t3IrhIaxGbnKnef76r9pnrT ddU7YB/w3vYN+5QAExNjjhKmTHyamSnWil+a7nmGRJNkgeSQR5Wp5FlMyKIF+3ks8im+nm/j GX4tlotJsS2EUB/YNu7Cx/F9zOTjJJ4DiK7lV0xUcS5WtdKp+WCAghxUK5kdmqUjmQo+RS3y I5EpDjuh0BaRdE+Uqv1w2Z4fvNbfuO7WptrdRdKR9RveO7p2zYmhBv2ZH82du3N4/6Ghb96Y VZb5Rnf48tmL1y9e+CvUq3KoQXcb6iWiPPT71H4TiZGoOolUkY2CIelIalVah7fLq0/ICXfS Wy6Xu2vkGvdyebm73tvmvWa4brtj+Er4WhVHE78Qc5SSEuEZ8rRQSxrIDeEz9QvlK+2O+9/E ihmz3QW502KwQ5xCFqelGNHUacWiNWWtt7ZZGeta6X+kTo/3W5ybg9wHk79bH9SCpVxuSkwY IdtvRc7CaOf8M0P/eOnqy+daDmZGvb9hzZFj69cdGmog7KRqXISNXUPbjuz611O6X1++/OeP rn3yEaWJHYBL56E6EtqWmjRWxiKDA0yCeYqpYZ5n1jIGTmI5ljPLEmdGOhabsm2AeK6gg8Ws 3ydjmfil/0uptoqzjyl1QKx70DoA26KbAkLNoRISP263bDlLt9iK6x6ZbC73GMErdhyc2pBc vGTq9OmTlti9TPhAS2XZ0UhFsr41c43+/+TwXd0J+P/j8I3UJsZv95dxM7ny4AL/Sv9mbhe3 PXhEfq/wTzoz53SpznFVhZ849W4ynxAxjnk1zaa5NJ82pYW0uZFt5Br5RlOj0GjuDfdGrJFw MBIcPSFYyy8yrQivKFgbWBtsC+7l3xH2FHQW7ht3mP+lcChyuKAnfC6seAAAUjZvaS0bCQk8 4/KFHYypyOOiwSgvX0tqc7Sl2jHtimawavnaS9otjcnXdmtE+y2ZjxzwDCA/iTiFiYj7gZKw iAmm89iuJOgx5bVICYyL0p4mD/HkOYxMXpEp34VdQS0lqwntFFncbQxG4c4P8kr7ozjqitNv hSPRRH28L06S8bY4iYsY4yDyBa3+W4/hajz1saw4Z0PCGmytzpp+SwzgKjbYmrW0Flvp2Bi4 eWtWuK0D8NikLOg6c6MgFRnjDUDQDEuiTZRFncFv9rkRV2B0Y/0YWLx2uBxlCbiRP2AW2NGA wQURjjfEGDfKFz10aMQoxOUWCk+xaGzrVppSWijm18kTlVybR8KRIsh1kPByU8WYGyh2Gvyc XpIz13Cy2/r6ps0bSkJ7z789Z9r3om/VbDlTKx0X1jRsblSUse7tf+hc0HB+y5UbeEreqtaV 5VMCaij+zNbqio0F+bHKTS+o89LzJgbyPDIfLJ62OV377vffp50WHP4nierfRk7Udhrx8GwC YQrTfalpcNKmQcIRzDzWIUXkYlYerFJnsop+5MdmW0jAw0Z2Bjej3rja2GbsMDIIZkyX8bix z9hvNBg/JI1IxRNOPJ8TCzjkIE11A9QFBpNwSl0AAoX4McWtWCzkpPsMl0gB8ICJoJmAZKcl IqJr1uRlTYXbt/ecPCnHCrwH3hWnrjxIlu/ExqahN3dm9s4udNG9bAPV3GbCSEVnTiMX7IED QiQ+WUlYKWqMttkTMRkHWVkRsKyYQPASbAcVKyHVmUUMJ+5zYme1Kyt7ihiu+y6y2tXlOu4a djEuyLePDQGyH+fj+iEJMly19ji2Dj6iC3AGusvk5JwjZFvKxYgWs9VMICsYWD0LjMEIbmRm pVx4ika3giNCn4wqyRYiEs4GKGe2TbJhSpfcfH3JoTmiqdckvTh37q5Jve/0VjbPKVlD9mR6 3hxfMbdm92ukFMIiRlAQ3V2oBY+XfFCix8gvlfJUzWaplAO8SrB0IaeGv+6BIx45wh2fpjjv qAQqgAWu7qY4oG2kwAJXf0udLChKIB8sVmE0KuDCfCkq4StRBb8ALyCL2IXcf6iu2tgojjM8 M3u7Ozv7Pbtn39lHOF8wPnKodmIbc+RStqQNAQuZFJpik2tBiUAUGheF4vARQ6QkhiQKIj8S 06iiatMCUlsD/jogLZRSRKB8tCWloSKhiiE0jUurGlTq3F3fORtCdm92Z+Zu53bmeeZ532cZ XkZW0BXas6gDd5B19Fmtg3XhLvKStFXdQl/Wfoi6te3s5+jH7FdoUN3H3kW/YxfRe+xT9BEb RSNsKkMyi6AylkSTWRNrQeBs5ICXNcgBJIoMTFa1xnxNY0gi4KeQjzE8wEC6KSUEKyrTJITl WgMbCRoEgbZZI1oOV/YHYAuIDLVAi5MAJ/RP/iggG66I5rP5bEVkeCgrhFto923z5ZacV9dz x7rAd3WV1ByMzeps6q4DZatwvQfZc5MHLueXhVW/HqqeGEl9eqDwdGhy/oXl7QvXki0ACCCi ICQPAiKc7Asc28f3haYwMtdd7L7mSq7gpzaxqsGJTRhzt8EvJk5qCCmG5imVWpTLIRRSdE23 KHeQJ/lqjFbqEyB5q1bvoymrATWqM+iD1lel2UqgzqPN+sP2bHcuX2x/na9Un6LL+TplvbqG HlAO2gP8hjKqJXU3iZJmjZW0a3itPx018Q76Eu2W3jR24d1kt/4zox8NKAetE6E/K+9r10LX 7I/5iPI/LcYlWQYKq7LGGNUNgzmuC/uruVdGPJ4rzgmWMduK/9ZVaVx1OU/Jqi/LqsUMo9q0 fNO0qGvbKUZ9eBzJd1BEBKs8RG3XsEzmspDETcOgVFUFrNy2LQsx/6Zj4iXm98zNpmTm8K6A xVsYbmebGGE58o1Aa3Fxu7vJJa5o6Y6Ml5T8oATA7+rHN72by0phITpvJJuNgOzDRxAgG7l6 B3Vn/ORjDkowwi1du+bdTYYv3oAJXZZzTLWcjCiiLkrz3okLFvWZcSNO3ileRhiKVTzXh+rs OM8VL+Pp40dr896GBYsOIFo8t0+tw6WOqgXNe+sfayv1Xt6nxsd6OfTeU+qFgQbsuBib5orn 9qt1YsT9aDo5OPZPdwa/81x56Tm3eLmXxUNxJL4A4YWcXgx2foCn0VQoueL5fV4aJtQKUVEw fDVkaYLkJY575YLo90o1Em4uHDq4Z2aofs+BnY0PDfQU+g7tmXIBSP/WkHuSPJ3vPnWaLBu9 SDb2f3YW2G+DHv0b2O/gjkGbYzsRTStCjwai6Tb7jdAbdIf1A/uIfEQ5op6yNTsoS1dInhY2 K5xGPEN/Hr+m01r+zVCr2qovst7E3axbHyQ544R+0vq9c1F6T/uD+VfnCuNcUSSVahpWFE0O SRCtbBBdE9u26eig2cTUJcNhik1s5hxHxzXiVCPNR0iTiHncxGa1IfmGITFNkySiOCawELEW jvkcs9NIMHuponUGDIRkMFDmK5sVScmRhwMrLnWSRAtMdI67cSw7HBnTFpAW54ozMnw1+wWK CWnJjhMo+5xzDAmu2XYXLRFn7Ao3waYMzYzh1GdFJqR1sWr6hLSRKE9LUER7f1XaEZGJhdM4 UZXWglj6tkC1ljwr6FYW9Km+XChVE9QAQWzjFwo7/vaTL8WmVvdeKGzHr1y6OKPwd5LEhVuz 62bVjxaM/Bk8t7WQFepVVXhM+ifgV4G7eu0YtsVbvB1LJ/3H7R4mBWYACxpP1jU44qIaGi8z I7xGrzFqzGnGNLPR2uHqSZ70Hi1r5a1ea3gFX+GtCK9T1prr3PX++vCL5svuq/xVb6vfzXbr 7ziH3IP+J+xj/4aZd275xdg9IAGGA3oCyh/1Pa+aMx8atgGCUa0zX9eZx7lh6IoUi9oo5sRI bexwjMRyZGa/7QU88HNkYaDP5AEn3+aHOeE5PGvAxgn0tUomvuJ2XA+CuFFntBjSfKNoEAN+ 0Vtrw2TJzL7K+EYQj4qok18NaSWgCtXhiDMyFHWGwPhVRJzhUg1FRHJzG2IK0MI9krLGMe4q AQrKYMGOjMCOPISM4jWkF6/hu/ajX/xgoCnNEk1pC4JwfzjtJsLpcThLWxLw9GpEXtAkzs9D ELgLyB02+Q9OzTxa7k6W9cJ3j15KJSamPuorrPrKpLqNjzcUlu9xkpMqV9oTQsn8ju8/v3Et WTl6omdW6wKBcxL26XnA2cJbApPnyLuUcPwAL28AlTkTaFDBX4bcAFpHg7lQmUKSWq2Txmk2 Bz9CHqFztBbnCbyQLKRt2nxnFX6SPAkWZANeQzdor+AX6VbtFh4hlVE6GU+hKS1Nf0ovYFWw d9AJNxBQIIh+54MaSMXJDI0Rylg1JhAgCIbIoZClcgqmyJaayExZjOSw3QdBQoZNuDiYitSE +SMLIyuwllibrX9ZsrUGsU6MexBuQe2oiCQUtZ01VWKLlpxpZp4zLPL/zJAzIkDLQ9KWca5A dnrFFX5gPANwrGMpwAYAWJ1FAgdAqX8KnkyFnxlbFioWCVpHB8XyiDUq/RCvbsXZEqYU9qkt Zjd+uzZYmdZoWeVDItzvLxdd/w1YWZr4UCrKPt/B9Y1YubeqsSqM1Wn1VeEkefuZRYUW6an8 b9rXfQf/43WJKq935L+1QXsLpncdIZWj01BTkY4yAVdkgkMsIyJpKCQxloF0KLpfzUBIjA5K GXTKeP+G0Ku8OMclyhkuf+D+uvrG+nDVeLl+Gn9wGl86c7p0QHz5DJ8MtZPF8D/3BDZuRKRC jgN9oqHe9SLEDmWdq6h23vD9dRK8eCj0DD65fTvEeLRA+g9pk/8E71aO/hI8sRPsI7muXvfI h+qHHjmrnvXIYfWwR3rUHo/sVHd6ZJu6zSOdaqdHRumoT1bRVT5po20+MajhE9+jarlh60iy b1nSLWKZBBsZE2VMnMPzg1qvXd2kblMlFXv/Z7/cYuKo4jD+nTPLzih7k11YLqVdymXLLgVa 7mXLXbB0oVxaaUsRUaG24aGLxWjjgyFpY4ymDW2wGmsiifGBRFttjPGJqi81janxheiDpBhj TZoQEo0xIfjNznCrJajp45zJb+fbw5lzzv875wz7r/RFXE5HhD8l6vzppa5RoVZqESkQUZTz Usi01NiHRtLITcE8ZfFnzx/hiKFQ28d8hZmk4Y7nnjDSRXhu6tkLRmKxmIiZRfSJ5OyyUp5L v92uZq3RwncjEOotqChVxKVlZfv6uw/ORTrym/29PauKTrUod2V7ws24Uz/WtcedmtfmfVJo widn1VmvvK3e9sppddorr6pXvXJSnfTKcXXcK8fUMa88pZ7yykFt0Ce7tW7TKbcjUYFvyqt7 43DSMhfNEtqUqlcUCxooERHC5Y446FfQ6a9xOJy6Xc5RKblbaFkQASHEybhb/DcXYV5Hj3Sr eIZ0HT9CPFX3lu/rzVrxKRajb3yPcXv5mC4Gy8srStbonhvbwr0F5WXKzLKw/UmDqjvzW1L6 u1eV/tYaVu6KvXGvTtflfa/OqfKa+pUqFzRxUXtfky9oY5o8pA0yRdCERgfMgLfGAxY8JwIr 0cXDS3NceXllM5hRLRprb8SD5WXX131tCK88aLYwy/B9LGyMGCHzq8jnyUfkN76hjwK2F5lP pAD2p3nirwPaHeDRYiDxJOBgvfM1wHULcPON7v5lPZ4ZIInwZz+Sa4CUY4C/iXwLpDYAaZeB 9ELCxCVjCMjMIaeBbew/0Axk8Z71g0H2BJDLMXLfBfIOA8ExIH/EIHTHIFxjMmHyjcHON4DC aaCIc9rFjHX3c0DJU0Ap51H2JVDOsSs4nyrOrepXoJpxRULAXtbVsP/aC0BdB9DwBdB4Dmga B5o5133bgVaOG+UY7a9b/C8WHsyBkEHHQaDzVYOuHAsLCwsLCwsLCwsLCwsLCwuLhwEkBPTi g6IrkU7s2LQoNuOe6ADcnseSvL7kFH9qWnrGlsytrN6enZObF9yRHwoX7CwsKt61uwRl5RWV VXsQQQ3q0ICmx5tbntjXuj/a1n6go7Or++ChJ3sOHznae6xvdZCptSN+9ul1XNt8Yg+r2PA5 P3cgQKUhC/moRgd6cAS96EM/zuAsxnEJEwFvIC2wJZAZyFta4hMBPlOAWnSttByIt7y4vuXS 3D8v5CGHz2fMvjd7ZfYtXmfNtfl3Rdm0hYYhs0cFXDdT26gdprZTpeo7wfYIa1I5H0NLuLhy hlZY32pqG/UzprZTn2mMtrXW14frR04MDG+k0Ygo2thHPa8wGcEJujRMzwZxHKNUA6zbqNV/ rWdkCR5+1OJZJDASD4q4/2BzcL0UfmcQ4gL/otlgi9uxfMeQTKJJK+V+O2tZuJcDmND0bm5p UeWy6ap8+52p4Tdf6ndHftcytHjryblgSL9/sv+nmb8+Xjzu2aNF+VX3Od7z3wMA8mAVhwpl bmRzdHJlYW0NZW5kb2JqDTE3OTkgMCBvYmoNPDwgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VS R0IgL0xlbmd0aCAyNTc1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJnJZ5 VFN3Fsd/b8mekJWww2MNW4CwBpA1bGGRHQRRCEkIARJCSNgFQUQFFEVEhKqVMtZtdEZPRZ0u rmOtDtZ96tID9TDq6Di0FteOnRc4R51OZ6bT7x/v9zn3d+/v3d+9953zAKAnpaq11TALAI3W oM9KjMUWFRRipAkAAwogAhEAMnmtLi07IQfgksZLsFrcCfyLnl4HkGm9IkzKwDDw/4kt1+kN AEAZOAcolLVynDtxrqo36Ez2GZx5pZUmhlET6/EEcbY0sWqeved85jnaxAqNVoGzKWedQqMw 8WmcV9cZlTgjqTh31amV9ThfxdmlyqhR4/zcFKtRymoBQOkmu0EpL8fZD2e6PidLgvMCAMh0 1Ttc+g4blA0G06Uk1bpGvVpVbsDc5R6YKDRUjCUp66uUBoMwQyavlOkVmKRao5NpGwGYv/Oc OKbaYniRg0WhwcFCfx/RO4X6r5u/UKbeztOTzLmeQfwLb20/51c9CoB4Fq/N+re20i0AjK8E wPLmW5vL+wAw8b4dvvjOffimeSk3GHRhvr719fU+aqXcx1TQN/qfDr9A77zPx3Tcm/Jgccoy mbHKgJnqJq+uqjbqsVqdTK7EhD8d4l8d+PN5eGcpy5R6pRaPyMOnTK1V4e3WKtQGdbUWU2v/ UxN/ZdhPND/XuLhjrwGv2AewLvIA8rcLAOXSAFK0Dd+B3vQtlZIHMvA13+He/NzPCfr3U+E+ 06NWrZqLk2TlYHKjvm5+z/RZAgKgAibgAStgD5yBOxACfxACwkE0iAfJIB3kgAKwFMhBOdAA PagHLaAddIEesB5sAsNgOxgDu8F+cBCMg4/BCfBHcB58Ca6BW2ASTIOHYAY8Ba8gCCJBDIgL WUEOkCvkBflDYigSiodSoSyoACqBVJAWMkIt0AqoB+qHhqEd0G7o99BR6AR0DroEfQVNQQ+g 76CXMALTYR5sB7vBvrAYjoFT4Bx4CayCa+AmuBNeBw/Bo/A++DB8Aj4PX4Mn4YfwLAIQGsJH HBEhIkYkSDpSiJQheqQV6UYGkVFkP3IMOYtcQSaRR8gLlIhyUQwVouFoEpqLytEatBXtRYfR Xehh9DR6BZ1CZ9DXBAbBluBFCCNICYsIKkI9oYswSNhJ+IhwhnCNME14SiQS+UQBMYSYRCwg VhCbib3ErcQDxOPES8S7xFkSiWRF8iJFkNJJMpKB1EXaQtpH+ox0mTRNek6mkR3I/uQEciFZ S+4gD5L3kD8lXybfI7+isCiulDBKOkVBaaT0UcYoxygXKdOUV1Q2VUCNoOZQK6jt1CHqfuoZ 6m3qExqN5kQLpWXS1LTltCHa72if06ZoL+gcuiddQi+iG+nr6B/Sj9O/oj9hMBhujGhGIcPA WMfYzTjF+Jrx3Ixr5mMmNVOYtZmNmB02u2z2mElhujJjmEuZTcxB5iHmReYjFoXlxpKwZKxW 1gjrKOsGa5bNZYvY6WwNu5e9h32OfZ9D4rhx4jkKTifnA84pzl0uwnXmSrhy7gruGPcMd5pH 5Al4Ul4Fr4f3W94Eb8acYx5onmfeYD5i/on5JB/hu/Gl/Cp+H/8g/zr/pYWdRYyF0mKNxX6L yxbPLG0soy2Vlt2WByyvWb60wqzirSqtNliNW92xRq09rTOt6623WZ+xfmTDswm3kdt02xy0 uWkL23raZtk2235ge8F21s7eLtFOZ7fF7pTdI3u+fbR9hf2A/af2Dxy4DpEOaocBh88c/oqZ YzFYFTaEncZmHG0dkxyNjjscJxxfOQmccp06nA443XGmOoudy5wHnE86z7g4uKS5tLjsdbnp SnEVu5a7bnY96/rMTeCW77bKbdztvsBSIBU0CfYKbrsz3KPca9xH3a96ED3EHpUeWz2+9IQ9 gzzLPUc8L3rBXsFeaq+tXpe8Cd6h3lrvUe8bQrowRlgn3Cuc8uH7pPp0+Iz7PPZ18S303eB7 1ve1X5Bfld+Y3y0RR5Qs6hAdE33n7+kv9x/xvxrACEgIaAs4EvBtoFegMnBb4J+DuEFpQauC Tgb9IzgkWB+8P/hBiEtISch7ITfEPHGGuFf8eSghNDa0LfTj0BdhwWGGsINhfw8XhleG7wm/ v0CwQLlgbMHdCKcIWcSOiMlILLIk8v3IySjHKFnUaNQ30c7Riuid0fdiPGIqYvbFPI71i9XH fhT7TBImWSY5HofEJcZ1x03Ec+Jz44fjv05wSlAl7E2YSQxKbE48nkRISknakHRDaieVS3dL Z5JDkpcln06hp2SnDKd8k+qZqk89lganJadtTLu90HWhduF4OkiXpm9Mv5MhyKjJ+EMmMTMj cyTzL1mirJass9nc7OLsPdlPc2Jz+nJu5brnGnNP5jHzivJ25z3Lj8vvz59c5Lto2aLzBdYF 6oIjhaTCvMKdhbOL4xdvWjxdFFTUVXR9iWBJw5JzS62XVi39pJhZLCs+VEIoyS/ZU/KDLF02 KpstlZa+Vzojl8g3yx8qohUDigfKCGW/8l5ZRFl/2X1VhGqj6kF5VPlg+SO1RD2s/rYiqWJ7 xbPK9MoPK3+syq86oCFrSjRHtRxtpfZ0tX11Q/UlnZeuSzdZE1azqWZGn6LfWQvVLqk9YuDh P1MXjO7Glcapusi6kbrn9Xn1hxrYDdqGC42ejWsa7zUlNP2mGW2WN59scWxpb5laFrNsRyvU Wtp6ss25rbNtenni8l3t1PbK9j91+HX0d3y/In/FsU67zuWdd1cmrtzbZdal77qxKnzV9tXo avXqiTUBa7ased2t6P6ix69nsOeHXnnvF2tFa4fW/riubN1EX3DftvXE9dr11zdEbdjVz+5v 6r+7MW3j4QFsoHvg+03Fm84NBg5u30zdbNw8OZT6TwCkAVv+mLiZJJmQmfyaaJrVm0Kbr5wc nImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfg qFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQl tJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDs wWfB48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42 zrbPN8+40DnQutE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF 3IrdEN2W3hzeot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb 6uXrcOv77IbtEe2c7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4 +cf6V/rn+3f8B/yY/Sn9uv5L/tz/bf//AgwA94Tz+wplbmRzdHJlYW0NZW5kb2JqDTE4MDAg MCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMzU2NCAvTGVuZ3RoMSAy NjQ3NiA+PiANc3RyZWFtDQpIiXxVC3SNVxb+9jnnvzfyIAh5mz+5pEYSmgwSBGlyb8ioiEQ1 8ejkSkKCkFZqMCoVTGYuplRqOkNNRRVB5w+ZUs/Q0aqhmkWNqrZZSpVKl3qUQe4/+17GMGtN z1l/ss8+++z97ecFAQjAy5DIHpHbK3HCmbwPgYnnmZtVWOYsj9WT7gKFjQA1FM6s0L8/XXOU 784C1uSJ5ZPKauX3QYAPf9qQSVNnT9x0+Ae+TuwORI4qKXYWfbh6Yj4wqTcz+5Ywo8P77bey wXF87lpSVjHrxsGcz/n8MhDUf+r0QieWDv0RGDGXz/Yy56xyvxtUzXj+zvL6NGdZ8dymujSg uIbx9CqfPqOCcfMqrvDcl79QXL6uc1UnIGoPEDhV24UI77cBESoGEYB5/j+fu9Q877nz/BeX WVvk/e/B2oYt+Cd1Jx3b6Q6CcZtCKQGZULjFFv+KVryGIIzCSuqAruiMZ5BJimVisYRWmTPN SxiIV1Fr7qAqs47vX8EHuM0IvlSEJGSx/DMoxiV5Afnmn+GDavhhAHKoM5w4xfsmY1iBGuyj ueZtthqEKtaXgqfwlHnAvIceWKKWaafb/A3LsZssZqFZii6IhkvEmqfMrxCDfKzDFsYUS41q KKIwBYvwOoXKD5h6DW/BTf5ivEzX9rOlTIzGNPwaLtThCHWgbO20dtX8jXkRFnREd8ZUikvU h4aL9crfHGSewVi8h8Psr2c3qrFqgzbWPdh8wzyITthBvrSHDmiJ2h9a55trzXfgz3gSOCJZ bGcCFuAAPsIPuCYqzUoMRS5bPkSRpFMMR/yUCBXzxDx5Aj3Z2/GM9kX8BQZnZBd2Yy/H5nM0 4wIFUTj9kibQcrom/EWROC5XyQZ5UpHaxPG2oRvHqALr8S6O4hiOk8b6n6RsmkzT6Y/0BjUL Q1wRt5SPWqDuqlYtxt3svmtmmTcRgjA8jTmo5Niuw3Y04GN8imu4jh8pkJKphNaSQc10RbQR 0WKEKBcrxXqxVWbJ5fKA6qPS1BR1TJ3Rfqsttjqt7ntvu1e4t7qbzB1mE9dOW9YfgwyO6Hyu ivXYjxOs/TN8gXOe+mH9A2gMPcdWZtDvqIa20iFqosvsJbw7WgwQdrY6XbzAcaoSK0QNWz/O +xNxRnwhvhM3pSajZV/5vFwrDblTfiK/UYEqRvVUCWqEGqNMzkyiNkTL1TZqm7WD2lVLiqXI Um751lplXehztLVH65duuEvchns7164PV9IcjsQa1HLdN3AOjnBEP2bEzbjBWQijKHqCcfej DBpGw+lZGkfFVEXV9Cq9Tquolt5hD9gHYWXsseIpkSucolgsFNViqWjgvUt8JE6J06KFkQdL m4yVCTJTjpFj5TT2oULOkws5sstlnTwuT8iL8lvZwlkLVl3Ui2qO+pPaoBpUk/a0Vsa7Vtuv NWpN2j3tnkVYwiwRll6WyZaNlnNWi7WvNdv6e+tJ63WfcoqgHoxcxyNLhHIPdhF1IkhVUgsz IkmhHXsey3nI5a64jsHSzXlp67lnbJ1EqOroeWlJVQa/r6Dd6EOHUGkRkqeqasY2Oiua1fti ID6lAgpVG+Q07YiIwmaeRsvEHrGb0tAgUsRosVqCLtBGXOB6n4UamkIzsJlaqD+9RElUiZOi s8ylhUgxa4WiNpRJV8EIMF8V4Tn85KJ+PK0vudeoADWX59NOrOSMbsFXtAl3SDOv8HSTPI2c PGWWcL0vgmfqjec+q+R+DOUJMtVyHA1k4YmfZBmk5uAq/oVL2i6uKJ7E5kV3qVqjvjaTzHju MO4ybOS+K8EQ7pgLXCV7+ew5jeNO9+VZkshdnY0xKMJLPPWWm4a52lxgzjan4x/89g7F0R16 kztiJ79IwWHer+AzWsx9OOSn/fx/y12ERlymEOpGidwPLdpMbZlWpzVo+7RjlgSO9kKs4oo+ x9Xsyx4UogmXcYt8ODehiENvxpvM2PMwVeTLvUinMJRzz3bnOZ72wJMZrKWKo7ea+3kv98ZV nhPjsA+nSVAwe1TI9n1YzzCO869Y+m3O4ALazpwinto98B373ZaSRQXbS2VNK3lqNTKms/iG o216ccXxXLDTaNZ1C8+iiC30RTbVI8N8lydVFuzyKMe7KwUijaLpLX5XwB3aFpHop31NAnHu LDNZlMq9/BtjMv9N/vUKx0B6nlG0Yz9a0YlGoI87B3GpqamDBw1MGdC/X3JSn96/SEx4slfP +LjYHj/v/kRMt6626Cj9Z10iI8LDQkOCO3cK6tihfWC7tgH+fr5tfKwWTUlBiHPYMgp0I6bA UDG2oUPjPWebkxnORxgFhs6sjMdlDL3AK6Y/LpnKkhP/RzL1vmTqQ0kK1FOQEh+nO2y6ccxu 03fSmJF5TC+12/J1o8VLD/fSy7x0ANNRUfxAd4SU2HWDCnSHkTGzxOUosLO6ej/fdFt6sW98 HOp9/Zj0Y8oItpXXU/Ag8hIi2NG/XsAngEEZYTa7wwi12T0IDNnN4SwyskfmOezhUVH58XEG pRfaJhiwpRntYr0iSPeaMSzphtVrRi/1eIPFen1co2vJzkBMKIj1L7IVOcflGdKZ77HRPpbt 2o3gOedD/ntk5R3S86ofvQ2XLkdIqe45ulzVutE4Mu/R2yjP3/x81sFvRbeMAlcGm17CQRyW q7M1sSg/z6BFbFL3eOLx6r5/xTaHh1MwWTfa2NJsJa7JBZyaMJeBnNlR28LCUt8zmxHm0F2j 8mxRxuBwW77THlEfBFfO7O2hqXro4zfxcfWB7e8Htr5tuweEf8CjRPHDOy/lFfdQw3IeRpY8 iGyZXBCGXqgzkjwb+5T8b+7LP6rK+o7jn+f3lSzvZjDFk17iwFRwKPkTm17H4ebGIlBAQFdI aIlrujhycueIzNOSLrJERRHRuVpZYOv6449b2HZdOzNtrHaK1nGdTtOxqei2TroKlGfvz/d5 nuvlUcP2458BLz7f3z8+3/f3x8P/ls2k4IMzUQw/pRJqhSqxIitCw7LLg94sTuf6IS3Fm+wL XiIoIPnC+cEpS+0UPcV7iTjIOolKDflOOJSWFpo4kSViZGNNMcY5Ij5tUnpNWJ6evNrrg4H7 KB++XVqalQH3JyXxAjeE/VSBSKiuoMSK+6hizEHyZ6SVhuRyzok4OfFFnFPn5ESrlydDyYeJ 3/PxIU9q9G+EN2FkzsNZISnhc7KXWfm5C5NzC8pKfDnBctu3uYWDYlb+zGieHQqNzC5Rxsh2 SB6jiFyIckm0MEdKhofUFPzpQtSVIQWiFAmSLxDyls+3/pfGJSXdsE7Y8MRUCpv/4FrCXK1m jzKUlTY4PntQfNDohgcVjFdNlXMLy4LBuEF5ARxAwWAg2RcIlgeXhs26imSfNzn4srxP3hdc nVPuLGjYfKVhTCiwqRSTeFjKmkTsbGPOQB5le6mvb6DAmyPcH/Oj3arbSfIsm3YKK2/QarWa vgwCxh1Uqh2jMumvtAR5K0G2cge+Z/ZTEcqvQbwadqs8y7yC8sXgaXAXuBekgsVgkc1CMA91 joN2tPEAtyPsaaoyuujr6IvAdrAUbNOKqRl5O/RZVMHp6GsT2khGeCfSd+vt1IRwC/JLuayw XL+YvoX8dIS3asWmaTSSgTRC+ArSE9D/Fh4zbCr6r1arzQsIT0Tb30T+Rtgi2EJ7vKNE+DTX EXPlOT7JYfinFulNYAFoAIvhH64/GfXGId6I8C0Y1zDY4eA2lehOlLkb77IQ7CT0n23Pm8S8 MY/onDB+Mabrwz6dFwvGxPM6C7rAWzFjc9M4iGrc4HeJ9eM53wpmy130DfhlgOel9ZifMB6i 9zCvTqDh7TfFQ2Y7xjlXO0wtiGeCuwXVJKlttEq5iDU4TD/Qt9NPkU7yFPBPSpHPU6KeQjPg vxK0vwgsQ5uvCT1U8hjM87Dj1B5KRFvloAp9H3f8xL5BfD7WtQRlLyOMByQ9DlbABy3gUR4f +s9gn2PdP5GKB15A2Q/RTy6DPscJMHdrXWkN6n8fbUmiH2sdLAuQXwWf/hz8EhzlMTgIndmI ttpJkdvNj2FHgkTQBZpYb6Ac7OUy6D8O5eOEXqEZ1ibrg7WhHRNaXchjt+Yg9kKDvWceQf3F YDQYr++nJTbjUZb9U8Ga5f3itM3aYl07Vmh6JeteOsfzZE3F2G1ahAp4DKJfaMuxvO/Q7lq2 +AbgMbUq3bSZNct6cyz7hbXG+5H3hG3zY+aabu+RdNQfK7QOLTrW8UXUvkmtaLNYb4JOeylP PUl5eHXmaWtht2B+LyMN81HxelfS6D5PhCZgLe9D3Z0u28IY3VIV+npK7YAvumm38Gu3fKfa LWlah3lWI+m41iHXivA11o0UsfLYMrF5XzT930F+V+ug5Qif07pNE/PZwnvC6JUmA59jkX4Q 1IGJnjSpxbNSChtF5MXn1UWwSvVTluanGWqE5qrx5IefUpBepN8jzt3NaP+Y1EuNWK8njHhK Vs7ibERf8ru4HwC3D3tvjI4Gac6tJcc6enVb1gyfu7Aa7Gjsu1dAJzhp8ydwCnr8nti/uBv4 fBb3A85o0Gjp1bwQ1edxaoP9saNPl04nuvRpuHXptny38Pku7hbsU4yj0Zk/n498xvEZyecc 331OebeNqd+Ms+MP4hzuojJ7X08Ak0EG2jhinyOdSti8iD16Rn/b7DTmmp3KCbNT32k+Z6w0 X9cPm22Y94TonRqxzjLeT85dyn7ie9G5R7VUWm6fZ62iLPoX92ixOAdIX4v9V0UVaPe3fK/y PlTasO/gT7S3QX2evqueos0Y+wjlJStdXUh5fCaqNQgjHWc659+ibBb5C9SPqUadgPDzsLvo S7pBNfqvuI7ZJdJOW3mcppXRDuguQ32SfqYdoBJeK56HPM08wWuPPZ/oqaPdBkHDp6hV7cOc I5jjMWF3CT1x3UNmH8/PmE1f0RTMj8sArqPtJp/tj+3CFxHho2ahYfiC29TfEe8N0t5D+Z/Q Ok8ctXq+ivPpEiUaOEtEXwdokccv/K6K+/oj7I9eaKyI6rXbzc+E/vebptKHPdSL/cVIyIun 0Vov7cJeqhf+sWwD7x+ll+JZI5hfoXhP9ELjz9Kjegdt0iPQXTfugm6sWy/mspJmItykdpj9 KJuDNoj7RnqBeJ/wPeU33+L9YkRolOFH/yjDYxDvP/Sr9GC8W6keZ8k8Ty89o/v4XSNJ0N5Y MMVCxNeDWrDJQqR5LSsloY11In0ZvS63KzL0zfnH1Rew93bRPGUfxanL8X44RxvkDNqo5EF3 F3BnKKiHuJpO45ULlKt8Ku6fjVoczRDlEnCPn6F8tRT1I1SpHqRKxUR4FGiGHlFPC1OZ9iDe WfejHRt5OuoMo3y9AeEMcz+XE318aiYw6lrKFPViEGN14DE/HTPmZvj2h9ADjxfh2PHyWKPj tMd4vfGJeXK7qCfK/JHmEZnvgxTLDhTIjdQB9son8Q6PUK20HY+VNgpIPaDN5kWaL+wBUEAB tVaqB/lAVWtpD+wk2HOgG7SBI+Bv6jT6Edo+CnuIvwsY+Rc4u2CR/yx4FXzg5MXCfV0vPRb1 LzQormXSekZOx5swna4tv4emqo/hHJ4MfwKlhvIZ/TZaZXholXwK6XwmueLaeNqhrqKxQ41n KKQ3abLwoYU/do7OesAm3ATvx1gfW+yvSXw//6dj/KJgfdeDh4T/99LXhIbOwP8GDZOO0P3S h9BfG32bsePlwp97sO/tdUJ6vUh3rR+0Ml1ZQH53OsIbGCfuXteh4mj3pVgcHTgYmXiLAPUD lAfuOO6DJxidNZYu4usYJx7t90YU0lT4KQBLQmOuuO6lNYy8GvEWYp0/wkTjhXhXFVr6ZODb FQx8SAzSHmLgO2JQ9nEmxq8l7Ff0yXXJWR9H5+714XGpv0a5P+PNXEiJbhvVt31eDNJ8gaX3 aJzPkh5Xmat74urewF65UZv/T2DvnADHwG/+133xKcNnhJfPibfx3gjhrfoMvjHfoEaiK/VE /UeJLj+Ac2gK7ItIK0I4FfYjMAppK2BxG/VDZZehxoF3QBfYq46hx+x35WjEc6y6V56z20ux 6nO9Prx2+qdb9fs3gl0I/w5AZf2vwW6DvYTyIdQrha1F2gbYqYjngwDiv0d8DpARzgJnAcZ5 Gc+YyxmovwfU8HvkOt+h/117g++Pm7UYYxX4jnhzYrzub4ibts56DmHd3xrO+g9lnW+Ja6zt B7z5TjAx3z6f+43jWKznZ/i9OPB3oleVVhohSTTOjCgth7y3Z/rDys5/kV6GsU0dBxy/u2f8 nBDHJoTgEsI9MLYTpy6OG2YQKH4vOFSrNcWFtLIHVQ00UqdJxVKTskGbBCYkEkSabeqkqdLi VlqExto8nwe1myDcZZWqTR3WpmnppGn+wD6Nin6Y9m3K/nf2oJP4Ui3R//7nd//f3b2787Nd 8myNmZZXexvP5rcJI7b2LVKFGDmr/ZBMQwzxlIgMxCqyUmptj3mRv0oMaAbSSAElVa9NSOav lrZ2ye5/IDxbFHdBRAcblZLXF0tbndr3CNXGtVeJn3BtCr4LfgbeAz+tvUzcap5myeONzWC8 BOIJbRvpQ7OFb2cxeFLbQbpVbFK0N8aZFL3hmNWqHdF8KuLR3GQQ7tJ0EePGimZipqZ2pdSy Wc7vivBui93WLms66URqBqnt3HNbayX7IHknY6UWd2zBatPGcJtjWBaOOVKyqEpTe1WgI4w3 ou0kXWj7Ln6QboMf1XaJbby6gu/RMvYj2QvGGxKup6WV3O2xqtWiDaHV1uax4vNqtIVS8ECM WEGtl0QhhkWdRm0aNa82h9octmkOWzOHrZnDLObw5CHaLFpmkdmnnSd57RxZgBZRd6DLbQIr WFGVvb2xivaE5sNKeFewdhRXd5Ra2uXMfKJjq4r5Sm3tscRt7TUyCjFMfqK03Rc7u6KF1a08 WfJ1SyAvWtqwdNsbewGwS+7BbW2ntkutRI9aAdvieE3x45ITyn7LanJ12B/Zn+T+srt4Lf13 Tf+s6b9v+EaV1UoYxSyzP0ivWzvZ39HZS+yvZBE1xlbYGokC+Asry1mwz1mFJODreP0yvAJ/ Gv6R2P0pL7NyCYa5vyPcXfJm2Zro39es8ECzsr27WenoilkB9mv2MdmJLv4M3wv/mFXJHvgd uA9eZRPkU/hNtp8cgv+q6b9hq/JMsw/ZLXIAXhLtcgq20KUtC6e0DwRpvErv46vsA3aD7ED0 fRHcgavXS8G93LOC/ij7OZsQPbzDamXv0gz9J0IFsi6ddLD3RFx2siBWDV5hC2zB9MXNgBkx l7RoIBqJLmlGwIgYcWPJsLxsnmzC4uENy66ijBOD4fRAJrTAZoUjblv/xj3J+2JkBmVB1XIo 86pGUHoftn6pagl2mYxCDH1MQdPQDHSROFCehy5Ab0BvqisT0CR0Do+PPIg8iDyIvCLyIPIg 8iDyisir0SchSeRA5EDkQOQUkQORA5EDkVOEnG8ORE4RaRBpEGkQaUWkQaRBpEGkFZEGkQaR VoQJwgRhgjAVYYIwQZggTEWYIEwQpiKiIKIgoiCiioiCiIKIgogqIgoiCiKqCAOEAcIAYSjC AGGAMEAYijBAGCAMRXhBeEF4QXgV4QXhBeEF4VWEV+3PJCSJOog6iDqIuiLqIOog6iDqiqiD qIOos3NFrWZ9AqQGpAakppAakBqQGpCaQmpAakBqzVufUIvBcGymoGloBpJsFWwVbBVsVbFV dbwmIcnaIGwQNghbETYIG4QNwlaEDcIGYSuiAKIAogCioIgCiAKIAoiCIgrq4E5Ckvj6h/Jr bw27SDMufLiyGdqnfJrcVz5F1pW/SYrK3yBLyi+QS8rPk7jycySoHP0pnyDcRQWPe6wuPAJG oZegs9AitAzdgXRVuwv9Ddpg+809Do8+qi/qy/odfdOyXteZxznqXHQuO+84Ny07605mWN3M rZ6jeLSQt1Q5jfIBhA8RlAlVS7BBjDuI5+x+/A+yQXPLF8aDML0bpnfCdDlM3wpTq4U9Qx3q SWeQOMPEacZsCw7xdSgeDA3hyTR/6/52LoLf4GW62rA+sx9+HypCS9AlKA7FoAgUgLi6FkY+ Y+5pdrkKhaDdkCGHIF1d+L7dscVlVpibLpU+cZMWOU6oF9yKCEVhZREahX0oQqe51UJvkZD8 GkRvYuduwJcFv4fm9xv2S8FXYNcFH4S9KEJPwU6I0GfcctPnCXdIdKzpx3Hf0o8J/gJizwne B+sXoaBMhzFQAK19NEPuwQNNam9jJL/gh2B7BD8o0y4SkhtPnSSiprcJkq6VMKEHFZpxUHMz /4L/mN8H/g8sLI7H50bZAbsbKNMXzFa+GvkZwhYXVqvM4/Oh2HRb+k2+FJjl76AvGrjFf8qf 4vORsguXr2Hes2oIwS8ZZXbD3MpneJRPRO7x1/iz/BQ/xl8M4LrgJ/mqnCbJ0gy7cYun0eE3 cRcBwZ8JlNUUj/Lvc5OH+EFjVa4vOdDoNx5ZlStAYo3Rn8T6hgNlecafj5fpFjOsf6kv6Cf0 Yf2Q7tf36Lv0Hr3T1eHyutpdba5Wl8vldDlczEVcneWNutlPcGw7nV5pTocsHaruZbJEIX+Q Mepi5Flib9VSLHV8mKbs6hmSOm3Y/zruL9PW575tb/IPU7sjRVJjw/aB/lRZ3zhmx/tTtp4+ kSlSOp/FVZtdKVMylinTDXnpcrfdcQSN5PK17gqh9InL17JZ4ut6PeFLdAxtOXg0+Zgi1yz7 H/35vlrtsX+SOp6xf9GTtWOystGTTdkXjxsnMxXmYe6RZIW1S8tmKo4884wck9cd+WQWsXsq htPcjhgJSUPMNUwMGcPzZFjGsEeNXBA4crulIdfqJkGVC7a6Vc5BZa64bowki4ahMviBua4y 6wHylQxODNhkMRhUKb9BMzJFM35DTaxPdcQ5IhGuIhTf61RHnKrB7H2PIoFmZP/DyH41lkYf ZXgj09n730xnLzL9/+ff+HA/LQ1MTq2NjPtHcv6RcShnX339FZ89c9owilOTssGwtWDu9JlX pJ8atyf940l7yp80igNrj2lek80D/mSRrI2MZYpr5nhSDJgDI/5TyWwpcThj/c9Ysw/Hyhx+ TGeHZWcZOVbCekyzJZsTcixLjmXJsRJmQo018h157tOZoosMZ4+cbHiJbW7FGc51784Od3nz Q/JAVw7t9k11f+Qg9DrZ3J+12/zDthuSTRErYskmvM/+w3a1xzZ1nfHzuOeee33jV/xKHExs UhMTE8dxnIQIs9xRCIXMIW260lAMgbWDsqkQkvCYVGpNK6Eb0rJNPDqpwt1UVtGWhKRCSUZH VjG2tpq6CbTSdZPyR1f6AJU/ssBofLPv3DiMalz7nO+87ne+8/te94gpGwzbC1MlB5eHysbx q4UpBww7K1aieWiRWNQ6VP9w61CoY+PjwlSG9K3311mPeMzpErT66VXwh36vWeB370rUc9+n 935PX19fj6j6oj0ItQ5VdbQONTwMknAOW3Wt6oSx2PwYpebYWVVdPTo7AZNREAL3iu1EK4qj gKBugVsXJzk5x4m4KvSO+AOJXW9BBn8OCtzjyL7hmlrzFrFvZFFY3F96R2rq5yjcTwUd9ocS sMNII7wqaHiO6s5qaAyEB6oHGnPhXHWuUYbRc6dgsPyUSKXDNaco6o32zAMBzd5OABvEEvu9 PLwgYG6cE41otDPag028/h9sPA/6XWB7Clx7TPa98wqZG+9Bc4vnJqN98y/1FV4xJ/vMV8R+ kBUR3DQY3E7hG2XlmwQbMh8lzboLMcmgyMIlA6NSRWYGoefxYqTiIVyCSqKO6VQ+1eaYSqXz KdQMbccMVLXxkDPkDEMFYR7NBOnEjM7QVygoTUCcn83PXiPL2WXYa5kegIi8llA3IRSEgJ3w F8TP6BeoVPrF90uiwDp9o80xnb4B3JtT/SwWfdZxsTbOcR2m+HuXjZ+Vsut33MjMIIhdYOMg vwUnxhCfvaqrjU1JOQIVF8pSI/VJWYcKelf19lAlzEG1BFVJVSxiqSlahhpZc9FOtJM8Rb/L dijbLZ9S+zoZE0XF1KKqElcxDiIO23FZlaQgk92MyYpF9we+YRFbaP5A0hImlMqS+KzRbTIn TIKMrhT5fH40SrZCwgUeOI6zIP8oeUBXy1UcV7MqUcfJA0iCFWqQYVaqbf6OefxMOl86neme ynSX5NtWP7XqEwAi5QAs0jecxU01qXw0asLS/+zF/liJINyRSvVfBJAgf2rgKgvBVcYQnTWG FckyPmsANDNnZWmZeDpxd2bOMkIhCj8cclHKLhi/y+bPHTAukeW4qerdSzhtjLDxmR+TYH4S dHQMkN4GSLtQEC1FV/XmfVV4h21/1SfStCSpIY8qR5aGwt7ics96D4l7Bj3E43FXLAoXu5Sg OwzZvqxyt5yVidwaqRwswkXCo1QtWTRKjuiheEyPtce6Yrtj2dhALBdTgrF4jMTci4Io6Iq7 iGuU/GSkurZjDhxhd2lHpns62p2+MZW5YdqgKM6mmky3cDPkmc0OB5o8sMmwX5DsWVcTnLcT FmFAEEG5C5VdRBVLEGDJoIwrlFhIPG6Ze71Qy1xmIeysSzQ2NNQnF1curqDOUKGzuOIYWXfm tf6Nu7YcGsi8vHed8S/DiiNvv1H1rQ2t65b+9TQuzkVXdugH3mXjgU0vbtn+erTy/HNPvtVt VYh0yXiDqRvWrPq2yvJjxn61KNO2clOV+B7aOnuNbQY/8aMrevqQ+oL7Be9JdEL+o3qFXtH+ TdWwGimKWJe4l3j7WJ96iCncxX0+l8+3hFTRMOMR1ozX4xfZcfUd+geN40ccCE+im+ArAnFn SdKkFitQvFH3lVRLik23FSdtrVvseL0d23VPSdI+iiP6ouJqC7V/aXsMfYmAJcH++AK8wFOZ 49jOy3mcU4gWR0bKDhbU0i2cNjOdAZ2ASvJT0Uz3x1FBRaM2jjI4k8lgJksVQeR0oFDQ5/Ux gHGR7HR46xINUjMuX2n8+brxD+Mw/gFOYuurTyaMj/yv7P31e3/K7T1Nyp64+Rn+Kd6In8FH T24eatnzo8+NO8bn148J3I4iJN0E+9TQgL5CYRJXwnJxOcNxNsgIYyqVwgQTixrWkMLlVkoe siANa/6gNW7VrdQqqUFw87jACWyt6F5bM0+VSk+lplL3MTUGNhZoYmBjYGrsa6ZGGXhlbbzO GfKECuWo1DzzGZnMB2kdG79t/PaW0X0LpD8CR3gTpKdol8lxJJFMMqGoirBJ9Wa3L4mYztpZ lk0yVs662G52k0lZBoohFCmEfgjxfAiBr04IdYuz/AV6EnpGqj1Z0NCeQshuBqkwdEFOEM55 BEfY+J0WkOMlQPEVdgaSwgrd384FbwmsCikS83NC74VIrh27FyJD8E3nC6wF15DnJRwhk+zM V2tvCQ2dgAhSAWdU8SndplJZKaU+RSoGyenoLBop1pqpOPETmaSgelXHo0ma4Iqbc4UqhHCq SoSo0JF0WCPpMC8l5PchboI4eqmutWtdGt2tZTWS0yY0EtTiGtEUtcBUUN3W0ZFUE+YpJgBs cQ5Lbd/dc0BYhcACwEwXeiZWImI0ISj9MRE0IdrWxh80o2v2nFavZLV6U+AV/lhS6YCKUS9N UJ1KLfR5ZUDJKcPKx1S+SN9X/q7QIK1RknS5sl75OT2p5OigMkQvKNpcsqqrTxK9zkxWk7q1 JpEkQVFxdz2MHNfVUCxJHoXKXN2yMAg9qBTCeQmhPr6UVPLlpI63EZ1vIo9x1U3KeJqs5r/k r/H3yIfkU3KN/4dolSTC1/H9/DB/ncjCDvb876stM2cW0U4klIiFHrHzBA6Sx7HL+CB/FlJC Nb18p4Wen1klMrDwu9ugVTsqQ/v0sMzG3GMldA3D29nfGCl2hq02GypzCOezI8VbOcgxL8R+ ET50b3kgHugK7A5kAyzgsN9rYQu+HvDn4r2pkXzKzIIpEVW6TWuDYFII2BUVpQSiSSFeH8Uf YdsjB09vO962853f/2pw74ObH6rPsXFv6J+D/aNPOz35D6S3ja7Ytm+277BaYGOR587DeTwo hG7rP2yyr7Vv4Du1nUWn1d/YchXnbFdVi6zIFp/itTTYWmwtdq44VKfb5ra7HQ22Bvsae5/t gOOyRduv7i/dGzisHv4v1dUC3MRxhm9PpzvdSXeSTnfSSWcJPfwCYWzwGSxw8PEIDzvFdgHX grqxh9pg0gSZkiEwNTaE2pA0gykMhITUZlJqGjLEmMZgMjTgzpA2Mx2YtAGSNu3Q8ohLHJgM Q5wSn/vvSS1UGt1/u1rpdr/9/v/71t8ZpFmvxDqcwnLheWGnsF94U7AKYd4h8bzD6ZB5nzfH 45JQg9QrkZJEhCMYLgBOJmwCthR5BO/iSf7Pal4v3U+fpy/TFN2ViqFwrChGxiLy46hFp695 hBpWyfqMRpoGwkSuvjWjg5jR9QKYK+TOaCJU6dZ6DOgME0+QQZ8nYplGxmJu9yNUQfo23Pm4 Y/hCQ9v6U8Yvrmxc8YPmsr98vL6sakn2b25bz1Z9uOPo1azSzuPGP1D58WRk/LBlWXbd/IrV DiuuBBUTt6ivQOOmon79iSH3meBg/sWpFAiZDEImK/Ema1P+JvoFflP+J44rMUeSWymsjCZj 6xzN4tpIS/7aqZuDncEDEYcYgzw5FZqk4ag3+QNaTbQmdiF6IUa1Rltj26PbY9ej12N0nJvC Z0ezYwlei1VylfzC6ILYer4ptoXfGt3NvxT9FdfHH4t6WI7l6Sgd83N+3htlojGOp5CvVtH9 YW2DgjYoPQqpnCWbCBWyzxFITFKRWiBZiCUIp+PSQFgrQjqqRg2oG/WCVz6PbOhLSg8kXBSi Cqawyt0JH/LpHp/mq2TycgPTJuX1uvpdpKsS3XWnN9Bf8FGG85XL604SemnSdDimGb4f34h1 tTV+vz5+Ix03xm+IvkQ6ZU0xigIeanAu4HE5E/854ElEAR4I0PrDgIhbl3WnmODDYoIzP07c 97kuOKCPT3AK/pgi9uiVzKSaJ8eLtdqkAX6XaDNnFoeptJAztCz5vJTJHKzyFSgc6Onas/eJ p7ShLxu62u/+GknIxxjXPG1t25cWTi1F/Zee/9kE8b7xL+MK+ixr764tNdpSVZw2p3bLidTv mr/6kG9dUxJNaDmFzc+ee3nbX59BCPNnKtScIdP1b9RjhWwRVWStZlPgp7tZhkZWMoeykAxh Y8F+U+1YH1CBztEMOHCiHWcJNN0WoZpMkR1kN0mRftv42xnUa+pOkoA6qH095AhcwH3fyNSc MlPaoCCWYC1Hfze+Q71iLKOGx8YezoVZ7QPnlg2z8hMv6aWMjWEZFxQJdrFtMct8j611HXAd dL8qv+7tc532XpVv0g9oO+9wgDNmcjyswx7mLwlIwFIW1dVqtUG1pNQOlQyrRWqvel6lVASa HvYX+c/7LX6c6IHHhMv0w2nVAs0aNZPdlHhPxA1b4jVTF2q5SyBj0Vy8b/tQvt2z5yfbOgIo v2j7tRMffbJNCkJxv3WudNWzaw+csMS/NYyxTw8kG19fue0BrvRdE59T+81Kn0W8MUSIE2P6 dHtilrpYJcVaupar9dYqyayvGbqEmsPP8ZSoT1KVfKXnSXU/c4jlHAKYCSJwhtw0YGUkCLrH bncSnC9iC6RCKOSaTFpywXdO1h0oRXTgXAiWzzMX2ArHnvGyW8tAAdL1fxSvEAjZCpZyQZ1u b6abuWZvs9KSZa0H3TI9zcziGSK4TFhtnuwBCNKkBbPZhfw7BoYNY3xo9Uld1JZuqX9x59qm TuvZ8Xv7jdvGN8Y949PVycPklKNVqZ7jg0fewIxbCWsvp+bC3l7Xa+qcSTHpXedsEVu8bcoW /0HyoOOi66Jy1XVFGaFHbCOeEXmM9pR6SuUKscK7SEk6WhzMbHGWd5Zi2Wzd7Oyydjp3+4+J fd4hcdDLClgPFVXD8V1R0oRiHvf4Q5oZnW6NP4soggPMRLed0GEoocM4orgbIXQWcoKCr8I+ BuFeFCEKeXzDR6qAUAGViUj+QF0aSmzRsUOP3x+NY49efyOetugQ0xkOmKZNuSxhzGZZaToW xX69eIaXmm7cEdZUtbS1P1PdLCMpfv+PI8Yd5B0dvkl+MWP5ir1vnTu8ekPhb4dRLqIQg3L6 MG9WAHaNGd506wVikk5ySTHNlleBGmMsmwp1hMjZFs0xW9b8FZaFjgp5of8Qy0omXeyYNbpg ZwQnbAXnmyzwuQgzxekkAnswdyI2f7Cu7H8rbH2QZoyZt5gtGV0DrvAtdAvXIqbZQtcnI5GS zALF4hk+8DqPU4VqNB7OO7nqtPHQGB7YgfzjYuHCrY27dq79Ydfh1UmUB/VdQP79pOvb1FtP PXf0l6eP9MB658F684ArEpGF3hwiXJAni+yJQ+xr/AHXMWsf9x77Hn8mYLNJaAm5mF7EVYWO 8YP0YOAD7veOK9w1xxjzNc9nObNkXQ1qsi64Naf8vnxJtsgmG0LlZhR8EMlXdDAVYrXQIJCC ImIdGvSrGioWzVNeMJw+7UUnp2O8IB2VLDPqTsGp9QKkhAum/bQoAsynKLuoYLiz7QwRQYVy mkSFoadDG0I9ISrkjNh03qkB4C1pSsX/79g3CjKkS4qeL5UresgJF9UFlyx3uaki5eOmTIkw CRgh4snAIDPCOBwH/jsUjium8pg/IOALMYEnPeDDof8Uy801m/Mi5XECj78RBwNTbz5e0AEl AT9UwI+H862vnDD/FExjPA5iCe6n2KyPUC0QpngYSiLmOGGJmNXSk9YzH/lvpMwcece489MW JP1pFIn0uG7Z0Th/VZ7lhdrvl5Uh9N3C1468u/cz4ELc+MA41/byEvSjre0LFvwY142fg1Il gfteYkCPO9EklEDFZLFrPprv/hv6BrGM1WvNJuvc69xWhEiP5BY9FolETrwDQQvDcpwkc16C sHO5NlYPZ2vvsGiCRWxAwfvnjWZr3UqvQqaUewp5V0EKIeV6ZXNrYWyvjO7JSPb7ytOpAS4h c5yFuweZlpkj2BqOJhJuX8IiuMpspnRAxuAiGiJlqKaaWRJofIuO7zrXeLgqaNwO1zyx6Lli A/ze+M2eJalde8b3ktP7VpUs3N05/gUsGki1D0B42zzXMsTmIYLFJ1k3V66z1SzZwfaz59nL 7F3WOoltYNvZXuiwWmiGsFIWyPT/sF/lsVEdZ/ybefPOvXffenftBXzu82LideK1wcbID3yE +ALMFVNcjAsuiNNuUUmUBKciQkClhjaA26bBQlFx+w+Oc9moUlFBSaNShaqiiggqSKAaqUWY KAFE7N1+83a5GqlWJVSp0s76N/PNvPF78x3zHaZVvwrQiXFDEiWZaVRGv2IVSnmFcRZS0nw9 5AOjNOa2gujmHHEuejFF8vFDI35KQolxEmIfEJaY/LqJRb6+yKP2gxMuHwMR3x3l5xOXirRf HBZPi+fFm6I4S+wS94iDuCDiYQR0xUKEwP2TQIh94yTpb5enviueuteI33oFQBpAz2CQ+WMQ xf/uxG+h9dn9UpY9LsSVeDBeUE8blIZgfYEdK8XocrUr2h89Fn1bOiH/yv6+9L59OHo+eiXq hGgsuhQf/C56OSpFzexwvBbn/dZDUc5jcvaMLO48NTmP29JMJrs9HiMnHI4YGorT5Y54Peaa ii4P2YHCGaWNpis7JzIjjGs7wqQrTMK49l4Rpgrc044AGJbzUWv5aFbiuQ3capgLETWIQiNu mNUL4jHjU+OyIbiMWUa/IYCRa5QZSYMZoeKrKRGly0tsmLPccE/V3MZ7jsnV7d5OPtw3R7dl krU3eJWSqkxIX0kvN8oSX54f7TIrUGn1WZZ5Gg/M86GlvkKEg6d7jpQ1Hl+763gx2usMY9n8 TaWJ8Zm1lQs3PZUYZ5FDv16xcuWKdWvrB6Y66Lq3SmsWHzySoLTxF2vmNO792dQkWnA7evOf o84cGPuPmouvk3Hlju+On31Mr2N5GxJDKu1wr/KtyuoIHqUD0oBy1D6qXqCfi5fUC/ZxcVy6 7nCfUP5Iz0lnlI/s4i5lv7RXETyWbmwBrhudyXqVnN2VszOH5jjz4LFgnUp5UiGMpzu9GMPU ze4ejGCbg4zwdAeT8rgXZQF+HdOdwkiR/jCCtR+YevMWiSc++edPEncOkNwj27cfPrx9+xGa /yMiHUh8fPNW4sze5NBbQ0ODbw4NcY+1D0CYi/y6YcgsPioS1UmWiz3iLlGIeZ93bnLu9DJN ddln2emP7Uk7rbUvsVP7KP2BGZVlDM4ClbRiUN1qGSbkTM3e4z3mpeu8e7wnvee9zOuGCBF4 6LZR2o9FEiUhT+0YCcP9RM8yiTarbA21XoNgKoKj0VQ9k3JKvdA8HFjePFyxbM3z72jPzEMB 5GFK7ufWEJAt3XvIIF50sW5LfVfH6mcXzG+PscjRLfUVX5Uu/E3iFvI4K3mdHhJ/iRr9kxnF pJoUaFFXtbPJ2eGSQ34ICll+CHh9WKt4qU6Cgiprsj04SojpgsBgYDggdOFwOiAERgkbwUSI B07wS7KVp9htakyLAcTIOuQPd5jFQSES8K701+rH9JO60KX366/r5/UJXQTdrefqZTrDFG33 4P0L0jw8FzmcjxyOgZ48zcuRyVQ14v4yxIVyg5cjfOs1vBqechc2Lh3iL/DoPHzNDUjpNN9T UFFeUeShL562GWGjKdj9UsuLVTb11VdJNotcSaz4YUk45+Ls8mUNTx8mn175y9uJ/SgfO0at LhYBG+k3DxbLf2B0QB4jl8gFecIhKnI2C0rF0lyYpywmHeQlskvWIqREriTVciNpkgdsd6W7 slrEIvJsLc6qtTrWpp1hSou2gnVoG9g2bTd5WXuDHZFPaRfYJW1ScwhMxliXxXLZbK2c1WqN TPWzkFattWlbtBPsQ/aJdpup8mhy4l1vMI4h4LN3/QE+XjH9dk+cME1mQK1BAVURBHzyQfSp eFIgnDRdWYVxIUJVnVJVlGy29OMJG+GkGcDHtgiIOoAoiSLasKKqNhBH6bYRqVzFwbQpG5c4 jjmuOASHwJdpuY0veydS6VMulAGDjfazqMOQpcQgz4dCWJbdtiiIWUGWd/vE0pKS3pJ9L5/d VxpMU+jmAtzPBdDR8Uyls7e3j/CunJA8ny8Pe0Gwkz2JQ2T1bz8iTYkBsj9x4rOLtIAKiUuk MKFO/Zk8l/iQ32BnYhlrR+35SPw9b7FIfJzFoB1ztixM3GTeSbwTs3CNcnc+K7s6jmGIOWxO yU3BJzEfZYKAhYXk63IT9yg5aXptLkfMWQy5/jJ/l1/giYWVWkbiVr7hDc+M+wOBbFYlmMFQ fA8XPDFMlVozSiifeUkVmOHKOJcW1nf62bTFl7ROhbDHv+BUW8PG+r+jVPpa3V9eQ8/XGau1 ggFBQ7cigRfzlCrZyetbKCFWJOlsHnbjhanGCzPC3HAqiVpJTrwjuMk8bB1WBikmr5tOh6fW 5/aFsPMGa0VuTjjh4wjOU+/q8Fnylp1CQb5hWCWQEzO7u6Qgsb+uqG71nqXL2kKLKrq/HWKR KSf9YpKOdXYvyPdccnyvA9Jt6xPC758M6Bz06W/gnT6XgnjgcUjeR7A9BaU+BVVPQdsNYB8F cLQBOEv/e7hm4zXpAfCsAvB1P4SO8LNHsBMgUJhCUH8Ed1PIDj6OnL8CzFiRQQYZZJBBBhlk kEEGGWSQQQYZZJBBBv8/AAoEeNNB4BTJRkgwbRMen3q/saGwKALFOM4BiMHTUA4VlXPnPbqh ofHZxQDNLQBLlkI7wEpYjavfWjv9t/8njcEg9vmQixTFPgZ10ADPQQu0wVI87EbYDNtgB/TB 9+GFZBL38j0LH9nTDt2wCbam9+xOJpNX//MvrYnpmjDtDgV60u8SwIM9SXPkwV+KlpDK5xpn Kq7ko3pSNAUn8paiBVz/TppmSL+WpiWkT9S1tDY1tpYs7Nu8fuucRTu2bph+AQXYAq3QBI3Y l6Co+lCE61FAc2ARCmkrbECRbYTvwi6k1+PT6fc/iR1cIqIbvoAa5FZECbgtPYLUiloVcI7M k9fxicKQ4rP7I/RQtHvyoP27GmqxgYl28YLCX3NO6WY0rQ0c//F52811rpqvlJBi7T5+tWYG H0eaL//t3r3JKXeD0o1Trh/rzf8aAJ6d8b0KZW5kc3RyZWFtDWVuZG9iag0xODAxIDAgb2Jq DTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTc5MiAwIFIgPj4gDXN0cmVhbQ0K SIl0VMtu2zAQvOsr9lSkQEuRFB8iEAS1nRxyCBogQi9pDqwsW2xsUZAYpO7Xd2XXsaUw8ME8 zK5mZmc3ueg/F78TRgnlQPF3eHHBCWdGAeOaqJwyKLbJBdgG3DaKV4YINka3vgu2CdB6FyvJ mCKaaz0uasKA/YoISiUUJeyfzEDxCu86cEmYQNiY5E/OFYS6gpUtAz5sgIfbe3hw68ZuXLOG 2vbQxCgJnRNhRD5u6KPQXBCquRlDQ439Y3BJJYqdwiF4GNB7tfxNLdKPqDX4QMs4H5BYvPTw 6kINHqXGPslERowQalzVQdv5EJXENCd5JrNxQRmHapLrKdRvothcEkWVHmN7aG00SFQQodmk cxdc6VobXHRsXDCiBZ0oXYNrwMIPfwpUdrKYxSzmOSNcGzNuhNn5ZftqCdEU84xgFuREnd+8 BOebL7gxSwjRwsEWM/1WXbkO+qp86VzYYVD/2m4ZTyonRtNJdXSVh1BTNoUS2Mu5KZKbu0WS 3sPlZXq3uL0G3OKrq/n1IpkXSVoUODYoVgkdnKMfxRJnpukx0+dtZzi4/RZi92LXVpDe27Vr 7OANpLMQbFmjsY/p3Ifgt/CUzuf+Dzxyjos4UM0kkQrdzXJFKC4R5HiXDN6lp3OS8kDyncUY CfRJ8BOxGESxwxV5A51dn31WolE5MhSGGP5f+8K3u86t6/iFFCSjmRwVBDxWkmHoEfB9haOf dc+Y2ihTIfEvM6P6T/CtD/a5OtFm+sNJ4deJUlSgmUQdBbPzef0TYACEDlXbDWVuZHN0cmVh bQ1lbmRvYmoNMTgwMiAwIG9iag08PCANL1MgL1VSSSANL1VSSSAobWFpbHRvOnNpcEBpZXRm Lm9yZykNPj4gDWVuZG9iag0xODAzIDAgb2JqDTw8IA0vUyAvVVJJIA0vVVJJIChtYWlsdG86 c2lwQGlldGYub3JnKQ0+PiANZW5kb2JqDTEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFy ZW50IDE3NTggMCBSIA0vUmVzb3VyY2VzIDw8IC9Db2xvclNwYWNlIDw8IC9DUzIgMTc3MCAw IFIgL0NTMyAxNzcyIDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HUzIgMTc5MyAwIFIgL0dTMyAx Nzk0IDAgUiA+PiANL0ZvbnQgPDwgL1RUNSAxNzY4IDAgUiAvVFQ2IDE3NjcgMCBSIC9UVDcg MTc3NiAwIFIgL1RUOCAxNzg0IDAgUiAvQzJfMSA0ODUgMCBSIA0vVFQ5IDE3NzMgMCBSID4+ IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSA+PiANL0NvbnRlbnRzIDIgMCBSIA0vTWVkaWFC b3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUg MCANL1N0cnVjdFBhcmVudHMgMyANPj4gDWVuZG9iag0yIDAgb2JqDTw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggMyAwIFIgPj4gDXN0cmVhbQ0KSImcV8tu3MYS3esrepkACdXv bgJBgMQxLgxcB0EsZKUNRVEaxjOkQnIs6H79PUVKGna7KEtJFh4np4pdr1Onzv8QP/10/vHd h9+EFD///Otv787O333Soh7xd/pXjHV3pkQrzs7/bPbV1H5p3vX7fmgPzTS0tRjas/P/wOB2 PPv14uz84sIJJS5uzmQhpcSvWvxIP7UTF/dC4aee3S6/YlmU+EcE/DV4acXF4ey7i10jdtX3 F3+f5XClVaFUaVP8MO7EOPEGjgxCTA0mHmqKGHLfzaHpJrFvp2ao9nvOTuMPVzqX2j3wUFe4 kEPFeLy9bVi8BT7q7PXjNIppx+J9WVgXsnRWk7hvBOHnkphTSQJXEl36QqvSZ06GRvTcN42K RRmDSeEdC9W2cP6r8PvjsOHa4Y/ShhR/z0NDYZzJXyHu22knWINIUUadGvTTrhnEHWdgFb5g Y1aLgYVqIGR0uW82SGuQlJi3Xc1Dy8LrMvfLdqW1eK7PwhvF5Xf/HNHLp27Qp27wLw2oL8tC 20c/x+6a7VeldKENeiFBD1uzqWMRS2NTdHfNg2kUXAgp+Gpr5mVwGZTNEs28Lq1Koc3l94WY U/T+4uz9RxDiiSPVI0emVEdJlC+mL4YiROmWjudda871jzmNmhc/E9DVT9X+9TiJShyqv/sB fNF2t6IdBZ+xaIpS+5Da8yXGp5y0MYWSc5aQJKrmwSUJ+qYfbvtpajqx42nPgVJcNKnV0Pwg aDyX5v0x717Nc1lZSCszT8Rl1zxBqSKUOg9ui8ukUpnnmxu8D/vibtiYdhNCUVr8SMzYaTdR oyg5tN8T+YPSa55NMFM22OxZB7bq1urCmJBXktLc3zaU6h/Yojpp8A1ns6SuymJPZXmxW70t wtPQ1f3hjp9R5QtvKdNrON+cWtPqsikUdPdX/+EPcVWNzTUbkaLpDNTUa7ux3x9ZpaAliIsS t0azXaIVqMhh4yXQvhNVdy3YHaktkoPmyiz4McFwKemzaEXf7R/EJwT8qb3tWDI12hfBySyl e0zxJu+Zf8l7RLDxadPzru02731rvp8/Y9Vpy/3eg/fGkc2Z0lBItoypRd1C1vJbJxSqpN5b w0F2zRewF0Zkg/U0WdnU6uOHj+/FXT8sX3odr2soIK/KkHrq+c7xgMiQYbHxr/rrh8vvRX8z NwV2QIcEjewAQTEU0ZnMx9D2R57MaBfIDD3OySnEB1Ed5k/dVId231YDxBhLQ2WA7jZZER9l 25Im95wmVb7YBkbSFjcLIXUPCw/X/Z6fehRXk/PE7J7IdewpiGGjuuAj6W1qNnPyGwqLCVSG +jD5drvf0yUDxpr9VeKuGiaqXAvNf1fVn5vTJ+IpKaxyM95hyMssvIkagF83igSxT+GXWhuq IZ6wg+HQjHd9N7ZXKOj0cFKRrzvzhMetEOLzPr/llZ6cwTpDX/MDio0tfXApmKTOxIdJRfdl VKkBPw0KOkRrkrNrbH0cEDsSYwtxseNpX9qinMVB8hEeimgdccUaSkWq9tOO531rCxNJ365N jrf8oaM9zlppMvRMRmNTH1+9tI2CRgxflaVlN6ShRWxMTMEPPBRTqPL3zVK1IVl54Ikqksa3 mVU3tX3XXIN7psUBRCa0b7/MFE8+dINkQYk3DvNTd8twkkNEtSDethnF/a6td4Lv9eDQvrgU E1v2qFQByk5T466hjUAlt1hK+TKDv+dFCkhfk2paQ8X0cIfH11XH3wzaQ0MgH+lzWGSAzoRW zvzzM6cjRE3MH4OZe5Rur9MF1Ky2LLPX8UtM4URQIYOyszprfheyt22cB5DGimZ0DUU7fzqf R4/0H/oSkuszyQhenssiGJP11YGHIoZgsjbCvsUW5dNs6bgwMou6xvxsTYn1Ogu8Q+cUG5rO /Ru5KLCtSI6al9Si31aLrzo7hIv2JEkXopiG4+PGXSmkZdexPapBhdK71BW24r4RuG03aFgV HrSY2vx5AZY4LlwjT6+3bE9LBVUZQ+qhnQO4h6zcCbY3jLMQad6kZk23UWqDm06FPLaOmHhO 0EY7adJwMaZWtClhxxo4GHgbvk7HRv5siY0SXPYu0nhvPDuFAx1BZi5N1tOZi/NwQ1zAIoK4 EpOahRoQOYg0hTZirHDVorcGnv5L/KGsTa3YnlMYDVdqn0LHu03uVz5koUJJznqY1xSmAGeZ V4SqbSwMDsfM+17wUsjTojZZ2nkphI0iHURDAgVVivZAd1P1Fv5HBsoyy0A3iakaP4t2Od36 L7yymBdnZtoMFUnzZhF/JIcrUfdUW15XOOkKhXWdxXKKwJ/Ue3ypWZE+Ix+7/a8e7DT2+yPJ HF7ckpqxOjUTV9WGvg0ouowZ/HpLfcRIRU889x0xJvRWhyuvprvp0FByng+DVaHYI4XWvXe4 OhK/VJ0lTn63wiba7C04S6iwPAWiGNJlcfI5oavJG59hqexbMjSoPIO05lGp+Zq7avCqL9X+ WNF2uN813aoJzCk76qUmwHqHOF0z1tNhy58tWBTGmtRupLpQYucu4nWgWs6d1O6x38R9s3lf lCS1Equn2I8jNsAPz6mo+7fdrwqUlzo+IPJDO0INkoSqro4j6X1eKoR/IUIi0m0iiZwXVUjk XG86hBiM8mWHZeLQr2XNfH48/cKzHz+hRSkFLsdCz35xcSnxyzRV9eeFXZ9hykmsdKNW4Dl5 F7uhwUb/2F83+3HjWUpuy61vdS89D5olxOeDaG6Daj/2S2ugiJjYmm1iLcGbwdi1i54smu5L O/TdAQpm5BuSlioUz9pyPOICe8v6gNAnHbpyUY0z5Q/YRLgleZ6JUOwqhLXZf3/5naZ+eP3Q W1wZXqPWKy/NPLnTUrADFWzJ5at5FrWwyAv9T7i7WvxBnPBapoTaRxgrC35/WIge6+IaWKCt lpeyFhGyz1q9tkBEYCbaHGw1DeSrBbGuLPpug4ocqMirxPvYtTc8bSHIYNUae7OoXNB0uzz/ VbLS4BpwWiZf5bWQ0TijbIrkD02D85UYb+2SbpK+2z+QIOK7jzR4SIw+dFMzdM0kaowLv8Is NAOUUlLEGllALi61dIIVrrb0UDXWr41YReIwxgbXwRrICgwn6SCQyTPEhzcIJupwEimPDT4t 5wpVs2oPdCMd+gGN2d9Xw/U4//cj30O4cEk7n5xtiFXwbZngqttZ+xDR3fTPk6lO3eP49gE7 EyucHA2iroahbQZQDptVA+FmXfLxmUpBNhQaXzLqqVLZlQ3r22L6pS/9Cjcfte10qbUe+axZ XI0RZ+O3smahl6ILedb4hlB08MUV9L6ddq8/96ghPIoZnyXl3fFqv3HohSLMzzoZbJx52Erz sJyA4mnItmQIDsg36RB6OBRrcJB+LygG8Bzn9rXbwNpiESTE12PDK0lNS9jZFZqndRCbccat cDU0I78zDE6UsIZunDLgZ+XWuHlN4ALjF4sFHJr3BJ8PNX4NaVkWpgx6hd5jqV8LfnQ0UGWE gDrB/zezCFilq+bVLk8Zt+ydQ4Tpyrh+H5sf83/Sq7a3beQI/5X9mANyLPd9Fyh6SA899AoU PaQ53JcAhSzRMltJ9JF0XPfX9xnKEXc3s1aMfIkcYGZ2OTvzvMA4OhBrEviIi808n6BH1qT3 4mtq8DRoKuslMcnY7Xmi8raxLqYJ0wzZQzbgrv83jy8QuV5lF9/+p+chBhEmuJiE7tk4CNfW 2fT73or+eA9gHPjCCy3J9N7sXRdW0jG960zcz8XSrtDW++dt3GAGx0+VNaC4YPOEkQ918GhB 5aFvF11e9XREJlk8gRoJYXoX9uXJ0nnZFsfwggia10C95qFi1536zeG8el8voJULjSWEzjvx qd+Cjs8ehdcw5JS0Le778Q2pQzE/3bNt1yAf3cqiN1hNXiXFxoZQfCa/NhEG1NGYZj2HgTl8 /K4RNVjWr0d7Baq7hvambsTiKo1YiUFHAPHwBecjfhbHB5ae5TIDPubhLPZICQLU0eShgi+r yCfIPJRdTKlboF9UeejTWcv9LHbDooI3+7Ejkf6sBr6EazyXskURXsUZEL+zOg/lVwnmQhtd fPBxkXyLmeLRXDWh9UV9VlpoEsCmDO3AL/3A1zbolQ/FY4n7sZsACbVF8TKE4ojduZX0Ebtx c1vXMfbVk61jgIi7MtmOK8sVC+66KPJZMZeuiV5u+vzXI+mnpfy5tjcNQRkqA8SBteI9uPFC en8F6RGb7WvHhmprXhAFdK6Tz+IW6lqTFPuJ3zYwvTIhiX9foxUXtE7i/vF3cVdnFJDrGtpt djyvwW5o7WwSOorbvjvsaPg3i+MZu98fuokdO+UVhoDm75L+lo8jmYIXXOPE3fDYferGtyL3 U1/yhiQ0SlO3LMBoDUJ0WJo18CRuwKLDrscXsdZUR4RiPdN7bcabHsPBCyHVRAKKpFs1waQh y5K4Hprs5mnZxOGRVzjYgYDq6avxSkgByVX+ZHisSxvdZTZ1bTShvhLz9Os7TKipsl58PTbo cHWdVVtlvfpKwcx9djY9LzMkZJFTUSWx0xZQy1MSvE0LrbjGjjVrA1cRgksixbDdPoyTeORX MPoGuyWThI59ddUCRp1K7yvOb0IWZHPiaRAaTOksCXv6y2UC9IpOntVwAQwvYVnW/Lvh1ImP b4axIt5IEmSfA7E83M4T+GXLdkB7qDEt05SP3/GyDUQaoXSSDvBxcC4RVie5AyT1c7PYZzNw pJFU+5ryyLsRwhifhJ341XMwFyqmVxjpme4PmyfeD9nWwG75tAtnovl+RbzzQ1V3VdpVoV7Y fMuPqYbmCdblSafbfv+wsB3PAKGJ2hYpn6XPriNhX1XESr4eG9ARrV5EBvVcVC6ZYtqenuv7 5/rPGPElWaA+dn8VQH/+9cOyFGuhUmCHVWA77sYSP85go7K6S2/e//SjeBz7uRvFPMywDk/i dhj33Xw+8mWBoDQYEfoxrzuhMK9QwejWxjwawrk/nRVqByzq5yfxOIwHXlHC8NAnZgWW7Rk7 GuHTIKYHdualbowrG7ClMeRH3kCjxxaTkSXsxWYSJIQu7wEXqS5vEi6T82WrjPNg3bJVPx56 aOFklwI/EGdPq4Jc1eo/O1amS8h05aGhs2C2KVLSTeAfs1B6gSvjptaxUOy4QTnIQN1OCxM9 v+UhTsIqWB+KL2RViSQ0BCznoQIiDEM0Pkwz/57giUZHW6TteTIjvDXFARuxXd6qEb9VhhsI 5MAUWRoN9xmDztm5Sjy30HIthMykcSnKwQgdDuJhwrDPE99KMgoWF8kTWcLQiAjW+DyUbZ8G 12qviqkiylqcL2BjeJzEXX8EiLC8t+hCZ4sC2ztW0mCn0EtfjMNp363y0K79ixWMVi42QX5u AF2TlPriC/jBogeMKs/bCbzdY88mBICqDD5PmO54ixLhDal/WSw/fosDkHnoD7yEoh9jiytg 0Zz4G7vySuEjJZxSfo8Z9ujI3huqDi8gdZ5w5O0RlthCAmWhN92zGMvgJCRwsq6C5EkGsxdC WzTkNMw0a7TyvI+CyDF5ykxLzAYvyikWH7kubB0Jr0kfjYKOpGxWGRKVZ0gdAD0xFu/JPowO UKbeFxMl7sfhhh1vI4ELRhfj3R1FxYIYQ2Sti/oLzB6HMdnEhAxY7UGbCGxU8XLkPb/1UmF+ 4E6y6IlfPehQb53OY//X7Xg3ZRwWlbA/jX6sLKozAF5IySyY5xQaeCWLG0PNzN3h0O/5fSJ6 hsL9ivJqoWcZ8tAtsL+22Sq6IppHGK0brctQAYAkoupgR+4H/gwCsVYWbT/N08fvmpoM1q/W 1grPddHwtbKGK8sVg0LV8koxmxVzqz5P9pv+xHWfy59rKzzQ2QS8e0DrTnO/JYNyEovDed/t +2keN+NUO9exvaHDzLpUodYm/HX2Yh/usMOVNZZKQvlHmYRvTsuIjpXxpyX0LoknSbWvjYSM AGcdQxIPPXvTbdkVV5p8SEhvw9OUdg1ITKW36IDefLCDtofxS4P5uNAYn8WBm/jVC7ZxzqVf 1XU7FoYhVbTOzk7U/FV6wI9qyRRc0sFpHb0OxBRPVaZx2mXvQ4IQH7I5okW0vCyca98Y6MJ0 Dqq+x4fsg6ZHVmkaZxtvfHr5cUcocugqqg5y0yh57Z1sC6kYsriZyq5tdatiqG0H6X2Q45IM ULvtR/Ys4pzWYN3SeDH3R1LYEEXYYB75Sc2Bf9I0PjA2JiAiCewqV4kYY6WzUH6lgcJSWZUG LoCzqV94wVRlwtULK0MXdllDAGGNqGGYfzW+S/IS6kVADknRH9W/ZCK51AKNX76jJeEU0XDb LLf+Y9sGjVnRf8IRpWy7NkCLyczKvfmNDMRiv56GB7EbBPTDaSFMajqvh6HQtE6LEB0sBNH9 974fu+mHalvjtQ6w3V3bABXz2ThVOvFV4m1tRFIw6QWrYmUEJlrIhCyJ13ygj6iizUNZBFMt 9sP4MhSPsLzEhjdIluo/y7pLEmzrqYLnJHGCaYsPnshqjN33tafWhlC5PGaaLyJZr332LBFY hY/L04Hpm1tiAgzcyGv0NjbSmOKytUsaDAf0pC4vmYwkm4Yx9hbXLg5h22eiaWQwRfAPfCjq OlVcvrYQuv3GhUCDg7oKDMk+qJf34VLvzW+0CAQEGCvYr+P9WUeDlHkVAoK1Jqsw8oHQQNbY NFBs9pv+VEUNLb+xSfB8n2X9i226pmvWNiUV3/yMNSKpeuT1wQIb2tk8iXdeBBuwdXkolSdg egEOoG6llj7Pq72UJxEaikP4tyKoD0HnoWeIPLHFSflJAt0s47xU7dpdw4KFWlJCcRogCl8i /hKlZD9eBxwZZdFfSMdP/N5Drinvixtu+VAHk+WLtrLfbSREoLZFKKtZjAQUe1t+JklcXuHG prWQjVk4zRv2Ev+ygwSp0wRZPgMvd2k8Y1vcfOYl2mX+VVy9bA2YyXM57WUePZFF2wkgCc+G tmmDL05YBu6GJMnvDz1lz1fchIyNU20oThbbcRXbiRVlh1FD3MjyU7sdju03B96Uah+wLtbl OTfd7TDyX0tE51x5yHZzOJA1JbS9Hw79thPDuPzv6x3Y+lIyYIY/X//YjfuOh54AGeKjyhO2 T2JZpC2PJApwpVWRwwt1Tf6rDK0jvvpGxMfm+pcR/5U6MSl4BvyFF/cDL5EJY4yReRo96RnL eIdigeHkk9KcLUspylrMjfZ57HSHzehPmLYjpA+/FxhQpYt7QSQR/7IJVja6Dbb4kCpYaRBG 63TRr4Xd+fnXuI8vvoOXVaQJW1u0pzY++tXuLdpErFWqGq4qUwurFCRX690497eb7UwlPzzd d+IPv2z+T3cV5DAIAsGv7KlHQRCqt0of0AdYD6ZJDTEVQzm0v++oqcEE77swMNnZmd6Oq1Fl dQjdY+awYcaF4F7UMmPchxqs66wQCx+Z0vBOEvrOFVdUilmzNbUxsiqNTCIfnuHHo4yaKtE5 zDeO3opWxVHL7x3J5YawqOZgki/dVzd9ve2TYUrAHUsu1a4h0F2oHOODgtvTeqr9YMc0UowL tK/a9Z/o8g7dEAklPNER6bgdQ4Q9IMtM/x8sYr5+AgwAyucjAQ1lbmRzdHJlYW0NZW5kb2Jq DTMgMCBvYmoNNTY3MSANZW5kb2JqDTQgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50 IDE3NTggMCBSIA0vUmVzb3VyY2VzIDw8IC9Db2xvclNwYWNlIDw8IC9DUzIgMTc3MCAwIFIg L0NTMyAxNzcyIDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HUzIgMTc5MyAwIFIgL0dTMyAxNzk0 IDAgUiA+PiANL0ZvbnQgPDwgL1RUNSAxNzY3IDAgUiAvVFQ2IDE3NjggMCBSIC9DMl8xIDQ4 NSAwIFIgL1RUNyAxNzc2IDAgUiAvVFQ4IDE3ODQgMCBSIA0vVFQ5IDE3NzMgMCBSID4+IA0v UHJvY1NldCBbIC9QREYgL1RleHQgXSA+PiANL0NvbnRlbnRzIDUgMCBSIA0vTWVkaWFCb3gg WyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCAN L1N0cnVjdFBhcmVudHMgNCANPj4gDWVuZG9iag01IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlIC9MZW5ndGggNiAwIFIgPj4gDXN0cmVhbQ0KSImkV9tu3EYSfddX9KMCaFvse3cQ OPAtgR4SGNIEeTGwoClqxOzMcEJSkvX3e5ojDbvpouTsIjA4jk9XV9fl1KnzT+ynn85/e3/x gRXszZt3H96fnL+/kqzq8ff4H+ur3YlgDTs5v6w35dDc1+/bTds123romop1zcn5rziw7k/e rU7OVyvDBFvdnBS8KAr8qlj8JQxbPTAhR5P4hIK5InDrI2R7ciolF1yyi+2+7vp2h2t2a1ay q7q7rzv2w+qvk4+rk4+/wbnJX/Hk7+Fa+3RtvPFf8Uqpxyvx8+nW8RcutsFxacdrr2qYLzfs vt7dxUvmaKE9VyHY9Ezds5u2g3PkAa+5tsGnB/54+1lK2ZN4WeACqXSK7+q/SWekjNhC584M bGjZl5q2bgPXojDpiWY31F1V74f6mn2hDikJrAkiPfRIApXkUoUUx/p2W7N2uK3JA15wV9gs OB3bl93w+ONCjuVCjunEesOdPjhCm1OJuffy3+Jg71gu1TdWhRU8hOCYdZpLH23/VBReobbV G1wxOTUaKfRUfpSTwoVozibmTt9WFRktWSC8RczDhO37mO2F8CIXPJhYe9MB9mfT1awcYmLI M8HiI7JL6NwVgpsQVGZ836KaWHsTPWJdezd2Lf56dfGJXTXrXbmJ/4NOhX4tFWSWp3xYyZ19 IR9jOvwxHeqVfBzNnX74/So+jIyWiK2hTArvW7pXHXc+6BS5a3YkVAsuhPcpdE0DLbfBhhS4 EFzzfwbXiNjZ4bVyF/YY3xjql+KbWDyN5fGpa78+ni2FDoHOvThFTS3VvLZe5uBP7LK+RuFX 5BGvuNKzV54OZ2PVxgPjc8zxZT5QL1P4GBMTnFq5rNdNP3Rlx6qurP5DJ1yBpqxxIT9KplyF iLAih54vlKcuHFfKzXyiC1SjlL2LoyHF7p779Rs44mxCMXNkofrs4mAmy86PNQLTuMP5lww7 yvCiOYxLzLEXPfVPBkepww1Oj3LnYN+lxG6o6XC8SljujsXXtV829ci2iYKaDwo1DQpBdo7C R4Tc9I/sz1tSdRg4r6zL0WD9h2azYbflfk8PGJySiHh2qqZJSghuhZphYX+4Hcn//S1NmNZy 49zMMbotHQaMAa3lb1i3vGq3rNxdk3UZNYiQYebXu2bTfm3Gg31V78qObhcBGgXT5GcXugW1 FObXsOaGfYHYOYS5JAOnnedeOJOf7B+gakn1ZSAI0fGzxJN60AgF0zPLAxmmY6EWhkv3DF3O m5BIt4pKLT1A5k1ITCU3hz7l7SB8y9343jFKUKo3TXdQrXQZFNwWeuZq2XXYO8YDh/aRU/uQ gx0lwcFZMjfzBZz8M11HGDrezq9d3dZRPeHPrmXburotd3QlSQjPIsxi0JOKSyuPXESSzrBn aCM07AUrUewP8crjYw9T9kXqNEFx98x17c3Z4Y0Z+/iUfV4LnyhQWsa73PDo4aHWN3U3jI1f ozEX2AUmEJLcNRqJGe7s7BVRWY4XLilXiBWhrMlP0cIYLOSEtvPXxGHX9NPMF1NUDDnzoYFF 8DM7Dx35KhW1ogcmA8etFhFrBrZuB/xcYg1Q87ePG7vohr5OK4iKMEsYXYBa8eDs7BVseGjZ h4tffvl4+fH31TEmmEDPMdFqsQIhkYyXky7ooL5IriiiglV2jiaxwnCDZSPHVgPNQZB0xosc y/q6I9EaHxWLO0Xf01DDCwdtnkFpf+MMjuo8fxsNRQbwthzaLyqGZekkDMhE+VlAP0vIFVrw hO9WUDGn4GL3zFALBkVBir0ZydgXS8eESaitbtGRTxxDxk5ZLgo9O9XTw0TowCGhdQ7e3w3o ovLuml3XZDkhfNzo+bG6Gpp2hzFA72ZIhJi7VZFqDf/MtZ5jS5q5NA9WzqC0QkOy4LTIoQ09 hKS3vDDzIJJIbCBFmCFZA+KCrqQnKXhfQ/BkJzpMCZom41IrxNyVJsaaL9Wc+B8WjFho2nGU 88v1LP9Rh6Aa5WsdojKLJp3D48R5/vUQLx/vkCwUzCCQ1sd/gO0/RyUSBy7mYr3ZNOt6V+Ev /c9Lt2rqHd83/ePl0Puxa3H1BRIN7VWyfVxsFqnPKJmeqrfTchA1OFlbkE3GY64k56DV28Pc X1worI3DazpC1y3WCVdEjp2AEJ8N7QgmodIZdk3j0OXSiMzonp5fSkSi8uZVTxW0ttA+exJt UX77dvI5cSmSWvsUONTXsWuHSK/9gcp+XCod88/aC+WiQ+D+xSawi+Uo9ZJRj1XIP000qVYL q0rhuPBepfCe3ZTbZvPI2hu8uKvLoV9gKwHHtVcuP00PBdwTjEyRJbsvscps6y25y0X21jGz yZG662+b/RnbTruMmtpR0LIT0k5jpKc37x4X9hhc6ZH6BIsgPNw21S173iq+OeRRgbGsk0NV Bwquyg1nb7HAsard3ZNFqeMbncvCT4oebbFhxcU2jXQd18BIEd+twWNdOMh5+yQd18tCcwzZ hO2HrkTZ06ICM8t5ncLJzhIK5WLQggmQLdQltEfQUJkJ9C/sn3HpONTk4i6kZebJWYx+T9Mh lkklTPbOaywJCCldkLCusGml7ldlnyybaQJIwS8DRp4I2btALA90FCK5udmN1RK5OZEFFgXL lhKsLD4Cwuj7Egy1D3ns3KsJVkFyD1WdRaiv4y7asi/Nht694kYlZXboa8OrdntcL6egLrKd NVw9RXOou6reR8omeUVAx6DHTXLmkZ7LeIzMcKwCE9BM6OJsw242gdct3kBXKealCzrBbs+e SIZWx3HQx6ge8V293yxM+EiaLrVN17KLH5P626dsQrJoCJYMNK1MAzhEp45ckzhjuISUSaO8 WLZOcyuhCBOnD1W7O8ilkt203XqBaQV2vcK95k8kWlNAnCb+qEKQUKwBM5OfT38jkVA+RtvU aHuP+sx5mypr7LruwPaf6m5b0rQKIVhgcUjR6LnN4+cfEMp+T9drZJZYg9OZlrbuYxtExpqQ fc3Zit7O8LFF7IMJjS6mRZ6UcR74DNzTi87YAxmQlqIGs1h5mTvLts36dgARTTxtjpSC5YlU DZLrmJc0pnRjOKyuPsWRO2MUtNK47Amx4UBzNbvpQHY08+IzyrPpVOTRJ358rAd2XfcNKbdj JSs5C1o5pNPqO1YZjNNpsayWRKREMcU5moGX9KZz0akUWpIPEMJzb6XLse34cprYgVd+hi/7 kdRKug38KDPyE9jUaNrWHApsDl7SIR6SKIeSwg50hm3DzQLSxDwtNI0WyFfUBOmBdROZsIPe 3GzYzd1w9/2SJFJ7oQs9c7Zmlx9/vbhafbyEI3/TxWmwo809uat7UptpTL1g7KxIyJ1OFxim YQ49dMlA0k4EeuNmb6hZ2zVremnVDgMNm+usWIYoMCm8KfAZt5EU/8fbf6a9VfG06D20dxu6 5gtuVGz4I/Q61u+O0S2iodSNDgmclujQMlIpkeBG8olyBjplUaUYmZpG49E0DuOj6jsisXFq Gvpf0quuN27kCP6VeQp8QEzN9wzz4sh3CWIgQA45B0Fwvgdql9plvFrqSMry/vtUc3e1nHGP LCFPKwHVzZme7qpq0HggpniCVqWdN3A772wFZam8qq50OLdLIW3k0r5sUugTxF/n1/9ADgjt zneYMtAiW7s0ZiNaHu3w8J58xxLdP2y2f4StQZ/xekeTgtqnUW3LWptj8fMDzbaPRp23k6DU eT9dhsykgCheD2tYHZlFbE9O/hs0WRcyiUn6Dz+Lf7ZHRuN5B4Wta51GDdD34Qvv/RSZHdpf kgAeigPV+YVFs18XmQc8YnSWuxXLSwwv3WIMtsOzuYaTZadNKXzHR7sAj2LbYVmaxLZZizty lnyvoAoy6EXgJy0dL0qA6gQqSvNUF8aUv2C0kP/nJ1RLNuMLKdYEc6HnD6Nov7TD4aZfHwqW AQ601j4NG9uW9zlwVFF6m6IhGGQwupJrwBeiN1kMX3X0nrcuhR7EFiTzrlR/rYrVWrg7X6oW tiI8x/FLf+Olg8ydw4wm2EfRHX0Vb1LIihmZB5VHWgV8xON9E/yAnh7b3a2Y2t2OhBlWednl pfY1KKTysLRJtnc8AWFfiTKDFoutT8VWcwoxrvanuseljvjLchFLhQfda1XHU5vykgAFtgCl YEir5tFgd003WaInPBJeimcSEypPhjaJOPDvifeRdXYU8XdeyUDP4NAUW7AlsC8xZGlXcGE8 PNDyYEwKL2yt5F6UzQ78CySCHW0S0kj2Lj1JybFHuPsU2or/9jdiaDATvJDCtUea7WUQvxF4 W1m4zOzo04uNpg748TK7+7bZzwPL2w+jaFnM67V+e993+0l0+2MbscvOvAY4nz0ir9y1pEVR ZVWYuhXvhkm4o/bZq5z09BuwxriYrJvHFX9fFLhyLq9RM3T9u9Lsm9Psy3z2X2JNjYnkDuKz wmf/L2sKE1Lp+smairuD6O+7fdfzA0LKBx+RhlGHYPPDUzdi3d3eFhXNUH8uIxHGi5oGWtOI L9GrVtzwy22sdPR5bhbqMIbemhQ6PRbGD6egKqZ59zB2pYEAIehaZRFrgYHgdaSGEZfZNTE6 j1ixtmJT+Ej0mFSdHwsswvvYmaRUVp2RnxwiqRyKVzXy61E8BQymGFmedXCKPrsKpJeDUt9B bZ883dDy+i7Badr4FMyeXFF7+Rza46lYtEZJoknBMOsNb/cgTdK5OoWTVW/3UzcdjivEUFpJ QbevXUlhgiqjvmN4fXnuX2AldK0vzuXfrdhj/cPD3rWg7NmbNujCbrebv37MGi9ZWWeooQbR 0x/L3JvuSyseRrHv92+H9v5h3ZFQ78mFlW4WXl0wjeUOdPE8UUYuLZcMYx+/V/10gXHL6tv5 pKe/cNxT+mNuh+nQc2atK1UB0UI/UPGf+se9+GXuv6cADS9XB+eWYW0OqSuvarWEjCMKPBZO bthF6W3u/XWp0pDAY5mv91D4CQw+TnT+sVuji/qpFfCaXnS8CuDHKxiGS5rZXtw3Q8O6Te2w EoS4wLf45EgMfGlMczm2Yhuzhk2hzeiSpZmmZvW5HUi0cIuhXz+seIqGJXQSLXmJxWUfu2kr tmyA1Q40qMwiYBTv//MX7Dy/P6BWohmOpPgiV0YVN9jrTl/up7lcY1MgVgVf4iLmYBHUjKK/ ncNWhV1TY3Z8WMYMeFXWtmncTjrjluB+v+bdsUX36phgUbt7lpK1jwDb9BTgVjr3HDDP/7d6 SzubTD5xftmZvYZ21YKASjJaS5l8EQpgoyqsp1Z7crtmGTDeszWFEYdypecqOMpQ1SatES/N ToMKUiDsEFtLG3Rl6jo56OqzuB36O7ZrnAxkQ1RSxW37igmjNtXkuufYf10TB5gfm93u6uPA K7B1x2SLMN5xUkfPZ7sAeQfgsMn6FMh/mpaqEBMgu7Ip7yulUiBJl1jze2YNuCSyvsDbkS04 kbaJ0Obl7THb7ddunFA6W4kSe6vXayP+Ms9pmdFlRbCXhy+kxxZ0MUUfad/r+Esr3BXvY9MI uvam79cn1cA/GNeZ358oeqaAm25HVuvSkt/TKgNaizH92NSLm+EBEgUXi2Xi05sNGHkUN4dL WncxOTWX1tKs1HWWWNzh4ZrP7fjpB3GeHG4qa+ezyFUPrl1N4onijleypWpHSNmxYUgzS1a4 ruHEF1hWW9HblTHeL4FHdd3yIwvTXMsUzk8ibLun2l+As79kwYGMuwpLMFroKFhjt9k3u4K4 0I9N4iAu6L3yKgcCT+AsMICYtEzyrobDPb9bUZNpBxpboNcCKxK/uGE1CiFFs1RiwMPGUXUu wEl86cbuZtcKdPG2uyutG8YUGILvJ1z3yaqXMlo2YzaE7EpAX/CWrPlpaer2mDt6WhKIjzyP 2hqOK4Q0kliRbzaMuQ82RYM/ZkYxfx0KXG2gz3UWdUcfEbddu1uP/OKoDc7mfBY38A2KcYfW pFBYXd7m+ir4GF6S18sK+2t2BH64dMBapGqXYrvV1FAffXrDO14ZMSrEcMsg8LHYgathJVfN yA9DkFWQ2cdGvHbJfYVo8/LAGxfkwyrahWR277G7u98d+ACyGN+cB3pzXHB7yPjrHM7caue9 sLnpH8iMd0T5kK1d28y6xXZbBCEGq9MMvN2p8eO0SaEXLZwXj5LCkIc2gbpzGfzj+BJt0RGb WahDGtv+jknimwRbTtAZfE3n45kP3sg7n8L5xjCqCtbErAJ0ZzKUbz/wrYcKx5BV+Ce+8Si/ y05+nHrxpdk9FLw/Bt/K7AO8UzcWO5jMn/DJezz1nFXP2TZlMbtnZr5lWQw+wmAhS6EsaSgJ 7xW1TqG865UYTJ1DeaFX2DNodBLoFQ/FMHo43gS6eeCNIjVLnWFb3vUbnBa7TorloUDMtiuB VjwUTwjCSaEleXRFS849KxrpYhsLGX3ZkH/P9tInyNed++6aCK8tGBI1+wyahWUIr5gmYlE1 dQqd2j+RV3uEQR9mY8Kbr/kH+2gSy9sv9ImXJOdL6GzAeMojG6h0lvo530gcaWR2DxKELXYO nups5TXpyDKi2R/O9hTBrKgbqK/R2ZcKyumrWgadQoeJVRMTI5rTZCXipRxqErzKL3vSv1XP rgWwyfBG1rzg3NZiGbJ59cXt0N+Jft+SWThr1dy8/ql5Tal3iX2exrhb87wDh2IsbZIJWtAu 2fKNbmEeNL36MuLo69di5PcdFE+BX9KY/mHHWy1sXVJ5naLFTSvWQ897PviTIEN2pnuch+9b Vykrszt/ejNjZ5wYV3uii7ggoOcE35PNk9mBH7f8BJNb8yTKSzDvT6lsGqSYQGdbt+OXHQW6 r21W582G72jQp61ddmpa/GBQd7tjx3Xju6PlWZZlsbZoUxReSAlOL1VW5h9KTB1ew/21Ix8a n6X+yCVkckWz8BbLXNfD1N02q4lSfjzct+Lq52bT7Zup6/fi6pqM5BY99uvV+36aMKe/Xb1/ 338Vv2qNftBUAldhw3GzQ5cOvBc1aaAXvy1PVvMnM5jxQPxxORgH8Yqa2V1AR3Fz87tUs8ox HXs+IRbEmt5odrf9/WHoNuwEaxh/I9GKy4AJe6FTmFcA/nHbDeJ6+NwVmJ82CKx8SfwfxJ/H qfm88HEqlNtJmsp7TC3U058vbJbv9T8BBgB6JddxDWVuZHN0cmVhbQ1lbmRvYmoNNiAwIG9i ag01MzQzIA1lbmRvYmoNNyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTc1OCAw IFIgDS9SZXNvdXJjZXMgPDwgL0NvbG9yU3BhY2UgPDwgL0NTNDMxIDE3NzAgMCBSIC9DUzQz MiAxNzcyIDAgUiAvQ1M0MzMgNDg2IDAgUiAvQ1M0MzQgNDg3IDAgUiAvQ1M0MzUgNDg4IDAg UiANL0NTNDM2IDQ4OSAwIFIgL0NTNDM3IDQ5MCAwIFIgL0NTNDM4IDQ5MSAwIFIgL0NTNDM5 IDQ5MiAwIFIgL0NTNDQwIDQ5MyAwIFIgDS9DUzQ0MSA0OTQgMCBSIC9DUzQ0MiA0OTUgMCBS IC9DUzQ0MyA0OTYgMCBSIC9DUzQ0NCA0OTcgMCBSIC9DUzQ0NSA0OTggMCBSIA0vQ1M0NDYg NDk5IDAgUiAvQ1M0NDcgNTAwIDAgUiAvQ1M0NDggNTAxIDAgUiAvQ1M0NDkgNTAyIDAgUiAv Q1M0NTAgNTAzIDAgUiANL0NTNDUxIDUwNCAwIFIgL0NTNDUyIDUwNSAwIFIgL0NTNDUzIDUw NiAwIFIgL0NTNDU0IDUwNyAwIFIgL0NTNDU1IDUwOCAwIFIgDS9DUzQ1NiA1MDkgMCBSIC9D UzQ1NyA1MTAgMCBSIC9DUzQ1OCA1MTEgMCBSIC9DUzQ1OSA1MTIgMCBSIC9DUzQ2MCA1MTMg MCBSIA0vQ1M0NjEgNTE0IDAgUiAvQ1M0NjIgNTE1IDAgUiAvQ1M0NjMgNTE2IDAgUiAvQ1M0 NjQgNTE3IDAgUiAvQ1M0NjUgNTE4IDAgUiANL0NTNDY2IDUxOSAwIFIgL0NTNDY3IDUyMCAw IFIgL0NTNDY4IDUyMSAwIFIgL0NTNDY5IDUyMiAwIFIgL0NTNDcwIDUyMyAwIFIgDS9DUzQ3 MSA1MjQgMCBSIC9DUzQ3MiA1MjUgMCBSIC9DUzQ3MyA1MjYgMCBSIC9DUzQ3NCA1MjcgMCBS IC9DUzQ3NSA1MjggMCBSIA0vQ1M0NzYgNTI5IDAgUiAvQ1M0NzcgNTMwIDAgUiAvQ1M0Nzgg NTMxIDAgUiAvQ1M0NzkgNTMyIDAgUiAvQ1M0ODAgNTMzIDAgUiANL0NTNDgxIDUzNCAwIFIg L0NTNDgyIDUzNSAwIFIgL0NTNDgzIDUzNiAwIFIgL0NTNDg0IDUzNyAwIFIgL0NTNDg1IDUz OCAwIFIgDS9DUzQ4NiA1MzkgMCBSIC9DUzQ4NyA1NDAgMCBSIC9DUzQ4OCA1NDEgMCBSIC9D UzQ4OSA1NDIgMCBSIC9DUzQ5MCA1NDMgMCBSIA0vQ1M0OTEgNTQ0IDAgUiAvQ1M0OTIgNTQ1 IDAgUiAvQ1M0OTMgNTQ2IDAgUiAvQ1M0OTQgNTQ3IDAgUiAvQ1M0OTUgNTQ4IDAgUiANL0NT NDk2IDU0OSAwIFIgL0NTNDk3IDU1MCAwIFIgL0NTNDk4IDU1MSAwIFIgL0NTNDk5IDU1MiAw IFIgL0NTNTAwIDU1MyAwIFIgDS9DUzUwMSA1NTQgMCBSIC9DUzUwMiA1NTUgMCBSIC9DUzUw MyA1NTYgMCBSIC9DUzUwNCA1NTcgMCBSIC9DUzUwNSA1NTggMCBSIA0vQ1M1MDYgNTU5IDAg UiAvQ1M1MDcgNTYwIDAgUiAvQ1M1MDggNTYxIDAgUiAvQ1M1MDkgNTYyIDAgUiAvQ1M1MTAg NTYzIDAgUiANL0NTNTExIDU2NCAwIFIgL0NTNTEyIDU2NSAwIFIgL0NTNTEzIDU2NiAwIFIg L0NTNTE0IDU2NyAwIFIgL0NTNTE1IDU2OCAwIFIgDS9DUzUxNiA1NjkgMCBSIC9DUzUxNyA1 NzAgMCBSIC9DUzUxOCA1NzEgMCBSIC9DUzUxOSA1NzIgMCBSIC9DUzUyMCA1NzMgMCBSIA0v Q1M1MjEgNTc0IDAgUiAvQ1M1MjIgNTc1IDAgUiAvQ1M1MjMgNTc2IDAgUiAvQ1M1MjQgNTc3 IDAgUiAvQ1M1MjUgNTc4IDAgUiANL0NTNTI2IDU3OSAwIFIgL0NTNTI3IDU4MCAwIFIgL0NT NTI4IDU4MSAwIFIgL0NTNTI5IDU4MiAwIFIgL0NTNTMwIDU4MyAwIFIgDS9DUzUzMSA1ODQg MCBSIC9DUzUzMiA1ODUgMCBSIC9DUzUzMyA1ODYgMCBSIC9DUzUzNCA1ODcgMCBSIC9DUzUz NSA1ODggMCBSIA0vQ1M1MzYgNTg5IDAgUiAvQ1M1MzcgNTkwIDAgUiAvQ1M1MzggNTkxIDAg UiAvQ1M1MzkgNTkyIDAgUiAvQ1M1NDAgNTkzIDAgUiANL0NTNTQxIDU5NCAwIFIgL0NTNTQy IDU5NSAwIFIgL0NTNTQzIDU5NiAwIFIgL0NTNTQ0IDU5NyAwIFIgL0NTNTQ1IDU5OCAwIFIg DS9DUzU0NiA1OTkgMCBSIC9DUzU0NyA2MDAgMCBSIC9DUzU0OCA2MDEgMCBSIC9DUzU0OSA2 MDIgMCBSIC9DUzU1MCA2MDMgMCBSIA0vQ1M1NTEgNjA0IDAgUiAvQ1M1NTIgNjA1IDAgUiAv Q1M1NTMgNjA2IDAgUiAvQ1M1NTQgNjA3IDAgUiAvQ1M1NTUgNjA4IDAgUiANL0NTNTU2IDYw OSAwIFIgL0NTNTU3IDYxMCAwIFIgL0NTNTU4IDYxMSAwIFIgL0NTNTU5IDYxMiAwIFIgL0NT NTYwIDYxMyAwIFIgDS9DUzU2MSA2MTQgMCBSIC9DUzU2MiA2MTUgMCBSIC9DUzU2MyA2MTYg MCBSIC9DUzU2NCA2MTcgMCBSIC9DUzU2NSA2MTggMCBSIA0vQ1M1NjYgNjE5IDAgUiAvQ1M1 NjcgNjIwIDAgUiAvQ1M1NjggNjIxIDAgUiAvQ1M1NjkgNjIyIDAgUiAvQ1M1NzAgNjIzIDAg UiANL0NTNTcxIDYyNCAwIFIgL0NTNTcyIDYyNSAwIFIgL0NTNTczIDYyNiAwIFIgL0NTNTc0 IDYyNyAwIFIgL0NTNTc1IDYyOCAwIFIgDS9DUzU3NiA2MjkgMCBSIC9DUzU3NyA2MzAgMCBS IC9DUzU3OCA2MzEgMCBSIC9DUzU3OSA2MzIgMCBSIC9DUzU4MCA2MzMgMCBSIA0vQ1M1ODEg NjM0IDAgUiAvQ1M1ODIgNjM1IDAgUiAvQ1M1ODMgNjM2IDAgUiAvQ1M1ODQgNjM3IDAgUiAv Q1M1ODUgNjM4IDAgUiANL0NTNTg2IDYzOSAwIFIgL0NTNTg3IDY0MCAwIFIgL0NTNTg4IDY0 MSAwIFIgL0NTNTg5IDY0MiAwIFIgL0NTNTkwIDY0MyAwIFIgDS9DUzU5MSA2NDQgMCBSIC9D UzU5MiA2NDUgMCBSIC9DUzU5MyA2NDYgMCBSIC9DUzU5NCA2NDcgMCBSIC9DUzU5NSA2NDgg MCBSIA0vQ1M1OTYgNjQ5IDAgUiAvQ1M1OTcgNjUwIDAgUiAvQ1M1OTggNjUxIDAgUiAvQ1M1 OTkgNjUyIDAgUiAvQ1M2MDAgNjUzIDAgUiANL0NTNjAxIDY1NCAwIFIgL0NTNjAyIDY1NSAw IFIgL0NTNjAzIDY1NiAwIFIgL0NTNjA0IDY1NyAwIFIgL0NTNjA1IDY1OCAwIFIgDS9DUzYw NiA2NTkgMCBSIC9DUzYwNyA2NjAgMCBSIC9DUzYwOCA2NjEgMCBSIC9DUzYwOSA2NjIgMCBS IC9DUzYxMCA2NjMgMCBSIA0vQ1M2MTEgNjY0IDAgUiAvQ1M2MTIgNjY1IDAgUiAvQ1M2MTMg NjY2IDAgUiAvQ1M2MTQgNjY3IDAgUiAvQ1M2MTUgNjY4IDAgUiANL0NTNjE2IDY2OSAwIFIg L0NTNjE3IDY3MCAwIFIgL0NTNjE4IDY3MSAwIFIgL0NTNjE5IDY3MiAwIFIgL0NTNjIwIDY3 MyAwIFIgDS9DUzYyMSA2NzQgMCBSIC9DUzYyMiA2NzUgMCBSIC9DUzYyMyA2NzYgMCBSIC9D UzYyNCA2NzcgMCBSIC9DUzYyNSA2NzggMCBSIA0vQ1M2MjYgNjc5IDAgUiAvQ1M2MjcgNjgw IDAgUiAvQ1M2MjggNjgxIDAgUiAvQ1M2MjkgNjgyIDAgUiAvQ1M2MzAgNjgzIDAgUiANL0NT NjMxIDY4NCAwIFIgL0NTNjMyIDY4NSAwIFIgL0NTNjMzIDY4NiAwIFIgL0NTNjM0IDY4NyAw IFIgL0NTNjM1IDY4OCAwIFIgDS9DUzYzNiA2ODkgMCBSIC9DUzYzNyA2OTAgMCBSIC9DUzYz OCA2OTEgMCBSIC9DUzYzOSA2OTIgMCBSIC9DUzY0MCA2OTMgMCBSIA0vQ1M2NDEgNjk0IDAg UiAvQ1M2NDIgNjk1IDAgUiAvQ1M2NDMgNjk2IDAgUiAvQ1M2NDQgNjk3IDAgUiAvQ1M2NDUg Njk4IDAgUiANL0NTNjQ2IDY5OSAwIFIgL0NTNjQ3IDcwMCAwIFIgL0NTNjQ4IDcwMSAwIFIg L0NTNjQ5IDcwMiAwIFIgL0NTNjUwIDcwMyAwIFIgDS9DUzY1MSA3MDQgMCBSIC9DUzY1MiA3 MDUgMCBSIC9DUzY1MyA3MDYgMCBSIC9DUzY1NCA3MDcgMCBSIC9DUzY1NSA3MDggMCBSIA0v Q1M2NTYgNzA5IDAgUiAvQ1M2NTcgNzEwIDAgUiAvQ1M2NTggNzExIDAgUiAvQ1M2NTkgNzEy IDAgUiAvQ1M2NjAgNzEzIDAgUiANL0NTNjYxIDcxNCAwIFIgL0NTNjYyIDcxNSAwIFIgL0NT NjYzIDcxNiAwIFIgL0NTNjY0IDcxNyAwIFIgL0NTNjY1IDcxOCAwIFIgDS9DUzY2NiA3MTkg MCBSIC9DUzY2NyA3MjAgMCBSIC9DUzY2OCA3MjEgMCBSIC9DUzY2OSA3MjIgMCBSIC9DUzY3 MCA3MjMgMCBSIA0vQ1M2NzEgNzI0IDAgUiAvQ1M2NzIgNzI1IDAgUiAvQ1M2NzMgNzI2IDAg UiAvQ1M2NzQgNzI3IDAgUiAvQ1M2NzUgNzI4IDAgUiANL0NTNjc2IDcyOSAwIFIgL0NTNjc3 IDczMCAwIFIgL0NTNjc4IDczMSAwIFIgL0NTNjc5IDczMiAwIFIgL0NTNjgwIDczMyAwIFIg DS9DUzY4MSA3MzQgMCBSIC9DUzY4MiA3MzUgMCBSIC9DUzY4MyA3MzYgMCBSIC9DUzY4NCA3 MzcgMCBSIC9DUzY4NSA3MzggMCBSIA0vQ1M2ODYgNzM5IDAgUiAvQ1M2ODcgNzQwIDAgUiAv Q1M2ODggNzQxIDAgUiAvQ1M2ODkgNzQyIDAgUiAvQ1M2OTAgNzQzIDAgUiANL0NTNjkxIDc0 NCAwIFIgL0NTNjkyIDc0NSAwIFIgL0NTNjkzIDc0NiAwIFIgL0NTNjk0IDc0NyAwIFIgL0NT Njk1IDc0OCAwIFIgDS9DUzY5NiA3NDkgMCBSIC9DUzY5NyA3NTAgMCBSIC9DUzY5OCA3NTEg MCBSIC9DUzY5OSA3NTIgMCBSIC9DUzcwMCA3NTMgMCBSIA0vQ1M3MDEgNzU0IDAgUiAvQ1M3 MDIgNzU1IDAgUiAvQ1M3MDMgNzU2IDAgUiAvQ1M3MDQgNzU3IDAgUiAvQ1M3MDUgNzU4IDAg UiANL0NTNzA2IDc1OSAwIFIgL0NTNzA3IDc2MCAwIFIgL0NTNzA4IDc2MSAwIFIgL0NTNzA5 IDc2MiAwIFIgL0NTNzEwIDc2MyAwIFIgDS9DUzcxMSA3NjQgMCBSIC9DUzcxMiA3NjUgMCBS IC9DUzcxMyA3NjYgMCBSIC9DUzcxNCA3NjcgMCBSIC9DUzcxNSA3NjggMCBSIA0vQ1M3MTYg NzY5IDAgUiAvQ1M3MTcgNzcwIDAgUiAvQ1M3MTggNzcxIDAgUiAvQ1M3MTkgNzcyIDAgUiAv Q1M3MjAgNzczIDAgUiANL0NTNzIxIDc3NCAwIFIgL0NTNzIyIDc3NSAwIFIgL0NTNzIzIDc3 NiAwIFIgL0NTNzI0IDc3NyAwIFIgL0NTNzI1IDc3OCAwIFIgDS9DUzcyNiA3NzkgMCBSIC9D UzcyNyA3ODAgMCBSIC9DUzcyOCA3ODEgMCBSIC9DUzcyOSA3ODIgMCBSIC9DUzczMCA3ODMg MCBSIA0vQ1M3MzEgNzg0IDAgUiAvQ1M3MzIgNzg1IDAgUiAvQ1M3MzMgNzg2IDAgUiAvQ1M3 MzQgNzg3IDAgUiAvQ1M3MzUgNzg4IDAgUiANL0NTNzM2IDc4OSAwIFIgL0NTNzM3IDc5MCAw IFIgL0NTNzM4IDc5MSAwIFIgL0NTNzM5IDc5MiAwIFIgL0NTNzQwIDc5MyAwIFIgDS9DUzc0 MSA3OTQgMCBSIC9DUzc0MiA3OTUgMCBSIC9DUzc0MyA3OTYgMCBSIC9DUzc0NCA3OTcgMCBS IC9DUzc0NSA3OTggMCBSIA0vQ1M3NDYgNzk5IDAgUiAvQ1M3NDcgODAwIDAgUiAvQ1M3NDgg ODAxIDAgUiAvQ1M3NDkgODAyIDAgUiAvQ1M3NTAgODAzIDAgUiANL0NTNzUxIDgwNCAwIFIg L0NTNzUyIDgwNSAwIFIgL0NTNzUzIDgwNiAwIFIgL0NTNzU0IDgwNyAwIFIgL0NTNzU1IDgw OCAwIFIgDS9DUzc1NiA4MDkgMCBSIC9DUzc1NyA4MTAgMCBSIC9DUzc1OCA4MTEgMCBSIC9D Uzc1OSA4MTIgMCBSIC9DUzc2MCA4MTMgMCBSIA0vQ1M3NjEgODE0IDAgUiAvQ1M3NjIgODE1 IDAgUiAvQ1M3NjMgODE2IDAgUiAvQ1M3NjQgODE3IDAgUiAvQ1M3NjUgODE4IDAgUiANL0NT NzY2IDgxOSAwIFIgL0NTNzY3IDgyMCAwIFIgL0NTNzY4IDgyMSAwIFIgL0NTNzY5IDgyMiAw IFIgL0NTNzcwIDgyMyAwIFIgDS9DUzc3MSA4MjQgMCBSIC9DUzc3MiA4MjUgMCBSIC9DUzc3 MyA4MjYgMCBSIC9DUzc3NCA4MjcgMCBSIC9DUzc3NSA4MjggMCBSIA0vQ1M3NzYgODI5IDAg UiAvQ1M3NzcgODMwIDAgUiAvQ1M3NzggODMxIDAgUiAvQ1M3NzkgODMyIDAgUiAvQ1M3ODAg ODMzIDAgUiANL0NTNzgxIDgzNCAwIFIgL0NTNzgyIDgzNSAwIFIgL0NTNzgzIDgzNiAwIFIg L0NTNzg0IDgzNyAwIFIgL0NTNzg1IDgzOCAwIFIgDS9DUzc4NiA4MzkgMCBSIC9DUzc4NyA4 NDAgMCBSIC9DUzc4OCA4NDEgMCBSIC9DUzc4OSA4NDIgMCBSIC9DUzc5MCA4NDMgMCBSIA0v Q1M3OTEgODQ0IDAgUiAvQ1M3OTIgODQ1IDAgUiAvQ1M3OTMgODQ2IDAgUiAvQ1M3OTQgODQ3 IDAgUiAvQ1M3OTUgODQ4IDAgUiANL0NTNzk2IDg0OSAwIFIgL0NTNzk3IDg1MCAwIFIgL0NT Nzk4IDg1MSAwIFIgL0NTNzk5IDg1MiAwIFIgL0NTODAwIDg1MyAwIFIgDS9DUzgwMSA4NTQg MCBSIC9DUzgwMiA4NTUgMCBSIC9DUzgwMyA4NTYgMCBSIC9DUzgwNCA4NTcgMCBSIC9DUzgw NSA4NTggMCBSIA0vQ1M4MDYgODU5IDAgUiAvQ1M4MDcgODYwIDAgUiAvQ1M4MDggODYxIDAg UiAvQ1M4MDkgODYyIDAgUiAvQ1M4MTAgODYzIDAgUiANL0NTODExIDg2NCAwIFIgL0NTODEy IDg2NSAwIFIgL0NTODEzIDg2NiAwIFIgL0NTODE0IDg2NyAwIFIgL0NTODE1IDg2OCAwIFIg DS9DUzgxNiA4NjkgMCBSIC9DUzgxNyA4NzAgMCBSIC9DUzgxOCA4NzEgMCBSIC9DUzgxOSA4 NzIgMCBSIC9DUzgyMCA4NzMgMCBSIA0vQ1M4MjEgODc0IDAgUiAvQ1M4MjIgODc1IDAgUiAv Q1M4MjMgODc2IDAgUiAvQ1M4MjQgODc3IDAgUiAvQ1M4MjUgODc4IDAgUiANL0NTODI2IDg3 OSAwIFIgL0NTODI3IDg4MCAwIFIgL0NTODI4IDg4MSAwIFIgL0NTODI5IDg4MiAwIFIgL0NT ODMwIDg4MyAwIFIgDS9DUzgzMSA4ODQgMCBSIC9DUzgzMiA4ODUgMCBSIC9DUzgzMyA4ODYg MCBSIC9DUzgzNCA4ODcgMCBSIC9DUzgzNSA4ODggMCBSIA0vQ1M4MzYgODg5IDAgUiAvQ1M4 MzcgODkwIDAgUiAvQ1M4MzggODkxIDAgUiAvQ1M4MzkgODkyIDAgUiAvQ1M4NDAgODkzIDAg UiANL0NTODQxIDg5NCAwIFIgL0NTODQyIDg5NSAwIFIgL0NTODQzIDg5NiAwIFIgL0NTODQ0 IDg5NyAwIFIgL0NTODQ1IDg5OCAwIFIgDS9DUzg0NiA4OTkgMCBSIC9DUzg0NyA5MDAgMCBS IC9DUzg0OCA5MDEgMCBSIC9DUzg0OSA5MDIgMCBSIC9DUzg1MCA5MDMgMCBSIA0vQ1M4NTEg OTA0IDAgUiAvQ1M4NTIgOTA1IDAgUiAvQ1M4NTMgOTA2IDAgUiAvQ1M4NTQgOTA3IDAgUiAv Q1M4NTUgOTA4IDAgUiANL0NTODU2IDkwOSAwIFIgL0NTODU3IDkxMCAwIFIgL0NTODU4IDkx MSAwIFIgL0NTODU5IDkxMiAwIFIgL0NTODYwIDkxMyAwIFIgDS9DUzg2MSA5MTQgMCBSID4+ IA0vRXh0R1N0YXRlIDw8IC9HUzIgMTc5MyAwIFIgL0dTMyAxNzk0IDAgUiA+PiAvRm9udCA8 PCAvVFQ0IDE3NjcgMCBSIC9UVDUgMTc2OCAwIFIgL1RUNiAxNzc2IDAgUiAvVFQ3IDE3NzMg MCBSID4+IA0vWE9iamVjdCA8PCAvSW00NTkgMTAgMCBSIC9JbTQ2MCAxMSAwIFIgL0ltNDYx IDEyIDAgUiAvSW00NjIgMTMgMCBSIC9JbTQ2MyAxNCAwIFIgDS9JbTQ2NCAxNSAwIFIgL0lt NDY1IDE2IDAgUiAvSW00NjYgMTcgMCBSIC9JbTQ2NyAxOCAwIFIgL0ltNDY4IDE5IDAgUiAN L0ltNDY5IDIwIDAgUiAvSW00NzAgMjEgMCBSIC9JbTQ3MSAyMiAwIFIgL0ltNDcyIDIzIDAg UiAvSW00NzMgMjQgMCBSIA0vSW00NzQgMjUgMCBSIC9JbTQ3NSAyNiAwIFIgL0ltNDc2IDI3 IDAgUiAvSW00NzcgMjggMCBSIC9JbTQ3OCAyOSAwIFIgDS9JbTQ3OSAzMCAwIFIgL0ltNDgw IDMxIDAgUiAvSW00ODEgMzIgMCBSIC9JbTQ4MiAzMyAwIFIgL0ltNDgzIDM0IDAgUiANL0lt NDg0IDM1IDAgUiAvSW00ODUgMzYgMCBSIC9JbTQ4NiAzNyAwIFIgL0ltNDg3IDM4IDAgUiAv SW00ODggMzkgMCBSIA0vSW00ODkgNDAgMCBSIC9JbTQ5MCA0MSAwIFIgL0ltNDkxIDQyIDAg UiAvSW00OTIgNDMgMCBSIC9JbTQ5MyA0NCAwIFIgDS9JbTQ5NCA0NSAwIFIgL0ltNDk1IDQ2 IDAgUiAvSW00OTYgNDcgMCBSIC9JbTQ5NyA0OCAwIFIgL0ltNDk4IDQ5IDAgUiANL0ltNDk5 IDUwIDAgUiAvSW01MDAgNTEgMCBSIC9JbTUwMSA1MiAwIFIgL0ltNTAyIDUzIDAgUiAvSW01 MDMgNTQgMCBSIA0vSW01MDQgNTUgMCBSIC9JbTUwNSA1NiAwIFIgL0ltNTA2IDU3IDAgUiAv SW01MDcgNTggMCBSIC9JbTUwOCA1OSAwIFIgDS9JbTUwOSA2MCAwIFIgL0ltNTEwIDYxIDAg UiAvSW01MTEgNjIgMCBSIC9JbTUxMiA2MyAwIFIgL0ltNTEzIDY0IDAgUiANL0ltNTE0IDY1 IDAgUiAvSW01MTUgNjYgMCBSIC9JbTUxNiA2NyAwIFIgL0ltNTE3IDY4IDAgUiAvSW01MTgg NjkgMCBSIA0vSW01MTkgNzAgMCBSIC9JbTUyMCA3MSAwIFIgL0ltNTIxIDcyIDAgUiAvSW01 MjIgNzMgMCBSIC9JbTUyMyA3NCAwIFIgDS9JbTUyNCA3NSAwIFIgL0ltNTI1IDc2IDAgUiAv SW01MjYgNzcgMCBSIC9JbTUyNyA3OCAwIFIgL0ltNTI4IDc5IDAgUiANL0ltNTI5IDgwIDAg UiAvSW01MzAgODEgMCBSIC9JbTUzMSA4MiAwIFIgL0ltNTMyIDgzIDAgUiAvSW01MzMgODQg MCBSIA0vSW01MzQgODUgMCBSIC9JbTUzNSA4NiAwIFIgL0ltNTM2IDg3IDAgUiAvSW01Mzcg ODggMCBSIC9JbTUzOCA4OSAwIFIgDS9JbTUzOSA5MCAwIFIgL0ltNTQwIDkxIDAgUiAvSW01 NDEgOTIgMCBSIC9JbTU0MiA5MyAwIFIgL0ltNTQzIDk0IDAgUiANL0ltNTQ0IDk1IDAgUiAv SW01NDUgOTYgMCBSIC9JbTU0NiA5NyAwIFIgL0ltNTQ3IDk4IDAgUiAvSW01NDggOTkgMCBS IA0vSW01NDkgMTAwIDAgUiAvSW01NTAgMTAxIDAgUiAvSW01NTEgMTAyIDAgUiAvSW01NTIg MTAzIDAgUiAvSW01NTMgMTA0IDAgUiANL0ltNTU0IDEwNSAwIFIgL0ltNTU1IDEwNiAwIFIg L0ltNTU2IDEwNyAwIFIgL0ltNTU3IDEwOCAwIFIgL0ltNTU4IDEwOSAwIFIgDS9JbTU1OSAx MTAgMCBSIC9JbTU2MCAxMTEgMCBSIC9JbTU2MSAxMTIgMCBSIC9JbTU2MiAxMTMgMCBSIC9J bTU2MyAxMTQgMCBSIA0vSW01NjQgMTE1IDAgUiAvSW01NjUgMTE2IDAgUiAvSW01NjYgMTE3 IDAgUiAvSW01NjcgMTE4IDAgUiAvSW01NjggMTE5IDAgUiANL0ltNTY5IDEyMCAwIFIgL0lt NTcwIDEyMSAwIFIgL0ltNTcxIDEyMiAwIFIgL0ltNTcyIDEyMyAwIFIgL0ltNTczIDEyNCAw IFIgDS9JbTU3NCAxMjUgMCBSIC9JbTU3NSAxMjYgMCBSIC9JbTU3NiAxMjcgMCBSIC9JbTU3 NyAxMjggMCBSIC9JbTU3OCAxMjkgMCBSIA0vSW01NzkgMTMwIDAgUiAvSW01ODAgMTMxIDAg UiAvSW01ODEgMTMyIDAgUiAvSW01ODIgMTMzIDAgUiAvSW01ODMgMTM0IDAgUiANL0ltNTg0 IDEzNSAwIFIgL0ltNTg1IDEzNiAwIFIgL0ltNTg2IDEzNyAwIFIgL0ltNTg3IDEzOCAwIFIg L0ltNTg4IDEzOSAwIFIgDS9JbTU4OSAxNDAgMCBSIC9JbTU5MCAxNDEgMCBSIC9JbTU5MSAx NDIgMCBSIC9JbTU5MiAxNDMgMCBSIC9JbTU5MyAxNDQgMCBSIA0vSW01OTQgMTQ1IDAgUiAv SW01OTUgMTQ2IDAgUiAvSW01OTYgMTQ3IDAgUiAvSW01OTcgMTQ4IDAgUiAvSW01OTggMTQ5 IDAgUiANL0ltNTk5IDE1MCAwIFIgL0ltNjAwIDE1MSAwIFIgL0ltNjAxIDE1MiAwIFIgL0lt NjAyIDE1MyAwIFIgL0ltNjAzIDE1NCAwIFIgDS9JbTYwNCAxNTUgMCBSIC9JbTYwNSAxNTYg MCBSIC9JbTYwNiAxNTcgMCBSIC9JbTYwNyAxNTggMCBSIC9JbTYwOCAxNTkgMCBSIA0vSW02 MDkgMTYwIDAgUiAvSW02MTAgMTYxIDAgUiAvSW02MTEgMTYyIDAgUiAvSW02MTIgMTYzIDAg UiAvSW02MTMgMTY0IDAgUiANL0ltNjE0IDE2NSAwIFIgL0ltNjE1IDE2NiAwIFIgL0ltNjE2 IDE2NyAwIFIgL0ltNjE3IDE2OCAwIFIgL0ltNjE4IDE2OSAwIFIgDS9JbTYxOSAxNzAgMCBS IC9JbTYyMCAxNzEgMCBSIC9JbTYyMSAxNzIgMCBSIC9JbTYyMiAxNzMgMCBSIC9JbTYyMyAx NzQgMCBSIA0vSW02MjQgMTc1IDAgUiAvSW02MjUgMTc2IDAgUiAvSW02MjYgMTc3IDAgUiAv SW02MjcgMTc4IDAgUiAvSW02MjggMTc5IDAgUiANL0ltNjI5IDE4MCAwIFIgL0ltNjMwIDE4 MSAwIFIgL0ltNjMxIDE4MiAwIFIgL0ltNjMyIDE4MyAwIFIgL0ltNjMzIDE4NCAwIFIgDS9J bTYzNCAxODUgMCBSIC9JbTYzNSAxODYgMCBSIC9JbTYzNiAxODcgMCBSIC9JbTYzNyAxODgg MCBSIC9JbTYzOCAxODkgMCBSIA0vSW02MzkgMTkwIDAgUiAvSW02NDAgMTkxIDAgUiAvSW02 NDEgMTkyIDAgUiAvSW02NDIgMTkzIDAgUiAvSW02NDMgMTk0IDAgUiANL0ltNjQ0IDE5NSAw IFIgL0ltNjQ1IDE5NiAwIFIgL0ltNjQ2IDE5NyAwIFIgL0ltNjQ3IDE5OCAwIFIgL0ltNjQ4 IDE5OSAwIFIgDS9JbTY0OSAyMDAgMCBSIC9JbTY1MCAyMDEgMCBSIC9JbTY1MSAyMDIgMCBS IC9JbTY1MiAyMDMgMCBSIC9JbTY1MyAyMDQgMCBSIA0vSW02NTQgMjA1IDAgUiAvSW02NTUg MjA2IDAgUiAvSW02NTYgMjA3IDAgUiAvSW02NTcgMjA4IDAgUiAvSW02NTggMjA5IDAgUiAN L0ltNjU5IDIxMCAwIFIgL0ltNjYwIDIxMSAwIFIgL0ltNjYxIDIxMiAwIFIgL0ltNjYyIDIx MyAwIFIgL0ltNjYzIDIxNCAwIFIgDS9JbTY2NCAyMTUgMCBSIC9JbTY2NSAyMTYgMCBSIC9J bTY2NiAyMTcgMCBSIC9JbTY2NyAyMTggMCBSIC9JbTY2OCAyMTkgMCBSIA0vSW02NjkgMjIw IDAgUiAvSW02NzAgMjIxIDAgUiAvSW02NzEgMjIyIDAgUiAvSW02NzIgMjIzIDAgUiAvSW02 NzMgMjI0IDAgUiANL0ltNjc0IDIyNSAwIFIgL0ltNjc1IDIyNiAwIFIgL0ltNjc2IDIyNyAw IFIgL0ltNjc3IDIyOCAwIFIgL0ltNjc4IDIyOSAwIFIgDS9JbTY3OSAyMzAgMCBSIC9JbTY4 MCAyMzEgMCBSIC9JbTY4MSAyMzIgMCBSIC9JbTY4MiAyMzMgMCBSIC9JbTY4MyAyMzQgMCBS IA0vSW02ODQgMjM1IDAgUiAvSW02ODUgMjM2IDAgUiAvSW02ODYgMjM3IDAgUiAvSW02ODcg MjM4IDAgUiAvSW02ODggMjM5IDAgUiANL0ltNjg5IDI0MCAwIFIgL0ltNjkwIDI0MSAwIFIg L0ltNjkxIDI0MiAwIFIgL0ltNjkyIDI0MyAwIFIgL0ltNjkzIDI0NCAwIFIgDS9JbTY5NCAy NDUgMCBSIC9JbTY5NSAyNDYgMCBSIC9JbTY5NiAyNDcgMCBSIC9JbTY5NyAyNDggMCBSIC9J bTY5OCAyNDkgMCBSIA0vSW02OTkgMjUwIDAgUiAvSW03MDAgMjUxIDAgUiAvSW03MDEgMjUy IDAgUiAvSW03MDIgMjUzIDAgUiAvSW03MDMgMjU0IDAgUiANL0ltNzA0IDI1NSAwIFIgL0lt NzA1IDI1NiAwIFIgL0ltNzA2IDI1NyAwIFIgL0ltNzA3IDI1OCAwIFIgL0ltNzA4IDI1OSAw IFIgDS9JbTcwOSAyNjAgMCBSIC9JbTcxMCAyNjEgMCBSIC9JbTcxMSAyNjIgMCBSIC9JbTcx MiAyNjMgMCBSIC9JbTcxMyAyNjQgMCBSIA0vSW03MTQgMjY1IDAgUiAvSW03MTUgMjY2IDAg UiAvSW03MTYgMjY3IDAgUiAvSW03MTcgMjY4IDAgUiAvSW03MTggMjY5IDAgUiANL0ltNzE5 IDI3MCAwIFIgL0ltNzIwIDI3MSAwIFIgL0ltNzIxIDI3MiAwIFIgL0ltNzIyIDI3MyAwIFIg L0ltNzIzIDI3NCAwIFIgDS9JbTcyNCAyNzUgMCBSIC9JbTcyNSAyNzYgMCBSIC9JbTcyNiAy NzcgMCBSIC9JbTcyNyAyNzggMCBSIC9JbTcyOCAyNzkgMCBSIA0vSW03MjkgMjgwIDAgUiAv SW03MzAgMjgxIDAgUiAvSW03MzEgMjgyIDAgUiAvSW03MzIgMjgzIDAgUiAvSW03MzMgMjg0 IDAgUiANL0ltNzM0IDI4NSAwIFIgL0ltNzM1IDI4NiAwIFIgL0ltNzM2IDI4NyAwIFIgL0lt NzM3IDI4OCAwIFIgL0ltNzM4IDI4OSAwIFIgDS9JbTczOSAyOTAgMCBSIC9JbTc0MCAyOTEg MCBSIC9JbTc0MSAyOTIgMCBSIC9JbTc0MiAyOTMgMCBSIC9JbTc0MyAyOTQgMCBSIA0vSW03 NDQgMjk1IDAgUiAvSW03NDUgMjk2IDAgUiAvSW03NDYgMjk3IDAgUiAvSW03NDcgMjk4IDAg UiAvSW03NDggMjk5IDAgUiANL0ltNzQ5IDMwMCAwIFIgL0ltNzUwIDMwMSAwIFIgL0ltNzUx IDMwMiAwIFIgL0ltNzUyIDMwMyAwIFIgL0ltNzUzIDMwNCAwIFIgDS9JbTc1NCAzMDUgMCBS IC9JbTc1NSAzMDYgMCBSIC9JbTc1NiAzMDcgMCBSIC9JbTc1NyAzMDggMCBSIC9JbTc1OCAz MDkgMCBSIA0vSW03NTkgMzEwIDAgUiAvSW03NjAgMzExIDAgUiAvSW03NjEgMzEyIDAgUiAv SW03NjIgMzEzIDAgUiAvSW03NjMgMzE0IDAgUiANL0ltNzY0IDMxNSAwIFIgL0ltNzY1IDMx NiAwIFIgL0ltNzY2IDMxNyAwIFIgL0ltNzY3IDMxOCAwIFIgL0ltNzY4IDMxOSAwIFIgDS9J bTc2OSAzMjAgMCBSIC9JbTc3MCAzMjEgMCBSIC9JbTc3MSAzMjIgMCBSIC9JbTc3MiAzMjMg MCBSIC9JbTc3MyAzMjQgMCBSIA0vSW03NzQgMzI1IDAgUiAvSW03NzUgMzI2IDAgUiAvSW03 NzYgMzI3IDAgUiAvSW03NzcgMzI4IDAgUiAvSW03NzggMzI5IDAgUiANL0ltNzc5IDMzMCAw IFIgL0ltNzgwIDMzMSAwIFIgL0ltNzgxIDMzMiAwIFIgL0ltNzgyIDMzMyAwIFIgL0ltNzgz IDMzNCAwIFIgDS9JbTc4NCAzMzUgMCBSIC9JbTc4NSAzMzYgMCBSIC9JbTc4NiAzMzcgMCBS IC9JbTc4NyAzMzggMCBSIC9JbTc4OCAzMzkgMCBSIA0vSW03ODkgMzQwIDAgUiAvSW03OTAg MzQxIDAgUiAvSW03OTEgMzQyIDAgUiAvSW03OTIgMzQzIDAgUiAvSW03OTMgMzQ0IDAgUiAN L0ltNzk0IDM0NSAwIFIgL0ltNzk1IDM0NiAwIFIgL0ltNzk2IDM0NyAwIFIgL0ltNzk3IDM0 OCAwIFIgL0ltNzk4IDM0OSAwIFIgDS9JbTc5OSAzNTAgMCBSIC9JbTgwMCAzNTEgMCBSIC9J bTgwMSAzNTIgMCBSIC9JbTgwMiAzNTMgMCBSIC9JbTgwMyAzNTQgMCBSIA0vSW04MDQgMzU1 IDAgUiAvSW04MDUgMzU2IDAgUiAvSW04MDYgMzU3IDAgUiAvSW04MDcgMzU4IDAgUiAvSW04 MDggMzU5IDAgUiANL0ltODA5IDM2MCAwIFIgL0ltODEwIDM2MSAwIFIgL0ltODExIDM2MiAw IFIgL0ltODEyIDM2MyAwIFIgL0ltODEzIDM2NCAwIFIgDS9JbTgxNCAzNjUgMCBSIC9JbTgx NSAzNjYgMCBSIC9JbTgxNiAzNjcgMCBSIC9JbTgxNyAzNjggMCBSIC9JbTgxOCAzNjkgMCBS IA0vSW04MTkgMzcwIDAgUiAvSW04MjAgMzcxIDAgUiAvSW04MjEgMzcyIDAgUiAvSW04MjIg MzczIDAgUiAvSW04MjMgMzc0IDAgUiANL0ltODI0IDM3NSAwIFIgL0ltODI1IDM3NiAwIFIg L0ltODI2IDM3NyAwIFIgL0ltODI3IDM3OCAwIFIgL0ltODI4IDM3OSAwIFIgDS9JbTgyOSAz ODAgMCBSIC9JbTgzMCAzODEgMCBSIC9JbTgzMSAzODIgMCBSIC9JbTgzMiAzODMgMCBSIC9J bTgzMyAzODQgMCBSIA0vSW04MzQgMzg1IDAgUiAvSW04MzUgMzg2IDAgUiAvSW04MzYgMzg3 IDAgUiAvSW04MzcgMzg4IDAgUiAvSW04MzggMzg5IDAgUiANL0ltODM5IDM5MCAwIFIgL0lt ODQwIDM5MSAwIFIgL0ltODQxIDM5MiAwIFIgL0ltODQyIDM5MyAwIFIgL0ltODQzIDM5NCAw IFIgDS9JbTg0NCAzOTUgMCBSIC9JbTg0NSAzOTYgMCBSIC9JbTg0NiAzOTcgMCBSIC9JbTg0 NyAzOTggMCBSIC9JbTg0OCAzOTkgMCBSIA0vSW04NDkgNDAwIDAgUiAvSW04NTAgNDAxIDAg UiAvSW04NTEgNDAyIDAgUiAvSW04NTIgNDAzIDAgUiAvSW04NTMgNDA0IDAgUiANL0ltODU0 IDQwNSAwIFIgL0ltODU1IDQwNiAwIFIgL0ltODU2IDQwNyAwIFIgL0ltODU3IDQwOCAwIFIg L0ltODU4IDQwOSAwIFIgDS9JbTg1OSA0MTAgMCBSIC9JbTg2MCA0MTEgMCBSIC9JbTg2MSA0 MTIgMCBSIC9JbTg2MiA0MTMgMCBSIC9JbTg2MyA0MTQgMCBSIA0vSW04NjQgNDE1IDAgUiAv SW04NjUgNDE2IDAgUiAvSW04NjYgNDE3IDAgUiAvSW04NjcgNDE4IDAgUiAvSW04NjggNDE5 IDAgUiANL0ltODY5IDQyMCAwIFIgL0ltODcwIDQyMSAwIFIgL0ltODcxIDQyMiAwIFIgL0lt ODcyIDQyMyAwIFIgL0ltODczIDQyNCAwIFIgDS9JbTg3NCA0MjUgMCBSIC9JbTg3NSA0MjYg MCBSIC9JbTg3NiA0MjcgMCBSIC9JbTg3NyA0MjggMCBSIC9JbTg3OCA0MjkgMCBSIA0vSW04 NzkgNDMwIDAgUiAvSW04ODAgNDMxIDAgUiAvSW04ODEgNDMyIDAgUiAvSW04ODIgNDMzIDAg UiAvSW04ODMgNDM0IDAgUiANL0ltODg0IDQzNSAwIFIgL0ltODg1IDQzNiAwIFIgL0ltODg2 IDQzNyAwIFIgL0ltODg3IDQzOCAwIFIgL0ltODg4IDQzOSAwIFIgDS9JbTg4OSA0NDAgMCBS IC9JbTg5MCA0NDEgMCBSIC9JbTg5MSA0NDIgMCBSIC9JbTg5MiA0NDMgMCBSIC9JbTg5MyA0 NDQgMCBSIA0vSW04OTQgNDQ1IDAgUiAvSW04OTUgNDQ2IDAgUiAvSW04OTYgNDQ3IDAgUiAv SW04OTcgNDQ4IDAgUiAvSW04OTggNDQ5IDAgUiANL0ltODk5IDQ1MCAwIFIgL0ltOTAwIDQ1 MSAwIFIgL0ltOTAxIDQ1MiAwIFIgL0ltOTAyIDQ1MyAwIFIgL0ltOTAzIDQ1NCAwIFIgDS9J bTkwNCA0NTUgMCBSIC9JbTkwNSA0NTYgMCBSIC9JbTkwNiA0NTcgMCBSIC9JbTkwNyA0NTgg MCBSIC9JbTkwOCA0NTkgMCBSIA0vSW05MDkgNDYwIDAgUiAvSW05MTAgNDYxIDAgUiAvSW05 MTEgNDYyIDAgUiAvSW05MTIgNDYzIDAgUiAvSW05MTMgNDY0IDAgUiANL0ltOTE0IDQ2NSAw IFIgL0ltOTE1IDQ2NiAwIFIgL0ltOTE2IDQ2NyAwIFIgL0ltOTE3IDQ2OCAwIFIgPj4gDS9Q cm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VDIC9JbWFnZUkgXSA+PiANL0NvbnRlbnRzIDgg MCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzky IF0gDS9Sb3RhdGUgMCANL1N0cnVjdFBhcmVudHMgNSANPj4gDWVuZG9iag04IDAgb2JqDTw8 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggOSAwIFIgPj4gDXN0cmVhbQ0KSImUV01v 20oSvOtXzDEB8uj54nwAQYAXO3jwIUB2rbd78YWmKIsbSVRIKo7//daQssSZbcZe5GAnqR7O dFdXV199Yx8/Xn29vr1hnH369PnmenF1faeVYGWHfwl/WFfuF4LVbHH1z2pb9PXP6rrZNm29 q/q2LllbL67+upPssVt8Xi6ulkvNBFuuF3/wjHOes2XJXn57YkIOZ+KH58xynxnHgd4t3kmZ iSxnN9W+LrasWbO7qv1ZlxUr9iv25+6wrd8v/7O4xEsjM8OVjE9ZpyCTScNtDKpLvKLZs4D9 slx8+YpHX/IgTnkYH5OPjxleIMNbhmdJMzwGv54+NfyGJxlvs/Cf+Mq9lOrv7lhst8/s4Zmt xvsnISLHD2XdNLCtyr7ek2irM+1VPkU/IkGs+kXBJQdKuujwsiKRwmY2j5Fdh0oH8FhIcXm8 oh4vNc9M7qMjWLEjv5YDYVGVCbQ5kkjjMpW7CLnvAzv2Vf/UtN8ZFaUkooyO0tS3xXpdl/eS 5yiMZjPFl2TxL0/Xc3V3eWb18KW7Bo2B5ug+sIIuuciEzeU0BhSvflZ7Vu8ZnTHuMs25mcYU +2dWkl+QymZO464TdEfXXSNTlsfID+y5ObJVw/ZNjzxPOKAuiRBUIpTMM6HR6ZPjVmSFVCCL i77L+k3Rg8llNTAP3GmOY61PtWN9w8q2KnrqxBxc11zb6Yk4g+RHqBc6SbrxgmfF6aA4ZMW0 z7QwbhoVlKls9qsaSkLGeMRIPw0hWxp8RDrtFJfNcFPNcpPPsRIaaU+tSJ+pqTP/SNVOzp0P Kkvl/fCF5aZi67rtegb+b2aZL72K45pVyP1LFWh1QpwO/TyNW9NQlfnQJ1PkUNhQsFXVlW39 UK1IWshBLYIIToOf6n4DatYdTilniq2QZ+mFjyP3rC+23ztWPDTHHlQsi65iT1UbRtpwgbSn 7Fyalc/syI2i74vye9WSDxCD7lkxDegODc3PMHi0yafYNWurH0dSKIQLomWjk/uOvoU3mfEY zBNsSdd1mE9aTZG7ev/I1m2zQ85pyTJBCk10POuKXcU2dG0w+XMlk6uzpkU9f1YtOEdX1ADs bJJKEupk5ryeImdwuLiI7k1SWPmQamWmQDB203Sk8GkJxmsTfb+jgS7zLq44ktySl9UYDN64 6BLHx01gcdX2RT0S+G3OIDAY35b5qS9atEPF7t/96/ZPRtdYhK/DJcRxxapq799n7N+0uHiU Qbo0pmdP9XbLNsVhblJKA4mMgg5hEnfsaYOf/blRX3N/EryXFkdEZ0EU2wrMIcVfwTNZmyef DyoR7vxQ0dR0OjPayjRoP5CaLCbcnTc2TQ10uuuKRzLCiAyXU3FEfK+3F1+gl86q3bRPtC0S 8LZa5DG8paHwN1yIGEoaDYHuUEGYp0h0U+B94HMf6gM+zsmTE7lKgj+MRmVVhZFCK5TNFE9u F6XuNUOpOOyRCWMsSt22aVbkFyFvmHoyyQcbRlfBts3gosZqk/EadkxypeMDOtq/aq3CEhJj YWCLYYaTEYGxXCT3Gz3XhUlv8RswS0OLjYzHUKfpITJunYzhJQ01mRAp9MXZzXkY7tKImd0O 3OPGxlDsnQMV6KnsfKZc7t9ydY9+gRLFyCOtAMFBceWTW9+/WzVk10gV4DyBPz5/YM0e22y9 Hvrm7vYb+9ae9XGiBDm9HIjMwhwk6fj1zKAJsElDK875D0x8qDt3CQVgQepR4WmmatzGJwVg Rdkfiy3ecZiZffCBXtnk9WSico5eyINETKHkKpvDh3Cl8qRgUy215wyKOSuYe5XZFz3eNfCS p+UoY7djVb61IaWrpuqG/W3I7SBZ4N30Y6/ucrim4FgN40/WjxuyL5SEzeJYeCI4bvc83Kov 2scKolm3MNHb5+G2uE6BB4RbFg9betiFtc5ZSH107GnOvSajIV8wZ2dDvhpX2ie6W/EAH1ov Cuk2YevEcCVDLM9ybZKP0EjojNQihg6ZGVQ9mN4dPUy0DauFSq7VkdIsTfBAPgE/ggor8s0S cgMnkbygpS/isVxIm5wdinliF8l6pbEMOJlmlYRCWa1MoSEzBbubM97W6Rh/SyNzFCpP3vnt 1CvgND0UwWgLLYuCSO+J3TTDQmVjaM++72mBCcuFN8lLy++Yh2MPn7tUXLpUkF0aKG6DiTwd MmpyeBVNcrwJ3k7EQfSg07ibDNyYQsnKicBRgxUrgtLOPgdDNfcxdLu+lzy/fz88/Mty8eXr 9eLqG/v48err9e0Ny9mnT59vrhefl4ur5TJnyMR6bH4+l5PcX2zrzKmGOvXNpjbHm3H9E+nG snXNsYWgQ3LHvx6aZk33UpgFnOfxKfQohi3OrUugv7HuEhlWRiQBkABaAeBVHbxZjCbVDr2f aeUSKBzB+HCy7wT6wqXvLGf2Gqwa2mDER+BBWjDjsY+N4y78vaKNKVwwfIKJD+ieg4Ifjv2w u9L2FN5C2+Rh6Zb72rwMnFDmMtmxYVTdptmuyMcKpTLnTBwS/Dq+WbBLFweTW7WsK56DEK5P g+9thln6YLtD9qcfqX4VuwNpl5REHuBAE/y47kjOuno3t49yaXQcRk8DzBvDdfLsbV/sK1oo Yc8dyJwc3QWfOGf4cm+S849VRyqcNiA0tpkYTSqcNuCm08kb2bptdkgPbVzQhho7T5LMS/nc RdrNHKGkDqbHjRcrdhWr93VfFz29PGDWcmtdHNaG1kF/spGQc4uugEWJAwN10TlYWXdVPxg2 WhVc5nj60Zch9ppDkz7PjAwUjaOH1pkTCe+CkZoG0HTGEiPDLhJBV4OSwIoGIaE5ilJr4eMw tj62eFT7mw1FI87zJC5sKMO69zCnPFJjfYhi6OO9gLVTyWtYvH1RFBIK/vFlwrTNgWSOOAlK hD5Uq4wtScYIrTLPrY4D6ImvYTlknsfQ37BR2GDETYwHGe/hRkg8OJSL0MbTgI7RDpkHugZF mYLp0SgEfujkIrvAH7RFta13NT0njc+UTZNZ9BDSc0v8rxEHrUMRoxg00aHpOvJ2QayxUSQV eKi3df8MHzkYkCMsAj1rMSaRBp5EIyxMc9oM20wplQR0JJu0Dp5CpofDC61eLBKtmGH+p0TB JDxzfDKCLaUmmC4IgxRxMTG3zbhiwQK0NPlh3o3iJg6jFRYritAugdKeOEd9nEsuQ3eIAYIb 95ZTw+agw+YwhbL7metCm5UxKka3rBmUjOY8fgifnP9U1S1mAbzJjONE4UTwT6/eX4aRi6Uq ht6/z+YaSXuXXH/Gzdv/b0d4oQoUOywK7ndHO+ro2QOR84s5nh54u9/W++puUxyq89H+dPTV X3eKPXbsxwLaYYZjOTZWpnNom2PKYNM1rNzhlJ3OPbtpFv9Y/FhAy9wE7M249MRww1/gwY3L 6eESDTegYSBf0OKMhnvU09NVxl2Klmc0nv1yF4005Dw8RAVq/5fyKkjSZkWB+3eKPkGHgqIe Y1ZzgtlOxLz7Lx5QpYBV9Ruz6Y4vIiUtUhIoC41faG5ubEYbukw0ZO4g7ibcabuC7R71C8u6 lB1MC1wE4wLzHivXSL9k6WsOXXy6O1ti39F9odtvIveJ4jIXOveFXkqym1efEB4MNH0e3ZaQ PASRvwmPvXwF5KWXVvraEhKGKObuXSR9Ebx0lKHJR8bfrNi8oEtETCaixsVfjhPBS0MEe6ua DtAuxtZBS5hWv9CdH/QOXioi6xJUTL+jKDpZ7toXumcJuqGXijy8B81RZhNGN/k10cPQPjC/ iw3Zl4LY5cHbB/LvoeC0nlJfAnLvrf4p8YBU+442BYc8Bndl7sbygfzCVvI6OnTwBLavuoOX iJwr9JF5iJBPrJKTCV4asmYlfCK704WuC7w05LezBCfGVibCWjgpE7oE7HU67x236NsoUvcT vPTjOop5Rq3CivJEJtr8tFkySMG5KBgXeCwJu75GFxrkMLKp9qXKWBqyD2WvIdeZagjiIRO9 NOSu1PxFkjwA5OmjGXhJyOYJIfQ1IFYRa4JvCT8bUU53J/rfX4X9ospnJ3k3A/TeEvjv//z1 75//CiGYoQhhODAZ64kx34z/+lHSrr2IY3BobjXsw/Lpxonr6XFCAnoy0okRImPTUub1hF1q qHdtn1l+MXymPzBJ24kUd1IuConBkjEBPHJb5PkEUjswSfuJtERSEnPhrknK2bfMVqkFS60D T75x4quRr0oxSwxuXhy+PzLLHOEj/YGLtKZ0IqWdFCVRTdra0PapLmWk7KLOvAJ+cuYTZ4uc 2kk5RBbGsRN2MVHHaOjJBye+vvPxi8RC4jxDx48tscNn1aMnI54YR2REsRyJwd2RGQfsHzni CBUOTNKT+0DaSWUM44mJIw4t9UiaU5LwgdVOTNaTA8HmQDo0SwzuqswqRRGSm3kNCR4eTkzW kwsB7KwgIhV5K0OH1f1b2fX9p/oDk/TkQrC5UNYuyDFYGk3mXqE5gVqwfas/MmlPPgRlp5Wb I9ehkNbHl4J1Pf1Uw0/GkxPB5kQ6g/GsyXaj8j0o0TxeKd2BmzOfjAho55Q5gGNw3oS07lWa Exu/H2/DkUl78iKIXpR1nseS5eFKKtOzaoq8V/vYcGTSniwJ+k6brhgXKz1Za1xp/YlJenIl iK7E66PMQzLow49omJ+1yi3Fv99wZNKefAnTTpu6xsCLVuY/30pzIntO9BMPTNKTLWG0pdx0 geU5vUuGi45e27eS+rJ9qz8yaU++hLDRagAk5WwPSqYIjBM96U6OhPik6/I8Jx29s9GPw06y kw9h9KGs243EAKnQKlPH8/vCAhqOTNqTGWE0o1xFJpR9TFnbk7Xbtqms7sRNCic3QtpJZX7k EPJk6Ro4KXKuWYx+An5SnpwINycqEhF532sXZ3tW54i7YTgyaU9OhH2nxSsGSKE0Ge822pzi NhiOTNqTF+F4pa3ipYuWPljpJx6YpCcnKpsToQ7MHCOTkj5GbGGtwRT8kUl78qKSd1p5G0VG AXk4+CDNkXGhJ+HJhcrmQiAjM4dIF+HYU8tTicusQ0/Ckw8VfCNka1982wf++gnQwSfhyYtK 2QllSOcQSSjHNdOHBsqQMOyGI5P25EVl86KsYzqCPBKhfQz2Qkt+NApHblo8uVGhD1odPG/a mGHQbm4p9kcm7cmRSttpZT3ALJMnF8ZzoZCP7fFj14lJevKjsvlR0u0Akw6f/EsXisiKtlAo qz8yaU9+VMYHrYyfkzamGOMeE45M2pMj1bTTyloCQ8dPTt9zkWHaFj/WTkzWkyHVaEj8gmQr 4RhCCtceE0mL7THC6k9M0pMpVXgl7Tp9TtY9w+QfcTgyaU/WVHGnBQ2BXVkf6xN/aob4qevA 5Dy5U43uxBbIAz1C0+GTvyo933DRmd9Y/ZFJe3KnWj9o8f9mxUlaTt5UaSeVJQxImqmwPvc2 Ho58Sw0nJuvJmmr7YJVZdLLu39ogfqsdmbQnc6rRnHhkkNUPqgxnwvDcFt3HKqs/MVlP3lTH zpo1BJCS0kuCW6gbd2BynoyJ0hun5nBy7t/ZSvzQdWBynmyJNlsiXTY5RhZR67Wf/pnVH5m0 J2MieKUVn12sf86vOzFJT7ZEuJMm0BAyijIBPR+wvtTwrXZk0p6cicorrQ4pH7TPFNuRSXty JtqcqUooiZGlbkgb6ZZjkr7mcuyP3LT15E1Er7QyfS7WR45DuboTk/S2Jg35FKUq2kbKelvK hr0+ibFJrGpi0WP7vAjP5KnItIWZu7yhy2vkEeBpaVSrhzc38CeUqJj7bzE0fV/7hjc3cdT2 evMbzmYj8GJJ6a/RydAcxNDjOzjwciFoa86Uvm9+oSv/neD8eZGJXZ2Q4DWBd2BOHbIvWgsj /NM9bjiuDNK7mmRodC2D6nfwrBsqw83t6V1NfbA3HJxRk1Nzr/4FN4OldzXvy6DImc0Zafjg FzjLarbAyTlLS69X0dhJ3ojAzRFa/r75BZcZcqHBo+EVbJXcnKBulnBX4ZHCirmVEJxidFk9 GW7LWKs+Or3Bm21RjV7R911utNV+ax6e+0twcltLc4LGbWOiq6v9NnxwvybgGLp1Mnyhe/Kx /Xi/0MWN9z17+L1v6XNZcHQjcneKul20BDguSTt6eOovVwdX0r14eKUIR0XbMNnra/D7LoLm WlpgJ6g0m/CZgk2uPruTMz/DJhFhQp2UfFNrKRcY+C8ZeHhwmtoMQ/N+0FOe+GFacqWU8gje 5Qsm2JTkhz9ovzeMZpU5wIMLvIEzuJuYkPzwe3/chCc0Dy8e/vKd3PbJwU3JpI1pj84v1sPJ w/Hl8sUV2zAxuU56eUEvaPdQfFyDe2dy1zA1uaTaS8LBCo1S8mh4vFZBl7LQTkw0c6NZNzD4 bZd1F0pOTwje6Q6suqSEHp6fdQkjWV1ScnLm5Vc+ONuWv031+EzP8H2s0qTk5EzBJG47FDTY 3ZeeUlsPY4behWGCuwOnp+kLGvzNl6ZcWxVe8G11WspL0iGtY29XgoWVw7wU5VoZ200UTb72 KS9FhzaDN/zqy5SXoEPdfZ8QoFfpYhNdHBr9KLTAidxVlpxDzX2fhaAX68uUl5wD3iYnQVto EzP7Z34PZdDxtyZ3E5MzbV154RM4/JJTntBjsIUOktEbDEtOfhQE4S6CzdaTCZaaXYzSB9YB W9DFpRCWmpzb8Zz2oSfbPAjQoZO/yQKjgZeY/PEjDHC6pUDjpcblEJaa/PW47UsCXksKwZKS PwfdNXRrg9adR8BSEseWEV1oBe09ArrDeyWLrogP+FISW5gMJHyVr2zmKLiUxP6bHZZjtw26 hMQQlFVVoPkOgiHloi5qk4FgQy8JsWxZbjIRQCNnU1i+0KWr7UT0UhDB1jW9dpfUC9qbGtIX nqP3J9yUTMLqwnMRMbyaBaKpmOMMXoZaSQAvDWGvxiGzpIDNMMsSEXqYNEtN4kIbeukIJGZk F+FJqwm6BHstS01wBSx4jj6e8CUnlCi+rF5d8ebGpTh09d5ds7jzhl5yQg6jWOGxVkKjs+5C X+CK8m9D2+zTo5Q87PcL7cY8Kv0LX8tVZRveRqBiu4bGr9eHgusM1UagGptxpevdBrRZrA2c mpV+XQWsjVRrlrFB1a4F76Howrr8qQPz6sUtzlpCLe93QH40vezg+gFuOh1uYHKZqw59uZOA 05KxNgf24xfobrqB+5smeo8svzf0cIqDbRhX4aIMpQtLyWHddAwg7XLD5ncsjWsMDFhwb9rL d9cJ8mxgzZHwowKQfyfa0eUjNlIT2Ia2Uiz+GvouBVoX0uowdl3M/IUbtr1FRSK5fkT2NxcT NbL0UBziTRM73rGYm1woYFv6wFL5h/Gy2bHktqHwvp/iLpMA8UgiJVGAYSAeG4ED2BikO6sg i8AZxzHGkx8vnLx9SFaVSKpVgBfTc4H7XRZLRyQPxUtGNt/03cJRhDR/0MsNCrkdxRRouKMb SLNZaBuJyRYasR2NxGGBrBBTuF5vaOBWw7IvdHM0ubYFrchMWWibh8UKWzPpV2yYhd3phoas a99CD0d3vyg1naeRJvM1KGdg0vBd0tgkcl50djQEdeCIHehyExtakg1xoc3exO2ktCqGRWiY WhLe0MATruBKm5b+QCrbypU0HaMpLHyvNW53ton6DQ1Zl9SFJk/7PEh21AU2GaP5LXy1z9Bw wSPdwMBW5QxtcL6Da9duF+CpISZpnO48ilQc8M7Yp4YDHN18zSR91EKjp/29rrrRLPTUEHO4 14XvdVPYvNtoNzCwn61lpbujveeQROoKTxURzJ+qMEl7Oi9YfdbXGJ52Z530wgS4p+RgCMqg NvZITx2Rv/XnwZqjwmWyxbHg35B3ndEWGBxcgi46mCJsIlabnZIGV5cMGEJzjz1VR0NIYyWb J0PVFh0wkXZ2JoVFoHBxyQkynmniztDk0K4L1wBKdJCLcOHOk7oFV/FjKjF+2cGezdMgxO4u 95rhItJftLkakcbfp1oP0YuU8IUXw6tvIoWvCAmdzRL2DEY3eS+Hw3GKljYay/ukz+Ps7Ukq 56Kr0dq9XOSio7cPc0E9O2865HYGHJRGS7t72hvOwtsOe8hOcmkv2sSs6ZPwjknKRWi0xE1L iYURF2sobnkmXtyCUeLFktSa4jPxkj192eqmrAy83j6xyKYkHzD4wKR9hOE5l3oxJVloKBHn KcbmmiwP9DQ1l8jRdmTRNdq0lCvnQ3ct4WPbuOjmab+VFL5jUqBdu8aFm5a1WYOQVCQPkMZ/ oeTR4a+g9JYDtxNxQnYpQkejjg/22H3i4IQkK4WmtJg/2eiMdkIOHxmkgI+t50KdjkOgQEsB d/UCF25CSp/256HmDnpy3QFwS2vwiVt3gOrx2iIOqMuSBTcleYRml0mWfbGNCXYPhtWSUfFm jVxvANOxFXMYUmLcnPtclC58eLy1iIvnYtyaA6YtrsmceHPdAU1JMU6+3tn+9HYtTRdePO5N ieBi5Ft17QGdmhjbA+hGIriljltag580miPuWD3eI10UtgaBTkwtbpdJ10bF72MdArvHe3jP rlatwXSBHcnTsIGL6xA47mM3qZxzJzrx6gRtsbUxnnVvMddT85Y+gx+0hS4eJn+1eG2QRshl Yi6iOjW72STNpKqPPhaXC8cQPQYXug7XJ2r1wcM9xMPjDfMQte1gTeSESfz1RXdPB8cBc724 WCclBWNVANQaczc1B1FHCB3EmXiaJ9iSj352+yyPL7yNilM6rP2FZ4/7Rss0Xv77gssmtvar C+a2P2HYRR4CZzW8h5W9aAy0Gw5Mw0GD0XVLa9onXlwZN6eluhyHJ+3hVU3lhfct3ozOtib2 Rp6e1nQcuBxKEtUueni6WugypOPX5Mqypx0rWR8wWxqryp49PCjSMiEYL/NIetlm3YwmV5Yd PE3+vAtJTxPcyrLjFpcbfuHd1WWv21wiPguzt/sXJZ0+bIKsMnt/fYhHOVx0dcXW92Jq8K6z inErtj7uMz9xdGOZ0u09ZFxGG+NpJkN5i5/RFQcrTirbmvB0cVOZ4LaEDMcpKeHraj6Psenc ZBtiiddtn0BHJ2lFF952naIpXJS1IUt9G3pMmj0C2EvStncaTG5o0tj2Zc266vyWoT9PZKQQ mzZ4t11jZE+7lmLsfMdRdqwP3JytHk5Im4GRtk1joI8NMRHxETw4rTJHDbGXIzlxc9ajeTz4 iAtHt22MvsWbp21sjuCAOm2CgznrERyQ90sGzzqmlLaxFUf1SzzgZh1Tyh4PTs/wWceUnJ7R RV50nmVMae9nPZ2sjCntDa1PJVkZU3KCLub6xLn9D8u8eXyTC9MGOzmXteCiyaqeEm1xH5xs KFMKO0re5dLNXVN2iuquuMNh0tnTaSMo94s5xCk7Qd2S54M36xSU48K5O/Rqk5wybnGfTLVJ TtkkZf+Ku+ho7YJyc/iWzZa4KVp1vXydCfB9vmgTlB3p2CkE1iwom6C1LfPqKNFSbI5TSR7H TfkznuchFlO01mjILzzPbkGleBq3sHWLYnqK4d20ucI/nqdY0OObNpeHGXIqTk6Yjcu18zys WRQnpu5/OzrZGXaPl5iJ0jpSL9rpqfvf6+Dd9Yri9ExL+euwZRrnGYLJicPqc07m3My/E2QP 59eRm2sUYFoiLeVzmI9c55ZCYFqKJw1pnOzsEmBCssWM5XBYpoyuS4ApKR5zS8+VhsCkZBPo d6vTSWZwPQJMSfaAtPGpjFuPAJMSyyuHLS44F9cjwKRkW0e4xa1NoNMyLTPo8O85W5vAKSaf CoSyPzYPhq1LYLmjezsyCTQ4Gl0H0tazwlNOPvBCm0SS6z9YHQ24SSTQzdH4Oo/ATi1Zymia dM1j2PoakoOLLzJOo7+ixw19NO4I1ykjLhPz2GPTsIZZs2N7kKXLgyJcbuBz2kTYJEzRoHAW dMDWiive0V3M9wJXB5eYRmsrPBXkjSJ7VditgdDkenztjk5BFpLbstB0E/uc7As9ReQlIWyB nMk4aDObLTk6WBPOhJvTQucb+rQkCz2FDJXIZhcF7TaYGmzJPo6j8+RUkFeJEUpFPVSEp4K8 GqCfSJzDKArbuGvN0eB7JOcxVrjfhD6t30KbgiXef94rqtDNue42HB28CCVJLNI93dCHZV1g EzDFTi2vIaGrm9G9ODqsOZRlOC80eDoUDB1pB3oKyd/Gwq0yhoU2uDq4Y0xk4AK3m8iSB7UF njqybtWLDk1ab0K3g3S6gwlE7YUeN/S5NEWapowlyNLV8yV0loWmiNyWRzgNPHN2cNnFPbfC BZ0ClhyHJ5D4pgRuYyJ0sJ+dhaq0tIWuN6GBL23ClTZzo/7BiTLUrTANs/VSd7R3wNRkbC4w 3YQGrsRXkZ2xMQXlHXkyychPxRm44XxNHIhEx9wKdL6JDXz/c1vpqSLFjsCDeihr++OAG3ak ozMFGPcw8MXThh5gU3Fcxu34VPjc5L+hRvfC2+uGcHwClkZ0DOvjOHV88/YZ2cK/feZMuBk8 xHTI38rT5/H89punzB/x8fMjp8fXj/z4gf/94fHnv6TH3x5Pb37/XB5//+npvLLHXvAjjxXd GQF0onx4en7axP7p248Gqgj8w65mD9gCsOAf+PuqA5p98ZBA3/3m6cuv3z69eff49NM3X7/9 6osHT4bPPvv8i7dPepZH1M9fnt68vDRO9OU7fnIqPKRfvn38lj9WdlQvPz/45rJ/01+cH68j 1Q6X+Jc/Pv3q+atfv/zwtGHZqSYuvEi/e/zpd8LzU3KbDwQWaPtAIC5FSvncHRIcj9w/EYgN E0rlevgmPSB2plSWyO8e7/6z55FnVsW2BP/nf/93vk3irn29Ddy8jfbCxAmiTOLrSF6+vznA weOv89gJ9PvH3Qtpm2ADFPBv7mD2q4mvWczkBtadsC7wlzdw4Zsr9jDAf7yDxSDhL8yZ23KV AvlFaUitydL4+gW/fDnK46uPH/7x8f3z93/913srFDoLhWsWuGYf/34aYZJkbDLesFcbUmj2 Vv2pwXwhudtH2NxtruazNTTIr5Gre44dbHctOfNdqitc3CDx3ijL1nKEhgmDh0PWbIYXFnej kidU5h7EPQk72GDAth2sQpMavIU2a4TyeMvj/4yXS28dxxGF9/wVd5kECNnvB2AYiGUl0EKG ETJZZWMolO1AUoLIgJN/n3N67lRVz51WuKFE8JuemqquU6dQwrzRQbNXDZ3sJ9bhwg60mqNK VTdno4y4HDXwoZ225sgOS49NrJQDrR6Xls5sQDzbhUGHIrS/HVMbXenpDrB6XK877wg70ePi NFZsp1ce1+Pe+XSkdVkJ82WF2WC/gJb5l9TkHmlcD1eOtN1W7ALi8XQEjPiEXS0rHqkYpbGw 7irlcEc8y03Ya/p0V5n3MV/HtjnTanLjWBTN2Y7Jx7VgeXd6tW16HEphmGktZOcN0o/ELUDe SHu5Uep1QXt7R4C1cqTVJXmxmAwE15EtWXArhZUytqDJHvCmUICd0lLGZrz8iBp9AbhSiXZY 6ghB6vsnlsHygpTRaDssdYQh782enJl70llgVdU6pyMM6StFt9mkRreZbmQYkY9AkyjjOyxF hAnw9mBc0pJ0I0zqcWFU5wJ6LkqkkyROXW73rJQG4Zl1SC7LuMNSvx5o38zRm0qWaKaG2twe 7ULhPW0MYDSNsFK/PlYpCQNs2FhR9l4N2+wHYiqQ9Uaqu5SvZ3XmV3i0iueX7LTUDw68mygq lxzMQRXT7KR8vc5qALdcByzymJ2Ur7d5JgLm1c9dBS87LWGf5y3mLwYEaZGw7KKhp3RsWpqb qFJ2UkGYOq33ODqxUXJTnckuK+3l1l1hXO+UqypHdsXSZcpI5EcT95o/3TexHU2TDjg7K5d7 DaVZukw5CVQ10k5xXTnp/20oYUy6nFUQsld/48aeYg73oxfz6PUd9xafRozfFDUn0YTs1eG4 PKkeYE7GHClCOx0t3WwS4X/Zvnmow46behZtHJ4OnLMxB9WG7LPFm82ia7jwpBU29cQNt5E0 eqSUh57sdD2jrydf6ahxN0tPAw+/01Jmpy4xe1POpuZ2xFLZv8SjJDE4i/fpMwslInWViBxM OTvqNsGUiNTVn+UQLC0DAS9hwSoPp5+/4k31h+XORtlAc5ymaho/aH24itpmxk2rgw6SlVAs ndNMI9AE5181K/UUL5bW3g8m8KBKMQ6PYwCnoUU73i1ebE8ApwylbJo/Oou7doInbf7oLZ2n tAwxIO0li1FLBCXxG+75FuKc8ClqO7feLT7pFnSMupXGS/fTTY2SDvkROkWStNNYyunhhvam nWO1Z4cpFEcDkbygzaJXD339SDckLnZtz+5MwvO9CRozgxtL7KY7k7dnm3TvcJPJnVNYHdyG FMZmGjNFC5c20dTCWE1jpnRKMw6hZXbnlC1dkyYE85nCGYsO5O7MJxaV/DRo6mYczbyf3ezZ NmyBtS1TPz2aNE1FiknncXbLMHY2SD7yHLMpOWBKbIzaYt0FS1dbxTwUNo7W2c9Op4EUAztN XlxGfaW9Ttfu0hcCoXZHNsIeR1nHMVinkzVXyzYzFWgMB6uNmNtJ8gwcxtXe4X4aciHLiRCa GarlvIZd6ar7RDee6nB0HNMjVNOI5TzRXemiO0J35fQTB0z7GrJprnIOMx9Ca3OVetJc252+ 0kziDrdlAwQOsZCMMy79rLUYxsZGbcPu6qoNdzbo9W9LqQlj2oWgbVj9UmkE1j6sS8m7wt4M xhonLS1ntM7Fms6OZhzjzBSc6dmaT47e9GCjsTyZNuyW9u3mbN+1DavJ3jy2driZkVjPj95o DnPQ2onNfeHsQVczEpu3tC9T2Bu9f6F3p6g5uHBs7PRkKqxj2els7G2LlnbtNozMJXCn0/Js 9mNClmSAtmxZu5IJqwO0TZbPJmNjI3fc/QPDGavnRu3vbtYOazwVDtrebba04SaIoP43t25h p6bzynp1v90sM5bVg73pb7vKqGtX1hnn243DN/tAUVZ9bw+WTe14MF6mzd3NtmbWGAtLJnqy 7DEReJfezNXiJajXnJm1q/C+HuHKDttDKBaO7RhDNUtuNwfPi+gVLkYAzJbDHffmXgJ2mjSz zCUd2xJF1u4vxrZySbmtRhbS1DhyvhzbGc9L8xdjjrYN4oaO2vzF+B3Q/rb5QUvzF+N3YPHr 7dFBmr8YNzDWgRM2atCmfO6oQRRlHNE0dVJAuPb5A69s1JCbsreku9dDpXaw4Pl2PoGV3i+q x7DJ2Zw7Bl9EWDLai6oxje/NlCQsvV9U2eAKp667wk2bv6i0wY71eVrXwQaNOBk2Hg1GxGcU jVhKBwsUj4aIrNeApXKM0BbuChcd60VbGkmdfRnyRdZrEFo4ty+BaiYj0pOVldq1Pg/S4ccI 7/O/BClda7MfurKJU22HpXat6uwom7Em6hSVyrUyK/xwmxFxiwsvQSrXkt6JCZadpISksEYw HG9E0rX1g9StBa1x2peoiKSLWy9BCtf8rGtcz8iKAAUpW+wUaIlhGPqI+kjXh2ZQzZfHPpuP qBQt1mnKjZ2WqPj/EqVosU3J9fy9HGmpWrTt1piqiBuiShKDklZJeCz+OcBSNOyuKU0n9w1W 3YlpAXsmJhxpqRy20WmP7Fsc7b5JmWMxsN0NfRrj/kBr8Rw7RwNxXDgJq65FLZ+fJg2PrkdY Chj65Ek3wY9oGVXBJBUMbdpZfBpG6UBLBbEGFltvjA3WG3QUWIqIDdNP+QijpSdYiohdLU3p iJS12IpR2JQMnW0VU6TaHWipIjafaI9OQ7xbMYKcioWnVCeakgOtnqVpFUdCMkUztrG77nRb 0SnzahxodS2JXWrirkONWhavV7LalqzJHmGP3WaGVT7ZR+bgPnq8JTMcso4+9rLC2W0ln+Br GQd1uTy++u7u4U+P4fLjZ1Rq3PPIXatcPqKzKS8RdzRdPtw94vcxhmPIvBz4ex32i0Anwb/j /TEODf5w9/53d4gDQn/9ub3t5i2ZO2ZEfsdDj8dnPr/7JIzjxzOwMeJjKhQEvDjX0eyp8UNv Xzx+bi/HS/Ll1wtibyNWpKjxyIAK1rQPsZswthMYSkDcvAibn8CDtONhH9cf8PfMP1xVasTy +u2ru4fvL1999fD21ZtvL6Vfvv76m29f7SXgqd883T08PUHuL0/v8WYXcAGe3l1+j/9mJOvp 1wv1I2xG7PpfX7aOLpwXTx/vfvP45rdP/7g7AyHGHPWKfn/5y4JtMLkcccr+YUXCqwVcZCUf FiRGYuWAM6GuSBQyYAopufom6jub23zTORm4fWDAK3ghiMz62plkt0pvuvdcTHj5oKTjFf9e RFPh3ysa1bD/XKEwl/T4Bv3PKsM4FabRov9dobChfg5gVY1RN6wvBl3enFEPKrDJwZ4+h35B +s4yV6ELjg2LV8Gmj+f+vMoH7F1tfYafv5A82iHL/v3n1YfC6bLdJ3pVQXracGCf3/1C+vXT 1sJvPn34+dPz408//OtZmrm6vZlpy+8jLek9170hN553lHJzK63cD66/bmpzeHzIXtl2Fx93 wR0rnjy2/x1zcBfcg9ZUv9KaLFrjkNCr1uBNi2bIkPpLSMORMTV/XKQR9yQ1bCsG/WGlSugv bpkG/bBCoam4ixb9/AWtyz1b9Pmyuk1wPXU6ddUHuHcVc9Si360uEog51L+umgulruVF78e2 0mKbKvD0hZb1fUrr65Uy4l4F9On/TyunXHczushq8HQdcLUGfbdCcQWSn9K6kM3gaYTcVNeP CxT+pBQInEEXEhHge2tu06mfFih8fc91ivXHFQovAI/ykmRhp8GnTbG+X6Cw+/FQ2IWYBXjs 1nuf8rrKVoaxxYdNwf6yYAuMUJ2O/WlFwk75KdaFpAc0bO8lviRZmLIuTocufERAZ9c+98vC xgQYntTbdF3fLlA0bIxzsVatBTuIUOesLoKNjoh7iQ5Eh2Pd9FkL1xM9PJcL03VdeT7cKvrb 8oJsbd4/9BdUK6K3WkrTZ/3tf5RXy24cRxK88yvquAbkZj2yXoDhhWwJuzoY0Fr07sWX5kyT HHg4Tc8MTenvN6opilPJSm7tQdZAjqrOykdE5N8ErMOSZWusFAGGy9QTK3QrSgUbErqgkGdn U0Vv4+qPSZgvF8xgY64a4ffvJKxDK+YeMlj2JzJVeR8EKEYBFjh1cNyypdVIKQsxDCnW2iXM t0uwHIb1twR1KFjdtILKYGDw4xR4JwCxUeD1VQHmWSBOgsyRr1VmWgvRQo2w/5DviJYwNpqo DkKAWio/qnTdS1AspqF2UEIbEiTJ6Bq6EmgWBINrc8/g4kmDMbWAC3xEQIToOviIPCYsuprm x/VaehpUwZCt4NNBKgT2JOwc4cXbFksLrnjN0joa/JPfHwXtN5hhbDuxRq8lMHjPOAZWh7tZ 2gixehjv2QGhmYtphMVzNVhalzJhoH1gcUvyqs0Q/GJKTtCSc8JQRW9MDZa8k0ZPZ227Xlj8 o3fFO5yCRVsIPTKaxSzZIuxNyXOw6CLR2k6zqgi7DP5gvcvsgZKLWpwkv1nKs3NDTrkvGRC8 EFJnTQgrReBdKmELKRbR7YmYsIBgfvui8Og57Gt9YfjCojH0ZdkHbCyZDYpoVwuTJla/Sa2k TEMpYwTVdLVdzIPz5PvAENbsKHTNN9zNEF5QjbRsQTOdd53Zy0UzPWslJcmx1nD7nqVvK4Et zBNL3biaDqKPBLtTYHGLThJjGy3va8lvYGxJ86sFYXaYxKC970r2o/fkYMlMYRQp8W5SoxS1 ByWQ4aMrmToPUrCU+yIJIAXrEp+Df0uGEbvji0ik3QU7GaxYjZVMPjxjIMufKJrRPKTk+PRK 1hG8bi2LY1xLXp+wSOFvFork9ot9dKzqQ4HCiehg1MVKLaYE7uo1UwJnCXcZl+MXgrZ7YFLJ /SlYyFAxMAEqXIMnaSM1hd50EfdTuFBXE1NZCX0NFmygQWHzsj+egpWEBmXFQCxsoVDF7JAm drXkuTJW3uBY0J9f8TrBsbp8kcARuuNY7iRFg9fRobB9xwOtsYNPPBuSNJiySjmWjdUkiTa2 Dustu/uvVwxM5E+cBLqy2DxiNq4vIdg9yDGspFEUsIPyfEgKj/3DeMeTJ5k/+IFgbF/ImK0Y eStJRjEkyLtlqROU0kbsbLkXW5oj85CljcZiDr1O7G5ho7FYUGIKvi8dWFCSTSwQyetnO+SF XDtmFjgIcMpdw7JYEsvz8SCBA7g0suYYpauNG5IO7Gppq0KxMeKhr6UxsSBeXhZJ9izWGYp8 DIWWdg4uNPi+nnZkoKj8iVLQ2A40xb4iOkrFn3EBkLwLLKtOsS+MYou8pr7cwRWhlaiLSx9d UerrfxdoSBDPGvxe8kS6LJksDGFmXYS1Ddl3zaxLuhSF5fl7CQzyCLztBFF2qfxI1Fdu7BE6 RBazIEIue2xhPvVlAwqOzPX1Bmk0EgXqqiBM6pATz4ZAHQQFty/6Wei6xR2G0JUMMmHwltsZ Yd0giz56YZRulHQ39h5P3IUJiYYcDxGgvty5UMxg7qsKlqSsufsR1i+CMzCay6xk2mENrOVq Lz0Q1gAjzsDqUvJKBMHPJru+yyH4aGkGvhbA0Q3OhdiV6q+rgkYpTQ6vqazxoTzQ1WDBSBgP /2qLQzkFz/NaIMeyK4Si4Kfw9SDbf+yLqUZLD0zwd77w3SlYWoewKthk2BuldQhEQ9aw7E1K YGksTjBLlmq45KwWl86TLTmrxaVbFoiSco0/+GFYIKJLL96qzO0pWPL/zkMPDSuMwDZYKzBd PB9SzJjb/CJ5Srq62HQi1k6SmcYEJMvBUl182fgK2XS03uL/F4t3Cr6Unhhh8SyxRlWfJHQx YoEF8kGy3hpFTKwugjJbDExwfQ9MKGE0LHW/ScYbzeH4uLx9xXg7y5JxLoHhrByx5wmJc8AY x4siJM5Bl0NO1JU4B62Fn+C9IaEtiPdFR0vLgg0w6Y5VRXJLGFl0HYvjswSGxml+8xfZ/afA W1SqCtx/1rGvKPDz4EfXVxTKQ4w69BUFqqWNYUKkfpVsN5Yyw5lUNPQgdM81bi3Z0ujxg+uQ VO8I+YSJ7Yuj+O7MwStpwcHMuuSpr4bQw8eVtmdmcxxMyl08Wqw0GCl3tR1BOU3gqZslP2gg y1mzB4peOmPAtelKNNlivLPrKiFhZLFIvhDlV+xx5kwqxVEcr+c9LQg4kR2C4TwjmVLCcmgM byUJnIb0ov+lmL0bvOPOSk1SEYOFxXOhL5AQB52JPXExj+8vzt7/8vPZ+YfddrObPt2Md5P6 4YfzX37+8E5Fq3788ad3+L//+OTU9UH9eeagOna5uvxKygRf/uFxs1WrW1x0m2BT381n/3q8 +OPzde75Oovrzn66ODu/uPDKqIurM60uVrj24kFBUvTjNx5/IYNDqTu+hKl4ltun0E++QF+/ UN3M78v4r8ZFyAPm4NT9N270/9eNiYYc/8eNoXXj9+UG9GDj+d8ux9bin5aV/9yMR/Ww2W7V ZfkMP2MwAM75WB+amtBiHIGvoep4M6nV2DwAXAI11QcOk9pclVOtI8XZp2RYOOow3k6qiUf4 UPPAPjHfN8Gwp5l4PPs2FGnRME0VdNWOGeKVnGZYdX9oo1METRrLIm5Cs4Vzw6DXF9/eb4+b u23zdsgi+CwFnr+7eb5qHwA7RIqsadZtaCEJz8P58FGN6/W+eTst5eRHmo8FRcEQvYC2ry3q kR3Hqs1OzU188URkOupOvuwZmvXfuh0FUhdS5u2kjrO62s7zWo1Lyy4DawpnPf56fXSx5+Qn pvmE1H7cz5+/nP/2tjlfCNYEkHV16vzXab3ZT6vmiZQGDICtTxzB6bu5ecAaHIgx1gfajW1B DxncXkF3R/XXpn01xcHRogynsbSnEUuozizsze3fJeaMLeaUdeNb9vEdiqeLWuPuJLIybnqq Mnzva9+B+ddPDXNxM+5Ahxu0b5ug4bozCL861BwhgzXBlE2vgqo2N8P5U2GhCnrcb1Z/bNrs HzFDUaf6RHOITMIQLYRYXX7YHJu0bDI4yxKLZTxu5t0bdXl/VOP1iMluNkY02M9CqI9CXh6W NyzppueipFZRLIx5jDnzaCd8GHXZT4ebJhtSKKzPPj1v12reSerm0AAxeJ713f3tpchzxvJv 7NV8pQS+RQNbHdmBP+8F/sILomcVPRwP6nputiJlGKtQaPf0wO66WRoPAxkM6wFQ47e6nAxL eHVYbCzm63EoR7Wa9sexPSkWUhbhw6oTOzXt1s0Iy7R7CGaNv5s34Ky7ad8+A0m2hlhUgtLr Iq0cu5p36/Pbze7+KDiagL8oUH3qYfrq4SY1Xm6/yYp2z0k0rSS6spRZzXLS/rIDJKXM8oGS gaDW26lwVPMYHL1zxRZWKWlDQfnGxRo6qLdlwN+o+X6vbsuo3+3ny+10224rMyQd2RUK7Pmc lG4axnqbn+j+WHxy8bIo/7Tdbq6nXbMBsMYEk3x9eDWVCJYLJFfrgmdfnJbOvGvPmi38HIr3 Oz2yOx4G9c92ZDYF2JGQWGRtYwnKsyGzeN48p/DZr1jX7CsNRS77S3XDkr9iWm7mHTJyPEzb K7WbpqadJBCECY7qKw7FPgm5J6IhLrWvwt6PGKURjAiX224ZBzniH2p+oZCWNYZV9zCp/on7 1lyaiik8aa5lgA/31205LrwCIqyOCdCIraCM9Cm0rdne/ZfxclluGISh6K+w6tIPDNjd1e4H tIvs0iyY+BEmjcnYzCT5+165TYs9uO2KjYQASVcH/GKKxa4jlSnOYxwVbdN3OhiHc7C7yrNF nDpim8OadMkIj/0496jtpcfsD38pEvqR5ek/7pJhkZxmp2+KG4SlDIN2wvi5cdgWHQ1Nn9u2 YVP0cbG84Be8of9Z3fQrGoneVMXi8PqdJvnYDCBkVLA5NTVpiGYE/j59loMzrd47gtDN7dyw +FV3pp8QicWlc3p/gO82rqxz9sR2cVXZK9tSCgWn+EiMEnI6RyJRO9BsTuK581k2/4uTCXdy ji1/ADlkAkhPBYJ8G312jpz2jSZ9DmDY/ayCaJAECN7P9nwbTBcWVYVPYJLJmYNjbxw6yynI S2sGVg7HFXbMhMSCZPr+D+xpdProNXya//IcEBYFwMyKSN0vLPzMfQgwAM+DT8cNZW5kc3Ry ZWFtDWVuZG9iag05IDAgb2JqDTE0MzA5IA1lbmRvYmoNMTAgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxOCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgMTc3MCAwIFIgL0xlbmd0aCAzNCAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIibq6+8hVILp+/QoMXMUDrl27vufI9ctHAQIMAMFtLF4K ZW5kc3RyZWFtDWVuZG9iag0xMSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDE3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSAxNzcwIDAgUiAvTGVuZ3RoIDI3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJunXzyo3bV4gE169cuXnzCkCAAQBO5ypgCmVuZHN0cmVhbQ1lbmRvYmoNMTIgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyOSAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTc3MCAwIFIgL0xlbmd0aCAz MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibqyesaVw4eunj17lSrg4sVr 507e2LwIIMAAPSxHWgplbmRzdHJlYW0NZW5kb2JqDTEzIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDE3NzAgMCBSIC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIm6veLKtVNXrl64QhVw9dyVG/uuAAQYAH3NRUoKZW5kc3Ry ZWFtDWVuZG9iag0xNCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDM2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA0 ODYgMCBSIC9MZW5ndGggMTggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIli YGQiAJhZAAIMAATxAEkKZW5kc3RyZWFtDWVuZG9iag0xNSAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDM2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSA0ODcgMCBSIC9MZW5ndGggMTggL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGQiAJhZAAIMAATxAEkKZW5kc3RyZWFtDWVuZG9iag0x NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQxIC9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA0ODggMCBSIC9MZW5n dGggMjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYEQCTNgARIoZIMAA BNkAQAplbmRzdHJlYW0NZW5kb2JqDTE3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggNDEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDQ4OSAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiWJgJA4wAQQYAANeACoKZW5kc3RyZWFtDWVuZG9iag0xOCAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ3IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA0OTAgMCBSIC9MZW5ndGggMjAgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYIQBJkIAqIYZIMAABx8AUgplbmRzdHJl YW0NZW5kb2JqDTE5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggNDcgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDQ5 MSAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJg ZCIFAAQYAAhzAFwKZW5kc3RyZWFtDWVuZG9iag0yMCAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSA0OTIgMCBSIC9MZW5ndGggMjUgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIliYGQCA2YUwIICUOVY2QACDAAPiwClCmVuZHN0cmVhbQ1lbmRv YmoNMjEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1 MSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNDkzIDAgUiAv TGVuZ3RoIDE2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAkFTABBBgA BS8ANAplbmRzdHJlYW0NZW5kb2JqDTIyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggNTUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDQ5NCAwIFIgL0xlbmd0aCAyMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiWJgBAMmOGDGB2CKWAACDAANVgCGCmVuZHN0cmVhbQ1lbmRvYmoNMjMgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1NiAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNDk1IDAgUiAvTGVuZ3RoIDE3 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkIgcwAwQYAAwKAG8KZW5k c3RyZWFtDWVuZG9iag0yNCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDYwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSA0OTYgMCBSIC9MZW5ndGggMjcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIliYAQDJihgRgAWNIAkBVHLChBgABJXAKoKZW5kc3RyZWFtDWVuZG9iag0yNSAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDU5IC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA0OTcgMCBSIC9MZW5ndGggMTUgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYCQbAAQYAAbqADsKZW5kc3RyZWFt DWVuZG9iag0yNiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDYzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA0OTgg MCBSIC9MZW5ndGggMzIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYAQB JghghgIWIGDFDoAyMFVADWwAAQYAGPAA3wplbmRzdHJlYW0NZW5kb2JqDTI3IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjMgL0hlaWdodCAxIC9C aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDQ5OSAwIFIgL0xlbmd0aCAxNiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgpAQwAQQYAAfhAEAKZW5kc3RyZWFt DWVuZG9iag0yOCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MDAg MCBSIC9MZW5ndGggMzEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYAQB JjBghgAWFhZWQgCoBqKYiQkgwAAdcwD6CmVuZHN0cmVhbQ1lbmRvYmoNMjkgMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2NiAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTAxIDAgUiAvTGVuZ3RoIDE2IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmCkEDABBBgACKQAQwplbmRzdHJlYW0N ZW5kb2JqDTMwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggNzAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDUwMiAw IFIgL0xlbmd0aCAzMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgBAIm MGAGAxYWFlZiAQsLRA8bQIABACNMARwKZW5kc3RyZWFtDWVuZG9iag0zMSAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY5IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MDMgMCBSIC9MZW5ndGggMTggL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRkohQwAwQYABITAIgKZW5kc3RyZWFt DWVuZG9iag0zMiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDczIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MDQg MCBSIC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYAQC JjBgBgEWFlYSAQsLSB8bQIABACepATIKZW5kc3RyZWFtDWVuZG9iag0zMyAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDcyIC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MDUgMCBSIC9MZW5ndGggMTggL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYAQDJkoBQIABABKlAIkKZW5kc3RyZWFt DWVuZG9iag0zNCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDc2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MDYg MCBSIC9MZW5ndGggMzMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYAQC JjBgBgEWVnTAhgVgKGJhYWZmBwgwAC5UAVsKZW5kc3RyZWFtDWVuZG9iag0zNSAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDc1IC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MDcgMCBSIC9MZW5ndGggMjAgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYAQCJhBgphQABBgAHTgA0gplbmRz dHJlYW0NZW5kb2JqDTM2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMTU2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSA1MDggMCBSIC9MZW5ndGggNDIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIliYAQCJjBgBgIWFlYUwIYfoCpmYWYHGgE2C2QqIweFACDAAO1EA5EKZW5kc3RyZWFtDWVu ZG9iag0zNyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDE1OCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTA5IDAg UiAvTGVuZ3RoIDQ2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAEAiYQ YAYCFlZkwAYF7NgBTBpZCwsLyBiweSCDGTkoApwAAQYAAXADuQplbmRzdHJlYW0NZW5kb2Jq DTM4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTYx IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MTAgMCBSIC9M ZW5ndGggNDUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYAQCJhBgBgIW VgRggwB2QgCiDEkjCwvIKLCZIMM5KAKcAAEGABM6A90KZW5kc3RyZWFtDWVuZG9iag0zOSAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE2MyAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTExIDAgUiAvTGVuZ3Ro IDUwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAAAkYgYAICZhY4YAUD NgRgxwBIkmxg1QjdzMwg40DGgoznoAhwAgQYAP6bA6oKZW5kc3RyZWFtDWVuZG9iag00MCAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE2NSAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTEyIDAgUiAvTGVuZ3Ro IDU0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAEAiYgYAYCFlY4YAMB dijgAAJO7AAoA1PFDtYDN4EFZCLIZCaQFVyUAIAAAwBRvAS2CmVuZHN0cmVhbQ1lbmRvYmoN NDEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNjcg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDUxMyAwIFIgL0xl bmd0aCA1NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgBAImIGBmZmZh YYUBNiBghwAODg5OQoCDA6oYpI8NbgoL0FBmkOEgS7goAQABBgBmIgTfCmVuZHN0cmVhbQ1l bmRvYmoNNDIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAxNzAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDUxNCAw IFIgL0xlbmd0aCA1OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgBAIm IGAGAhZWKGADAXYw4ODghAMubAAhzQHRwQ7SDDOJlQVoLsh8kD3cFAAegAADAIvjBVoKZW5k c3RyZWFtDWVuZG9iag00MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDE3MSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgNTE1IDAgUiAvTGVuZ3RoIDU3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJYmAEAiYgYGZmZmGFAjYQYAcBDg5OKODCD2DKOMDa2EEGwExjARrNDLICZBUD+QAgwABO nwLnCmVuZHN0cmVhbQ1lbmRvYmoNNDQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAxNzQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDUxNiAwIFIgL0xlbmd0aCA2MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiWJgZAICZiBgYWFhZYMCdiDgAAFOLgjghgMeDICQ44Yo5uQE6wUZAjOQFWg6 yBKQZYxkA16AAAMApNsD1wplbmRzdHJlYW0NZW5kb2JqDTQ1IDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTc1IC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MTcgMCBSIC9MZW5ndGggNjAgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImczckCABAIBFApS/j/7zUlVwfvPEuiDMwsIqWGBt3o cDOslxs6FfW+DcVmwQFu2O7o2xZgALs2A/sKZW5kc3RyZWFtDWVuZG9iag00NiAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE3NyAvSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTE4IDAgUiAvTGVuZ3RoIDYxIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJnM3JEQAgCARBEFTU/PN1OQKw7Dfs EDFzAxHRngZMZ8vtdF7UbfxZbGCrZhUJQQlBpm9XgAEAlfcDdgplbmRzdHJlYW0NZW5kb2Jq DTQ3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTc5 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MTkgMCBSIC9M ZW5ndGggNjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImczckVACAIQ0FB ELf+6zWABfice/ILETNXEBFtycy6G9OtsN/lILbDb3Bn91lRQQtJpl9HgAEA5EgETAplbmRz dHJlYW0NZW5kb2JqDTQ4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMTgxIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSA1MjAgMCBSIC9MZW5ndGggNjYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SImczTcSACAIBEBBDJj+/1wPrJyxcusLgYiZI4hIyq5ABW2mm3GZL1fCS937alNYPNs54cfu 8Eqf1hZgAAKlBJIKZW5kc3RyZWFtDWVuZG9iag00OSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE4MiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgNTIxIDAgUiAvTGVuZ3RoIDY3IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJnM07AsAgCATRgEvwg/e/rqwWSZUir4bZS0RVSwLsPty9ptZp UDzmp9dh7E8mGms1qydvADiYu/LTEmAAF5wEsQplbmRzdHJlYW0NZW5kb2JqDTUwIDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTg0IC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MjIgMCBSIC9MZW5ndGggNzQg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImczUkSwCAIBEAWJSZx+f9vHbTU u32jgBkiYmYRUdUQJzN7IL3wuX/LS3F1GdPenfPx7THJA5E7CwLKUClopjutCzAA+OQESwpl bmRzdHJlYW0NZW5kb2JqDTUxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMTg2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSA1MjMgMCBSIC9MZW5ndGggNzQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSImczTcCgDAMQ1FcgmkR978tcgoTE2+29RcRUVUzc/eyNhGx0X7Qma6pdgDub8A4qe9P W8ip3OR0bxTmGDW25Z9HgAEAWJMFMQplbmRzdHJlYW0NZW5kb2JqDTUyIDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTg3IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MjQgMCBSIC9MZW5ndGggNzIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImczUsCgCAIRVH5FJGG+9+tj7RpA88Y3i1E xMwioqrH+TKzC/yGCm15poj+L2Jdfo85kmOes1ifGQSRFdRpyxBgAG9RBWMKZW5kc3RyZWFt DWVuZG9iag01MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDE4OSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTI1 IDAgUiAvTGVuZ3RoIDc3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJnM05 AoAgDERRs2gACer9L+uwSEXlayF/NiJiZhFR1f1ozCxAhATnkBsvn2thPrr37+O2dhJ6dw2j 34cwiWHMM/3xvAIMAG3TBWYKZW5kc3RyZWFtDWVuZG9iag01NCAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE5MCAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTI2IDAgUiAvTGVuZ3RoIDc1IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJnM47AoAwCANQwSj4o3r/yxpKZwffTBImEVHVmYBl 7czM3bedDjrLlSJaub+Mm4ieGfmsykpWOxdqCgCX+YD88bwCDACpzQXjCmVuZHN0cmVhbQ1l bmRvYmoNNTUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAxOTEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDUyNyAw IFIgL0xlbmd0aCA4MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZzOSRKA MAgEQBEiBiMu/3+sAzHl3b5RwMBERDMws0hZkuoK1cw2aN0e/EjncMH9iXK0+qR7rL0RDWkI tYp0Vc1bRURwGx/QH48AAwDNngYeCmVuZHN0cmVhbQ1lbmRvYmoNNTYgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxOTIgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDUyOCAwIFIgL0xlbmd0aCA4MCAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZzOMQKAMAgDQAsoFmsV//9YA6xO3koILA2I iJlF1i2p7tDN7ICRzjCvdCd3f75hUpGKz1itlhGF6O3oV9U6JyK4jh/aD68AAwDrGwZeCmVu ZHN0cmVhbQ1lbmRvYmoNNTcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCAxOTQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDUyOSAwIFIgL0xlbmd0aCA4MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiZTOQRKAMAgDQAtUFEXR/v+vTendGfdMEpYCRMTMInVNqhvsYGbHdIJfw50inm8ReZcR 9xGfRag0NL9YUNXcqyKCfXxR/mtdgAEA4YYGUQplbmRzdHJlYW0NZW5kb2JqDTU4IDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTk1IC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MzAgMCBSIC9MZW5ndGggNzkg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUzskBgEAIA0AXMIqu4tF/rwZs QOcNSYZGIqKqZjYWYKKZ3H0pK/Ut7Sni+CKirvOtZ8KbxVBn9skOANV4sZsLuKP9dj8CDADC FwYVCmVuZHN0cmVhbQ1lbmRvYmoNNTkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAxOTYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDUzMSAwIFIgL0xlbmd0aCA4NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiZTOSw6AMAgE0AIVq7bi5/53dabGpFvfjpAZSAlERFXNLE/kPkMpZYG126A2 2CmOwUnXh8O4jWCAyVZZ8tahF/U3rrh7v5nN8AIeSf89AgwAziMF8AplbmRzdHJlYW0NZW5k b2JqDTYwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg MTk3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MzEgMCBS IC9MZW5ndGggODkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUzjsSgDAI BFA+MYkSjej97+oSZ7Sx8ZUM7EIUmFlEVNMUcs6llFrrDMtgZm2FLfT94e7HF8zfpR5Hcd0Q Y3cgklFwogdtozWp4gd8Qr9dAgwA6K0GKgplbmRzdHJlYW0NZW5kb2JqDTYxIDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTk4IC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MzIgMCBSIC9MZW5ndGggOTEgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUzssWgCAIBNAUEs0so/r/X22w02Pr XXJghsEZ7z0RMY/BiEiMMaU0QTYzlAVWqNtDdf8ct99E9d2sdmgBBUktMiMbFSeaRFptYGZ8 gV9cr0uAAQBRSgcrCmVuZHN0cmVhbQ1lbmRvYmoNNjIgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMDAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDUzMyAwIFIgL0xlbmd0aCA5MSAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiZTOSwKAIAgE0BRDySSjz/2P2mgu2/S2wDCTa7z3RBRCmBtm jjEmkQVys0JR1Q3qPpgdr/PLmJmN7VpxiwgtyOqhGekikvCLuT++0IAIZdxf9yPAAGrpB2kK ZW5kc3RyZWFtDWVuZG9iag02MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDIwMSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y U3BhY2UgNTM0IDAgUiAvTGVuZ3RoIDk0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJlM5LFoAgCAXQFAylsMw++99pQA2adocc3oMhuBgjACKm0RDlnAvzpGYjInVRq2rb o+/u+DjNd+Abvb+JZnFtqVon3qv9zFz0GpFfTogAoN+En65bgAEAvjgIEQplbmRzdHJlYW0N ZW5kb2JqDTY0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMjAyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MzUg MCBSIC9MZW5ndGggOTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUzkEW gCAIBNBUDNQozbLuf9LAXLTt73joDJPprLXOOQA/K0QiCjHGlNKimHndRM657K96qHNorV1f Mo9Nf1br+FUkQYMkkHuyNEhPIELE3u0B5BK5x/xzPwIMAOLuCF8KZW5kc3RyZWFtDWVuZG9i ag02NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIw MyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTM2IDAgUiAv TGVuZ3RoIDk0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJlM5BAoAgCATA FArTiMyi//80xGuX5rzsMgUXYwQAxHnpiFJKa865lLJ1zLyLyGHq6drV3U71+aY6Aj3a2jis 1mFVYpXs3bZhSzZIRL6OiAD2UPjpFWAAAl4IhwplbmRzdHJlYW0NZW5kb2JqDTY2IDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjA0IC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1MzcgMCBSIC9MZW5ndGggOTQg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUzlESgCAIBNAUQsxMLar73zSg /2Z638suU3jFGAEQcTZElFJi5pzzYkopa611U62bMXZ1GJHzi4inLD78tDer0bZVW71dV5gv XSTy+RsRAPSj8M8jwACtsAfnCmVuZHN0cmVhbQ1lbmRvYmoNNjcgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMDUgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDUzOCAwIFIgL0xlbmd0aCA5MiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZTOURaAIAgEwEQMMVOzrPvfNMAD9JpvdpfFTQDg vUcMqyKKMTJzSmlTOee9lFJrbYfpp7jUuL8Nu9RIn/EmTdK3S6/1yw7zI5tEth8Q5RsA988r wAACZgiPCmVuZHN0cmVhbQ1lbmRvYmoNNjggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCAyMDYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDUzOSAwIFIgL0xlbmd0aCAxMDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSImUzkESgCAIBdAUAjHTMq3uf9KgaVWr3pKBzx/cw3sPgIijIWLmIBJj nExKac45l1KW1dRNNdX7/naYz7TbdtOregesi2Zp4qzJ9kAfiUhgJiIrcCICgHZyv1wCDAAQ hwiuCmVuZHN0cmVhbQ1lbmRvYmoNNjkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAyMDYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDU0MCAwIFIgL0xlbmd0aCA5NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiZTOyxaAIAgEUJGCJFKz1///aVCbatfdcmaGEG4AEGNE7HpDRMxDSklkdKo6 5ZxLKXV2bTGr2fan4+t13TzgwXZ1VGuzzkn1mhAR22NmIv+g7xDtH4DwyynAABMCCIkKZW5k c3RyZWFtDWVuZG9iag03MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDIwNyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgNTQxIDAgUiAvTGVuZ3RoIDEwMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiZTOyRaAIAgFUIFS1LQ0G/7/S0Mbt90d58B7KHUBQESirq+0NsYws7XWCe/9EEKIMY5T lXLOsyjLa71tp2f+7JR6JLeppYySJ6kSXjucdDHv0qt1+4GIEAFA/XEIMAD6mgheCmVuZHN0 cmVhbQ1lbmRvYmoNNzEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAyMDggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDU0MiAwIFIgL0xlbmd0aCAxMDIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SImUzksWgCAIBdBCgyDCSvvtf6OpdZo06k7hPWjaBwA457zvCkQi6plFZChURzMLIUxzscQY U0rr9tqr4+sevHtrjqWcXmrPlBvNRlWtV0SYuSdCxPLE6X3+CKD94xJgAF4RCVAKZW5kc3Ry ZWFtDWVuZG9iag03MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDIwOSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug NTQzIDAgUiAvTGVuZ3RoIDEwNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iZTOQRKDMAgFUAVqaDDBmtiq9z9oIU7c+3YM8GEYOwBEJHpNLgTmd4xRZHYppZyzqi4ft5ZS aq3bt/u5vTsud9269+xmm7a/tqRF1YJPy/czImI3mTmE9gURIQLA+MBfgAEAjGUJqgplbmRz dHJlYW0NZW5kb2JqDTczIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMjEwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSA1NDQgMCBSIC9MZW5ndGggMTAzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJlM5LAoMwCATQSlIgRlATv73/QQt+Vq58W2CGT3MDgBBCjF+HSETMnFJqTc65E1HVfnCj KaXU6TKb5bA+nQNfuder3VrCdmT1qiLSWYMXWR/zToSI/sYvRvsJoHnhL8AAPTkJFgplbmRz dHJlYW0NZW5kb2JqDTc0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMjExIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSA1NDUgMCBSIC9MZW5ndGggMTA5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJjM7RFoMgCAbgAkqCnJblZnv/9xx62tZl3x0H+KHrfwAQkWgYK+eYJxFVnY33/hFCiHFZ q5TSZvavnPOzev2VUi5V69pUPhcO27aQd0tbYrRsO1EvzaoiwszOtT+ICBEA+vs+AgwArzQJ 8AplbmRzdHJlYW0NZW5kb2JqDTc1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMjExIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSA1NDYgMCBSIC9MZW5ndGggMTExIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJjM7dGoMgCAZg0RTGtLDZbN3/hQb9PJ3uPYMHPnDuBgDe+xAGE2NKCRGJXob5 nXMupYxmEqm1zp9La21R31PvfX1odbZtYtHJa2fWABGZjjzN1XRmtlNEhPjT6zHaI1sI+hWA +98uwAAUiwiiCmVuZHN0cmVhbQ1lbmRvYmoNNzYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMTIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDU0NyAwIFIgL0xlbmd0aCAxMTIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSImMztEagyAIBeClNA0SKynL9f7PGbp9u+mm/xY4nFf3Z4yxFqB/ V855PyAS0ahCCMwcY5xmtaSURNbtK+e8q6Mp5XNXSpvVLV3+na0iojlLDZw0mfnUL/UZESIO 3jvXmgCAtdqte+wSYAD3AgqJCmVuZHN0cmVhbQ1lbmRvYmoNNzcgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMTMgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDU0OCAwIFIgL0xlbmd0aCAxMTggL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMzkESwjAIBVAbUhMwDbWhTUz1/tcUxjhufTtm Ph8u049zAOD9fFUhxBgRkeimUkpLzsy83tVWShHZj49aa2vtYXo/h+fwnc/eLaDBpvmxKSLa tFnlypxzXlKya0SE+NL7Idgrs/cAzrnpb28BBgAIdAqxCmVuZHN0cmVhbQ1lbmRvYmoNNzgg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMTQgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDU0OSAwIFIgL0xlbmd0 aCAxMTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMzkESgyAMBdCa0IIg QSUKUr3/NQ2ycMaVb5nJz8+nuwEAolLfX6W1Mb21zrlBeO+JKIRxEnOMkXlZm5RSznkTpfwv +1Mbl1KXZFcSLbows9yqN6cxBKJDemqdtFrbG6P19YtSiAjQvXYKMAAsvQr4CmVuZHN0cmVh bQ1lbmRvYmoNNzkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCAyMTQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDU1 MCAwIFIgL0xlbmd0aCAxMTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImM zksWwjAIBdBAagLSxBKj9b//ZRaMHqfeGQd4EMIPACLGOO1MSjlnImLeGxGZS6m1Hsyiqq21 49D7yZzNenHX4fb1qd+91cdsuvc+lu+Wo7p46sPSS5lF/B4zEz3tg5T8mSlGRAAIf3ptAgwA nHgJ2QplbmRzdHJlYW0NZW5kb2JqDTgwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMjE1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSA1NTEgMCBSIC9MZW5ndGggMTE4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJjM7JFsIgDAVQGxAKxqQWBFun//9LX9qF57jyLjO+w/BFRM45748mhBjH lHLOJ2A+i6jqdIG5lFrrddda7/0Gywr3zePXVrX+umASC721ff2JS6XMdnZSFRFmtof4m9IY YwgW5uU9khENf3p/BBgALD0LIAplbmRzdHJlYW0NZW5kb2JqDTgxIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjE2IC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1NTIgMCBSIC9MZW5ndGggMTIxIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjM7ZEsIwCAVQG2IDkQZtqIm7//+VgtUZHz1v DJdlM/wIIQDEuB1NSohIRDnvDDNPpYjsD2auVVWX41trvfeTObuLua5uX5/aWx65W9ZGemvr gkW11jr7YhEpZWL2izlnogdiSv7NGCMA2H/Df54vAQYAXHoLfgplbmRzdHJlYW0NZW5kb2Jq DTgyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjE1 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1NTMgMCBSIC9M ZW5ndGggMTIxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjM7JFsMgCAVQ 0VSjpRIjrZoO//+ZgXTT01XuEh6DMT8ArLXOTRfhfQhzjCmlq0C85UxESyllrbUy3x+H1nrv Y4ztKV7irT7/jqq2NbZJXqZa+65g5lpXWVwWopwzIurJlGKMIQTv9Z3JOWsBwJyzCzAAV9kL SQplbmRzdHJlYW0NZW5kb2JqDTgzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMjE2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSA1NTQgMCBSIC9MZW5ndGggMTI0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJjM7ZEsIgDAVQSGQxUEsqobj2///SUHXGR89bJjeLMT+stQCIeFDOee9DCDEe FRGllHKeTmouhXk572oVkdba2nu/qKu6fdzfvuVoaUKDfdUJkVrrvmNh5lLmsXrKOaUH0bgZ Ywzh6b1z458NEQCsNf95CTAAyv8KQwplbmRzdHJlYW0NZW5kb2JqDTg0IDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjE3IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1NTUgMCBSIC9MZW5ndGggMTI2IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjM5JAsIgDAVQC1EGY7BBoKCo9z+lgS50 6VsmP8Nh+aWU0hrgeBLGWGud896fBeKFKIRwFStzjPE2pZRzLqVstdbW2l08pt6fX73vRelK SKJ1k5mcU0pzyytGZh673yEQESKOo94756w1xoyHAEBr+XD5y0eAAQBhYQt9CmVuZHN0cmVh bQ1lbmRvYmoNODUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCAyMTcgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDU1 NiAwIFIgL0xlbmd0aCAxMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImM zssSwiAMBVAIFcqjUIMCBUT9/5806MYZN55tbm7C2DfOAUCI5USkVGrV2hhjrXXObd6HsJ8J IsZ4ub6llHMp5ai1ttZ677dp3H+MMQcU6JSj9EFbOaf0qYkxIj5m+R6C95tzdNTSba1XpaSc Dy1CAHDO2T+eLwEGAHxhC74KZW5kc3RyZWFtDWVuZG9iag04NiAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIxOCAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTU3IDAgUiAvTGVuZ3RoIDEzMiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYzO2w7CIBAEUAvIgkARBArYevv/j3SKiYlvnrfN Tmb3MP1gjHMuxBGkJCKllNYnMMZY65ybvffnEGKMlyGlnEspS621tdZ7v8K6Dbevz7yt+xIZ JJFfSsk5pzR67mgMAeV+ds5ai3u4qrVW6kEk5f7RUwh8x9j0j9dbgAEARyMLfwplbmRzdHJl YW0NZW5kb2JqDTg3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggMjE5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1 NTggMCBSIC9MZW5ndGggMTI5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ jM7bAsIgCAbgppaGOV241HlYh/d/x6C7uuq7BH7gMH0RQkip1PFEtDbmDGCtvRDnZu9DWK4E EWNcbyylnHMpW621tdZ7H2Psd/b4xcWd2oOmaJYSWymUTumzaY0R8cnrlxC8n53js9YCgDFG a35JKSmlENM/Xm8BBgAJfgz9CmVuZHN0cmVhbQ1lbmRvYmoNODggMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMTggL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDU1OSAwIFIgL0xlbmd0aCAxMjcgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMjkkSAiEQBFlGGNZBkH1c/v9KC29GeDCvnVXV hHxBKWOM8+0ChJByV0prbYyx1jrnvD9CCNcYU0q3Rc6llFpra633PsaYc5538PjFOpww4MFG BslScv5UPdEZI+rD4b1zL2sxa7Cu1C6lEOuljXPGKKXkD94CDABrHQuYCmVuZHN0cmVhbQ1l bmRvYmoNODkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAyMTkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDU2MCAw IFIgL0xlbmd0aCAxMjMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMzksS AiEMBFAnQQgiGEbCAP7vf0mJOxdW+bad6s5u+QaAiMbslbXOEZH3hymEY4wppdPEzDmvZ1WK SK11a633PsZluk63HzS7z5sxRu+tta1WESnl07XmzPzQgZRijCEEHfae6OmctfrSyxhEAFj+ 8BZgAGJhC7EKZW5kc3RyZWFtDWVuZG9iag05MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIyMCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgNTYxIDAgUiAvTGVuZ3RoIDEzOCAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiWzO2RLCIAwFUAVkkUIxCJSlttr+/zca1KeO5yUzSSY3p/MBIZQy xi6IcyGElEqpK9J6MMba0Tl3A/De37sQYowpTTmXUmqtrc0PtHyt6Nlh/bUWnM6tNdwtJec8 pRRjCJ9jL+8BAAPcaK0xg9Y9WCkpNyE47z/tjFFKCTm+/c9bgAEAvvAMdgplbmRzdHJlYW0N ZW5kb2JqDTkxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMjIwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1NjIg MCBSIC9MZW5ndGggMTMyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJhM5H FsIwDARQF7BxJRa4G4dy/zuikA2s+Eu9kUaE/KKUMsb54YiEkPKklNbaGGOtdc55f0ZLCACX 6ybGlHLOpZRaW2u99zHGbTfn+m3OfYyBO+YwXSvu4XZKMX6uAUAICzY8vHfuaS0WG+xXSkop xPYU54wxSsl/r7cAAwCN1AwJCmVuZHN0cmVhbQ1lbmRvYmoNOTIgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjEgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDU2MyAwIFIgL0xlbmd0aCAxMzYgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlkztkSwiAMBVAFKhREKAiUTerS//9FA77V85SZ 3Enu6XyAEMKYkOkCKGVs5lyIK5DyppTWegHGGGvvg/Peh7DGmFLOuZRSa30MrW3dcxjj1n4b iLwgmXNKMcY1BO+dG9fe1hrz6S+0VkpJKeGzEILzmTFKe6mJEIyh5bH4v/0rwAD52Qz+CmVu ZHN0cmVhbQ1lbmRvYmoNOTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCAyMjAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDU2NCAwIFIgL0xlbmd0aCAxMzIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIlkztkagiAQBlABYwlBgmInLd//HR246rNzOfPPMk0XCGGMCZlvgFLGOOdC3IGUi1Ja r8aYh7XOPV+d9yHEGFNKOZdSa22tvYdtB59fvbCNHoS+kC0lZ5iE+RC8H/ucc9bCCbNqrdQi ZT8tBOcHY5T2p2ZCMEYIXR//dwowAMS4DHYKZW5kc3RyZWFtDWVuZG9iag05NCAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIyMSAvSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTY1IDAgUiAvTGVuZ3RoIDE0MiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWTOyRbCIAwFUAVkkEIpVKAMpeP/ /6Kgruxd5SQ5ebnd/wEAIUToUWFMCKGUMfasOO+EkLJXSg1aGzO+Guuc834KIcaUUs5zKWWp 1nXbtv3rOH7FXntrmy51a845pRhjCJP3zln7uTcao/VQM3opheg4b9GMUUoJwbh9dSIEIQDg 8vnFW4ABABZKDTgKZW5kc3RyZWFtDWVuZG9iag05NSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIyMiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgNTY2IDAgUiAvTGVuZ3RoIDEzOCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiWTORxYCIRAEUAVmkChIlgmY7n9Fu5875+9ooKtO5wNCKKWM TWCeOb8IIaVUSmmtjbHWXoFzzvsbCiHGlFLOuZRaW7v33hewbtu2ozEeP2PgEcYr3i/wrrVW aynwN6UYYwi48Om9cy8MsdaYt9YQraQUQnDOZ2w1MQYNCTlW//P5CjAAoBMMYAplbmRzdHJl YW0NZW5kb2JqDTk2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggMjIyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1 NjcgMCBSIC9MZW5ndGggMTQyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ ZM7LFsIgDATQAgqCSIugQHm1FfX//9DgylPvMsnJzDDsIYQwJuRwBJQyduJciDOQ8qLUOE5a 66sx1t7unXPehzDHmFLOpZRa6wLWbdseoD1/tAYTWKz9Yqn1VUrOOaUY5xC8d+770VprDITo aVRKSSkhWwjBOWOM0l6LEIwxQn/V994fAQYAVAwNvgplbmRzdHJlYW0NZW5kb2JqDTk3IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjIyIC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1NjggMCBSIC9MZW5ndGgg MTM5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJZM7bFoIgFATQAgyECCQw uUqC9f9/GPSo+/Gss2bmcj0BAECI0HBrMCZkpJSxe8P5QwgpJ6XUU2tj5le3WOuc896HEGNK a87vbiul1rp/DvZ2LKVs/SXnnFKKMQTvv85Zuyz/xNkYrVuJmqQUgnPeuhljlI6EYNxnDQhB CMB5+8FPgAEAp+8OfAplbmRzdHJlYW0NZW5kb2JqDTk4IDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjIyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSA1NjkgMCBSIC9MZW5ndGggMTQwIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJZM5JEsIgEAXQAJFBAiEgMwYc739EoXRl3qqrq+v3n6YD AACECM2nDmNCKKWMnTvOFyGkXJVSm9bGXAZrnfPehxBjSinnUsq122ttrd3uX4/hN/d1rXUf R6U8c04pxhBCz3DO2hH5MkbrrX9ZpRRi4Xw8Z4zSNyEYj1ozQhACcOz+5yPAAOEvDNgKZW5k c3RyZWFtDWVuZG9iag05OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDIyMyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgNTcwIDAgUiAvTGVuZ3RoIDE0NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiWzO2Q7CIBQEUAUsuyDQAmLB4u7/f6DQJxM9bze5mZnN9hcAEEKEdt2AMSaEUsoY45wL IaTcN0oprQ+dMdY6N06T9yHEeEzp1Mw551LOS1frZVXrei6llJzn/pVSijGG4P00jc5Za0yP vGqt1K213KUU4sF5K2eUEvLEeBj6rBdCEAIA/qz/9v4IMADBMgz/CmVuZHN0cmVhbQ1lbmRv YmoNMTAwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg MjIyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1NzEgMCBS IC9MZW5ndGggMTQxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJbM5JEsIg EAXQADJjUCAMwUBwuv8RBReWVfqW3V39/zT9AgBCiNChw5gQQiljjHMuhJBSKXXs5lnr03kw xlrnFu9DiDGlNedLt5VSa92Hdv1obQxufVPKNs5yXlOKMQTvF+esNeb9U2s930eMUlI+hOjh nDFKKSEYj15PhCAEAPxp/+0lwABrwAwECmVuZHN0cmVhbQ1lbmRvYmoNMTAxIDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjIzIC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1NzIgMCBSIC9MZW5ndGggMTUxIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJbM5JEsIgEAVQBQQhgAgaIAyBmDjc /4KCGzd5m67q6ur/D8cdAEAIETo1GBNyppQxNgwD51wIKS9KqavWxtzu3Witc877aQohxJhS yjnPpdRal0ezbs2z6XNb+2qptZS5neWUXjGGME3ee+esHcffT2OM1i1GSSmE4LyFD4xRSgnB uPd6IwQhAGCv/t/nK8AAQ1oN9wplbmRzdHJlYW0NZW5kb2JqDTEwMiAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIyMyAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTczIDAgUiAvTGVuZ3RoIDE1MSAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWzO0RKCIBAFUIEklEACFQIJhdLq/z+w9aHp xfO0s7Oz91bVAYQwxoScQF1TemasaZq2bTm/CCFlp5S6am1MP4BxtNa5m/chTFOM95RmsORc yuMJ1m3bXj8wr/uylJLzAncppRjjFIL33jlr7bj/HHpjtIYY1UkpBOcc0qEDY5TSeu/1JgRj hNBR/b/PV4ABAFYZDhkKZW5kc3RyZWFtDWVuZG9iag0xMDMgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjMgL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDU3NCAwIFIgL0xlbmd0aCAxNTMgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlsjtsWgiAQRUtQQkkkMECQCLxk//+BDS89uV9mzVmz 5uzL9YyqQghjXANNQ8iN0rZtu65j7N73nA9CiIeUSo1PQGtjrJ2c836eQ3jF+AZSSjkv67pu +75/gOM4yoBtg3TJOaVvOYwxhDDP3js3WWuM1uXpqJSUUCMGzvueMQbt4EApIaQpXjXGCKGq OvX/8xNgAJ3BDp8KZW5kc3RyZWFtDWVuZG9iag0xMDQgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDU3NSAwIFIgL0xlbmd0aCAxNTIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIlszsEWgiAQBdCAIIhAxQAFlKDQ6v8/MNi08q7mzJkz751O RwCAECF0rjAm5EIpY9eK85sQUnZ93w9KjeO90doYa6d5ds77EJZ1jTE+Usr5+apKKdu27e9m r1Mpn7bOOaVUD+O6LiF479w8T9Yao3V7+h1HpYaa00kpBOe8pjPGKCWEYNyKIQQhBOCw/99P gAEAK28NogplbmRzdHJlYW0NZW5kb2JqDTEwNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIyNCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgNTc2IDAgUiAvTGVuZ3RoIDE1NiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiWzP3RKCIBAF4AILhQhUTAgFggjs5/1fL5y69Lvc2Tlnd7ffBACE VXU4FgjVdYMxIaeC0jNjnLdd1/VCDMNlNY5SKnXVeprm2RhrrXPu5n0I9xjjI6Wc8/L8WXJO KZVxDCF4XxadtS9j5nmatL4qJeU4rqHvYRCiLz0t54xRSks7IQTjpq4RWg+rKgghANsP/H2+ AgwAzW4PPQplbmRzdHJlYW0NZW5kb2JqDTEwNiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIyMyAvSGVpZ2h0IDIgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgNTc3IDAgUiAvTGVuZ3RoIDE4MyAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiaTPXQ+CIBSA4RJKBL/FRBFREUWr///3wjW7aK7Vei/ZGec8h+Nu jgMAhKezzXUR8jAmxLcFQRhFcZykaZpRmueXtaJgrCwrzutaiKaRUrZt2/W9UoPWepwmY+Zl yxgzTaN9H5Tq+85OSnltGiHqmvOqLBkrivXTW55Tmtk9SRxHURgEdjshBGMPIdddD4MQAOA4 +4DPfcGjbzxueeLJazee3ngv3TL/wfN/5d0fAgwArZYeZAplbmRzdHJlYW0NZW5kb2JqDTEw NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIyNCAv SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTc4IDAgUiAvTGVu Z3RoIDE0OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiXTP3RYCERQF4EIx JGbIjEFD9N/7P1900VV9l2edtfc5q/VvAECI0GZbYUxIRylju4rzvRBS9sMwKKW0PjTGjOM0 WWtn55z3IRyrJcaUTlXOpZTz16WUnK91fkspxqVuhhC8926erb1P0zga00IfWiv1rD29lELs OW/1jFHaEYJxOwwhCCEAfz74eL0FGABszA6TCmVuZHN0cmVhbQ1lbmRvYmoNMTA4IDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjIzIC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1NzkgMCBSIC9MZW5ndGggMTQ4 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJdM/NFsMQEAXgkJZQIaFB0FL6 3/d/v9JFV+23nDPn3pmu+w0ACPt+s60QwngghNJdxdjIuRDTPM9SSqX2zbJobYy1dnXOeR/C oTrGmNKpyrmUcv66lJLztc5vKcV4rJsh3L33bl2tfRij9bK00KdSUr5qzyQE5yNjrZ5SQgaM EWqH9T2EEIA/H3y8BRgAAokNmAplbmRzdHJlYW0NZW5kb2JqDTEwOSAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIyNCAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTgwIDAgUiAvTGVuZ3RoIDE0OSAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiXTP2xaCIBAF0AIKhBAU4yKQmNi9//+94KU3 9+OsWefM7PYbAIAQocOxwJiQhlLGTgXnrRBSdn3fK6WG4VxpbYy1zrnRex9CjJdiSmmer8WS 87re/u7rmvNS5o95TmkqmzE+Q/B+HJ17WWuM1jX0PQxKfUpPJ6UQLee1njFKG0IwrochBCEE YOuF4vsTYABqTA6wCmVuZHN0cmVhbQ1lbmRvYmoNMTEwIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjIzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSA1ODEgMCBSIC9MZW5ndGggMTUyIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJdM9JEoMgEAVQgQSFoKgYQCZnyHD/+wUXWfqWXV3/dxfF BQAgROh2zzAuy4oQSh8ZY3XTcN52XdcLMQzPk5RKaT0aY61z3ocQpmmal2Vdt33fjxhTer3/ UkoxHnm+reuyzHkzhI/3zllrzKi1UlKeod9hEKLPPS3nTVMzltsppYRUZYnxeRhCEEIArl7I fgIMAEQ+DjoKZW5kc3RyZWFtDWVuZG9iag0xMTEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDU4MiAwIFIgL0xlbmd0aCAxNTUgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIl0z9sWgiAQBdAUCoQIrwGCQJCKXf7/98LVs/tx1qxzZk7FkbIE AMLzJUMI44oQSq8ZYzfO67pp27br+2G474SQUqlRa2OmyVrnnPf+EUKMz3mel3VNKW2vvy2l dV3yeI4xhpAXvXNva6fJGK1HpaQUYg/9DEPfd7mnqWvOGWO5nVJKSIUxQvthEAIAyvLwh+L7 E2AAonMPPAplbmRzdHJlYW0NZW5kb2JqDTExMiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIyMyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgNTgzIDAgUiAvTGVuZ3RoIDE1MyAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiXTPWxKDIAwF0ApUCqXggwLyUEQr2u5/f8UFeL4ymUxucquuAAAh Quhe1DXGD0IofRaMvTgXomnbtut7Kd8npbQ2ZrDWOe9DGKcpxjintCzrp9hy3vf9+J6OUuW8 le66LCnNZTBO0xiC985ZOxijtVLn0p+Ufd+VnEYIzhljJZ1SSgjGuK7PwxCCEAJw+UP1F2AA Wq8OiwplbmRzdHJlYW0NZW5kb2JqDTExMyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDIyMyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgNTg0IDAgUiAvTGVuZ3RoIDE1NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiXSPaxKDIBCDBZSiFKVqAXmU4oPa3v+AXQ7g9yczO5kkW1VXIIQxIaQG mobSG2Nt23Zdx/ldiL4fpJSPcZym+QkopbUxi7XOeR/CK8Y3kFJa123f9yPn/AHO8yyS8wHH fVvXlL7FGGMIwXvnrF2M0VqpEjpP0zhCjRz6XgjOObTDBsYopU3ZVROCMUbo8offX4ABAAVr DekKZW5kc3RyZWFtDWVuZG9iag0xMTQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAyMjQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDU4NSAwIFIgL0xlbmd0aCAxNTAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIl0z9EWgiAMBuACglACCVQIIRJKq/d/v+ZFl35XOzs727/DcRdCGGNCToBS xs6cN03Ttq0QFymV6rTWV2Os7Qcwjs55fwthmmJM6Z7zA8yl1Pp8gWVd1/cf1MvWrLWWMsNc zjmlFOMUQvDeOTduO4feWmPgjO6UklIIAdchA+eMUbrl+hCCMUJo94fvT4ABAHIvDvgKZW5k c3RyZWFtDWVuZG9iag0xMTUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCAyMjMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDU4NiAwIFIgL0xlbmd0aCAxNDcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIl0z9kSwiAMBVABQSgggpadQm1d/v8LBd97XjKTyeQmp9MhACCECJ07jAm5UMoYm6aJ cy6ElFel1E1rY+6PYbbWOed9CDHGlHLOpZSl1tra+uy2vXt1o+7baK2t1br0sZLzO6UYQ/De O2ftPP93GmO07jFKSiE+nPfwiTFKKSEYj7u+CEEIADj84SfAAJoMDQwKZW5kc3RyZWFtDWVu ZG9iag0xMTYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAyMjMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDU4NyAw IFIgL0xlbmd0aCAxNDEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl0z9kS wiAMBdACsiMoUJZiqbj//xcKzvjY85hkcpNp2gUAhBChQ4cxIYRSxhjnXAghpVLq2GltzOk8 WOuc93MIMaaU81LKpVtr3bbtOrR2+2ttFO69U+s6xkpZck4pxhBm752z9rfTGK0fI0YpKZ9C 9HDOGKUvQjAed70RghAAsPfC5yvAAChaDEoKZW5kc3RyZWFtDWVuZG9iag0xMTcgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjMgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDU4OCAwIFIgL0xlbmd0aCAxNDcg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl0z9kSwiAMBVAFatkFgbKIhdq6 /f8PCn3vechMZjK5yel8DAAIIULDpRkxxoRQShljnHMhhJTXRiml9a0zxlrnJu9DiDGle86P Zi6l1Lo8d+u6btvW6t4ttdZS5j6Vc04pxRiC95Nz1hrTV760VurdUj5SCvHlvIUzSgn5YTyO /awBIQgBAEcv/AUYAJ1HDUgKZW5kc3RyZWFtDWVuZG9iag0xMTggMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjMgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDU4OSAwIFIgL0xlbmd0aCAxMzggL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl0z0kSwiAQBVAFIoMEQkBAJgNxuv8JhbWVt+2u /7tP52MAAAgRmi4dxoRQShm7dpzPQki5KKVWrY25DdY65/09hBhTSjmXUh7dVmttbX/+2Vtr fbaNpVJeOacUYwjBe++ctSPybYzWa29ZpBRi5nyUM0bphxCMx1kTQhACcPTB9yfAAPRwDhcK ZW5kc3RyZWFtDWVuZG9iag0xMTkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCAyMjIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDU5MCAwIFIgL0xlbmd0aCAxMzggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIl0z9kSwiAMBdACCgURilDZ7UL1/z/R4KMzPa+5k5sMwzmEEMaEXK6AUsZGzoW4 ASnvSmk9GWMe1jo3PzsfQowxpZRzKbW+lmVZwbbve2vH+8/RWoPJ1iOQrLWWknNKnxhD8P63 cXbOWigxk9ZKSSmhWwjB+cgYpf0sQgjGCJ198BVgAMxmDZwKZW5kc3RyZWFtDWVuZG9iag0x MjAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjMg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDU5MSAwIFIgL0xl bmd0aCAxNDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl8zksSwiAQBFAF FAQRgqBA+CUh6v1P6MSVG33Lrqnp3u3/QQhjQg5HQCljJ86FOAMpL0ppPRhjrtY6d7tvvA8h xjGlnEuptbbWJjAvoPe+Pr6tkEA+bxdTa89aS8k5pTTGGIL3n4/OOWuhxAxaKSWlhG4hBOeM MUq3WYRgjBH6sf/1FmAAK20OmQplbmRzdHJlYW0NZW5kb2JqDTEyMSAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIyMiAvSGVpZ2h0IDIgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTkyIDAgUiAvTGVuZ3RoIDE5NSAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiXzP7RKCIBBA0YBEEAkDRPwoK63e/w3bjSmd ZvL+Q8Dl7HZbEUIpY2wPZRnnuRBSyqIolFJlqbU+QMaYqjpi1jrnva/rOoSmibHtuq6HhhN0 hsbxkhpHXMLXAfd7OBdjbJoQ4K73zjlr8YfXqjLmhkO0LstJKRhdSCmE4Jxn+Ko9Y5RSQjYV Wzq66PhHB7wJeTMMvqHumngOefekW/O+vlWnNa5NONDdUZdwi27+0eWAe+seqCP/dM+XAAMA l0wXXgplbmRzdHJlYW0NZW5kb2JqDTEyMiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDIyMiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgNTkzIDAgUiAvTGVuZ3RoIDEzMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiXyOSRYCIRBDFWihEKERlJluh/uf0YKNG59/l1dJJYfjXwihlDK2nBDO hQAAKc+IUhetjVmttVfnvL/dByHEmFLKOZdSa2ut975N9sfg+WXqfd7Q9EJvraVgEvMxhjD/ ee+dwwq7GqO1UmpUSwnwFoLzMWphjFJCyO/5HwEGAI4JDVAKZW5kc3RyZWFtDWVuZG9iag0x MjMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjIg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDU5NCAwIFIgL0xl bmd0aCAxMzUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl8ztkOAiEMBVAF RhgQ0CIwbDJu//+Ldoi+Gc9Tk970drf/ixBCKWPTAXEuxCylUkektTbG2tMZAYBzl8GHEGJc Usq5lFJrba1dh97Xj9t36H1sMHLHZCk5p5SWGEPwflx7OAfw3CqsNcZgJzYrpaScheB8e2pi jFJCfn//egswAFjbDPAKZW5kc3RyZWFtDWVuZG9iag0xMjQgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjEgL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDU5NSAwIFIgL0xlbmd0aCAxMzEgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl8jskWwiAUQwsolNGCMitO//+PTevGhce7zEteMk1/ IYRQytjhCDgXYpZSKaW1NsZYa507gcX7EM6XjRhTyjmXUmptrfXer+C2M8b9mzE+Mu4P+OCu FTmkU4px/xZC8H5Bw9M5a1/GoFijX0ohBOfbKMYopYT8HP9eBRgA5scMCAplbmRzdHJlYW0N ZW5kb2JqDTEyNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDIyMCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTk2 IDAgUiAvTGVuZ3RoIDEzNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiXyO yRICIQxEByIQGRgEgWFRXP7/Iw2W3izfJVXpTrqX5T+McQ4AB0IIKaVSiHgktF6NsXZzzp28 DyGcJzGmlHLeSym1ttZ67xfi+mGMcZvQ/K5IvZOLvLXS1Z5zSjG+nz1C8N5TgNusNWbVegYj KqWkFGJ2egJwzhn72f0lwACgkgteCmVuZHN0cmVhbQ1lbmRvYmoNMTI2IDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjIxIC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA1OTcgMCBSIC9MZW5ndGggMTI1IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJhM5JFgIhDARQJcggEhtaQhNwvP8hDa71 +bepl6rd/g+lAEDrw2SMtc45748ihFOMiHgWS0o5r5epFKJa69YaM/fexxhXcfth3u6SkSRz a22rlYhK+fxac05pmQWIMcYQgvR67517WGvMnPTUGkAp9W366y3AAOLYDB4KZW5kc3RyZWFt DWVuZG9iag0xMjcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCAyMjAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDU5 OCAwIFIgL0xlbmd0aCAxMjYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImE jkkSgyAABBPAgKwSCLua/P+TGT1bZR+nZns8byCEUMrY9AKcCzFLqZTSWhtjrLXOLd77dwgx xs9JyjmXUmqtrbXe+xhj3cB+waFvKxzwtYZIRTLnlM6mLzpDQL1fnLP2ZwxmNdalFEJwflya GKMUH6+u/wUYAA2yDG4KZW5kc3RyZWFtDWVuZG9iag0xMjggMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjAgL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDU5OSAwIFIgL0xlbmd0aCAxMjkgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImEjtsSwiAMRJugIBGhQgXKper//6SBN2ec8Txudje7 LH8AAEQhTmdGSqUuWhPRlTHmZq1z653x3oewPQYxppRy3ksptdbWWu/9eE5e30zt4HNnF3s5 sefM6Rhn0xaC9+9RvzpnrTFmvCXSWislpRyThEBEgJ/TPwIMAN7cC/0KZW5kc3RyZWFtDWVu ZG9iag0xMjkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAyMTkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDYwMCAw IFIgL0xlbmd0aCAxMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImEjkES wiAQBAMIrEAQAgQwavT/n3SS6M0q+7a1XTMzDP9gjHMuxAlIKZXSWhOdgTHGWufc6L2/hBBj nHZSyrmUMtdaW2u99ytYbh/uB99z2Z5wYMKfS8k5p7TnPJAYAsL96Jy1K/rQSkRaP5WSclv0 EgLrGPs1/C3AAC92CpcKZW5kc3RyZWFtDWVuZG9iag0xMzAgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMTggL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDYwMSAwIFIgL0xlbmd0aCAxMjYgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImEjssWwiAMRJtQoTwKbVCgoOj/f6XBLvUc7zY3MzNN /wBARCHmCyOlUovWxhhrrXNu9T6EbWeIKMbr7UNKOZdSjlpra+3OPJj+/KL3cRgCe2wf/JVz SmdMjJHoNcK3ELxfneNSy91aL0pJOQbNQiACwI/dbwEGAJ8pC5wKZW5kc3RyZWFtDWVuZG9i ag0xMzEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAy MTkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDYwMiAwIFIg L0xlbmd0aCAxMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImEzskWwiAM BVANWAYRSkMlFJT+/1ca6qIbz/Euk5fhcv0LAISQ8jYxpbTWxlhr78y5h/chhDnGuCCmlNbn kDMRlVK2Wmtr7cXeh973U+/fInc5xNG68QxRzvnYsqaEiLw6ziF4751z46i1xhitlRr/TFIK IQB+/f0RYADWKgwLCmVuZHN0cmVhbQ1lbmRvYmoNMTMyIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjE4IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSA2MDMgMCBSIC9MZW5ndGggMTI1IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJhM7ZEsIgDAVQhRiIFGqhJhTX//9KQ1vfnPG8ZXKzHI7/ GWMtAJwUIjrnvSc6qxDCEGNK40VNOZcyX1fMIlJrXVprN3VXj91z8y17SxMabItOiDDzumMu peQ89dVjSjEOIfSbROT9yznE/s8bwFprzI+vPwIMAH7rC3EKZW5kc3RyZWFtDWVuZG9iag0x MzMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMTcg L0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDYwNCAwIFIgL0xl bmd0aCAxNjcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMz9sSgiAUQNEC FIQQRDBAy///y86RnMFypvYbd9bl+jtCKKWMNS3EuRCdlEqpG6R1b4y1dnDOjd77EKb7Vowp pZzzvEAP6Imtn22zuIzbZtgPp2IsV4QQvB/hYjdYa4zRWuOTSkkphRCc43caxiglhPyhOIWR A0xIlBVYkSEMZeFLlpcDrcK9xzWrdk3oKjCLsH53AazbXS266KnrJcAAwm4YDwplbmRzdHJl YW0NZW5kb2JqDTEzNCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDIxNiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug NjA1IDAgUiAvTGVuZ3RoIDExMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iYzOzQKAEBAE4JCNUBH9v/9zNqtbXfqO7O5M0/wghJRSqZZpTdQZY63twTnnvQ9hGGGKMaU0 P3IupSywbrBXx1t95f9txSQWSs7P+olLMU58dggBGUjiQOQaQ0Rac5lLKTQT4lv5FmAAvlcJ wAplbmRzdHJlYW0NZW5kb2JqDTEzNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDIxNSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgNjA2IDAgUiAvTGVuZ3RoIDExNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiYzOyRbCMAgF0EIqg2liiWgd//83JUZXbrw7DvBgmv4AgIgpzbtAxMwioroP OeellFrrIaxm1lo7Du6ncA7bpbsOt69P/e5tfSym3X0s3yPHbO2pj0gvZcm531NVkSczEfVn 5pQQAeDn45cAAwCyvAm6CmVuZHN0cmVhbQ1lbmRvYmoNMTM2IDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjE2IC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2MDcgMCBSIC9MZW5ndGggMTE3IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjM5LFsMgCAXQFqhGKyaVVGt/+19moM6aSe6Qw+Nx Oh8BAIhEdDHOeT+FEGO8qpQSM+c8L+pWShFZ70OttbX2UL0/f17/xrh3W9JdTYzoKiJ6y24u c87Mb+2xOm0NYfLeOXvlQ4SIALuHv5sAAwAFjQqdCmVuZHN0cmVhbQ1lbmRvYmoNMTM3IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjE1IC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2MDggMCBSIC9MZW5ndGgg MTE3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjM5BEsIwCAVQhdQkiKE2 tNGo97+mMJm6cNW3Y+bz4XQ+BAARQ5guJsaUUs6Z6OqYb6WIyHw3S61Vdd2G1trDPE3vr917 +M29e8CDlh+Lq6pa0+KVs0gphZn9GBHZ5ZRijP7KFAIiAPy/+/kKMAAO9wq1CmVuZHN0cmVh bQ1lbmRvYmoNMTM4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggMjE0IC9IZWlnaHQgMiAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2 MDkgMCBSIC9MZW5ndGggMTUyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ jM/RFoIgDIDhEmJuIYhgFNn7v2YDvBCtc/xvgbHvcj1V13VCSClvnFIKoEckojuntR6MsdaO jpu89yHMj1qM8cm9Sim9j6VUzvItvrw+m0MIPGfKA0eebMzAv+TPiBCxB1Aqb7JIKYTg3c4h fquYtVQWAOCWZQrLHVmti2GpEVVSMf1BuR2KVlSj2m/7+QowAIFgFMgKZW5kc3RyZWFtDWVu ZG9iag0xMzkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAyMTMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDYxMCAw IFIgL0xlbmd0aCAxMDYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMzsES gzAIBFCBCpLGJBpbbf//Q7tx6sUZZ3xXYJeuu4eImUUePaiq2eAeQnhCjHFMKeVcpmaGWuvy 94J3s17Zp9g6LjZcI+Ozp5WckY2K1oRCdzcz1fZHLyLMRHT69fsTYABhMAkyCmVuZHN0cmVh bQ1lbmRvYmoNMTQwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggMjEyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2 MTEgMCBSIC9MZW5ndGggMTA3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ jM5LAoMwCARQSVIgQVBjaz/3P2iJn41ufFtgmK67BwBCCDGmh0MkImbOORcnIr2qmQ1jM7la 6/zcvdyyel9tg7ZyrM9+6wmfNWswU9VepP0p/o/5S4SIrUaK0TsBnKr+/gIMADEDCNQKZW5k c3RyZWFtDWVuZG9iag0xNDEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCAyMTEgL0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDYxMiAwIFIgL0xlbmd0aCAxNDQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSImMz+0WgiAMgGE3DIRws7DM7v9C21aS6ekc338cPsbTNAcDQETn2pPmfQhdjDGldJZy zj0RMw8X7SqVUsbb0l2blh5WXU62W8+OclPuz/bSwExEvbyvY2SazAwheG+/cM4hAsBRwp60 MilJTR+SmmhlmremN+qr+ucx0I+It6KuiloV4U70fAkwAMcdEcMKZW5kc3RyZWFtDWVuZG9i ag0xNDIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAy MTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDYxMyAwIFIg L0xlbmd0aCAxMDUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMztsSwiAM BFASDKENWHpV//9H3ehU27eeN2bI7oZwFREzxxhvTiSlpKo55w56MLNSSr27obU2wjT/Lbv1 6/c+/Jn8CLfDJ6Uiz2xDtnd06FJ9oFfEJzyxhZmIzjNfbwEGALFPB7IKZW5kc3RyZWFtDWVu ZG9iag0xNDMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAyMDkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDYxNCAw IFIgL0xlbmd0aCA5OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYzOSxaA IAwDQEq1FUTAv/c/qakrceVs+5rEub+IyHvP3PUgIqpDCCHGOEJKaco5l1LqbJYVNtiPt/Or ue72YI/Lk1GRhkxEJ6tAE/pUVcQW9B0z9hC1K69bgAEACgQIoAplbmRzdHJlYW0NZW5kb2Jq DTE0NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIw OCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjE1IDAgUiAv TGVuZ3RoIDEwMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYyOQRKAIAwD oRWoIogK6P9faurN4eIeO80mxvzGWkvEzJPinPM+iMxgATHGNaWUc96Ksh/gBLW2gd7HW6v6 fSK1v4KywQUjxOpf0CMiwXs064CLmYiw6bPxfgQYAL99B/IKZW5kc3RyZWFtDWVuZG9iag0x NDUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMDcg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDYxNiAwIFIgL0xl bmd0aCA5NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYyOMQKAIAwDKdUC loII+v+n2uLkpDcnuTj3GwDw3iMuq0EUQogxppQ2g5mziJRS6j5ph9KVMc5vhiW7VdpTr7ok knWWbV41KrvUSTT9iKhvAN4fbwEGALBGB78KZW5kc3RyZWFtDWVuZG9iag0xNDYgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMDYgL0hlaWdodCAy IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDYxNyAwIFIgL0xlbmd0aCAxMzAg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUz+0OhSAIgOGERMzs0+r+7/QA p7W2Vqv3N4JPVb3POQeAiLWXiCiEwMwxxkZLKbU5507qB22ctFkrZXmqFJvS8dGeDr1skWWt LE26XI5E5lUuEul1XyMCgPzow/8vHDCOPzjrE+fsuQftlL/lBtMYhg1DOwavmO0nwAAylg75 CmVuZHN0cmVhbQ1lbmRvYmoNMTQ3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMjA1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSA2MTggMCBSIC9MZW5ndGggOTggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSImUzkEWgCAIBFCRArWyNKv737TRXNSyv+OhMxjzAxFZa5mHsRJRVee9DyFM1QwL xBjX7ZFytXellOMNc9+0Zzn1XysSkHPWwJaMBvQ4VRFp3cyMS4g+5123AAMAdIgHUAplbmRz dHJlYW0NZW5kb2JqDTE0OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDIwNCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgNjE5IDAgUiAvTGVuZ3RoIDk1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJlM5BEoAgCAVQBQO1NDPr/kcNqJna9pYM/4Nzf3jvARAxTIqImWNKKec8q0WUWusq2nbr uxmvw3wGwzZ6fxJN49JStM56pV+uRGYisssBEQDkm+9z5yXAAGtcB0YKZW5kc3RyZWFtDWVu ZG9iag0xNDkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAyMDMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDYyMCAw IFIgL0xlbmd0aCA5NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZTOsQKA IAgEUEVFySSj+v9f7SqHhpbeChzn3B/eeyIKIcQEzJxzLiIT1MsMTVUX6Otgtj32L2NmNrZ7 xy0itCHrDq1IF5GCX8zX3xTRgAhl3t2OU4ABAFMGBw8KZW5kc3RyZWFtDWVuZG9iag0xNTAg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMDIgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDYyMSAwIFIgL0xlbmd0 aCA5MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZTO2xKAIAgE0EIMzSyj y/9/aoszWq+dRwZ2GcZfiMg5x+wnIyIhhBjjDMkskFfYoOyN6tGdzTtS7ZvFDnGfLalGJmSj 4kKTSK31zIwviL6f3Y8AAwBn+wdCCmVuZHN0cmVhbQ1lbmRvYmoNMTUxIDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjAxIC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2MjIgMCBSIC9MZW5ndGggODkgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUzkEWQDAMBFDSkBTVCu5/VZMssLDxl33N zHT9P0SUUmIeRiciqppznmAOC5QVKrTtZmb7F7w/n5of+XHxmMjzZBQc6EFbtDIzNmDJa9d5 CTAAS50HAQplbmRzdHJlYW0NZW5kb2JqDTE1MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIwMCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgNjIzIDAgUiAvTGVuZ3RoIDkwIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJlM5BDoAwCARApVQqtkrV/7/VhcTYq3MjhF2m+SeilBIz58WJSCll BVXdQoW2w+HM+ud018uHYdnN4gKXzTNqpCFWkX6jBV3RmZnxAhGNbz0CDAAyHgaxCmVuZHN0 cmVhbQ1lbmRvYmoNMTUzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMTk4IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSA2MjQgMCBSIC9MZW5ndGggNzkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SImUzjECgDAIA8ACFbRW0f9/1oTJUW+GJK39IyKqamZ9IXePiBU2GLTTPOCkzOuLzLrm22RA RQ2GIvtGB5qqsZthgIq8Vz0CDADIsAWlCmVuZHN0cmVhbQ1lbmRvYmoNMTU0IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTk3IC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2MjUgMCBSIC9MZW5ndGggODEgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUjkESgDAIAwsIRa2i//+sgV48OeOe k2xa+wkRMbOILIWqmll39xVsxZ6MA5xFxPVNxAxmZVR7DuUkljsM8JTvhhl+vHh9egQYAKzF BWQKZW5kc3RyZWFtDWVuZG9iag0xNTUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAxOTYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDYyNSAwIFIgL0xlbmd0aCA4NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiZSOMQKAIAwDoVgoihb//1nTsDi4eGvTXFL6S85ZREopG1HVWmszsw52cgRj nMFF3H1+g8uKMD34ulqir6O3oR8W2m54YceG16JHgAEAmBIFMQplbmRzdHJlYW0NZW5kb2Jq DTE1NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE5 NSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjI2IDAgUiAv TGVuZ3RoIDg1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJlM5LDoAwCARQ LQhFbf3d/64ONMS1b0doZ5jm30opRMTMSxARVa1mtrot7KF1d6TTXSmmXMXD3sa3EeFhCLWK dHRE141WdOOC75znFWAAyYsFxgplbmRzdHJlYW0NZW5kb2JqDTE1NyAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE5NCAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjI3IDAgUiAvTGVuZ3RoIDc3IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJlM5RDoAwCANQhwjqRN39L7sCS/Zn4vumLUv5 jYhWYOYtiIiq7gecUNMV7E7Plzwxy8jIe5VXolqxEEsvNrGMB+Y3rQswAK/LBX0KZW5kc3Ry ZWFtDWVuZG9iag0xNTggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAxOTIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDYyOCAwIFIgL0xlbmd0aCA3NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iZTOyxaAIAgEUIkoFV///7WNYKeNm+4WmCGE34joAGY+jYhccEOckstGtSx1452p+nZet5aD vDaDkW89HY3oRf33y3gEGAA7swQ/CmVuZHN0cmVhbQ1lbmRvYmoNMTU5IDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTkxIC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2MjkgMCBSIC9MZW5ndGggNzQgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUzkEOgCAMBVFKLYhWuf9tGbTGnYlvXf6Q 0n8ikqGqy8XMCuqKhi3swf344h53z7u50eZYZZXxu3LSo0r8/UkfAgwAPIYESQplbmRzdHJl YW0NZW5kb2JqDTE2MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDE5MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug NjMwIDAgUiAvTGVuZ3RoIDc4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ nM4xEoAwCERRRRIxGvT+p/WTESsrX8nALtP8g4gsUNVSwwoz2xr2cKT+cPfzA+Pc6HkyAiKp EWkkj4paaKOTann/uG4BBgCO2AU4CmVuZHN0cmVhbQ1lbmRvYmoNMTYxIDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTg5IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2MzEgMCBSIC9MZW5ndGggNzMgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImczlESgCAIBNBCDJXI+9/WRWewfnu/wC7H +QcRJWDmfE0iUqA2UHcH256P18Biex6rx1QPRO4qyOjySjTHF30IMAB2FAT0CmVuZHN0cmVh bQ1lbmRvYmoNMTYyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggMTg3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2 MzIgMCBSIC9MZW5ndGggNjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImc zksSABAMREER4hPuf10TqmJnodfxRgg/iCgCM6e8iUiB2kzf1I2ne6fnoSWq1RCVk09YskHs +h/mEmAAHogEBAplbmRzdHJlYW0NZW5kb2JqDTE2MyAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE4NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgNjMzIDAgUiAvTGVuZ3RoIDY5IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJnM5JDgAgCANAEdz1/9+1QmI08eScaYtzX4jIAzNLUBES5LJU 1U794TpoFtJ8XlVotO4g2MEaRml/MKYAAwAPHwPbCmVuZHN0cmVhbQ1lbmRvYmoNMTY0IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTg0IC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2MzQgMCBSIC9MZW5ndGgg NjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImczUkSACAIA0GN4P7/9xrE 8mzZZ8iE+AdAIhHR7ApVat0MN1+d+/3bbMbmfFgZEbaYxO0vAQYAOggETAplbmRzdHJlYW0N ZW5kb2JqDTE2NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDE4MiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjM1 IDAgUiAvTGVuZ3RoIDYzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJnM3B EgAQCEVRKRT+/3u9yNqMs653U/pDRBmYWcpRoTk118N4i8v9ZuoTvhWzggSjhCDd+FwCDADr wQN+CmVuZHN0cmVhbQ1lbmRvYmoNMTY2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMTgxIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSA2MzYgMCBSIC9MZW5ndGggNjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSImczTkCABAMBEBC3P7/XRshncbUezj/iYgCROCkMhRR29av8WSRrpW6+zJ0 Nhn78oM7u55LgAEAHLUECAplbmRzdHJlYW0NZW5kb2JqDTE2NyAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE3OSAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjM3IDAgUiAvTGVuZ3RoIDY0IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJnM3JEQAgCANAFQ88+q/XIIyDX/cLSUL4FCEBEeVi KjTBXQ1ves9Fn5lPVkqsL6OcZARbd3htAQYAzNQDIgplbmRzdHJlYW0NZW5kb2JqDTE2OCAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE3NyAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjM4IDAgUiAvTGVuZ3Ro IDU5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJnM07AgAQDARRv5Bw//va JZQKr052QvyVIEMBqVsjJbPuxts5s/WmHPCxKpxmAqWbnQIMAPa8A5QKZW5kc3RyZWFtDWVu ZG9iag0xNjkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAxNzUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDYzOSAw IFIgL0xlbmd0aCA1OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgIBsw MjIyAQEzELCwQgEbCLCDAQcHJxxwYQMIaQ6IDrBmmEksIHNB5gOtYYRZyQ0QYACsSwLBCmVu ZHN0cmVhbQ1lbmRvYmoNMTcwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMTc0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSA2NDAgMCBSIC9MZW5ndGggNTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIliYCQfMAEBMxCwAAErGxSwgwEHGHBycnIRApycELUcYH0wU9hYQYaCDAdZArOQGyDA ANV/AzMKZW5kc3RyZWFtDWVuZG9iag0xNzEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCAxNzEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDY0MSAwIFIgL0xlbmd0aCA1NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiWJgIB8wAgETEDCDAAsrDLCBATsUcHBw4gAcHBwwRRAtcBNYQAaCTGYC 2gC3DiDAAItdAk8KZW5kc3RyZWFtDWVuZG9iag0xNzIgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNzAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDY0MiAwIFIgL0xlbmd0aCA1OCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiWJgpAQwAQEzELAAASsrGwywQwAHHHBCARcXjIWQ44Aohmtm YwWZxgIyFmQ8zCpugAADALMFAsUKZW5kc3RyZWFtDWVuZG9iag0xNzMgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNjcgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDY0MyAwIFIgL0xlbmd0aCA0OSAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgoAQwAgETCDADAQsLKxywQQE7fgBVhdDH ygIyiRlsJshwqD0cAAEGAGuQAegKZW5kc3RyZWFtDWVuZG9iag0xNzQgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNjUgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDY0NCAwIFIgL0xlbmd0aCA0OCAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgoAgwAgETCDADAQsLKxJggwN2TICQRNbC AjKFGWweyGCYJRwAAQYAYQ4BwQplbmRzdHJlYW0NZW5kb2JqDTE3NSAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE2MyAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjQ1IDAgUiAvTGVuZ3RoIDQyIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmCkDDCBADMIsIAAKxsKYMcPUNSysoJNAJsF NhVmBUCAAQCHOQIsCmVuZHN0cmVhbQ1lbmRvYmoNMTc2IDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTYxIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSA2NDYgMCBSIC9MZW5ndGggNDUgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIliYKQQMAEBMxiwgAArKxsaYMcC0NWwsoI1s4DNAZnIBDOe AyDAAH3nAhAKZW5kc3RyZWFtDWVuZG9iag0xNzcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNTggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDY0NyAwIFIgL0xlbmd0aCA0MCAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiWJgpBAwgQAzGLCAASsrG0mAlZUVohFsBtg4mNnsAAEGAHDXAeIK ZW5kc3RyZWFtDWVuZG9iag0xNzggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCAxNTYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDY0OCAwIFIgL0xlbmd0aCA0MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiWJgoBQwggATGDCzgAErKysbcYCVFaKDBaIfbBTMXHYOgAADAEUoAWwKZW5kc3Ry ZWFtDWVuZG9iag0xNzkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCA3NSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug NjQ5IDAgUiAvTGVuZ3RoIDIwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ YmCgGDCCARMzQIABAABzAAwKZW5kc3RyZWFtDWVuZG9iag0xODAgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA3NiAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjUwIDAgUiAvTGVuZ3RoIDM0IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkggJmZmYW/ACoAqqWEQJYQYANBtgBAgwAJCAB CwplbmRzdHJlYW0NZW5kb2JqDTE4MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDcyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSA2NTEgMCBSIC9MZW5ndGggMTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIliYKAcMDIyMgEEGAAAUwAGCmVuZHN0cmVhbQ1lbmRvYmoNMTgyIDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNzMgL0hlaWdodCAxIC9C aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDY1MiAwIFIgL0xlbmd0aCAzNiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGRkggNmIGDBACBRZrgaRghgBQM2 GGAHCDAAHV8A7wplbmRzdHJlYW0NZW5kb2JqDTE4MyAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSA2NTMgMCBSIC9MZW5ndGggMTYgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIliYKQcMAEEGAAJcABGCmVuZHN0cmVhbQ1lbmRvYmoNMTg0IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNzAgL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDY1NCAwIFIgL0xlbmd0aCAz MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgBAMmVMAMBWjCjDDAAgas MMAGEGAAE4QArwplbmRzdHJlYW0NZW5kb2JqDTE4NSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSA2NTMgMCBSIC9MZW5ndGggMTYgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIliYKQQMAEEGAAIpABDCmVuZHN0cmVhbQ1lbmRvYmoNMTg2IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjYgL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDY1NSAwIFIgL0xlbmd0aCAy NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJggAFGfACuioEJAphhgAUg wAAGbgBLCmVuZHN0cmVhbQ1lbmRvYmoNMTg3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggNjMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDY1NiAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiWJgpAQwAQQYAAfhAEAKZW5kc3RyZWFtDWVuZG9iag0xODggMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2MyAvSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjU3IDAgUiAvTGVuZ3RoIDI2IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBgRAVMyABVigEKmOGABSDAAAmz AFoKZW5kc3RyZWFtDWVuZG9iag0xODkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA1OSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgNjU4IDAgUiAvTGVuZ3RoIDE2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJYmAgFzACBBgAADwAAgplbmRzdHJlYW0NZW5kb2JqDTE5MCAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDYwIC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2NTkgMCBSIC9MZW5ndGggMjMgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYAQBJkKAEQaYEYAFIMAADKkAdgplbmRz dHJlYW0NZW5kb2JqDTE5MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDU2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSA2NjAgMCBSIC9MZW5ndGggMTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIliYCQHMDEDBBgABkAAOwplbmRzdHJlYW0NZW5kb2JqDTE5MiAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDU1IC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2NjEgMCBSIC9MZW5ndGggMjQgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYIABRmyAAQkwIQAzQIABAAOzAC8KZW5kc3RyZWFt DWVuZG9iag0xOTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA1MSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjYy IDAgUiAvTGVuZ3RoIDE2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAk FTABBBgABS8ANAplbmRzdHJlYW0NZW5kb2JqDTE5NCAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSA2NjMgMCBSIC9MZW5ndGggMjAgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIliYCQCMCEDZhaAAAMABd4ARgplbmRzdHJlYW0NZW5kb2JqDTE5 NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ3IC9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2NjQgMCBSIC9MZW5n dGggMTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYCQBMDABBBgABGcA LwplbmRzdHJlYW0NZW5kb2JqDTE5NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDQ3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSA2NjUgMCBSIC9MZW5ndGggMjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIliYAQCJhyAER0wAwQYAAdGAEkKZW5kc3RyZWFtDWVuZG9iag0xOTcgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0MSAvSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjY2IDAgUiAvTGVuZ3RoIDE2IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAkDjABBBgAA14AKgplbmRzdHJl YW0NZW5kb2JqDTE5OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDQxIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2 NjcgMCBSIC9MZW5ndGggMjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIli YEQCTEyMuAAzQIABAAOWAC0KZW5kc3RyZWFtDWVuZG9iag0xOTkgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzNiAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjY4IDAgUiAvTGVuZ3RoIDE4IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkIgAYmQECDAAE7ABGCmVuZHN0cmVhbQ1lbmRv YmoNMjAwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg MzYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDY2OSAwIFIg L0xlbmd0aCAxOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZCIAmFkA AgwABPEASQplbmRzdHJlYW0NZW5kb2JqDTIwMSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI4IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSAxNzcwIDAgUiAvTGVuZ3RoIDI5IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJunvlyrUr1AFXr1y5fuXKgytXAQIMAJE3Ra0KZW5kc3RyZWFtDWVu ZG9iag0yMDIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAyOSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTc3MCAw IFIgL0xlbmd0aCAzMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibq+4/rV k1evXL5CHXDu6hWgabOvAwQYAFexR6gKZW5kc3RyZWFtDWVuZG9iag0yMDMgMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNyAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTc3MCAwIFIgL0xlbmd0aCAyNSAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiXpw5crNK8SC21eu3LtyBSDAAE4jKl8K ZW5kc3RyZWFtDWVuZG9iag0yMDQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCAxOCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y U3BhY2UgMTc3MCAwIFIgL0xlbmd0aCAzMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIibq24fq1ZdevnL16hRhw4eqVNdeubLoGEGAAvZEsIgplbmRzdHJlYW0NZW5kb2Jq DTIwNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE3 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNzcwIDAgUiAv TGVuZ3RoIDMxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ6jt2efaRSwdu XLtCBLh98vKDIxcAAgwAKR0pggplbmRzdHJlYW0NZW5kb2JqDTIwNiAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE3IC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNzcwIDAgUiAvTGVuZ3RoIDMxIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJWnP05q5jNw8duHaFCLDq6s3Zx24BBBgAMiIp XwplbmRzdHJlYW0NZW5kb2JqDTIwNyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDE3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxNzcwIDAgUiAvTGVuZ3RoIDMxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJenT71q2bN49ev3aFCHDn6rUHN68DBBgAUWsqfQplbmRzdHJlYW0NZW5kb2Jq DTIwOCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI4 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNzcwIDAgUiAv TGVuZ3RoIDMxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJaj9wfu3eKycv XL5CDXD96tW71y4ABBgAU9xE6QplbmRzdHJlYW0NZW5kb2JqDTIwOSAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI4IC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNzcwIDAgUiAvTGVuZ3RoIDMxIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJWrv/5tEr185evXqFGuDUpatnjt4CCDAAdURF LAplbmRzdHJlYW0NZW5kb2JqDTIxMCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDI4IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxNzcwIDAgUiAvTGVuZ3RoIDMxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJenTtzu1rN65dvXqFGuD41aunL14DCDAAmhNFpQplbmRzdHJlYW0NZW5kb2Jq DTIxMSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDM1 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2NzAgMCBSIC9M ZW5ndGggMTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGQiAJgBAgwA BKgARQplbmRzdHJlYW0NZW5kb2JqDTIxMiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDM1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSA2NzEgMCBSIC9MZW5ndGggMTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIliYGQiAJgBAgwABKgARQplbmRzdHJlYW0NZW5kb2JqDTIxMyAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDM1IC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2NzIgMCBSIC9MZW5ndGggMTcgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGQiAJgBAgwABKgARQplbmRzdHJl YW0NZW5kb2JqDTIxNCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDQxIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2 NzMgMCBSIC9MZW5ndGggMTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIli YCQOMAEEGAADXgAqCmVuZHN0cmVhbQ1lbmRvYmoNMjE1IDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDY3NCAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiWJgJA4wAQQYAANeACoKZW5kc3RyZWFtDWVuZG9iag0yMTYg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0MSAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjc1IDAgUiAvTGVuZ3Ro IDE2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAkDjABBBgAA14AKgpl bmRzdHJlYW0NZW5kb2JqDTIxNyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDQ2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSA2NzYgMCBSIC9MZW5ndGggMTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIliYGQiHjADBBgACBgAWwplbmRzdHJlYW0NZW5kb2JqDTIxOCAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ2IC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2NzcgMCBSIC9MZW5ndGggMTYgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYCQBMAEEGAAEOgAvCmVuZHN0cmVhbQ1lbmRv YmoNMjE5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg NDYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDY3OCAwIFIg L0xlbmd0aCAxNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZCIeMAME GAAIGABbCmVuZHN0cmVhbQ1lbmRvYmoNMjIwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggNTEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDY3OSAwIFIgL0xlbmd0aCAxNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiWJgZCIRMAMEGAAJ+ABlCmVuZHN0cmVhbQ1lbmRvYmoNMjIxIDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTEgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDY4MCAwIFIgL0xlbmd0aCAxNyAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZCIRMAMEGAAJ+ABlCmVuZHN0 cmVhbQ1lbmRvYmoNMjIyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggNTEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDY4MSAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iWJgJBUwAQQYAAUvADQKZW5kc3RyZWFtDWVuZG9iag0yMjMgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1NSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgNjgyIDAgUiAvTGVuZ3RoIDE2IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJYmAkBzABBBgABgUAOAplbmRzdHJlYW0NZW5kb2JqDTIy NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDU1IC9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2ODMgMCBSIC9MZW5n dGggMTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYCQHMAEEGAAGBQA4 CmVuZHN0cmVhbQ1lbmRvYmoNMjI1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNTUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDY4NCAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiWJgJAcwAQQYAAYFADgKZW5kc3RyZWFtDWVuZG9iag0yMjYgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1OSAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjg1IDAgUiAvTGVuZ3RoIDE1IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAkGwAEGAAG6gA7CmVuZHN0cmVhbQ1lbmRv YmoNMjI3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg NTkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDY4NiAwIFIg L0xlbmd0aCAxOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJghAImUgEz QIABAAvmAG4KZW5kc3RyZWFtDWVuZG9iag0yMjggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1OSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgNjg3IDAgUiAvTGVuZ3RoIDE1IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJYmAkGwAEGAAG6gA7CmVuZHN0cmVhbQ1lbmRvYmoNMjI5IDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjMgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDY4OCAwIFIgL0xlbmd0aCAxNyAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZKIAMAMEGAAPRAB9CmVuZHN0 cmVhbQ1lbmRvYmoNMjMwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggNjMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDY4OSAwIFIgL0xlbmd0aCAyMiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iWJgZGRkQgBm0gALQIABABNjAKsKZW5kc3RyZWFtDWVuZG9iag0yMzEgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2MyAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjkwIDAgUiAvTGVuZ3RoIDE2IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmCkBDABBBgAB+EAQAplbmRzdHJlYW0NZW5k b2JqDTIzMiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2OTEgMCBS IC9MZW5ndGggMTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYKQEMDEx MQMEGAAIrgBHCmVuZHN0cmVhbQ1lbmRvYmoNMjMzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDY5MiAwIFIgL0xlbmd0aCAyMSAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiWJgRAAmGGAmAbAABBgAEnwApgplbmRzdHJlYW0NZW5kb2JqDTIz NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDY2IC9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2OTMgMCBSIC9MZW5n dGggMTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYKQQMAEEGAAIpABD CmVuZHN0cmVhbQ1lbmRvYmoNMjM1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNjkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDY5NCAwIFIgL0xlbmd0aCAxOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiWJgpAAwQQAzQIABAAmUAE4KZW5kc3RyZWFtDWVuZG9iag0yMzYgMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2OSAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjk1IDAgUiAvTGVuZ3RoIDIzIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAEAyYEYIYCFuIBQIABABnwAOEKZW5k c3RyZWFtDWVuZG9iag0yMzcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCA2OSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgNjk2IDAgUiAvTGVuZ3RoIDE2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJYmCkHDABBBgACXAARgplbmRzdHJlYW0NZW5kb2JqDTIzOCAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDcyIC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2OTcgMCBSIC9MZW5ndGggMjAgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYKQAMIEBMwgABBgACpUAWAplbmRzdHJlYW0NZW5k b2JqDTIzOSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDcyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2OTggMCBS IC9MZW5ndGggMjYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYEQAJiYm ZhhgAQNWogFAgAEAH/4BFwplbmRzdHJlYW0NZW5kb2JqDTI0MCAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDcyIC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2OTkgMCBSIC9MZW5ndGggMTUgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYKQOAAgwAApEAEgKZW5kc3RyZWFtDWVuZG9iag0y NDEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA3NSAv SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzAwIDAgUiAvTGVu Z3RoIDIyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkIhswgwELFLAC BBgAFlUArQplbmRzdHJlYW0NZW5kb2JqDTI0MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDc1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSA3MDEgMCBSIC9MZW5ndGggMjYgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIliYMQATEzMUMACBqzEATaAAAMAHpkBEAplbmRzdHJlYW0NZW5kb2Jq DTI0MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDc1 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3MDIgMCBSIC9M ZW5ndGggMTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGSiFgAIMAAV rwCUCmVuZHN0cmVhbQ1lbmRvYmoNMjQ0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggNzcgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDcwMyAwIFIgL0xlbmd0aCAyNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiWJgJBswgQEzGLCwsAIBQIABAAzTAHUKZW5kc3RyZWFtDWVuZG9iag0yNDUg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA3OCAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzA0IDAgUiAvTGVuZ3Ro IDI5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkggNmZMDCwgoGbGDA ThTgAAgwADH3AZkKZW5kc3RyZWFtDWVuZG9iag0yNDYgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA3OCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgNzA1IDAgUiAvTGVuZ3RoIDE1IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJYmCkJgAIMAAMCQBOCmVuZHN0cmVhbQ1lbmRvYmoNMjQ3IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODAgL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDcwNiAwIFIgL0xlbmd0aCAy NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgJBswgQAzGLCwsEIAG0CA AQAOcwCICmVuZHN0cmVhbQ1lbmRvYmoNMjQ4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggODAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDcwNyAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiWJgxARMMMDMzAIGrCDARgxgBwgwACRdAUIKZW5kc3RyZWFtDWVuZG9i ag0yNDkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4 MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzA4IDAgUiAv TGVuZ3RoIDE2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmCkKmACCDAA DKkAUQplbmRzdHJlYW0NZW5kb2JqDTI1MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDgzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSA3MDkgMCBSIC9MZW5ndGggMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIliYCQbMIEAMwiwsLBCARsbGztAgAEAEEoAnQplbmRzdHJlYW0NZW5kb2Jq DTI1MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDgz IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3MTAgMCBSIC9M ZW5ndGggMjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYMQFmKCAmZkF BFhBgI0IwA4QYAAjiwE8CmVuZHN0cmVhbQ1lbmRvYmoNMjUyIDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODMgL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDcxMSAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgpDZgAggwAA2fAFQKZW5kc3RyZWFtDWVuZG9iag0y NTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4NSAv SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzEyIDAgUiAvTGVu Z3RoIDI4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAkFzCBADMIsLCw ggEbFLADBBgAEf0AsAplbmRzdHJlYW0NZW5kb2JqDTI1NCAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDg1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSA3MTMgMCBSIC9MZW5ndGggMjcgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIliYMQHmKCAmQUEWEGAjTBgBwgwACLkATcKZW5kc3RyZWFt DWVuZG9iag0yNTUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA4NSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzE0 IDAgUiAvTGVuZ3RoIDE2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmCk PmACCDAADkgAVgplbmRzdHJlYW0NZW5kb2JqDTI1NiAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDg3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSA3MTUgMCBSIC9MZW5ndGggMjYgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIliYCQbMAEBMwiwsIIBGxIACDAAE20AvAplbmRzdHJlYW0NZW5k b2JqDTI1NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDg3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3MTYgMCBS IC9MZW5ndGggMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYMQGmJAB MwSwsIIAGxCwEwYAAQYAKiIBbwplbmRzdHJlYW0NZW5kb2JqDTI1OCAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDg3IC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3MTcgMCBSIC9MZW5ndGggMTUgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYKQJAAgwAA70AFcKZW5kc3RyZWFtDWVuZG9i ag0yNTkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAy NjkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDcxOCAwIFIg L0xlbmd0aCA1MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgJBcwAQEz CLCwggEbArADAQc7HoCkFqKZBWwSyEiC9nJyke1kQgAgwACUkAKlCmVuZHN0cmVhbQ1lbmRv YmoNMjYwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg MjcyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3MTkgMCBS IC9MZW5ndGggNTMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYCQbMAEB MxCwsIIAGxywIwAHGHBCAISDJAvXATaAlQVkGMhQ8p1EMeACCDAAtF8C0gplbmRzdHJlYW0N ZW5kb2JqDTI2MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDI3MyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzIw IDAgUiAvTGVuZ3RoIDUyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAk FzABATMQsLCCABsMsMMABwcHJ3YAlIGrgusDm8ICMhBkMNmuohgABBgA2EYC/wplbmRzdHJl YW0NZW5kb2JqDTI2MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDI3NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug NzIxIDAgUiAvTGVuZ3RoIDU3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ YmAkGzABATMQsLACARsMsEMABwcnCuACAVQhDg6oWrhekEEsICNBRpPvMAoBN0CAAQD3XQMz CmVuZHN0cmVhbQ1lbmRvYmoNMjYzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMjc3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSA3MjIgMCBSIC9MZW5ndGggNTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIliYCQXMAEBMxCwsAIBGxSwQwAHBycMcGEDcFkODqgOqH6QWawsIGNBxpPtNgoB QIABABvNA18KZW5kc3RyZWFtDWVuZG9iag0yNjQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNzkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDcyMyAwIFIgL0xlbmd0aCA1NSAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiWJgJBcwAQEzELCAACsEsIEBOzsHBHDiB1BV7OwQbVAzwOaBDAZZ QLbrKANcAAEGAAFvAzwKZW5kc3RyZWFtDWVuZG9iag0yNjUgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyODEgL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDcyNCAwIFIgL0xlbmd0aCA2MyAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgJBswAQEzMzMLKxCwQQA7GHBwggEXDHCDAA8CgPlw WYhiDohWqDkgI1mAZoOsIN+BFAGAAAMAacoDzgplbmRzdHJlYW0NZW5kb2JqDTI2NiAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI4MyAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzI1IDAgUiAvTGVuZ3RoIDY0 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJpM5LAgAQCARQEiLuf119bG3y tjVTKYcBQBFYRTPd0FDTMfN6kdndsgSRxb1KS1Hr5Ur8xR/7CDAAk5cEEwplbmRzdHJlYW0N ZW5kb2JqDTI2NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDI4NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzI2 IDAgUiAvTGVuZ3RoIDYzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAk GzAxMTEDAQsQsEIAGwiwc4AAJxhwcXETAlxcEKVgXezsIBOgpoEM5gFaALSHfEdSAgACDAB2 xgPeCmVuZHN0cmVhbQ1lbmRvYmoNMjY4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMjg2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSA3MjcgMCBSIC9MZW5ndGggNjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSImkzlkWABAIBVAqROx/uxo24OT+v6HUNABARGqqu2F4quVkPxKJgEXZW6LQ qkk3dCl/88O5AgwA0s8EagplbmRzdHJlYW0NZW5kb2JqDTI2OSAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI4NyAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzI4IDAgUiAvTGVuZ3RoIDY3IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJpM47DgAgCANQBb+o97+uRQcT3fCtpC3OWXkgIg4Q lwS5QFUi7daP5yayUhrPWrQrtZyxgi3zox/GFGAAU4UDfQplbmRzdHJlYW0NZW5kb2JqDTI3 MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI4OSAv SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzI5IDAgUiAvTGVu Z3RoIDY2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJnM5BFgAQCEVRJCT2 v10/Rp1j1B3Xq5TDChBRZeZ2dRgC0+hy9p+bUbVFK8iw2MuiX3EH1+K/xh0BBgAWwgTACmVu ZHN0cmVhbQ1lbmRvYmoNMjcxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMjkxIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSA3MzAgMCBSIC9MZW5ndGggNjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSImczjkSACAIA0AVUbz//1uDNtRsyUBCiG4JiCgzc3kqSIMOYxrL2J8dLbM69FhDRON+ MBoymtDn/9btXAEGADpVBPwKZW5kc3RyZWFtDWVuZG9iag0yNzIgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyOTIgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDczMSAwIFIgL0xlbmd0aCA3MiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgJB8wMTExMzOzsLKysoEAOxBwcAIBFxBw88AB LxTwYQcwaYQGbpABIIM4QEaCzQbawQK0C2gjBe4lE/ADBBgAYV8FNQplbmRzdHJlYW0NZW5k b2JqDTI3MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDI5MyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzMyIDAg UiAvTGVuZ3RoIDc2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJpM5LDsAg CARQy8cqtvX+t3WwCbFb+5YEZkjHPiJiZlHV7E4oFcysXeGenlV3n8m7FDfNHKKKh850tAja 0Pnj401DgAEAfx0FUgplbmRzdHJlYW0NZW5kb2JqDTI3NCAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI5NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgNzMzIDAgUiAvTGVuZ3RoIDc4IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJpM5LAoAgCATQgkjJD97/tA2mi7b6loIzHOc6ImLmS0Ru FyCq6gMpD6Wrg5m1P7zM4bc6PyaPQVr02J6PHkEfWjduXvMKMACu2AWYCmVuZHN0cmVhbQ1l bmRvYmoNMjc1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMjk2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3MzQg MCBSIC9MZW5ndGggNzggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImkzsEC gCAIA9AECcOK+v+fbagdu9g7j40lzSMiZs4isgZVLRuYWd2HI5yd+/XFfWRa/j2uaIrCgua2 gKWMRez++HrK/QgwANzWBeMKZW5kc3RyZWFtDWVuZG9iag0yNzYgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyOTcgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDczNSAwIFIgL0xlbmd0aCA4MiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaTOURKAIAgE0AIJyUzr/odtMWfs294nA7ss6zwi YuYgIptT1WhmO6Sjy3A2pQ7X8JmWd9FPcj9PHobMiOzWga6ATjT/+HvG/QgwAAQ7Bh0KZW5k c3RyZWFtDWVuZG9iag0yNzcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCAyOTggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDczNiAwIFIgL0xlbmd0aCA4MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiaSOQRaAIAgFCyUEK637H7aPj3atbLbADMs6DxGllDIzb46IFFU1s7oHBzid1oPrm3fc xrafhaFCZ7AW2EcFtYwq2j8+n+B+BBgAK2UGVQplbmRzdHJlYW0NZW5kb2JqDTI3OCAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI5OSAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzM3IDAgUiAvTGVuZ3RoIDg0 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJpM5BEoAgCAXQAgnByuz+hw2w sb29JQP/s6zzAAARExFtjpmziKhq2bvDnK5eoQ338M1aX6px4advSrFEy82WHz3Wl6wX4Mfr Mx4BBgBTcAZ+CmVuZHN0cmVhbQ1lbmRvYmoNMjc5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzAwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSA3MzggMCBSIC9MZW5ndGggODQgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSImkzkEWgCAIBNACCcFI6/6HDcx2bXr+LTDDsk4AAMRERFtg5iwi qlr2h5kdobZwDteXd9g3axz5sY2c4pmenL2hN3ljQvT2mef/uwUYAHXzBrAKZW5kc3RyZWFt DWVuZG9iag0yODAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCAzMDEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDcz OSAwIFIgL0xlbmd0aCA4NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaTO OxKAMAgEUCVIIGr83P+wLmBj6eSVDOwyzQOIqJTCzIsTkaqqZtbWsMEO/XBnuNL99U5zJba7 H3pARjWkIruiI7rQiWb0j7z/2yPAAFAMBngKZW5kc3RyZWFtDWVuZG9iag0yODEgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMDMgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc0MCAwIFIgL0xlbmd0aCA4OSAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaTPyxaAIAgE0ALJV6Q9/v9bG3Db puPdCjO4rBOIiJmDyGZijCnnXEqpu1PVA1o3p7nc/W08+pxvNOwiQkdYRS7SE1qsTEQCunHB zAf+el4BBgDMUAc2CmVuZHN0cmVhbQ1lbmRvYmoNMjgyIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzA0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSA3NDEgMCBSIC9MZW5ndGggOTMgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSImkz0sOgCAMBFAtVChYAT/3v6pTjdGt4S2bdiYdxh5EzjnP zBOEEKKIpJTyfFHVBUqFBqvZXvvjM7MV2212VOwcKXdcRjLyI3qsDq0e7URdH/x0nAIMAPJc B24KZW5kc3RyZWFtDWVuZG9iag0yODMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAzMDUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDc0MiAwIFIgL0xlbmd0aCA5NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiaTPORaAIAwEUE1ANgMu8f5XdYI2lj5+CWQmTPMIImJ23vsFQggxpZRzLmsn IrXWtsEOhzkfqnp94eS96+9swAYbEpAjPbAgGw0RTVaIXseMHYb+8NMtwAAlfgekCmVuZHN0 cmVhbQ1lbmRvYmoNMjg0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMzA2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSA3NDMgMCBSIC9MZW5ndGggOTEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SImkj0sWgCAMxBSQjxWr9f53NaBLNz6ynpm00zyCc857H0JYGjHGlFLOuawNEdmg7qCqB5wP Ztc3Zm+CLBVt1coGU9I3C+s4MHUjZvxcMfTFP24BBgCtUwb0CmVuZHN0cmVhbQ1lbmRvYmoN Mjg1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzA3 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3NDQgMCBSIC9M ZW5ndGggOTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImkz1kOgCAMBFBt qSziAuL9r+oMcgHj+yKknUmn+RcRUXVmC3nvQwgxxrRSznmDHQ44oVC9Xg3uge82/mufKhjn GtcZg7SempCPFnSx0sycqor8O+OTR4ABAAkBB3kKZW5kc3RyZWFtDWVuZG9iag0yODYgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMDcgL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc0NSAwIFIgL0xlbmd0aCA5 OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaTPQRaAIAgEUEVTNDXL6P5H bXDdpuffCjNozAprLZHz3m8QQojMKaW8q1JKrbUd0Hs/4VLjViLPBxGZr2PopK5gUwMakpA3 czMamCPatBTdjgh3LP3jl1eAAQD1Jgc1CmVuZHN0cmVhbQ1lbmRvYmoNMjg3IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzA4IC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3NDYgMCBSIC9MZW5ndGggOTYgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImkj0ESgCAMA7UgUAQKAv7/qabePTjs Odm0274CERljrLUHcM75EAJzPJWUUs65iEgFrbVL6QPMeX8zNTF61zRaWoajwAXja47M2PHY 01ms4waipUd+8QgwAHtNCB4KZW5kc3RyZWFtDWVuZG9iag0yODggMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMDkgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc0NyAwIFIgL0xlbmd0aCA5NiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaTPWxaAIAgE0FIJKd9m7X+nDW2g0/F+wwws6xRj jLWOaFPM7L0X2Q8VQogxppxzKaVCg37CuD6MoWNdF1qtWC9ISUhD5pstImi6mbWWiJy1uGTu lR8eAQYAsFQIbwplbmRzdHJlYW0NZW5kb2JqDTI4OSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMxMCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgNzQ4IDAgUiAvTGVuZ3RoIDk4IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJpI/LFoAgCEQLzTB8kFn//6mNuapdx7vkMHdgmocgImOMtXYB zrmV2Xu/PYiEEGJKKeesqjsoB6jnm6vzmda2WloIWRjgifCJdDlamBmNrRj9uIJo7Jcf3AIM AHt4CB0KZW5kc3RyZWFtDWVuZG9iag0yOTAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCAzMTEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDc0OSAwIFIgL0xlbmd0aCAxMDIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSImkj0kSgCAMBBWIbLLK4v9f6uBFq7xYRV+T6UmWdQ7GGOeCaANSSqW1 McbuA+e89yHGmFLKOR+g1Fpbfzg/vIa9YbuMGNJwwBRgdO62W/RordA5qokE57hl8pvfXAIM AD3nCTcKZW5kc3RyZWFtDWVuZG9iag0yOTEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCAzMTIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDc1MCAwIFIgL0xlbmd0aCAxMDYgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSImkj8kOgCAMRLWABWxlEVz+/0ctGjmb+G5NOm/aYfwHACiljTGTgIjW Wuf83CBi5iWEEGNMKeWc11JK3Tr7y/HQ575RJVBWSUpeLOJamIno9nvnpO1EbNVygVYK4Oc7 n7kEGAAfhAkPCmVuZHN0cmVhbQ1lbmRvYmoNMjkyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzEyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSA3NTEgMCBSIC9MZW5ndGggMTA0IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJpM/LEoAgCAXQQFMpUcxe//+l0WvVphnPFrh36Lo2AIBorO2V c86HQDSMpxgjM6eUcs4iUkqZaq3z8lgv29c9eNdmvZn0tohojqbtzJp8NRBRCF5bz3JrDSIC NP7z1yHAAJj+CCYKZW5kc3RyZWFtDWVuZG9iag0yOTMgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMTMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDc1MiAwIFIgL0xlbmd0aCAxMDUgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSImkj0kSgDAIBDHBLGYhi9v/XyqoB49WpW8UTE8B0xgAoJRG nAVjrHPe+0UIIcQYU0o5ZyIqpdTWWl8fNmH/cHyHe/tedk5VThciNrGPreyWipO7nLPGSDki aqUABh/6yyXAAMkPCJAKZW5kc3RyZWFtDWVuZG9iag0yOTQgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMTQgL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDc1MyAwIFIgL0xlbmd0aCAxMDkgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImkz0sOgCAMBFAFEVCwFOv3/gd1UOPahLdrUzqlaSsp pbTujOnBWuuc834YixBijBNRSomZc86zyLI+tmK/HXB+UDztMvAOryIy431mxi4iwt4Q7ozB eyQit8Qb02mNe2q/9M8lwACHhgmgCmVuZHN0cmVhbQ1lbmRvYmoNMjk1IDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzE1IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3NTQgMCBSIC9MZW5ndGggMTEyIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJpM/BEsIwCARQTYo0KBSIVBv//z9Nqjcv zvRd2dkdTueDUko5TwCXAXEuheh6G5hFZFFVM3evtd4j1sfHs9uG1l6/WttvWw9982tE9Ibq bmaqiwgz7ytEVMqMiH0eAKacUzr603/eAgwAAtoKUgplbmRzdHJlYW0NZW5kb2JqDTI5NiAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMxNSAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzU1IDAgUiAvTGVuZ3Ro IDExMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaTPyQ6AIAwEUEFkEWSx Luj/f6hTTfRqwrsRykzpukZCCCl7pQbQWhtjrHUjeO9DmGKMKeWcSykz0bLeNthZPV4n+471 vufB58lCRMhAUkrInEJAPtc4a9GJZl5AqV5KbNT6qV8uAQYAD8UI0AplbmRzdHJlYW0NZW5k b2JqDTI5NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDMxNiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzU2IDAg UiAvTGVuZ3RoIDExMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaTPQRKA IAgF0FIjKRVMM6v73zOyXatmeksHP5+u/0sprbUxZhAAo7WI03xzznsfQiBi5hjjklJem1LK dqt7c7w8r3ttMzL7fMopLZLCTESSKtnOtT2IaO0IAFJAekgbpX5f9cF5CTAArBEJ7QplbmRz dHJlYW0NZW5kb2JqDTI5OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDMxNyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgNzU3IDAgUiAvTGVuZ3RoIDExNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiaTPSRaEIAwEUAURsBMZRNFW739NC4e1C/8uLyEVqvorIYSUjVItaK2NMdZ2PyBi5t45 730IMcYhpXE65ZxnWP7FetsuT3n2ljKG6evZmNKAPSFgo3M9MxGVoM5apCK7nKBUIyVu+vyv d/shwAAcGAqRCmVuZHN0cmVhbQ1lbmRvYmoNMjk5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzE4IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSA3NTggMCBSIC9MZW5ndGggMTEyIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJpM9JAoAgCAXQUiMpzTltuv81Q9u1adFbCsKn639jjHMuhBgI wCgl4jRXSmm9GGOsdc57H2JMa5NzLqVse3VU51t7bfWNOqn/+ZhiDDTJOWtp7qK1Um0TIko5 AtQIlITyMPb/sE/XLcAANL4KtAplbmRzdHJlYW0NZW5kb2JqDTMwMCAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMxNyAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzU5IDAgUiAvTGVuZ3RoIDExNyAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaTP0RqDIAgG0DSmlg4wNqzV+z/ncG3Xu+jc 8YH8OAyXOef9CHAzIYQYY0rTbHIupdwRiZi51kXk8fxQ1dbaupmX2U/Hz7furT6y2mxTPZ+K yFIrMxEhou3PuUdNKVmupdsNADB679z1j/31FmAAlZAJoAplbmRzdHJlYW0NZW5kb2JqDTMw MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMxOCAv SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzYwIDAgUiAvTGVu Z3RoIDExNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaTPOwKEIAwEUBdE JCvIb4P4uf81HShttvCVIRmS4fOaEELKUakJtJ6NIfoujbXOrd6HEGJMKeWcfx0zl1K2WusO R3M+9Spe0VQ3dBfmPnshBVkxItX71Tlr+19EZMysdVtCqVFKbPX+tH9uAQYAcq8LAgplbmRz dHJlYW0NZW5kb2JqDTMwMiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDMxOSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgNzYxIDAgUiAvTGVuZ3RoIDExMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiayPSRZAMBBEySQhc+gI97+nirX3LPjbrq5hGL/DGOdcCCGlVEpNWhszL8Ba55z3PoQY U0q5lHXrEFGtdQettQOcz/QTFF0IfSW6v9dSMtxiDAHeSLC2h83GaD0hHy3QBY0Y+2HbC5cA AwArhgqYCmVuZHN0cmVhbQ1lbmRvYmoNMzAzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggMzE5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSA3NjIgMCBSIC9MZW5ndGggMTIwIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJpM9LAoMgDARQgxQQ5CMWhKb3P2cHdd+FbwkZJkzTY0QkxCzlC5RS WhtjlsFa51bvQwgxprTlvL+HUkqt9YDWWu/9c2H+3pj5PsMtZsYoEsid+T3nLaUY8a73q3PW nm1o1Rr9Yw0pZyGInv/tn58AAwCLWgmRCmVuZHN0cmVhbQ1lbmRvYmoNMzA0IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzIwIC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3NjMgMCBSIC9MZW5ndGggMTIxIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrI9LAsIgDEQVihRavlEQSnv/Y3bS pQs3+pbJfJLb/XeEEFJOSj2A1rMx1i4rcM57H0KIMaWcM9HzxZRSaq1v0FrrvW/M2D8Y45pj DxWL4YHzSiAi5KUUI9LR4RzXLdYaM2vNZyg1SYm7/vDdV45TgAEAn1ILXQplbmRzdHJlYW0N ZW5kb2JqDTMwNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDMyMSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzY0 IDAgUiAvTGVuZ3RoIDEyNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiayP yRbCIAxFlVkohNIGCVbr/3+lwbp21bvLyfBuLtcTEEJKqZTSWhtjrLXO3QbehzDFmBIA5DyX sqwMItZa760RUe/9MdieB6+DX7V9ezxD1BjeQhwX1qWUOWeAlFKMUwjej7jdOc5mA/ZgG3YS 4oz3/vH+CDAAXCILAwplbmRzdHJlYW0NZW5kb2JqDTMwNiAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMyMCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgNzY1IDAgUiAvTGVuZ3RoIDEyMiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiazPSwLCIAwE0EIxRAmfKBSw6v2PadKdG1d9S5gMZFlO YIy1q3MXAQDeI15vIgQiijGmlHMphfn+ULW21rbe+xhzzqfYX+r96zjb9VpSY0h+k7lajw5m lsacU5J+ohCCPoiI3n8A9CPOrdYac8Z6/3wFGADjXgopCmVuZHN0cmVhbQ1lbmRvYmoNMzA3 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzIxIC9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3NjYgMCBSIC9MZW5n dGggMTI3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrM/bGoIgDADgGhKC gRykIZBW7/+QbXnflf/d9u14uZ4AAIQYpLwRpUatjZnuxFrnZu9DCDGmtOT8YIhYylprba33 /iTbTl4/78MRcHrjAqprjTrWUgoiD/nkvKQUI832fnbOWl44GaP1qBQfIuUgBMAZ//3zFWAA YLUMbQplbmRzdHJlYW0NZW5kb2JqDTMwOCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDMyMSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgNzY3IDAgUiAvTGVuZ3RoIDEyNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiazPOQLDIAwEQAMhEDCXLcyRw///ZVZlmlSeEglptSwXEEJIqZS6gdZ3 Y6x9MOe8X0OIMaWccynbDkRU69Fa632MMed8vuANn1/8xCW0THT2jj9HrUQ8Zd9KwcyUYgxh 9d45Xnhaa4zRWiMI8kiJZFcc+MdXgAEAAV4KVQplbmRzdHJlYW0NZW5kb2JqDTMwOSAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMyMiAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzY4IDAgUiAvTGVuZ3RoIDEz MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiayPyxbCIAxEFRCiPEtBHkXr /3+lg+e47K53l2SSmVyuZ8AY51yIG5BSKkV0fwCtjTHWWue8D2GJcZ2klHN+llJrba33vo0x XuA92f/8qtnGdIOqNehLKdhNaZ75xLiE4L1zcICP1tOSiJRCBiQRQiAVY6d8ePz6V4ABAKDm C1MKZW5kc3RyZWFtDWVuZG9iag0zMTAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAzMjMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDc2OSAwIFIgL0xlbmd0aCAxMzMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSImsz8kWwiAMBVCFIoUKZbKhDKXo//+jYenCXe8yyXlJbvdLEELpxNgDcT4L IeXyREppvRpjrXPe+xBeGwKAGPeUcs6l1FqP1tqJeu/vX1jp2MD+gXOl5JxS2mMEGDlbCAFT nbXWmFVrpcbKRUohZs7HKYxNlBJyzYv/fL4CDACy6g0DCmVuZHN0cmVhbQ1lbmRvYmoNMzEx IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzIyIC9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3NzAgMCBSIC9MZW5n dGggMTMzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrM9JEoMgEABAQYJg QBYxrAH0/4/MUMk1N/s0xaxM0x0QQhjPhDwApQtjnK9PIISUm1JaG2Pt7tzxAt6HEGKMKeWc S3nXWltrvffz6wK/8IRXyEFFATmnBH3Q7f0YdDi3W2uM1kptUgoxVq6cM7ZQOk4hZMYYoVu+ +NdHgAEAAEwL1QplbmRzdHJlYW0NZW5kb2JqDTMxMiAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMyMyAvSGVpZ2h0IDIgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgNzcxIDAgUiAvTGVuZ3RoIDE5NyAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIibTQ3RqCIAwG4MIACUREJuJPmtX932JD7KnO9TsDNgbv6bxL CCFZdqGUMcY5z/NciGuMVEoVRaF1WRpTWVtjnHMAjfdt24bQdV3f98MwjON4i5mmOWWa1jXu 4ynWYGUI2ON9A+BcvKm2tjKmLLXGGUpJKeNMIXA+5/gURinNMkL2+ePBWQlXwUQoxH0VTIRJ 0Fi7JEIA8JHwTzABzr9JipvhYzPETvgYLtbivUiIhs9omAhFJORfwkMNX28BBgCncBftCmVu ZHN0cmVhbQ1lbmRvYmoNMzEzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMzI0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSA3NzIgMCBSIC9MZW5ndGggMTM4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJrM9JFsIgDABQBaRQoQxFKJQC1uH+RzTo1mX/Ki8v4+l8DIQwxoRcAKUDY5yPVyCE lJNSWhtj7ezcrfM+hCXGlNZ1zXkrpdba2h3sj+758433nm4NKkrZcoaOlGJcQvC+j3o5N1tr jNZKTVIK0ZeOnDM2UAq3EELgLoQO+vKv90eAAQC6Gw0lCmVuZHN0cmVhbQ1lbmRvYmoNMzE0 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzIzIC9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3NzMgMCBSIC9MZW5n dGggMTMyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrM85FoMgEABQQYJg QBaRHWJy/0Nm6Cws/d3Mm3WanoEQxjMhL0Dpwhjn6xsIIeWmlNbGWLs7dwDvfQgxxpRyLqXU Wlvr/QPOL/hdQHhCvvfeGtRBdc4pQW8I3o9Zh3O7tcZordQmpRBj6co5Ywul4xhCZowReujL W38BBgAFIwvuCmVuZHN0cmVhbQ1lbmRvYmoNMzE1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzI0IC9IZWlnaHQgMiAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSA3NzQgMCBSIC9MZW5ndGggMTg1IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJvNDZEoIgFIDhQgkxEcFkExfSev9HjJM2OVOX1n/FAMPyHY47 hVCSpBifYoRklOb5GSoYY2VZcl5VQkhZX2JNo5TS2hhjrXOt913X9f0wDGMI4QpN0HMUZ0Jc 6fu4x/vWOWuN0VrPSjUNHFZLKYSoOI+3MFYUcOktzynNCIHHYJwmCUJ7ffOXoe+GxWK4EG4N ZzAEQufBcEs4vVsQxxUx7nQvxE9DDoYrIhjSfxneHwIMACSLGawKZW5kc3RyZWFtDWVuZG9i ag0zMTYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAz MjQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc3NSAwIFIg L0xlbmd0aCAxNDYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsj8kSwiAQ RBVCAgqyBEGWANn0///QSXn1mHfq6a6a6blcTwIhhHFHSN/3wzBQytjtDnAuxENKpbQ2ZrT2 eeCc968QYkwp56mUWlub53lZ13Xbtn3f3z9AwQzuAmlrtZYy5ZxSjCEE7507ln2sHY3RWikp H0JwfpxljFEKPaANIR3GCJ315x++AgwA/8YNjAplbmRzdHJlYW0NZW5kb2JqDTMxNyAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMyNCAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzc2IDAgUiAvTGVuZ3RoIDEz OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiayPSRaDIBBEFREMyCBB5snc /5BpV1lk619Wv1f1e5oeYp5nhJZlwRiv60oIpdsLYIzzXQgpldL6MOYNWHuep3Pe+xBiTCnl XEqttbXWex/j+jEGJJDDtZScU/rEGEPwzjnosPauM+bQWikphdg5Z+ye3SglBDzABpwQArun Hv3nK8AAfJkLNQplbmRzdHJlYW0NZW5kb2JqDTMxOCAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMyNSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgNzc3IDAgUiAvTGVuZ3RoIDE0OCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiazPyxKDIAwF0FYoYEEe2oKAICJq//8Li1127dlkJjNJbm73 qzRNAwCEjwohhDEh7bOilLGOcyGkVKofXu9Ka2NGa53zfpqmEEKMc0ppyXld11K2077/ylZK 7eW8pDTPMcYQ6oT3zlk7GqP1uW4YeqWkFILzjjFKz7MtIRgfCNU0EEIAarrLPv33+QowANVg DXsKZW5kc3RyZWFtDWVuZG9iag0zMTkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAzMjUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDc3OCAwIFIgL0xlbmd0aCAxNDcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSImsz0kSgyAQBVCBEDAgQzQig4BCTO5/wuA2a9+qq37V7+6uuwoAAEKEbg3G d0Io7R8NY5wPQkiplNbPcXo182zMYq1z3oewxphSztu27fteSq3v5vicjnOstZSWtDznlGJc Q/DeOWsXY+b5rJvGUWulpBRi4Jyxc21PKSF3jNs1CCEIIQCXffrv+xNgAHCUDMkKZW5kc3Ry ZWFtDWVuZG9iag0zMjAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAzMjUgL0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDc3OSAwIFIgL0xlbmd0aCAxODMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIm00NkSgiAUgOFCc0tEMBREBFna3v8Bw5xmminv9L87N5zDdzhuFgBRFMXxKZQkaZbleXEO lSWEVVUhVNcYE9JcQpS2bccY530vxCDlOCql9WSMtc5576+3T2HwzllrzKS1UuMo5SBE33PO WNe2lM7PNYRgjGuEwh4Iy3JeW+R5lqVJMp8Tx+EyALb76n6tIcIFsQ6GfxHlG1F/I85899Ci uIbIfhDRGuJjT8TnS4ABAKRPGwMKZW5kc3RyZWFtDWVuZG9iag0zMjEgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMjUgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc4MCAwIFIgL0xlbmd0aCAxNDQgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsz8sSgyAMBdAWKELlIZY3Ciq2//+Jhemq e88uM8lNcrtfBwAIIUKPBuOBEEqf3cgY45wLKadpUmp+NVobY611zvsQYowpLeu65pxL2fZ9 P2o9f2o9Wr2VUnJuHUtKKcYQgneuzRujdY+blWrZUgjBOWPj2Ne+KSVkwLifg9AHQgAu/PXP V4ABAD2EDKAKZW5kc3RyZWFtDWVuZG9iag0zMjIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMjUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDc4MSAwIFIgL0xlbmd0aCAxNDYgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSImsj8sWgyAMRAWKWF5SQAQEFNv+/y82Lrv3ribnzEySYbgPhDDG hDwASkfGpul5wYUQUiql9TzPxrwAa61z3i9LCOu6xphSztu2lVJra/u+H8fR+3mevYOCubVa SwFHzinFCJkQFu+9c85efW9joFtrpaQUgnMOaz/TxNhI6XUOIV+MEbrx1z9+AgwARrQLIgpl bmRzdHJlYW0NZW5kb2JqDTMyMyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDMyNiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y U3BhY2UgNzgyIDAgUiAvTGVuZ3RoIDE0NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiazPewLCEAAG8GLaCDNhxB4metz/gPFfB+h3gO9xOv8RABB2CF2qvh8wJuTaUMYY 5+MoxDRNUt4qpZTWxsyztc7dvQ9hWdZ12/cYjyOlR86lPJtSck4pHUeM+76t67KE4L1zztrZ GKO1Vi3vJWXNFmIcOWeMUlpr34RgPPR9m4NQByEA/zz74/MVYACzsQ1xCmVuZHN0cmVhbQ1l bmRvYmoNMzI0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMzI1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3ODMg MCBSIC9MZW5ndGggMTQ2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrM/b AYIgAAVQQUJJQSJ5pSCgUO2/YPjXAJ4B7qNpLgQAhC1Ctwrjru8JuZ+GcRwpZWyaOH8I8azm eZZSKa2Nsfa1LOvqnPdbCDGmtO9HzqW8T6XkfOx7SjGGsHnv3Loui7XWGK2VklLOZ95HCM75 NDFGaW0bhlr7JaTvO4zPOQi1EAJw5dk/PwEGABXXDGEKZW5kc3RyZWFtDWVuZG9iag0zMjUg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMjYgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc4NCAwIFIgL0xlbmd0 aCAxNDUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsz+kBgiAABeBSCSEQ JUCIQ46g2n/B9FcL+A3wjsv1TF3X9wMAtx2EI0IY3w+EUjpNjM3zsiycP3ZCCCmVWletjXla 65z3IWwxppRzKa9aW3sfWqu1lJJzSjFuIXjvnLXGGK1XpZSUUhx5H8737HlmbJooJYTstV+M ERohPOYAMPR915369u8nwACnhg1ICmVuZHN0cmVhbQ1lbmRvYmoNMzI2IDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzI2IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3ODUgMCBSIC9MZW5ndGggMTQ4IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrM9JAoMgDAVQgSKUSSqIgAwVO9z/hsVN T+BbZZH8JMNwJQAghAjdOoxHQii9nxjnXAgplZqmSetHN8+zMdYui3PrunofQozbtqWUcym1 Pvd9b+04jtZ6VWstJeeUekeMIXjfZ5xbrLXGmPnMe2nds5WSUgjOGWN97ZtSQkaMz3MQ+kAI wKXf/n1/AgwARjYLWgplbmRzdHJlYW0NZW5kb2JqDTMyNyAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMyNSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgNzg2IDAgUiAvTGVuZ3RoIDE0MyAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiazPWRKDIBAEUIEgREAxLAKyZrn/FQOVqpzA9ztT3TPT dCUAIIQI3TqMZ0IovQ8LY4xzLtZ12zYp90enlNbGWGuPwznvfQhnjDGllHMptbbWnj+tvWqt Jec+6xvnGYL3zrnDWmOM1kqNuF3Knr0KIThnbFlG7ZtSQmaMxzkIfSAE4NJv/74CDABTOQtT CmVuZHN0cmVhbQ1lbmRvYmoNMzI4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMzI2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSA3ODcgMCBSIC9MZW5ndGggMTQ5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJrM9bFoIgFAXQAlIwAcUglJc8ymr+AwzWagjtn/N37j2n818BACFE6FJ1XY8x IcO1GimljDE+TfM8C7HcKimVumu9rttmjLXWOe9D2GNMKedSHs/qOI4WpZScU4pxD8F756x9 GbNt66q1VkrKVrcIUbsnzjljlI5jOzsQgnHfde0dhN4QAvDfuT+frwADAKt0DYwKZW5kc3Ry ZWFtDWVuZG9iag0zMjkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAzMjUgL0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDc4OCAwIFIgL0xlbmd0aCAxODMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIm00MsWgiAQgGGRCA0UNFFBEPGS9f4vGHRq0/HURv/dbJjhi6JdAyCOYwhPPoTOGCdJevER QmmWZTljjPOiKK++qhKibpq2lVKpTmtj+t7awblxnKZ5npfbp8VP0zSOzg3W9r0xWndKSdm2 TVMLUVXhubIoOOcsz/0eSgkJa9MkwfiMUDgHQn8ZAPt+95hAUNxGXD1iHhDvvxCt+1YMhG9D Z/8gshfiuoEID0R8PAUYACKCGIMKZW5kc3RyZWFtDWVuZG9iag0zMzAgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMjUgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc4OSAwIFIgL0xlbmd0aCAxNDYgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsz1sSgyAMBdBWKGChPLQFeRRFxHb/K2zs Gjw/mclkkpvL9Vxd1yGE8Q0QQihlrL8DzoV4SKmU1sYM4/MFrHVu8j6EGFN65zzP81JKWWvd tq21HXzAUffWoFfrWsqywFzOKaUYQ/B+cs7aY904DsZorZSUDyE4P872jFH6JQTSYIwRgnQn //v3E2AArk4NiAplbmRzdHJlYW0NZW5kb2JqDTMzMSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMyNSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgNzkwIDAgUiAvTGVuZ3RoIDEzOSAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiayPWxKDIBAEBRQSkIcEQd4kuf8ds3zlAvbnbNVM77LcC0II Y0LIuq7btlHK2OMJcC7ELqVSWhtzWPsCnDvP0/sQwnXFmFLKuZRaa2ut9z7G+88YkEAO11Jy TukTY7xC8N5Dh3OzztrDGK2VknIXgvM5yxijFDzABpwwBrub/518fwIMADiVC1YKZW5kc3Ry ZWFtDWVuZG9iag0zMzIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAzMjUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDc5MSAwIFIgL0xlbmd0aCAxNDUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SImsj1kWgyAMRVsRhRZkkEIZZHBo97/DxtMteL9e8pF3c7tfTNd1CPUYD8MwjiMhlD6eAGOc T0JIqZTWszGvE2ude3sfQowpLTmXUmtrbd22bd/34zg+fyDBDNu1tVprKTkvKcUYgvfeOWvP Y19jZq2VklKIiXPGzlpKKSHgATYY9wiB3dUPAz8BBgCq0w2NCmVuZHN0cmVhbQ1lbmRvYmoN MzMzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzI1 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3OTIgMCBSIC9M ZW5ndGggMTM2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrI9bFsIgDEQV igjyrlDeLdX9r9Hw5QZ6/5LMmZnc7heDEMJ4IeQBUPpkjPMXIISUUimtjbHWOre+Ae9D2GJM KedSSq21td73fT/GGOd5fv7ABLsDbr23BkrQ55xSjFsI3k+z1TlwNkZrpSBLiBnLOWOM0lmG kAVjhK7+F/j+BBgALuAM6gplbmRzdHJlYW0NZW5kb2JqDTMzNCAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMyNCAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzkzIDAgUiAvTGVuZ3RoIDEzNyAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiayPWxaDIAxEASlCAaFa5CHgo93/Gpt0Dd6vnEwy kxByN5QyNnD+AIQYpVTqiWhjjLV2cs55/5qXNxDCuq4xppRyLmWrtbXW+77vx3meF/JB/hV0 DlB6h5lat1Jyhr0YwSEENFvm2XvvpglSjNEaQ79KSTkKgcdwPjBG6e3/EvITYAB2JgvACmVu ZHN0cmVhbQ1lbmRvYmoNMzM1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMzI0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSA3OTQgMCBSIC9MZW5ndGggMTM1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJrM9JEoMgEAVQQIJgQAYRwiBokvufMc0qF/DtuutXDwjdDWNCJkofgLGZcyGWJ5BS qVVrY6x1bvN+ByGEGF8p5VxKrfU4jtZ6P8H1Bp+/UV7Q7723BjlIl5JzSinGGMas3fvNOWuN 0XpVSsqxdBGC85mxcQylEyEY3/4v+v4EGADBIwxQCmVuZHN0cmVhbQ1lbmRvYmoNMzM2IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzI0IC9IZWln aHQgMiAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3OTUgMCBSIC9MZW5ndGgg MTg4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtNDbEoIgFEDRQkIwSEUS uYhk2f9/YpzMyaZX3U8Mw8BhHY6bh1CWZRifUoTklDJWnFOcC3Epy6qqaykbpa5Q22rdGWOt dc77PoRhGGK8pcY79Jh7r8e0G2NMJ0LovXfOWWtMp3XbwlWTUo2UdV1VZXkRgnN4tGCM0pyQ NAvGOM2F0PYf3iEEiIsh+TEUi6FUaloMtQFEMPRhhfhRXALBNaGfCY1eGco/QwaG5GuIdjB8 vgQYANcbGgwKZW5kc3RyZWFtDWVuZG9iag0zMzcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMjMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDc5NiAwIFIgL0xlbmd0aCAxMzIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSImsj1kCwyAIRKNxi2uMxqVq7f1PWWyvkPcHA8ywbY+DEMJ4J4RS yhjjnAtxLKRSSmttjLXOnd5fQAghxjulnHMptb5aa733McZ7Mefnz5y/GvqgwkyttRTYSemO MYR16fL+dM5aY8BDKSnl8hQC/BmDKJQQgjFke/zfrwADAKFUCokKZW5kc3RyZWFtDWVuZG9i ag0zMzggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAz MjQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc5NyAwIFIg L0xlbmd0aCAxMzUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsj2sSwiAM hBWKFITyKJVnC0Xvf0bDjN6g369MsptNbvfrQQhhPBHyACidGeP8ORBCykUprY2xdnVuewHe hxBijCnlXErZj+OotbbWzh+9938JXZiBYgdlzimBD9zej0Wbc6u1xmit1CKlECPyzTljM6Xj FEImjBG6/N3PV4ABAP4bDN0KZW5kc3RyZWFtDWVuZG9iag0zMzkgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMjMgL0hlaWdodCAyIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc5OCAwIFIgL0xlbmd0aCAxODIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm00NESgiAQBdACCcVA0FUQUTP7/29syZjGaXrL +wYLu3BO5wNCCKUZYxcM53lRCFFeMVIqVWltTF03TQPQdhhrrXO998MwhDCO4zTP8w2zLMt9 H9yJBaxPeC4EvOF975y1sU8HANi1ro3RulJKyjiyFKIocs7jUxjLKCXkiA//P5GQJkK+I1Ra vw1XgG4zdL8MP4zb4lvQu0TYAqxJUKtEKCIhfxEyxugRhI+nAAMAXAsZ2wplbmRzdHJlYW0N ZW5kb2JqDTM0MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDMyMiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzk5 IDAgUiAvTGVuZ3RoIDEyNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibSP yQLCMAhEm0QkJs3Wkq0u9f+/Ujh613eEYZhZlj+glNLaGHNhAK6I1t4E57xfQ4gxpZxzKdvO EFGttbXW+xhjznncmYfw/EImsjpYw8re+eZVK5G47Fsp7JlSjCGs3jsnD09rEREAOAjn0ZqT /bjr+yPAAEehCkUKZW5kc3RyZWFtDWVuZG9iag0zNDEgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMjMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDgwMCAwIFIgL0xlbmd0aCAxMjggL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIm0z0kWgyAMANAWpAiWkCAFGezk/e8o6BXav0texsv1Hxhj nA9C3BopR6W0nu6NMQBgLSIROTd7/+hCiDEuKeWcSym11vXZvQ7v0xkc+bVVtLqcU0pL6wyh D/l4PztHhIjWfgGM6QsnrZUapeyHCDFwztivf912AQYAij4MRwplbmRzdHJlYW0NZW5kb2Jq DTM0MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMy MiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODAxIDAgUiAv TGVuZ3RoIDEyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibTPOwLCIAwA UIUiRIkBUqGAtXr/Sxq6uds35p/T+RBKaT0ZcxHWWucArjfhPSLeiUKIMaXEPD+GnEspS62t td77U6yvYfu1x9aRliqprXWRvpz3GcwsE2MMgYgQvfdjIQA497Z2HGLMpLVSf/708xVgAEjV C+8KZW5kc3RyZWFtDWVuZG9iag0zNDMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAzMjEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDgwMiAwIFIgL0xlbmd0aCAxMjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIm0j1sWgyAMBeUtSIJoKKBt979Mw6lLqPOXk5tkMk2PIISUUimltTbGWGud mwfeh7DECICIKa05bztDRKWUV62ttd77wZzvm8+PuzpH7+AMJ2utPEU0NuxbzmtKiAAQ4xKC 9+Pc1zm+zQbswTbsJMSfP70EGADnpwmnCmVuZHN0cmVhbQ1lbmRvYmoNMzQ0IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzIxIC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4MDMgMCBSIC9MZW5ndGggMTE1IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtI/LAkAgEEWVpOitkvj/73TH0pqz nLmPmWH4BcYY56MQE5ByVkrrZQXGWGudc96HEGNMKW1EzrmUUmvdQWvtAL2fbzrND+xJBjU8 cD4JSEJeCN4jHR3GUN2itVKzlHSGECPnuOvbR69bgAEA+f4J2QplbmRzdHJlYW0NZW5kb2Jq DTM0NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMy MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzYyIDAgUiAv TGVuZ3RoIDExOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibTPSxaDIAwF UIMUECRBNKUU979OAw7cQHuH+ZyXTNNfAIBSs9YvYYyx1jm3dN6HsMaISEQpbTnvR8f8FqWU j6i1fofWzkdrd1G6MiOjRTaYeezvOW8pESFijGsI3o80SbVW8vsZWs9KAfz40UuAAQDa0gmZ CmVuZHN0cmVhbQ1lbmRvYmoNMzQ2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMzIxIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSA4MDQgMCBSIC9MZW5ndGggMTIwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJtI9bFoQgDEMdqAjKU7Qjou5/mUaPs4Px/vU0TdLm8xJCSCmJWqCU6rQ2ph+A tc45730IMaaUxpyn+YL5C5ZSygpqrdvDfvObNmwqBNAV6Jn5vp5yHuEWYwjwRoK1V1hvjNYd 8tGCiNBIiP++eZwCDACbSQrpCmVuZHN0cmVhbQ1lbmRvYmoNMzQ3IDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzIwIC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4MDUgMCBSIC9MZW5ndGggMTE0IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtM9LAoMgDARQBRGJgvyMorb3P2YHll3rW4Zk SLr+JUIIKQelRtB6MoZoXiprnVu9DyHEmFLKOW8N8w5HKeWEq7r/tWp9RteBbmZusx+kICtG pHq/Omdt+4uIjJm0rksoNUiJrR698vsTYACyqAsiCmVuZHN0cmVhbQ1lbmRvYmoNMzQ4IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzE5IC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3NTkgMCBSIC9MZW5ndGgg MTE1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtM/RGsIgCAXg4UxdGurY aLXe/zk7ZI9Q/x0fyMFp+hMicm72/gIhhBhjSssVci6l3Jhrba31vops+4fqHY4HPM05vIZv dVrHRg7Mqup4KiJr79hXKzNjf84WtaSEXKTbEd7PzhH99pdvAQYAy3wJoAplbmRzdHJlYW0N ZW5kb2JqDTM0OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDMxOSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODA2 IDAgUiAvTGVuZ3RoIDExMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibSP SwLDIAhEA9ZIK/6jpknvf86i2XXdvCUMw8yy3AUAICqlHoLWqzFEz9fAWmZ2znkfQowx5Vy2 Sa21tdZ34T05fpnTsd+7KEV/HZackziF4L34nszWzk9EZMyq9YggSRAR4K8dP18BBgBwKQkp CmVuZHN0cmVhbQ1lbmRvYmoNMzUwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMzE4IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSA4MDcgMCBSIC9MZW5ndGggMTExIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJtI9XGoAgDINlCCh7iPP+5zQ4bqD/W7+mSdp1f0EIoZRx3gMhhJRSqWEEWhtj rHPe+xBijCnnMl3UWmewrI3tYb95x2u3NBnU91nJOcEnBDg6Z+GudQsalEIqslsFzhml6PTl i8cpwACEtglWCmVuZHN0cmVhbQ1lbmRvYmoNMzUxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzE3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSA4MDggMCBSIC9MZW5ndGggMTA2IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJtI9LFoAgCEVTMikV1LLP/jca2LBp3SHncXkMw28YY60FGBXn Ju8R50UJIcaYUiJi5pxzqXXdOq21XTlO5XrRx+fRM5J9ltZai1iYiUis4g6h30FE7yfntAAA SBtjPv3wFmAAHQoImgplbmRzdHJlYW0NZW5kb2JqDTM1MiAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMxOCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgODA5IDAgUiAvTGVuZ3RoIDEwOCAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIibSPVwJAMBBESZEiXZTg/uc0CW7A+9zyZrfr/4MQQinj fABCCCmlUnoExhhrnfc+hBhjSmnKeV4aK9gqZX84Xt5CaX3M3RvLnPMEB0whwOmshb/GaKWQ ieR6AOeMUlz05YPnJcAAAsQKKgplbmRzdHJlYW0NZW5kb2JqDTM1MyAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMxNyAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODEwIDAgUiAvTGVuZ3RoIDEwNyAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibSPSxKAIAzFtFARBPkIKnr/e9qiO7eabd8k 067/DwAQQiIOjFKj1saYibHWOTd770OIMaaUlpzLerMRO1Pr8abWduPRsy85L2QgTwhknMls batQTetRKc4johQC4Mv/zkuAAQDgVQn+CmVuZHN0cmVhbQ1lbmRvYmoNMzU0IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMzE2IC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4MTEgMCBSIC9MZW5ndGggMTEwIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtI9bFoAgCAXLRz7SFCXL2v8+w6wd 1HxxOBcGhvFHGGOcCyknQimltTbGzg3nvPdLCDFGAEgpZcS1dLbG3qm1Hi9U195tgSdcEDHT fAKgXSEstNe522GNISN5m15KwTnd8+F35yXAAK4RCbkKZW5kc3RyZWFtDWVuZG9iag0zNTUg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMTUgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDgxMiAwIFIgL0xlbmd0 aCAxMDEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm0jzcCgDAMA1NMGilO Af7/UxRgZYNbbZ1sIX5ESqmUJlomxljnvPdhBTHGlFLOuZTCzLXW1nsf280+Od64ps/mQKoh XZlhgg9WuGdFQJdz1phZTkRaKdzz4XenAAMA0uoISAplbmRzdHJlYW0NZW5kb2JqDTM1NiAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMxNSAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODEzIDAgUiAvTGVuZ3Ro IDEwMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibSPSRKAIAwEBSMQDZuI y/8/6kjpyav2MZXpSbruT5RSWvdEAzDGWOeYx+lCxIMQQowxpZRznkspS71ZG9ubNn+26oLM jCwM8MC2ey8irYGZnbNovcqJSGtc8+FvxynAALztCD4KZW5kc3RyZWFtDWVuZG9iag0zNTcg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMTQgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDgxNCAwIFIgL0xlbmd0 aCAxMDQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm0j0cOgDAMBFNMCumF 8v+XskEifADmZsk7azP2J5xzISTRMlBKaa2NsevAOe99iDGmlHLOpZTaWut9e9gnx+Ad50ZH oFUkkYcFrgCnc7ffGoM2dI5qIpJC4JrvXjsvAQYAf8kH3gplbmRzdHJlYW0NZW5kb2JqDTM1 OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMxMyAv SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODE1IDAgUiAvTGVu Z3RoIDEwMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibSPNxKAMAwEnXBC TjjA/1/KmQZmaGFb6fYkxn6Fcy6EVGoBWmtjrXPOrxOiEEJMKeWcSykbqK21Pm72F4/h6Niu M4Y0HDBFGIkuu0ePtQads1opKQRu+e6x4xRgAJmWCBkKZW5kc3RyZWFtDWVuZG9iag0zNTkg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMTIgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDgxNiAwIFIgL0xlbmd0 aCA5NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibSPQRaAIAhERTMMFTPt /ldttFWt6y95zB8w5leIyFrrnFuA935lDiFsE5EYY8o5q2opZQf1AK0/OSevYW9jtY4QsjDA k+ATueVoYWY0jmL04wrc8t1jlwADAPDvBugKZW5kc3RyZWFtDWVuZG9iag0zNjAgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMTIgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDgxNyAwIFIgL0xlbmd0aCA5MyAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibSPSQKAIAwDoVSosiP6/6ea8gEv Oudk0hrzL9ZaIse8Kd77EILIfigxxpRSLqXUWhvoYJxgXi/MqbGhhY4i+rBk2OBcbhHBEvbW LrMjwiXfvXU/AgwAGMgHQwplbmRzdHJlYW0NZW5kb2JqDTM2MSAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMxMSAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgODE4IDAgUiAvTGVuZ3RoIDkzIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtM9BAoAgCARA0VRMDVPr/09t8d6t5gy7YMy/iMha 65zbwHsfYozMaVc551JKPUCkwan6gDmvd1MnRl/T2BJAREUWEldyYkZPQJ/Woh03EH331f0I MADrxQcACmVuZHN0cmVhbQ1lbmRvYmoNMzYyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggMzEwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSA4MTkgMCBSIC9MZW5ndGggOTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIm0j0sCgCAIRBVN0dQos+5/0wa3best+bwBY37GWkvkvPcLCCFE5pRS XpVSSq21bUBEdnAo/VTGGNcbVGe3z0ldwaYKGkzwTW9GAnNEmoYi2xHhjs9+uh8BBgANqQdK CmVuZHN0cmVhbQ1lbmRvYmoNMzYzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMzA5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSA4MjAgMCBSIC9MZW5ndGggOTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIm0z0EWgCAIBFBBMjSL0ur+Rw2wI9RfsWCGRwh/AwDESDSZlNLMnHMui6m1rmpT IrKrw7XW3Wmuwcb+amNN9zUmFrcabfPWov3MrLf8JlFERIDPProfAQYAvEcGxQplbmRzdHJl YW0NZW5kb2JqDTM2NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDMwOCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug ODIxIDAgUiAvTGVuZ3RoIDg5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ tI8xAoAwCAML2FKxVtH//9VQHR315iQHKf0NETGziExBzrmUoqp1DsxsAW0FvfcN7Dfuxzvu TyLC6ES1xQi2xmbFOhwwDSPM8OOKrx46LwEGADQsBdgKZW5kc3RyZWFtDWVuZG9iag0zNjUg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMDcgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDgyMiAwIFIgL0xlbmd0 aCA5MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibTPSwKAIAgEUEFCNLOP 3f+sDdamfb2lygyG8DsiYo4iMjnVZGY55zIPtS7QVthgd8et936+4eS5G+98wAcbEiqMwIJs NCRV9T70Rmbs8Nl/LgEGAI5+BnQKZW5kc3RyZWFtDWVuZG9iag0zNjYgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMDcgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDgyMyAwIFIgL0xlbmd0aCA4OSAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibTPURKAIAgEUENSMLKs7n/WFpvGC9T7ZGCB EH43AVFknl1KKYuIqpalM7MV6gY7NHcM52uUekvzZh+qPo6UJ64gGfkZe3wdM0ciXPDZO9ct wABnIgY/CmVuZHN0cmVhbQ1lbmRvYmoNMzY3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggMzA2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSA4MjQgMCBSIC9MZW5ndGggODUgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIm0j0sCgCAIRJUI0ch+979rA7ZsWW8L8wZS+p+cMxFNzLMjIkVVa61t CcxsBX1zdnAMzneeqS9GonsYjiFr8MJe0BJtzIxuXPDVM9ctwABFYgYNCmVuZHN0cmVhbQ1l bmRvYmoNMzY4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMzA1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4MjUg MCBSIC9MZW5ndGggODYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm8j8ES gCAIBQVDNDKr///YHjQeujftkYHdIaUfICJmzjkvjogUVa21tjUws83puzOcY3K+mNPYie3u hxDYo2qwwl3QiBaaKKP/1SvXLcAA4kgFYAplbmRzdHJlYW0NZW5kb2JqDTM2OSAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMwNCAvSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODI2IDAgUiAvTGVuZ3RoIDg0IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJvM87EoAwCARQlSCBiPFz/7u6JCkt HV8L7A7T/IMFiBIzr0FEsqqaWdk6d99DPcLZXe/GtG3WdoXrkVOQieSMhtaExkSE9q8+uR8B BgCw6AbKCmVuZHN0cmVhbQ1lbmRvYmoNMzcwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggMzAzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSA4MjcgMCBSIC9MZW5ndGggODUgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIm8z8ESgCAIBNAKCcVKrf//1xa0Q/emd2Rgd5jmPyxAFJh5NSISU0qq mrduh8OU6tpwvjzT1peKX9jpSMlIRG5EvvegLxARyj/647oFGACPgAaYCmVuZHN0cmVhbQ1l bmRvYmoNMzcxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMzAxIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4Mjgg MCBSIC9MZW5ndGggODEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm8jzES gDAIwApFChWp/v+zcsjo6JkVSI7W/gAAELETbQkzDxFR1bkXZnYk7uvhfKemy3M7zqwMM3Qa 1hH2rBBRj2q0P/riugUYALg8BS0KZW5kc3RyZWFtDWVuZG9iag0zNzIgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzMDAgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDgyOSAwIFIgL0xlbmd0aCA4MyAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibzP0Q2AMAgE0EKRSsW27r+sl0rUAYzvk8Bd SOkXRMTMWWSZVLWsYGZ1C+6+X1p/jNtr2Fts4sbjvCLLEFmQPTtEJKMTzR/9cJwCDACVjQT2 CmVuZHN0cmVhbQ1lbmRvYmoNMzczIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMjk5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSA4MzAgMCBSIC9MZW5ndGggNzYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIm8z0ESgDAIA8BCo4KK+v/XmiJXb457DsnQ2j9ERFU7MKWZFjIzX8s27I+I401E ZTJft+5sGoUni3MBQOcidz/64LoFGABI2gRuCmVuZHN0cmVhbQ1lbmRvYmoNMzc0IDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjk4IC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4MzEgMCBSIC9MZW5ndGggNzkg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm8zksOgDAIBFCFjharove/rAOx Ju6Nb8lnYBh/IiKqWoApzVTNbKG23rawd+5+vLHydHO2L7aIYVqN2MwHUHiPVz/6/7wEGAD+ rAWuCmVuZHN0cmVhbQ1lbmRvYmoNMzc1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMjk3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSA4MzIgMCBSIC9MZW5ndGggNzYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIm8zlEOgDAIA1CVVRHUef/TWjCa+b/4Pgm0DONPJhKRAsxpIV3JzNy3xx6O Vr19Zrn13jgjLKI0QjMdQGEbOzu9f14CDADW3AVpCmVuZHN0cmVhbQ1lbmRvYmoNMzc2IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjk2IC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4MzMgMCBSIC9MZW5ndGgg NzMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYKQXYAICZmZmFlZWVjYQ YAcCDk4g4AICbh4E4AUDPlwAIs0LV87NDTIAZBAH0ESw0WxAO1iAdoGspI7j+QECDAC6IQU6 CmVuZHN0cmVhbQ1lbmRvYmoNMzc3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMjk0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSA4MzQgMCBSIC9MZW5ndGggNzEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIliYKAXYAQCJiYmZhYWFlYwYAMCdg4g4AQCLm4kwAMFvKgAJoykkosLpBlkCDvI OIjBQBuYgTaBLKSO0/kAAgwA8gID4QplbmRzdHJlYW0NZW5kb2JqDTM3OCAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI5MyAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODM1IDAgUiAvTGVuZ3RoIDY5IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmCgG2AEAiYmJmYWFhZWMGADAnYOEOAE Ai4ubmTAgx2gqOHiAmnkBJnADjIMYizQfGagPSDrqONwXoAAAwDUQQOtCmVuZHN0cmVhbQ1l bmRvYmoNMzc5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMjkyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4MzYg MCBSIC9MZW5ndGggNjcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYKQf YAICZmZmFlZWVjYIYAcCDk4g4AIBbm4edMCLABhy3NxgXSDtHCCDoGYCTWcB2gKyjDrO5gMI MABgRQSjCmVuZHN0cmVhbQ1lbmRvYmoNMzgwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggMjkxIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSA4MzcgMCBSIC9MZW5ndGggNjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIliYKQjYAICZmZmFlYgYAMDdhDg4AQBLhDg5iEScHOD1XOBdHKATYEY CDKaBWgHyCrqOJoXIMAAQ1gEcAplbmRzdHJlYW0NZW5kb2JqDTM4MSAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI4OSAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODM4IDAgUiAvTGVuZ3RoIDYyIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmCgI2AEAiYgYAYCFghgBQI2NnYQ4AADTk4u QoCTE6IUrIsNZAIr1DSQwSALgPZQycncAAEGAFkcAsYKZW5kc3RyZWFtDWVuZG9iag0zODIg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyODcgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDgzOSAwIFIgL0xlbmd0 aCA2MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibzOMRYAEAwDULSUuP99 pXS1ef7cJE35p0SFRFVraGTW3TgAzBsgjsZOmHm8RRVbxeu58ujhJcAA1cMDnAplbmRzdHJl YW0NZW5kb2JqDTM4MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDI4NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug ODQwIDAgUiAvTGVuZ3RoIDYyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ YmCkL2ACAmZmZhZWIGCDAHYw4OAEAy4Y4AYCHmQAEoDLQhRzQLRCzQEZyQI0G2QFdRzLCxBg AO5ZA+EKZW5kc3RyZWFtDWVuZG9iag0zODQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCAyODQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDg0MSAwIFIgL0xlbmd0aCA1NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiWJgoC9gBAImIGBmYWFhhQI2MGBn54AATvwAqoqdHaINagYLCIAMBllA HadyAQQYACsLAnwKZW5kc3RyZWFtDWVuZG9iag0zODUgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyODMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDg0MiAwIFIgL0xlbmd0aCA1NiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiWJgpDNgAgJmIGBhBQI2GGAHAw4OTijgwg5g0hwcEA3sMP0g w1hAxoKMp45DuQECDACy4wNxCmVuZHN0cmVhbQ1lbmRvYmoNMzg2IDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjgxIC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4NDMgMCBSIC9MZW5ndGggNTEgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYKAzYAQBJiBgZgECVhhggwB2dg5CgJ0dqhau F2QQM8hIkNFUciYnQIABAPlKAhsKZW5kc3RyZWFtDWVuZG9iag0zODcgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNzkgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDg0NCAwIFIgL0xlbmd0aCA1MSAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgpDtgAgJmIGBhBQE2GGCHAQ4ODk7sACgD VwXXBzaFBWQgyGDqOJELIMAAfGADDgplbmRzdHJlYW0NZW5kb2JqDTM4OCAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI3NyAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODQ1IDAgUiAvTGVuZ3RoIDUxIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmCgO2AEASYgYGYBAVYEYIMDdijg4OCA MRGSSDrAJjCDDAObSh0HcgIEGADJTAHACmVuZHN0cmVhbQ1lbmRvYmoNMzg5IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjc2IC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4NDYgMCBSIC9MZW5ndGggNDMgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYBwAwAQCzEDAwgoCbEiAnRBAVgzW zQIyiBlkIpVcxwEQYABGbQKiCmVuZHN0cmVhbQ1lbmRvYmoNMzkwIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjczIC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4NDcgMCBSIC9MZW5ndGggNDIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYBgAwAgCTCDAzAIGrCiADTtAVQTRyAw2BWwe dZzGDhBgAKJMAXIKZW5kc3RyZWFtDWVuZG9iag0zOTEgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNzIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDg0OCAwIFIgL0xlbmd0aCAzOSAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiWJgHBDABALMIMDCCgFspACIFhYWsAlgs6jkLnaAAAMAHLYC UgplbmRzdHJlYW0NZW5kb2JqDTM5MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDI2OSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgODQ5IDAgUiAvTGVuZ3RoIDQ1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJYmCgEWBkwivNDAIsYMDKBgHsxAE2DrBqVlawZrA5VHIyJ0CAAQDFKgHNCmVu ZHN0cmVhbQ1lbmRvYmoNMzkzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggODcgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDg1MCAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiWJgoAVgBAgwAABYAAIKZW5kc3RyZWFtDWVuZG9iag0zOTQgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4NyAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgODUxIDAgUiAvTGVuZ3RoIDMwIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmDABxjBgAkMmJlZoIAVPwCqYAMIMAAWJQDmCmVu ZHN0cmVhbQ1lbmRvYmoNMzk1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggODcgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDg1MiAwIFIgL0xlbmd0aCAyMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiWJgZGQCA2YQYKESYAUIMAAzfQFDCmVuZHN0cmVhbQ1lbmRvYmoNMzk2IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODUgL0hlaWdodCAxIC9C aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDg1MyAwIFIgL0xlbmd0aCAxNSAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgpAEACDAADkcAVQplbmRzdHJlYW0N ZW5kb2JqDTM5NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDg1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4NTQg MCBSIC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYMQP mCCAGQxYWFjhgA0bgEixAwQYAB+sAR0KZW5kc3RyZWFtDWVuZG9iag0zOTggMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4NSAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODU1IDAgUiAvTGVuZ3RoIDIxIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAEASYwYKYSYAEIMAAlLQDuCmVuZHN0 cmVhbQ1lbmRvYmoNMzk5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggODMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDg1NiAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iWJgpDZgAggwAA2fAFQKZW5kc3RyZWFtDWVuZG9iag00MDAgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4MyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgODU3IDAgUiAvTGVuZ3RoIDI2IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJYmAkBJgggBkCWFhYCQA2gAADABqWAPMKZW5kc3RyZWFt DWVuZG9iag00MDEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA4MyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODU4 IDAgUiAvTGVuZ3RoIDIwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBk ggBmagEWgAADACVvAO8KZW5kc3RyZWFtDWVuZG9iag00MDIgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgODU5IDAgUiAvTGVuZ3RoIDE1IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJYmCkLgAIMAAMqABQCmVuZHN0cmVhbQ1lbmRvYmoNNDAz IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODAgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDg2MCAwIFIgL0xlbmd0 aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgJAiYIIAZBliAgBUb AIqzAQQYABaIANcKZW5kc3RyZWFtDWVuZG9iag00MDQgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgODYxIDAgUiAvTGVuZ3RoIDE5IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJYmAEASZqAWaAAAMAF4AAmwplbmRzdHJlYW0NZW5kb2JqDTQw NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDc4IC9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4NTAgMCBSIC9MZW5n dGggMTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYKAiYAQIMAAATwAC CmVuZHN0cmVhbQ1lbmRvYmoNNDA2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNzggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDg2MiAwIFIgL0xlbmd0aCAyNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiWJgJAIwQQEzEmBBBSAhVjaAAAMAEnAArAplbmRzdHJlYW0NZW5kb2JqDTQwNyAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDc3IC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4NjMgMCBSIC9MZW5ndGgg MTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGCkHgAIMAALbwBMCmVu ZHN0cmVhbQ1lbmRvYmoNNDA4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggNzUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDg2NCAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiWJgoBZgBAgwAABMAAIKZW5kc3RyZWFtDWVuZG9iag00MDkgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA3NSAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgODY1IDAgUiAvTGVuZ3RoIDIxIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAkBjDBATNOwAIQYAAPXACMCmVuZHN0cmVhbQ1l bmRvYmoNNDEwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggNzUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDg2NiAw IFIgL0xlbmd0aCAxNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgoBJg ZAIIMAAATwAECmVuZHN0cmVhbQ1lbmRvYmoNNDExIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNzIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDg2NyAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiWJgoApgBAgwAABJAAIKZW5kc3RyZWFtDWVuZG9iag00MTIgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA3MiAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODY4IDAgUiAvTGVuZ3RoIDIx IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAgEjAiAyZ0wAwQYAAC5AAz CmVuZHN0cmVhbQ1lbmRvYmoNNDEzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNzIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDg2OSAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiWJgoApgBAgwAABJAAIKZW5kc3RyZWFtDWVuZG9iag00MTQgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2OSAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODcwIDAgUiAvTGVuZ3RoIDE2IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmCkHDABBBgACXAARgplbmRzdHJlYW0NZW5k b2JqDTQxNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDY5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4NzEgMCBS IC9MZW5ndGggMTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYCAaMOIC TAABBgABpQAcCmVuZHN0cmVhbQ1lbmRvYmoNNDE2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDg3MiAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiWJgpBwwAQQYAAlwAEYKZW5kc3RyZWFtDWVuZG9iag00MTcgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2NiAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODczIDAgUiAvTGVuZ3RoIDE2 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmCkEDABBBgACKQAQwplbmRz dHJlYW0NZW5kb2JqDTQxOCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDY2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSA4NzQgMCBSIC9MZW5ndGggMTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIliYCQNMKEDZoAAAwAJTwBVCmVuZHN0cmVhbQ1lbmRvYmoNNDE5IDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjYgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDg3NSAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgpBAwAQQYAAikAEMKZW5kc3RyZWFtDWVuZG9i ag00MjAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2 MyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODc2IDAgUiAv TGVuZ3RoIDE2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmCkBDABBBgA B+EAQAplbmRzdHJlYW0NZW5kb2JqDTQyMSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDYzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSA4NzcgMCBSIC9MZW5ndGggMTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIliYKQEMAEEGAAH4QBACmVuZHN0cmVhbQ1lbmRvYmoNNDIyIDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjMgL0hlaWdodCAxIC9C aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDg3OCAwIFIgL0xlbmd0aCAxNyAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgpAAwMQMEGAAH5ABCCmVuZHN0cmVh bQ1lbmRvYmoNNDIzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggNTkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDg3 OSAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJg IBcwAgQYAAA8AAIKZW5kc3RyZWFtDWVuZG9iag00MjQgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1OSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgODgwIDAgUiAvTGVuZ3RoIDE2IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJYmAgFzACBBgAADwAAgplbmRzdHJlYW0NZW5kb2JqDTQyNSAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDU5IC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4ODEgMCBSIC9MZW5ndGgg MTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYCAXMAIEGAAAPAACCmVu ZHN0cmVhbQ1lbmRvYmoNNDI2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggNTUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDg4MiAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiWJgJAcwAQQYAAYFADgKZW5kc3RyZWFtDWVuZG9iag00MjcgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1NSAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgODgzIDAgUiAvTGVuZ3RoIDE2IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAkBzABBBgABgUAOAplbmRzdHJlYW0NZW5kb2Jq DTQyOCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDU1 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4ODQgMCBSIC9M ZW5ndGggMTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYCQHMAEEGAAG BQA4CmVuZHN0cmVhbQ1lbmRvYmoNNDI5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggNTEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDg4NSAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiWJgJBUwAQQYAAUvADQKZW5kc3RyZWFtDWVuZG9iag00MzAgMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1MSAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODg2IDAgUiAvTGVuZ3RoIDE3IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAkETAxAwQYAAUyADYKZW5kc3RyZWFt DWVuZG9iag00MzEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA1MSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODg3 IDAgUiAvTGVuZ3RoIDE3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAk ETAxAwQYAAUyADYKZW5kc3RyZWFtDWVuZG9iag00MzIgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgODg4IDAgUiAvTGVuZ3RoIDE2IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJYmAkATABBBgABDoALwplbmRzdHJlYW0NZW5kb2JqDTQzMyAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ2IC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4ODkgMCBSIC9MZW5ndGgg MTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYCQBMAEEGAAEOgAvCmVu ZHN0cmVhbQ1lbmRvYmoNNDM0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggNDYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDg5MCAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiWJgJAEwAQQYAAQ6AC8KZW5kc3RyZWFtDWVuZG9iag00MzUgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0MSAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgODkxIDAgUiAvTGVuZ3RoIDE2IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAkDjABBBgAA14AKgplbmRzdHJlYW0NZW5kb2Jq DTQzNiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQx IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA4OTIgMCBSIC9M ZW5ndGggMTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYCQOMAEEGAAD XgAqCmVuZHN0cmVhbQ1lbmRvYmoNNDM3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggNDEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDg5MyAwIFIgL0xlbmd0aCAxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiWJgJA4wAQQYAANeACoKZW5kc3RyZWFtDWVuZG9iag00MzggMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzNSAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODk0IDAgUiAvTGVuZ3RoIDE3IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAkAJiYAQIMAAJ6ACYKZW5kc3RyZWFt DWVuZG9iag00MzkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCAzNSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgODk1 IDAgUiAvTGVuZ3RoIDE3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmAk AJiYAQIMAAJ6ACYKZW5kc3RyZWFtDWVuZG9iag00NDAgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzNSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgODk2IDAgUiAvTGVuZ3RoIDE3IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJYmAkAJiYAQIMAAJ6ACYKZW5kc3RyZWFtDWVuZG9iag00NDEg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyOCAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTc3MCAwIFIgL0xlbmd0 aCAyOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibp76db1K9QB165euX31 6uNr1wACDACTDkXACmVuZHN0cmVhbQ1lbmRvYmoNNDQyIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDE3NzAgMCBSIC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIm6su3ElXOXr1AFnL907vDpi2sOAwQYAHxjRP0KZW5kc3Ry ZWFtDWVuZG9iag00NDMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAyOCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug MTc3MCAwIFIgL0xlbmd0aCAzMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI ibpy5dqVK1evUANcvnr1yo2r5+9cAwgwAI51RZ8KZW5kc3RyZWFtDWVuZG9iag00NDQgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNyAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTc3MCAwIFIgL0xlbmd0aCAz MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiXrw4MGdO3euEAFuXL3y4OqV R9eOAAQYAFaOKosKZW5kc3RyZWFtDWVuZG9iag00NDUgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgMTc3MCAwIFIgL0xlbmd0aCAzMCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIibqy6ciVXeeuEANOHL+0+cjFTUcBAgwAOPEpawplbmRzdHJl YW0NZW5kb2JqDTQ0NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDE3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAx NzcwIDAgUiAvTGVuZ3RoIDMxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ unDl+uUr164QAa5dvXrp+rXLN64DBBgASq4qSgplbmRzdHJlYW0NZW5kb2JqDTQ0NyAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDU2IC9IZWlnaHQg NTYgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTc3MCAwIFIgL0xlbmd0aCAx NjQwIC9GaWx0ZXIgL0RDVERlY29kZSA+PiANc3RyZWFtDQr/2P/uAA5BZG9iZQBkgAAAAAH/ 2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgXEhQUFBQSFxcbHB4cGxckJCcnJCQ1 MzMzNTs7Ozs7Ozs7OzsBDQsLDQ4NEA4OEBQODw4UFBARERAUHRQUFRQUHSUaFxcXFxolICMe Hh4jICgoJSUoKDIyMDIyOzs7Ozs7Ozs7O//AABEIADgAOAMBIgACEQEDEQH/xAE/AAABBQEB AQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAA AQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2 hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMF MoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPT dePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ ANHFxjk2+k17WOIkbzAKufsLJ/0tX+d/sVHG0yaz8fyLIu+tGd9pLqw0Ug6VkcjzKq898W5z FzmXBhhCUcYiblp80bpf8H/4tYuf5THmBPFKMjL1UNJyiK+x6X9hZP8Apav87/Yl+wsn/S1f 53+xZud1m6lldtTRsfULdpEnUTCoO+suc7CdkMa1pA0Dh5x4qTl+Y+MZ8UMsMeDhmLHFOj+T Fk+E/D8c5QkcnFE8J83of2Fk/wClq/zv9iX7Cyf9LV/nf7FymN9aOr3lwDqWbROrT/eidM+t HU8rqFGPaK9lrw10NIMH5qTJP41jhOcseCscTOVTOwF9kR+FfDyQBLJZNOxcxtV76BY2x9UB +wyATrEpKrT/AE7O/wCO/gkp/vuT/Rv3uh7nt8ddN2r/AKLwf6Z+4XL2u9+r+a4/zbeN/Sa/ n+RYXUMShvX/ALO1sVPsZLR/Lgu/Kt3G/pNfz/IsjqP/AIpmf8ZV+Rq5/wCJkj4rzNH/ACUT 9kYvW/8AFORHI4qNfqcx+oySbvWWtZksY0Q1tYAA7ASsy+oXUuqJ2hwiV1l3RGZ0ZDiRBDND Hf4HxQ3/AFYpY17i50V/S9w7/wBlaHw74zy2Dk8MJjJxQhqRCx1O7lZ+WyTzTkDH1S6nV86y qBRe6oHdEa8chWeh/wDLGJ/xrVuW9I6Xk2NtOPnk2iWba9HAD83266ImD0jpdGVTkV05rC2w Bj7WAV7wdsOMeKucz8c5afLZYCGa5Y5x1x6WYs8PhnNRlEmI9JBOvZNT/Ts7/jv4JJU/07O/ 47+CSh/8sX/Uf2uf/wCzR/L/ADDHpGc/J6jbU5oaMd+0Ed/pDX7lm52dRZ1z7WyTUyxhnuQy AY+5Wfq9H7XzJ49T+L0S36q2nJJruYKCZ1ncB4Rwsr4tPFD4pzBmeG4YwPrEW9J/xePL4eUx cZ4AcRA7eqRMvq9dimu3Eba2s2Ne5pa8HSDGnKJcxoruiktiIM/R0Hmq+H9mx8RlAe4entDQ DptbAn4o1l2OWWhtjyXRtBOh+KyAcft6GPy9eG9peDUkD7hoS4eLTfaw8hUKNuLIo+iZkZf7 v523T/NRMUVb6NvpbvtH5oyd0bz/AKT9H9+vzR68bqTG0j0rD6IjTMeJ0j2iPb8lKjGzw6pt lb2sbb6jnOyXWNjcX/zZEE68rQycxhOOYGSNmJ6+DszyRo+s/wDhsfHo5dme+nrt2KGgtvuM uPISVXL/APFR/wBdKS36H+gf+oftea9qH/KLi4dfa4v8L26v7GvkYvVW5WQaKnhllhdIHMEx +VC+zda/0di4pJaOb7hxn3vY9zTi4+Hi20u/Br8n/pv2Mf3fj9qvT7fucP4Pa/Zutf6OxL7N 1r/R2Likkz/gz/ym/wCa2P8Asi/1v/jr2v2brX+jsS+zda/0di4pJL/gz/ym/wCar/si/wBb /wCOvd4GF1AdQptuqeGtdLnEJLhElZ/Uez/k/Y4fD26v7N3N/wCE/wDSX/lZ7f8AX4/42//Z CmVuZHN0cmVhbQ1lbmRvYmoNNDQ4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNTkgL0hlaWdodCA1OSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxNzcwIDAgUiAvTGVuZ3RoIDEyOTggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSInsl3tQVFUcx4/2T9ZMk03lZE414wM2pKxZ5JUCISmMijANo5UI0ygQgZFI SiDBFMNzd9ld9rLALvtg995dkMdeIQILqAQUEFjkoRggamVNqBRSppwOd+fSYi7RcHdbZ+7M 55/v3rPnfM6Z3znnXtfaXle7x6323Cxc0mj39M7lf/dhWPhT8hhGRtuGVDJt8cLd5IZbhmW2 oZ10WbzwAMmBJIB1y2GTk7VodIC1j0IDMJIvMST80HSr792runn487JufAC/1qOdGiHmb/lP 4FgRbHK2jTDyvD6Aj7ZpEGnRWFSwuBFX/nHJ7oRvj+nGzmibCAUhkOUelqZFFZw6rvJ25L22 lpebUIimYIfCzXpl6Fahz4t8JPlZTMGVDm3ygYIDgeK8o4XqHJmxofS/Ct+pXGo94ev9RG+D OuuQ9HUn/qa1uZ0n1GgKP3RpWypUh0Ml/q8KIgPFU8MLsv19hBj8shhPCueHB3VVv2IN4dHW 0t3ewnf8hMrM4sR3scig/Bt0DYye1sTuzt+8jrfLTXDzPIFmMZ/qKFElle/fKdruwvdbn50d +mZX9QZmhX+7SPzci1di8k3reJsdeFhK8UiLtucL9e2/d5m+nVQLE6XydFlUcH5GnBSVumVh XTupCvMXoa68HLJbszhG8mUGhSeGiHKxPGEfJk4uSgjFjoRjbVUqSzIZcQWotndsFNTISi63 ayYu3LsNJ78jDIUlJZnFuEC2f4c4zCvhe8UTzNbw+WZNVFA+0tjlnjfeT/xkxO9c0VsS/lyu 2PuGKH6vpEJSkhKBNRJKdACaN+ipU/s589GeRYdMMy6r+iToV93DjAj3k5xLshX5sRGS5KKj 4VigmzA9VvqvWwktYMcJFVrDuLckvuv5mR9KUcWaHo3346gS6lUKtDe3OPOlqUVTQ8WTddy7 1UsYET5X7SSNDPDhZG13ydML5X1flV4zWixLc0ZaNDEhYtO5t8dXhOp/ZiIXCWVGMdqzYdtE 9SrlyVLlj904s+dwn8FJEbvFh5MT7Jn3TZly4acruqM7a9RobdEf0SIPt2jQoXG1Q5sSUYD2 rJcjf+hrralOGL84JsuWNeaFnK1VoX29cOFZJi4QTbjidLVKkCj9aB+WE194MCRflFg0e4Pb 8l1i4fSdVKPaQGTHS28Mzjk07FMY3d3o1ehtX2G5WHZrmLB/YVSug02lnTWqX/ruPZOtILwE 1j8zfcrbSsBv3WHd40wKG8CMM7nUiqAhmBXWASgBkACmnqEeQDGA+NyooyNqJgKwjI4aKh43 i6hxOR21VM96poXTAFwD4DF6lCwAVwGYSMcMAFdSbUwxCcAVAObQ8SCATwJYaBZXUc6meAjA 1QBmMi2cCuBzlAk1yjQyfBrAI/Sg6ZRSCh3RRJYDmE3HGAAfMxNG8SkAhXT8gPLPYIVZYVaY FWaFWWFWmKKi2yW3aWNqvSUGdGtsJtyLcyxoNMzAa+ZW9nC1He4BCk9HgSUGsWdtJyx+4T4O HEQewmOniot3zghvlZu+tu7LoGSl7YRFz1vQ4CM8AhRcLSvMCrPCrDArzAqzwg+msJLyKaFH KQUw2SyqwXQS1cYU0e8fA6ihYxE1BT0dC6mJ42ZPU6gOmRVGVNNDWC0yItzJW32TeMQ2tGU7 Ll441v+9xKBw2/D+tujFC9sHD7Iw3ukaovFww+wWzxkKEO57cC5xlmswokV2UZ2xb9pnQB90 ht6/BBgAsLH2LgplbmRzdHJlYW0NZW5kb2JqDTQ0OSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIxMSAvSGVpZ2h0IDIgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgODk3IDAgUiAvTGVuZ3RoIDE1MiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiZzP0RaCIAyA4WQYODBmFIX2/s/ZhgqeTjf133GAwXfqakoB gNb9WTLG2gHROee5cRwvIQSi6SrFGG/cfS+l9JCerZzzYVV2+VTaLsx8m4csZdpExLP5CXnJ O4eI1lpjyj+01gBKqe6f1EaqIotC8itpFVH5w1JE8weoWV6tKttR30x0NDkxDdXUCwl+Ir0F GADBMBRECmVuZHN0cmVhbQ1lbmRvYmoNNDUwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggMjE3IC9IZWlnaHQgMiAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSA4OTggMCBSIC9MZW5ndGggMTc2IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJnM/bFoIgEEDRFIxLCAmBopHa/39kM5KXVk91HhWG2afiWFmWhFBa nSHGOOdCSCkvkFK11saYK9RY65y7LXkfQmjbtosx9n0/QPellB57KeWP8BcOwdHYwZ0QvPfL lNE5ay3OnozRWiul8FEphRCcM8ZwIUopIbBh8UfoOsLmFabesAkftwgbd9iHK6seX2XbsNFW WR7jUNZssnqFgWxGGS5U/QJ7vgQYALjuF4cKZW5kc3RyZWFtDWVuZG9iag00NTEgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjAgL0hlaWdodCAy IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDg5OSAwIFIgL0xlbmd0aCAxODUg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMz9sSgiAUQNECEglRhARBzLz0 /7/YQaNx7MX9wgwwcNblegghjAkhNyjLKKV5zhi7Q5wXQpRlJaWsldJaP2JNY4yxtnXOe991 XQj9Exq2XtAYg/W7NcBpH0KAu94751prjWma9bFJa6UUfCCrshSi4Dx+zFiez5RmWZxpIQRj jNBx7DOhzbYk25xsnHMRbTLZpp/NWuuibaWFvWzcl3gHnN3hdMTVfzbA0YQ7b3t/BBgAbUEZ OgplbmRzdHJlYW0NZW5kb2JqDTQ1MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDIyMiAvSGVpZ2h0IDIgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgOTAwIDAgUiAvTGVuZ3RoIDE4MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiZzPaw+CIBSA4UINBRG8ptwk0er//8JAc01da+v9xBjjnOd0PgQACIIwjC4u COM4QQjj1EVIRiljeVEUZVXVdXP1tV3HORdCSKmU1r0xN99g7TiO033X5C6ttYN/YozRWisl pRAPzruubecfm7quKjekyBmjlBDiZmOMEUriGEK/VhSGQQDAcfff7XXom27BrTqPczqz6La4 p+993vD6VSf4hzfrylWXzbr0L91LgAEA6+EdDwplbmRzdHJlYW0NZW5kb2JqDTQ1MyAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIyMyAvSGVpZ2h0 IDIgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgOTAxIDAgUiAvTGVuZ3RoIDE5 MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYzP2xKCIBRA0RKUVBIVb3hB Q9Gw//+/Djm94dR+YWAYOOtydeV5CGGMfSgICLmFYRRFcRxTek8SxtIsy3LOi6KsoLpuGiHa ruv7YZBynKYHpJSa50VrvW7b9oSMMXaB3QqnyzwrtduL0ySlHIa+77pWiKapa/toWRScwzdZ yliSUErhd5ghDAkhgZ3Lxxgh5HnO+X/k4sUOXnXK2786fejMy2Y+PsvTlqcO3njGy094wd+8 twADAAZMHVkKZW5kc3RyZWFtDWVuZG9iag00NTQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDkwMiAwIFIgL0xlbmd0aCAxNTQgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIlsz0kSwiAQBVAFFAIiJAEzMSSQAYf7n09Spbu8ZVfX/92n8yEA IETocs0wJqSglLFbxvldCCnLqqpqpbR+7JqmbbuuHwZjrHXOez+O4xRCjPOyLOu2pfR8/aWU tm3N8znGEKa86f3bOWuNGYa+69q2afbQj9ZK1bmnlFKIO+e5nTFGaUEIxvthCEEIATh+4Ocr wADBYQ8YCmVuZHN0cmVhbQ1lbmRvYmoNNDU1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggMjIzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSA5MDMgMCBSIC9MZW5ndGggMTUwIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJbM/dEoIgEAVggQIhBMUQBApS+u/9ny+YZrryu9zZOWe3aTYBACFC u32BMSEtpYwdCs47IaTsh2FQSo3jsdJ6moyx1s7OOe9DOBXnGFO6FMu65nz9u+W8rkuZ31OK 8Vw2Q3h479w8W/s0Zpq0rqGvcVTqXXp6KYXoOK/1jFHaEoJxPQwhCCEA2w/8fL4CDAAWXw3R CmVuZHN0cmVhbQ1lbmRvYmoNNDU2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMjIzIC9IZWlnaHQgMiAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSA5MDQgMCBSIC9MZW5ndGggMTg5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJjM9rD4IgFIDhEpQgUlHDK4lgXrL///s6bPWhTVrvJ8bOODyHo68gQAhjHEJR RMiJUsbOEOeXOE6SVAiR5XlRXF1SlmVV1U3Ttl2n1K3vtdaDMdaOd2ia52VZ1odrhdM8T3A7 WmvMAIO6729KdV3bNk1dVWUppXt0K4o8z2BPmiRxzDmH7YwxSgkhUeQ+hjFCKAi8hh/t8dgO b/PytPn4gOd8y7o63Fv3xVM+nvDwwn94z5cAAwBl1h1CCmVuZHN0cmVhbQ1lbmRvYmoNNDU3 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjIzIC9I ZWlnaHQgMiAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA5MDUgMCBSIC9MZW5n dGggMTk0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjM/tDoIgFIDhwEQQ SaEUBAzUvu//AgNaW7XcfP+wsTMOz2azGAAQwizbhvIcoQJjQkhZlpTSqmJsV9d1w7kQ+0Os 7ToppVJ9r7U2xlo7DMPROef9OIXmU+gciudpjlej984dw9hg7cUYrfteKSVl17VtelMIwXlY UzNWVVdKw/KSEIwxQnke/3XLMggBAMuI1Tz0w2Nx7wcv+e4vnzGXxIs+7/2UfAn4wr11f3j3 Lx7nzR9esZb3eAowAJoPGlQKZW5kc3RyZWFtDWVuZG9iag00NTggMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMjIgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDkwNiAwIFIgL0xlbmd0aCAxMzQgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIl8zkkWwiAMANACBRkFmaVV1N7/jk2ea/27zFmW fwihlDG2As6FuEiplNJaG2Osdc5dgfc+hBuKMaWccyml1tZ6v48xNrA/wBPM+fqaE0PI7ljf oK/33lqtMJtzSilGXPgOwfsPHnHO2sMYOK2VklIKITh+tTJGKSXkx/+nAAMAw0kLXwplbmRz dHJlYW0NZW5kb2JqDTQ1OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDIyMiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgOTA3IDAgUiAvTGVuZ3RoIDEzOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiXzO2RKDIAwFUIGyFEEEC8iiYpf//8WGvnWm0/OYZHLvMPyDEMaYkAuglDHGuRDiCqQc ldJ6MsbM1jq33DofQohxTSnnUkqt277vB2jtBPdvfdT69oCrrdZScs4prTGG4P3n3+KctTNk TForNUrZo4Xg/MEYpb3VkxCMEUK/67/eAgwAMjEMmQplbmRzdHJlYW0NZW5kb2JqDTQ2MCAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIyMCAvSGVp Z2h0IDIgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgOTA4IDAgUiAvTGVuZ3Ro IDE3NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZTP2Q6DIBAF0FawUGQR x4rg7v9/ZAeJpoltTO/jZLZzu18kyzJCKM0fGMY4fwpRFIWUUimltTamtNZWAHVdv7Y0zrm2 bb33IYSu6/q+H0bM9CWxPg7YgX0h4IjHSeeaZts0404AXG9LY7RelMKzEq8LwTlnLL6UU0oI /njF+M+GuGW3WYi4OdkSbj3hTrxDlmjRtkbahw2gOmxqt4loY8kWaeQH7S3AANVCGNsKZW5k c3RyZWFtDWVuZG9iag00NjEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCAyMTcgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDYwNCAwIFIgL0xlbmd0aCAxMjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSImEzt0CwiAIBeBSlwSRzGmpq/b+bxmsu7rou4TDz+H4n3Pe+xCmk4oR4IxIRBfFfE1J ROac81JKqfV237XWex9jrA/1VC+zfdur1rbYqnmdau2zotZayqKL8yySUmJmO0mEiAAQo70z heC9c+736bcAAwDGcAwhCmVuZHN0cmVhbQ1lbmRvYmoNNDYyIDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjE3IC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSA5MDkgMCBSIC9MZW5ndGggMTE4IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJhM7ZEsIwCAXQQmwWadBCTdz//zMF274543ljuCzD 8B8AIIZwGE2MKaWccylHQ0RTrcyns5lFVHW5fLXWe7+am7ubx+q522pveeTlYZtpbV2wqIrI 7IuZudaJyC+WUnJ+pxSjfzOGgIgAP57+CDAAGjgKiAplbmRzdHJlYW0NZW5kb2JqDTQ2MyAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIxNCAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgOTEwIDAgUiAvTGVuZ3Ro IDExMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYzOQQLCMAgEQA1ICqZJ bajR6P/f6aZ60otzBZY9HP8SQiBi5hOISIyTqpmdIaU051xKWS6w1lrdt+tba+0G913vj1+9 77OxheXP2ebuyFlH4ILknGd8Gc/MVHWKUWQ0eTITEbp9130JMADqjgplCmVuZHN0cmVhbQ1l bmRvYmoNNDY0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMjE0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA5MTEg MCBSIC9MZW5ndGggMTE1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjI5J DsIwDEXrpNgOcWhcUsJw/3vyQyshseLtbP1pmv6CiEIIMc4nwCwiqppSOoOcs5mVUi6Dpdbq vl4PWmsbuO303u9fcO3vodigPDyruyNl+eQh1+yBjlGFRtWnCDOPIXOMWEX0u/b1FmAAQz8I 3AplbmRzdHJlYW0NZW5kb2JqDTQ2NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDIxMSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgOTEyIDAgUiAvTGVuZ3RoIDEwNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiYzOyxKAIAgF0ICSNIPKyvr/Hw2dyUWrzo7hcem6nwAQkagfCueYR+99CGEy McZZRFWXtdhMSmk/XmeRX1fVyly7bXa3Tdu/66VFVURmu19iLM0ymdm5+gURIQLA59NHgAEA Pg8I6wplbmRzdHJlYW0NZW5kb2JqDTQ2NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDIxMSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgOTEzIDAgUiAvTGVuZ3RoIDEwNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiYyOSRKAIAwECVsMElTA7f8fNXDQKr3Yx1RmppX6CQBorY2xTvAeEQei EMLYiDEyc0ppmhtLzrmUUtebrbN/6ffnr0qsSHrpPZM0Mh/S3kZkjIgGRO+bg7PGiBHAS/S8 BBgAI34IvAplbmRzdHJlYW0NZW5kb2JqDTQ2NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIwNiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgNjE2IDAgUiAvTGVuZ3RoIDk3IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJjM5BFoAgCARQBUVITS3r/kcN3LXp9dfDDM79570HQMQQFRGllJhZ RDaTcy611l21bsZhTjPn9WXOlbL4WKe9aYuWFS3NVq4jwnzrIpGtx4AIAPrR68NHgAEAlmAH igplbmRzdHJlYW0NZW5kb2JqDTQ2OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDIwNiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgOTE0IDAgUiAvTGVuZ3RoIDk3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJlI5BFoAgCAUFkzQ0s6juf9NAV73Xpll/ZnDuBwCI6L2fjBAC0RxjTCktBjPn Usqq1K3TduPoiJzfiIyBTVsbh1Udqsqq5O7WhpaISKsWv/QLRAB4/Xc/AgwAfeIHXwplbmRz dHJlYW0NZW5kb2JqDTQ2OSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTc1OCAw IFIgDS9SZXNvdXJjZXMgPDwgL0NvbG9yU3BhY2UgPDwgL0NTMiAxNzcwIDAgUiAvQ1MzIDE3 NzIgMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dTMiAxNzkzIDAgUiAvR1MzIDE3OTQgMCBSID4+ IA0vRm9udCA8PCAvVFQzIDE3NjggMCBSIC9DMl8xIDQ4NSAwIFIgL1RUNCAxNzY3IDAgUiAv VFQ1IDE3NzMgMCBSID4+IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSA+PiANL0NvbnRlbnRz IDQ3MSAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYx MiA3OTIgXSANL1JvdGF0ZSAwIA0vU3RydWN0UGFyZW50cyA2IA0vQW5ub3RzIDQ3MCAwIFIg DT4+IA1lbmRvYmoNNDcwIDAgb2JqDVsgDTEzNDggMCBSIDEzNTAgMCBSIA1dDWVuZG9iag00 NzEgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA0NzIgMCBSID4+IA1z dHJlYW0NCkiJpFfbbhvJEX3XV/TjGliP+35JDG9srxMIiAFjpSQvBoIRORQnIjnKzFBa5+tz emiJ0+1qSkpsw6St09XVdTun3nxhb9+++fzx/FfG2bt3H379ePbm44VkiwH/jr/ZsNidCday sze/NZt6bO+aj92m69ttM/btgvXt2Zu/4MD1cPbh8uzN5aVigl2uzl7zinOu2OWCTV8l/vee CXyVk93DNx+qgF/M4Z/Ocs0ut2c/fem737/htmXbN68u/3WWHxLaVV54l55ajOx+3ZJ4pyol ncrwNNRXyubQNWsH1lF4yWUluTYpfkdDXeWk1CmUjeuG3dbjmo0dq9lwS1/jdRW0zc7S0MAr I3OPVhE6ZUQeM2KpjMiAYP2QkmbJxrq/pi5UUuPC7D4yb0rhQ2exHWmkrPwPYWVff/r7+Xu2 bupl0399hXCNa7pCtOSV9Tx7xLDuNiRaeVShy6K7jEnfdSOuue27W/Ieg5wG5dODPYvQKcTC xGjzU5VvQ6ikfvCQuiQYRC3FkZkXHI8WXqbQzX5su101+fTp8uzTZzT4sefF955PWpdHp4v+ epSx5+aQEdqqpKy+zstPngyLs5V8iOhFt21Yu2xq8tnKHWolOTL8oeCbKr74dJqsrtxDTAum 9cz0R/lPMXs32p6IqZAmWvfMGlVJf7D+lnOv4uh8h0tmLmbj1FHeCq1+NPjTPxq2qHdssaan abCVlyY7Q05HyQVCbVwKvZlm2LLb1uT0lcAaHkx6aBcPDQ3rm3/vyQnAQ4XMyvRUM9DjQspK SxNSMNlM4IFKW5siWWlaSRWyx9Z9Q6PBSVqGzN9FtyVjoqw/DOk0Jte0aS8r5TA3E/Cq77as 3i3ZVWGmISRcZ1ntFjc48w1R39TfME43pHcGaQ7c6CzNNNSCmEz2kOY4AZ9UAMeS1eI4Q1Gu F58vv7ChULIB9lx6pL+LpFCxQnOap5qTbP9jh8Zq0PE15Q49vlSffunM1kNzbtptO06NtNtv r8g+0rIK1tv0OBkfqVFe2roU2rNuRaItDAvQX4KeOpO2HgRgmfFhHNgtWb0C1YsGfYbbSoBN BRCZ23QfI5jaZ0733X5s2H3DtiRVKKi74Fx2wU1TYkf7f9aM8JEqn5zq5lg44XThzAy+pHAU BERQ6fFi4VjpTAotFw4M41kp+nThKBMFyhx/snK08eYZfisguIoFn/pd0qvc5dE8DJpnkaxS GkGKkmxuYNGRql8ZKENpMs+WNNRWiquQhfO+QDgOstvl0bmn6cajgJzOPB6mnWNdk36DTish shPLTQPSWHX9VG9DvSVPhik89hlpM1CsIvgsODPyOHaGeKIzIMQftV/cVJrxjwx+Tiw5OUsW pMIki9fPT5OTQyqIJGtECt3SqYmKRzudgYdu39OqymHseZk9gu4gH7UUz6BYhej55f43rWuw cbhHHqBNe8p00SDW11Rs/WgwkL7GIhDHfjQn3XYyqoGD2+ds1TQbpL4e2baDaGtWqFuMmvt2 XNNZw4d1aPnEzkGl0iWBvcOjARP8sGh2dAXZ2K9KpPCelswOHxZiMsF2WEcLcxWmOQRiAm+W L2gkxT1kMc+8w3i4ouct+NMamcHBuktw6XuI0nNWbxHqzaaFqIUZ8pkaszEubokRehoZg5mS B+8O60B7XYPxx3VByILvMfbSDJFIgUHiM2SuYk83jQW58Qdxvu9ROH1JVwhebMyieR3ihDzZ k0K8qCmVjyPktEWZWNQzAXRoy4dv9xE63SFZ4MyAPbC7Rcvvx7Fe3AxsP7ab9j+xHH5rrtth 7Ot+KN2qqHc8b52IlyOX37V17PWhI1cI6EclMKOPaEzzbjWRRfN7vb3d0L3GTWxjNTtHUws+ jFFz+6yNS287FJYaaVB6Crx5PLEYW9J5ifUR666eQXdouWXHdt3I6uu+aYp7EDj9RaQQA4p9 0PmTdWKK0/spcQv7OvD4nDDd8Gew9iH+ZNp0nIyoguQMVImUNv6l6qncClsjNhETZHq2p6Go X+FDCh1oHuBge2V0il10+82SLQsqG7LD6syR1/3UF3S+QxyUmTtNX6jtaUED56bwWN79caLJ Y14kyQgCiieeTYywekPmRcmAthDZlWw/NOhy1D0WFXojwzQyBhyQnKPlMXIiFNKcvqrdFYKm JaIQtVKa7nps7xq0yrZudz/Hbi8JU8fz/JOlAuJFRfrMrYJVPNbbDErubEbgsVZnzn9jz15S Ylth2z107W3f3DW7sSW5VUAEC6/cDH/NDrJnT+JBkUpiAh7x5AQUkLXKKj3D0W3pJXQUJsgR R/ektxU6R87vjfq+NKWtlXMsuatIoQ+S6IiD4okk1e7u2hESCtpl19zTGxjUBQ7PA0dP9rid GgWBPwMO9KIGXeWEm8e2sFZihHge7Nwkxp8uj3374rGvLXYM99DKBbPkijETCIcSVaUroOvc Q3V/2I+sHXZ4hhwPRFkjv/V+SUZfeBCsh+RJbNy0EJ+FksBrpiTM8SsaGiUS9HQChTdwanf9 SzHE5E50OsQai1F4IsTkZvRsNaQVZMVDFt9jEbpv2DWtiEKlZeyZ+QlaPClzuD2BxrYh0UZU 3ASRotFY6zpO4v2WnIBSiMpqkd0BRr1rFwVWVYhl5j6tzbSvlMqQh1Wx221eMGQj0cKATy3d Nv2KDBv0JkhS2xTeb+O0bXtEgjxkMW69yg5trwAnaU9B5QThM5/aZmBX6K8NycIRGlQeu8UN mU6t42y12QWLph/BqMfYzbrflEozMrR5rJ6xwbp43dAkFYszGJOeWTS/sPNSyYmoRuZosteF UZV3xqZQ9Hr/sKXQu6vkFuWpfHqusAqIuLxm0INUv9o0kWL2uyWEEq39gouqNaSna5oVwEja PGifRzUVS7vENtbyzDRdVUrF4WB+CNNt12NJ2cXNqR2HKWpk0YACtVVZmIex6Rt6vGvsu+BW kT2l2P0aaiNIJ5+RDw3BEWwk2fQtmI1T9cbCpaoVrOAeZnXpnSKWhYpuzNHf33nfkrEVeKrm MTbzM2u6WnUVfJQcc+i0sw41BD7ZDBIKVYU4SeeHvpRKlRuRufLzgY3x56ompbm0qHCudXrs K1RYgdMkL1AlOSdU8E8KEfBfkSX94yjCywpXQFyC6Q9K6nwVSXKsNzdo0A5Tc9tdtZt2/IY4 lNQmN1KnVrDyLNvVCpnfjYnTF7f40aPf8rvfkznGhsWOeILyRRUhDQof5ZNevqY1UNwjsVqk WHpoOSjjkEPpCeXippg58CeSzMDPlYk7QeoArZq5wgxXmQf9LJKHp+PnICRMV4hsHdOM7uub s1VSHWoWZU5EmR/ZSlNRVuhrbGOTK/b7vChRPHy1cyS9zUrsdc49B2gQXePmwJ4OmMLdgus5 chhA/GTRYjWrIMrEHE0/CUUjLMTB3Cy9EMVC8Dxx9dgC518G9hVdsZyY73FkRUOHNjXHNg1U DnxU5SgD5UylDo36Zfj6qmJ/G/b1Brrt/V/P3198usCc3WxIByU+hHB6ZuKqYdt62bD/cl5t vW0rR/iv8KnoQ8Jw77sHRRsn7UNQtCeAU/Th5KCgZVoiYokqSdvRv+831G2XmZVSP8mAZ5az OzPfBdqv5nMcpISnRp1y/vrP2+KxeW74j5Db03GVxyvX+1s/dot6okyeJwNcjYm/NjT9M8+p GvQ9bfMpdpEVbCGJaw71txPSnVsgz2sgL7YAw+P2C7lpwGyQMOzsCAVicIdpcxfgRihLs6uS QN57aPJxVseRi7YemyPasklgkAB1lBR+CZX1z6Dy3h/wqEw/Jpj4g0/o5PsMMBvAlg/66jtJ OFIv08AxhkQKs5NpcJcR0VxDxJ8R8dL40sa1wJ8Ni77dYsB5TNelCCrtAx8IIeHSuclsm8O2 6eShX9h1URLo5Hz6dCs4Piw/1pMHSUhFHXxSB4+93kOu2mR+e96eiVK55M3KIqdpbEYlZYYu HGBUGVlKe1Etubxa0ueeX/wI0Gdf/0eAb/HQ9S91f99ulnv4PeLq09CyDcYKl1ISWZ3OWU7w 2Gzu3+5l/lAQcvJMB0/kCS1OyQSw+BZPYMAW75PoZQrFE8YumkmxDl3xicfmQBaDGPN0zn0X gWe0LOriy8HLynPVQ9PkwRMmNiQJOfAEQSeBO2x8PZAxw0V5SASOBpEk9eQUN8UaxpetSMKp GElS75zzjYcpDZ2XBrJVSIsfr5JAHvgsNLZVIg6kavecOvm2VENIVkMQAFWSJEr0vXrN44Us /USbV+6gJHnbkJwJtVPU9/cZoUYy3FbJXYYMvHkBQwXbEoUe94tV2Bp4SF7v2ntq3C6Y9D1B 5A9srELbrU9egoV3UhpCW5vO1AVe1g4v4WTydBta5KYfzk2NVEnGvx0WC3cHVk/l9cWWp1oB eaaIgc7BYIAN+5hCK8TaEAev76i2r/woCPCFr4iAzwnDll8/OjqNbKBjSMe2m4M85hcBEyG9 SGqC+OnWNY9+MKd2YpzowqSac9TgX0k6cEjqIueEPOe4s/R3lz4C5QNZEML0nRti7aYvmu88 fKJ53ruQJrGrLogwpZudv31sfim+SqnqcawX36jta/aJJQBABvojTl+uIPkfwSZIb9bb8efn WVWyBMfo9Lyxg7hCTVC69XPdPvJmDRJfApDS1LtHsHGz5ncWjkMYM/tYv5vI974dvhX51RU/ XJrX7Bq+wcl5LI9fgS7gZ6GslIIwg4OdN3jBVmugJ4Wcx0YYE6kef3ECPfb2gDEPsIx9swRb 8qyM+ZvKO6f0dc/CvIBU98a4OPZud+lwD8rX1ezwMaO1sJpVwKxFwUs2UEx2LSmjWD0tgY+8 HAAnCzjFKJxtKtkbE6DXosD1HY9uutTGJ/eixcNb3/GXI3wzs2e+550C5JRLHgFqlSd0FBFc 0mzggOZjgarGiTg2i62qeh22Skcq4DC0ubMFe/b/w58kxuRxNz49QAav6udmmkJ+aNF+wGOa N4w05LADE4exnYDsL03l0zwWOCY7S4MbR7IQLonWrZmF1qDS97dfbv7OpriqdJZaF6f8jQ+F y5ROp6HTLcE+6xOKRBbAsMgOsK08rW18DkD9TfGy2hUDL1mU06X11exu7KbBFZXS+NnbPvIL QZ61kvNLfQJrPXYv2bZrBdjVRv7YdrJSPFXA85ofMoqHvltH/ika04vOUxJYHhZ9Ly0hGaF/ csCqrJZxEoZi+Etui+QrN1SRm7qyoSovgBR9IXu4NGfOun1aLnntiQ0IZHuS8CHXFAFRj4L9 LDy76Goe+kvumjr7hNkLCl1iNS6/nomO/Sj/I6Lnk5o7XVR+z+xQHif4/FMFu0kP/md8Zd6F aH0V120h7Y8n/vHfTbGoN9ga9u0AMlr6WQpUIR/tTRlgh5JgHnyxvOjL7Nx1O06wu3nK0Cs6 GTSCkyx2nKQRpZkUUxzaExP3zX/ZDDCgsNqkGbwgQPVOE7BfrwOCDbgxO5WdUyxgqap56Dic 4Nmc+xt44e3wqBiD5IBiC5MxsMUprL2dhE2csOBRHAgEtpx1DCKbDbayrJyTafBLU2z7btEM A/XgidflGjJHhNnTDuMEt2yCBUQaOfsUi6baQXUGMZuJots0JyGNf+aw8rQ9IgiiAX9YBXZC hJalUM6nwawPIHiCXLNp6II3ethGNw/l4dSgWmNmBeTAyb4anAR8lBcXwemnRNz5daMDj9j0 2F5FBkA70kOazm+kgpp3s0gCBh5xdBmMcmk0KadvDT/60mFPAA6z8zOYEzCI80s/nTWFOr+a 4F5NwkMqOT+A3/UKfk75WSgLRArN9W4eOg7v+mbY8nSsMJmVULPD+UKgoozys9ACfrGe3pVX bVSSFDbN4uUasXEIs1DWKWno2UCmKu3u7afPxee++77LrYt7ncoSgKqrKstzZ2dPxJa7a8sd khN1tJRnwVDtx+vwDfoAcAnMRWxCZ0tZyuK2WTz17bgr/tEsVvWmHdZD5puadYoXnAV9T4mj xIVbVV9lZfZNGJr+OYeGxjkXZzb9UPBK2hlMHd4+CuaR2xMBeREHDhP48F4Qxxqt4mgW5SUN MApIisW4N8VdU4z90zCyWdahv0InWfdvirErhokNWV2qKlsKMlxR1jpjZpUEgjib1rXs+c0l N+Jmd+DRQAE1ZRz3hhacFutfN0N5AjhxnkDBSlYtVKltlXyy+NKhHS0LXVpbDC3EdhzPB8Ju aJ0cvH3qt90AMwv/+Pakuq4xVzhcRMiqVHu/Wu+ykksQUQkTovAFP4fKkE+NA6fdW9Pu5QbX Bhsn8M7Jw+s5Exc8bTKGcWpQjZnsmwVvSKUP5KXi5PVpDk96gSMqByMbpzU8j2BNtKniwPsm M7gGe0qrcYp8U7ys2sWqyNCOxnsGee15FByPAIHHDep32738aDZj2zf8QMGQVkbFldNrTkKX X25NyiwEE2XwMx1sqVQSx1cA/1DpuAB09DTGkZRwF8cYHQClHGVLjvDpIybALSXxmZnHimHu 7Sy2yJysQcoBY5RET8//Qo/fwauyozn9zC5QrLpt8/Zu93bFm0RXejv7UrflkRh4YayaHX9X D6xekfScys2vzIca8kouDX1T1PBWL6uf14JKKeqgTM+hfagfH3mU9qWp7OzDvPnD8lRez0Jf iswSe6ymVbPL3xfbrt3AyIG8njPeT5e2mr9x3z7spu6397R+gMDuoTg/y5lBJMsgx7kmADrA /EFV8GMNwvUyROH9M4kKFP2y6tZ5HUCgigrOeTt+SCGkyK2e41AJOs0zriTGhW2NwgEn/HyS ATIuihxG6Chd5iSaeIWIxTuit47VsDf92D7Ui5G+8GW3bYp3n+tlu6nHFhv77mYc68UKnum3 dx+6ccRL/v7uw4fue/GbhALRcprH0lggivJkXaFuvSR8tMXvcaGGV8TQPIWTOCiPjxRigUQa R5+C9kNkpmuXE9kz5HWskJBJHhTxx26769sljytYF/gtkySMxVcJ1pX0kV8f2r64gdfZ8JVq NFNCaMX5fyjeD2P9rTmXLVy2W+T2rIUxVL60xwubuF//E2AAH1/2jQ1lbmRzdHJlYW0NZW5k b2JqDTQ3MiAwIG9iag01MjcxIA1lbmRvYmoNNDczIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSAN L1BhcmVudCAxNzU4IDAgUiANL1Jlc291cmNlcyA8PCAvQ29sb3JTcGFjZSA8PCAvQ1MyIDE3 NzAgMCBSIC9DUzMgMTc3MiAwIFIgPj4gL0V4dEdTdGF0ZSA8PCAvR1MyIDE3OTMgMCBSIC9H UzMgMTc5NCAwIFIgPj4gDS9Gb250IDw8IC9UVDUgMTc2OCAwIFIgL1RUNiAxNzc2IDAgUiAv VFQ3IDE3NjcgMCBSIC9DMl8xIDQ4NSAwIFIgL1RUOCAxNzg0IDAgUiANL1RUOSAxNzczIDAg UiA+PiANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gPj4gDS9Db250ZW50cyA0NzQgMCBSIA0v TWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9S b3RhdGUgMCANL1N0cnVjdFBhcmVudHMgOSANPj4gDWVuZG9iag00NzQgMCBvYmoNPDwgL0Zp bHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA0NzUgMCBSID4+IA1zdHJlYW0NCkiJpFddb9s6 En3Pr+Bj7sNV+ClSi6JF62T3BrhdFLW7xQIFAsVWbG0dKSvJ8fW/30PZjkV2lKTdJECc4MyQ nI8zZy4+sTdvLj5Ori8ZZ2/ffricnF1MppLNW/ztv1k7r84EK9nZxedinXflYzGp13VT3hdd U85ZU55d/AMGy/bsw+zsYjYzTLDZ3dnvPOGcKzabs/6jxH+3TOCj7P3uP7ksyfDFLP60Kdds dn92PtvW7LfZf85isBAiSUXmQnRbrzddWVcty5uC1Xd3RVMsevv9FczTFURGXUFyk3Cb2dDr dlXOV73H2Z9T8jbSisQKE5rl1YJdf5peTRLWG13Nzq4+IqSnKItDlINgcX9H/lyA0ixLpD6c MuJaUq5HHTqbWOejA4dfy27VO4VdOsif7PP3Yx5kYrPMhD76Zx98BDUgTjWgqCcK3bvToTu2 LVhVkGVgZSKFsiEeOe9qtiIzxXGAzkRokNNQlyhkNoQ+FqxbFezLe3/Epi3YQ1P83pJnKaES lZn4rKYkwVIn2kS5qJbse7Ej4UYlzmQqxLc01CUuy2QcU59n/5S7smk7tqof2ANlrpESx+Mw NDQ0TQRP0xBa/7X7hsYaKVRFFerPEAZLbZrIY9Nd1uwatbKvALJitE2E84EbmrVd3hVsu9oh ImXL8HObL96NXFkHV05f17YsTXWSOv+o8a41lOd9MBzVfUfXKAbpeLpnzANHDRgl6jxDdp4n VOOrZOgMgdi0ZL0KpVHc0dmoVzrmDoSlXXTRyaeEzXy4SZvMJDoFFQc223K9RsfVi828YDk+ k42bojeUT/HQtK2brsVMGIwDeYqJJMcBiNaI2BGOv10X9y3Kpaj6DiK7zqVgMhEFqGvyqn3A TbxJfIeUuoOWKNMfHuNj0I22oPPdOoTX85oOlU5tIq2SRJRvMe4oE8NVkv0QlAkJRU0Ja6O8 f/qJgXwscC38XDVPc7WqO/bl8lg/+ZqsIIfZwD39Dq3bmt2To0TyDAVtRXxYixTnHSvv2K7e gDX3XP86hpKZTkw/HYc+j5ODHgM2UcKq0AJPPZw+UvJ9tcnIygdplR8GVn5brstu99zZx2Ar 7uXFYZRW82b34DXVE4dT3Z1xFxles0Xdp6knYzLg/hf4NzDD9Zpi25Tdvr3RrscG46dY69FY 940y9LdvVjrSMlFKuBB/T0KBSK2IrtripiQaE0Zm1oboZd4syhF+VE4lWpjoKuBHL3xIaaF9 mXgmDyxIGaMV5rfvvQD6SF5da1yEZ9HV91LhX/X1J0zF9pDNV5HXsaKEO8kBz1w1LekhzZzX fkP4nIbaxEnfV0NoTdOANIlJeXQLkEa1oKvZ39mlIRzqf75CUY7xjHXZa67t+muLENpt6PkH Ilc6ugddcZJr3Fmo6ImeHYsdlN0aaqjZQOnVDWvLJVmCYD9jdPSKKl+PiFXsSc7E6CUbTa5K QUxOi1dESaUpohRD6eQqi6bHV5xcusswD9I4UTnmeLFeJyOKLP2VFY2l3HptaZ7TenZc+L60 JR1OMZBI9olvO9YWXpWAQUkS6wvbZS40oyva+JaxEXQ/B6GPqyUdYOlfLSOrbdEU0BIVJmg1 otaw+GgIz8CsbhZ0qTuPjg9p+n0vf6S3MDSd78+X362kX9jS+N1tfT8yrCFrlEGlBngvNP3g auv1BoOT5FlQnZMuOqiioQ6UHN8pYV9XNNtrxMfTVwAfkYq+SKO3lne0TjQIouHRLfpd6Zln Gg6ayCBmXn6mEX7Emgj605PGoDzksbV7tVRWHdYFeoPBxpMpERr5xeK+Rs0+0AwOGvNBG5o0 NLKnSBtCIUZosncoPB+GIXiE65VXWxGU7HiJKpPat/EQ2uvZii1zktmlb/1Mq9CGTJkEpWNm R9B3NDRFqKH1AihjI9Tofol0jZUDjU17zkjPEeea5w7BoxU/HDKFItpigNBUJTRPjEvT0KYl wy7Qixa4ELusILbINhcWBSO1iXzThQiSSnV0DZazNa0EvJjQMnrpqtsWI3AF98rTd4gf3VB9 2aRaRU/tN1S6zByeypWN8CQ0U5C6Irp7x5CifGTbEgnXLorN3Qa8cbuutxUtvpWFlbXRk+mJ YlH40FUhlEyplydY/KKUPu6Yj/w+njSL+y6MojnC94hOT15x4P1qR1qgo6SIr0R2uLYo4ExE WRrpQsF/rcGhYE6KfMS1GO3w144Q5U7a7UubLws/zOdFQwbVqyqNzg3NyrtynmOF/SZx1Ire djJM1F72DA23WDQKv/Ut654n9npQn25OXVwanXDoltAV3UzGy3wbQenGTg0WECylAdQLrUds BQv/vG5V9IHBc2l5lPqaiA4b0fwiccqXzxCKM9p3Y4mW/79+llg0jqX6dVUzmpoFJqLwND6E 01QrwfgmhvpckskQGh2fYeEN4GQy+vlgrYk8IxmghQW9QGLZlFAhocncZ42mfZe4FDtkAH82 v9jREu4LJDiARqZeCEYhfza96tcoAsmSL1GEplyPOYTcgqjQzzo0gUM74Bz1VIl8X4mHIyTL ONOZwL7Ue5Yg2gRmTV7tK+sJJwz3gswO0Q8xxKKOpB5C/A6SVwv2z6Lb1s139me+Kxo2Leab pux2Yw8ht919I1kq6v4RUCKuP/Lz3ydsSpei9PtkqgbghweaFdESUuGwE7LpIIImJS3HMXWk X8BO8FXRtH8be5/9uaLyz0txgns2+0O1OpE3Yhi1nrl/uDX2KA2dbQ0KDJ7fcO6Ur5C3OCDm MvdUQYKcWj62ma/Uocfzj5u2Y+0GUUYdzP6c3nyevr85DRQz+mSpIFhUFl7w/Ov17I+b91fT GyHdzeQDLaUwCB3uGBhOSCjOwIonQujNlMRqh3XHl84Q+8f7sWRkv5QMrRP1YiYG+oEcw6dM HN2dT1f1Zr3oEzG2TaYcqv9kQXcFqFxILQc4eufMOHKghjcIs0/yspPDC/SpVrQQ9/uVp5kn 8CVK4uryivStlPGqZHiZyYcJDcX0t9wM3zdFir+d39JKOfOlpgZ5o6eOxiZjZID7viU9as+/ DmLhhQBrpDjVQbwWbD6iy7FGZW54+P1D3pW35ZocpuidRKR8GINu9+23kTqX/KU6J7u7L3aF NNpXMM8LqvNU7gOH59f3D+vivqg6ch3ya6uEQgpt6Fr2vSGMCqEt+/j+33tiG1UkFgM+9O9H 4Y7VkKsNm9OTRHG0mOXRa7xBuykhdUfSQG8bzw4UrJzyyGNjbp/RtuY0D7KxIzj2pOxI3asd W5aPZbXs5fq0aB7xqDH2MFrZ0L4tFwUrkdXT9DiJGryfnCF8v48Ejvqq8NfY54FMHxrbCBRe YIiM7fNAzweOLSWLTJCxlpVV2xX5wm9vTfHfDd11Xo8qpULzxl+TbuoUAstEL8N77r0U37QF aWU4Us5jK4xTdorp61YWAe5DBx3LE9P4tuxYQW8XCoSisIwEJvNmR48i4892Ibgr64rV1Xr3 jn3Y0RkTPvyYOIHdoN5akgdkijhaHVr1hdkO1t6XBq7MFMoli9ws9nspPTkgUlLJbWhxOza+ hOfvAAryhno+5Pp/nFddc9vIEfwryEuqUpXA2O/Fk2OfdYmr4pwj20ldne8BIkEJJQpQAZBp /fv0gBS5uzdLy35g8WV2sDvT09O9a5vbhVF4ZOnS4nbxeSCZx5UoFRZxUpCpeBweimbcwyqt CSsHjzjx9iSXhvu2z3hbLClsqTgcrcN3x6ndbuip626zaUe+jxWKpCGr4/OQntCd7AGwq/d1 HD/RiAKYPFKgIgykQXSChbB0FaSr0nHoPFyPzbF8wZiZHKS0qVXyOXBoRopIxFsasuhBcCzN PPMnTF1W2iUPWt1OkDvtxO+mGtPik562GdiBYjAuSUd40YPm26pKmrHdPha7GzZegZ3dH+7R o9l3bLyTpdI2yc/jHz6uliZJTbCgUf4BlnSmlOH+YMFf+VIt9BFGY6Dn9utc8IAX2sG6ED7C M/eZYCuhKWQdB098KGymSEOxMHPSqDI6ufhU3PJ7AEtVGRizKJqXTxDM3tYmDt3xxI+3gani 0H5fu2EssJa6qfjvxeWvmU0PWyfSTrXNtCfXfs0WVBlbCi+Tp4xTZtKAPy/T1/Rr9kIEPEv6 L376TTPTU3bddpvV+aY0RiSI6Oem68EBxRZvmjOqAMxW6eSLm2EM8P4NCX6Eu1UnzUoTs+lG HmYSf8tloxPFpt0V265vp89/KXOaVH2f1D3ezUjSu/6s3tVs7qQC/uxnoAOP0urNsCzOzFQq hXnwJj5ylx13kGmS/u4qp6AdeYc4eHcDPOfmUisv43C2bTSXWvjkGlgyuiL99+biA7868VBb JQ+FWiQNyG9nXAnCPTnRsbhXFZjaE7uHsX1Od2E1a5kkxije8LkxU1Z7lVSyaPnkEJMOcisp 5OMyuM1EhHI18kdppVXKJve6xcmXOaiaHxwDKE/Q5fkxsNkxCCyXO/sZ4UovDu/4SH7v7fuD 55t4yKJ4FB8dnPi2gHqhUrWKg3lwe0R4angYul0XVxkdCWmhfBydd21S6dJIan0YP2Ig5syw SesxQTI5wQ+bIwkok1fCUBRTZmgQpnwSPw4ZC7mMQnp1XsspCbHhVFJEWIgxM2W0HoVJbtIv VeH3KS09S4wVHeA1KGgcyjgOxbZa7e3WasvLUQ0OqrVNigmHMO89VLO3Nid467PwBumcBM+M IvOuBncFZ8bh13woSlx7G4fC0rFCfFkdQibRvLhUvvQ1Oc0wNLNkwO4VOc0wdMzKT0u7Kwwt i390XzrgbWkEex0pRGlrIeODQ0fdg8Nrv7RbfmwcSaikkrCTYJMXgU4JXCkrVFQlIALI94V5 VrxvoAkBjJMq885IGrJ8SWjTdzzcUWiIn+Q1LAkoDUIyaSgYiUXRsoGUTTqYFaVKJA0c19S9 jOuiv1qkT1wGqLu737Z3NE2LQGWHwVREZyZtIR9K2zCt5hz02Rz7LOpzcwrIkLzcb7vrRQr3 j8U1v1U0oGkxKdGhTKiDofJJ6JoNhex0Bi2JQrPi1v3YVpeeCOEJHZncnsudzegECZHzOqGO MrpDxkM6WdQVZArkBrq0pJGAXCmKS1qn44KXqSCf8fYJPjTOw2bRCvwXVcW94XmzT7fRpBUP t4EqGcH79CtY0hGIttrp+BgPCDIX0pg4dKbH3I/DFV6Xk9MosYxPTRii+QYcCt/Kko00jqSS i4+xUy4tGQHn49BxLp/v7aQDWZHwi1L8DGOH5/Xbx6Vbl+0aHV2xukRBx9TK2eSVf10Ovh+H r107YSzXx7Z/awlTI5UpFQkvSnXZXrM7X+DPQLVEwVjWbKUENI7wRsbRwOO7Tx8+HgiO7yFY A3IkOpbRlkQaLo5kqVIK4oz0LnPx8V8flkK9y61IUSev/cQLS+z5PxQGr5xYyaoqlFFDmkTh 9/fDCULi1DHFrl2om8V0xMWdi6sBSL97mB+abUZKQhk6S+iLqrYG9NrT9+1pHXju+xrfV6ZO nvC3XfNYNA8QK/3crZq5G/qSX0fYQkaK+HSRoyjxgxQuVemfmDKXW+bprz7VwJz9DonSpyn8 383iTsE0yygvr1/OFNOqp0/4k/cTKvsGYTAErpZx8suLn35hoSq8L2sD9RiF86EwNbL2ybUv /v3mgkU2ZFjl6yTxmwOrhO+KSheYWsFSIPpeOSLcMO18A/HTFJ9e7UXPFfbIFbtHlCTvATkT HV8E77Hqz8Oxshp/VVKNru/mrplpjxFDPF8laZRL2Cpp21UzwcCuhr4HoWMmXhbPH/T6sImx 8qHXDwlfYVx3BLQJxZqWjcsvUW9KU4Pzo9O8s6oFuBQPjELPIfg4GRkIE48LKkGU8d2rX7+B nW9VREL0eE0EFuYltKya+8zOXt6WFJGHlrTk7nxSh5Z0R4PmQczzrEqINDL5BG9ApC+VSiIX nE3t+IW3Nw66yRLbh2dYH6k8/dVJy6eXWXJVz9GwEAgCdKee2PTDzfCwXe8V1VVOz3uBjRgd Yx8nDA2zSELPMOcZ0rR7xEWZLi/+w37W4YYgkTiYXe80RlUNzReFvr245Cmz8qWuhI6j32RR n4Ke3TVSmNKqOrlC0fXTzEsjBZcrdBLfrPM40N+3ZAkRqKA7a2fQ/+x2/daKoA9YS+rgabFi OUBZFJc/56yFqLyKD/0EBXZ93U6wRaygJY6qaqvjU+zYSmiWytnkA9+xaggXnoRXlGDZeUTi y8rjGcmWsLsyPrfsuS/t2G0ei1U7zt2GBFc7PduFKLtsKJe8BxV+LGA82u5LW2zG4Y69k9YQ vK7W6VvaYt1tNnCB/RxU5hk+Uhhd7qGUJUEh8E3l6iCWZUABaQppYYO4gvTo3PFpwVRSOhNe 4bPEImz4PekIZ9hMp/ADD2YABkOqwrtkwAUt6awI7/xwT3qGatrxPslSaheeIUuFpy5UQ4V3 x8IrdsbIiFhbhddjdYQC9oXz9lulV3iGdgTV03PpEbc9nxYoMmRJT+GrW3oxW0pyvboyYfKx uOF3IPha+rClbbNmcYz5hzCoowsP/VJ1Hvf409Ctp/hdg7nlsaIddEctIqhctzNGHR7tNB7P YUKtMKzHIevulk7zcMaUWC3CIzyQNSDnZRQ48/tZlk7TKj8F7q1djvXt968SJQItlEnrnqtU ZFWqs5k8e8GEqmzuruDxw9r7J6+6KxTMaB1G7vYcsRB2thtW2/AMOwXUDUFr7hS3WrpBCpUW QY5eQJ0yyn5YGBne0nAOxkQneOYyFSyGiS5UXA98UksyVkSxENTHSRCnlcW7RmhbK6uoSESR zS1PRovHFGE0r67xZ01cneJ+26zYYCDVeRVnfVl8RHfZcJC0cTrOnQl1CPU2ygxioWEfxrnp Sf3Af/wpB+o6r7X8qa45VNcOe3yva9nb1aTnnQviFkTzC5i2hY1igQh0Gs2CTdt2bL8EdRc+ KjjWZokYCxqiCFr5FLxrHotuPhT3ecJDaiJoqOrgpgdu7ecWe31gt4aCwqilDW+aNYVQSjqI e8w5Qi11mG+/I3btVXE1DjtoIjg4vu+6+m62xXpkZPsrEpHwuJT54+N9W7x431x3/Z5cXrya 52Z1g5r89uL1MM/Qhb+/eP16+Fr8Jpfb0zOoJdqAXqGUDRSUh8Ksa1v8Hl6w5nkbEqNwEokC 98eEWDQMIiDV3mZ5bk7qHm9IJHu0BsP949hdswKCpJWqsPLCA3PxWRoB5CHgl003Fq/G267n b6pJgGAiw/N/Lv4+garagO9ctkv4OikzjWKW9unBNuzX/wUYAHwXn3INZW5kc3RyZWFtDWVu ZG9iag00NzUgMCBvYmoNNTQ0OSANZW5kb2JqDTQ3NiAwIG9iag08PCANL1R5cGUgL1BhZ2Ug DS9QYXJlbnQgMTc1OCAwIFIgDS9SZXNvdXJjZXMgPDwgL0NvbG9yU3BhY2UgPDwgL0NTMiAx NzcwIDAgUiAvQ1MzIDE3NzIgMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dTMiAxNzkzIDAgUiAv R1MzIDE3OTQgMCBSID4+IA0vRm9udCA8PCAvVFQzIDE3NjggMCBSIC9UVDQgMTc2NyAwIFIg L1RUNSAxNzczIDAgUiA+PiAvUHJvY1NldCBbIC9QREYgL1RleHQgXSA+PiANL0NvbnRlbnRz IDQ3NyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYx MiA3OTIgXSANL1JvdGF0ZSAwIA0vU3RydWN0UGFyZW50cyAxMCANPj4gDWVuZG9iag00Nzcg MCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA0NzggMCBSID4+IA1zdHJl YW0NCkiJnFfbbhtHEn3XV/S+2cCm1ffLIgigON7AgI0NJBp5WO3DiByKsyI52pmRFP39Vs1I 5HS7mnLiwJCMnOrprjpV59T5b+zHH8+/fPj0CxPsp59+/uXD2fmHK8WWPfwb/2P9cn8mWcPO zi/rbTU0j/WHdtt2za4eumbJuubs/FcIuO3Pfl6cnS8Wmkm2WJ/9ILgQQrHFko2/Kvj1iUn4 VY3nTr+FyCP8YR7+6Z0wbLE7e/d7M2zY1fmXT18+sveL/57lQdJKrrQxadRTzTbVY82GTU1G KeF5iD6kUfdde7Ml4Rp+xKBSeL1j7Zrd1WSEC9xInT3mma2aHjJ18zA07Z6K08pwa61O466V sCRaA9rn6PHFHxdnH79A/Y4llS8lTSojsCbiVDVcjFyZ00cr6ujigcFzH4Q9daBODjRzFsnx xi+/wbVfPqFYFMx5y2XA/wFHK8U1V+yqXj50zfDM+nY7pr0vfNOQ+Tl8ciKupVKFX3YKCjB+ d7Gp+5pVXc3aPckmpKy0Ic6D4HoPt7cklWRwXHqv5/C+xB8ktooiJGASKBVXPgWyfTtsmv0t 27U0p4FtWiUhHc1+r7kOwc+RyOFC5u2fYyamG7v+JCUddebEIH0spyydryNwdDz/08Canj3s V3XXD2RepIGcq2jmUe0KZk81jAPosr7Frq86ehQZwZ2NYR59TwNHHiTAjgZGqJNP7/PY0CUd WeDn0FXdsw2NDoFHIe0c3TMyJ1oo6MT0sk80MHJjnJ4D92xZd0OzbpbVADO8hSySoQHIFdPr 1OzrBWv2rO1WVIjRyEfjkhAaGLg2KklMh1d5rLbNCq9FRSFzVOBqYvym2fX1ds3WbVd4wcgc icw5RuELOJtYV237dqQeLUqOOxfcPLhEUWWhIUVMsEBRmhKew73myAOTET+bwlMPaaqHtNDc qPkhWJeedfX/HkhuaQtMjCYkr6lXmPLlpl7eHdtp1e4qqDBZtQBjIWg5P+SpwZlGoa1wPGib JGU8VhwfZ0oDQjruNajZlJ/6lbFklcE9WCfTmCWNtNwJmUGBbTR5oHO8DSkYk3zIEq0QMEZM 9ok9awb21PQbmmlA0yC0TmNoWYEyBqNNdimoYgdTkB4qQE20LunhQ02PSxws3lmVwrHItJ2C 1CtQoAR9Qop8QYpoEggLdDulQuEvewoJ0myj5t6+XFpy2v8qBz/guAQMzVb3Q3WzpQnpJQdk 9gGyntLDkMG8JdANfZVgeAQKp9jF5yt2U/XQyst2t3vY0yTAz0SffQbGf0OPswiElNKkcNpQ C7QiMPkSKEPCvIgzPY1Qa8HAJFGTjNNSBCKu8jR1BVbEIivskRWxyAqQPfVKZXWKFUGm4MtC C0pwFtbDepOgS2+VDmy10S5Fd2xfcK8C9F1mNylALY82ZtcgdVxGOVmc9MY4Z3p6hMEgiN5m AfsVzL1+JmvH/Esy/zgJnY9ZEeZu5d/Qevu6Xo13oakFDAkxu8nygcSC49ZSZdgB1s71JFR4 Z3PkTCClOIyUzD9YbkYDO6i2OR3GZiRbzIAZFzbovBjNmlWgi7RQW27yLxyT+P0+QyrgTAxQ EC+49y8ngQbCKsNualr4x/nn0pBbGgheSGeHM9KdI3mNREbOsaQ/l2CjvfcpEgz6CmYkPe6g m62DhfHts2EP4VEFm115KAk7HqyySyfuu+kLMmx4CCpL4rQNTpVTx8opkpZS82DzRz22d6Us aBN4gEXh7SSMXlIp/20STtk0HS16hSwZpE8zAh2dz7KM6VpW+4l546JAxnpYonTI3oErBby7 m1E/HGeRO019G7myKfVf1xSaf54LBxY/CSzMWcWdAS1KoP8p6JoUlLBNr9FHOkha2Ty+Br6E ZnP8jD6hbVK4GfJijXYR64tuY3jY7+stMnfZFWgvuZPaz04glQ6nPShNmOGwStfvItu1j/TR EfrPw056DOmv39MdBBtmnL/3sGJ962I9SAak8IidVIbWDMkhmfMbTGIEyUCGki81CjLi1DyI XX789dPV4uPluLORn7LgrYDK8/z0w18a3rDKqtdWgKtOxqxgVjyok8arzoPQrHS8xEtZcPUn t7wjI0EPD57OnCKly8CLosGUFjQgoh+Z49FgFt+MSUzQ8OLRapA8lGiQok8jRh5U/R1bw6Sp HiDN+6GZhJ39icmtgLk+T8y6a3clndHOcmG0SiPY1wvOIEVdvSYHPpLSK5+9gZz4BpgklM8S VONWC2PgoW/2t4zeEE0Apy+DyyMNsPdgsd5c1g5EBlGDEfAi6R2c4mm6WBjBAUVgHkBPKwnJ i8aoFNvfkzmTYKiEsTYF0y4IZMApnILJufQdYuDSog4k2JFHw4Ze6TQ4blSxNISG4gtFdvrI DXb5T3pfBPshs1d+YNWWnsmKW6Pyh8KqcE+zFXgHxcyuQxoBnMwiT0uzfoakVMM0xj5efP7C mn3fkH1qNLigb4pAe2YducG9JIGOH/mtoxsIx0Z0Gcv+eP7hQOxZq7/hMYQ8mpWL4+SgBUsG w6EldRpWnFXCofj4FD1pFu2HYfJD95g0oOvqnrTmyqJxzB/RwvI3SQ2tzhp2IDQZ8xi2andV s2eTMn2fyGkTuR232vlJtHvQDn4EJ7O8sZvnmXml5x/8cD5L4VSg63eFDjUwhII2Os87TExS hdC5Aouyj9DMg50zeJ+l/OBKp8n6lv6+cs9Egd7zxYBBHr5eXL8var0itf67yP4q+PhQ/9ou 9oTgK5GBf6fZJHHP8ioD01MZdhdpZYpkJWXQ3LuoUvCybh5p5wRF8fnRIIzVnk0dTXtgGB3e hTTq4BoKBhtE1cHITYMKLnJsNQkrawLup/EJPndJOlZt0RMH9R0p1ZAmLXwGhV5mwxMOADAH xZ6S2mT3KtoPm0P/UaKoLq9Jb3kvCeWYmsL5o/utChx1YAakysAgFrv7l+z2sDbR5ksZ1GSf xXa4RazomnuPHi/Fg0hU2/7vr4stkQtTzsWb68MhF9aidZsGxM2pXBibghfVXWEjws3XOiNT PN2yaI7ArKZQVt3TaiQ9HCxdiu7a+64pyamyhiuVf+BEJSLAjc+ujqVgo0uv2F393KEnXrYd 3cE6RNw4snSR5NcRbhdghifQe9BXWnUktIgSWdXQn097H2yp212hhBLrDe8y5mhn7quOLmBA NF5rjt7RBRS4UqbIeoDeaPZ0QWA0BNC4NGKU6E21pU0omBDhTMw+Qo8etLdeZccXJi1oI1rn BAqa/68N2z2z23b1t+v3pd6zRam0h9YDOTwplVqhvk9FdKek0qfYy/qWFqlRKnFYz9E9FqMg grgKuBz/QFPCgh9GBZxjb3ZN36OWPTX0ioij0Bic7vMwmhgGLBJkL0Fio5JgmJTOuhRcj31K rzESBofKck4vVBH0V2jiwgQLXHkCuwMNZDhNA1iZDhbNn6AB5maOxRVv8fmK9fVUA3qVFKBF Pmah9MulhDEfXQplN3VDuxtIkDMhRdMtqaGyCnmWHIzrwAB/C80J+xcud0kMzQWYtxGXu/T4 Zj1Z8be8MnooNUrhPPz/pFdLb9w4Ev4rPC2wh1XEN3nyOAMsMNjFJNhkZg6TOcjdsi243XLU sh3/+/1Kslsit9hxvKcGGlUlslj1Pch+FtZMa8gn7bM+HUYeSzUISAeflR/YZyYPAz2U3QSe AkJgRvhPv3wkx/rtCTB1N7QPRa/hoQ6SKrQcYIqjfV3mkxcIRwdRR5Jlz5e8YwUPGLySNQA0 CS6EYnGDz0Iv2y34dM9LhECOVcs0o92QhubHGIsbiZKSk5eh3LNQTu2puc7QtNHe6kht/g5A BK52sSJuumigQsVYhhy9TLo8eXJvie/m75zvduKxFfsWT1BkFaexvUkaiyAwX5XzeSipk+vm AWJx1kybUbAUg22vFMzGKz6kMHDK56HtsGdXENCDPQgmjb7FgfZb8RqIADxUJkaZFrjj9x1T ZwP0TXqLw2M/bKcPNvzqe1mF/7k8km54DIoWullmncZ+w/SxxzIaWGBU1gN2gYzGGLo6C2Wh 1+AdtIb/TB8c89QMrej3lfi1XyBnMiXFoYTTPPJtv28hKTCZQ/v1vjCVodLO2jQPH70/0Lyx 9oG0KvxQnsOHwvcGrbNjPRQ41lVSmewO22ngeXIDIYZos4Rh7C67TTPyI2wra5RLM9ovJJgK SKHqN+KapW2J/hQKAV9KKMRv0LG4qRdM/tezkzqMBarAj5FZEv9csLOmhhxLQnndQiAljUlD rzCsE8ESv17T+PEvjdWQIMUkt4BQ2DcVZBqKibhoCoI2VDGo7AY4UjfbOwLQSnxen3DT7MUF u5VKV7Wm3VjXYifRqFA5qfPPbnbsi5BRksr7NJoHEROhDm0W2m4XzP0+IqhIBOtfDOLQXvJz oqYHdWkCPyfKVLamx1+HEhGUpioqaOckujCrET7HZ6HsKkvar5rIZB2K6wG6Wl4XStgXZ2J2 w6LnAgMZaXUa3c3zve1JdvMTiDRyj0ma2LCx3ld6WoR1LOaRJ3ZYKp83nd0aXcvKByPz96GT s/GKFJPKSze3hXCLB7UhK08ek10ODSEdfZ1Vn0zmoeh4jVLAdpmNb38/Cn4BDYi81tnT8rre 1iSEs9B2Pzm0lbJfyUB/Eoulr4J8ETNDf8uOHqlp51wWPWKTL/vCtE67QNy5TsFws8ETsYWs Pr+8BJF1yOrykk+GejY5SextadNVDUvn89JbcdfMwq0S55AWj+2xx2rpseMVo4VHzK/FyxJd m6qWQb2iBRCIlQb9p6EtL0QlRKvLQjcTn9DL7fuCDgWTRheyw/D7EaD+LOmpdWyzE809FhZ7 UmIcK/MkFmUwQ5W1OmsiL5AM+DZMfLuOhUUURBxnJR2j3qiRoPggd09rJP3/OzUVDam9+Tt/ 0E1EdyiiIWniAKuWpv12/kUpdYAUfRGYaMc8zhiCUdx2hwMNxexL/pGPt+LOpyVMjo0q/RLc XfusWKaj8jMT8YMGJJmP1/ys1MDrUOef4UO5utezi2h2u/7x2RlcdBAgLx1cRMh8WXvyMQI8 wctkwWehGNX5ve82rfi1HR95ZQDT4Ry2O0kvmA4AgQpp5A3v5wixsOE+DealqKQ1zS+A59/t eI2LcJmd90x8GKAdStbE6Sy+nae0gHfQa8GbV3SEoNGhLWlof7Hj8Qi619Z5YZbWtAZcGJ+d WvSXZEYmU8JjasALYcWytHm1lvUxy0RxA2VqQGDM3mNaTLgQHtxwsQBwSz9LHcYcbofuge2H RaO1UfEVM2IBaPC72Qd+WFIoL0nsHyU7AGYvCjZMk7j2Ms3Z7FgFKY2rXLAhDWZvQvbOw7+m oUQEeFyA06GgsD0AHUIyyeJpT6FX0k4qeBX79b4rhIPw0NrsQLfgR9KQpY2yEeIhyeC1PiKk d1ljnrX+f/7J6wJEap8d/+czfqMM1IDKypcIz7yNTJWrV36jUNuWydQehxOq+9R3iB7lQqZ7 UB4c1wNM18QS+xailkC92d28gDvBPH4+tcty++Vz7C7oGvgZs8+tvgLKvYAOBYbRR/B/d/n0 /K2ZqLstZoOFgUjASfy+Lk3py+lWZKZPNkP7RcGQlyGHctWOY2Fb8cVoYAOSvCt+AU0FS+bT UPT6WYDwch2WIagshyV6Ikmr8lBgJ7+q2L1oVXaWL7Cq21XTvjdBirAqRpuWab+NQ1NgZ0eH JMBeJ7DQpnwNA+iyI876GZRAwFXiOryjztpwmGj9y98rIUqb5N64pcqSrnInt9SXt/TVgykN MdB8n8+E1yXIVhLagNh+nQGpJ656XomBGWqrfZqwFTQL1DVxwT8QlGW0xPnrtFF0I9h69yQ2 PXZ4ljv3LCPN/o7EcnLQK2h5/mWhp0zWCHYpScSoiUKTk7XDHl14Klhd2MdKO2XyLhAuHa/C ixBFEJBdAxpvgB5jE8hKBumyhNsS7VkCTumy92HPApVXhWhCGjrrlWXOzMk5w9cWJdHfsvgh Ud4YwrJ1dL9vBZafx0lsI5mmJIGvbRERyLGsQ+ntZvLB2G9Lyl9B1mVnKin/IFX2idsG+uBw 1/c8FisHZLHGpElQxEP7lY2PqlIhC+c3CSIruFc1R8P56cn5Jc/Eh4bKqLyP46ESn//9CQTP 5liMpop5+QO/kGRwam/zIeC3C0I1epcVFv1du2dPYvBEWOFswra0I9cs7BkDEYCxz65LIuWX j+Lj0H9by4HvOJGXZZBQFuoF3Nea6A6qoAEwDtAkokBFE0BG9Cep0oiHlWhyC8MGlmEhkqOF 0UtqDE/49OFpuVklPvBd0bomTZ7lT1yoQO8Fugpvo0Lp4yK/SrUjV7tY0QUi8ZPkqusfqmjd Qtfvf/tcKip/qKixhLanj6nYpmYSwJ7sL+SWf+nGH9dPUAB7ksYT5z4O3Ti2ZHCacSLdob3i cUy5Sll8NCl3gGZjo4ndamjrJHogU1CyaM5Zk4ZvD6JhqVAFvIapQ3aWflkQtfSG3VTCTm3z 5iQOAv3gsc6Dw4B1SeazuaHmHXjtDEzFlOusIXykgQmF+EtvB+DgAQx2T6rsJtf9gfc8Nla1 wwon0T+xoS7iwfMWbVlmNKGutHHZcIAZed/lKiND1kEW/zFvmGGXzcUsTOiZ9fLMrHk8roBS Kxi75k0TdGV0WSzvmeinjjINvYbeGwZem0wkg7gkgaVfaRz8Sx561+9Z8UJAp+2k3teFZ7rj dSfwGz+0O+uUVmz7ScjQIBc3VNPgrNOKYBEoKG9mESwi2ErTKye1yanw/SS3FkgWpE0qBGv0 SEX7iuZrA5kEvZH1BtaRVyfoSW1V1v2rsxKU6zfyoyTk+A5NmLJVXC2JPPWdGBfSJJp4bAX7 XLSLwSfhLI5JDWVNU7+ObAXbyslMenivdWzBdkISWquSyFFcdPttB1WN+eWlOzYQOi/JIsSe vAEO1Y6P/XDzjoc3TR7B2fTOt2ykJHFrdRLZFMaHRJqEalrHnvEjDN8U6zSyNAn2bVMWYCY0 V/p8GLvLZjPSFz4/3bXi3cfmqts3YwcB++58HJvNdbsVf757349jfyv+evf+ff9N/EkaFKRH jFlZZ6zQYO3aAkIIHOgWf60PanmtpKF1vUKh5WBciMPzGpQ+Bs2jb6drl+T68YQGPVCkp5D9 c3/3NHRXPHY6U8FK2SRhFF+UlcBVBHy47AZxPtx0vLTXhrBXxyT/b+Knw9jctMuxYV9Kr0VG zjkIc4Cae7mwX7/XfwUYAAab8sINZW5kc3RyZWFtDWVuZG9iag00NzggMCBvYmoNNTQxNiAN ZW5kb2JqDTQ3OSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTc1OCAwIFIgDS9S ZXNvdXJjZXMgPDwgL0NvbG9yU3BhY2UgPDwgL0NTMiAxNzcwIDAgUiAvQ1MzIDE3NzIgMCBS ID4+IC9FeHRHU3RhdGUgPDwgL0dTMiAxNzkzIDAgUiAvR1MzIDE3OTQgMCBSID4+IA0vRm9u dCA8PCAvVFQ0IDE3NjggMCBSIC9UVDUgMTc2NyAwIFIgL0MyXzEgNDg1IDAgUiAvVFQ2IDE3 ODQgMCBSIC9UVDcgMTc3MyAwIFIgPj4gDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdID4+IA0v Q29udGVudHMgNDgwIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3gg WyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDS9TdHJ1Y3RQYXJlbnRzIDExIA0+PiANZW5k b2JqDTQ4MCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDQ4MSAwIFIg Pj4gDXN0cmVhbQ0KSImkV9tu3EYSfddX9KMDrFrsK5uAYcNWjKwAJxHsyQYLGFhQnJaGyQyp JSkp+vuc5kiabqo4IzkOYMvOqWJ1XU6dOjlnb9+e/Hx69iPL2Lt3H388PTo5/SpZ1ePv4T/W V82RYDU7Ovni1+VQ3/rTdt129cYPXV2xrj46+QkGV/3Rx8XRyWKhmWCLy6PjjGdZptiiYuOP Ev96xwR+lKPf7U+u4AV+sRx/zW2m2WJz9Oas+cNXQ91csesfFn8cTW2EMtxYq1Kjm4t1TaKN 4JmTKbiikZYLOUGyP/09uyzXvWeVp6ykENzaTKRm3VBf1lU50CZacZfbyat7Gup4IaZQNrTs 7Jydr9rG999kZliw/bQ4+vQzyrerqHioaFKYLJQk21cMWxRc6sdv0a4l5XpbaL3Xt8t57hBx 8L0ouyuyEvjD6HyC9mNLDCsypyIkKsttarLLEivJ9GYouclTo2bJmnYIH2I9XT+reGFzk5p1 t77bVww1U4w9ucotl3Z/HTTlddah1Tw/UFjzKodGcen2O7SJQ/Pw7kAO8okcwo/Iw8MnJCsy ZnXGrcNcBddf/P9vfD+giijOoiubvh620/5kIjPBC5fL1PDWA37TDzOx5bNdfJC5QojSoT5b yhpY3bO+ZU1debTOLBPlrojtym2fVW3T0P2JQVAiMQnU2Dbssms37GO9bv+qeYUfQQkX7QXl RMG20MbGTthdvV6zC8/KdUf2uMrDPEmTBLskkaEZnEuQ96y99o0n8VoJLpCLGL9nbBw5NpMK 5XMVEhYNP37i9xVyPb6aLo5yXAUaj0xIyhAg70I5FQPpNaULjqzrBOgbVl+i5GiWqqUrbrgV WsZWTUPTkJRh+GwM3fbGXdkzmrgC0BSxxeDLzi8ZXdpM4QnpF8aos13qSbZXWcGzwFyR4V2D +djQzYZUZblKcroi04MScWFl6vg9W9CNKXiOnZB4pYE5au9cDESBNp5sAA2Qy9KkkMOrUR+M UeK2n+EGjfbTRiWVQb9+bC+2PVuu78r7bVG39GSfKiDcXPOjlaQbXV34kWbqBrRZji3SXo7/ 4puqu78e0ACLz1/ZcINWW3P28WaIPiV2xVZ0sbGmVJHHH7xbkblTUkO6iRg50DhURAb22QEf hre8vp4hLP2gGXYmu2HbvmwcjLDbO191viQ/bTJ8usiT1yA9u3ToXTpmEm8KBa22reGTmEAQ ZzRN5FzkzsZWv9DrQ3OtsOAi4H/OFp9Y42miDRsREsLFBv24Jzxb+jWEfBj87d54P8O+xesU ZHi8k6Ebin2SQGT/hNRNDim8LcyHzrM7z2gRKQP/KhnjSU4J90SmhI6BQWnO7XCRhWrtsMjg qoTQWCGfNO2CDXWB4Y6MSnQFrWShvHlW5CpGdyhYQ5430iL4vEiCp6Uu/r8pIFoj4JoGSu5E 8sLj9vK4990tGYHKoBRwj8UG5H2lBDYndHMM9HONJ155u4S+MDhbzIHOI++WHaNSbjGg22B/ mnM6J+1pfwp0mR8I80WyPjgDoeaH3mxmFfiO2jPxTIEbgUmWo+dz77vjoT0Of4I8H8T4zOfs Pxlujdtzm+3/tjdsE6T7BT1V48WnIBp2Jn/WyyXZo8JiAsOhtsNiwDeedfRQgfoNtvAOfbUa Zjt1zxGxu3Dk3LLQzj2umcXIIHVYUfS5Gp6MF7vY6IamKYyawN0QAUE3zVBX4/qfezSYRMU2 QZeTWAFskWLH22zcc3RODcZIySSknmY08E+eArH7l57RgrnA3od4jOGQ2XyuWvQ9sY9XdG4P zxi5KCln4Gu1z5Mkd+PL2wmVzx/ZZbx5SvIoFFBYUmIdJAYthN9vH4Im+O3De/bvsNWwXi/b jtyw0qBSQbSmPobBb6U+moHeAzArZGrVXL2nhWABVYdrKwHPpe71O0NreXBnSHJnUM4U9lpx wBm5Kyhnoji4JuRL14SGqD3UwtK80JkqsMAOPZNcApQzpw/XNZ9dYM/OIPX0BfX4hVxwtb2o fn04viYgIQQ3CodaBPU0MOfWyhjXPaj6KRKtoB2ukQja0EC4dCoBDvTHgw5R2KHx17GHa9pv 7lBxlcfoK3be1hRYoj10aI9D0UqhuTU2CXZOB8jXM60yDsnY2woxz57K/4mIHqWmFBfUOlPh xhoPoLdZhhxCibwLrxthrK+aEKCNAnzy9zxMIQ1UbMjVk9M3H3CYtg+X5u9nnz+zX35dsGuS MqHXCq3z2LqjgVj1mdYxkD4XlOIObmPgLQ103FlM+UGPWnMVxFIEpBWDLqD8cQxFQOwb1tfD zSgzSN2GFsbW0Cq2ugvCp21ooRdweZqJqiQDUhautZIxlG1IZK65c2kQZXO19j3rSJmhheWZ KJIobjB742LMkkbSz3qS7HeNyQdDJNnj7Ayrk/w+jhsjknhJ5Rf0RVaIJAXVCkUJ4OOpChf7 O1wZbtUDN++KuiL1BBgBR6BKjWgVmyMyrSfQW+QSYV53dE9KEdI/sTmeGzGVT6IfynpNy0cI AFtkE8edX7KvZ+fsvGv/uof4HB4z+KyPcMwJOTW/Ldf1klW+G+rLoLihour1mm4rHDHZNBfs qobyKhtWDkNZ/YmbC+KdbTvtpeyELIgtlZYX9boe7oOqu/YdxNwGj9nQEySxt6DoXGxPZznQ TlGYGFjPsITgVsvEI55zvKHPhFxi2J2I4cvlGtkYaDIBXKTvDSn7F5thCAxdHq6Q2P1YHbq8 uEUswonhLa4LJPDWkx/QELfCQP5EFvSgihBJlrgmW19LxaV2CTBIclYi6NAXLX7rovk+dCXs egSx2kdVuG21Hh7DzUDOrTNcQ0WmduT2ErjFnDJ5CvXsm5SK3ovZSK9i4tsjy8PM2isw5SF9 scFybp855yZQhKJptAvpNima1Zds8fkrw4K/8PRVg7UmiqkdOO2m98u5a1SRx95+jZQJLtR+ wazE96gk6Qo0+9bzHp2UXKRi12tqb6/Fzt8s6g3aFrfmNb1shcMQKSFSK/qOdRgjLLwUuvab nhxoGaS+cTqFjwQfRimUuGppGnPoUO0mL6GhBRgPR0uCpLu4GFfhxGk1x3TCTaFPKiuSIM8s sTtFEBqJ5bc3kKs0RUJByLQd3vSzG0wZi8VlJ69lZQW5sF7fY1wYvRdGArRiEtbgo5vmmQbC cjK5SS2uwmK7K4dq9e2H2TmTr5uzcRxwQQlzYNDUdw2atU+7Phm06XS9WKnFHt+cNdHGv2mW vuuHslkyWv8otFWBqyBxQZ8kaAxjEEkCDfMydO12Fd22M9wYVIVNXz7X5vhIbidP8qxazS10 4LGiU3zj6V4Ft4c5SOIvL+m2xm1TiEnIw4MUqzoftDC9rjFtYvqAhrNFuA43nlytOlccUnJS BXoI0JbOmAmUvhlc0GhTr9sNj332HYpBGhOo5IE1PetXIPElzeG4sJQO453YkG8KJJ4VobNi 7JjpL4tzSLmZvY6o3CQoGJyez3cLGlFrObGZgcK7nYREkrgKO0UVE+i6jxKsdwmm8hsYGpLB pB6CrPN/c14tu23DQPBXdCpykkmKpKhb7KKHAgUa9HFKchBc1RGSSIYiNPHfd1aKZVFYMnHu w+VyuTM7S44jsOuSUV4+hf0KMC/FFcvyNu3renKcIVwrW0ind4xWk4aUBftRUG71eXLriGtU QJ3NLFcgtjlfcvN0aN5B6qKyu/wsF2GDF+9igyZ9ZsVPGhAWt/l4tqOlBWec1T6Ulk9+9o6O XC/wPB3hSYQhnZ9DtyEVU7TG5PkCzrsdmuPGWB+a3FwEFrwMb7TkF+bwpycerC2NnEWtYarL gL2DjiIX5eOfq4eHiDewH2xWJWZ+JxA752IHI4qCHIeLRnTnRJTwl7Z4I8firIiwwdCCaI6a 3WqCETEo7Buv1pKLOHAUE+ZIV8HSdbrHZqeW+Pq4hy1iiYJvxeLqoXlGKVRCu0XgBoxqBkta NgfSSL5PhcboMto/+6XpybUFSsBa2LEEjkoAByFtvAJGUse+VjqUG/aR1FlhffhV174EU8uC qY3WglIz7OSbUtNi1vqx1ArhnA//1kZm2CCRoIB/5GfV/au3Veg97PgaS62nUuvoe5Qj4r2n 1LmyPvxHtav51szhXmj/8eA9D81SJWGOPGhXdqEnm/CTDTdUp4dC/eU7e8r56N/rUDIfVGQJ ywYlyaNKcpYiF5rYyUjTuoN3wo5LcX8d9lWyuip3dTP24Wrd9+X2rvqTXK82bd+3j8ntarNp X5Jrhe/QatgvsLag6hj3mMvCJE6lqsBycjtPL+fTy8DOXCHQKTEOYrGJaISeQCMlh/8MetEp Q40aKCGH05/b/aGrd3eslpFpEbBl8wN9cqMMTTQAvv+tu2Td3dc8QzPYeKEwhebnPyWXWFrv q1PaMg/+P25PrYVvy9Drxwe7+X/9F2AAz1V3LQ1lbmRzdHJlYW0NZW5kb2JqDTQ4MSAwIG9i ag0zMzEwIA1lbmRvYmoNNDgyIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxNzU4 IDAgUiANL1Jlc291cmNlcyA8PCAvQ29sb3JTcGFjZSA8PCAvQ1MyIDE3NzAgMCBSIC9DUzMg MTc3MiAwIFIgPj4gL0V4dEdTdGF0ZSA8PCAvR1MyIDE3OTMgMCBSIC9HUzMgMTc5NCAwIFIg Pj4gDS9Gb250IDw8IC9UVDIgMTc2OCAwIFIgL1RUMyAxNzczIDAgUiA+PiAvUHJvY1NldCBb IC9QREYgL1RleHQgXSA+PiANL0NvbnRlbnRzIDQ4MyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2 MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0vU3RydWN0 UGFyZW50cyAxMiANPj4gDWVuZG9iag00ODMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgL0xlbmd0aCA0ODQgMCBSID4+IA1zdHJlYW0NCkiJfJFNT8MwDIbv+RU+ITiQzyZtpWli 7SbEYWKC3MYOVdduYV0ztRFj/550FYOhiuQQW/Jr+3lDFjAakXn6NAUK43EyTRFJXznkrc+7 C21eIwYGEHkpqsyZjyK1lW3MvnCNyaExiDx6waZFiUZEaw4MdInuKaaUKtA5nEMWgT4C8yE/ 9+2jKMaxPxD6NFQ0AL1Ht3PbFGDWRdbe6Xf0V8JEjCULxbUGnIXSVpU9QieaaTSbe5RJ40yZ 5a6D1KdDAWSRbUztMWwNZOJclm+LNSxJYp2ze1iRJLGfsOQ8wgH304TEUgUSRKQwlVRCxDGP YwWr3qyeWfTMtKOlQ5zCOxFy37JfdoirK1EMs8APuRT1LspzXx/xod6XXQNvJqfsrE7t4dSY zXZoElcBFlTIK4GDNy4Z8G7Ic2kamDQ7Uw9vGkj/iPhKfwMPrct2xc/aLPzHDoFV93Uiwuob OP79c18CDAAVe5lEDWVuZHN0cmVhbQ1lbmRvYmoNNDg0IDAgb2JqDTM1OSANZW5kb2JqDTQ4 NSAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMCANL0Jhc2VGb250IC9D TE1LT0YrV2luZ2RpbmdzLVJlZ3VsYXIgDS9FbmNvZGluZyAvSWRlbnRpdHktSCANL0Rlc2Nl bmRhbnRGb250cyBbIDEzNDYgMCBSIF0gDS9Ub1VuaWNvZGUgMTM0NyAwIFIgDT4+IA1lbmRv YmoNNDg2IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQgOTE1IDAgUiANXQ1lbmRvYmoN NDg3IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQgOTE2IDAgUiANXQ1lbmRvYmoNNDg4 IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDMgOTE3IDAgUiANXQ1lbmRvYmoNNDg5IDAg b2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIgOTE4IDAgUiANXQ1lbmRvYmoNNDkwIDAgb2Jq DVsgDS9JbmRleGVkIDE3NzAgMCBSIDMgOTE5IDAgUiANXQ1lbmRvYmoNNDkxIDAgb2JqDVsg DS9JbmRleGVkIDE3NzAgMCBSIDIgOTIwIDAgUiANXQ1lbmRvYmoNNDkyIDAgb2JqDVsgDS9J bmRleGVkIDE3NzAgMCBSIDYgOTIxIDAgUiANXQ1lbmRvYmoNNDkzIDAgb2JqDVsgDS9JbmRl eGVkIDE3NzAgMCBSIDIgOTIyIDAgUiANXQ1lbmRvYmoNNDk0IDAgb2JqDVsgDS9JbmRleGVk IDE3NzAgMCBSIDQgOTIzIDAgUiANXQ1lbmRvYmoNNDk1IDAgb2JqDVsgDS9JbmRleGVkIDE3 NzAgMCBSIDMgOTI0IDAgUiANXQ1lbmRvYmoNNDk2IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAg MCBSIDUgOTI1IDAgUiANXQ1lbmRvYmoNNDk3IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBS IDEgOTI2IDAgUiANXQ1lbmRvYmoNNDk4IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDYg OTI3IDAgUiANXQ1lbmRvYmoNNDk5IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIgOTI4 IDAgUiANXQ1lbmRvYmoNNTAwIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDUgOTI5IDAg UiANXQ1lbmRvYmoNNTAxIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIgOTMwIDAgUiAN XQ1lbmRvYmoNNTAyIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDYgOTMxIDAgUiANXQ1l bmRvYmoNNTAzIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDMgOTMyIDAgUiANXQ1lbmRv YmoNNTA0IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDYgOTMzIDAgUiANXQ1lbmRvYmoN NTA1IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIgOTM0IDAgUiANXQ1lbmRvYmoNNTA2 IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDcgOTM1IDAgUiANXQ1lbmRvYmoNNTA3IDAg b2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDMgOTM2IDAgUiANXQ1lbmRvYmoNNTA4IDAgb2Jq DVsgDS9JbmRleGVkIDE3NzAgMCBSIDggOTM3IDAgUiANXQ1lbmRvYmoNNTA5IDAgb2JqDVsg DS9JbmRleGVkIDE3NzAgMCBSIDkgOTM4IDAgUiANXQ1lbmRvYmoNNTEwIDAgb2JqDVsgDS9J bmRleGVkIDE3NzAgMCBSIDkgOTM5IDAgUiANXQ1lbmRvYmoNNTExIDAgb2JqDVsgDS9JbmRl eGVkIDE3NzAgMCBSIDkgOTQwIDAgUiANXQ1lbmRvYmoNNTEyIDAgb2JqDVsgDS9JbmRleGVk IDE3NzAgMCBSIDEwIDk0MSAwIFIgDV0NZW5kb2JqDTUxMyAwIG9iag1bIA0vSW5kZXhlZCAx NzcwIDAgUiAxMCA5NDIgMCBSIA1dDWVuZG9iag01MTQgMCBvYmoNWyANL0luZGV4ZWQgMTc3 MCAwIFIgMTIgOTQzIDAgUiANXQ1lbmRvYmoNNTE1IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAg MCBSIDEwIDk0NCAwIFIgDV0NZW5kb2JqDTUxNiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAg UiAxMyA5NDUgMCBSIA1dDWVuZG9iag01MTcgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIg MTIgOTQ2IDAgUiANXQ1lbmRvYmoNNTE4IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDEx IDk0NyAwIFIgDV0NZW5kb2JqDTUxOSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxMiA5 NDggMCBSIA1dDWVuZG9iag01MjAgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTQgOTQ5 IDAgUiANXQ1lbmRvYmoNNTIxIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDEzIDk1MCAw IFIgDV0NZW5kb2JqDTUyMiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxNSA5NTEgMCBS IA1dDWVuZG9iag01MjMgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTUgOTUyIDAgUiAN XQ1lbmRvYmoNNTI0IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDE1IDk1MyAwIFIgDV0N ZW5kb2JqDTUyNSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxNyA5NTQgMCBSIA1dDWVu ZG9iag01MjYgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTcgOTU1IDAgUiANXQ1lbmRv YmoNNTI3IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDE4IDk1NiAwIFIgDV0NZW5kb2Jq DTUyOCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxOCA5NTcgMCBSIA1dDWVuZG9iag01 MjkgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTkgOTU4IDAgUiANXQ1lbmRvYmoNNTMw IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDE5IDk1OSAwIFIgDV0NZW5kb2JqDTUzMSAw IG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxOSA5NjAgMCBSIA1dDWVuZG9iag01MzIgMCBv YmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMjEgOTYxIDAgUiANXQ1lbmRvYmoNNTMzIDAgb2Jq DVsgDS9JbmRleGVkIDE3NzAgMCBSIDIyIDk2MiAwIFIgDV0NZW5kb2JqDTUzNCAwIG9iag1b IA0vSW5kZXhlZCAxNzcwIDAgUiAyMyA5NjMgMCBSIA1dDWVuZG9iag01MzUgMCBvYmoNWyAN L0luZGV4ZWQgMTc3MCAwIFIgMjQgOTY0IDAgUiANXQ1lbmRvYmoNNTM2IDAgb2JqDVsgDS9J bmRleGVkIDE3NzAgMCBSIDIzIDk2NSAwIFIgDV0NZW5kb2JqDTUzNyAwIG9iag1bIA0vSW5k ZXhlZCAxNzcwIDAgUiAyMyA5NjYgMCBSIA1dDWVuZG9iag01MzggMCBvYmoNWyANL0luZGV4 ZWQgMTc3MCAwIFIgMjMgOTY3IDAgUiANXQ1lbmRvYmoNNTM5IDAgb2JqDVsgDS9JbmRleGVk IDE3NzAgMCBSIDI0IDk2OCAwIFIgDV0NZW5kb2JqDTU0MCAwIG9iag1bIA0vSW5kZXhlZCAx NzcwIDAgUiAyMyA5NjkgMCBSIA1dDWVuZG9iag01NDEgMCBvYmoNWyANL0luZGV4ZWQgMTc3 MCAwIFIgMjQgOTcwIDAgUiANXQ1lbmRvYmoNNTQyIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAg MCBSIDI1IDk3MSAwIFIgDV0NZW5kb2JqDTU0MyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAg UiAyNiA5NzIgMCBSIA1dDWVuZG9iag01NDQgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIg MjYgOTczIDAgUiANXQ1lbmRvYmoNNTQ1IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDI3 IDk3NCAwIFIgDV0NZW5kb2JqDTU0NiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAyNiA5 NzUgMCBSIA1dDWVuZG9iag01NDcgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMjggOTc2 IDAgUiANXQ1lbmRvYmoNNTQ4IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDI5IDk3NyAw IFIgDV0NZW5kb2JqDTU0OSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAyOSA5NzggMCBS IA1dDWVuZG9iag01NTAgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzAgOTc5IDAgUiAN XQ1lbmRvYmoNNTUxIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDMxIDk4MCAwIFIgDV0N ZW5kb2JqDTU1MiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzMiA5ODEgMCBSIA1dDWVu ZG9iag01NTMgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzAgOTgyIDAgUiANXQ1lbmRv YmoNNTU0IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDMxIDk4MyAwIFIgDV0NZW5kb2Jq DTU1NSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzMiA5ODQgMCBSIA1dDWVuZG9iag01 NTYgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzMgOTg1IDAgUiANXQ1lbmRvYmoNNTU3 IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDM0IDk4NiAwIFIgDV0NZW5kb2JqDTU1OCAw IG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzNSA5ODcgMCBSIA1dDWVuZG9iag01NTkgMCBv YmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzIgOTg4IDAgUiANXQ1lbmRvYmoNNTYwIDAgb2Jq DVsgDS9JbmRleGVkIDE3NzAgMCBSIDMzIDk4OSAwIFIgDV0NZW5kb2JqDTU2MSAwIG9iag1b IA0vSW5kZXhlZCAxNzcwIDAgUiAzNiA5OTAgMCBSIA1dDWVuZG9iag01NjIgMCBvYmoNWyAN L0luZGV4ZWQgMTc3MCAwIFIgMzUgOTkxIDAgUiANXQ1lbmRvYmoNNTYzIDAgb2JqDVsgDS9J bmRleGVkIDE3NzAgMCBSIDM3IDk5MiAwIFIgDV0NZW5kb2JqDTU2NCAwIG9iag1bIA0vSW5k ZXhlZCAxNzcwIDAgUiAzNSA5OTMgMCBSIA1dDWVuZG9iag01NjUgMCBvYmoNWyANL0luZGV4 ZWQgMTc3MCAwIFIgMzcgOTk0IDAgUiANXQ1lbmRvYmoNNTY2IDAgb2JqDVsgDS9JbmRleGVk IDE3NzAgMCBSIDM3IDk5NSAwIFIgDV0NZW5kb2JqDTU2NyAwIG9iag1bIA0vSW5kZXhlZCAx NzcwIDAgUiAzOSA5OTYgMCBSIA1dDWVuZG9iag01NjggMCBvYmoNWyANL0luZGV4ZWQgMTc3 MCAwIFIgMzkgOTk3IDAgUiANXQ1lbmRvYmoNNTY5IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAg MCBSIDM4IDk5OCAwIFIgDV0NZW5kb2JqDTU3MCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAg UiA0MiA5OTkgMCBSIA1dDWVuZG9iag01NzEgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIg MzggMTAwMCAwIFIgDV0NZW5kb2JqDTU3MiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA0 MSAxMDAxIDAgUiANXQ1lbmRvYmoNNTczIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQy IDEwMDIgMCBSIA1dDWVuZG9iag01NzQgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNDIg MTAwMyAwIFIgDV0NZW5kb2JqDTU3NSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA0MiAx MDA0IDAgUiANXQ1lbmRvYmoNNTc2IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQ1IDEw MDUgMCBSIA1dDWVuZG9iag01NzcgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNDUgMTAw NiAwIFIgDV0NZW5kb2JqDTU3OCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA0NCAxMDA3 IDAgUiANXQ1lbmRvYmoNNTc5IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQzIDEwMDgg MCBSIA1dDWVuZG9iag01ODAgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNDUgMTAwOSAw IFIgDV0NZW5kb2JqDTU4MSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA0MyAxMDEwIDAg UiANXQ1lbmRvYmoNNTgyIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQ1IDEwMTEgMCBS IA1dDWVuZG9iag01ODMgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNDMgMTAxMiAwIFIg DV0NZW5kb2JqDTU4NCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA0MiAxMDEzIDAgUiAN XQ1lbmRvYmoNNTg1IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQzIDEwMTQgMCBSIA1d DWVuZG9iag01ODYgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNDAgMTAxNSAwIFIgDV0N ZW5kb2JqDTU4NyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA0MCAxMDE2IDAgUiANXQ1l bmRvYmoNNTg4IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQxIDEwMTcgMCBSIA1dDWVu ZG9iag01ODkgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNDAgMTAxOCAwIFIgDV0NZW5k b2JqDTU5MCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzOCAxMDE5IDAgUiANXQ1lbmRv YmoNNTkxIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQwIDEwMjAgMCBSIA1dDWVuZG9i ag01OTIgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzkgMTAyMSAwIFIgDV0NZW5kb2Jq DTU5MyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzNiAxMDIyIDAgUiANXQ1lbmRvYmoN NTk0IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDM3IDEwMjMgMCBSIA1dDWVuZG9iag01 OTUgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzUgMTAyNCAwIFIgDV0NZW5kb2JqDTU5 NiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzNCAxMDI1IDAgUiANXQ1lbmRvYmoNNTk3 IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDM0IDEwMjYgMCBSIA1dDWVuZG9iag01OTgg MCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzMgMTAyNyAwIFIgDV0NZW5kb2JqDTU5OSAw IG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzMyAxMDI4IDAgUiANXQ1lbmRvYmoNNjAwIDAg b2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDMzIDEwMjkgMCBSIA1dDWVuZG9iag02MDEgMCBv YmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzIgMTAzMCAwIFIgDV0NZW5kb2JqDTYwMiAwIG9i ag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzMiAxMDMxIDAgUiANXQ1lbmRvYmoNNjAzIDAgb2Jq DVsgDS9JbmRleGVkIDE3NzAgMCBSIDMyIDEwMzIgMCBSIA1dDWVuZG9iag02MDQgMCBvYmoN WyANL0luZGV4ZWQgMTc3MCAwIFIgMzEgMTAzMyAwIFIgDV0NZW5kb2JqDTYwNSAwIG9iag1b IA0vSW5kZXhlZCAxNzcwIDAgUiAyOCAxMDM0IDAgUiANXQ1lbmRvYmoNNjA2IDAgb2JqDVsg DS9JbmRleGVkIDE3NzAgMCBSIDI5IDEwMzUgMCBSIA1dDWVuZG9iag02MDcgMCBvYmoNWyAN L0luZGV4ZWQgMTc3MCAwIFIgMzAgMTAzNiAwIFIgDV0NZW5kb2JqDTYwOCAwIG9iag1bIA0v SW5kZXhlZCAxNzcwIDAgUiAyOSAxMDM3IDAgUiANXQ1lbmRvYmoNNjA5IDAgb2JqDVsgDS9J bmRleGVkIDE3NzAgMCBSIDI5IDEwMzggMCBSIA1dDWVuZG9iag02MTAgMCBvYmoNWyANL0lu ZGV4ZWQgMTc3MCAwIFIgMjYgMTAzOSAwIFIgDV0NZW5kb2JqDTYxMSAwIG9iag1bIA0vSW5k ZXhlZCAxNzcwIDAgUiAyNiAxMDQwIDAgUiANXQ1lbmRvYmoNNjEyIDAgb2JqDVsgDS9JbmRl eGVkIDE3NzAgMCBSIDI2IDEwNDEgMCBSIA1dDWVuZG9iag02MTMgMCBvYmoNWyANL0luZGV4 ZWQgMTc3MCAwIFIgMjUgMTA0MiAwIFIgDV0NZW5kb2JqDTYxNCAwIG9iag1bIA0vSW5kZXhl ZCAxNzcwIDAgUiAyNCAxMDQzIDAgUiANXQ1lbmRvYmoNNjE1IDAgb2JqDVsgDS9JbmRleGVk IDE3NzAgMCBSIDI0IDEwNDQgMCBSIA1dDWVuZG9iag02MTYgMCBvYmoNWyANL0luZGV4ZWQg MTc3MCAwIFIgMjIgMTA0NSAwIFIgDV0NZW5kb2JqDTYxNyAwIG9iag1bIA0vSW5kZXhlZCAx NzcwIDAgUiAyMyAxMDQ2IDAgUiANXQ1lbmRvYmoNNjE4IDAgb2JqDVsgDS9JbmRleGVkIDE3 NzAgMCBSIDIzIDEwNDcgMCBSIA1dDWVuZG9iag02MTkgMCBvYmoNWyANL0luZGV4ZWQgMTc3 MCAwIFIgMjIgMTA0OCAwIFIgDV0NZW5kb2JqDTYyMCAwIG9iag1bIA0vSW5kZXhlZCAxNzcw IDAgUiAyMSAxMDQ5IDAgUiANXQ1lbmRvYmoNNjIxIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAg MCBSIDIyIDEwNTAgMCBSIA1dDWVuZG9iag02MjIgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAw IFIgMjEgMTA1MSAwIFIgDV0NZW5kb2JqDTYyMyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAg UiAyMCAxMDUyIDAgUiANXQ1lbmRvYmoNNjI0IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBS IDE3IDEwNTMgMCBSIA1dDWVuZG9iag02MjUgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIg MTcgMTA1NCAwIFIgDV0NZW5kb2JqDTYyNiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAx OSAxMDU1IDAgUiANXQ1lbmRvYmoNNjI3IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDE3 IDEwNTYgMCBSIA1dDWVuZG9iag02MjggMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTYg MTA1NyAwIFIgDV0NZW5kb2JqDTYyOSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxNSAx MDU4IDAgUiANXQ1lbmRvYmoNNjMwIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDE2IDEw NTkgMCBSIA1dDWVuZG9iag02MzEgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTUgMTA2 MCAwIFIgDV0NZW5kb2JqDTYzMiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxMyAxMDYx IDAgUiANXQ1lbmRvYmoNNjMzIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDEzIDEwNjIg MCBSIA1dDWVuZG9iag02MzQgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTIgMTA2MyAw IFIgDV0NZW5kb2JqDTYzNSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxMiAxMDY0IDAg UiANXQ1lbmRvYmoNNjM2IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDEzIDEwNjUgMCBS IA1dDWVuZG9iag02MzcgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTIgMTA2NiAwIFIg DV0NZW5kb2JqDTYzOCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxMSAxMDY3IDAgUiAN XQ1lbmRvYmoNNjM5IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDExIDEwNjggMCBSIA1d DWVuZG9iag02NDAgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTEgMTA2OSAwIFIgDV0N ZW5kb2JqDTY0MSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA5IDEwNzAgMCBSIA1dDWVu ZG9iag02NDIgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTEgMTA3MSAwIFIgDV0NZW5k b2JqDTY0MyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA4IDEwNzIgMCBSIA1dDWVuZG9i ag02NDQgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgOCAxMDczIDAgUiANXQ1lbmRvYmoN NjQ1IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDcgMTA3NCAwIFIgDV0NZW5kb2JqDTY0 NiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA4IDEwNzUgMCBSIA1dDWVuZG9iag02NDcg MCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNyAxMDc2IDAgUiANXQ1lbmRvYmoNNjQ4IDAg b2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDggMTA3NyAwIFIgDV0NZW5kb2JqDTY0OSAwIG9i ag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzIDEwNzggMCBSIA1dDWVuZG9iag02NTAgMCBvYmoN WyANL0luZGV4ZWQgMTc3MCAwIFIgNyAxMDc5IDAgUiANXQ1lbmRvYmoNNjUxIDAgb2JqDVsg DS9JbmRleGVkIDE3NzAgMCBSIDIgMTA4MCAwIFIgDV0NZW5kb2JqDTY1MiAwIG9iag1bIA0v SW5kZXhlZCAxNzcwIDAgUiA3IDEwODEgMCBSIA1dDWVuZG9iag02NTMgMCBvYmoNWyANL0lu ZGV4ZWQgMTc3MCAwIFIgMiAxMDgyIDAgUiANXQ1lbmRvYmoNNjU0IDAgb2JqDVsgDS9JbmRl eGVkIDE3NzAgMCBSIDYgMTA4MyAwIFIgDV0NZW5kb2JqDTY1NSAwIG9iag1bIA0vSW5kZXhl ZCAxNzcwIDAgUiA0IDEwODQgMCBSIA1dDWVuZG9iag02NTYgMCBvYmoNWyANL0luZGV4ZWQg MTc3MCAwIFIgMiAxMDg1IDAgUiANXQ1lbmRvYmoNNjU3IDAgb2JqDVsgDS9JbmRleGVkIDE3 NzAgMCBSIDQgMTA4NiAwIFIgDV0NZW5kb2JqDTY1OCAwIG9iag1bIA0vSW5kZXhlZCAxNzcw IDAgUiAxIDEwODcgMCBSIA1dDWVuZG9iag02NTkgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAw IFIgNCAxMDg4IDAgUiANXQ1lbmRvYmoNNjYwIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBS IDMgMTA4OSAwIFIgDV0NZW5kb2JqDTY2MSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAz IDEwOTAgMCBSIA1dDWVuZG9iag02NjIgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMiAx MDkxIDAgUiANXQ1lbmRvYmoNNjYzIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQgMTA5 MiAwIFIgDV0NZW5kb2JqDTY2NCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAyIDEwOTMg MCBSIA1dDWVuZG9iag02NjUgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMyAxMDk0IDAg UiANXQ1lbmRvYmoNNjY2IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIgMTA5NSAwIFIg DV0NZW5kb2JqDTY2NyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzIDEwOTYgMCBSIA1d DWVuZG9iag02NjggMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMyAxMDk3IDAgUiANXQ1l bmRvYmoNNjY5IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQgMTA5OCAwIFIgDV0NZW5k b2JqDTY3MCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzIDEwOTkgMCBSIA1dDWVuZG9i ag02NzEgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMyAxMTAwIDAgUiANXQ1lbmRvYmoN NjcyIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDMgMTEwMSAwIFIgDV0NZW5kb2JqDTY3 MyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAyIDExMDIgMCBSIA1dDWVuZG9iag02NzQg MCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMiAxMTAzIDAgUiANXQ1lbmRvYmoNNjc1IDAg b2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIgMTEwNCAwIFIgDV0NZW5kb2JqDTY3NiAwIG9i ag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzIDExMDUgMCBSIA1dDWVuZG9iag02NzcgMCBvYmoN WyANL0luZGV4ZWQgMTc3MCAwIFIgMiAxMTA2IDAgUiANXQ1lbmRvYmoNNjc4IDAgb2JqDVsg DS9JbmRleGVkIDE3NzAgMCBSIDMgMTEwNyAwIFIgDV0NZW5kb2JqDTY3OSAwIG9iag1bIA0v SW5kZXhlZCAxNzcwIDAgUiAzIDExMDggMCBSIA1dDWVuZG9iag02ODAgMCBvYmoNWyANL0lu ZGV4ZWQgMTc3MCAwIFIgMyAxMTA5IDAgUiANXQ1lbmRvYmoNNjgxIDAgb2JqDVsgDS9JbmRl eGVkIDE3NzAgMCBSIDIgMTExMCAwIFIgDV0NZW5kb2JqDTY4MiAwIG9iag1bIA0vSW5kZXhl ZCAxNzcwIDAgUiAyIDExMTEgMCBSIA1dDWVuZG9iag02ODMgMCBvYmoNWyANL0luZGV4ZWQg MTc3MCAwIFIgMiAxMTEyIDAgUiANXQ1lbmRvYmoNNjg0IDAgb2JqDVsgDS9JbmRleGVkIDE3 NzAgMCBSIDIgMTExMyAwIFIgDV0NZW5kb2JqDTY4NSAwIG9iag1bIA0vSW5kZXhlZCAxNzcw IDAgUiAxIDExMTQgMCBSIA1dDWVuZG9iag02ODYgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAw IFIgMyAxMTE1IDAgUiANXQ1lbmRvYmoNNjg3IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBS IDEgMTExNiAwIFIgDV0NZW5kb2JqDTY4OCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAz IDExMTcgMCBSIA1dDWVuZG9iag02ODkgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNCAx MTE4IDAgUiANXQ1lbmRvYmoNNjkwIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIgMTEx OSAwIFIgDV0NZW5kb2JqDTY5MSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzIDExMjAg MCBSIA1dDWVuZG9iag02OTIgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNCAxMTIxIDAg UiANXQ1lbmRvYmoNNjkzIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIgMTEyMiAwIFIg DV0NZW5kb2JqDTY5NCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzIDExMjMgMCBSIA1d DWVuZG9iag02OTUgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNCAxMTI0IDAgUiANXQ1l bmRvYmoNNjk2IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIgMTEyNSAwIFIgDV0NZW5k b2JqDTY5NyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzIDExMjYgMCBSIA1dDWVuZG9i ag02OTggMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNSAxMTI3IDAgUiANXQ1lbmRvYmoN Njk5IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDEgMTEyOCAwIFIgDV0NZW5kb2JqDTcw MCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA1IDExMjkgMCBSIA1dDWVuZG9iag03MDEg MCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNiAxMTMwIDAgUiANXQ1lbmRvYmoNNzAyIDAg b2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIgMTEzMSAwIFIgDV0NZW5kb2JqDTcwMyAwIG9i ag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA1IDExMzIgMCBSIA1dDWVuZG9iag03MDQgMCBvYmoN WyANL0luZGV4ZWQgMTc3MCAwIFIgOCAxMTMzIDAgUiANXQ1lbmRvYmoNNzA1IDAgb2JqDVsg DS9JbmRleGVkIDE3NzAgMCBSIDEgMTEzNCAwIFIgDV0NZW5kb2JqDTcwNiAwIG9iag1bIA0v SW5kZXhlZCAxNzcwIDAgUiA2IDExMzUgMCBSIA1dDWVuZG9iag03MDcgMCBvYmoNWyANL0lu ZGV4ZWQgMTc3MCAwIFIgNyAxMTM2IDAgUiANXQ1lbmRvYmoNNzA4IDAgb2JqDVsgDS9JbmRl eGVkIDE3NzAgMCBSIDIgMTEzNyAwIFIgDV0NZW5kb2JqDTcwOSAwIG9iag1bIA0vSW5kZXhl ZCAxNzcwIDAgUiA3IDExMzggMCBSIA1dDWVuZG9iag03MTAgMCBvYmoNWyANL0luZGV4ZWQg MTc3MCAwIFIgNyAxMTM5IDAgUiANXQ1lbmRvYmoNNzExIDAgb2JqDVsgDS9JbmRleGVkIDE3 NzAgMCBSIDIgMTE0MCAwIFIgDV0NZW5kb2JqDTcxMiAwIG9iag1bIA0vSW5kZXhlZCAxNzcw IDAgUiA3IDExNDEgMCBSIA1dDWVuZG9iag03MTMgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAw IFIgNyAxMTQyIDAgUiANXQ1lbmRvYmoNNzE0IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBS IDIgMTE0MyAwIFIgDV0NZW5kb2JqDTcxNSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA2 IDExNDQgMCBSIA1dDWVuZG9iag03MTYgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNyAx MTQ1IDAgUiANXQ1lbmRvYmoNNzE3IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDEgMTE0 NiAwIFIgDV0NZW5kb2JqDTcxOCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxMCAxMTQ3 IDAgUiANXQ1lbmRvYmoNNzE5IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDEwIDExNDgg MCBSIA1dDWVuZG9iag03MjAgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgOSAxMTQ5IDAg UiANXQ1lbmRvYmoNNzIxIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDExIDExNTAgMCBS IA1dDWVuZG9iag03MjIgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTAgMTE1MSAwIFIg DV0NZW5kb2JqDTcyMyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxMCAxMTUyIDAgUiAN XQ1lbmRvYmoNNzI0IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDEyIDExNTMgMCBSIA1d DWVuZG9iag03MjUgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTMgMTE1NCAwIFIgDV0N ZW5kb2JqDTcyNiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxMiAxMTU1IDAgUiANXQ1l bmRvYmoNNzI3IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDEzIDExNTYgMCBSIA1dDWVu ZG9iag03MjggMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTMgMTE1NyAwIFIgDV0NZW5k b2JqDTcyOSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxMyAxMTU4IDAgUiANXQ1lbmRv YmoNNzMwIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDE1IDExNTkgMCBSIA1dDWVuZG9i ag03MzEgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTUgMTE2MCAwIFIgDV0NZW5kb2Jq DTczMiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxNSAxMTYxIDAgUiANXQ1lbmRvYmoN NzMzIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDE2IDExNjIgMCBSIA1dDWVuZG9iag03 MzQgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTcgMTE2MyAwIFIgDV0NZW5kb2JqDTcz NSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxOCAxMTY0IDAgUiANXQ1lbmRvYmoNNzM2 IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDE4IDExNjUgMCBSIA1dDWVuZG9iag03Mzcg MCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTggMTE2NiAwIFIgDV0NZW5kb2JqDTczOCAw IG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxOCAxMTY3IDAgUiANXQ1lbmRvYmoNNzM5IDAg b2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDE4IDExNjggMCBSIA1dDWVuZG9iag03NDAgMCBv YmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMjAgMTE2OSAwIFIgDV0NZW5kb2JqDTc0MSAwIG9i ag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAyMSAxMTcwIDAgUiANXQ1lbmRvYmoNNzQyIDAgb2Jq DVsgDS9JbmRleGVkIDE3NzAgMCBSIDIxIDExNzEgMCBSIA1dDWVuZG9iag03NDMgMCBvYmoN WyANL0luZGV4ZWQgMTc3MCAwIFIgMTkgMTE3MiAwIFIgDV0NZW5kb2JqDTc0NCAwIG9iag1b IA0vSW5kZXhlZCAxNzcwIDAgUiAyMSAxMTczIDAgUiANXQ1lbmRvYmoNNzQ1IDAgb2JqDVsg DS9JbmRleGVkIDE3NzAgMCBSIDIyIDExNzQgMCBSIA1dDWVuZG9iag03NDYgMCBvYmoNWyAN L0luZGV4ZWQgMTc3MCAwIFIgMjIgMTE3NSAwIFIgDV0NZW5kb2JqDTc0NyAwIG9iag1bIA0v SW5kZXhlZCAxNzcwIDAgUiAyMyAxMTc2IDAgUiANXQ1lbmRvYmoNNzQ4IDAgb2JqDVsgDS9J bmRleGVkIDE3NzAgMCBSIDIyIDExNzcgMCBSIA1dDWVuZG9iag03NDkgMCBvYmoNWyANL0lu ZGV4ZWQgMTc3MCAwIFIgMjQgMTE3OCAwIFIgDV0NZW5kb2JqDTc1MCAwIG9iag1bIA0vSW5k ZXhlZCAxNzcwIDAgUiAyNSAxMTc5IDAgUiANXQ1lbmRvYmoNNzUxIDAgb2JqDVsgDS9JbmRl eGVkIDE3NzAgMCBSIDI0IDExODAgMCBSIA1dDWVuZG9iag03NTIgMCBvYmoNWyANL0luZGV4 ZWQgMTc3MCAwIFIgMjQgMTE4MSAwIFIgDV0NZW5kb2JqDTc1MyAwIG9iag1bIA0vSW5kZXhl ZCAxNzcwIDAgUiAyNiAxMTgyIDAgUiANXQ1lbmRvYmoNNzU0IDAgb2JqDVsgDS9JbmRleGVk IDE3NzAgMCBSIDI3IDExODMgMCBSIA1dDWVuZG9iag03NTUgMCBvYmoNWyANL0luZGV4ZWQg MTc3MCAwIFIgMjYgMTE4NCAwIFIgDV0NZW5kb2JqDTc1NiAwIG9iag1bIA0vSW5kZXhlZCAx NzcwIDAgUiAyNyAxMTg1IDAgUiANXQ1lbmRvYmoNNzU3IDAgb2JqDVsgDS9JbmRleGVkIDE3 NzAgMCBSIDI5IDExODYgMCBSIA1dDWVuZG9iag03NTggMCBvYmoNWyANL0luZGV4ZWQgMTc3 MCAwIFIgMjkgMTE4NyAwIFIgDV0NZW5kb2JqDTc1OSAwIG9iag1bIA0vSW5kZXhlZCAxNzcw IDAgUiAyOCAxMTg4IDAgUiANXQ1lbmRvYmoNNzYwIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAg MCBSIDI5IDExODkgMCBSIA1dDWVuZG9iag03NjEgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAw IFIgMjcgMTE5MCAwIFIgDV0NZW5kb2JqDTc2MiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAg UiAyOCAxMTkxIDAgUiANXQ1lbmRvYmoNNzYzIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBS IDMwIDExOTIgMCBSIA1dDWVuZG9iag03NjQgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIg MzIgMTE5MyAwIFIgDV0NZW5kb2JqDTc2NSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAz MCAxMTk0IDAgUiANXQ1lbmRvYmoNNzY2IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDM0 IDExOTUgMCBSIA1dDWVuZG9iag03NjcgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzEg MTE5NiAwIFIgDV0NZW5kb2JqDTc2OCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzMiAx MTk3IDAgUiANXQ1lbmRvYmoNNzY5IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDM1IDEx OTggMCBSIA1dDWVuZG9iag03NzAgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzQgMTE5 OSAwIFIgDV0NZW5kb2JqDTc3MSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzNyAxMjAw IDAgUiANXQ1lbmRvYmoNNzcyIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDM4IDEyMDEg MCBSIA1dDWVuZG9iag03NzMgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzQgMTIwMiAw IFIgDV0NZW5kb2JqDTc3NCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzOCAxMjAzIDAg UiANXQ1lbmRvYmoNNzc1IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDM5IDEyMDQgMCBS IA1dDWVuZG9iag03NzYgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzQgMTIwNSAwIFIg DV0NZW5kb2JqDTc3NyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA0MCAxMjA2IDAgUiAN XQ1lbmRvYmoNNzc4IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQwIDEyMDcgMCBSIA1d DWVuZG9iag03NzkgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNDIgMTIwOCAwIFIgDV0N ZW5kb2JqDTc4MCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzOCAxMjA5IDAgUiANXQ1l bmRvYmoNNzgxIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDM3IDEyMTAgMCBSIA1dDWVu ZG9iag03ODIgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNDIgMTIxMSAwIFIgDV0NZW5k b2JqDTc4MyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA0MSAxMjEyIDAgUiANXQ1lbmRv YmoNNzg0IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQxIDEyMTMgMCBSIA1dDWVuZG9i ag03ODUgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzkgMTIxNCAwIFIgDV0NZW5kb2Jq DTc4NiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzNyAxMjE1IDAgUiANXQ1lbmRvYmoN Nzg3IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQyIDEyMTYgMCBSIA1dDWVuZG9iag03 ODggMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNDEgMTIxNyAwIFIgDV0NZW5kb2JqDTc4 OSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA0MCAxMjE4IDAgUiANXQ1lbmRvYmoNNzkw IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDM1IDEyMTkgMCBSIA1dDWVuZG9iag03OTEg MCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzkgMTIyMCAwIFIgDV0NZW5kb2JqDTc5MiAw IG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzNiAxMjIxIDAgUiANXQ1lbmRvYmoNNzkzIDAg b2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDM2IDEyMjIgMCBSIA1dDWVuZG9iag03OTQgMCBv YmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMzYgMTIyMyAwIFIgDV0NZW5kb2JqDTc5NSAwIG9i ag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzOCAxMjI0IDAgUiANXQ1lbmRvYmoNNzk2IDAgb2Jq DVsgDS9JbmRleGVkIDE3NzAgMCBSIDMyIDEyMjUgMCBSIA1dDWVuZG9iag03OTcgMCBvYmoN WyANL0luZGV4ZWQgMTc3MCAwIFIgMzYgMTIyNiAwIFIgDV0NZW5kb2JqDTc5OCAwIG9iag1b IA0vSW5kZXhlZCAxNzcwIDAgUiAzNiAxMjI3IDAgUiANXQ1lbmRvYmoNNzk5IDAgb2JqDVsg DS9JbmRleGVkIDE3NzAgMCBSIDMyIDEyMjggMCBSIA1dDWVuZG9iag04MDAgMCBvYmoNWyAN L0luZGV4ZWQgMTc3MCAwIFIgMzUgMTIyOSAwIFIgDV0NZW5kb2JqDTgwMSAwIG9iag1bIA0v SW5kZXhlZCAxNzcwIDAgUiAzMyAxMjMwIDAgUiANXQ1lbmRvYmoNODAyIDAgb2JqDVsgDS9J bmRleGVkIDE3NzAgMCBSIDMwIDEyMzEgMCBSIA1dDWVuZG9iag04MDMgMCBvYmoNWyANL0lu ZGV4ZWQgMTc3MCAwIFIgMjggMTIzMiAwIFIgDV0NZW5kb2JqDTgwNCAwIG9iag1bIA0vSW5k ZXhlZCAxNzcwIDAgUiAzMCAxMjMzIDAgUiANXQ1lbmRvYmoNODA1IDAgb2JqDVsgDS9JbmRl eGVkIDE3NzAgMCBSIDMwIDEyMzQgMCBSIA1dDWVuZG9iag04MDYgMCBvYmoNWyANL0luZGV4 ZWQgMTc3MCAwIFIgMjggMTIzNSAwIFIgDV0NZW5kb2JqDTgwNyAwIG9iag1bIA0vSW5kZXhl ZCAxNzcwIDAgUiAyOCAxMjM2IDAgUiANXQ1lbmRvYmoNODA4IDAgb2JqDVsgDS9JbmRleGVk IDE3NzAgMCBSIDI1IDEyMzcgMCBSIA1dDWVuZG9iag04MDkgMCBvYmoNWyANL0luZGV4ZWQg MTc3MCAwIFIgMjggMTIzOCAwIFIgDV0NZW5kb2JqDTgxMCAwIG9iag1bIA0vSW5kZXhlZCAx NzcwIDAgUiAyNyAxMjM5IDAgUiANXQ1lbmRvYmoNODExIDAgb2JqDVsgDS9JbmRleGVkIDE3 NzAgMCBSIDI3IDEyNDAgMCBSIA1dDWVuZG9iag04MTIgMCBvYmoNWyANL0luZGV4ZWQgMTc3 MCAwIFIgMjMgMTI0MSAwIFIgDV0NZW5kb2JqDTgxMyAwIG9iag1bIA0vSW5kZXhlZCAxNzcw IDAgUiAyNSAxMjQyIDAgUiANXQ1lbmRvYmoNODE0IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAg MCBSIDI0IDEyNDMgMCBSIA1dDWVuZG9iag04MTUgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAw IFIgMjQgMTI0NCAwIFIgDV0NZW5kb2JqDTgxNiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAg UiAyMSAxMjQ1IDAgUiANXQ1lbmRvYmoNODE3IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBS IDIyIDEyNDYgMCBSIA1dDWVuZG9iag04MTggMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIg MjIgMTI0NyAwIFIgDV0NZW5kb2JqDTgxOSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAy MyAxMjQ4IDAgUiANXQ1lbmRvYmoNODIwIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIy IDEyNDkgMCBSIA1dDWVuZG9iag04MjEgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTkg MTI1MCAwIFIgDV0NZW5kb2JqDTgyMiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAyMCAx MjUxIDAgUiANXQ1lbmRvYmoNODIzIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIwIDEy NTIgMCBSIA1dDWVuZG9iag04MjQgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTkgMTI1 MyAwIFIgDV0NZW5kb2JqDTgyNSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxOCAxMjU0 IDAgUiANXQ1lbmRvYmoNODI2IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDE5IDEyNTUg MCBSIA1dDWVuZG9iag04MjcgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTkgMTI1NiAw IFIgDV0NZW5kb2JqDTgyOCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxNyAxMjU3IDAg UiANXQ1lbmRvYmoNODI5IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDE3IDEyNTggMCBS IA1dDWVuZG9iag04MzAgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTYgMTI1OSAwIFIg DV0NZW5kb2JqDTgzMSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxNyAxMjYwIDAgUiAN XQ1lbmRvYmoNODMyIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDE2IDEyNjEgMCBSIA1d DWVuZG9iag04MzMgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTUgMTI2MiAwIFIgDV0N ZW5kb2JqDTgzNCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxNCAxMjYzIDAgUiANXQ1l bmRvYmoNODM1IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDEzIDEyNjQgMCBSIA1dDWVu ZG9iag04MzYgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTQgMTI2NSAwIFIgDV0NZW5k b2JqDTgzNyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxMyAxMjY2IDAgUiANXQ1lbmRv YmoNODM4IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDExIDEyNjcgMCBSIA1dDWVuZG9i ag04MzkgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTEgMTI2OCAwIFIgDV0NZW5kb2Jq DTg0MCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxMyAxMjY5IDAgUiANXQ1lbmRvYmoN ODQxIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDEwIDEyNzAgMCBSIA1dDWVuZG9iag04 NDIgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTEgMTI3MSAwIFIgDV0NZW5kb2JqDTg0 MyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA5IDEyNzIgMCBSIA1dDWVuZG9iag04NDQg MCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMTAgMTI3MyAwIFIgDV0NZW5kb2JqDTg0NSAw IG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA5IDEyNzQgMCBSIA1dDWVuZG9iag04NDYgMCBv YmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgOCAxMjc1IDAgUiANXQ1lbmRvYmoNODQ3IDAgb2Jq DVsgDS9JbmRleGVkIDE3NzAgMCBSIDcgMTI3NiAwIFIgDV0NZW5kb2JqDTg0OCAwIG9iag1b IA0vSW5kZXhlZCAxNzcwIDAgUiA3IDEyNzcgMCBSIA1dDWVuZG9iag04NDkgMCBvYmoNWyAN L0luZGV4ZWQgMTc3MCAwIFIgOSAxMjc4IDAgUiANXQ1lbmRvYmoNODUwIDAgb2JqDVsgDS9J bmRleGVkIDE3NzAgMCBSIDEgMTI3OSAwIFIgDV0NZW5kb2JqDTg1MSAwIG9iag1bIA0vSW5k ZXhlZCAxNzcwIDAgUiA2IDEyODAgMCBSIA1dDWVuZG9iag04NTIgMCBvYmoNWyANL0luZGV4 ZWQgMTc3MCAwIFIgNSAxMjgxIDAgUiANXQ1lbmRvYmoNODUzIDAgb2JqDVsgDS9JbmRleGVk IDE3NzAgMCBSIDEgMTI4MiAwIFIgDV0NZW5kb2JqDTg1NCAwIG9iag1bIA0vSW5kZXhlZCAx NzcwIDAgUiA3IDEyODMgMCBSIA1dDWVuZG9iag04NTUgMCBvYmoNWyANL0luZGV4ZWQgMTc3 MCAwIFIgNCAxMjg0IDAgUiANXQ1lbmRvYmoNODU2IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAg MCBSIDIgMTI4NSAwIFIgDV0NZW5kb2JqDTg1NyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAg UiA2IDEyODYgMCBSIA1dDWVuZG9iag04NTggMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIg NCAxMjg3IDAgUiANXQ1lbmRvYmoNODU5IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDEg MTI4OCAwIFIgDV0NZW5kb2JqDTg2MCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA2IDEy ODkgMCBSIA1dDWVuZG9iag04NjEgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMyAxMjkw IDAgUiANXQ1lbmRvYmoNODYyIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDYgMTI5MSAw IFIgDV0NZW5kb2JqDTg2MyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxIDEyOTIgMCBS IA1dDWVuZG9iag04NjQgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMSAxMjkzIDAgUiAN XQ1lbmRvYmoNODY1IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQgMTI5NCAwIFIgDV0N ZW5kb2JqDTg2NiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAyIDEyOTUgMCBSIA1dDWVu ZG9iag04NjcgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMSAxMjk2IDAgUiANXQ1lbmRv YmoNODY4IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDMgMTI5NyAwIFIgDV0NZW5kb2Jq DTg2OSAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAxIDEyOTggMCBSIA1dDWVuZG9iag04 NzAgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMiAxMjk5IDAgUiANXQ1lbmRvYmoNODcx IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIgMTMwMCAwIFIgDV0NZW5kb2JqDTg3MiAw IG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAyIDEzMDEgMCBSIA1dDWVuZG9iag04NzMgMCBv YmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMiAxMzAyIDAgUiANXQ1lbmRvYmoNODc0IDAgb2Jq DVsgDS9JbmRleGVkIDE3NzAgMCBSIDMgMTMwMyAwIFIgDV0NZW5kb2JqDTg3NSAwIG9iag1b IA0vSW5kZXhlZCAxNzcwIDAgUiAyIDEzMDQgMCBSIA1dDWVuZG9iag04NzYgMCBvYmoNWyAN L0luZGV4ZWQgMTc3MCAwIFIgMiAxMzA1IDAgUiANXQ1lbmRvYmoNODc3IDAgb2JqDVsgDS9J bmRleGVkIDE3NzAgMCBSIDIgMTMwNiAwIFIgDV0NZW5kb2JqDTg3OCAwIG9iag1bIA0vSW5k ZXhlZCAxNzcwIDAgUiAzIDEzMDcgMCBSIA1dDWVuZG9iag04NzkgMCBvYmoNWyANL0luZGV4 ZWQgMTc3MCAwIFIgMSAxMzA4IDAgUiANXQ1lbmRvYmoNODgwIDAgb2JqDVsgDS9JbmRleGVk IDE3NzAgMCBSIDEgMTMwOSAwIFIgDV0NZW5kb2JqDTg4MSAwIG9iag1bIA0vSW5kZXhlZCAx NzcwIDAgUiAxIDEzMTAgMCBSIA1dDWVuZG9iag04ODIgMCBvYmoNWyANL0luZGV4ZWQgMTc3 MCAwIFIgMiAxMzExIDAgUiANXQ1lbmRvYmoNODgzIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAg MCBSIDIgMTMxMiAwIFIgDV0NZW5kb2JqDTg4NCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAg UiAyIDEzMTMgMCBSIA1dDWVuZG9iag04ODUgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIg MiAxMzE0IDAgUiANXQ1lbmRvYmoNODg2IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDMg MTMxNSAwIFIgDV0NZW5kb2JqDTg4NyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzIDEz MTYgMCBSIA1dDWVuZG9iag04ODggMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMiAxMzE3 IDAgUiANXQ1lbmRvYmoNODg5IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIgMTMxOCAw IFIgDV0NZW5kb2JqDTg5MCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAyIDEzMTkgMCBS IA1dDWVuZG9iag04OTEgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMiAxMzIwIDAgUiAN XQ1lbmRvYmoNODkyIDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDIgMTMyMSAwIFIgDV0N ZW5kb2JqDTg5MyAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAyIDEzMjIgMCBSIA1dDWVu ZG9iag04OTQgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMyAxMzIzIDAgUiANXQ1lbmRv YmoNODk1IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDMgMTMyNCAwIFIgDV0NZW5kb2Jq DTg5NiAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzIDEzMjUgMCBSIA1dDWVuZG9iag04 OTcgMCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgMjggMTMyNiAwIFIgDV0NZW5kb2JqDTg5 OCAwIG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiAzNCAxMzI3IDAgUiANXQ1lbmRvYmoNODk5 IDAgb2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDM3IDEzMjggMCBSIA1dDWVuZG9iag05MDAg MCBvYmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNDAgMTMyOSAwIFIgDV0NZW5kb2JqDTkwMSAw IG9iag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA0MyAxMzMwIDAgUiANXQ1lbmRvYmoNOTAyIDAg b2JqDVsgDS9JbmRleGVkIDE3NzAgMCBSIDQ0IDEzMzEgMCBSIA1dDWVuZG9iag05MDMgMCBv YmoNWyANL0luZGV4ZWQgMTc3MCAwIFIgNDQgMTMzMiAwIFIgDV0NZW5kb2JqDTkwNCAwIG9i ag1bIA0vSW5kZXhlZCAxNzcwIDAgUiA0NCAxMzMzIDAgUiANXQ1lbmRvYmoNOTA1IDAgb2Jq DVsgDS9JbmRleGVkIDE3NzAgMCBSIDQyIDEzMzQgMCBSIA1dDWVuZG9iag05MDYgMCBvYmoN WyANL0luZGV4ZWQgMTc3MCAwIFIgMzUgMTMzNSAwIFIgDV0NZW5kb2JqDTkwNyAwIG9iag1b IA0vSW5kZXhlZCAxNzcwIDAgUiAzNyAxMzM2IDAgUiANXQ1lbmRvYmoNOTA4IDAgb2JqDVsg DS9JbmRleGVkIDE3NzAgMCBSIDM0IDEzMzcgMCBSIA1dDWVuZG9iag05MDkgMCBvYmoNWyAN L0luZGV4ZWQgMTc3MCAwIFIgMzAgMTMzOCAwIFIgDV0NZW5kb2JqDTkxMCAwIG9iag1bIA0v SW5kZXhlZCAxNzcwIDAgUiAyOCAxMzM5IDAgUiANXQ1lbmRvYmoNOTExIDAgb2JqDVsgDS9J bmRleGVkIDE3NzAgMCBSIDI3IDEzNDAgMCBSIA1dDWVuZG9iag05MTIgMCBvYmoNWyANL0lu ZGV4ZWQgMTc3MCAwIFIgMjUgMTM0MSAwIFIgDV0NZW5kb2JqDTkxMyAwIG9iag1bIA0vSW5k ZXhlZCAxNzcwIDAgUiAyNSAxMzQyIDAgUiANXQ1lbmRvYmoNOTE0IDAgb2JqDVsgDS9JbmRl eGVkIDE3NzAgMCBSIDIzIDEzNDMgMCBSIA1dDWVuZG9iag05MTUgMCBvYmoNPDwgL0xlbmd0 aCAxNiA+PiANc3RyZWFtDQrUp6LVwMbV1dXW0dHYsrkKZW5kc3RyZWFtDWVuZG9iag05MTYg MCBvYmoNPDwgL0xlbmd0aCAxNiA+PiANc3RyZWFtDQra0tTW1NTU1NTVytTZotQKZW5kc3Ry ZWFtDWVuZG9iag05MTcgMCBvYmoNPDwgL0xlbmd0aCAxMyA+PiANc3RyZWFtDQrVwb7V1dXW 1tbV0NYKZW5kc3RyZWFtDWVuZG9iag05MTggMCBvYmoNPDwgL0xlbmd0aCAxMCA+PiANc3Ry ZWFtDQrWwdTU1NTWwNQKZW5kc3RyZWFtDWVuZG9iag05MTkgMCBvYmoNPDwgL0xlbmd0aCAx MyA+PiANc3RyZWFtDQrVtrrV1dXW1tbYtK4KZW5kc3RyZWFtDWVuZG9iag05MjAgMCBvYmoN PDwgL0xlbmd0aCAxMCA+PiANc3RyZWFtDQramdTV1NTU1NQKZW5kc3RyZWFtDWVuZG9iag05 MjEgMCBvYmoNPDwgL0xlbmd0aCAyMiA+PiANc3RyZWFtDQrVtsXV0tTV1dXW1tbX19fW1dXY oKwKZW5kc3RyZWFtDWVuZG9iag05MjIgMCBvYmoNPDwgL0xlbmd0aCAxMCA+PiANc3RyZWFt DQrWztTU1NTVzdQKZW5kc3RyZWFtDWVuZG9iag05MjMgMCBvYmoNPDwgL0xlbmd0aCAxNiA+ PiANc3RyZWFtDQrVyc3V1dXW1tbX19fW0dUKZW5kc3RyZWFtDWVuZG9iag05MjQgMCBvYmoN PDwgL0xlbmd0aCAxMyA+PiANc3RyZWFtDQrYqNTVz9TU1NTWwdQKZW5kc3RyZWFtDWVuZG9i ag05MjUgMCBvYmoNPDwgL0xlbmd0aCAxOSA+PiANc3RyZWFtDQrVrrPV1dXW1tbX19fY2NjY usYKZW5kc3RyZWFtDWVuZG9iag05MjYgMCBvYmoNPDwgL0xlbmd0aCA3ID4+IA1zdHJlYW0N Cta/1NTU1AplbmRzdHJlYW0NZW5kb2JqDTkyNyAwIG9iag08PCAvTGVuZ3RoIDIyID4+IA1z dHJlYW0NCtXFx9XV1dbW1tfX19jY2NnZ2dbU1AplbmRzdHJlYW0NZW5kb2JqDTkyOCAwIG9i ag08PCAvTGVuZ3RoIDEwID4+IA1zdHJlYW0NCtXW1NTU1NXB1AplbmRzdHJlYW0NZW5kb2Jq DTkyOSAwIG9iag08PCAvTGVuZ3RoIDE5ID4+IA1zdHJlYW0NCtXCxtXV1dbW1tfX19jY2NnZ 2QplbmRzdHJlYW0NZW5kb2JqDTkzMCAwIG9iag08PCAvTGVuZ3RoIDEwID4+IA1zdHJlYW0N CtXR1NTU1NXQ1AplbmRzdHJlYW0NZW5kb2JqDTkzMSAwIG9iag08PCAvTGVuZ3RoIDIyID4+ IA1zdHJlYW0NCtXbtdXV1dbW1tfX19jY2NnZ2djdvwplbmRzdHJlYW0NZW5kb2JqDTkzMiAw IG9iag08PCAvTGVuZ3RoIDEzID4+IA1zdHJlYW0NCtXW1dXV1dTU1NTQ1AplbmRzdHJlYW0N ZW5kb2JqDTkzMyAwIG9iag08PCAvTGVuZ3RoIDIyID4+IA1zdHJlYW0NCtXaudXV1dbW1tfX 19jY2NnZ2dnb1AplbmRzdHJlYW0NZW5kb2JqDTkzNCAwIG9iag08PCAvTGVuZ3RoIDEwID4+ IA1zdHJlYW0NCtbY1tXV1dTU1AplbmRzdHJlYW0NZW5kb2JqDTkzNSAwIG9iag08PCAvTGVu Z3RoIDI1ID4+IA1zdHJlYW0NCtXZp9XV1dbW1tfX19jY2NnZ2dra2tjJ0QplbmRzdHJlYW0N ZW5kb2JqDTkzNiAwIG9iag08PCAvTGVuZ3RoIDEzID4+IA1zdHJlYW0NCtfQ0NbW1tXV1dTU 1AplbmRzdHJlYW0NZW5kb2JqDTkzNyAwIG9iag08PCAvTGVuZ3RoIDI4ID4+IA1zdHJlYW0N CtTYqNXV1dbW1tfX19jY2NnZ2dra2tfX1tTU1AplbmRzdHJlYW0NZW5kb2JqDTkzOCAwIG9i ag08PCAvTGVuZ3RoIDMxID4+IA1zdHJlYW0NCtXW0tXV1dbW1tfX19jY2NnZ2dra2tvb29TU 1NTR1AplbmRzdHJlYW0NZW5kb2JqDTkzOSAwIG9iag08PCAvTGVuZ3RoIDMxID4+IA1zdHJl YW0NCtTXxNXV1dbW1tfX19jY2NnZ2dra2tvb29TU1NXU1QplbmRzdHJlYW0NZW5kb2JqDTk0 MCAwIG9iag08PCAvTGVuZ3RoIDMxID4+IA1zdHJlYW0NCtXV1dbW1tfX19jY2NnZ2dra2tvb 29zc3NTU1NXU1QplbmRzdHJlYW0NZW5kb2JqDTk0MSAwIG9iag08PCAvTGVuZ3RoIDM0ID4+ IA1zdHJlYW0NCtTI0NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3dTU1AplbmRzdHJlYW0N ZW5kb2JqDTk0MiAwIG9iag08PCAvTGVuZ3RoIDM0ID4+IA1zdHJlYW0NCtTR1NXV1dbW1tfX 19jY2NnZ2dra2tvb29zc3N3d3dTU1AplbmRzdHJlYW0NZW5kb2JqDTk0MyAwIG9iag08PCAv TGVuZ3RoIDQwID4+IA1zdHJlYW0NCtTK0NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e 3tTU1NTU1QplbmRzdHJlYW0NZW5kb2JqDTk0NCAwIG9iag08PCAvTGVuZ3RoIDM0ID4+IA1z dHJlYW0NCtTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3gplbmRzdHJlYW0NZW5k b2JqDTk0NSAwIG9iag08PCAvTGVuZ3RoIDQzID4+IA1zdHJlYW0NCtDHxNTU1NXV1dbW1tfX 19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f39TU1QplbmRzdHJlYW0NZW5kb2JqDTk0NiAwIG9i ag08PCAvTGVuZ3RoIDQwID4+IA1zdHJlYW0NCtbWztTU1NXV1dbW1tfX19jY2NnZ2dra2tvb 29zc3N3d3d7e3t/f3wplbmRzdHJlYW0NZW5kb2JqDTk0NyAwIG9iag08PCAvTGVuZ3RoIDM3 ID4+IA1zdHJlYW0NCtTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3wplbmRz dHJlYW0NZW5kb2JqDTk0OCAwIG9iag08PCAvTGVuZ3RoIDQwID4+IA1zdHJlYW0NCs+81NTU 1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3wplbmRzdHJlYW0NZW5kb2JqDTk0 OSAwIG9iag08PCAvTGVuZ3RoIDQ2ID4+IA1zdHJlYW0NCs/W1NTU1NXV1dbW1tfX19jY2NnZ 2dra2tvb29zc3N3d3d7e3t/f3+Dg4NTU1QplbmRzdHJlYW0NZW5kb2JqDTk1MCAwIG9iag08 PCAvTGVuZ3RoIDQzID4+IA1zdHJlYW0NCtPV1NTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc 3N3d3d7e3t/f3+Dg4AplbmRzdHJlYW0NZW5kb2JqDTk1MSAwIG9iag08PCAvTGVuZ3RoIDQ5 ID4+IA1zdHJlYW0NCtTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh 4eLi4tXU1wplbmRzdHJlYW0NZW5kb2JqDTk1MiAwIG9iag08PCAvTGVuZ3RoIDQ5ID4+IA1z dHJlYW0NCtPB1NTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi 4gplbmRzdHJlYW0NZW5kb2JqDTk1MyAwIG9iag08PCAvTGVuZ3RoIDQ5ID4+IA1zdHJlYW0N CtTB1NTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4gplbmRz dHJlYW0NZW5kb2JqDTk1NCAwIG9iag08PCAvTGVuZ3RoIDU1ID4+IA1zdHJlYW0NCtHQ1NTU 1NXV1dbW1tfX19jY2NnZ2dra2tvb293d3d7e3t/f3+Dg4OHh4eLi4uPj49zc3NPU1gplbmRz dHJlYW0NZW5kb2JqDTk1NSAwIG9iag08PCAvTGVuZ3RoIDU1ID4+IA1zdHJlYW0NCtLR1NTU 1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj49fU1QplbmRz dHJlYW0NZW5kb2JqDTk1NiAwIG9iag08PCAvTGVuZ3RoIDU4ID4+IA1zdHJlYW0NCtDX1NTU 1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5Qpl bmRzdHJlYW0NZW5kb2JqDTk1NyAwIG9iag08PCAvTGVuZ3RoIDU4ID4+IA1zdHJlYW0NCtbX 1NTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl 5QplbmRzdHJlYW0NZW5kb2JqDTk1OCAwIG9iag08PCAvTGVuZ3RoIDYxID4+IA1zdHJlYW0N CtXV1NTU1NXV1dbW1tfX19jY2NnZ2dra2tvb293d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl 5dzc3MzU1gplbmRzdHJlYW0NZW5kb2JqDTk1OSAwIG9iag08PCAvTGVuZ3RoIDYxID4+IA1z dHJlYW0NCtXV1NTU1NXV1dbW1tfX19nZ2dra2tvb293d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk 5OXl5dzc3NjY2NfU1QplbmRzdHJlYW0NZW5kb2JqDTk2MCAwIG9iag08PCAvTGVuZ3RoIDYx ID4+IA1zdHJlYW0NCtTU1NXV1dbW1tfX19jY2NnZ2dra2tvb293d3d7e3t/f3+Dg4OHh4eLi 4uPj4+Tk5OXl5ebm5ufn59zc3AplbmRzdHJlYW0NZW5kb2JqDTk2MSAwIG9iag08PCAvTGVu Z3RoIDY3ID4+IA1zdHJlYW0NCtXV1NTU1NXV1dbW1tfX19jY2NnZ2dra2tvb293d3d7e3t/f 3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6Nzc3AplbmRzdHJlYW0NZW5kb2JqDTk2MiAw IG9iag08PCAvTGVuZ3RoIDcwID4+IA1zdHJlYW0NCtXV1NTU1NXV1dbW1tfX19nZ2dra2tvb 29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6NjY2MTU1wplbmRzdHJl YW0NZW5kb2JqDTk2MyAwIG9iag08PCAvTGVuZ3RoIDczID4+IA1zdHJlYW0NCtfP1NTU1NXV 1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn 5+jo6Onp6cLU1wplbmRzdHJlYW0NZW5kb2JqDTk2NCAwIG9iag08PCAvTGVuZ3RoIDc2ID4+ IA1zdHJlYW0NCtfO1NTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh 4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp6erq6srU1QplbmRzdHJlYW0NZW5kb2JqDTk2NSAw IG9iag08PCAvTGVuZ3RoIDczID4+IA1zdHJlYW0NCtPU1NTU1NXV1dbW1tfX19jY2NnZ2dra 2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp6erq6gplbmRz dHJlYW0NZW5kb2JqDTk2NiAwIG9iag08PCAvTGVuZ3RoIDczID4+IA1zdHJlYW0NCtfS1NTU 1NXV1dbW1tfX19nZ2dra2tvb293d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo 6Onp6erq6tzc3NjY2AplbmRzdHJlYW0NZW5kb2JqDTk2NyAwIG9iag08PCAvTGVuZ3RoIDcz ID4+IA1zdHJlYW0NCtXG1NTU1NXV1dbW1tfX19jY2NnZ2dra2tvb293d3d7e3t/f3+Dg4OHh 4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp6erq6tzc3AplbmRzdHJlYW0NZW5kb2JqDTk2OCAw IG9iag08PCAvTGVuZ3RoIDc2ID4+IA1zdHJlYW0NCtC91NTU1NXV1dbW1tfX19nZ2dra2tvb 29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp6erq6uvr69jY2Apl bmRzdHJlYW0NZW5kb2JqDTk2OSAwIG9iag08PCAvTGVuZ3RoIDczID4+IA1zdHJlYW0NCtTU 1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm 5ufn5+jo6Onp6erq6uvr6wplbmRzdHJlYW0NZW5kb2JqDTk3MCAwIG9iag08PCAvTGVuZ3Ro IDc2ID4+IA1zdHJlYW0NCtTU1NXV1dbW1tfX19jY2NnZ2dra2tvb293d3d7e3t/f3+Dg4OHh 4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp6erq6uvr6+zs7Nzc3AplbmRzdHJlYW0NZW5kb2Jq DTk3MSAwIG9iag08PCAvTGVuZ3RoIDc5ID4+IA1zdHJlYW0NCtXU1NTU1NXV1dbW1tfX19nZ 2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp6erq6uvr 6+zs7NjY2AplbmRzdHJlYW0NZW5kb2JqDTk3MiAwIG9iag08PCAvTGVuZ3RoIDc5IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJDMHHAcAgCADA/bfLI4KIvWDfIbl78P0p pQAAEbXWRGSMYWZrrXPOex9CiDHmnEsptdbWmoj03scYc8611t77nHPvTSl9AgwAJJpG4wpl bmRzdHJlYW0NZW5kb2JqDTk3MyAwIG9iag08PCAvTGVuZ3RoIDc5IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJDMHHAcAgCADA/XfLM4KIXbG7Q3LHz/tTSgEAIhKRMYaZ nXPe+xBCjDGllHMupdRaRaT3PsaYc6619t7nnHtva81aq7X+BBgAMGNG4wplbmRzdHJlYW0N ZW5kb2JqDTk3NCAwIG9iag08PCAvTGVuZ3RoIDgxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJDMGFAcAgDACw/2/aG8NKsRa3G7aEnvcnhJBSKqW01sYYALDWIqJzznsf QogxppSIiJlzzqWU1lrvfc651tp7n3PuvWOMWusnwAD6uEmjCmVuZHN0cmVhbQ1lbmRvYmoN OTc1IDAgb2JqDTw8IC9MZW5ndGggNzggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIkEwYcRABAMAMD99xNRoh+ir+BfCAEAUkpE1FobY6y1zjnvfQghxphSyjmXUmqtrbXe OzOPMeaca6299znn3vveIyKl1BdgAEAYR1MKZW5kc3RyZWFtDWVuZG9iag05NzYgMCBvYmoN PDwgL0xlbmd0aCA4MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiRTBhRHA IAwAwP33a/DgEnwFrv/w/QCAMcY5F0JIKZVSWmtjDCJaa51z3vsYY0op51xKqbW21oio9z7G mHOutfbe55x7bwjhCTAA4ytMfAplbmRzdHJlYW0NZW5kb2JqDTk3NyAwIG9iag08PCAvTGVu Z3RoIDg1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJDMHHAYAgDADA/Ufz LxBC772MoHfwvD9CCKWUMQYAnHNEFEIopbTWxhhrrXPOex9CiDGmlHLOpZRaa2ut9z7GmHOu tfbe55x7r5TyE2AAzzpPRAplbmRzdHJlYW0NZW5kb2JqDTk3OCAwIG9iag08PCAvTGVuZ3Ro IDg1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJDMGFAYAwDACw/3/iDDrp 3F1OgASe9wcAhBBKKWOMc46IQggppVJKa22MsdZ670MIMcaUUs65lFJrba313scYc8611t77 nHPvdc59AgwAxn1PNAplbmRzdHJlYW0NZW5kb2JqDTk3OSAwIG9iag08PCAvTGVuZ3RoIDg3 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMEFAcAwDAAw/8auoGNmJgdP AAAhhDEmhFBKGWOccyGEUkprbYyx1jrnvPchhJRSzrmUUmvtvY8x5pxrrb33Oefe+95rrcUY pZQfoF+AAQDZkVIRCmVuZHN0cmVhbQ1lbmRvYmoNOTgwIDAgb2JqDTw8IC9MZW5ndGggODkg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkMwQURgEAAALD+tWjA3bu7awPY 4At+EEKEEMaYUsoY45wLIaSUSimttTHGWuuc896HEGKMKaWccymltdZ7H2PMOddae+9zzr23 1koIeQD6BBgAxPpUiAplbmRzdHJlYW0NZW5kb2JqDTk4MSAwIG9iag08PCAvTGVuZ3RoIDkz IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJDMG1AQJBAACw/RejheLP3V0n eJLf9/kDAEAIEUIYY0IIpZQxJoSQUiqltNbGGGutc857H0KIMaaUcs6llFpra633PsZYa+29 zzn33jkn5/zzwFeAAQDDcldbCmVuZHN0cmVhbQ1lbmRvYmoNOTgyIDAgb2JqDTw8IC9MZW5n dGggODQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwQMBADAAALD+/W7b TvANAAAhRAhhjAkhlFLGGOdcCCGlVEpprY0x1lrnnPc+hBBjTCnlnEsptdbWWu99jDHnXGvt vc8599733hdgAM3YUngKZW5kc3RyZWFtDWVuZG9iag05ODMgMCBvYmoNPDwgL0xlbmd0aCA4 OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBBQHAIAAAsP79cIfjLgW+ AQAghAghjDGllDHGOZdSKqW01sYY59z3fd77EEKMMaWUcy6l1Fpba733Mcacc6219z7n3Hvf e9ZaIQQh5BdgAOgCVVEKZW5kc3RyZWFtDWVuZG9iag05ODQgMCBvYmoNPDwgL0xlbmd0aCA5 MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQzBhRHCMAAAwP3XA+IXd5dm gPL/+f7+AAAQQoQQxpgQQilljHHOhRBSSqWU1toYY6313ocQYowppVJKrbW11nsfY8w511p7 73PO8zz33pyzc+4VYADOwVgSCmVuZHN0cmVhbQ1lbmRvYmoNOTg1IDAgb2JqDTw8IC9MZW5n dGggOTQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwYUBgCAAALD//yOk pKQ7DnADAEAIEUIY4+d5CCGUUsYY51wI8b6vlFIppbU2xlhrv+9zzoUQYowppZxzKaXW2lrr vY8x5pxrrb33Oefe671HAPwCDADiAFqrCmVuZHN0cmVhbQ1lbmRvYmoNOTg2IDAgb2JqDTw8 IC9MZW5ndGggOTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkMwccRhCAA AMD+61NyHBAkZ/93u9d1/wEAIIQIIUIIpZQxJoSQUiqltNbGGGvt8zzOOe/9+74hhJRSzrmU UmttrfXexxhzzrXW3vuc831fjJFzjjGGN/gJMAAE0l1iCmVuZHN0cmVhbQ1lbmRvYmoNOTg3 IDAgb2JqDTw8IC9MZW5ndGggMTAzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJDMHHAYMgAADA/UfKANkgdKRKk47yN3f48/sDAEAIEUIYY0IIpZQxxjk/jkMIIaVUSmmt jTHW2vM8nXMhhBhjSum6rpxzKaXW2lrrvY8x5pxrrfu+n+fZe3vvvwC8AgwA+ZVf4AplbmRz dHJlYW0NZW5kb2JqDTk4OCAwIG9iag08PCAvTGVuZ3RoIDkzIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJBMFHEsAQAADA//9PixpEZ/R7dgEAEEKEEMaYEPI8D6WUMcY5 F0JIKZVS7/saY6y13/c557z3IYQYY865lFJrba313scYc8611t77nHPvTSlprX8BBgDbIFhC CmVuZHN0cmVhbQ1lbmRvYmoNOTg5IDAgb2JqDTw8IC9MZW5ndGggOTQgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkUwccRwyAAALD99wvd9ANM739fJPD7AwBACBFChBBK KWOMcy6EkFIqpbTWxhhrrXMuhPC+b4wxpZRzLqXUWltrvfcxxpxzrXXOuffuvb33z/NgjD8B BgDvpFrdCmVuZHN0cmVhbQ1lbmRvYmoNOTkwIDAgb2JqDTw8IC9MZW5ndGggMTA2IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJDMHHAYMgAADA/QfKJqEI0otKUap8k7sP +P4BACCECKFt2wghlFLGGOdcCCGlVEpprY0x1lrnnPf+OI7zPEMIMcaUUs75vu/neUoptdbW Wu99jDHnfN93rXVd177vGOOfAAMAPHpjMQplbmRzdHJlYW0NZW5kb2JqDTk5MSAwIG9iag08 PCAvTGVuZ3RoIDEwNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBRw6E IAAAwP9/bJO90wWkqhQjSLs6AwCAECKEMMaEEEopY2zbNs65EEJKue+7UsoYY6313h/HcZ7n dV0hhBhjSinnfN/38zyllFrr+7699zHGnHOt1Vpzzmmtwe//CTAAJahgbAplbmRzdHJlYW0N ZW5kb2JqDTk5MiAwIG9iag08PCAvTGVuZ3RoIDExMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiQTB1xWDIAAAwP1HyBIZIHPQBEHAJ0Wli/CZOwB+AAAIIUIIY0wIWZaF UsoYW9eVcy6E2LZNSqmU0lrv+34ch7XWOXee53Vd932HEGKMKaWccyml1vo8T+/9fd8xxpyz tea9N8aAz/cvwABcpmWMCmVuZHN0cmVhbQ1lbmRvYmoNOTkzIDAgb2JqDTw8IC9MZW5ndGgg MTAyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMFZFoAQAADA+98vZM+S orzsfDazbRsAAEKIENr3HWNMCKGUcs6FEFLK4ziUUlprY4y19jxP59x1Xfd9e+9DCM/zvO8b Y/y+L6WUcy6ltNZ672OMOedaq9bKGPsFGAAltGDxCmVuZHN0cmVhbQ1lbmRvYmoNOTk0IDAg b2JqDTw8IC9MZW5ndGggMTEwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ BMFZFoUQAADQ/e/ufSBxTFGGTJHS37sXgB8AAEKIEFqWZV1XQgillDHGORdCSCmVUtu2aa2N Mfu+H8dhrXXOee9DCOd5xhhTSjnnUkqt9bqu1lrv/b7vMcbzPO/7zjm/78MY/wUYAHenZooK ZW5kc3RyZWFtDWVuZG9iag05OTUgMCBvYmoNPDwgL0xlbmd0aCAxMTQgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwckRgyAAAMD+60kJ+ebJMQiCwCiHOtwivLILwAcA ACFECGGMCSHLslBKGWPrunLOhRDbtimltNb7vhtjrLXe+/M8r+u67zuEEGNMKeWcSym11tba 8zy99/d9xxhzTufccRxSSvD9/QUYAH2KZlQKZW5kc3RyZWFtDWVuZG9iag05OTYgMCBvYmoN PDwgL0xlbmd0aCAxMTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwVsC hBAAAMD7n2BvsadRJEUlFCF59tUMAKDrur7vIYQIoWEYMMbjOBJCpmma55lSyhhblmVd123b OOf7vgshpJRKqeM4zvPUWhtjruuy1jrnvPf3fYcQYowppZxzKaXW2lp73/d5HvD7fwIMAOsi a60KZW5kc3RyZWFtDWVuZG9iag05OTcgMCBvYmoNPDwgL0xlbmd0aCAxMTYgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwVkChBAAAND732mOgbJUsqSFkCX6mvcA+AEA IIQIoWEYxnHEGBNCKKWMsWma5nleloVzvq6rEEJKqZTSWm/bZozZ9/04jvM8r+uy1jrnvPch hBjj8zwppZxzKaXW+r5va633/n3ffd9/AQYAyGdr+AplbmRzdHJlYW0NZW5kb2JqDTk5OCAw IG9iag08PCAvTGVuZ3RoIDExMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iQTBWRaAEAAAwPvfT5YkhLL1SiLlpxkAwDAMEEKEEMaYEDKOI6WUMTbPM+dcCCGlXJZFKaW1 Nsas67ptm7XWex9CiDHu+34cx3meKaXruu77LqXUWp/naa297/t9X+895+ycm6bpF2AAw/dp uwplbmRzdHJlYW0NZW5kb2JqDTk5OSAwIG9iag08PCAvTGVuZ3RoIDEyOCAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBWxZEIAAA0P0vZjYw58wuopdCelAeFaL4mHsB +AEAqqqq6xpCiDEmhFBKGWOc87Ztu64TQgzDoJQyxozjaK11zs3zvCzLuq7btnnvQwgxxn3f j+M4zzOldF3Xfd8551LK8zzv+07TpLWWUvZ93zQNQgh8vn8BBgAOanQZCmVuZHN0cmVhbQ1l bmRvYmoNMTAwMCAwIG9iag08PCAvTGVuZ3RoIDExMiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiQTB2RKAEAAAwP//PzkyCQ3KVUmkPLQLABiGAUKIECKEjONIKZ2miTE2 zzPnXEq5LItSyhizruu2bdZa55z3PoQQY9z3/TiO8zxTStd15Zzv+y6l1Fqf53nf9/u+3ntr TWsthMAY/wIMAPF+ajkKZW5kc3RyZWFtDWVuZG9iag0xMDAxIDAgb2JqDTw8IC9MZW5ndGgg MTIzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMELEkUgFADQ/S/rbeHN FUlq+gkZyq8PM84B+AFAVVUIobquMcZt2xJCuq6jlPZ9zxjjnAshpJRKKa21MWYYBmvtOI7T NM3z7JxblmVd123bvPchhOM4zvO8ruu+7xhjSinnXEp5nud9333fm6aBP3wCDACPyHHmCmVu ZHN0cmVhbQ1lbmRvYmoNMTAwMiAwIG9iag08PCAvTGVuZ3RoIDEyNSAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBxxGEIAAAwP5Lut8VQZAkEsUsKoppxl0AAIQQIYQx JoRQShljnHMhRFmWUsqqqpRSWmtjjLXWOee9r+s6hNA0Tdu2Xdf1fT8MwziO0zTN8xxjXJZl Xddt21JK+74fx5FzPs/zuq77vp/ned+3KArw+38CDAAAgHS9CmVuZHN0cmVhbQ1lbmRvYmoN MTAwMyAwIG9iag08PCAvTGVuZ3RoIDEyNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiQTBCRJFIAAA0Puf518lGaVNpURZCiHmvwfADwBQVRWEsK7rpmkQQhjjtm0JIZRS xhjnXAjRdZ2UUimlte773hhjrR2GwTk3juM0Td77EMI8z8uyrOu6bVuMMaW07/t5njnn67ru +36ep5Tyvu/3fcdx/AUYANQ/dT0KZW5kc3RyZWFtDWVuZG9iag0xMDA0IDAgb2JqDTw8IC9M ZW5ndGggMTIxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMEJEkAgAADA //+PGkoppEQ5KoSyWxRFWZYAAAhhVVV1XSOEMMZN0xBCKKVt2zLGOOdd1/V9PwyDEGIcRynl NE1a63mel2Uxxlhr13Xdtm3f9+M4nHPe+xDCeZ7Xdd33HWN83/f7vpRSzvl5HqXUL8AADUV1 3wplbmRzdHJlYW0NZW5kb2JqDTEwMDUgMCBvYmoNPDwgL0xlbmd0aCAxMzUgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwVkCRCAAAND7H2T+5gBzkBKRskVCoiwVzXsA fAEAEMIkSRBCaZpmWYYxzvO8KApCSFmWlFLGWFVVdV03TdO2bdd1nPO+74dhGMdRSjlN0zzP y7IopdZ11Vpv22aMsdYex3Ge53Vd930757z3IYTned73jTHu+y6EAJ/fX4ABAAf4fOwKZW5k c3RyZWFtDWVuZG9iag0xMDA2IDAgb2JqDTw8IC9MZW5ndGggMTMwIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJBMEJFkUgFADQ/S/vn//ImFLIlEwlSu4F+AFAFEVxHCOE kiRJ0zTLsjzPi6IoyxJjXFUVIYRSWtc1Y4xz3jRN27Zd1wkhhmEYx3GapnmepZTLsiil1nXd tu04jvM8tdbGmOu6rLX3fT/P45zz3r/vG0LY973ve/jDJ8AAHBh9WwplbmRzdHJlYW0NZW5k b2JqDTEwMDcgMCBvYmoNPDwgL0xlbmd0aCAxMzIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIkEwdcVgyAAAMD9h8gGGSWfKBaKXRAR8IEFEHMHwA8AkGVZnucQwqIoyrKs qqqua4QQxpgQQiltmqZt267r+r4fhmEcx3meGWPLsggh1nWVUiqltNbGmH3frbXOueM4zvO8 rst7H2N8nud935RSCOG+723bOOfTNIHP9y/AALNteh8KZW5kc3RyZWFtDWVuZG9iag0xMDA4 IDAgb2JqDTw8IC9MZW5ndGggMTIzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJBMEHAoAQAADA//+vpIRkhqamhu6yLMvzHABQFAWEsCzLqqoQQnVdY4wJIZTSpmkYY23b cs6FEFJKrbUxxlrrnPPe930/juM0TfM8L8uyruu2bfu+H8dxnmeM8Xme931TSt/33fd9XVcI YRiGruuUUr8AAwBs53hnCmVuZHN0cmVhbQ1lbmRvYmoNMTAwOSAwIG9iag08PCAvTGVuZ3Ro IDEzNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBWxZEIAAA0P2var7m nFlAiUh5RUKiPCqaewH4AAAghEmSIITSNM2yDGOc53lRFISQsiwppYyxqqrqum6apm3bruv6 vh+GYRxHKeU0TfM8K6XWddVab9tmjLHWHsdxnud1Xc45730I4XmeGOP7vvd97/u+LIsQgnMO ft+/AAMAI/d9LwplbmRzdHJlYW0NZW5kb2JqDTEwMTAgMCBvYmoNPDwgL0xlbmd0aCAxMjMg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwQcCgBAAAMD//6+khGSGpqaG 7rIsy/McAFAUBYSwLMuqqhBCdV1jjAkhlNKmaRhjbdtyzoUQUkqllNbaGGOtdc557/u+H4Zh HMdpmuZ5XpZlXddt2/Z9P47jPM/rumKM930/z/O+7/d9KaUQQtd1vwADAFr5eGcKZW5kc3Ry ZWFtDWVuZG9iag0xMDExIDAgb2JqDTw8IC9MZW5ndGggMTMzIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJBMELFkQgAADA+99rD7D7XolI+UVConwq2hkAPgAACGGSJAih NE2zLMMY53leFAUhpCxLSiljrKqquq6bpmnbtus6znnf98MwjOMopZymaZ7nZVmUUuu6aq23 bTPGWGuP4zjP87qu+76dc977EMLzPO/7xhj3fRdCgN/3L8AAFSh9SAplbmRzdHJlYW0NZW5k b2JqDTEwMTIgMCBvYmoNPDwgL0xlbmd0aCAxMjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIkEwQUShCAAAMD/v+8QhjCQBjtQVPR2AfgBAIqigBAihDDGhBBKKWOsLMuq quq6bpqGc962rRBCSqmU0lobY6y13vsQQtd1fd8PwzCO4zRN8zwvy7Ku67Zt+77HGI/jOM8z pXRd133fz/PknN/3/b7POfcXYABR73haCmVuZHN0cmVhbQ1lbmRvYmoNMTAxMyAwIG9iag08 PCAvTGVuZ3RoIDEyMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBBw6D IAAAwP8/rw0jskSmuEVFccU7AACEECGEMS6KghBCKWWMcc6FEGVZSimrqlJKaa2NMdZa55z3 vq7rEELTNG3bdl3X9/0wDOM4TtM0z3OMcVmWdV23bdv3/TiOnPN5ntd13ff9PM/7vikl8Pt/ AgwABEB1WQplbmRzdHJlYW0NZW5kb2JqDTEwMTQgMCBvYmoNPDwgL0xlbmd0aCAxMzAgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwUkSgyAQAMD/3/OPnPKTQREQAVlc EVdUtCrdAD8AQAhlWZbneVEUhBBKKWOsLEvOeVVVQggppVKqrmuttTHGWuuca5qmbduu6/q+ H4ZhHEfv/TRNIYR5npdlWdd127Z934/jiDGe53ld133fKaXned73xRjD5/sXYAA17XbkCmVu ZHN0cmVhbQ1lbmRvYmoNMTAxNSAwIG9iag08PCAvTGVuZ3RoIDExNyAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBCRKAEAAAwP//rxTpQooyQpJrpt2madq2BQB0XQch RAgNw4AxHsdxmqZ5npdlIYRQShlj27Zxzvd9P45DCCGlPM/zui6llNb6vm9jjLX2eR7v/fu+ IYTv+2KMKaWccyml1uqcW9e17/tfgAEAYwFvpgplbmRzdHJlYW0NZW5kb2JqDTEwMTYgMCBv YmoNPDwgL0xlbmd0aCAxMjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkE wVkWhRAAAND97+at4K2CQmToNBiiCUUf3QsAgBA2TdO2LcaYENJ1HWOs73vOuRBCKTUMwziO 8zwvy6K1NsZYa51z67p670MI27bt+34cx3me13XFGFNKOef7vksptdb3fZ/nmaZJSkkpRQiB /+8TYACAsW8PCmVuZHN0cmVhbQ1lbmRvYmoNMTAxNyAwIG9iag08PCAvTGVuZ3RoIDEyMyAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBSwJFIAAAwPvf5y3eQYrSDymp fCqELMz8wQ8AACGsqqqua4QQxrhpGkIIY4xzLoRo27bveymlUmocR2OMtdY5572f53lZlnVd t20LIcQYU0r7vh/HcZ5nzvm6rvu+n+cppbzvO02T1noYhq7rKKWfAAMAipRxuQplbmRzdHJl YW0NZW5kb2JqDTEwMTggMCBvYmoNPDwgL0xlbmd0aCAxMTkgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIkEwVsChBAAAMD732rPsCsqRSUUIXnma2d+4AsA6LoOQogQ6vt+ GIZxHDHG8zwTQiily7Ks67ptG2Ns33fOuRBCSnkch1JKa31dlzHGWuucu+/be/88T4wxpZRz LqXUWt/3ba2FEM7znKYJgM9fgAEALzRudQplbmRzdHJlYW0NZW5kb2JqDTEwMTkgMCBvYmoN PDwgL0xlbmd0aCAxMTEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwUkC gBAAAMD//0+WJISyVRIpp2YAAMMwQAgRQhhjQsg4jpTSaZoYY/M8c86FEFLKZVmUUlprY8y6 rtu2WWudc977EEKMcd/38zxTStd15Zzv+y6l1Fqf52mtve/7fV/v/TiOX4ABAKvBaZQKZW5k c3RyZWFtDWVuZG9iag0xMDIwIDAgb2JqDTw8IC9MZW5ndGggMTIwIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJBMFbAoQQAADA+59n9wZ7BVEpKqEIyTNfO/MFHwBA13UQ QoRQ3/fDMIzjiDGepmmeZ0IIpXRZlnVdt21jjO37zjkXQkgpj+M4z1MppbW+rssYY611zt33 7b1/nifGmFLKOZdSaq3v+7bWQggA/P4CDAD74m46CmVuZHN0cmVhbQ1lbmRvYmoNMTAyMSAw IG9iag08PCAvTGVuZ3RoIDExNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iQTBWQKEEAAA0Ptfac6BslSypIWQJfqa9wAAEEKE0DAMGGNCCKWUMTZN0zzPy7JwzoUQUkqt tTFm3/fzPK/rstY657z3IYQY4/M8KaWccyml1vq+b2ut9/5933Ec27at66qUuu97HEcAfn8B BgAiGmv2CmVuZHN0cmVhbQ1lbmRvYmoNMTAyMiAwIG9iag08PCAvTGVuZ3RoIDExMSAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTByRGDIAAAwP5rSAH5pRpEbhRQOXQ4 BZ7Z/X5+AIBlWSCE67oihDDGhBBKKedcCCGl3LZt33ellNbaGHMcx3me13VZa51z3vsQwn3f z/PEGFNKOedSSmvtfd/e+xhjzllrZYz9BRgA+tBi4QplbmRzdHJlYW0NZW5kb2JqDTEwMjMg MCBvYmoNPDwgL0xlbmd0aCAxMTQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIkEwckRgyAAAMD+S8ojk68FgCj3IMotCCI+s/udfgAACOE8zwihZVnWdcUYE0IopYwxzrkQ QkqplNq2TWu977sxxlrrvQ8hxBhTSud55pxLKdd11Vrv++69P88zxnjft7XmnDuOA4DPX4AB AFIxZb0KZW5kc3RyZWFtDWVuZG9iag0xMDI0IDAgb2JqDTw8IC9MZW5ndGggMTAzIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMFHDoQgAADA/z9vE5Am0hUQQsfrzgAA IITHcSCEMMaEEEopY+w8T875dV1CCCml1toY45y77/t5Hu99CCHG+L5vSinnXEqptbbWeu9z zrXW3vv7vjGGtVYpBcDvL8AAJcxgggplbmRzdHJlYW0NZW5kb2JqDTEwMjUgMCBvYmoNPDwg L0xlbmd0aCAxMDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwUUSgCAA AMD//09CGEJCSkDJq7vHcQAAIIQIofM8CSGUUsYY51wIIaW8rksppbU2xlhr7/t2znnvY4wp ped5cs6llFrr+77f97XWxhhzzrXW3rv3HkLAGP8CDAAYZV4/CmVuZHN0cmVhbQ1lbmRvYmoN MTAyNiAwIG9iag08PCAvTGVuZ3RoIDEwNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiQTBxw3DIAAAwP3HiZQMkB3oHSM62GDD33e/zxcAACFECGGMKaWMMc65lFIppbU2 xlhrj+NwznnvQwgxxpRSzrmUUmttrfXez/O8rmuMMee873uttfd+nkcIQQgB4P8KMADYv1zj CmVuZHN0cmVhbQ1lbmRvYmoNMTAyNyAwIG9iag08PCAvTGVuZ3RoIDEwMSAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBxxHDIAAAsP3HyiOXBTDF9Gb60cw/0vfzAwBc 1wUhRAhhjAkh931TShljnHMhhJRSKWWMsdY657z3z/OEEGKMOedSSq21tdZ7H2PMOddae+/3 fc85KSWt9V+AAQDDkVqPCmVuZHN0cmVhbQ1lbmRvYmoNMTAyOCAwIG9iag08PCAvTGVuZ3Ro IDk1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMFFAoAgAACw//9PQEJS Qjrvbtd1AQAghAih+74xxoQQSilj7HkezrkQQkqplNJaG2Pe97XWeu9DCN/3xRhTSjnnUkqt tbXWex9jzDnXWnvvc45z7hdgAONHWwwKZW5kc3RyZWFtDWVuZG9iag0xMDI5IDAgb2JqDTw8 IC9MZW5ndGggOTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwUUCgCAA ALD//09AQlJCOu9u13UBACCECCGMMSGEUvo8D+dcCCGl1FobY973tdY657z3IYQYY0op51xK qbW21nrvY4w551pr733O+b5PKcUYu+/7F2AAA/ZbDAplbmRzdHJlYW0NZW5kb2JqDTEwMzAg MCBvYmoNPDwgL0xlbmd0aCA5MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iQTBhQGAIAAAsP//oyQFpDsOcAMAQAgRQhhjQsjzPJRSxhjnXAghpVRKve+rtTbGWGu/73PO hRBijCmlnHMppdbaWuu9jzHmnGutvfc5597rvf8FGADUbFgtCmVuZHN0cmVhbQ1lbmRvYmoN MTAzMSAwIG9iag08PCAvTGVuZ3RoIDk4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJBMHFEQMhAADA/jvJM/+0AYcNh7tLAdn9fH8AAAjh8zwIIYwxIYRSyhjjnL/vK4SQ UiqltNbGGGutc857H0KIMaaUcs6llFpra633PsaYc6619t7nnHvvX4ABAKCKV6wKZW5kc3Ry ZWFtDWVuZG9iag0xMDMyIDAgb2JqDTw8IC9MZW5ndGggOTYgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIkEwbUBwzAAALD/7+rUoZsdY8zM8ECl7+cHAIAQPs+DECKEUEoZ Y+/7CiGklEoprbUxxlrrnPPehxBijCmlnHMppdbaWuu9jzHmnGutvfc5597LOccY/wUYAMgf V6oKZW5kc3RyZWFtDWVuZG9iag0xMDMzIDAgb2JqDTw8IC9MZW5ndGggOTEgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwcUNAkAAALD9Z+NBSM7d3Seg/f4+AAAIIUII Y0wIoZQyxjjnQggppVJKa22MsdY657z3IYQYY0op51xKqbW21nrvY4w551pr733Oufe+9/4C DACzo1TjCmVuZHN0cmVhbQ1lbmRvYmoNMTAzNCAwIG9iag08PCAvTGVuZ3RoIDgyIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMGHEQAQEACw/ffTeZz+ug0khBBKKWOM cy6lVEpprY0xAGCtdc5570MIMcaUUs65lFJrba313scYc8611t77nHPvfe8hohDiCzAA/g1M /wplbmRzdHJlYW0NZW5kb2JqDTEwMzUgMCBvYmoNPDwgL0xlbmd0aCA4MyAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBBQEAIAwAsP79cIfjTgM2hBDGmBBCKWWMcc6F EFJKrbUxxlrrnPPehxAAIKWUcy6l1Fp772OMOedaa+99zrn3vvdaazFGpdQXYADlzU+iCmVu ZHN0cmVhbQ1lbmRvYmoNMTAzNiAwIG9iag08PCAvTGVuZ3RoIDg4IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJBMEFAYBAEACw/lWIARXu3d0lAtv7PACAEMIYE0IYY5xz IYSUUimltTbGWGu99yGEGGNKKedcSqm1ttZ672OMOedaa+99zrn3OucopR/AL8AApyxRUApl bmRzdHJlYW0NZW5kb2JqDTEwMzcgMCBvYmoNPDwgL0xlbmd0aCA4OSAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBtxHAIBAAsP3n8XkE126efOScGQHp+V4AQAhhjAkh lFLGGOdcCCGlVEpprY0x1lrnnPc+hBBjTCnlnEsptdbWWu99jDHnXGvtvc85P8AVYAC17U7f CmVuZHN0cmVhbQ1lbmRvYmoNMTAzOCAwIG9iag08PCAvTGVuZ3RoIDg4IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMHFEYAwEADA/ouC4UcDF3f3pIXs/t8DAAghjDEh hDHGORdCSCmVUlprY4y11jnnvQ8hxBhTSjnnUkqttbXWex9jzDnXWnvvcw6l9AW4AgwAv59O qQplbmRzdHJlYW0NZW5kb2JqDTEwMzkgMCBvYmoNPDwgL0xlbmd0aCA3OSAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBhwHAIAgAsP//6gkIKu6B+4cmAKCUQkQi0lob Y6y1zOyc896HEGKMKaWccyml1tpa672PMeace+9zzr33vbfWEpEP4BdgAC7DRtQKZW5kc3Ry ZWFtDWVuZG9iag0xMDQwIDAgb2JqDTw8IC9MZW5ndGggNzggL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIkEwYcBwCAIALD/7yuCinvg/qEJACilEJGItNbGGGstM3vvQwgx xpRSzrmUUmttrfXexxhzzrXW3vucc+9974mIc+4D+AUYADP3RuMKZW5kc3RyZWFtDWVuZG9i ag0xMDQxIDAgb2JqDTw8IC9MZW5ndGggNzkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIkEwYcBwCAIALD/P+lBCCrugfuHJgCglEJEItJaG2OstczsnPPehxBijCmlnHMp pdbaWuu9jzHmnGutvfc559773hORD+AXYAAuFUa4CmVuZHN0cmVhbQ1lbmRvYmoNMTA0MiAw IG9iag08PCAvTGVuZ3RoIDc5ID4+IA1zdHJlYW0NCtTU1NXV1dbW1tfX19nZ2dra2tvb293d 3d7e3t/f3+Dg4OLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp6erq6uvr6+zs7OHh4dzc3NjY2LXU 1AplbmRzdHJlYW0NZW5kb2JqDTEwNDMgMCBvYmoNPDwgL0xlbmd0aCA3NiA+PiANc3RyZWFt DQrU1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3Nzd3d3e3t7f39/g4ODh4eHi4uLj4+Pk5OTl 5eXm5ubn5+fo6Ojp6enq6urr6+vP1NQKZW5kc3RyZWFtDWVuZG9iag0xMDQ0IDAgb2JqDTw8 IC9MZW5ndGggNzYgPj4gDXN0cmVhbQ0K1NTU1dXV1tbW19fX2dnZ2tra29vb3Nzc3d3d3t7e 39/f4ODg4eHh4uLi4+Pj5OTk5eXl5ubm5+fn6Ojo6enp6urq6+vr2NjY09TUCmVuZHN0cmVh bQ1lbmRvYmoNMTA0NSAwIG9iag08PCAvTGVuZ3RoIDcwID4+IA1zdHJlYW0NCtTU1NXV1dbW 1tfX19jY2NnZ2dra2tvb293d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp 6erq6tzc3AplbmRzdHJlYW0NZW5kb2JqDTEwNDYgMCBvYmoNPDwgL0xlbmd0aCA3MyA+PiAN c3RyZWFtDQrU1NTV1dXW1tbX19fY2NjZ2dna2trb29vd3d3e3t7f39/g4ODh4eHi4uLj4+Pk 5OTl5eXm5ubn5+fo6Ojp6enq6urc3Nyf1dQKZW5kc3RyZWFtDWVuZG9iag0xMDQ3IDAgb2Jq DTw8IC9MZW5ndGggNzMgPj4gDXN0cmVhbQ0K1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb3Nzc 3d3d3t7e39/f4ODg4uLi4+Pj5OTk5eXl5ubm5+fn6Ojo6enp6urq4eHhsdXUCmVuZHN0cmVh bQ1lbmRvYmoNMTA0OCAwIG9iag08PCAvTGVuZ3RoIDcwID4+IA1zdHJlYW0NCtTU1NXV1dbW 1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo 6Onp6cDV1AplbmRzdHJlYW0NZW5kb2JqDTEwNDkgMCBvYmoNPDwgL0xlbmd0aCA2NyA+PiAN c3RyZWFtDQrU1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3Nzd3d3e3t7f39/g4ODh4eHi4uLj 4+Pk5OTl5eXm5ubn5+fo6OjP1dQKZW5kc3RyZWFtDWVuZG9iag0xMDUwIDAgb2JqDTw8IC9M ZW5ndGggNzAgPj4gDXN0cmVhbQ0KxcbH1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb3d3d3t7e 39/f4ODg4eHh4uLi4+Pj5OTk5eXl5ubm5+fn6Ojo3NzczdXUCmVuZHN0cmVhbQ1lbmRvYmoN MTA1MSAwIG9iag08PCAvTGVuZ3RoIDY3ID4+IA1zdHJlYW0NCsPBvdTU1NXV1dbW1tfX19jY 2NnZ2dra2tvb293d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn59zc3NPV1AplbmRz dHJlYW0NZW5kb2JqDTEwNTIgMCBvYmoNPDwgL0xlbmd0aCA2NCA+PiANc3RyZWFtDQq5u7LU 1NTV1dXW1tbX19fY2NjZ2dna2trb29vd3d3e3t7f39/g4ODh4eHi4uLj4+Pk5OTl5eXm5ubn 5+fc3NwKZW5kc3RyZWFtDWVuZG9iag0xMDUzIDAgb2JqDTw8IC9MZW5ndGggNTUgPj4gDXN0 cmVhbQ0K1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb3d3d3t7e39/f4ODg4eHh4uLi4+Pj5OTk 5eXl3NzcCmVuZHN0cmVhbQ1lbmRvYmoNMTA1NCAwIG9iag08PCAvTGVuZ3RoIDU1ID4+IA1z dHJlYW0NCtTU1NXV1dbW1tfX19nZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk 5OXl5djY2AplbmRzdHJlYW0NZW5kb2JqDTEwNTUgMCBvYmoNPDwgL0xlbmd0aCA2MSA+PiAN c3RyZWFtDQrVzNTU1NTV1dXW1tbX19fZ2dna2trb29vc3Nzd3d3e3t7f39/g4ODh4eHi4uLj 4+Pk5OTl5eXY2NjU09QKZW5kc3RyZWFtDWVuZG9iag0xMDU2IDAgb2JqDTw8IC9MZW5ndGgg NTUgPj4gDXN0cmVhbQ0K2LXU1NTU1dXV1tbW19fX2dnZ2tra29vb3Nzc3d3d3t7e39/f4ODg 4eHh4uLi4+Pj2NjY1NLUCmVuZHN0cmVhbQ1lbmRvYmoNMTA1NyAwIG9iag08PCAvTGVuZ3Ro IDUyID4+IA1zdHJlYW0NCtTU1NXV1dbW1tfX19nZ2dra2tvb293d3d7e3t/f3+Dg4OHh4eLi 4uPj49zc3NjY2NTJ1AplbmRzdHJlYW0NZW5kb2JqDTEwNTggMCBvYmoNPDwgL0xlbmd0aCA0 OSA+PiANc3RyZWFtDQrU1NTV1dXW1tbX19fZ2dna2trb29vc3Nzd3d3e3t7f39/g4ODh4eHi 4uLY2NjUydQKZW5kc3RyZWFtDWVuZG9iag0xMDU5IDAgb2JqDTw8IC9MZW5ndGggNTIgPj4g DXN0cmVhbQ0K1c3U1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb3Nzc3d3d3t7e39/f4ODg4eHh 4uLi1MrUCmVuZHN0cmVhbQ1lbmRvYmoNMTA2MCAwIG9iag08PCAvTGVuZ3RoIDQ5ID4+IA1z dHJlYW0NCtis1NTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4dS7 1AplbmRzdHJlYW0NZW5kb2JqDTEwNjEgMCBvYmoNPDwgL0xlbmd0aCA0MyA+PiANc3RyZWFt DQrU1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3Nzd3d3e3t7f39/g4ODTrtQKZW5kc3RyZWFt DWVuZG9iag0xMDYyIDAgb2JqDTw8IC9MZW5ndGggNDMgPj4gDXN0cmVhbQ0K1NTU1dXV1tbW 19fX2NjY2dnZ2tra29vb3Nzc3d3d3t7e39/f4ODgparUCmVuZHN0cmVhbQ1lbmRvYmoNMTA2 MyAwIG9iag08PCAvTGVuZ3RoIDQwID4+IA1zdHJlYW0NCtqY1NTU1NXV1dbW1tfX19jY2NnZ 2dra2tvb29zc3N3d3d7e3t/f3wplbmRzdHJlYW0NZW5kb2JqDTEwNjQgMCBvYmoNPDwgL0xl bmd0aCA0MCA+PiANc3RyZWFtDQrU1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3Nzd3d3e3t7f 39/R09QKZW5kc3RyZWFtDWVuZG9iag0xMDY1IDAgb2JqDTw8IC9MZW5ndGggNDMgPj4gDXN0 cmVhbQ0K1szU1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb3Nzc3d3d3t7e39/fzsjUCmVuZHN0 cmVhbQ1lbmRvYmoNMTA2NiAwIG9iag08PCAvTGVuZ3RoIDQwID4+IA1zdHJlYW0NCtTU1NXV 1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f37691AplbmRzdHJlYW0NZW5kb2JqDTEw NjcgMCBvYmoNPDwgL0xlbmd0aCAzNyA+PiANc3RyZWFtDQrV1NTU1NTV1dXW1tbX19fY2NjZ 2dna2trb29vc3Nzd3d3e3t4KZW5kc3RyZWFtDWVuZG9iag0xMDY4IDAgb2JqDTw8IC9MZW5n dGggMzcgPj4gDXN0cmVhbQ0K1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb3Nzc3d3d3t7e0c7U CmVuZHN0cmVhbQ1lbmRvYmoNMTA2OSAwIG9iag08PCAvTGVuZ3RoIDM3ID4+IA1zdHJlYW0N CtbQ1NTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3buv1AplbmRzdHJlYW0NZW5kb2Jq DTEwNzAgMCBvYmoNPDwgL0xlbmd0aCAzMSA+PiANc3RyZWFtDQrU1NTV1dXW1tbX19fY2NjZ 2dna2trb29vc3Nzd3d0KZW5kc3RyZWFtDWVuZG9iag0xMDcxIDAgb2JqDTw8IC9MZW5ndGgg MzcgPj4gDXN0cmVhbQ0K2MjU1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb3Nzc3d3dz87UCmVu ZHN0cmVhbQ1lbmRvYmoNMTA3MiAwIG9iag08PCAvTGVuZ3RoIDI4ID4+IA1zdHJlYW0NCtTU 1NXV1dbW1tfX19jY2NnZ2dra2tvb29PS1AplbmRzdHJlYW0NZW5kb2JqDTEwNzMgMCBvYmoN PDwgL0xlbmd0aCAyOCA+PiANc3RyZWFtDQrU1NTV1dXW1tbX19fY2NjZ2dna2trb29vJxdQK ZW5kc3RyZWFtDWVuZG9iag0xMDc0IDAgb2JqDTw8IC9MZW5ndGggMjUgPj4gDXN0cmVhbQ0K 2L7U1NTU1dXV1tbW19fX2NjY2dnZ2traCmVuZHN0cmVhbQ1lbmRvYmoNMTA3NSAwIG9iag08 PCAvTGVuZ3RoIDI4ID4+IA1zdHJlYW0NCtbM1NTU1NXV1dbW1tfX19jY2NnZ2dra2sO71Qpl bmRzdHJlYW0NZW5kb2JqDTEwNzYgMCBvYmoNPDwgL0xlbmd0aCAyNSA+PiANc3RyZWFtDQrV z9TU1NTV1dXW1tbX19fY2NjZ2dnS0dQKZW5kc3RyZWFtDWVuZG9iag0xMDc3IDAgb2JqDTw8 IC9MZW5ndGggMjggPj4gDXN0cmVhbQ0K1NTU1dXV1tbW19bX19fX2NjY2dnZ1NPUsKvVCmVu ZHN0cmVhbQ1lbmRvYmoNMTA3OCAwIG9iag08PCAvTGVuZ3RoIDEzID4+IA1zdHJlYW0NCtTU 1NXV1dbW1tfW1gplbmRzdHJlYW0NZW5kb2JqDTEwNzkgMCBvYmoNPDwgL0xlbmd0aCAyNSA+ PiANc3RyZWFtDQrZ1tjW1tbX19fY2NjZ2dnV1dXU1NS5tdUKZW5kc3RyZWFtDWVuZG9iag0x MDgwIDAgb2JqDTw8IC9MZW5ndGggMTAgPj4gDXN0cmVhbQ0K1NTU1dXV1tXWCmVuZHN0cmVh bQ1lbmRvYmoNMTA4MSAwIG9iag08PCAvTGVuZ3RoIDI1ID4+IA1zdHJlYW0NCtnW2NbW1tfX 19jY2NnZ2dXV1dTU1Mm61QplbmRzdHJlYW0NZW5kb2JqDTEwODIgMCBvYmoNPDwgL0xlbmd0 aCAxMCA+PiANc3RyZWFtDQrV1NTU1NTV1NUKZW5kc3RyZWFtDWVuZG9iag0xMDgzIDAgb2Jq DTw8IC9MZW5ndGggMjIgPj4gDXN0cmVhbQ0K2dbY1tbW19fX2NjY1dXV1NTUzcPVCmVuZHN0 cmVhbQ1lbmRvYmoNMTA4NCAwIG9iag08PCAvTGVuZ3RoIDE2ID4+IA1zdHJlYW0NCtbW1tfX 19XV1dTU1Lq/1QplbmRzdHJlYW0NZW5kb2JqDTEwODUgMCBvYmoNPDwgL0xlbmd0aCAxMCA+ PiANc3RyZWFtDQrY1NTU1NTV1NUKZW5kc3RyZWFtDWVuZG9iag0xMDg2IDAgb2JqDTw8IC9M ZW5ndGggMTYgPj4gDXN0cmVhbQ0K1dXV1tbW19fX1NTU1MzVCmVuZHN0cmVhbQ1lbmRvYmoN MTA4NyAwIG9iag08PCAvTGVuZ3RoIDcgPj4gDXN0cmVhbQ0K1NTU19TVCmVuZHN0cmVhbQ1l bmRvYmoNMTA4OCAwIG9iag08PCAvTGVuZ3RoIDE2ID4+IA1zdHJlYW0NCtfV19XV1dbW1tTU 1NS11gplbmRzdHJlYW0NZW5kb2JqDTEwODkgMCBvYmoNPDwgL0xlbmd0aCAxMyA+PiANc3Ry ZWFtDQrZ1NTU1NTV1NXb1NYKZW5kc3RyZWFtDWVuZG9iag0xMDkwIDAgb2JqDTw8IC9MZW5n dGggMTMgPj4gDXN0cmVhbQ0K1dXV1tbW1NTU1MrVCmVuZHN0cmVhbQ1lbmRvYmoNMTA5MSAw IG9iag08PCAvTGVuZ3RoIDEwID4+IA1zdHJlYW0NCtfU1NTU1NfU1QplbmRzdHJlYW0NZW5k b2JqDTEwOTIgMCBvYmoNPDwgL0xlbmd0aCAxNiA+PiANc3RyZWFtDQrYsNjV1dXU1NTU09TU xdUKZW5kc3RyZWFtDWVuZG9iag0xMDkzIDAgb2JqDTw8IC9MZW5ndGggMTAgPj4gDXN0cmVh bQ0K1dTU1NTU39TXCmVuZHN0cmVhbQ1lbmRvYmoNMTA5NCAwIG9iag08PCAvTGVuZ3RoIDEz ID4+IA1zdHJlYW0NCtei19TU1NXV1dTG1QplbmRzdHJlYW0NZW5kb2JqDTEwOTUgMCBvYmoN PDwgL0xlbmd0aCAxMCA+PiANc3RyZWFtDQrZ1NTU1NTX1NUKZW5kc3RyZWFtDWVuZG9iag0x MDk2IDAgb2JqDTw8IC9MZW5ndGggMTMgPj4gDXN0cmVhbQ0K1dTV1NTU1dXV1LvVCmVuZHN0 cmVhbQ1lbmRvYmoNMTA5NyAwIG9iag08PCAvTGVuZ3RoIDEzID4+IA1zdHJlYW0NCuLU1NfU 1NTU1N3U1QplbmRzdHJlYW0NZW5kb2JqDTEwOTggMCBvYmoNPDwgL0xlbmd0aCAxNiA+PiAN c3RyZWFtDQrXxtfV09XU1NTUwtXUr9YKZW5kc3RyZWFtDWVuZG9iag0xMDk5IDAgb2JqDTw8 IC9MZW5ndGggMTMgPj4gDXN0cmVhbQ0K4s/R2dPU1NTU19fTCmVuZHN0cmVhbQ1lbmRvYmoN MTEwMCAwIG9iag08PCAvTGVuZ3RoIDEzID4+IA1zdHJlYW0NCqfZ2MbW1tTU1NjV1wplbmRz dHJlYW0NZW5kb2JqDTExMDEgMCBvYmoNPDwgL0xlbmd0aCAxMyA+PiANc3RyZWFtDQq7wNvY zdbU1NTC19UKZW5kc3RyZWFtDWVuZG9iag0xMTAyIDAgb2JqDTw8IC9MZW5ndGggMTAgPj4g DXN0cmVhbQ0K3cfT1NTU2tfRCmVuZHN0cmVhbQ1lbmRvYmoNMTEwMyAwIG9iag08PCAvTGVu Z3RoIDEwID4+IA1zdHJlYW0NCrXW1tTU1NvX2QplbmRzdHJlYW0NZW5kb2JqDTExMDQgMCBv YmoNPDwgL0xlbmd0aCAxMCA+PiANc3RyZWFtDQrd0NnU1NS4zdUKZW5kc3RyZWFtDWVuZG9i ag0xMTA1IDAgb2JqDTw8IC9MZW5ndGggMTMgPj4gDXN0cmVhbQ0K28/U1dXU1NTU183WCmVu ZHN0cmVhbQ1lbmRvYmoNMTEwNiAwIG9iag08PCAvTGVuZ3RoIDEwID4+IA1zdHJlYW0NCsnI 1dTU1NbP1QplbmRzdHJlYW0NZW5kb2JqDTExMDcgMCBvYmoNPDwgL0xlbmd0aCAxMyA+PiAN c3RyZWFtDQrV2NjT1NTU1NTD1tUKZW5kc3RyZWFtDWVuZG9iag0xMTA4IDAgb2JqDTw8IC9M ZW5ndGggMTMgPj4gDXN0cmVhbQ0K39PU1dPU1NTU183VCmVuZHN0cmVhbQ1lbmRvYmoNMTEw OSAwIG9iag08PCAvTGVuZ3RoIDEzID4+IA1zdHJlYW0NCrrD1tHT1NTU1NbT1gplbmRzdHJl YW0NZW5kb2JqDTExMTAgMCBvYmoNPDwgL0xlbmd0aCAxMCA+PiANc3RyZWFtDQrey9rU1NTC z9UKZW5kc3RyZWFtDWVuZG9iag0xMTExIDAgb2JqDTw8IC9MZW5ndGggMTAgPj4gDXN0cmVh bQ0K19TU1NTU28POCmVuZHN0cmVhbQ1lbmRvYmoNMTExMiAwIG9iag08PCAvTGVuZ3RoIDEw ID4+IA1zdHJlYW0NCsLL1dTU1N3X2gplbmRzdHJlYW0NZW5kb2JqDTExMTMgMCBvYmoNPDwg L0xlbmd0aCAxMCA+PiANc3RyZWFtDQrX0dbU1NSqu9UKZW5kc3RyZWFtDWVuZG9iag0xMTE0 IDAgb2JqDTw8IC9MZW5ndGggNyA+PiANc3RyZWFtDQrfwdTU1NQKZW5kc3RyZWFtDWVuZG9i ag0xMTE1IDAgb2JqDTw8IC9MZW5ndGggMTMgPj4gDXN0cmVhbQ0Kl7vX1dXV1NTU1dTUCmVu ZHN0cmVhbQ1lbmRvYmoNMTExNiAwIG9iag08PCAvTGVuZ3RoIDcgPj4gDXN0cmVhbQ0K3cLa 1NTUCmVuZHN0cmVhbQ1lbmRvYmoNMTExNyAwIG9iag08PCAvTGVuZ3RoIDEzID4+IA1zdHJl YW0NCtrQ1NXT1NTU1NzG0AplbmRzdHJlYW0NZW5kb2JqDTExMTggMCBvYmoNPDwgL0xlbmd0 aCAxNiA+PiANc3RyZWFtDQqzvtbW1tbV1dXU1NS/0tsKZW5kc3RyZWFtDWVuZG9iag0xMTE5 IDAgb2JqDTw8IC9MZW5ndGggMTAgPj4gDXN0cmVhbQ0K2dPY1NTUqNTVCmVuZHN0cmVhbQ1l bmRvYmoNMTEyMCAwIG9iag08PCAvTGVuZ3RoIDEzID4+IA1zdHJlYW0NCtvX1NTU1NXV1dnB 1QplbmRzdHJlYW0NZW5kb2JqDTExMjEgMCBvYmoNPDwgL0xlbmd0aCAxNiA+PiANc3RyZWFt DQrEx9bW1tbV1dXU1NTR1NYKZW5kc3RyZWFtDWVuZG9iag0xMTIyIDAgb2JqDTw8IC9MZW5n dGggMTAgPj4gDXN0cmVhbQ0K2dXY1NTUyNTUCmVuZHN0cmVhbQ1lbmRvYmoNMTEyMyAwIG9i ag08PCAvTGVuZ3RoIDEzID4+IA1zdHJlYW0NCtrU1NTU1NXV1dbW1QplbmRzdHJlYW0NZW5k b2JqDTExMjQgMCBvYmoNPDwgL0xlbmd0aCAxNiA+PiANc3RyZWFtDQrFx9fX19fW1tbV1dXU 1NQKZW5kc3RyZWFtDWVuZG9iag0xMTI1IDAgb2JqDTw8IC9MZW5ndGggMTAgPj4gDXN0cmVh bQ0K2dTY1NTU1tTUCmVuZHN0cmVhbQ1lbmRvYmoNMTEyNiAwIG9iag08PCAvTGVuZ3RoIDEz ID4+IA1zdHJlYW0NCsnU1NTU1NXV1dbW1gplbmRzdHJlYW0NZW5kb2JqDTExMjcgMCBvYmoN PDwgL0xlbmd0aCAxOSA+PiANc3RyZWFtDQqzzdjY2NjX19fW1tbV1dXU1NQKZW5kc3RyZWFt DWVuZG9iag0xMTI4IDAgb2JqDTw8IC9MZW5ndGggNyA+PiANc3RyZWFtDQq91NjU1NQKZW5k c3RyZWFtDWVuZG9iag0xMTI5IDAgb2JqDTw8IC9MZW5ndGggMTkgPj4gDXN0cmVhbQ0KntTV 0tTU1NTU1dXV1tbW19fXCmVuZHN0cmVhbQ1lbmRvYmoNMTEzMCAwIG9iag08PCAvTGVuZ3Ro IDIyID4+IA1zdHJlYW0NCrHG2NjY2NfX19bW1tXV1dTU1NXU1QplbmRzdHJlYW0NZW5kb2Jq DTExMzEgMCBvYmoNPDwgL0xlbmd0aCAxMCA+PiANc3RyZWFtDQre1dzV1NTU1NQKZW5kc3Ry ZWFtDWVuZG9iag0xMTMyIDAgb2JqDTw8IC9MZW5ndGggMTkgPj4gDXN0cmVhbQ0K09TU1NTU 1dXV1tbW19fX2NjYCmVuZHN0cmVhbQ1lbmRvYmoNMTEzMyAwIG9iag08PCAvTGVuZ3RoIDI4 ID4+IA1zdHJlYW0NCpa42NXX2dnZ2djY2NfX19bW1tXV1dTU1NXU1QplbmRzdHJlYW0NZW5k b2JqDTExMzQgMCBvYmoNPDwgL0xlbmd0aCA3ID4+IA1zdHJlYW0NCrnV4tTU1AplbmRzdHJl YW0NZW5kb2JqDTExMzUgMCBvYmoNPDwgL0xlbmd0aCAyMiA+PiANc3RyZWFtDQrN1NTU1NTV 1dXW1tbX19fY2NjZ09gKZW5kc3RyZWFtDWVuZG9iag0xMTM2IDAgb2JqDTw8IC9MZW5ndGgg MjUgPj4gDXN0cmVhbQ0KzdXY2dnZ2NjY19fX1tbW1dXV1NTU1dTVCmVuZHN0cmVhbQ1lbmRv YmoNMTEzNyAwIG9iag08PCAvTGVuZ3RoIDEwID4+IA1zdHJlYW0NCtfU19TU1MzU1AplbmRz dHJlYW0NZW5kb2JqDTExMzggMCBvYmoNPDwgL0xlbmd0aCAyNSA+PiANc3RyZWFtDQqx1NXU 1NTV1dXW1tbX19fY2NjZ2dnCzdgKZW5kc3RyZWFtDWVuZG9iag0xMTM5IDAgb2JqDTw8IC9M ZW5ndGggMjUgPj4gDXN0cmVhbQ0KucvZ2dnZ2NjY19fX1tbW1dXV1NTU19XXCmVuZHN0cmVh bQ1lbmRvYmoNMTE0MCAwIG9iag08PCAvTGVuZ3RoIDEwID4+IA1zdHJlYW0NCtrV2dTU1NPU 1AplbmRzdHJlYW0NZW5kb2JqDTExNDEgMCBvYmoNPDwgL0xlbmd0aCAyNSA+PiANc3RyZWFt DQrS1NTU1NTV1dXW1tbX19fY2NjZ2dmzvtgKZW5kc3RyZWFtDWVuZG9iag0xMTQyIDAgb2Jq DTw8IC9MZW5ndGggMjUgPj4gDXN0cmVhbQ0K1NbZ2dnZ2NjY19fX1tbW1dXV1NTU0NXdCmVu ZHN0cmVhbQ1lbmRvYmoNMTE0MyAwIG9iag08PCAvTGVuZ3RoIDEwID4+IA1zdHJlYW0NCtLU 1dTU1MjU1AplbmRzdHJlYW0NZW5kb2JqDTExNDQgMCBvYmoNPDwgL0xlbmd0aCAyMiA+PiAN c3RyZWFtDQq+1NXU1NTV1dXW1tbX19fY2NjZ2dkKZW5kc3RyZWFtDWVuZG9iag0xMTQ1IDAg b2JqDTw8IC9MZW5ndGggMjUgPj4gDXN0cmVhbQ0Kv9LZ2tra2dnZ2NjY19fX1tbW1dXV1NTU CmVuZHN0cmVhbQ1lbmRvYmoNMTE0NiAwIG9iag08PCAvTGVuZ3RoIDcgPj4gDXN0cmVhbQ0K w9XY1NTUCmVuZHN0cmVhbQ1lbmRvYmoNMTE0NyAwIG9iag08PCAvTGVuZ3RoIDM0ID4+IA1z dHJlYW0NCtLU1NTU1NXV1dbW1tfX19jY2NnZ2dra2pWk2NDU1ZjV4AplbmRzdHJlYW0NZW5k b2JqDTExNDggMCBvYmoNPDwgL0xlbmd0aCAzNCA+PiANc3RyZWFtDQrK1NbU1NTV1dXW1tbX 19fY2NjZ2dna2trb29vc3NzR1NQKZW5kc3RyZWFtDWVuZG9iag0xMTQ5IDAgb2JqDTw8IC9M ZW5ndGggMzEgPj4gDXN0cmVhbQ0K0tTV1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb3NzcCmVu ZHN0cmVhbQ1lbmRvYmoNMTE1MCAwIG9iag08PCAvTGVuZ3RoIDM3ID4+IA1zdHJlYW0NCqXU 19TU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3drU1AplbmRzdHJlYW0NZW5kb2JqDTEx NTEgMCBvYmoNPDwgL0xlbmd0aCAzNCA+PiANc3RyZWFtDQq+1NbU1NTV1dXW1tbX19fY2NjZ 2dna2trb29vc3Nzd3d0KZW5kc3RyZWFtDWVuZG9iag0xMTUyIDAgb2JqDTw8IC9MZW5ndGgg MzQgPj4gDXN0cmVhbQ0K0dTU1NTU1dXV1tbW2NjY2dnZ2tra29vb3Nzc3d3d0tTUCmVuZHN0 cmVhbQ1lbmRvYmoNMTE1MyAwIG9iag08PCAvTGVuZ3RoIDQwID4+IA1zdHJlYW0NCp3U2NTU 1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3wplbmRzdHJlYW0NZW5kb2JqDTEx NTQgMCBvYmoNPDwgL0xlbmd0aCA0MyA+PiANc3RyZWFtDQq61NbU1NTV1dXW1tbX19fY2NjZ 2dna2trb29vc3Nzd3d3e3t7f39/G1NQKZW5kc3RyZWFtDWVuZG9iag0xMTU1IDAgb2JqDTw8 IC9MZW5ndGggNDAgPj4gDXN0cmVhbQ0KztTV1NTU1dXV1tbW2NjY2dnZ2tra29vb3Nzc3d3d 3t7e39/f19fXCmVuZHN0cmVhbQ1lbmRvYmoNMTE1NiAwIG9iag08PCAvTGVuZ3RoIDQzID4+ IA1zdHJlYW0NCtHU1dTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f36LU1Apl bmRzdHJlYW0NZW5kb2JqDTExNTcgMCBvYmoNPDwgL0xlbmd0aCA0MyA+PiANc3RyZWFtDQrU 1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3Nzd3d3e3t7f39/g4ODP1NQKZW5kc3RyZWFtDWVu ZG9iag0xMTU4IDAgb2JqDTw8IC9MZW5ndGggNDMgPj4gDXN0cmVhbQ0KtdTZ1NTU1dXV1tbW 19fX2NjY2dnZ2tra29vb3Nzc3d3d3t7e39/f4ODgCmVuZHN0cmVhbQ1lbmRvYmoNMTE1OSAw IG9iag08PCAvTGVuZ3RoIDQ5ID4+IA1zdHJlYW0NCq/U2dTU1NXV1dbW1tfX19jY2NnZ2dra 2tvb29zc3N3d3d7e3t/f3+Dg4OHh4YrU1AplbmRzdHJlYW0NZW5kb2JqDTExNjAgMCBvYmoN PDwgL0xlbmd0aCA0OSA+PiANc3RyZWFtDQrK1NbU1NTV1dXW1tbX19fY2NjZ2dna2trb29vc 3Nzd3d3e3t7f39/g4ODh4eHD1NQKZW5kc3RyZWFtDWVuZG9iag0xMTYxIDAgb2JqDTw8IC9M ZW5ndGggNDkgPj4gDXN0cmVhbQ0KzdTX1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb3Nzc3d3d 3t7e39/f4ODg4eHh4uLiCmVuZHN0cmVhbQ1lbmRvYmoNMTE2MiAwIG9iag08PCAvTGVuZ3Ro IDUyID4+IA1zdHJlYW0NCsXU19TU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f 3+Dg4OHh4eLi4uPj4wplbmRzdHJlYW0NZW5kb2JqDTExNjMgMCBvYmoNPDwgL0xlbmd0aCA1 NSA+PiANc3RyZWFtDQrT1NXU1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3Nzd3d3e3t7f39/g 4ODh4eHi4uLj4+OX1NQKZW5kc3RyZWFtDWVuZG9iag0xMTY0IDAgb2JqDTw8IC9MZW5ndGgg NTggPj4gDXN0cmVhbQ0Kz9TV1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb3Nzc3d3d3t7e39/f 4ODg4eHh4uLi4+Pj5OTkxtTUCmVuZHN0cmVhbQ1lbmRvYmoNMTE2NSAwIG9iag08PCAvTGVu Z3RoIDU4ID4+IA1zdHJlYW0NCtLU1dTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e 3t/f3+Dg4OHh4eLi4uPj4+Tk5NLU1AplbmRzdHJlYW0NZW5kb2JqDTExNjYgMCBvYmoNPDwg L0xlbmd0aCA1OCA+PiANc3RyZWFtDQrP1NXU1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3Nzd 3d3e3t7f39/g4ODh4eHi4uLj4+Pk5OTl5eUKZW5kc3RyZWFtDWVuZG9iag0xMTY3IDAgb2Jq DTw8IC9MZW5ndGggNTggPj4gDXN0cmVhbQ0K0dTV1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb 3Nzc3d3d3t7e39/f4ODg4eHh4uLi4+Pj5OTk5eXlCmVuZHN0cmVhbQ1lbmRvYmoNMTE2OCAw IG9iag08PCAvTGVuZ3RoIDU4ID4+IA1zdHJlYW0NCs7U1dTU1NXV1dbW1tjY2NnZ2dra2tvb 29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5gplbmRzdHJlYW0NZW5kb2JqDTEx NjkgMCBvYmoNPDwgL0xlbmd0aCA2NCA+PiANc3RyZWFtDQq41dfU1NTV1dXW1tbX19fY2NjZ 2dna2trb29vc3Nzd3d3e3t7f39/g4ODh4eHi4uLj4+Pk5OTl5eXm5ubOwsIKZW5kc3RyZWFt DWVuZG9iag0xMTcwIDAgb2JqDTw8IC9MZW5ndGggNjcgPj4gDXN0cmVhbQ0KudXX1NTU1dXV 1tbW19fX2NjY2dnZ2tra29vb3Nzc3d3d3t7e39/f4ODg4eHh4uLi4+Pj5OTk5eXl5ubm5+fn 0MbGCmVuZHN0cmVhbQ1lbmRvYmoNMTE3MSAwIG9iag08PCAvTGVuZ3RoIDY3ID4+IA1zdHJl YW0NCrrV19TU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj 4+Tk5OXl5ebm5ufn5+jo6AplbmRzdHJlYW0NZW5kb2JqDTExNzIgMCBvYmoNPDwgL0xlbmd0 aCA2MSA+PiANc3RyZWFtDQrd1tnU1NTV1dXW1tbY2NjZ2dna2trc3Nzd3d3e3t7f39/g4ODh 4eHi4uLj4+Pk5OTl5eXm5ubn5+fo6OgKZW5kc3RyZWFtDWVuZG9iag0xMTczIDAgb2JqDTw8 IC9MZW5ndGggNjcgPj4gDXN0cmVhbQ0K4tfb1NTU1dXV1tbW19fX2NjY2dnZ2tra3Nzc3d3d 3t7e39/f4ODg4eHh4+Pj5OTk5eXl5ubm5+fn6Ojo6enp6urqCmVuZHN0cmVhbQ1lbmRvYmoN MTE3NCAwIG9iag08PCAvTGVuZ3RoIDcwID4+IA1zdHJlYW0NCtTU1NXV1dbW1tfX19jY2NnZ 2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp6erq6gpl bmRzdHJlYW0NZW5kb2JqDTExNzUgMCBvYmoNPDwgL0xlbmd0aCA3MCA+PiANc3RyZWFtDQrV 1NTU1NTV1dXW1tbY2NjZ2dna2trb29vc3Nzd3d3e3t7f39/g4ODh4eHi4uLj4+Pk5OTl5eXm 5ubn5+fo6Ojp6enq6uoKZW5kc3RyZWFtDWVuZG9iag0xMTc2IDAgb2JqDTw8IC9MZW5ndGgg NzMgPj4gDXN0cmVhbQ0K1dTU1NTU1dXV1tbW19fX2NjY2dnZ2tra3Nzc3d3d3t7e39/f4ODg 4eHh4uLi4+Pj5OTk5eXl5ubm5+fn6Ojo6enp6urq29vbCmVuZHN0cmVhbQ1lbmRvYmoNMTE3 NyAwIG9iag08PCAvTGVuZ3RoIDcwID4+IA1zdHJlYW0NCtfV1dTU1NXV1dbW1tjY2NnZ2dra 2tvb29zc3N3d3d/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp6erq6uvr6wplbmRz dHJlYW0NZW5kb2JqDTExNzggMCBvYmoNPDwgL0xlbmd0aCA3NiA+PiANc3RyZWFtDQrc19jU 1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3Nzd3d3e3t7f39/g4ODh4eHi4uLj4+Pk5OTl5eXm 5ubn5+fo6Ojp6enq6urr6+sKZW5kc3RyZWFtDWVuZG9iag0xMTc5IDAgb2JqDTw8IC9MZW5n dGggNzkgPj4gDXN0cmVhbQ0K4dna1NTU1dXV1tbW19fX2NjY2dnZ2tra3Nzc3d3d3t7e39/f 4ODg4eHh4uLi4+Pj5OTk5eXl5ubm5+fn6Ojo6enp6urq6+vr7Ozs29vbCmVuZHN0cmVhbQ1l bmRvYmoNMTE4MCAwIG9iag08PCAvTGVuZ3RoIDc2ID4+IA1zdHJlYW0NCtTU1NXV1dbW1tfX 19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4ePj4+Tk5OXl5ebm5ufn5+jo6Onp6erq 6uvr6+zs7OLi4gplbmRzdHJlYW0NZW5kb2JqDTExODEgMCBvYmoNPDwgL0xlbmd0aCA3NiA+ PiANc3RyZWFtDQrV1dXU1NTW1tbX19fY2NjZ2dna2trb29vc3Nzd3d3f39/g4ODh4eHj4+Pk 5OTl5eXm5ubn5+fo6Ojp6enq6urr6+vs7Ozt7e3e3t4KZW5kc3RyZWFtDWVuZG9iag0xMTgy IDAgb2JqDTw8IC9MZW5ndGggNzggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIkEwYcRABAMAMD99yPCiRrRzeAfAZRSWmsAMMYgorXWOee9J6IQQowxpZRzLqXUWpm5tSYi vfcxxpxzrbX3Pufce997X4ABACsnRyUKZW5kc3RyZWFtDWVuZG9iag0xMTgzIDAgb2JqDTw8 IC9MZW5ndGggNzkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwYcBABAM ALD//7OKqq3mDRICEEJIKZVSWmtjDABYa51z3ntEDCEQUYwxpZRzLqXUWltrvfcxBjPPOdda e+9zzr33vfcFGAADVEnDCmVuZHN0cmVhbQ1lbmRvYmoNMTE4NCAwIG9iag08PCAvTGVuZ3Ro IDc4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMGHEQAQDADA/fcTwYle oq/gXwgBAFJKRFRKaa2NMdZaInLOee9DCDHGlFLOuZRSa22t9d6ZeYwx51xr7b3POffe994X YAA1X0duCmVuZHN0cmVhbQ1lbmRvYmoNMTE4NSAwIG9iag08PCAvTGVuZ3RoIDgzIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMHHEcAgDACw/XfjiR2KaUcxnRUiIYCU EgAQUSmltTbGWGuJyDnnvQ8hxBhTSjnnUkqttbXGzL33Mcacc6219z7n3Hvfe58QvwADAArg ScMKZW5kc3RyZWFtDWVuZG9iag0xMTg2IDAgb2JqDTw8IC9MZW5ndGggODYgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwQcRwCAMAED/tqoBEsix9wYJ/ScExhjnHAAQ UQghpSQipZTW2hhjrXXOee9DCDHGlFLOuZRSa22t9d7HGHPOtdbe+5xz733v0ff9AgwA1etP IwplbmRzdHJlYW0NZW5kb2JqDTExODcgMCBvYmoNPDwgL0xlbmd0aCA4NiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBBxHAIAwAQP+6agE4QphhbyT0nxAYY5xzIYSU EgCUUoiotTbGWGudc977EAIRxRhTSjnnUkqttbXWex9jzDnXWnvvc869972H3/cLMADek09B CmVuZHN0cmVhbQ1lbmRvYmoNMTE4OCAwIG9iag08PCAvTGVuZ3RoIDgyIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMGFDQAgDACw///DA8NlOB/QEkIopYwxzrkQQkqp lNJaG2MAwFrrnPPehxBijCmlnHMppdbaWkPE3vsYY8651tp7n3Puve+9L8AA9bhNEQplbmRz dHJlYW0NZW5kb2JqDTExODkgMCBvYmoNPDwgL0xlbmd0aCA4NCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiQTBhQ0AIAwAsP//Ywx3CC4f0CIAIQQAKKWIyBjjnAshpJRK Ka21McZa65zz3ocQYowppZxzKaXW2nsfY8w511p773POvfe911r7AgwAzxdPbgplbmRzdHJl YW0NZW5kb2JqDTExOTAgMCBvYmoNPDwgL0xlbmd0aCA4MSAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiQTBBw4AEAwAwP//Dym1GmrH+IE7QhBCSCmVUgCgtTbGIKK11jnn vQ8hxBiJKKWUc2bmUkqttbXWex9jzDnXWnvvc8699733BRgAEmlKRAplbmRzdHJlYW0NZW5k b2JqDTExOTEgMCBvYmoNPDwgL0xlbmd0aCA4MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiQTBhQ0AIAwAsP//wwMZLoOgD9ASQiiljDHOuRBCSqmU0lobYwDAWuuc896H EGKMKaWccyml1tpaQ8Te+xhjzrnW2nufc+69770vwAD9iU1fCmVuZHN0cmVhbQ1lbmRvYmoN MTE5MiAwIG9iag08PCAvTGVuZ3RoIDkwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJBMGFDcAgEADA/RfrBA+PS5BgQRfoHUMCAIQQSikiMsY450IIKaVSSmttjLHWOue8 9yGEGGNKKedcSqm1ttZ672OMOedaa+99zrn3vvc+wF+AAQDH7lIkCmVuZHN0cmVhbQ1lbmRv YmoNMTE5MyAwIG9iag08PCAvTGVuZ3RoIDk1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJBMHHDQMhAACw/ZfIQHkDAkTvvQ9wtmYYAAAhRAhhjAkhlFLGGOdcSqmU0lob Y6y1zjnvfQghxphSyjmXUmqtrbXe+xhjzrnW2nufc+697z0hxA/8PwEGAOqWV+gKZW5kc3Ry ZWFtDWVuZG9iag0xMTk0IDAgb2JqDTw8IC9MZW5ndGggODYgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIkEwQUNACAAALD+/XBnyHAPwA8AgBAihDDGhBBKKWNMCCGlVEpp rY0x1lrnnPc+hBBjTCnlnEsptdbWWu99jDHnXGvtvc859973Huf8CzAA4NRS0gplbmRzdHJl YW0NZW5kb2JqDTExOTUgMCBvYmoNPDwgL0xlbmd0aCA5NyAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiQTBRQKAIAAAsP//j25BuhTh7sYIAgBACBFCGGNCCKWUMcY5F0JI KZVSWmtjzHVd1lrn3H3f3vsQQowxpVRKqbW21nrvY4w55/M87/uutb7v23ufc3LOvwADAOkj XZQKZW5kc3RyZWFtDWVuZG9iag0xMTk2IDAgb2JqDTw8IC9MZW5ndGggOTAgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwUUOwCAAALD//w8IroPgzn0tAABCiBDCGBNC KKWMMc65EEIppbU2xlhrnXPf93nvQwgxxpRSzrmUUmttrfXexxhzzrXW3vucc+9970kpfwEG AObfVdIKZW5kc3RyZWFtDWVuZG9iag0xMTk3IDAgb2JqDTw8IC9MZW5ndGggOTIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwUcOABEAAMD//w9B1GD1Xs47gyAEAEAI EUIYY0IIpZQxxjkXQkgplVJaa2OMtdY5932f9z6EkFLKOZdSaq2ttd77GGPOudbae59z7r3v vRjjL8AA5WpYsgplbmRzdHJlYW0NZW5kb2JqDTExOTggMCBvYmoNPDwgL0xlbmd0aCAxMDYg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwUcSgyAAAMD//ywzOYYigoCA DEV6OWf3+yEAAAghQghjfBwHIeQ8T0opY+y6Ls65EEJKed+3UkprbYx5nsda65zz3ocQYozv +6aUcs6llFpra633PsaYc6619t4/AP8CDAD88mAhCmVuZHN0cmVhbQ1lbmRvYmoNMTE5OSAw IG9iag08PCAvTGVuZ3RoIDk5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ BMFFEoAgAADA//9PQlJCSgaUvLp7HAcAAEKIEMIYn+dJCKGUMsY450IIKeV1XUoprbUxxlp7 37dzznsfQogxppSe58k5l1Jqre/7ft/XWuu9jzHmnGutvfcvwAD3114MCmVuZHN0cmVhbQ1l bmRvYmoNMTIwMCAwIG9iag08PCAvTGVuZ3RoIDExMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiQTBxxGEIAAAwP5ruiL8IMGRjApKEJDwvN0F/gAA67pCCBFCGGNCyLZt +75TSjnnQggppdbaGHMcx3me13VZa+/7fp7Hex9CiDGmlN73zTnXWr/va6313scYc07GmHOu lKKUAgv4CzAAclJmAQplbmRzdHJlYW0NZW5kb2JqDTEyMDEgMCBvYmoNPDwgL0xlbmd0aCAx MTQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwVsWhBAAAND972QWMkuI o+QZKu+Q8te9APynaQIAQAgRQvM8L8uCMV7XlRBCKWWMcc6FEFLKbduUUlprY8y+78dxWGud c977EEKMMaWUc76uq5RSa22t3ffde3+e533fMcZ5nuAHPwEGAKJvaOIKZW5kc3RyZWFtDWVu ZG9iag0xMjAyIDAgb2JqDTw8IC9MZW5ndGggMTAxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJBMFHDoAgAACw//9PhkwZAgEDGJk32+M4AAAQQoQQxvg8T0IIpZQxxjkX Qkgpr+tSSmmtjTHW2vu+nXPe+xBCjDGl9DxPzrmUUmt93/f7vtZa732MMedca+29fwEGAPyl Xk4KZW5kc3RyZWFtDWVuZG9iag0xMjAzIDAgb2JqDTw8IC9MZW5ndGggMTE1IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMHtDoUQAADQ93+3u7vdjRIRE/ORhBR+3XMg /AEAIITTNM3zjBBalgVjTAhZ15VSum0b51wIIaXc910ppbU2xlhrnXPe++M4zvOMMV7XlVLK OZdS7vuutT7P875va633PsYIITDGvh/4F2AAsFtpIwplbmRzdHJlYW0NZW5kb2JqDTEyMDQg MCBvYmoNPDwgL0xlbmd0aCAxMTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIkEwUcOhCAAAMD/P28TKRJQumBBAaXoZWcA+A3DAACAECKEMMbjOBJCKKWMsWma5nnmnAsh pJRKKa21McZauyyLc25d123b9n0/jiOEcJ7ndV0xxpRSzvm+7+d5Sim11tZa7/193+/7vPd/ AQYA6HlsbwplbmRzdHJlYW0NZW5kb2JqDTEyMDUgMCBvYmoNPDwgL0xlbmd0aCAxMDIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwUkOwBAAAMD//6+ExlpLBVG0xHLp zHEcAAAIIUIIY3yeJyGEUsoY45wLIaSU13UppbTWxhhr7X3fzjnvfQghxphSep4n51xKed/3 +77WWu99jDHnXGvtvWutvwADACCTXwgKZW5kc3RyZWFtDWVuZG9iag0xMjA2IDAgb2JqDTw8 IC9MZW5ndGggMTE3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJDMHbEoUQ AADA//++EyNScgmJmJSkh85u9+v+AAAQQoRQ3/cY42EYKKXjOE7TxBib55lzLoSQUiqllmXR WhtjrLXrujrntm3z3ocQ9n2PMaaUjuPIOZ/neV1XKeW+71rr8zyttfd9CSEQgk+AAQBG528a CmVuZHN0cmVhbQ1lbmRvYmoNMTIwNyAwIG9iag08PCAvTGVuZ3RoIDEyMCAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBCRKFEAAA0Psf498pviVlaUPRgik003tN0wAA IIQIIYwxIYRS2rYtY6zrur7vOedCCCmlUmoYhnEcp2ma53lZFq21McZau67rtm3OOe/9vu/H cZzneV1XCCHGmFK67/t5npxzKaXW+r4v+v0/AQYAUHRvVgplbmRzdHJlYW0NZW5kb2JqDTEy MDggMCBvYmoNPDwgL0xlbmd0aCAxMjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIkUwYsShBAAAMD//72buFBoPKYHohIqzc3tAvBpmgYAACFs2xYhhDEmhHRd1/c9pZQx xjkfhkEIIaVUSmmtx3Gcpmme52VZjDHWWufcuq7e+xDCtm37vh/HEWM8zzOllHMupVzXdd/3 8zy11vd9v3/gJ8AA+391DgplbmRzdHJlYW0NZW5kb2JqDTEyMDkgMCBvYmoNPDwgL0xlbmd0 aCAxMTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwYcNhCAAAMD91/oZ pAgKEkoUCWAEolLydxD8pmkCAEAIMcbzPBNCKKXLsqzryjnftk0IIaVUSmmtjTH7vh/HYa09 z9M5570PIcQYr+u67zullHMupTzP877v93211tZa732MwRhDCP0FGADI3Gn6CmVuZHN0cmVh bQ1lbmRvYmoNMTIxMCAwIG9iag08PCAvTGVuZ3RoIDEwOSAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiQTBiQ6AEAAA0P//P1dCLFmOkVWWLHoPAAAhRAgRQqZpopTO88wY 45wvyyKlVEqt66q13rbNGLPvu3POex9CiDGmlI7jyDmf53ld133fpZTneWqt7/u21r7v672P May1QgiM8S/AALb8Z5YKZW5kc3RyZWFtDWVuZG9iag0xMjExIDAgb2JqDTw8IC9MZW5ndGgg MTI0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMEJEkUgAADQ+1/pn6O0 KDHFtE0SkWz/PQp+AAAIYdM0CCGMMSGEUtq2LWOMcy6E6Pt+GAYppVJqHMdpmrTW1lrnnPc+ hDDPc4xxWZaU0rqu27blnPd9P46jlHKeZ631uq77vp/ned/3+z5jTNd1mMC/AAMA+Rd1Mwpl bmRzdHJlYW0NZW5kb2JqDTEyMTIgMCBvYmoNPDwgL0xlbmd0aCAxMTkgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwQkSQCAAAMD//w9RUY0OR1MKqRC7VVXVdd00DQCg bduu6yCECCGMcd/3hBBKKWNsHEfOuRBCSqmUmqZpWZZ1XbXWxhhr7bZtzjnv/b7vx3Gc5xlC uK4rxphSyjnf9/08z/u+pZTv++Z5HobhF2AAuzty+gplbmRzdHJlYW0NZW5kb2JqDTEyMTMg MCBvYmoNPDwgL0xlbmd0aCAxMjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIkEwYkShBAAAND//7ydSY4UDZoco0tKon2P/WDTNACAtm0hhAghjDEhpOs6Smnf94wxzvk4 jkIIKaVSapqmeZ6NMdZa55z3flmWdV23bdv3/TiOEMJ5njHG67ru+04pPc+Tc37ft5RSa/2+ T2s9DMNfgAEAqv1yzAplbmRzdHJlYW0NZW5kb2JqDTEyMTQgMCBvYmoNPDwgL0xlbmd0aCAx MTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwe0OhRAAAND3f7v7I0Ly sdJUhkYWonvOMAwAAAghQghjTAiZpolSOs8z51wIIaVclmVdV6XUtm1a6+M4zvM0xlhrnXPe ++u6Qggxxvu+U0rP8+ScSym11vd9W2u99+/79n1njI3jiH/oL8AAO0RtCwplbmRzdHJlYW0N ZW5kb2JqDTEyMTUgMCBvYmoNPDwgL0xlbmd0aCAxMDkgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIkEwYkOgBAAAND//z9XQixZjpFVlsR6DwAAIUQIEUKmaaKUzvPMGOOc L8sipVRKreuqtd62zRiz77u11jnnvQ8hxBhTSsdx5JzP87yu677vUsrzPLXW931ba733Mcb3 fUIIjPEvwACvbWeNCmVuZHN0cmVhbQ1lbmRvYmoNMTIxNiAwIG9iag08PCAvTGVuZ3RoIDEy NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBWxKFEAAA0P2v7M7cb0Re NckoSi9JxXQO/v0BABBChBDGmBBS1zWllDHGORdCSCmbpmnbtus6pVTf91prY8wwDOM4Wmud c9M0zfPsvV+WZV3Xfd+P4wghnOcZY7yuK6V03/fzPO/75pxLKdu2VVXFGPoEGAD04nUGCmVu ZHN0cmVhbQ1lbmRvYmoNMTIxNyAwIG9iag08PCAvTGVuZ3RoIDExOCAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBCRJAIAAAwP//T6aUdKPLkRCZsds0DQCgbVsIIUKo 6zqMMSGk73tK6TAMjDHOuZRSKaW1NsZM0zTPs7XWOee9DyHEGJdlWdd127Z931NKx3HknM/z vK7rvu9SyvM87/vWWr/vE0KM4wgh+AUYALu/cnAKZW5kc3RyZWFtDWVuZG9iag0xMjE4IDAg b2JqDTw8IC9MZW5ndGggMTE4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ BMHLAkQgAADA//+5PZUtRIVSSkjR42DmD34AAAhh0zQIIYxx27Z93xNChmEYx5FSyhjjnE/T NM/zsixCCCnluq5KKa31tm3GGGvtvu/OueM4zvO8rst7f993CCHG+DzP+74ppZxzKaXW2nXd J8AARYVvbQplbmRzdHJlYW0NZW5kb2JqDTEyMTkgMCBvYmoNPDwgL0xlbmd0aCAxMDMgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwUkOwBAAAMD//w9Bal8qrWitQS+d AQBACBFCGGNCCKX0OA7GGOdcCCGlVEpprY0x1lrnnPf+PM8QwnVd933HGFNKz/O875tzrrW2 1nrvY4w551pr7/19XykFIfgLMABCvWGJCmVuZHN0cmVhbQ1lbmRvYmoNMTIyMCAwIG9iag08 PCAvTGVuZ3RoIDExNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBWRaA EAAAwPvfL0seabGUKEtEfprhBAzDAACAECKEMMbjOBJCKKWMsWmaOOfzPC/Lsq7rtm1CCCml Ukprve+7MeY8T2utc+66rvu+vfchhBhjSul5npxzKeV931pra+37vt77cRy/AAMA8VRsggpl bmRzdHJlYW0NZW5kb2JqDTEyMjEgMCBvYmoNPDwgL0xlbmd0aCAxMDYgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwdkSgBAAAMD//76QczCVUeQYZ57aRdsGAIAQIoT2 fccYE0IopYwxzrkQQkqplNJaH8dxnud1XcYYa+1938/zOOe89+/7hhBijCmlnHMppdbaWuu9 jzHmnN/3rbUgBL8AAwBDl2PDCmVuZHN0cmVhbQ1lbmRvYmoNMTIyMiAwIG9iag08PCAvTGVu Z3RoIDEwNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTB2RKAEAAAwP// P2fkGCWVQTnz1C4AAEKIEMIYE0IopcuyMMY45+u6SimVUlprY8y2bfu+W2uP43DOned5Xdd9 3977EEKMMaX0PM/7vjnnUkqttbXWex9jfN835xRC/AIMAFgmZCcKZW5kc3RyZWFtDWVuZG9i ag0xMjIzIDAgb2JqDTw8IC9MZW5ndGggMTA3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJBMFHDoQgAADA/39vQxOkF40UJTS97QwAAEKIEMIYE0K2baOUMsb2feecCyGk lEoprbUxxlrrnPPehxCO4zjP87quGGNKKedcSrnv+3meWmtrrfc+xphzrrXe9/2+D/7gX4AB AELwY5EKZW5kc3RyZWFtDWVuZG9iag0xMjI0IDAgb2JqDTw8IC9MZW5ndGggMTEyIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMHZEkAgAADA//88M4oOSYdQqXTIm91p GsZxBABACOd5RghhjAkhlNJlWRhj67pyzrdtE0JIKZVSWut9340xx3Fc12Wtdc557+/7DiHE GFNKz/PknEsptdbW2vu+vffv+87zBAP4BRgAqmlpGwplbmRzdHJlYW0NZW5kb2JqDTEyMjUg MCBvYmoNPDwgL0xlbmd0aCA5NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iQTBSQ7AEAAAwP//z1YhSFGx7xw7AwCAECKEMMaEkOd5KKWMMc65EEJKqZR631drbYyx1n7f 55zz3ocQYowppZxzKaXW2lrrvY8x5pxrrb33Oefe+wswAPLzWS8KZW5kc3RyZWFtDWVuZG9i ag0xMjI2IDAgb2JqDTw8IC9MZW5ndGggMTA3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJBMHHEYQgAADA/ou78UMUAQmKhCGL39sl2wYAgBAihDDGhBBK6b7vjLHjODjn UsrzPJVSWmtjjLX2uq77vp1zz/N470MIMcaUUs65lFJrba313scYc873fdda3/cJIX4b/Asw ADCoYvMKZW5kc3RyZWFtDWVuZG9iag0xMjI3IDAgb2JqDTw8IC9MZW5ndGggMTA2IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMHJAoQQAADQ//+zuY8lS3aKEJFz70Hw BwBACBFCGONt2wghlFLGGOd833chhJRSKaW1NsZYa51z3vsQwnmeMcaU0nVdOedSSq31vu/W Wu/9eZ4xxpzzfd+11nEcP4w+AQYAKl5i3wplbmRzdHJlYW0NZW5kb2JqDTEyMjggMCBvYmoN PDwgL0xlbmd0aCA5NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBSRLE EAAAwP9/bwaF2IOy7+7pBgBACBFCGGNCCKX0eR7GGOdcSqmU0lobY973tdY657z3IYQYY0op 51xKaa313scYc8611t77nHPvrbUKIX5/8AkwAO6YWEsKZW5kc3RyZWFtDWVuZG9iag0xMjI5 IDAgb2JqDTw8IC9MZW5ndGggMTA0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJDMHHAYMgAADA/YfIINkjFEGaNOlN/uYOwd8fAABCiBDCGB/HQQihlJ7nyRjjnAshpJRK Ka21McZa65zz3t/3HWNMKeWcSym11tZa732MMedcaz3Ps/cOIVzX9fniV4ABAAneX7sKZW5k c3RyZWFtDWVuZG9iag0xMjMwIDAgb2JqDTw8IC9MZW5ndGggOTcgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwcURxCAAAMD+e8vvcAnOYMELuF0IfgAACCFCCGNMCKGU MsaEEFLK932VUlprY4y11jnnvQ8hxBhTSjnnUkqttbX2fV/vfYwx51xr7b3POfdezvnzwL8A AwDZVlphCmVuZHN0cmVhbQ1lbmRvYmoNMTIzMSAwIG9iag08PCAvTGVuZ3RoIDg2IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMGHDQAQAACw//9DEHvvfYAWAAAhRAhh jAkhlFLGGOdcSqmU0lobY6y1zjnvfQghxphSyjmXUmqtrbXe+xhjzrnW2nufc+697z0hxBdg AO/RUxcKZW5kc3RyZWFtDWVuZG9iag0xMjMyIDAgb2JqDTw8IC9MZW5ndGggODcgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwYcJwCAQAMD9lwq4g769PBZExbpA7iil jDEA4JwLIaSUSimttTHGWuuc896HEBAxxphSyjmXUmqtrbXe+xhjzrnW2nufc+697z3ywS/A APTmTMkKZW5kc3RyZWFtDWVuZG9iag0xMjMzIDAgb2JqDTw8IC9MZW5ndGggOTQgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwccNxCAQAMD+O3AlV4Z1D0AsGZFzqMAz 6PcihDDGhBBKKQAwxjjnQggppVJKa22MsdY657z3IYQYY0op51xKqbW21nrvY4w551pr733O ufc+f/gEGADBpVHmCmVuZHN0cmVhbQ1lbmRvYmoNMTIzNCAwIG9iag08PCAvTGVuZ3RoIDkw IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMG1EcAwEACw/ddKlSbdmxnP DBtEgu8FAIQQxpgQQilljHHOhRBSSqWU1toYY611znnvQwgxxpRSzrmU0lrrvY8x5pxrrb33 OefeW2t9AP8CDAC5nlHCCmVuZHN0cmVhbQ1lbmRvYmoNMTIzNSAwIG9iag08PCAvTGVuZ3Ro IDg2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJBMEHEcAgEAAw/xJqAy3A PRuevZHQhFLKGOOcA4AQQkqplNJaG2Ostc45730IIcaYUso5l1Jqra213vsYY8651tp7n3Pu ve89RPwI/AIMAPswTG0KZW5kc3RyZWFtDWVuZG9iag0xMjM2IDAgb2JqDTw8IC9MZW5ndGgg ODQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwccRwCAMALD9V8sbm3J0 0/sIkRhjAICInHMhhJRSKaW1NsZYa51z3vsQQoyRiFJKOedSSq21tdZ7H2PMOddae+9zzr33 vfch/AIMAPTxTLMKZW5kc3RyZWFtDWVuZG9iag0xMjM3IDAgb2JqDTw8IC9MZW5ndGggNzkg Pj4gDXN0cmVhbQ0K1NTU1dXV1tbW2NjY2dnZ2tra29vb3Nzc3d3d3t7e39/f4ODg4eHh4+Pj 5OTk5eXl5ubm5+fn6Ojo6enp6urq6+vr7Ozs7e3t7u7u7+/vCmVuZHN0cmVhbQ1lbmRvYmoN MTIzOCAwIG9iag08PCAvTGVuZ3RoIDg5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJBMHHDcAgEACw/ZfIKPlkgki0Q7Sjd1bA/j8khFBKGWOccyEEAEgplVJaa2OMtdY5 h4je+xBCjDGllHMupdRaW2u99zHGnHOttfc+5zwvXAEGAOMoTBgKZW5kc3RyZWFtDWVuZG9i ag0xMjM5IDAgb2JqDTw8IC9MZW5ndGggODUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIkEwckNwCAMALD9d+oCfVaCAAFEwn3PUPt7SQghpQQApZTW2hiDiNZa55z3PoRA RMwcY0wp5ZxLKbXW1lrvfYwx51xr7b3POffeB+EXYAAAHEl+CmVuZHN0cmVhbQ1lbmRvYmoN MTI0MCAwIG9iag08PCAvTGVuZ3RoIDgzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJBMHHEcAgDACw/XfL5RNswEczvc8Q6XtICAEAiCilVEpprYnIGGOtdc5570MIzBxj TCnlnEsptdbWWu99jDHnXGvtvc85994X4RdgAAH2SZMKZW5kc3RyZWFtDWVuZG9iag0xMjQx IDAgb2JqDTw8IC9MZW5ndGggNzMgPj4gDXN0cmVhbQ0K1NTU1dXV1tbW19fX2NjY2dnZ2tra 29vb3Nzc3d3d3t7e39/f4ODg4eHh4+Pj5OTk5eXl5ubm5+fn6Ojo6enp6urq6+vr7OzsCmVu ZHN0cmVhbQ1lbmRvYmoNMTI0MiAwIG9iag08PCAvTGVuZ3RoIDc5ID4+IA1zdHJlYW0NCtTU 1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4ePj4+Tk5OXl5ebm5ufn 5+jo6Onp6erq6uvr6+zs7OLi4qHd2AplbmRzdHJlYW0NZW5kb2JqDTEyNDMgMCBvYmoNPDwg L0xlbmd0aCA3NiA+PiANc3RyZWFtDQrU1NTV1dXW1tbX19fY2NjZ2dna2trc3Nzd3d3e3t7f 39/g4ODh4eHi4uLj4+Pk5OTl5eXm5ubn5+fo6Ojp6enq6urr6+vs7OzF2NYKZW5kc3RyZWFt DWVuZG9iag0xMjQ0IDAgb2JqDTw8IC9MZW5ndGggNzYgPj4gDXN0cmVhbQ0K1NTU1dXV1tbW 19fX2NjY2dnZ2tra29vb3Nzc3d3d3t7e39/f4ODg4eHh4uLi4+Pj5OTk5eXl5ubm5+fn6Ojo 6enp6urq6+vr1dXUCmVuZHN0cmVhbQ1lbmRvYmoNMTI0NSAwIG9iag08PCAvTGVuZ3RoIDY3 ID4+IA1zdHJlYW0NCtTU1NXV1dbW1tjY2NnZ2dra2tvb29zc3N3d3d/f3+Dg4OHh4eLi4uPj 4+Tk5OXl5ebm5ufn5+jo6Onp6erq6uvr6wplbmRzdHJlYW0NZW5kb2JqDTEyNDYgMCBvYmoN PDwgL0xlbmd0aCA3MCA+PiANc3RyZWFtDQrU1NTV1dXW1tbX19fY2NjZ2dna2trc3Nzd3d3e 3t7f39/g4ODh4eHi4uLj4+Pk5OTl5eXm5ubn5+fo6Ojp6enq6urh39gKZW5kc3RyZWFtDWVu ZG9iag0xMjQ3IDAgb2JqDTw8IC9MZW5ndGggNzAgPj4gDXN0cmVhbQ0K1NTU1dXV1tbW2NjY 2dnZ2tra29vb3Nzc3d3d3t7e39/f4ODg4eHh4uLi4+Pj5OTk5eXl5ubm5+fn6Ojo6enp6urq 3NfWCmVuZHN0cmVhbQ1lbmRvYmoNMTI0OCAwIG9iag08PCAvTGVuZ3RoIDczID4+IA1zdHJl YW0NCtTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk 5OXl5ebm5ufn5+jo6Onp6erq6tfP1QplbmRzdHJlYW0NZW5kb2JqDTEyNDkgMCBvYmoNPDwg L0xlbmd0aCA3MCA+PiANc3RyZWFtDQrU1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3Nzd3d3e 3t7f39/g4ODh4eHj4+Pk5OTl5eXm5ubn5+fo6Ojp6enq6urV1NQKZW5kc3RyZWFtDWVuZG9i ag0xMjUwIDAgb2JqDTw8IC9MZW5ndGggNjEgPj4gDXN0cmVhbQ0K1NTU1dXV1tbW2NjY2dnZ 2tra3Nzc3d3d3t7e39/f4ODg4eHh4uLi4+Pj5OTk5eXl5ubm5+fn6Ojo1dTUCmVuZHN0cmVh bQ1lbmRvYmoNMTI1MSAwIG9iag08PCAvTGVuZ3RoIDY0ID4+IA1zdHJlYW0NCtTU1NXV1dbW 1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo 6AplbmRzdHJlYW0NZW5kb2JqDTEyNTIgMCBvYmoNPDwgL0xlbmd0aCA2NCA+PiANc3RyZWFt DQrU1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3Nzd3d3e3t7f39/g4ODh4eHi4uLj4+Pk5OTl 5eXm5ubn5+firtgKZW5kc3RyZWFtDWVuZG9iag0xMjUzIDAgb2JqDTw8IC9MZW5ndGggNjEg Pj4gDXN0cmVhbQ0K1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb3Nzc3d3d3t7e39/f4ODg4eHh 4uLi4+Pj5OTk5eXl5ubm3a3WCmVuZHN0cmVhbQ1lbmRvYmoNMTI1NCAwIG9iag08PCAvTGVu Z3RoIDU4ID4+IA1zdHJlYW0NCtTU1NXV1dbW1tjY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg 4OHh4eLi4uPj4+Tk5OXl5ebm5trG1gplbmRzdHJlYW0NZW5kb2JqDTEyNTUgMCBvYmoNPDwg L0xlbmd0aCA2MSA+PiANc3RyZWFtDQrUv93U1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3Nzd 3d3e3t7f39/g4ODh4eHi4uLj4+Pk5OTl5eXa1dYKZW5kc3RyZWFtDWVuZG9iag0xMjU2IDAg b2JqDTw8IC9MZW5ndGggNjEgPj4gDXN0cmVhbQ0K1Lrg1NTU1dXV1tbW19fX2NjY2dnZ2tra 29vb3Nzc3d3d3t7e39/f4ODg4eHh4uLi4+Pj5OTk5eXl2tbWCmVuZHN0cmVhbQ1lbmRvYmoN MTI1NyAwIG9iag08PCAvTGVuZ3RoIDU1ID4+IA1zdHJlYW0NCtTU1NXV1dbW1tfX19jY2NnZ 2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj4+Tk5M/V1QplbmRzdHJlYW0NZW5kb2Jq DTEyNTggMCBvYmoNPDwgL0xlbmd0aCA1NSA+PiANc3RyZWFtDQrU1NTV1dXW1tbX19fY2NjZ 2dna2trb29vc3Nzd3d3e3t7f39/g4ODh4eHi4uLj4+Pk5OTU1NUKZW5kc3RyZWFtDWVuZG9i ag0xMjU5IDAgb2JqDTw8IC9MZW5ndGggNTIgPj4gDXN0cmVhbQ0K1NTU1dXV1tbW19fX2NjY 2dnZ2tra3Nzc3d3d3t7e39/f4ODg4eHh4uLi4+Pj29vb1NTVCmVuZHN0cmVhbQ1lbmRvYmoN MTI2MCAwIG9iag08PCAvTGVuZ3RoIDU1ID4+IA1zdHJlYW0NCtXU1NTU1NXV1dbW1tfX19jY 2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj49TU1gplbmRzdHJlYW0NZW5kb2Jq DTEyNjEgMCBvYmoNPDwgL0xlbmd0aCA1MiA+PiANc3RyZWFtDQrX0tTU1NTV1dXW1tbX19fY 2NjZ2dna2trb29vc3Nzd3d3e3t7f39/g4ODh4eHi4uLU1NUKZW5kc3RyZWFtDWVuZG9iag0x MjYyIDAgb2JqDTw8IC9MZW5ndGggNDkgPj4gDXN0cmVhbQ0KvtTU1NTU1dXV1tbW19fX2NjY 2dnZ2tra29vb3Nzc3d3d3t7e39/f4ODg4eHh1NTTCmVuZHN0cmVhbQ1lbmRvYmoNMTI2MyAw IG9iag08PCAvTGVuZ3RoIDQ2ID4+IA1zdHJlYW0NCtTU1NXV1dbW1tfX19jY2NnZ2dra2tvb 29zc3N3d3d7e3t/f3+Dg4OHh4dTV0gplbmRzdHJlYW0NZW5kb2JqDTEyNjQgMCBvYmoNPDwg L0xlbmd0aCA0MyA+PiANc3RyZWFtDQrU1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3Nzd3d3e 3t7f39/g4ODV1c8KZW5kc3RyZWFtDWVuZG9iag0xMjY1IDAgb2JqDTw8IC9MZW5ndGggNDYg Pj4gDXN0cmVhbQ0Kw9XV1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb3Nzc3d3d3t7e39/f4ODg 1dXPCmVuZHN0cmVhbQ1lbmRvYmoNMTI2NiAwIG9iag08PCAvTGVuZ3RoIDQzID4+IA1zdHJl YW0NCrHX2NTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f39bW2gplbmRzdHJl YW0NZW5kb2JqDTEyNjcgMCBvYmoNPDwgL0xlbmd0aCAzNyA+PiANc3RyZWFtDQrU1NTV1dXW 1tbY2NjZ2dna2trb29vc3Nzd3d3e3t7f39/X1tcKZW5kc3RyZWFtDWVuZG9iag0xMjY4IDAg b2JqDTw8IC9MZW5ndGggMzcgPj4gDXN0cmVhbQ0K1dXV1NTU1tbW19fX2NjY2dnZ2tra29vb 3Nzc3d3d3t7e39/fCmVuZHN0cmVhbQ1lbmRvYmoNMTI2OSAwIG9iag08PCAvTGVuZ3RoIDQz ID4+IA1zdHJlYW0NCsHa1NTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f39TU 0QplbmRzdHJlYW0NZW5kb2JqDTEyNzAgMCBvYmoNPDwgL0xlbmd0aCAzNCA+PiANc3RyZWFt DQrU1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3Nzd3d3V1NQKZW5kc3RyZWFtDWVuZG9iag0x MjcxIDAgb2JqDTw8IC9MZW5ndGggMzcgPj4gDXN0cmVhbQ0K2dfW1NTU1dXV1tbW19fX2NjY 2dnZ2tra29vb3Nzc3d3d1tTUCmVuZHN0cmVhbQ1lbmRvYmoNMTI3MiAwIG9iag08PCAvTGVu Z3RoIDMxID4+IA1zdHJlYW0NCtTU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3NjU1AplbmRz dHJlYW0NZW5kb2JqDTEyNzMgMCBvYmoNPDwgL0xlbmd0aCAzNCA+PiANc3RyZWFtDQrS1dTU 1NTV1dXW1tbX19fY2NjZ2dna2trb29vc3NzU0tQKZW5kc3RyZWFtDWVuZG9iag0xMjc0IDAg b2JqDTw8IC9MZW5ndGggMzEgPj4gDXN0cmVhbQ0K1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb 3Nzc1cjUCmVuZHN0cmVhbQ1lbmRvYmoNMTI3NSAwIG9iag08PCAvTGVuZ3RoIDI4ID4+IA1z dHJlYW0NCtDY19TU1NXV1dbW1tfX19jY2NnZ2dra2taz1AplbmRzdHJlYW0NZW5kb2JqDTEy NzYgMCBvYmoNPDwgL0xlbmd0aCAyNSA+PiANc3RyZWFtDQrU1NTV1dXW1tbX19fY2NjZ2dna 2trU0NQKZW5kc3RyZWFtDWVuZG9iag0xMjc3IDAgb2JqDTw8IC9MZW5ndGggMjUgPj4gDXN0 cmVhbQ0KzNzc1NTU1dXV1tbW19fX2NjY2dnZ1cLUCmVuZHN0cmVhbQ1lbmRvYmoNMTI3OCAw IG9iag08PCAvTGVuZ3RoIDMxID4+IA1zdHJlYW0NCtTU1NTV2dTU1dXV1dbW1tfX19jY2NnZ 2drl2tTT1AplbmRzdHJlYW0NZW5kb2JqDTEyNzkgMCBvYmoNPDwgL0xlbmd0aCA3ID4+IA1z dHJlYW0NCtTU1NTU1QplbmRzdHJlYW0NZW5kb2JqDTEyODAgMCBvYmoNPDwgL0xlbmd0aCAy MiA+PiANc3RyZWFtDQrU1NTV1dXW1tbX19fY2NjZ2dnZ3d0KZW5kc3RyZWFtDWVuZG9iag0x MjgxIDAgb2JqDTw8IC9MZW5ndGggMTkgPj4gDXN0cmVhbQ0K2NjY19fX1tbW1dXV1NTU1MDU CmVuZHN0cmVhbQ1lbmRvYmoNMTI4MiAwIG9iag08PCAvTGVuZ3RoIDcgPj4gDXN0cmVhbQ0K zN7E1NTUCmVuZHN0cmVhbQ1lbmRvYmoNMTI4MyAwIG9iag08PCAvTGVuZ3RoIDI1ID4+IA1z dHJlYW0NCtTV1NTU1NXV1dbW1tfX19jY2NnZ2djZ2QplbmRzdHJlYW0NZW5kb2JqDTEyODQg MCBvYmoNPDwgL0xlbmd0aCAxNiA+PiANc3RyZWFtDQrY3t3W1tbV1dXU1NTU09QKZW5kc3Ry ZWFtDWVuZG9iag0xMjg1IDAgb2JqDTw8IC9MZW5ndGggMTAgPj4gDXN0cmVhbQ0K19fU1NTU 1NTGCmVuZHN0cmVhbQ1lbmRvYmoNMTI4NiAwIG9iag08PCAvTGVuZ3RoIDIyID4+IA1zdHJl YW0NCtTU19TU1NXV1dbW1tfX19jY2Nne3AplbmRzdHJlYW0NZW5kb2JqDTEyODcgMCBvYmoN PDwgL0xlbmd0aCAxNiA+PiANc3RyZWFtDQrX2trW1tbV1dXU1NTSzNQKZW5kc3RyZWFtDWVu ZG9iag0xMjg4IDAgb2JqDTw8IC9MZW5ndGggNyA+PiANc3RyZWFtDQrW1tXU1NQKZW5kc3Ry ZWFtDWVuZG9iag0xMjg5IDAgb2JqDTw8IC9MZW5ndGggMjIgPj4gDXN0cmVhbQ0K1NTV1NTU 1dXV1tbW19fX2NjY19nYCmVuZHN0cmVhbQ1lbmRvYmoNMTI5MCAwIG9iag08PCAvTGVuZ3Ro IDEzID4+IA1zdHJlYW0NCtXW1tXV1dTU1NLS1AplbmRzdHJlYW0NZW5kb2JqDTEyOTEgMCBv YmoNPDwgL0xlbmd0aCAyMiA+PiANc3RyZWFtDQrU1NPU1NTV1dXW1tbX19fW19XY49wKZW5k c3RyZWFtDWVuZG9iag0xMjkyIDAgb2JqDTw8IC9MZW5ndGggNyA+PiANc3RyZWFtDQrV1dXU 1NQKZW5kc3RyZWFtDWVuZG9iag0xMjkzIDAgb2JqDTw8IC9MZW5ndGggNyA+PiANc3RyZWFt DQrU1NTU1LwKZW5kc3RyZWFtDWVuZG9iag0xMjk0IDAgb2JqDTw8IC9MZW5ndGggMTYgPj4g DXN0cmVhbQ0K1NTT1NTU1dXV1tbW197BCmVuZHN0cmVhbQ1lbmRvYmoNMTI5NSAwIG9iag08 PCAvTGVuZ3RoIDEwID4+IA1zdHJlYW0NCtTU1NXU1NTM1AplbmRzdHJlYW0NZW5kb2JqDTEy OTYgMCBvYmoNPDwgL0xlbmd0aCA3ID4+IA1zdHJlYW0NCtTU1NTUzQplbmRzdHJlYW0NZW5k b2JqDTEyOTcgMCBvYmoNPDwgL0xlbmd0aCAxMyA+PiANc3RyZWFtDQrU1NTV1dXW1tbX3cIK ZW5kc3RyZWFtDWVuZG9iag0xMjk4IDAgb2JqDTw8IC9MZW5ndGggNyA+PiANc3RyZWFtDQrU 1NTS1NQKZW5kc3RyZWFtDWVuZG9iag0xMjk5IDAgb2JqDTw8IC9MZW5ndGggMTAgPj4gDXN0 cmVhbQ0K0tXW1NTU1NTNCmVuZHN0cmVhbQ1lbmRvYmoNMTMwMCAwIG9iag08PCAvTGVuZ3Ro IDEwID4+IA1zdHJlYW0NCtTU1NXV1dbZzAplbmRzdHJlYW0NZW5kb2JqDTEzMDEgMCBvYmoN PDwgL0xlbmd0aCAxMCA+PiANc3RyZWFtDQrU1dTU1NTQ1NQKZW5kc3RyZWFtDWVuZG9iag0x MzAyIDAgb2JqDTw8IC9MZW5ndGggMTAgPj4gDXN0cmVhbQ0K1NbP1NTU1MjPCmVuZHN0cmVh bQ1lbmRvYmoNMTMwMyAwIG9iag08PCAvTGVuZ3RoIDEzID4+IA1zdHJlYW0NCtTM0tTU1NXV 1dbZ0QplbmRzdHJlYW0NZW5kb2JqDTEzMDQgMCBvYmoNPDwgL0xlbmd0aCAxMCA+PiANc3Ry ZWFtDQrV2dTU1NTN1NQKZW5kc3RyZWFtDWVuZG9iag0xMzA1IDAgb2JqDTw8IC9MZW5ndGgg MTAgPj4gDXN0cmVhbQ0K09nR1NTU1MXGCmVuZHN0cmVhbQ1lbmRvYmoNMTMwNiAwIG9iag08 PCAvTGVuZ3RoIDEwID4+IA1zdHJlYW0NCtS9zdTU1NXbzwplbmRzdHJlYW0NZW5kb2JqDTEz MDcgMCBvYmoNPDwgL0xlbmd0aCAxMyA+PiANc3RyZWFtDQrV3NXU1NTV1NTQ1NQKZW5kc3Ry ZWFtDWVuZG9iag0xMzA4IDAgb2JqDTw8IC9MZW5ndGggNyA+PiANc3RyZWFtDQrU1NTUusMK ZW5kc3RyZWFtDWVuZG9iag0xMzA5IDAgb2JqDTw8IC9MZW5ndGggNyA+PiANc3RyZWFtDQrU 1NTW4cMKZW5kc3RyZWFtDWVuZG9iag0xMzEwIDAgb2JqDTw8IC9MZW5ndGggNyA+PiANc3Ry ZWFtDQrU1NTY1tQKZW5kc3RyZWFtDWVuZG9iag0xMzExIDAgb2JqDTw8IC9MZW5ndGggMTAg Pj4gDXN0cmVhbQ0K2NfW1NTU1MzLCmVuZHN0cmVhbQ1lbmRvYmoNMTMxMiAwIG9iag08PCAv TGVuZ3RoIDEwID4+IA1zdHJlYW0NCtS9wtTU1NXYzQplbmRzdHJlYW0NZW5kb2JqDTEzMTMg MCBvYmoNPDwgL0xlbmd0aCAxMCA+PiANc3RyZWFtDQrV29XU1NTU1dQKZW5kc3RyZWFtDWVu ZG9iag0xMzE0IDAgb2JqDTw8IC9MZW5ndGggMTAgPj4gDXN0cmVhbQ0K2NXV1NTU1LrACmVu ZHN0cmVhbQ1lbmRvYmoNMTMxNSAwIG9iag08PCAvTGVuZ3RoIDEzID4+IA1zdHJlYW0NCtTP ztTU1NTV1NXd0AplbmRzdHJlYW0NZW5kb2JqDTEzMTYgMCBvYmoNPDwgL0xlbmd0aCAxMyA+ PiANc3RyZWFtDQrU19XU1NTV1NTR2NQKZW5kc3RyZWFtDWVuZG9iag0xMzE3IDAgb2JqDTw8 IC9MZW5ndGggMTAgPj4gDXN0cmVhbQ0K2NXV1NTU1MXQCmVuZHN0cmVhbQ1lbmRvYmoNMTMx OCAwIG9iag08PCAvTGVuZ3RoIDEwID4+IA1zdHJlYW0NCtTP0NTU1NXL1QplbmRzdHJlYW0N ZW5kb2JqDTEzMTkgMCBvYmoNPDwgL0xlbmd0aCAxMCA+PiANc3RyZWFtDQrU19XU1NTS19UK ZW5kc3RyZWFtDWVuZG9iag0xMzIwIDAgb2JqDTw8IC9MZW5ndGggMTAgPj4gDXN0cmVhbQ0K 3NXW1NTU3dXdCmVuZHN0cmVhbQ1lbmRvYmoNMTMyMSAwIG9iag08PCAvTGVuZ3RoIDEwID4+ IA1zdHJlYW0NCtTAudTU1NXB1gplbmRzdHJlYW0NZW5kb2JqDTEzMjIgMCBvYmoNPDwgL0xl bmd0aCAxMCA+PiANc3RyZWFtDQrUw9XU1NTT2dUKZW5kc3RyZWFtDWVuZG9iag0xMzIzIDAg b2JqDTw8IC9MZW5ndGggMTMgPj4gDXN0cmVhbQ0K2NTU1NTU2NXJ4da/CmVuZHN0cmVhbQ1l bmRvYmoNMTMyNCAwIG9iag08PCAvTGVuZ3RoIDEzID4+IA1zdHJlYW0NCtTFz9TU1NPHz9Wr wgplbmRzdHJlYW0NZW5kb2JqDTEzMjUgMCBvYmoNPDwgL0xlbmd0aCAxMyA+PiANc3RyZWFt DQrUztXU1NTU19XR3NYKZW5kc3RyZWFtDWVuZG9iag0xMzI2IDAgb2JqDTw8IC9MZW5ndGgg ODMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkMwYUBwCAMALD/b9obQ4uW 4vbCluDz/hhjnHMhhJRSKaW1BgBjjLXWOee9DyHEGBExpUREOedaa2ttjDHnXGvtvc85vfdS yr33E2AA3UpMcAplbmRzdHJlYW0NZW5kb2JqDTEzMjcgMCBvYmoNPDwgL0xlbmd0aCA5OCAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQzBhQHDIAAAsP/f25BCcSluhQO2 5PMFfxBChBDG+LouQgil9L5vzrkQQkqplNJaG2Ostd7753lCCDHGnHMppdbaWuu9jzHmnGut 93333ueclJJzjjGGAPgJMADxLV0kCmVuZHN0cmVhbQ1lbmRvYmoNMTMyOCAwIG9iag08PCAv TGVuZ3RoIDExMiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQzByRGDIAAA wP4LSguZyV8O5UYF5RAQkK/Z/YDpDwAAIUQIzfO8LAshhDHGORdCSCmVUlrrdV23bdv33Rhj rT2OwznnvQ8hxBiv60op5ZxLKfd911pba73353nGGOd5UkoxxtP39wowAGrtZZQKZW5kc3Ry ZWFtDWVuZG9iag0xMzI5IDAgb2JqDTw8IC9MZW5ndGggMTE3IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJBMFZAoQQAADQ+99pjkEpoU0oO1H6mfcA+AEAIIRd1/V9jxAa hmEcR4zxNE2EEEopY2ye52VZ1nXdtm3fd875cRxCCCmlUuo8z+u6tNbGGOec9z6EEGNMKeWc 7/supdRan+d537e1Zq39vu8vwAAST27pCmVuZHN0cmVhbQ1lbmRvYmoNMTMzMCAwIG9iag08 PCAvTGVuZ3RoIDEyNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBhxGD IAAAwP3nySoIR7EgHewFRUXzD8APAFAUBYQQIYQxJoRQShljZVlWVVXXddM0nPO2bYUQUkql lNbaGGOtdc5570MIXdf1fT8MwziO0zTN87wsy7qu27bt+34cx3meKaXruu77fp4n5/y+b4zx +76/AAMAOg54OgplbmRzdHJlYW0NZW5kb2JqDTEzMzEgMCBvYmoNPDwgL0xlbmd0aCAxMjcg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwQkSRSAAAND7H+/PlF2rtSRS FMl/D4AfAABCmGVZnudFUZRlWVVVXddN07RtixDCGBNCKKWMMc5513V93w/DMI7jNE1CCCnl sixKqXVdtdbbtu37boyx1jrnzvO8rst7H0K47/t5nhjj+74ppe/7juOY5/kvwACmZHrgCmVu ZHN0cmVhbQ1lbmRvYmoNMTMzMiAwIG9iag08PCAvTGVuZ3RoIDEyNiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBCQKEEAAAwP+/b+nO2UlSoihpZwAAEMIsy/I8L4qi LMuqquq6bpqmbVuEEMaYEEIpZYxxzruu6/t+HMdpmoQQUsplWZRSWutt2/Z9N8ZYa51z53le 1+W9v+/7eZ4Y4/u+3/ellEIIx3Gs6zrP8zAM4Af+AgwA2sd64gplbmRzdHJlYW0NZW5kb2Jq DTEzMzMgMCBvYmoNPDwgL0xlbmd0aCAxMjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIkEwYkWhBAAAMD//7zdVV6HozuSEB1IOwPADwCQZVme5xDCoijKsqyqqq5rhBDG mBBCKW2apm3bruv6vh+GYRzHaZrmeeacL8sihFjXVUq5bZtSSmttjNn33VrrnDuO4zzP67ru +/behxBijM/zpJTe92WMgc/3L8AAv/x60QplbmRzdHJlYW0NZW5kb2JqDTEzMzQgMCBvYmoN PDwgL0xlbmd0aCAxMjUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwYcR gyAAAMD9t8kEmYIiTaSKXVQU253/AAAIIUIIY0wIoZQyxjjnQoiyLKWUVVVprY0x1lrnnPe+ rusQQtM0bdt2Xdf3/TAM0zTN8xxjXJZl27aU0r7vx3HknM/zvK7rvu/ned73XddVKVUUxTiO 4P/7BBgAE6x0sgplbmRzdHJlYW0NZW5kb2JqDTEzMzUgMCBvYmoNPDwgL0xlbmd0aCAxMDMg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwdkSgBAAAMD//78wuWNI0SQ3 T+1u2wYAgBAihPZ9xxgTQiiljDHOuRBCSqmU0lobY87zdM7d9+29DyE8z/O+b4zx+76UUs65 lFJrba313scYc8611nVd1trjOH4BBgBJjWGWCmVuZHN0cmVhbQ1lbmRvYmoNMTMzNiAwIG9i ag08PCAvTGVuZ3RoIDEwOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTB WQKEEAAA0Ptfac6BZI+yZIuUPuc9AACEECG0LMu6roQQSinnXAghpVRKbdumtTbG7Pt+HIe1 1jnnvQ8hnOcZY0wp5ZxLKbXW67paa733+77HGM/zvO875/y+jzGGMQbg9xdgAI8EZh0KZW5k c3RyZWFtDWVuZG9iag0xMzM3IDAgb2JqDTw8IC9MZW5ndGggMTAzIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJBMFHEoMgAADA/z8rh0w+AFKlFwGlyj27388PAAAhPI4D IYQxJoRQShljnPPzPIUQUkqllDHGWuuc896HEGKM13XlnEsp930/z9Na672PMeaca633fffe KSWtda31L8AA2OFdWQplbmRzdHJlYW0NZW5kb2JqDTEzMzggMCBvYmoNPDwgL0xlbmd0aCA4 NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBAwEAMAAAsP79bttO8A0A ACFECGGMCSGUUsYY51xKqZTSWhtjrLXOOe99CCHGmFLKOZdSaq2ttd77GGPOufc+59x733tr LSHEF2AA1xdSeAplbmRzdHJlYW0NZW5kb2JqDTEzMzkgMCBvYmoNPDwgL0xlbmd0aCA4NyAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBxRHAMAwAsP2H6l1/XSDoMDgM K1T63ocQQilljHHOpZQAoJTSWhtjrLXOOe99CCHGmFLKOSNiKaXW2lrrvY8x5pxrrb33Oefe K4T4BRgA1hFMQwplbmRzdHJlYW0NZW5kb2JqDTEzNDAgMCBvYmoNPDwgL0xlbmd0aCA4MiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQTBBxHAMAgAQP+mqoJMMsmRPSz0 HwCEEFJKpZTW2hhjrUVE730IIcaYUiKiUgoz11pba733Mcacc6219z7n3Hvfezln59wH8Asw ABUkSbkKZW5kc3RyZWFtDWVuZG9iag0xMzQxIDAgb2JqDTw8IC9MZW5ndGggNzkgPj4gDXN0 cmVhbQ0K1NTU1dXV1tbW19fX2NjY2dnZ2tra29vb3Nzc3d3d3t7e39/f4ODg4eHh4uLi4+Pj 5OTk5eXl5+fn6Ojo6enp6urq6+vr7Ozs7e3t5ubmCmVuZHN0cmVhbQ1lbmRvYmoNMTM0MiAw IG9iag08PCAvTGVuZ3RoIDc5ID4+IA1zdHJlYW0NCtTU1NXV1dbW1tfX19jY2NnZ2dra2tvb 29zc3N3d3d7e3t/f3+Dg4OLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp6erq6uvr6+zs7OHh4ajU 1AplbmRzdHJlYW0NZW5kb2JqDTEzNDMgMCBvYmoNPDwgL0xlbmd0aCA3MyA+PiANc3RyZWFt DQrU1NTV1dXW1tbX19fZ2dna2trb29vc3Nzd3d3e3t7f39/g4ODh4eHi4uLj4+Pk5OTl5eXm 5ubn5+fo6Ojp6enq6urY2Nif1dQKZW5kc3RyZWFtDWVuZG9iag0xMzQ0IDAgb2JqDTw8IA0v VHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgODk4IA0vQ2FwSGVpZ2h0IDAgDS9EZXNj ZW50IC0yMTAgDS9GbGFncyA0IA0vRm9udEJCb3ggWyAwIC0yMTEgMTM1OSA4OTkgXSANL0Zv bnROYW1lIC9DTE1LT0YrV2luZ2RpbmdzLVJlZ3VsYXIgDS9JdGFsaWNBbmdsZSAwIA0vU3Rl bVYgMCANL0ZvbnRGaWxlMiAxMzQ1IDAgUiANPj4gDWVuZG9iag0xMzQ1IDAgb2JqDTw8IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNjAyMyAvTGVuZ3RoMSAxMDIyOCA+PiANc3Ry ZWFtDQpIidxXC1QTVxqePIGkvAzRtUvxAqUIhDABgwKihhBwLCSYhJjaVk3ChIzmRWYAqSgQ LYJWS1vFJxW1VVGsj+Jje1qXHntEqVB8VWSturJutT6qFt+geweKoK275+w5u2fPzpx7Zu5/ v/+/3/0f+ScIA0EQHlKKsBCQqsHSJ5m7b0BJPYIE+JkKKPBZTF0dfP8SQTiJZmeu7ZuupJ0I Mvw+grCn51qLzN63iRkIEqaHOsUW3JBzZKFZiyDhEI/EW6BgiIC3FEGC6PVXLTZqNpayqBLO ixGEVWF1mAzCNKEY6p9EEMYhm2G2k6XjRkL9tRAPnC7cqWoKn44gIWyIh3YRRu9NPxHBA/gM QHovwS3ULbjO9Yosn1h+z5vhwax1C85BUQeTwZD4oC9xPftWmBwOgs7g8qK4DDbDPZrJYNeq 0SxUNEgSuCGoNBAZ23urECNCIg7EiuAIBcc4+kbBs/bYfu7hW1tuRZSPF4m8V4zMeN1U6/Yd j7qZjXBEMAMElQ3HFl3e/M1X0qY1SyqaRzRrdB+g3k+5MtiQUtnHkhHoK1xWNpsnGKrDXYSG yLUDrSufpIASpwodrlmSYaiQBvAFPv0AEcDsJrFEhEb2LYQOaBI2HGgog81J2HOBBncVECYc qB0OSjIKje1DRylVIAOTpWAZmPYNIJPLFVlaRaoIjDRFJIwGz+6BBg3zThiNSiWx6GgUXlPh NEESGyf5dfq/f4CydYN9zuAgrLIl0O+VzLIy5IQY3LQUi6LFZYG7uLs38/f5e0/p0LTndx6J i9x98q7Xm6N+uVL12Oultr/8ceqfWn68W7GrpnFh2NW5ej9y5uxv84Q9h/R3I7bpp1Wze6KN /vqywOa8ZadC9DGnjgZwFsR/sWxrQ+akKzeSQrbrVs0LXmstb5yUvmJmw6b4U91e0ScaEtYw WTCpn0sJFuSV6L/2Xc6441dKH805VddVX9TN6V6enBdaFzXy/HsCvPKxaCHj/amrjc3+m0u7 9h0I2HdMt2qWp1FxaMOnHdISTsg5VzS7nLO52GvoRwHym/eGZn7vsXSNn1X/mCdd0Vy57jzb uTZyrmHp15f5eau3NJmNKcnLl4XErgypXPQwx/PVO8cfwvxtgSOeKUS+8l/dIb8e/ChNv6Cy Oa2iKuxGwIz/vySul4SjYX2Gg/45jf6T8l940n+LYr9/eL/xjz/qSy94CDwxO4W77DiFltX8 JqUXwygspFN6m+F6w/YlVelVZxv8pxFneSXGKq6kpfVJxQdpp7HEZVdOcsfXbN8we+q1B90m hWo/347+vCF+W7TX+VuO8G3ek2dwpKqSVq2qbZ8opZ3ftmT/tCd7S9s6qxtKQrAUP+uJlTsZ uo0HvxOvS+wq2aLfdDoEv/TettlrvzyTnmJ5M3puzx4mg/U7CW2b8WjV9E+Iz0/McUYZQ4NS weQdocImivkAux3+8lv15XlSz6i775+7sKf68uLNr3eShyd61ezsWNwh/LCZdckrTMf9UflJ +qfHpqSdHKO7E9xy8LWk6LDY1jUX/zwh/ad2W3rBpUZ0o29pa0l70rzaB8sjJVHCh4cDrv+w 80q2zJkWLZqHur02weFby2IymEy/InO1ff7Otr2MIfaaxgY8bzBjJkxow+94/cURikMlfQGP fJoRcofNhrtMhMEKNA4zVWhw4SAr32glSAvuIoFc1puSY9BRkngUfZqS9DQ2TpogTZiKuhlv /8dJSNLQ1D6l5MLCQnEBVCShotjksMXADuwgCcrhKoqRZ2noPRwupxgYi4AaN4tFdF6LM7Sp dC7HS8ahY/vsSFOJXIKCG2KpQG41kCSIA9EgkzC5HCSkMMBDZ7ASOQaKcNhBQayEj3rR+lwB M1sjEaD+9MRTwJtiIC2w9CiHXeKH+vS5wkON59gc9hxJEBpIS1gBwgHzcsjR4eo127/Of8E6 dDB4vorcDG8Eyj2ZbgYDaag6/tqWnL9fFR58YpsjU/EeOCLzWsV/0GyKjb9w0vJXaQ82pL26 G/9OEwAOsI+8c+eI07bs2tHPd0Siq2P1xXvrZoXlrmq8WPgT59LPndX3tvOHb/ps7ALnxfuO t1RzHb5qxSLhafxsEuB0Jq+3rkj04YcJrgd/C5YmvGOczzkS+nK3uqa+JqP69FilPtk954aX VLfH0pii2JAk2fioffmj7CbRlo0HI1StXR/dZI2Yc0uYWHd/a9Z8js14c7GgYsyZzkAf8mvu hC9GHrza8mFe0wHz7vXakO/5ucX3FxZV1pt5Wyc/7HEFd5e/fahrks81vSE0s21XYs4FwcfT Dr9ryxi6I9kDFvJGN+cH1M050xudVwRsJoqgfPrVl81mMTm1aFkFPWOwy0rReaV+c6r/dkze Y1n5y5ij9qTbfPd603+hkNwcZgP8KkSDaSZsBuMJexgagNJffgNfdkNZTI9SBEYbQnhsLgrJ cyegbnb8IAyPVnWzQ6F4RG1EabiFopxkYkzMvyiM9W7W/jI3q0FrIUhgwl0UYSZMBgoHRG/B 0MmGk3TVuHAz7sLtJlwEDPYcQFAkyCchjAQk5SJMlLWIR+YbZ+ImClAOEaAsOBhwwlO7dL1k uQwmim6IsDVRuA23U2AkZBLBgzRJGiARo3CTAgNhNRitNJNnrQ0cABioRN6LDppEs1ZE26AZ iANwh2gXnpePkxQ54Vmcw8WD0H7gszEVgVhpQhwMowF2SFkBDgWZjnw7ZYCsdAReKIIhBAmj 0FFxvGyNDOKcRS4i10LRTVKSkBD/nDkAZFYrUNMIEv4QkbAn4zliIFeotTJMyZsiU6tlSi2m 0IBUTCPPkGGZilQgU6YO6sMZWCYG27CYR6OVmDI9EWgnKkC2RgFUafAV0/Saw9IwuUyrAHCq 0aoxuTbjDaDJTpmkkGuBVkWr8HQKNQb/OCkH4TGVEmSpZXItJldAPWggU6HUQtr0FphGkw33 A7Js7USVGnLh9ZPU9J8AYJlZGdivnBX6LLVCo/kH89UeFtVxxWfmvpYFAq6AiEYvbEBUWBcF 8YlQdlcgiDwFNOiyvAOyuCCfSEoBCSIIKqKt1AiaavAVl64apKapWBCj+ZQajPhKtfbTWqG1 UdGqoefeVUDSfF//6pf97d07c+bMmXPOnDNzlh+yCpwQFhgaoxKkDFGloPcidWRgEHRfW7k4 ktcER4cJ0zXQDuDDA0DHwJjQgEg+PCYyfHGU2kNcJDY4NJQPWxwt/ZladFKoWpwQuDgsSh0R A8oHB4R6wJSw4OjgJa/mvFZ2MVgVyasCFgUsVEcp+Ci1WirYKdwXggyVGrhCo8DTgXrI/WzY Mn3qyFhMy8iFYyElmc/WZwthlZqRkhxlToSAPMgM3WpIIGnKGpgvBnd+YtbqFD43PRHiIFuf x+tS+CQ9DCWLQhJz+cSkpNUGcwam6g0rxZyR5puvG+CASBU0CA5QSD+eWez9v6T5a3qWPk2v SMtIVZYcEU4Sni75RFmsLGYtteVBuPypGnMYA8GdlcCpwjBwgjqM/1H54CSlbpCTKJco7R1G nIdKKFaw0/zXxEm5omczhm7iwTOFz8pI1Cn4rDzIhTerSyR+lA7DTrpxtETJwmkH3xF1j1Cp bQvdUxBzNe+9Kte2ffw/s1pMhZrCXQ1rW1exQfaylPMJk59GzN2wqvmR3aw1Vzd9alk8c3NC 0C/b0Sxp1Bf+vgOVoyetRAu9+4NCFYZ/dVwqeqnSu2zqqm34S13v3QF0tq3PML5nJ5V9/FRS 4fQ1qrm7Pqx8Xlbu6664u2+Wr1/ri+9K5V6l9AQ4g53AdOXq/8P98V+KQStWYnYKYRjUWNKk HDvoJQvKa/jFQkONMdSz9Bpx7SgnDk2kvWS0bcpUh6Kvl68I23z6y6Jqm4vHlaHD2K2EMqpR VmyLYlEGykZpKNn83u1W/I4QR6/CaOXrckaMo7yCHH2aITEnvWBkOUOXYmTpHxJ8y6q9eONN iWKUIV97IvIXqvsX3OvWH1s4uX5eWnavrPbJ857iFvmk6Y2ZurG79br6sUvaznwy2TuopnnM vi05m7rWtx9RX3vPQ7d9wNFvJ9Ww/P323Br2H0kPXsqYVhddeZ4p/7Z1UE23rjut4/StCX9s erH2no1j5/yBKZ41+XjbM+++Dds2b/HN/NU0N+2F5bXrSr445+5kKIp3bqrY8c0Yk+uls4d8 z/mtWPbi0sHL2oabE/P+NKbgXNH+9NLW79/i9rd89rtCqGZujF3x57J5i5Y+OLMpvPbYtwsl 262z47oHbtAV77rVXfGVzenzyDk7M866uuJUTXf9tuqC3mjdFbvAM4bdpfgiVHTnh/aB9SrF nwPphBBgJS0/+f+uxB59Pqr+amCv83NNXNmGLzUVm1377LQjgjRe6Tg8Ri0HOxyGEB0cYbxs xL8dvl5KLx+f6T6zlv4gRGtTXypsiyv7Z0d2ddy67b58ZFCVFDsfLo94ZjF1xwtu0hH9N9Kv b7tWd/6705Z9fvlvscfDg3soa9e+789aP3TUWn212m7+ltASU4Cy0/Ny/8Ucqapm9uyU7v60 Z5VFoxQub1/feoCZu7CAtPSQVXslRx89/NhPZ7J/7KpzabG9H9LakeBYNlMTptK6Pa/d499S 72a1y/4Jg36Cn64fHfECJOE4UkKWQuvXSAe/9fAkw7MD1aE6YjLzoBnwGKEVgu4ynWg6Moj0 GegD+FWhp7gJlYuUeUgH4zrgboe3H4wlwRuLMurwRvH9c1QGsh8SE2kjbeLoApAbInCYQUxM J9AFeevQp+gm/gPwFKKtMHYCdQmzQHIdOoz6sTugCv8V95JwoGJhfZCTCdx1oO/vUQ/6Dtth P1yJTwKPjJSIuphXKwaedkCXKEXAIpyF9diAN4DMO4QiPiBVTypIIzGSNiqe9mM6WRnry2WB FIwIotAosFCQFoaiYGUdWjUo1YyLmOAIHI3T8XbcCDq0417AI+JJFoDXBWyjtLQVfY/JZPYA OtkY7iMJC7IZxCInxCNX5A1WqWGNCNA5Gb2P1oooBHwAvixFDagR7Ub7UTNqRaeENdE1dBP1 g3dsAIJdvng2jgXEAwy4CJeBP6qGoRrvxCbcCvqdw91kIlhtRhZYb9ZyHaknR8k5cp58S+6Q ++QhhSgLagWlo3KpvdQB6gJ1gQ6iG+nd9HX6OoMZo+gpGWvHJrBVgI2cBZfJlXFbuI+441IF GgN2eYBdIXCfJKECsOQDVIEqxV1rBhxFxwCd6L5gB2DglSUCZmMV1uAYQDxeirV4Jc7FawYt +g3eh5vwUbClG3AFX8O38N9xn4h+whIHMnXQvnASRWJJJtlOdpCd5CBEpImcJFfITbDxDnkM NlpSMsqemkCpKQ0gmlpGraHWUYepNuoa1Qv7ZkXPp/3oGDoBbO+g79D3YCcJQzGujA8zB5DO ZDNFTBWzCyK6l+llrUSvyNjR7Fx2PdvAmtge9iVnzzlwLgAF58VFcVlcPneAu8PdlRyyCLDI sDBIPdABpESfjcjeYxDdp0kCOw054WsQDasoG+DihdwjVlyWRQYxCdpxUdgdduoG6qcs0Lt0 B4qllqEsRkdZcg9QE86lS/BBSoMOob1cPj5Jaaleai/jys41+5PUUwe4Ak7L3QVNH1FbmXRO gQOYKtxEFkBGG3AEeoIfo+Wwch6ZgjrQBlSB85EE1UkOYWvItXYyEVcxe6jf0o2UminCk2EH xzGd1IfIB9kjK+SOXCDWGWQHD/L3neXrPWO6l3KawtNj6pTJ7pPcXN+RuzjzEye8PX6c01jH MQ72dqNlo2xt3rK2spRaSDiWoaESRR5quUbLG920RtpNHhTkKfTliUBIHEbQGnkgad7kMfJa kY1/k9MfOFNHcPqbOf0HObEtPw/N8/Tg1XLe+JVKzrfgpRFx0K5WyeN5Y6/YXiS2aTexYw0d Z2eYwasd01W8EWt5tVGTn16p1qpAXrOlNFAemCL19EDNUktoWkLLqJHnNGONHxYbRKOe00yQ xBq0MobIVWpjsFwlqGCkXNWJycbwiDi1apyzc7ynhxH/h/2yi42qiOL4md3t3um20G1py4ZF vcu1jWHblIJI+SpLv9t9cIFq9iIJ2y9CiRGeMIAha5CAt8WsgvFJPoJAQVZmKeKWYGiiKJEH Q4IYxQSD+Aa+YaKGrv+5s1vbiuiDLybe3d/9z5xz7sycmdneaWOP0S3IaBBFQTuEGu1uhLtR aHY3er9Mhwb0VNWoNZj2UncsWNhr9Hatiwpnlyn7KA6KVqNJtG6/46uuSrPjnVGR35hm1Bkd oY5MPNUeb2oyZW8ljdE9dvhMhM/cfsfvtJp9/bqsWtYeXRxeFZ3oDci7aaLR6qrw6mgAozaa B3WZxuqonQEaZb4aDFLaZJoq4T6jWVpim3SRbzQYG61NMSzWLEvQ6m2Bs7M6QiOZ76mjWbc6 o0ZArPAbZlfT7FQpWau3DbeH9PbJnuqqlLdYzXRqelG2UDhtYqFv3GeX7HBZwqhzU83kiIx2 bBGh9+gYSdQQjoo6eeurI6unDmG4TIYZ7cf8xSzvErkQeRVeQ7fuEzaCce/uZEtX1uKu8N4n WZTbZXzLwZ8ri2BQzJ0rd4rWiKXFyOrt+sLqqq0ibGzx6iKMKaNIFA+ZS2ow5YGAXOWBdIi6 URHxVVFV16nbf5ZCNUFTOGLSM5rzlD0nPfGcZ/zxmIHtfA6vQ6IywSvHv0Xe8hnNG5cIVv4I d5/y4+fTrKdceRVWJFrZZQ34K2PWoImlacFP0bJaDL3Filld6Uy829C9hpUKh60tzbFcSunM 6IBfhAbNjQyTKhao2RAzGqNOv8NUJYffaVaTHIdWOxYhKhgkynzpuWWPbOJ120V4h+NyAy6p p478p+iApx+MUodWSQfyL1LSeYou89OU1OZQMr8oy3pFwR4wSEl+mZKeS5TMe0chY12bwTX4 cILR3qYOfhhtvoZyQPltZLkVduAapqQ7iuf7FNrrClevQsa7L9HzOfgPiGuD7Sr6OA+/HxTA 9jRsr0LL6IC7nQ7k+sr7JcsVgDG7X4C9LDuOuWos+SG0hXFraI+PQJGf9jJ4E/UF0JdUrnw3 nl8O3UDDniDtdWHuJLm+MJ8dU6ibxA7E7JgyF/8yOAMmnSdVznY/Uzmk+Ls4l4y7MzGGebO+ aygXPbRtG9Y9xbbnr2P/Gbx7Cjjbc7V/ax+Fx4396VZrbq/75Ha/Hi/fyJKtuxdOhluKcf9v kxm3v0KXJXKN7fJK6AScN6nHWUY9vJV6Q4XU0oIcSop5qE1PO5452zYfsssWdlrJ+0pOKhlS ckLJUSVHlBxS0q6kTUmrkgYlISX1SpYpWazErcSlxKmEhZ6Ffgdugm/BDfAJOA8+BGdAEpwG Q+AEOAQOgnfBINgFesB6u80zqumkklNKjis5puQ9JQeVNClZqWS5kjolmpI8JQ4lFApBvwFf gSvgc/AZuAw+AufAMPgAHAZvgW2gt21+aX5p/qJEmm0NtWuJI1piv5bYpyU2a4kXtcQGLdGn JdZpibVawtQSUe1JPofr/HE+m8/iPl7OS3kJ9/LpvJB7OOdu7uIOjj0qZjjDjvCaBhYWoz0U 7tbFz2uMNPOsWivyjAYmSsIU7mzwibqgcOy1Tx5plkkx9sZuvzx0jBBjmd37/Fk1TSoP/vny TaqFI9su0hNsEWm4LxjWnvhUk9Y1sCZsa0JaE7bVx85GaH64ayD2GD2k4T8u9kjvpMjmfplu JJri1GA2rlM67CjwIJ+YP2A2lHu31NvJLQ34dvovuIgNUQHevYU4zE0D0lW9snqldOGNJV3T 5Tkv6/LtXBrwX2BDWZcX5mJMJf6vxLvNGcffeieSNEJF2nXmus6OErkylJdxjrAfiWrG7nnv 0YqfcK+dt6A4UFwRKA7EnfQg7qAxyrvya13cdUW+S5PsouOBqxBtlX5MzLEIv1Yn60ED9/Ct nTcDjyYdEQRFHgj5Sq38/4NP/X/6Y5+h6DYrpBraR9Oxo7woLYb5rms9fMz2O+Iw136xvmjZ fe7n9sHqWHL/mNTUVe060VjEc0urRbUwdwL7fQCgvzSGCmVuZHN0cmVhbQ1lbmRvYmoNMTM0 NiAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9DSURGb250VHlwZTIgDS9CYXNl Rm9udCAvQ0xNS09GK1dpbmdkaW5ncy1SZWd1bGFyIA0vRm9udERlc2NyaXB0b3IgMTM0NCAw IFIgDS9DSURTeXN0ZW1JbmZvIDw8IC9SZWdpc3RyeSAoQWRvYmUpL09yZGVyaW5nIChJZGVu dGl0eSkvU3VwcGxlbWVudCAwID4+IA0vRFcgMTAwMCANL1cgWyAxMzEgWyA0NTcgXSBdIA0+ PiANZW5kb2JqDTEzNDcgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAy MTYgPj4gDXN0cmVhbQ0KSIlUULtuwzAM3PUVHFN0kOx2NLwki4c+ULvZFYl2BMSUQMuD/76S ayfIQBI88nBHymNzashFkN/sTYsRekeWcfIzG4QLDo6gKME6E7duzWbUAWQit8sUcWyo91BV Qv6k4RR5gUPXFcWregH5xRbZ0ZCg9/L3nJB2DuGGI1IEBXUNFnshjx86fOoRQf4zH2i3BIRy 7YtN3VucgjbImgaESin1Vu8FyT7Pd9alN1fN4rFdqlqk7Q3PvHzV3YiZmZPH9fTVSLbgCO/f CT5ktRziT4ABAG8/asIKZW5kc3RyZWFtDWVuZG9iag0xMzQ4IDAgb2JqDTw8IA0vVHlwZSAv QW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDI1Ny45NDAyNSAzODMuNTAzMzYgMzA2 LjQxMTk5IDM5Ny4xNTA0NSBdIA0vQm9yZGVyIFsgMCAwIDAgXSANL0ggL0kgDS9BIDEzNDkg MCBSIA0vU3RydWN0UGFyZW50IDcgDT4+IA1lbmRvYmoNMTM0OSAwIG9iag08PCANL1MgL1VS SSANL1VSSSAobWFpbHRvOmhvc3RAdXNlcikNPj4gDWVuZG9iag0xMzUwIDAgb2JqDTw8IA0v VHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDIxMC4wNTk0OCAzNjAuNTIz NSAyNTguNjExOTQgMzc0LjE3MDU5IF0gDS9Cb3JkZXIgWyAwIDAgMCBdIA0vSCAvSSANL0Eg MTM1MSAwIFIgDS9TdHJ1Y3RQYXJlbnQgOCANPj4gDWVuZG9iag0xMzUxIDAgb2JqDTw8IA0v UyAvVVJJIA0vVVJJIChtYWlsdG86dXNlckBob3N0KQ0+PiANZW5kb2JqDTEzNTIgMCBvYmoN PDwgDS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyAxNzYyIDAgUiANL0sgMCANL1AgMTcw MSAwIFIgDT4+IA1lbmRvYmoNMTM1MyAwIG9iag08PCANL05vcm1hbCAvUCANL1RpdGxlIC9Q IA0vQm9keSMyMFRleHQgL1AgDS9UZXh0Qm94IC9EaXYgDS9GcmFtZSAvRGl2IA0vRm9vdG5v dGUgL05vdGUgDS9FbmRub3RlIC9Ob3RlIA0vU2hhcGUgL0ZpZ3VyZSANL0lubGluZVNoYXBl IC9GaWd1cmUgDS9UT0EgL1RPQyANL1RPQUkgL1RPQ0kgDS9UT0YgL1RPQyANL1RPRkkgL1RP Q0kgDS9TdXBlcnNjcmlwdCAvU3BhbiANL1N1YnNjcmlwdCAvU3BhbiANL1N0cmlrZW91dCAv U3BhbiANL1VuZGVybGluZSAvU3BhbiANL0Ryb3BDYXAgL0ZpZ3VyZSANPj4gDWVuZG9iag0x MzU0IDAgb2JqDTw8IA0vTm9ybWFsIDEzNTUgMCBSIA0vVGl0bGUgMTM2NCAwIFIgDS9Cb2R5 IzIwVGV4dCAxNDA2IDAgUiANPj4gDWVuZG9iag0xMzU1IDAgb2JqDTw8IA0vTyAvTGF5b3V0 IA0vV3JpdGluZ01vZGUgL0xyVGIgDS9TdGFydEluZGVudCAwIA0vRW5kSW5kZW50IDAgDS9U ZXh0QWxpZ24gL1N0YXJ0IA0vU3BhY2VCZWZvcmUgMCANL1NwYWNlQWZ0ZXIgMCANL1RleHRJ bmRlbnQgMCANPj4gDWVuZG9iag0xMzU2IDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQSBbIDEz NTcgMCBSIF0gDS9DIC9Ob3JtYWwgDS9QZyAxNzYyIDAgUiANL0sgMSANL1AgMTcwMSAwIFIg DT4+IA1lbmRvYmoNMTM1NyAwIG9iag08PCANL08gL0xheW91dCANL1RleHRBbGlnbiAvQ2Vu dGVyIA0+PiANZW5kb2JqDTEzNTggMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9BIFsgMTM1OSAw IFIgXSANL0MgL05vcm1hbCANL1BnIDE3NjIgMCBSIA0vSyAyIA0vUCAxNzAxIDAgUiANPj4g DWVuZG9iag0xMzU5IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9DZW50ZXIg DT4+IA1lbmRvYmoNMTM2MCAwIG9iag08PCANL1MgL05vcm1hbCANL0EgWyAxMzYxIDAgUiBd IA0vQyAvTm9ybWFsIA0vUGcgMTc2MiAwIFIgDS9LIDMgDS9QIDE3MDEgMCBSIA0+PiANZW5k b2JqDTEzNjEgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9UZXh0QWxpZ24gL0NlbnRlciANPj4g DWVuZG9iag0xMzYyIDAgb2JqDTw8IA0vUyAvVGl0bGUgDS9DIC9UaXRsZSANL1BnIDE3NjIg MCBSIA0vSyA0IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xMzYzIDAgb2JqDTw8IA0vUyAv Tm9ybWFsIA0vQSBbIDEzNjUgMCBSIF0gDS9DIC9Ob3JtYWwgDS9QZyAxNzYyIDAgUiANL0sg NSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTM2NCAwIG9iag08PCANL08gL0xheW91dCAN L1dyaXRpbmdNb2RlIC9MclRiIA0vU3RhcnRJbmRlbnQgMCANL0VuZEluZGVudCAwIA0vVGV4 dEFsaWduIC9DZW50ZXIgDS9TcGFjZUJlZm9yZSAwIA0vU3BhY2VBZnRlciAwIA0vVGV4dElu ZGVudCAwIA0+PiANZW5kb2JqDTEzNjUgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9UZXh0QWxp Z24gL0NlbnRlciANPj4gDWVuZG9iag0xMzY2IDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQSBb IDEzNjcgMCBSIF0gDS9DIC9Ob3JtYWwgDS9QZyAxNzYyIDAgUiANL0sgNiANL1AgMTcwMSAw IFIgDT4+IA1lbmRvYmoNMTM2NyAwIG9iag08PCANL08gL0xheW91dCANL1RleHRBbGlnbiAv Q2VudGVyIA0+PiANZW5kb2JqDTEzNjggMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9BIFsgMTM2 OSAwIFIgXSANL0MgL05vcm1hbCANL1BnIDE3NjIgMCBSIA0vSyBbIDcgMTM3MCAwIFIgOSBd IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xMzY5IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0v VGV4dEFsaWduIC9DZW50ZXIgDT4+IA1lbmRvYmoNMTM3MCAwIG9iag08PCANL1MgL0xpbmsg DS9QIDEzNjggMCBSIA0vSyBbIDEzNzEgMCBSIDw8IC9UeXBlIC9PQkpSIC9QZyAxNzYyIDAg UiAvT2JqIDE3NjQgMCBSID4+IF0gDT4+IA1lbmRvYmoNMTM3MSAwIG9iag08PCANL1MgL1Vu ZGVybGluZSANL1AgMTM3MCAwIFIgDS9BIDE3NDEgMCBSIA0vUGcgMTc2MiAwIFIgDS9LIDgg DT4+IA1lbmRvYmoNMTM3MiAwIG9iag08PCANL1MgL05vcm1hbCANL0EgWyAxMzczIDAgUiBd IA0vQyAvTm9ybWFsIA0vUGcgMTc2MiAwIFIgDS9LIDEwIA0vUCAxNzAxIDAgUiANPj4gDWVu ZG9iag0xMzczIDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9DZW50ZXIgDT4+ IA1lbmRvYmoNMTM3NCAwIG9iag08PCANL1MgL05vcm1hbCANL0EgWyAxMzc1IDAgUiBdIA0v QyAvTm9ybWFsIA0vUGcgMTc2MiAwIFIgDS9LIDExIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9i ag0xMzc1IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9DZW50ZXIgDT4+IA1l bmRvYmoNMTM3NiAwIG9iag08PCANL1MgL05vcm1hbCANL0EgWyAxMzc3IDAgUiBdIA0vQyAv Tm9ybWFsIA0vUGcgMTc2MiAwIFIgDS9LIDEyIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0x Mzc3IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9DZW50ZXIgDT4+IA1lbmRv YmoNMTM3OCAwIG9iag08PCANL1MgL05vcm1hbCANL0EgWyAxMzc5IDAgUiBdIA0vQyAvTm9y bWFsIA0vUGcgMTc2MiAwIFIgDS9LIDEzIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xMzc5 IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9DZW50ZXIgDT4+IA1lbmRvYmoN MTM4MCAwIG9iag08PCANL1MgL05vcm1hbCANL0EgWyAxMzgxIDAgUiBdIA0vQyAvTm9ybWFs IA0vUGcgMTc2MiAwIFIgDS9LIDE0IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xMzgxIDAg b2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9DZW50ZXIgDT4+IA1lbmRvYmoNMTM4 MiAwIG9iag08PCANL1MgL05vcm1hbCANL0EgWyAxMzgzIDAgUiBdIA0vQyAvTm9ybWFsIA0v UGcgMTc2MiAwIFIgDS9LIDE1IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xMzgzIDAgb2Jq DTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9DZW50ZXIgDT4+IA1lbmRvYmoNMTM4NCAw IG9iag08PCANL1MgL05vcm1hbCANL0EgWyAxMzg1IDAgUiBdIA0vQyAvTm9ybWFsIA0vUGcg MTc2MiAwIFIgDS9LIDE2IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xMzg1IDAgb2JqDTw8 IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9DZW50ZXIgDT4+IA1lbmRvYmoNMTM4NiAwIG9i ag08PCANL1MgL05vcm1hbCANL0EgWyAxMzg3IDAgUiBdIA0vQyAvTm9ybWFsIA0vUGcgMTc2 MiAwIFIgDS9LIDE3IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xMzg3IDAgb2JqDTw8IA0v TyAvTGF5b3V0IA0vVGV4dEFsaWduIC9DZW50ZXIgDT4+IA1lbmRvYmoNMTM4OCAwIG9iag08 PCANL1MgL05vcm1hbCANL0EgWyAxMzg5IDAgUiBdIA0vQyAvTm9ybWFsIA0vUGcgMTc2MiAw IFIgDS9LIDE4IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xMzg5IDAgb2JqDTw8IA0vTyAv TGF5b3V0IA0vVGV4dEFsaWduIC9DZW50ZXIgDT4+IA1lbmRvYmoNMTM5MCAwIG9iag08PCAN L1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDE3NjIgMCBSIA0vSyAxOSANL1AgMTcwMSAw IFIgDT4+IA1lbmRvYmoNMTM5MSAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCAN L1BnIDE3NjIgMCBSIA0vSyAyMCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTM5MiAwIG9i ag08PCANL1MgL1RpdGxlIA0vQyAvVGl0bGUgDS9QZyAxNzYyIDAgUiANL0sgMjEgDS9QIDE3 MDEgMCBSIA0+PiANZW5kb2JqDTEzOTMgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9Ob3Jt YWwgDS9QZyAxNzYyIDAgUiANL0sgMjIgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTEzOTQg MCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyAxNzYyIDAgUiANL0sgMjMg DS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTEzOTUgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9D IC9Ob3JtYWwgDS9QZyAxNzYyIDAgUiANL0sgMjQgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2Jq DTEzOTYgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyAxNzYyIDAgUiAN L0sgMjUgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTEzOTcgMCBvYmoNPDwgDS9TIC9Ob3Jt YWwgDS9DIC9Ob3JtYWwgDS9QZyAxNzYyIDAgUiANL0sgMjYgDS9QIDE3MDEgMCBSIA0+PiAN ZW5kb2JqDTEzOTggMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyAxNzYy IDAgUiANL0sgWyAyNyAxMzk5IDAgUiAyOSBdIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0x Mzk5IDAgb2JqDTw8IA0vUyAvTGluayANL1AgMTM5OCAwIFIgDS9LIFsgMTQwMCAwIFIgPDwg L1R5cGUgL09CSlIgL1BnIDE3NjIgMCBSIC9PYmogMTc2NSAwIFIgPj4gXSANPj4gDWVuZG9i ag0xNDAwIDAgb2JqDTw8IA0vUyAvVW5kZXJsaW5lIA0vUCAxMzk5IDAgUiANL0EgMTc0MiAw IFIgDS9QZyAxNzYyIDAgUiANL0sgMjggDT4+IA1lbmRvYmoNMTQwMSAwIG9iag08PCANL1Mg L05vcm1hbCANL0MgL05vcm1hbCANL1BnIDE3NjIgMCBSIA0vSyAzMCANL1AgMTcwMSAwIFIg DT4+IA1lbmRvYmoNMTQwMiAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1Bn IDE3NjIgMCBSIA0vSyAzMSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQwMyAwIG9iag08 PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDE3NjIgMCBSIA0vSyAzMiANL1AgMTcw MSAwIFIgDT4+IA1lbmRvYmoNMTQwNCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAv Qm9keSMyMFRleHQgDS9QZyAxNzYyIDAgUiANL0sgMzMgDS9QIDE3MDEgMCBSIA0+PiANZW5k b2JqDTE0MDUgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0v UGcgMTc2MiAwIFIgDS9LIDM0IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDA2IDAgb2Jq DTw8IA0vTyAvTGF5b3V0IA0vV3JpdGluZ01vZGUgL0xyVGIgDS9TdGFydEluZGVudCAwIA0v RW5kSW5kZW50IDAgDS9UZXh0QWxpZ24gL1N0YXJ0IA0vU3BhY2VCZWZvcmUgMCANL1NwYWNl QWZ0ZXIgMCANL1RleHRJbmRlbnQgMCANPj4gDWVuZG9iag0xNDA3IDAgb2JqDTw8IA0vUyAv Qm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDE3NjIgMCBSIA0vSyAzNSANL1Ag MTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQwOCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0v QyAvQm9keSMyMFRleHQgDS9QZyAxNzYyIDAgUiANL0sgMzYgDS9QIDE3MDEgMCBSIA0+PiAN ZW5kb2JqDTE0MDkgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0 IA0vUGcgMTc2MiAwIFIgDS9LIDM3IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDEwIDAg b2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDE3NjIgMCBS IA0vSyAzOCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQxMSAwIG9iag08PCANL1MgL0Jv ZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxNzYyIDAgUiANL0sgMzkgDS9QIDE3 MDEgMCBSIA0+PiANZW5kb2JqDTE0MTIgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0Mg L0JvZHkjMjBUZXh0IA0vUGcgMTc2MiAwIFIgDS9LIDQwIA0vUCAxNzAxIDAgUiANPj4gDWVu ZG9iag0xNDEzIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCAN L1BnIDE3NjIgMCBSIA0vSyA0MSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQxNCAwIG9i ag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sg MCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQxNSAwIG9iag08PCANL1MgL0JvZHkjMjBU ZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sgMSANL1AgMTcwMSAwIFIgDT4+ IA1lbmRvYmoNMTQxNiAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRl eHQgDS9QZyAxIDAgUiANL0sgMiANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQxNyAwIG9i ag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sg MyANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQxOCAwIG9iag08PCANL1MgL0JvZHkjMjBU ZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sgNCANL1AgMTcwMSAwIFIgDT4+ IA1lbmRvYmoNMTQxOSAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRl eHQgDS9QZyAxIDAgUiANL0sgNSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQyMCAwIG9i ag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sg NiANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQyMSAwIG9iag08PCANL1MgL0JvZHkjMjBU ZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sgNyANL1AgMTcwMSAwIFIgDT4+ IA1lbmRvYmoNMTQyMiAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRl eHQgDS9QZyAxIDAgUiANL0sgOCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQyMyAwIG9i ag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sg OSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQyNCAwIG9iag08PCANL1MgL0JvZHkjMjBU ZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sgMTAgDS9QIDE3MDEgMCBSIA0+ PiANZW5kb2JqDTE0MjUgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBU ZXh0IA0vUGcgMSAwIFIgDS9LIDExIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDI2IDAg b2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDEgMCBSIA0v SyAxMiANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQyNyAwIG9iag08PCANL1MgL0JvZHkj MjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sgMTMgDS9QIDE3MDEgMCBS IA0+PiANZW5kb2JqDTE0MjggMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkj MjBUZXh0IA0vUGcgMSAwIFIgDS9LIDE0IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDI5 IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDEgMCBS IA0vSyAxNSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQzMCAwIG9iag08PCANL1MgL0Jv ZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sgMTYgDS9QIDE3MDEg MCBSIA0+PiANZW5kb2JqDTE0MzEgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0Jv ZHkjMjBUZXh0IA0vUGcgMSAwIFIgDS9LIDE3IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0x NDMyIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDEg MCBSIA0vSyAxOCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQzMyAwIG9iag08PCANL1Mg L0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sgMTkgDS9QIDE3 MDEgMCBSIA0+PiANZW5kb2JqDTE0MzQgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0Mg L0JvZHkjMjBUZXh0IA0vUGcgMSAwIFIgDS9LIDIwIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9i ag0xNDM1IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1Bn IDEgMCBSIA0vSyAyMSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQzNiAwIG9iag08PCAN L1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sgMjIgDS9Q IDE3MDEgMCBSIA0+PiANZW5kb2JqDTE0MzcgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCAN L0MgL0JvZHkjMjBUZXh0IA0vUGcgMSAwIFIgDS9LIDIzIA0vUCAxNzAxIDAgUiANPj4gDWVu ZG9iag0xNDM4IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCAN L1BnIDEgMCBSIA0vSyAyNCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQzOSAwIG9iag08 PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sgMjUg DS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE0NDAgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4 dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgMSAwIFIgDS9LIDI2IA0vUCAxNzAxIDAgUiANPj4g DWVuZG9iag0xNDQxIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4 dCANL1BnIDEgMCBSIA0vSyAyNyANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQ0MiAwIG9i ag08PCANL1MgL0xCb2R5IA0vQSBbIDE0NDMgMCBSIF0gDS9DIC9Cb2R5IzIwVGV4dCANL1Bn IDEgMCBSIA0vSyAyOCANL1AgMTcwMyAwIFIgDT4+IA1lbmRvYmoNMTQ0MyAwIG9iag08PCAN L08gL0xheW91dCANL1N0YXJ0SW5kZW50IDU0IA0vVGV4dEluZGVudCAtMTcuOTk5OTggDT4+ IA1lbmRvYmoNMTQ0NCAwIG9iag08PCANL1MgL0xCb2R5IA0vQSBbIDE0NDUgMCBSIF0gDS9D IC9Cb2R5IzIwVGV4dCANL1BnIDEgMCBSIA0vSyAyOSANL1AgMTcwNCAwIFIgDT4+IA1lbmRv YmoNMTQ0NSAwIG9iag08PCANL08gL0xheW91dCANL1N0YXJ0SW5kZW50IDU0IA0vVGV4dElu ZGVudCAtMTcuOTk5OTggDT4+IA1lbmRvYmoNMTQ0NiAwIG9iag08PCANL1MgL0xCb2R5IA0v QSBbIDE0NDcgMCBSIF0gDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDEgMCBSIA0vSyAzMCANL1Ag MTcwNSAwIFIgDT4+IA1lbmRvYmoNMTQ0NyAwIG9iag08PCANL08gL0xheW91dCANL1N0YXJ0 SW5kZW50IDU0IA0vVGV4dEluZGVudCAtMTcuOTk5OTggDT4+IA1lbmRvYmoNMTQ0OCAwIG9i ag08PCANL1MgL0xCb2R5IA0vQSBbIDE0NDkgMCBSIF0gDS9DIC9Cb2R5IzIwVGV4dCANL1Bn IDEgMCBSIA0vSyAzMSANL1AgMTcwNiAwIFIgDT4+IA1lbmRvYmoNMTQ0OSAwIG9iag08PCAN L08gL0xheW91dCANL1N0YXJ0SW5kZW50IDU0IA0vVGV4dEluZGVudCAtMTcuOTk5OTggDT4+ IA1lbmRvYmoNMTQ1MCAwIG9iag08PCANL1MgL0xCb2R5IA0vQSBbIDE0NTEgMCBSIF0gDS9D IC9Cb2R5IzIwVGV4dCANL1BnIDEgMCBSIA0vSyAzMiANL1AgMTcwNyAwIFIgDT4+IA1lbmRv YmoNMTQ1MSAwIG9iag08PCANL08gL0xheW91dCANL1N0YXJ0SW5kZW50IDU0IA0vVGV4dElu ZGVudCAtMTcuOTk5OTggDT4+IA1lbmRvYmoNMTQ1MiAwIG9iag08PCANL1MgL0JvZHkjMjBU ZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyAxIDAgUiANL0sgMzMgDS9QIDE3MDEgMCBSIA0+ PiANZW5kb2JqDTE0NTMgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBU ZXh0IA0vUGcgMSAwIFIgDS9LIDM0IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDU0IDAg b2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0v SyAwIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDU1IDAgb2JqDTw8IA0vUyAvQm9keSMy MFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0vSyAxIA0vUCAxNzAxIDAgUiAN Pj4gDWVuZG9iag0xNDU2IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIw VGV4dCANL1BnIDQgMCBSIA0vSyAyIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDU3IDAg b2JqDTw8IA0vUyAvTEJvZHkgDS9BIFsgMTQ1OCAwIFIgXSANL0MgL0JvZHkjMjBUZXh0IA0v UGcgNCAwIFIgDS9LIDMgDS9QIDE3MDkgMCBSIA0+PiANZW5kb2JqDTE0NTggMCBvYmoNPDwg DS9PIC9MYXlvdXQgDS9TdGFydEluZGVudCA5MCANL1RleHRJbmRlbnQgLTE3Ljk5OTk4IA0+ PiANZW5kb2JqDTE0NTkgMCBvYmoNPDwgDS9TIC9MQm9keSANL0EgWyAxNDYwIDAgUiBdIA0v QyAvQm9keSMyMFRleHQgDS9QZyA0IDAgUiANL0sgNCANL1AgMTcxMCAwIFIgDT4+IA1lbmRv YmoNMTQ2MCAwIG9iag08PCANL08gL0xheW91dCANL1N0YXJ0SW5kZW50IDkwIA0vVGV4dElu ZGVudCAtMTcuOTk5OTggDT4+IA1lbmRvYmoNMTQ2MSAwIG9iag08PCANL1MgL0xCb2R5IA0v QSBbIDE0NjIgMCBSIF0gDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0vSyA1IA0vUCAx NzExIDAgUiANPj4gDWVuZG9iag0xNDYyIDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vU3RhcnRJ bmRlbnQgOTAgDS9UZXh0SW5kZW50IC0xNy45OTk5OCANPj4gDWVuZG9iag0xNDYzIDAgb2Jq DTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0vSyA2 IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDY0IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRl eHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0vSyA3IA0vUCAxNzAxIDAgUiANPj4g DWVuZG9iag0xNDY1IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4 dCANL1BnIDQgMCBSIA0vSyA4IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDY2IDAgb2Jq DTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0vSyA5 IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDY3IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRl eHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0vSyAxMCANL1AgMTcwMSAwIFIgDT4+ IA1lbmRvYmoNMTQ2OCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRl eHQgDS9QZyA0IDAgUiANL0sgMTEgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE0NjkgMCBv YmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNCAwIFIgDS9L IDEyIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDcwIDAgb2JqDTw8IA0vUyAvQm9keSMy MFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0vSyAxMyANL1AgMTcwMSAwIFIg DT4+IA1lbmRvYmoNMTQ3MSAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMy MFRleHQgDS9QZyA0IDAgUiANL0sgMTQgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE0NzIg MCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNCAwIFIg DS9LIDE1IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDczIDAgb2JqDTw8IA0vUyAvQm9k eSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0vSyAxNiANL1AgMTcwMSAw IFIgDT4+IA1lbmRvYmoNMTQ3NCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9k eSMyMFRleHQgDS9QZyA0IDAgUiANL0sgMTcgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE0 NzUgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNCAw IFIgDS9LIDE4IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDc2IDAgb2JqDTw8IA0vUyAv Qm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0vSyAxOSANL1AgMTcw MSAwIFIgDT4+IA1lbmRvYmoNMTQ3NyAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAv Qm9keSMyMFRleHQgDS9QZyA0IDAgUiANL0sgMjAgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2Jq DTE0NzggMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcg NCAwIFIgDS9LIDIxIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDc5IDAgb2JqDTw8IA0v UyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0vSyAyMiANL1Ag MTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQ4MCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0v QyAvQm9keSMyMFRleHQgDS9QZyA0IDAgUiANL0sgMjMgDS9QIDE3MDEgMCBSIA0+PiANZW5k b2JqDTE0ODEgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0v UGcgNCAwIFIgDS9LIDI0IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDgyIDAgb2JqDTw8 IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0vSyAyNSAN L1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQ4MyAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0 IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0IDAgUiANL0sgMjYgDS9QIDE3MDEgMCBSIA0+PiAN ZW5kb2JqDTE0ODQgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0 IA0vUGcgNCAwIFIgDS9LIDI3IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDg1IDAgb2Jq DTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0vSyAy OCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQ4NiAwIG9iag08PCANL1MgL0JvZHkjMjBU ZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0IDAgUiANL0sgMjkgDS9QIDE3MDEgMCBSIA0+ PiANZW5kb2JqDTE0ODcgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBU ZXh0IA0vUGcgNCAwIFIgDS9LIDMwIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDg4IDAg b2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBSIA0v SyAzMSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQ4OSAwIG9iag08PCANL1MgL0JvZHkj MjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0IDAgUiANL0sgMzIgDS9QIDE3MDEgMCBS IA0+PiANZW5kb2JqDTE0OTAgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkj MjBUZXh0IA0vUGcgNCAwIFIgDS9LIDMzIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNDkx IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQgMCBS IA0vSyAzNCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQ5MiAwIG9iag08PCANL1MgL0Jv ZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0IDAgUiANL0sgMzUgDS9QIDE3MDEg MCBSIA0+PiANZW5kb2JqDTE0OTMgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0Jv ZHkjMjBUZXh0IA0vUGcgNCAwIFIgDS9LIDM2IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0x NDk0IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQg MCBSIA0vSyAzNyANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTQ5NSAwIG9iag08PCANL1Mg L0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0IDAgUiANL0sgMzggDS9QIDE3 MDEgMCBSIA0+PiANZW5kb2JqDTE0OTYgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0Mg L0JvZHkjMjBUZXh0IA0vUGcgNyAwIFIgDS9LIDAgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2Jq DTE0OTcgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcg NyAwIFIgDS9LIDEgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE0OTggMCBvYmoNPDwgDS9T IC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNyAwIFIgDS9LIDIgDS9QIDE3 MDEgMCBSIA0+PiANZW5kb2JqDTE0OTkgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0Mg L0JvZHkjMjBUZXh0IA0vUGcgNyAwIFIgDS9LIDMgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2Jq DTE1MDAgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcg NyAwIFIgDS9LIDQgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE1MDEgMCBvYmoNPDwgDS9T IC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNyAwIFIgDS9LIDUgDS9QIDE3 MDEgMCBSIA0+PiANZW5kb2JqDTE1MDIgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0Mg L0JvZHkjMjBUZXh0IA0vUGcgNyAwIFIgDS9LIDYgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2Jq DTE1MDMgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcg NyAwIFIgDS9LIDcgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE1MDQgMCBvYmoNPDwgDS9T IC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNyAwIFIgDS9LIDggDS9QIDE3 MDEgMCBSIA0+PiANZW5kb2JqDTE1MDUgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0Mg L0JvZHkjMjBUZXh0IA0vUGcgNyAwIFIgDS9LIFsgMTUwNiAwIFIgNzMgXSANL1AgMTcwMSAw IFIgDT4+IA1lbmRvYmoNMTUwNiAwIG9iag08PCANL1MgL0lubGluZVNoYXBlIA0vUGcgNyAw IFIgDS9QIDE1MDUgMCBSIA0vSyBbIDkgMTAgMTEgMTIgMTMgMTQgMTUgMTYgMTcgMTggMTkg MjAgMjEgMjIgMjMgMjQgMjUgMjYgMjcgMjggMjkgMzAgDTMxIDMyIDMzIDM0IDM1IDM2IDM3 IDM4IDM5IDQwIDQxIDQyIDQzIDQ0IDQ1IDQ2IDQ3IDQ4IDQ5IDUwIDUxIDUyIA01MyA1NCA1 NSA1NiA1NyA1OCA1OSA2MCA2MSA2MiA2MyA2NCA2NSA2NiA2NyA2OCA2OSA3MCA3MSA3MiBd IA0vQWx0ICgpDS9BIFsgMTc0NiAwIFIgXSANPj4gDWVuZG9iag0xNTA3IDAgb2JqDTw8IA0v UyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDcgMCBSIA0vSyA3NCANL1Ag MTcwMSAwIFIgDT4+IA1lbmRvYmoNMTUwOCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0v QyAvQm9keSMyMFRleHQgDS9QZyA3IDAgUiANL0sgNzUgDS9QIDE3MDEgMCBSIA0+PiANZW5k b2JqDTE1MDkgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0v UGcgNyAwIFIgDS9LIDc2IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTEwIDAgb2JqDTw8 IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDcgMCBSIA0vSyA3NyAN L1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTUxMSAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0 IA0vQyAvQm9keSMyMFRleHQgDS9QZyA3IDAgUiANL1AgMTcwMSAwIFIgDS9LIFsgNzggPDwg L1R5cGUgL01DUiAvUGcgNDY5IDAgUiAvTUNJRCAwID4+IF0gDT4+IA1lbmRvYmoNMTUxMiAw IG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NjkgMCBS IA0vSyAxIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTEzIDAgb2JqDTw8IA0vUyAvQm9k eSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ2OSAwIFIgDS9LIDIgDS9QIDE3MDEg MCBSIA0+PiANZW5kb2JqDTE1MTQgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0Jv ZHkjMjBUZXh0IA0vUGcgNDY5IDAgUiANL0sgMyANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoN MTUxNSAwIG9iag08PCANL1MgL0xCb2R5IA0vQSBbIDE1MTYgMCBSIF0gDS9DIC9Cb2R5IzIw VGV4dCANL1BnIDQ2OSAwIFIgDS9LIDQgDS9QIDE3MTMgMCBSIA0+PiANZW5kb2JqDTE1MTYg MCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9TdGFydEluZGVudCA1NCANL1RleHRJbmRlbnQgLTE3 Ljk5OTk4IA0+PiANZW5kb2JqDTE1MTcgMCBvYmoNPDwgDS9TIC9MQm9keSANL0EgWyAxNTE4 IDAgUiBdIA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NjkgMCBSIA0vSyA1IA0vUCAxNzE0IDAg UiANPj4gDWVuZG9iag0xNTE4IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vU3RhcnRJbmRlbnQg NTQgDS9UZXh0SW5kZW50IC0xNy45OTk5OCANPj4gDWVuZG9iag0xNTE5IDAgb2JqDTw8IA0v UyAvTEJvZHkgDS9BIFsgMTUyMCAwIFIgXSANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDY5IDAg UiANL0sgNiANL1AgMTcxNSAwIFIgDT4+IA1lbmRvYmoNMTUyMCAwIG9iag08PCANL08gL0xh eW91dCANL1N0YXJ0SW5kZW50IDU0IA0vVGV4dEluZGVudCAtMTcuOTk5OTggDT4+IA1lbmRv YmoNMTUyMSAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9Q ZyA0NjkgMCBSIA0vSyA3IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTIyIDAgb2JqDTw8 IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ2OSAwIFIgDS9LIDgg DS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE1MjMgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4 dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDY5IDAgUiANL0sgOSANL1AgMTcwMSAwIFIgDT4+ IA1lbmRvYmoNMTUyNCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRl eHQgDS9QZyA0NjkgMCBSIA0vSyAxMCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTUyNSAw IG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NjkgMCBS IA0vSyAxMSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTUyNiAwIG9iag08PCANL1MgL0Jv ZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NjkgMCBSIA0vSyAxMiANL1AgMTcw MSAwIFIgDT4+IA1lbmRvYmoNMTUyNyAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAv Qm9keSMyMFRleHQgDS9QZyA0NjkgMCBSIA0vSyAxMyANL1AgMTcwMSAwIFIgDT4+IA1lbmRv YmoNMTUyOCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9Q ZyA0NjkgMCBSIA0vSyAxNCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTUyOSAwIG9iag08 PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NjkgMCBSIA0vSyAx NSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTUzMCAwIG9iag08PCANL1MgL0JvZHkjMjBU ZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NjkgMCBSIA0vSyAxNiANL1AgMTcwMSAwIFIg DT4+IA1lbmRvYmoNMTUzMSAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMy MFRleHQgDS9QZyA0NjkgMCBSIA0vSyAxNyANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTUz MiAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0Njkg MCBSIA0vSyAxOCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTUzMyAwIG9iag08PCANL1Mg L0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NjkgMCBSIA0vSyAxOSANL1Ag MTcwMSAwIFIgDT4+IA1lbmRvYmoNMTUzNCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0v QyAvQm9keSMyMFRleHQgDS9QZyA0NjkgMCBSIA0vSyAyMCANL1AgMTcwMSAwIFIgDT4+IA1l bmRvYmoNMTUzNSAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQg DS9QZyA0NjkgMCBSIA0vSyBbIDIxIDE1MzYgMCBSIDIzIDE1MzggMCBSIDI1IF0gDS9QIDE3 MDEgMCBSIA0+PiANZW5kb2JqDTE1MzYgMCBvYmoNPDwgDS9TIC9MaW5rIA0vUCAxNTM1IDAg UiANL0sgWyAxNTM3IDAgUiA8PCAvVHlwZSAvT0JKUiAvUGcgNDY5IDAgUiAvT2JqIDEzNDgg MCBSID4+IF0gDT4+IA1lbmRvYmoNMTUzNyAwIG9iag08PCANL1MgL1VuZGVybGluZSANL1Ag MTUzNiAwIFIgDS9BIDE3NDggMCBSIA0vUGcgNDY5IDAgUiANL0sgMjIgDT4+IA1lbmRvYmoN MTUzOCAwIG9iag08PCANL1MgL0xpbmsgDS9QIDE1MzUgMCBSIA0vSyBbIDE1MzkgMCBSIDw8 IC9UeXBlIC9PQkpSIC9QZyA0NjkgMCBSIC9PYmogMTM1MCAwIFIgPj4gXSANPj4gDWVuZG9i ag0xNTM5IDAgb2JqDTw8IA0vUyAvVW5kZXJsaW5lIA0vUCAxNTM4IDAgUiANL0EgMTc0OSAw IFIgDS9QZyA0NjkgMCBSIA0vSyAyNCANPj4gDWVuZG9iag0xNTQwIDAgb2JqDTw8IA0vUyAv Qm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ2OSAwIFIgDS9LIDI2IA0vUCAx NzAxIDAgUiANPj4gDWVuZG9iag0xNTQxIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9D IC9Cb2R5IzIwVGV4dCANL1BnIDQ2OSAwIFIgDS9LIDI3IA0vUCAxNzAxIDAgUiANPj4gDWVu ZG9iag0xNTQyIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCAN L1BnIDQ2OSAwIFIgDS9LIDI4IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTQzIDAgb2Jq DTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ2OSAwIFIgDS9L IDI5IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTQ0IDAgb2JqDTw8IA0vUyAvQm9keSMy MFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ2OSAwIFIgDS9LIDMwIA0vUCAxNzAxIDAg UiANPj4gDWVuZG9iag0xNTQ1IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5 IzIwVGV4dCANL1BnIDQ2OSAwIFIgDS9LIDMxIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0x NTQ2IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ2 OSAwIFIgDS9LIDMyIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTQ3IDAgb2JqDTw8IA0v UyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ2OSAwIFIgDS9LIDMzIA0v UCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTQ4IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQg DS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ2OSAwIFIgDS9LIDM0IA0vUCAxNzAxIDAgUiANPj4g DWVuZG9iag0xNTQ5IDAgb2JqDTw8IA0vUyAvTEJvZHkgDS9BIFsgMTU1MCAwIFIgXSANL0Mg L0JvZHkjMjBUZXh0IA0vUGcgNDY5IDAgUiANL0sgMzUgDS9QIDE3MTcgMCBSIA0+PiANZW5k b2JqDTE1NTAgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9TdGFydEluZGVudCAzNiANL1RleHRJ bmRlbnQgLTE3Ljk5OTk4IA0+PiANZW5kb2JqDTE1NTEgMCBvYmoNPDwgDS9TIC9MQm9keSAN L0EgWyAxNTUyIDAgUiBdIA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NjkgMCBSIA0vSyAzNiAN L1AgMTcxOCAwIFIgDT4+IA1lbmRvYmoNMTU1MiAwIG9iag08PCANL08gL0xheW91dCANL1N0 YXJ0SW5kZW50IDM2IA0vVGV4dEluZGVudCAtMTcuOTk5OTggDT4+IA1lbmRvYmoNMTU1MyAw IG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NjkgMCBS IA0vSyAzNyANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTU1NCAwIG9iag08PCANL1MgL0Jv ZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NjkgMCBSIA0vSyAzOCANL1AgMTcw MSAwIFIgDT4+IA1lbmRvYmoNMTU1NSAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAv Qm9keSMyMFRleHQgDS9QZyA0NjkgMCBSIA0vSyAzOSANL1AgMTcwMSAwIFIgDT4+IA1lbmRv YmoNMTU1NiAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9Q ZyA0NjkgMCBSIA0vSyA0MCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTU1NyAwIG9iag08 PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NjkgMCBSIA0vSyA0 MSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTU1OCAwIG9iag08PCANL1MgL0JvZHkjMjBU ZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzMgMCBSIA0vSyAwIA0vUCAxNzAxIDAgUiAN Pj4gDWVuZG9iag0xNTU5IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIw VGV4dCANL1BnIDQ3MyAwIFIgDS9LIDEgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE1NjAg MCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDczIDAg UiANL0sgMiANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTU2MSAwIG9iag08PCANL1MgL0Jv ZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzMgMCBSIA0vSyAzIA0vUCAxNzAx IDAgUiANPj4gDWVuZG9iag0xNTYyIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9C b2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDQgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2Jq DTE1NjMgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcg NDczIDAgUiANL0sgNSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTU2NCAwIG9iag08PCAN L1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzMgMCBSIA0vSyA2IA0v UCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTY1IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQg DS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDcgDS9QIDE3MDEgMCBSIA0+PiAN ZW5kb2JqDTE1NjYgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0 IA0vUGcgNDczIDAgUiANL0sgOCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTU2NyAwIG9i ag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzMgMCBSIA0v SyA5IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTY4IDAgb2JqDTw8IA0vUyAvQm9keSMy MFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDEwIA0vUCAxNzAxIDAg UiANPj4gDWVuZG9iag0xNTY5IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5 IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDExIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0x NTcwIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3 MyAwIFIgDS9LIDEyIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTcxIDAgb2JqDTw8IA0v UyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDEzIA0v UCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTcyIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQg DS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDE0IA0vUCAxNzAxIDAgUiANPj4g DWVuZG9iag0xNTczIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4 dCANL1BnIDQ3MyAwIFIgDS9LIDE1IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTc0IDAg b2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIg DS9LIDE2IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTc1IDAgb2JqDTw8IA0vUyAvQm9k eSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDE3IA0vUCAxNzAx IDAgUiANPj4gDWVuZG9iag0xNTc2IDAgb2JqDTw8IA0vUyAvTEJvZHkgDS9BIFsgMTU3NyAw IFIgXSANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDczIDAgUiANL0sgMTggDS9QIDE3MjAgMCBS IA0+PiANZW5kb2JqDTE1NzcgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9TdGFydEluZGVudCAz NiANL1RleHRJbmRlbnQgLTE3Ljk5OTk4IA0+PiANZW5kb2JqDTE1NzggMCBvYmoNPDwgDS9T IC9MQm9keSANL0EgWyAxNTc5IDAgUiBdIA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzMgMCBS IA0vSyAxOSANL1AgMTcyMSAwIFIgDT4+IA1lbmRvYmoNMTU3OSAwIG9iag08PCANL08gL0xh eW91dCANL1N0YXJ0SW5kZW50IDM2IA0vVGV4dEluZGVudCAtMTcuOTk5OTggDT4+IA1lbmRv YmoNMTU4MCAwIG9iag08PCANL1MgL0xCb2R5IA0vQSBbIDE1ODEgMCBSIF0gDS9DIC9Cb2R5 IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDIwIA0vUCAxNzIyIDAgUiANPj4gDWVuZG9iag0x NTgxIDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vU3RhcnRJbmRlbnQgMzYgDS9UZXh0SW5kZW50 IC0xNy45OTk5OCANPj4gDWVuZG9iag0xNTgyIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQg DS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDIxIA0vUCAxNzAxIDAgUiANPj4g DWVuZG9iag0xNTgzIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4 dCANL1BnIDQ3MyAwIFIgDS9LIDIyIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTg0IDAg b2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIg DS9LIDIzIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTg1IDAgb2JqDTw8IA0vUyAvQm9k eSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDI0IA0vUCAxNzAx IDAgUiANPj4gDWVuZG9iag0xNTg2IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9C b2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDI1IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9i ag0xNTg3IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1Bn IDQ3MyAwIFIgDS9LIDI2IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTg4IDAgb2JqDTw8 IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDI3 IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTg5IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRl eHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDI4IA0vUCAxNzAxIDAgUiAN Pj4gDWVuZG9iag0xNTkwIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIw VGV4dCANL1BnIDQ3MyAwIFIgDS9LIDI5IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTkx IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAw IFIgDS9LIDMwIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTkyIDAgb2JqDTw8IA0vUyAv Qm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDMxIA0vUCAx NzAxIDAgUiANPj4gDWVuZG9iag0xNTkzIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9D IC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDMyIA0vUCAxNzAxIDAgUiANPj4gDWVu ZG9iag0xNTk0IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCAN L1BnIDQ3MyAwIFIgDS9LIDMzIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTk1IDAgb2Jq DTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9L IDM0IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTk2IDAgb2JqDTw8IA0vUyAvQm9keSMy MFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDM1IA0vUCAxNzAxIDAg UiANPj4gDWVuZG9iag0xNTk3IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5 IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDM2IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0x NTk4IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3 MyAwIFIgDS9LIDM3IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNTk5IDAgb2JqDTw8IA0v UyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDM4IA0v UCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNjAwIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQg DS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3MyAwIFIgDS9LIDM5IA0vUCAxNzAxIDAgUiANPj4g DWVuZG9iag0xNjAxIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4 dCANL1BnIDQ3MyAwIFIgDS9LIDQwIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNjAyIDAg b2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3NiAwIFIg DS9LIDAgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2MDMgMCBvYmoNPDwgDS9TIC9Cb2R5 IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMSANL1AgMTcwMSAw IFIgDT4+IA1lbmRvYmoNMTYwNCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9k eSMyMFRleHQgDS9QZyA0NzYgMCBSIA0vSyAyIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0x NjA1IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3 NiAwIFIgDS9LIDMgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2MDYgMCBvYmoNPDwgDS9T IC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgNCANL1Ag MTcwMSAwIFIgDT4+IA1lbmRvYmoNMTYwNyAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0v QyAvQm9keSMyMFRleHQgDS9QZyA0NzYgMCBSIA0vSyA1IA0vUCAxNzAxIDAgUiANPj4gDWVu ZG9iag0xNjA4IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCAN L1BnIDQ3NiAwIFIgDS9LIDYgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2MDkgMCBvYmoN PDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sg NyANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTYxMCAwIG9iag08PCANL1MgL0xCb2R5IA0v QSBbIDE2MTEgMCBSIF0gDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3NiAwIFIgDS9LIDggDS9Q IDE3MjQgMCBSIA0+PiANZW5kb2JqDTE2MTEgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9TdGFy dEluZGVudCAzNiANL1RleHRJbmRlbnQgLTE3Ljk5OTk4IA0+PiANZW5kb2JqDTE2MTIgMCBv YmoNPDwgDS9TIC9MQm9keSANL0EgWyAxNjEzIDAgUiBdIA0vQyAvQm9keSMyMFRleHQgDS9Q ZyA0NzYgMCBSIA0vSyA5IA0vUCAxNzI1IDAgUiANPj4gDWVuZG9iag0xNjEzIDAgb2JqDTw8 IA0vTyAvTGF5b3V0IA0vU3RhcnRJbmRlbnQgMzYgDS9UZXh0SW5kZW50IC0xNy45OTk5OCAN Pj4gDWVuZG9iag0xNjE0IDAgb2JqDTw8IA0vUyAvTEJvZHkgDS9BIFsgMTYxNSAwIFIgXSAN L0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMTAgDS9QIDE3MjYgMCBSIA0+PiAN ZW5kb2JqDTE2MTUgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9TdGFydEluZGVudCAzNiANL1Rl eHRJbmRlbnQgLTE3Ljk5OTk4IA0+PiANZW5kb2JqDTE2MTYgMCBvYmoNPDwgDS9TIC9MQm9k eSANL0EgWyAxNjE3IDAgUiBdIA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzYgMCBSIA0vSyAx MSANL1AgMTcyNyAwIFIgDT4+IA1lbmRvYmoNMTYxNyAwIG9iag08PCANL08gL0xheW91dCAN L1N0YXJ0SW5kZW50IDM2IA0vVGV4dEluZGVudCAtMTcuOTk5OTggDT4+IA1lbmRvYmoNMTYx OCAwIG9iag08PCANL1MgL0xCb2R5IA0vQSBbIDE2MTkgMCBSIF0gDS9DIC9Cb2R5IzIwVGV4 dCANL1BnIDQ3NiAwIFIgDS9LIDEyIA0vUCAxNzI4IDAgUiANPj4gDWVuZG9iag0xNjE5IDAg b2JqDTw8IA0vTyAvTGF5b3V0IA0vU3RhcnRJbmRlbnQgMzYgDS9UZXh0SW5kZW50IC0xNy45 OTk5OCANPj4gDWVuZG9iag0xNjIwIDAgb2JqDTw8IA0vUyAvTEJvZHkgDS9BIFsgMTYyMSAw IFIgXSANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMTMgDS9QIDE3MzAgMCBS IA0+PiANZW5kb2JqDTE2MjEgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9TdGFydEluZGVudCA3 MiANL1RleHRJbmRlbnQgLTE3Ljk5OTk4IA0+PiANZW5kb2JqDTE2MjIgMCBvYmoNPDwgDS9T IC9MQm9keSANL0EgWyAxNjIzIDAgUiBdIA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzYgMCBS IA0vSyAxNCANL1AgMTczMSAwIFIgDT4+IA1lbmRvYmoNMTYyMyAwIG9iag08PCANL08gL0xh eW91dCANL1N0YXJ0SW5kZW50IDcyIA0vVGV4dEluZGVudCAtMTcuOTk5OTggDT4+IA1lbmRv YmoNMTYyNCAwIG9iag08PCANL1MgL0xCb2R5IA0vQSBbIDE2MjUgMCBSIF0gDS9DIC9Cb2R5 IzIwVGV4dCANL1BnIDQ3NiAwIFIgDS9LIDE1IA0vUCAxNzMyIDAgUiANPj4gDWVuZG9iag0x NjI1IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vU3RhcnRJbmRlbnQgMzYgDS9UZXh0SW5kZW50 IC0xNy45OTk5OCANPj4gDWVuZG9iag0xNjI2IDAgb2JqDTw8IA0vUyAvTEJvZHkgDS9BIFsg MTYyNyAwIFIgXSANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMTYgDS9QIDE3 MzMgMCBSIA0+PiANZW5kb2JqDTE2MjcgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9TdGFydElu ZGVudCAzNiANL1RleHRJbmRlbnQgLTE3Ljk5OTk4IA0+PiANZW5kb2JqDTE2MjggMCBvYmoN PDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sg MTcgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2MjkgMCBvYmoNPDwgDS9TIC9Cb2R5IzIw VGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMTggDS9QIDE3MDEgMCBS IA0+PiANZW5kb2JqDTE2MzAgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkj MjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMTkgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2 MzEgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2 IDAgUiANL0sgMjAgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2MzIgMCBvYmoNPDwgDS9T IC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMjEgDS9Q IDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2MzMgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCAN L0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMjIgDS9QIDE3MDEgMCBSIA0+PiAN ZW5kb2JqDTE2MzQgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0 IA0vUGcgNDc2IDAgUiANL0sgMjMgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2MzUgMCBv YmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiAN L0sgMjQgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2MzYgMCBvYmoNPDwgDS9TIC9Cb2R5 IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMjUgDS9QIDE3MDEg MCBSIA0+PiANZW5kb2JqDTE2MzcgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0Jv ZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMjYgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2Jq DTE2MzggMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcg NDc2IDAgUiANL0sgMjcgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2MzkgMCBvYmoNPDwg DS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMjgg DS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2NDAgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4 dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMjkgDS9QIDE3MDEgMCBSIA0+ PiANZW5kb2JqDTE2NDEgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBU ZXh0IA0vUGcgNDc2IDAgUiANL0sgMzAgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2NDIg MCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAg UiANL0sgMzEgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2NDMgMCBvYmoNPDwgDS9TIC9C b2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMzIgDS9QIDE3 MDEgMCBSIA0+PiANZW5kb2JqDTE2NDQgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0Mg L0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sgMzMgDS9QIDE3MDEgMCBSIA0+PiANZW5k b2JqDTE2NDUgMCBvYmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0v UGcgNDc2IDAgUiANL0sgMzQgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2NDYgMCBvYmoN PDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc2IDAgUiANL0sg MzUgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2NDcgMCBvYmoNPDwgDS9TIC9Cb2R5IzIw VGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc5IDAgUiANL0sgMCANL1AgMTcwMSAwIFIg DT4+IA1lbmRvYmoNMTY0OCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMy MFRleHQgDS9QZyA0NzkgMCBSIA0vSyAxIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNjQ5 IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3OSAw IFIgDS9LIDIgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2NTAgMCBvYmoNPDwgDS9TIC9C b2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc5IDAgUiANL0sgMyANL1AgMTcw MSAwIFIgDT4+IA1lbmRvYmoNMTY1MSAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAv Qm9keSMyMFRleHQgDS9QZyA0NzkgMCBSIA0vSyA0IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9i ag0xNjUyIDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1Bn IDQ3OSAwIFIgDS9LIDUgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2NTMgMCBvYmoNPDwg DS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc5IDAgUiANL0sgNiAN L1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY1NCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0 IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzkgMCBSIA0vSyA3IA0vUCAxNzAxIDAgUiANPj4g DWVuZG9iag0xNjU1IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4 dCANL1BnIDQ3OSAwIFIgDS9LIDggDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2NTYgMCBv YmoNPDwgDS9TIC9Cb2R5IzIwVGV4dCANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc5IDAgUiAN L0sgOSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY1NyAwIG9iag08PCANL1MgL0JvZHkj MjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzkgMCBSIA0vSyAxMCANL1AgMTcwMSAw IFIgDT4+IA1lbmRvYmoNMTY1OCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9k eSMyMFRleHQgDS9QZyA0NzkgMCBSIA0vSyAxMSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoN MTY1OSAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0 NzkgMCBSIA0vSyAxMiANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY2MCAwIG9iag08PCAN L1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzkgMCBSIA0vSyAxMyAN L1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY2MSAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0 IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzkgMCBSIA0vSyAxNCANL1AgMTcwMSAwIFIgDT4+ IA1lbmRvYmoNMTY2MiAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRl eHQgDS9QZyA0NzkgMCBSIA0vSyAxNSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY2MyAw IG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzkgMCBS IA0vSyAxNiANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY2NCAwIG9iag08PCANL1MgL0Jv ZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzkgMCBSIA0vSyAxNyANL1AgMTcw MSAwIFIgDT4+IA1lbmRvYmoNMTY2NSAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAv Qm9keSMyMFRleHQgDS9QZyA0NzkgMCBSIA0vSyAxOCANL1AgMTcwMSAwIFIgDT4+IA1lbmRv YmoNMTY2NiAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9Q ZyA0NzkgMCBSIA0vSyAxOSANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY2NyAwIG9iag08 PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzkgMCBSIA0vSyAy MCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY2OCAwIG9iag08PCANL1MgL0JvZHkjMjBU ZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzkgMCBSIA0vSyAyMSANL1AgMTcwMSAwIFIg DT4+IA1lbmRvYmoNMTY2OSAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMy MFRleHQgDS9QZyA0NzkgMCBSIA0vSyAyMiANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY3 MCAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0Nzkg MCBSIA0vSyAyMyANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY3MSAwIG9iag08PCANL1Mg L0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzkgMCBSIA0vSyAyNCANL1Ag MTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY3MiAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0v QyAvQm9keSMyMFRleHQgDS9QZyA0NzkgMCBSIA0vSyAyNSANL1AgMTcwMSAwIFIgDT4+IA1l bmRvYmoNMTY3MyAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQg DS9QZyA0NzkgMCBSIA0vSyAyNiANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY3NCAwIG9i ag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzkgMCBSIA0v SyAyNyANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY3NSAwIG9iag08PCANL1MgL0JvZHkj MjBUZXh0IA0vQyAvQm9keSMyMFRleHQgDS9QZyA0NzkgMCBSIA0vSyAyOCANL1AgMTcwMSAw IFIgDT4+IA1lbmRvYmoNMTY3NiAwIG9iag08PCANL1MgL0xCb2R5IA0vQSBbIDE2NzcgMCBS IF0gDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3OSAwIFIgDS9LIDI5IA0vUCAxNzM1IDAgUiAN Pj4gDWVuZG9iag0xNjc3IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vU3RhcnRJbmRlbnQgMzYg DS9UZXh0SW5kZW50IC0xNy45OTk5OCANPj4gDWVuZG9iag0xNjc4IDAgb2JqDTw8IA0vUyAv Qm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3OSAwIFIgDS9LIDMwIA0vUCAx NzAxIDAgUiANPj4gDWVuZG9iag0xNjc5IDAgb2JqDTw8IA0vUyAvTEJvZHkgDS9BIFsgMTY4 MCAwIFIgXSANL0MgL0JvZHkjMjBUZXh0IA0vUGcgNDc5IDAgUiANL0sgMzEgDS9QIDE3MzYg MCBSIA0+PiANZW5kb2JqDTE2ODAgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9TdGFydEluZGVu dCAzNiANL1RleHRJbmRlbnQgLTE3Ljk5OTk4IA0+PiANZW5kb2JqDTE2ODEgMCBvYmoNPDwg DS9TIC9Cb2R5IzIwVGV4dCANL0EgWyAxNjgyIDAgUiBdIA0vQyAvQm9keSMyMFRleHQgDS9Q ZyA0NzkgMCBSIA0vSyAzMiANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY4MiAwIG9iag08 PCANL08gL0xheW91dCANL1N0YXJ0SW5kZW50IDE4IA0+PiANZW5kb2JqDTE2ODMgMCBvYmoN PDwgDS9TIC9MQm9keSANL0EgWyAxNjg0IDAgUiBdIA0vQyAvQm9keSMyMFRleHQgDS9QZyA0 NzkgMCBSIA0vSyAzMyANL1AgMTczNyAwIFIgDT4+IA1lbmRvYmoNMTY4NCAwIG9iag08PCAN L08gL0xheW91dCANL1N0YXJ0SW5kZW50IDM2IA0vVGV4dEluZGVudCAtMTcuOTk5OTggDT4+ IA1lbmRvYmoNMTY4NSAwIG9iag08PCANL1MgL0JvZHkjMjBUZXh0IA0vQyAvQm9keSMyMFRl eHQgDS9QZyA0NzkgMCBSIA0vSyAzNCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY4NiAw IG9iag08PCANL1MgL0xCb2R5IA0vQSBbIDE2ODcgMCBSIF0gDS9DIC9Cb2R5IzIwVGV4dCAN L1BnIDQ3OSAwIFIgDS9LIDM1IA0vUCAxNzM4IDAgUiANPj4gDWVuZG9iag0xNjg3IDAgb2Jq DTw8IA0vTyAvTGF5b3V0IA0vU3RhcnRJbmRlbnQgMzYgDS9UZXh0SW5kZW50IC0xNy45OTk5 OCANPj4gDWVuZG9iag0xNjg4IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5 IzIwVGV4dCANL1BnIDQ3OSAwIFIgDS9LIDM2IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0x Njg5IDAgb2JqDTw8IA0vUyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3 OSAwIFIgDS9LIDM3IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNjkwIDAgb2JqDTw8IA0v UyAvQm9keSMyMFRleHQgDS9DIC9Cb2R5IzIwVGV4dCANL1BnIDQ3OSAwIFIgDS9LIDM4IA0v UCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNjkxIDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAv Tm9ybWFsIA0vUGcgNDc5IDAgUiANL0sgMzkgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2 OTIgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyA0NzkgMCBSIA0vSyA0 MCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY5MyAwIG9iag08PCANL1MgL05vcm1hbCAN L0MgL05vcm1hbCANL1BnIDQ3OSAwIFIgDS9LIDQxIA0vUCAxNzAxIDAgUiANPj4gDWVuZG9i ag0xNjk0IDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgNDc5IDAgUiAN L0sgNDIgDS9QIDE3MDEgMCBSIA0+PiANZW5kb2JqDTE2OTUgMCBvYmoNPDwgDS9TIC9Ob3Jt YWwgDS9DIC9Ob3JtYWwgDS9QZyA0NzkgMCBSIA0vSyA0MyANL1AgMTcwMSAwIFIgDT4+IA1l bmRvYmoNMTY5NiAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDQ3OSAw IFIgDS9LIDQ0IA0vUCAxNzAxIDAgUiANPj4gDWVuZG9iag0xNjk3IDAgb2JqDTw8IA0vUyAv Tm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgNDc5IDAgUiANL0sgNDUgDS9QIDE3MDEgMCBSIA0+ PiANZW5kb2JqDTE2OTggMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyA0 NzkgMCBSIA0vSyA0NiANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTY5OSAwIG9iag08PCAN L1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDQ3OSAwIFIgDS9LIDQ3IA0vUCAxNzAxIDAg UiANPj4gDWVuZG9iag0xNzAwIDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0v UGcgNDgyIDAgUiANL0sgMCANL1AgMTcwMSAwIFIgDT4+IA1lbmRvYmoNMTcwMSAwIG9iag08 PCANL1MgL1NlY3QgDS9QIDE3NjEgMCBSIA0vSyBbIDEzNTIgMCBSIDEzNTYgMCBSIDEzNTgg MCBSIDEzNjAgMCBSIDEzNjIgMCBSIDEzNjMgMCBSIDEzNjYgMCBSIDEzNjggMCBSIA0xMzcy IDAgUiAxMzc0IDAgUiAxMzc2IDAgUiAxMzc4IDAgUiAxMzgwIDAgUiAxMzgyIDAgUiAxMzg0 IDAgUiAxMzg2IDAgUiANMTM4OCAwIFIgMTM5MCAwIFIgMTM5MSAwIFIgMTM5MiAwIFIgMTM5 MyAwIFIgMTM5NCAwIFIgMTM5NSAwIFIgMTM5NiAwIFIgDTEzOTcgMCBSIDEzOTggMCBSIDE0 MDEgMCBSIDE0MDIgMCBSIDE0MDMgMCBSIDE0MDQgMCBSIDE0MDUgMCBSIDE0MDcgMCBSIA0x NDA4IDAgUiAxNDA5IDAgUiAxNDEwIDAgUiAxNDExIDAgUiAxNDEyIDAgUiAxNDEzIDAgUiAx NDE0IDAgUiAxNDE1IDAgUiANMTQxNiAwIFIgMTQxNyAwIFIgMTQxOCAwIFIgMTQxOSAwIFIg MTQyMCAwIFIgMTQyMSAwIFIgMTQyMiAwIFIgMTQyMyAwIFIgDTE0MjQgMCBSIDE0MjUgMCBS IDE0MjYgMCBSIDE0MjcgMCBSIDE0MjggMCBSIDE0MjkgMCBSIDE0MzAgMCBSIDE0MzEgMCBS IA0xNDMyIDAgUiAxNDMzIDAgUiAxNDM0IDAgUiAxNDM1IDAgUiAxNDM2IDAgUiAxNDM3IDAg UiAxNDM4IDAgUiAxNDM5IDAgUiANMTQ0MCAwIFIgMTQ0MSAwIFIgMTcwMiAwIFIgMTQ1MiAw IFIgMTQ1MyAwIFIgMTQ1NCAwIFIgMTQ1NSAwIFIgMTQ1NiAwIFIgDTE3MDggMCBSIDE0NjMg MCBSIDE0NjQgMCBSIDE0NjUgMCBSIDE0NjYgMCBSIDE0NjcgMCBSIDE0NjggMCBSIDE0Njkg MCBSIA0xNDcwIDAgUiAxNDcxIDAgUiAxNDcyIDAgUiAxNDczIDAgUiAxNDc0IDAgUiAxNDc1 IDAgUiAxNDc2IDAgUiAxNDc3IDAgUiANMTQ3OCAwIFIgMTQ3OSAwIFIgMTQ4MCAwIFIgMTQ4 MSAwIFIgMTQ4MiAwIFIgMTQ4MyAwIFIgMTQ4NCAwIFIgMTQ4NSAwIFIgDTE0ODYgMCBSIDE0 ODcgMCBSIDE0ODggMCBSIDE0ODkgMCBSIDE0OTAgMCBSIDE0OTEgMCBSIDE0OTIgMCBSIDE0 OTMgMCBSIA0xNDk0IDAgUiAxNDk1IDAgUiAxNDk2IDAgUiAxNDk3IDAgUiAxNDk4IDAgUiAx NDk5IDAgUiAxNTAwIDAgUiAxNTAxIDAgUiANMTUwMiAwIFIgMTUwMyAwIFIgMTUwNCAwIFIg MTUwNSAwIFIgMTUwNyAwIFIgMTUwOCAwIFIgMTUwOSAwIFIgMTUxMCAwIFIgDTE1MTEgMCBS IDE1MTIgMCBSIDE1MTMgMCBSIDE1MTQgMCBSIDE3MTIgMCBSIDE1MjEgMCBSIDE1MjIgMCBS IDE1MjMgMCBSIA0xNTI0IDAgUiAxNTI1IDAgUiAxNTI2IDAgUiAxNTI3IDAgUiAxNTI4IDAg UiAxNTI5IDAgUiAxNTMwIDAgUiAxNTMxIDAgUiANMTUzMiAwIFIgMTUzMyAwIFIgMTUzNCAw IFIgMTUzNSAwIFIgMTU0MCAwIFIgMTU0MSAwIFIgMTU0MiAwIFIgMTU0MyAwIFIgDTE1NDQg MCBSIDE1NDUgMCBSIDE1NDYgMCBSIDE1NDcgMCBSIDE1NDggMCBSIDE3MTYgMCBSIDE1NTMg MCBSIDE1NTQgMCBSIA0xNTU1IDAgUiAxNTU2IDAgUiAxNTU3IDAgUiAxNTU4IDAgUiAxNTU5 IDAgUiAxNTYwIDAgUiAxNTYxIDAgUiAxNTYyIDAgUiANMTU2MyAwIFIgMTU2NCAwIFIgMTU2 NSAwIFIgMTU2NiAwIFIgMTU2NyAwIFIgMTU2OCAwIFIgMTU2OSAwIFIgMTU3MCAwIFIgDTE1 NzEgMCBSIDE1NzIgMCBSIDE1NzMgMCBSIDE1NzQgMCBSIDE1NzUgMCBSIDE3MTkgMCBSIDE1 ODIgMCBSIDE1ODMgMCBSIA0xNTg0IDAgUiAxNTg1IDAgUiAxNTg2IDAgUiAxNTg3IDAgUiAx NTg4IDAgUiAxNTg5IDAgUiAxNTkwIDAgUiAxNTkxIDAgUiANMTU5MiAwIFIgMTU5MyAwIFIg MTU5NCAwIFIgMTU5NSAwIFIgMTU5NiAwIFIgMTU5NyAwIFIgMTU5OCAwIFIgMTU5OSAwIFIg DTE2MDAgMCBSIDE2MDEgMCBSIDE2MDIgMCBSIDE2MDMgMCBSIDE2MDQgMCBSIDE2MDUgMCBS IDE2MDYgMCBSIDE2MDcgMCBSIA0xNjA4IDAgUiAxNjA5IDAgUiAxNzIzIDAgUiAxNjI4IDAg UiAxNjI5IDAgUiAxNjMwIDAgUiAxNjMxIDAgUiAxNjMyIDAgUiANMTYzMyAwIFIgMTYzNCAw IFIgMTYzNSAwIFIgMTYzNiAwIFIgMTYzNyAwIFIgMTYzOCAwIFIgMTYzOSAwIFIgMTY0MCAw IFIgDTE2NDEgMCBSIDE2NDIgMCBSIDE2NDMgMCBSIDE2NDQgMCBSIDE2NDUgMCBSIDE2NDYg MCBSIDE2NDcgMCBSIDE2NDggMCBSIA0xNjQ5IDAgUiAxNjUwIDAgUiAxNjUxIDAgUiAxNjUy IDAgUiAxNjUzIDAgUiAxNjU0IDAgUiAxNjU1IDAgUiAxNjU2IDAgUiANMTY1NyAwIFIgMTY1 OCAwIFIgMTY1OSAwIFIgMTY2MCAwIFIgMTY2MSAwIFIgMTY2MiAwIFIgMTY2MyAwIFIgMTY2 NCAwIFIgDTE2NjUgMCBSIDE2NjYgMCBSIDE2NjcgMCBSIDE2NjggMCBSIDE2NjkgMCBSIDE2 NzAgMCBSIDE2NzEgMCBSIDE2NzIgMCBSIA0xNjczIDAgUiAxNjc0IDAgUiAxNjc1IDAgUiAx NzM0IDAgUiAxNjc4IDAgUiAxNjgxIDAgUiAxNjg1IDAgUiAxNjg4IDAgUiANMTY4OSAwIFIg MTY5MCAwIFIgMTY5MSAwIFIgMTY5MiAwIFIgMTY5MyAwIFIgMTY5NCAwIFIgMTY5NSAwIFIg MTY5NiAwIFIgDTE2OTcgMCBSIDE2OTggMCBSIDE2OTkgMCBSIDE3MDAgMCBSIF0gDT4+IA1l bmRvYmoNMTcwMiAwIG9iag08PCANL1MgL0wgDS9QIDE3MDEgMCBSIA0vSyBbIDE3MDMgMCBS IDE3MDQgMCBSIDE3MDUgMCBSIDE3MDYgMCBSIDE3MDcgMCBSIF0gDT4+IA1lbmRvYmoNMTcw MyAwIG9iag08PCANL1MgL0xJIA0vUCAxNzAyIDAgUiANL0sgMTQ0MiAwIFIgDT4+IA1lbmRv YmoNMTcwNCAwIG9iag08PCANL1MgL0xJIA0vUCAxNzAyIDAgUiANL0sgMTQ0NCAwIFIgDT4+ IA1lbmRvYmoNMTcwNSAwIG9iag08PCANL1MgL0xJIA0vUCAxNzAyIDAgUiANL0sgMTQ0NiAw IFIgDT4+IA1lbmRvYmoNMTcwNiAwIG9iag08PCANL1MgL0xJIA0vUCAxNzAyIDAgUiANL0sg MTQ0OCAwIFIgDT4+IA1lbmRvYmoNMTcwNyAwIG9iag08PCANL1MgL0xJIA0vUCAxNzAyIDAg UiANL0sgMTQ1MCAwIFIgDT4+IA1lbmRvYmoNMTcwOCAwIG9iag08PCANL1MgL0wgDS9QIDE3 MDEgMCBSIA0vSyBbIDE3MDkgMCBSIDE3MTAgMCBSIDE3MTEgMCBSIF0gDT4+IA1lbmRvYmoN MTcwOSAwIG9iag08PCANL1MgL0xJIA0vUCAxNzA4IDAgUiANL0sgMTQ1NyAwIFIgDT4+IA1l bmRvYmoNMTcxMCAwIG9iag08PCANL1MgL0xJIA0vUCAxNzA4IDAgUiANL0sgMTQ1OSAwIFIg DT4+IA1lbmRvYmoNMTcxMSAwIG9iag08PCANL1MgL0xJIA0vUCAxNzA4IDAgUiANL0sgMTQ2 MSAwIFIgDT4+IA1lbmRvYmoNMTcxMiAwIG9iag08PCANL1MgL0wgDS9QIDE3MDEgMCBSIA0v SyBbIDE3MTMgMCBSIDE3MTQgMCBSIDE3MTUgMCBSIF0gDT4+IA1lbmRvYmoNMTcxMyAwIG9i ag08PCANL1MgL0xJIA0vUCAxNzEyIDAgUiANL0sgMTUxNSAwIFIgDT4+IA1lbmRvYmoNMTcx NCAwIG9iag08PCANL1MgL0xJIA0vUCAxNzEyIDAgUiANL0sgMTUxNyAwIFIgDT4+IA1lbmRv YmoNMTcxNSAwIG9iag08PCANL1MgL0xJIA0vUCAxNzEyIDAgUiANL0sgMTUxOSAwIFIgDT4+ IA1lbmRvYmoNMTcxNiAwIG9iag08PCANL1MgL0wgDS9QIDE3MDEgMCBSIA0vSyBbIDE3MTcg MCBSIDE3MTggMCBSIF0gDT4+IA1lbmRvYmoNMTcxNyAwIG9iag08PCANL1MgL0xJIA0vUCAx NzE2IDAgUiANL0sgMTU0OSAwIFIgDT4+IA1lbmRvYmoNMTcxOCAwIG9iag08PCANL1MgL0xJ IA0vUCAxNzE2IDAgUiANL0sgMTU1MSAwIFIgDT4+IA1lbmRvYmoNMTcxOSAwIG9iag08PCAN L1MgL0wgDS9QIDE3MDEgMCBSIA0vSyBbIDE3MjAgMCBSIDE3MjEgMCBSIDE3MjIgMCBSIF0g DT4+IA1lbmRvYmoNMTcyMCAwIG9iag08PCANL1MgL0xJIA0vUCAxNzE5IDAgUiANL0sgMTU3 NiAwIFIgDT4+IA1lbmRvYmoNMTcyMSAwIG9iag08PCANL1MgL0xJIA0vUCAxNzE5IDAgUiAN L0sgMTU3OCAwIFIgDT4+IA1lbmRvYmoNMTcyMiAwIG9iag08PCANL1MgL0xJIA0vUCAxNzE5 IDAgUiANL0sgMTU4MCAwIFIgDT4+IA1lbmRvYmoNMTcyMyAwIG9iag08PCANL1MgL0wgDS9Q IDE3MDEgMCBSIA0vSyBbIDE3MjQgMCBSIDE3MjUgMCBSIDE3MjYgMCBSIDE3MjcgMCBSIDE3 MjggMCBSIDE3MjkgMCBSIDE3MzIgMCBSIDE3MzMgMCBSIA1dIA0+PiANZW5kb2JqDTE3MjQg MCBvYmoNPDwgDS9TIC9MSSANL1AgMTcyMyAwIFIgDS9LIDE2MTAgMCBSIA0+PiANZW5kb2Jq DTE3MjUgMCBvYmoNPDwgDS9TIC9MSSANL1AgMTcyMyAwIFIgDS9LIDE2MTIgMCBSIA0+PiAN ZW5kb2JqDTE3MjYgMCBvYmoNPDwgDS9TIC9MSSANL1AgMTcyMyAwIFIgDS9LIDE2MTQgMCBS IA0+PiANZW5kb2JqDTE3MjcgMCBvYmoNPDwgDS9TIC9MSSANL1AgMTcyMyAwIFIgDS9LIDE2 MTYgMCBSIA0+PiANZW5kb2JqDTE3MjggMCBvYmoNPDwgDS9TIC9MSSANL1AgMTcyMyAwIFIg DS9LIDE2MTggMCBSIA0+PiANZW5kb2JqDTE3MjkgMCBvYmoNPDwgDS9TIC9MIA0vUCAxNzIz IDAgUiANL0sgWyAxNzMwIDAgUiAxNzMxIDAgUiBdIA0+PiANZW5kb2JqDTE3MzAgMCBvYmoN PDwgDS9TIC9MSSANL1AgMTcyOSAwIFIgDS9LIDE2MjAgMCBSIA0+PiANZW5kb2JqDTE3MzEg MCBvYmoNPDwgDS9TIC9MSSANL1AgMTcyOSAwIFIgDS9LIDE2MjIgMCBSIA0+PiANZW5kb2Jq DTE3MzIgMCBvYmoNPDwgDS9TIC9MSSANL1AgMTcyMyAwIFIgDS9LIDE2MjQgMCBSIA0+PiAN ZW5kb2JqDTE3MzMgMCBvYmoNPDwgDS9TIC9MSSANL1AgMTcyMyAwIFIgDS9LIDE2MjYgMCBS IA0+PiANZW5kb2JqDTE3MzQgMCBvYmoNPDwgDS9TIC9MIA0vUCAxNzAxIDAgUiANL0sgWyAx NzM1IDAgUiAxNzM2IDAgUiAxNzM3IDAgUiAxNzM4IDAgUiBdIA0+PiANZW5kb2JqDTE3MzUg MCBvYmoNPDwgDS9TIC9MSSANL1AgMTczNCAwIFIgDS9LIDE2NzYgMCBSIA0+PiANZW5kb2Jq DTE3MzYgMCBvYmoNPDwgDS9TIC9MSSANL1AgMTczNCAwIFIgDS9LIDE2NzkgMCBSIA0+PiAN ZW5kb2JqDTE3MzcgMCBvYmoNPDwgDS9TIC9MSSANL1AgMTczNCAwIFIgDS9LIDE2ODMgMCBS IA0+PiANZW5kb2JqDTE3MzggMCBvYmoNPDwgDS9TIC9MSSANL1AgMTczNCAwIFIgDS9LIDE2 ODYgMCBSIA0+PiANZW5kb2JqDTE3MzkgMCBvYmoNPDwgDS9OdW1zIFsgMCAxNzQwIDAgUiAx IDEzNzAgMCBSIDIgMTM5OSAwIFIgMyAxNzQzIDAgUiA0IDE3NDQgMCBSIDUgMTc0NSAwIFIg DTYgMTc0NyAwIFIgNyAxNTM2IDAgUiA4IDE1MzggMCBSIDkgMTc1MCAwIFIgMTAgMTc1MSAw IFIgMTEgMTc1MiAwIFIgDTEyIDE3NTMgMCBSIF0gDT4+IA1lbmRvYmoNMTc0MCAwIG9iag1b IA0xMzUyIDAgUiAxMzU2IDAgUiAxMzU4IDAgUiAxMzYwIDAgUiAxMzYyIDAgUiAxMzYzIDAg UiAxMzY2IDAgUiAxMzY4IDAgUiANMTM3MSAwIFIgMTM2OCAwIFIgMTM3MiAwIFIgMTM3NCAw IFIgMTM3NiAwIFIgMTM3OCAwIFIgMTM4MCAwIFIgMTM4MiAwIFIgDTEzODQgMCBSIDEzODYg MCBSIDEzODggMCBSIDEzOTAgMCBSIDEzOTEgMCBSIDEzOTIgMCBSIDEzOTMgMCBSIDEzOTQg MCBSIA0xMzk1IDAgUiAxMzk2IDAgUiAxMzk3IDAgUiAxMzk4IDAgUiAxNDAwIDAgUiAxMzk4 IDAgUiAxNDAxIDAgUiAxNDAyIDAgUiANMTQwMyAwIFIgMTQwNCAwIFIgMTQwNSAwIFIgMTQw NyAwIFIgMTQwOCAwIFIgMTQwOSAwIFIgMTQxMCAwIFIgMTQxMSAwIFIgDTE0MTIgMCBSIDE0 MTMgMCBSIA1dDWVuZG9iag0xNzQxIDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dERlY29y YXRpb25UeXBlIC9VbmRlcmxpbmUgDT4+IA1lbmRvYmoNMTc0MiAwIG9iag08PCANL08gL0xh eW91dCANL1RleHREZWNvcmF0aW9uVHlwZSAvVW5kZXJsaW5lIA0+PiANZW5kb2JqDTE3NDMg MCBvYmoNWyANMTQxNCAwIFIgMTQxNSAwIFIgMTQxNiAwIFIgMTQxNyAwIFIgMTQxOCAwIFIg MTQxOSAwIFIgMTQyMCAwIFIgMTQyMSAwIFIgDTE0MjIgMCBSIDE0MjMgMCBSIDE0MjQgMCBS IDE0MjUgMCBSIDE0MjYgMCBSIDE0MjcgMCBSIDE0MjggMCBSIDE0MjkgMCBSIA0xNDMwIDAg UiAxNDMxIDAgUiAxNDMyIDAgUiAxNDMzIDAgUiAxNDM0IDAgUiAxNDM1IDAgUiAxNDM2IDAg UiAxNDM3IDAgUiANMTQzOCAwIFIgMTQzOSAwIFIgMTQ0MCAwIFIgMTQ0MSAwIFIgMTQ0MiAw IFIgMTQ0NCAwIFIgMTQ0NiAwIFIgMTQ0OCAwIFIgDTE0NTAgMCBSIDE0NTIgMCBSIDE0NTMg MCBSIA1dDWVuZG9iag0xNzQ0IDAgb2JqDVsgDTE0NTQgMCBSIDE0NTUgMCBSIDE0NTYgMCBS IDE0NTcgMCBSIDE0NTkgMCBSIDE0NjEgMCBSIDE0NjMgMCBSIDE0NjQgMCBSIA0xNDY1IDAg UiAxNDY2IDAgUiAxNDY3IDAgUiAxNDY4IDAgUiAxNDY5IDAgUiAxNDcwIDAgUiAxNDcxIDAg UiAxNDcyIDAgUiANMTQ3MyAwIFIgMTQ3NCAwIFIgMTQ3NSAwIFIgMTQ3NiAwIFIgMTQ3NyAw IFIgMTQ3OCAwIFIgMTQ3OSAwIFIgMTQ4MCAwIFIgDTE0ODEgMCBSIDE0ODIgMCBSIDE0ODMg MCBSIDE0ODQgMCBSIDE0ODUgMCBSIDE0ODYgMCBSIDE0ODcgMCBSIDE0ODggMCBSIA0xNDg5 IDAgUiAxNDkwIDAgUiAxNDkxIDAgUiAxNDkyIDAgUiAxNDkzIDAgUiAxNDk0IDAgUiAxNDk1 IDAgUiANXQ1lbmRvYmoNMTc0NSAwIG9iag1bIA0xNDk2IDAgUiAxNDk3IDAgUiAxNDk4IDAg UiAxNDk5IDAgUiAxNTAwIDAgUiAxNTAxIDAgUiAxNTAyIDAgUiAxNTAzIDAgUiANMTUwNCAw IFIgMTUwNiAwIFIgMTUwNiAwIFIgMTUwNiAwIFIgMTUwNiAwIFIgMTUwNiAwIFIgMTUwNiAw IFIgMTUwNiAwIFIgDTE1MDYgMCBSIDE1MDYgMCBSIDE1MDYgMCBSIDE1MDYgMCBSIDE1MDYg MCBSIDE1MDYgMCBSIDE1MDYgMCBSIDE1MDYgMCBSIA0xNTA2IDAgUiAxNTA2IDAgUiAxNTA2 IDAgUiAxNTA2IDAgUiAxNTA2IDAgUiAxNTA2IDAgUiAxNTA2IDAgUiAxNTA2IDAgUiANMTUw NiAwIFIgMTUwNiAwIFIgMTUwNiAwIFIgMTUwNiAwIFIgMTUwNiAwIFIgMTUwNiAwIFIgMTUw NiAwIFIgMTUwNiAwIFIgDTE1MDYgMCBSIDE1MDYgMCBSIDE1MDYgMCBSIDE1MDYgMCBSIDE1 MDYgMCBSIDE1MDYgMCBSIDE1MDYgMCBSIDE1MDYgMCBSIA0xNTA2IDAgUiAxNTA2IDAgUiAx NTA2IDAgUiAxNTA2IDAgUiAxNTA2IDAgUiAxNTA2IDAgUiAxNTA2IDAgUiAxNTA2IDAgUiAN MTUwNiAwIFIgMTUwNiAwIFIgMTUwNiAwIFIgMTUwNiAwIFIgMTUwNiAwIFIgMTUwNiAwIFIg MTUwNiAwIFIgMTUwNiAwIFIgDTE1MDYgMCBSIDE1MDYgMCBSIDE1MDYgMCBSIDE1MDYgMCBS IDE1MDYgMCBSIDE1MDYgMCBSIDE1MDYgMCBSIDE1MDYgMCBSIA0xNTA2IDAgUiAxNTA1IDAg UiAxNTA3IDAgUiAxNTA4IDAgUiAxNTA5IDAgUiAxNTEwIDAgUiAxNTExIDAgUiANXQ1lbmRv YmoNMTc0NiAwIG9iag08PCANL08gL0xheW91dCANL0JCb3ggWyA5MCAyMDYgNTI0IDQ3NSBd IA0vUGxhY2VtZW50IC9JbmxpbmUgDT4+IA1lbmRvYmoNMTc0NyAwIG9iag1bIA0xNTExIDAg UiAxNTEyIDAgUiAxNTEzIDAgUiAxNTE0IDAgUiAxNTE1IDAgUiAxNTE3IDAgUiAxNTE5IDAg UiAxNTIxIDAgUiANMTUyMiAwIFIgMTUyMyAwIFIgMTUyNCAwIFIgMTUyNSAwIFIgMTUyNiAw IFIgMTUyNyAwIFIgMTUyOCAwIFIgMTUyOSAwIFIgDTE1MzAgMCBSIDE1MzEgMCBSIDE1MzIg MCBSIDE1MzMgMCBSIDE1MzQgMCBSIDE1MzUgMCBSIDE1MzcgMCBSIDE1MzUgMCBSIA0xNTM5 IDAgUiAxNTM1IDAgUiAxNTQwIDAgUiAxNTQxIDAgUiAxNTQyIDAgUiAxNTQzIDAgUiAxNTQ0 IDAgUiAxNTQ1IDAgUiANMTU0NiAwIFIgMTU0NyAwIFIgMTU0OCAwIFIgMTU0OSAwIFIgMTU1 MSAwIFIgMTU1MyAwIFIgMTU1NCAwIFIgMTU1NSAwIFIgDTE1NTYgMCBSIDE1NTcgMCBSIA1d DWVuZG9iag0xNzQ4IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dERlY29yYXRpb25UeXBl IC9VbmRlcmxpbmUgDT4+IA1lbmRvYmoNMTc0OSAwIG9iag08PCANL08gL0xheW91dCANL1Rl eHREZWNvcmF0aW9uVHlwZSAvVW5kZXJsaW5lIA0+PiANZW5kb2JqDTE3NTAgMCBvYmoNWyAN MTU1OCAwIFIgMTU1OSAwIFIgMTU2MCAwIFIgMTU2MSAwIFIgMTU2MiAwIFIgMTU2MyAwIFIg MTU2NCAwIFIgMTU2NSAwIFIgDTE1NjYgMCBSIDE1NjcgMCBSIDE1NjggMCBSIDE1NjkgMCBS IDE1NzAgMCBSIDE1NzEgMCBSIDE1NzIgMCBSIDE1NzMgMCBSIA0xNTc0IDAgUiAxNTc1IDAg UiAxNTc2IDAgUiAxNTc4IDAgUiAxNTgwIDAgUiAxNTgyIDAgUiAxNTgzIDAgUiAxNTg0IDAg UiANMTU4NSAwIFIgMTU4NiAwIFIgMTU4NyAwIFIgMTU4OCAwIFIgMTU4OSAwIFIgMTU5MCAw IFIgMTU5MSAwIFIgMTU5MiAwIFIgDTE1OTMgMCBSIDE1OTQgMCBSIDE1OTUgMCBSIDE1OTYg MCBSIDE1OTcgMCBSIDE1OTggMCBSIDE1OTkgMCBSIDE2MDAgMCBSIA0xNjAxIDAgUiANXQ1l bmRvYmoNMTc1MSAwIG9iag1bIA0xNjAyIDAgUiAxNjAzIDAgUiAxNjA0IDAgUiAxNjA1IDAg UiAxNjA2IDAgUiAxNjA3IDAgUiAxNjA4IDAgUiAxNjA5IDAgUiANMTYxMCAwIFIgMTYxMiAw IFIgMTYxNCAwIFIgMTYxNiAwIFIgMTYxOCAwIFIgMTYyMCAwIFIgMTYyMiAwIFIgMTYyNCAw IFIgDTE2MjYgMCBSIDE2MjggMCBSIDE2MjkgMCBSIDE2MzAgMCBSIDE2MzEgMCBSIDE2MzIg MCBSIDE2MzMgMCBSIDE2MzQgMCBSIA0xNjM1IDAgUiAxNjM2IDAgUiAxNjM3IDAgUiAxNjM4 IDAgUiAxNjM5IDAgUiAxNjQwIDAgUiAxNjQxIDAgUiAxNjQyIDAgUiANMTY0MyAwIFIgMTY0 NCAwIFIgMTY0NSAwIFIgMTY0NiAwIFIgDV0NZW5kb2JqDTE3NTIgMCBvYmoNWyANMTY0NyAw IFIgMTY0OCAwIFIgMTY0OSAwIFIgMTY1MCAwIFIgMTY1MSAwIFIgMTY1MiAwIFIgMTY1MyAw IFIgMTY1NCAwIFIgDTE2NTUgMCBSIDE2NTYgMCBSIDE2NTcgMCBSIDE2NTggMCBSIDE2NTkg MCBSIDE2NjAgMCBSIDE2NjEgMCBSIDE2NjIgMCBSIA0xNjYzIDAgUiAxNjY0IDAgUiAxNjY1 IDAgUiAxNjY2IDAgUiAxNjY3IDAgUiAxNjY4IDAgUiAxNjY5IDAgUiAxNjcwIDAgUiANMTY3 MSAwIFIgMTY3MiAwIFIgMTY3MyAwIFIgMTY3NCAwIFIgMTY3NSAwIFIgMTY3NiAwIFIgMTY3 OCAwIFIgMTY3OSAwIFIgDTE2ODEgMCBSIDE2ODMgMCBSIDE2ODUgMCBSIDE2ODYgMCBSIDE2 ODggMCBSIDE2ODkgMCBSIDE2OTAgMCBSIDE2OTEgMCBSIA0xNjkyIDAgUiAxNjkzIDAgUiAx Njk0IDAgUiAxNjk1IDAgUiAxNjk2IDAgUiAxNjk3IDAgUiAxNjk4IDAgUiAxNjk5IDAgUiAN DV0NZW5kb2JqDTE3NTMgMCBvYmoNWyANMTcwMCAwIFIgDV0NZW5kb2JqDTE3NTQgMCBvYmoN PDwgDS9TIC9EIA0+PiANZW5kb2JqDTE3NTUgMCBvYmoNPDwgDS9OdW1zIFsgMCAxNzU0IDAg UiBdIA0+PiANZW5kb2JqDTE3NTYgMCBvYmoNPDwgDS9Qcm9kdWNlciAoQWNyb2JhdCBEaXN0 aWxsZXIgNS4wIFwoV2luZG93c1wpKQ0vQXV0aG9yIChAc3Rha2UpDS9DcmVhdG9yIChBY3Jv YmF0IFBERk1ha2VyIDUuMCBmb3IgV29yZCkNL01vZERhdGUgKEQ6MjAwMjAyMTUwOTAzMzla KQ0vVGl0bGUgKFwzNzZcMzc3XDAwMFJcMDAwZVwwMDB2XDAwMGlcMDAwZVwwMDB3XDAwMCBc MDAwb1wwMDBmXDAwMCBcMDAwc1wwMDBlXDAwMFwNY1wwMDB0XDAwMGlcMDAwb1wwMDBuXDAw MCBcMDAwMlwwMDAyXDAwMCAgXDAzNFwwMDBTXDAwMGVcMDAwY1wwMDB1XDAwMHJcMDAwXA1p XDAwMHRcMDAweVwwMDAgXDAwMENcMDAwb1wwMDBuXDAwMHNcMDAwaVwwMDBkXDAwMGVcMDAw clwwMDBhXDAwMHRcMDAwaVwwMDBcDW9cMDAwblwwMDBzIFwwMzVcMDAwIFwwMDBvXDAwMGZc MDAwIFwwMDBkXDAwMHJcMDAwYVwwMDBmXDAwMHRcMDAwLVwwMDBpXDAwMFwNZVwwMDB0XDAw MGZcMDAwLVwwMDBzXDAwMGlcMDAwcFwwMDAtXDAwMHJcMDAwZlwwMDBjXDAwMDJcMDAwNVww MDA0XDAwMDNcMDAwXA1iXDAwMGlcMDAwc1wwMDAtXDAwMDBcMDAwNykNL0NyZWF0aW9uRGF0 ZSAoRDoyMDAyMDIxNTA5MDMyMFowMCcwMCcpDT4+IA1lbmRvYmoNMTc1NyAwIG9iag08PCAv VHlwZSAvTWV0YWRhdGEgL1N1YnR5cGUgL1hNTCAvTGVuZ3RoIDEyODUgPj4gDXN0cmVhbQ0K PD94cGFja2V0IGJlZ2luPScnIGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnIGJ5dGVz PScxMjg0Jz8+PHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAy LzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8x LjAvJz48cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHhtbG5zPSdodHRwOi8vbnMuYWRvYmUu Y29tL3BkZi8xLjMvJyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8n IHBkZjpDcmVhdGlvbkRhdGU9JzIwMDItMDItMTVUMDk6MDM6MjBaJyBwZGY6TW9kRGF0ZT0n MjAwMi0wMi0xNVQwOTowMzoyMFonIHBkZjpQcm9kdWNlcj0nQWNyb2JhdCBEaXN0aWxsZXIg NS4wIChXaW5kb3dzKScgcGRmOkF1dGhvcj0nQHN0YWtlJyBwZGY6Q3JlYXRvcj0nQWNyb2Jh dCBQREZNYWtlciA1LjAgZm9yIFdvcmQnPjxwZGY6VGl0bGU+UmV2aWV3IG9mIHNlY3Rpb24g MjIg4oCcU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnPigJ0gb2YgZHJhZnQtaWV0Zi1zaXAtcmZj MjU0M2Jpcy0wNzwvcGRmOlRpdGxlPjwvcmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0 aW9uIGFib3V0PScnIHhtbG5zPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4bWxu czp4YXA9J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nIHhhcDpDcmVhdGVEYXRlPScy MDAyLTAyLTE1VDA5OjAzOjIwWicgeGFwOk1vZGlmeURhdGU9JzIwMDItMDItMTVUMDk6MDM6 MjBaJyB4YXA6QXV0aG9yPSdAc3Rha2UnIHhhcDpNZXRhZGF0YURhdGU9JzIwMDItMDItMTVU MDk6MDM6MjBaJz48eGFwOlRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gtZGVm YXVsdCc+UmV2aWV3IG9mIHNlY3Rpb24gMjIg4oCcU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnPi gJ0gb2YgZHJhZnQtaWV0Zi1zaXAtcmZjMjU0M2Jpcy0wNzwvcmRmOmxpPjwvcmRmOkFsdD48 L3hhcDpUaXRsZT48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiBhYm91dD0n JyB4bWxucz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8nIHhtbG5zOmRjPSdo dHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgZGM6Y3JlYXRvcj0nQHN0YWtlJz48 ZGM6dGl0bGU+UmV2aWV3IG9mIHNlY3Rpb24gMjIg4oCcU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnPigJ0gb2YgZHJhZnQtaWV0Zi1zaXAtcmZjMjU0M2Jpcy0wNzwvZGM6dGl0bGU+PC9yZGY6 RGVzY3JpcHRpb24+CjwvcmRmOlJERj48P3hwYWNrZXQgZW5kPSdyJz8+CmVuZHN0cmVhbQ1l bmRvYmoNMTc1OCAwIG9iag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDE3NjIgMCBSIDEg MCBSIDQgMCBSIDcgMCBSIDQ2OSAwIFIgNDczIDAgUiA0NzYgMCBSIDQ3OSAwIFIgNDgyIDAg UiANXSANL0NvdW50IDkgDT4+IA1lbmRvYmoNeHJlZg0wIDE3NTkgDTAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDEyMzg0NyAwMDAwMCBuDQowMDAwMTI0MjMyIDAwMDAwIG4NCjAwMDAxMjk5 NzkgMDAwMDAgbg0KMDAwMDEzMDAwMCAwMDAwMCBuDQowMDAwMTMwMzg1IDAwMDAwIG4NCjAw MDAxMzU4MDQgMDAwMDAgbg0KMDAwMDEzNTgyNSAwMDAwMCBuDQowMDAwMTQ5NjI0IDAwMDAw IG4NCjAwMDAxNjQwMDkgMDAwMDAgbg0KMDAwMDE2NDAzMSAwMDAwMCBuDQowMDAwMTY0MjMx IDAwMDAwIG4NCjAwMDAxNjQ0MjQgMDAwMDAgbg0KMDAwMDE2NDYyMyAwMDAwMCBuDQowMDAw MTY0ODE5IDAwMDAwIG4NCjAwMDAxNjUwMDIgMDAwMDAgbg0KMDAwMDE2NTE4NSAwMDAwMCBu DQowMDAwMTY1MzcwIDAwMDAwIG4NCjAwMDAxNjU1NTEgMDAwMDAgbg0KMDAwMDE2NTczNiAw MDAwMCBuDQowMDAwMTY1OTE3IDAwMDAwIG4NCjAwMDAxNjYxMDcgMDAwMDAgbg0KMDAwMDE2 NjI4OCAwMDAwMCBuDQowMDAwMTY2NDc2IDAwMDAwIG4NCjAwMDAxNjY2NTggMDAwMDAgbg0K MDAwMDE2Njg1MCAwMDAwMCBuDQowMDAwMTY3MDMwIDAwMDAwIG4NCjAwMDAxNjcyMjcgMDAw MDAgbg0KMDAwMDE2NzQwOCAwMDAwMCBuDQowMDAwMTY3NjA0IDAwMDAwIG4NCjAwMDAxNjc3 ODUgMDAwMDAgbg0KMDAwMDE2Nzk4MSAwMDAwMCBuDQowMDAwMTY4MTY0IDAwMDAwIG4NCjAw MDAxNjgzNTkgMDAwMDAgbg0KMDAwMDE2ODU0MiAwMDAwMCBuDQowMDAwMTY4NzQwIDAwMDAw IG4NCjAwMDAxNjg5MjUgMDAwMDAgbg0KMDAwMDE2OTEzMyAwMDAwMCBuDQowMDAwMTY5MzQ1 IDAwMDAwIG4NCjAwMDAxNjk1NTYgMDAwMDAgbg0KMDAwMDE2OTc3MiAwMDAwMCBuDQowMDAw MTY5OTkyIDAwMDAwIG4NCjAwMDAxNzAyMTQgMDAwMDAgbg0KMDAwMDE3MDQzOCAwMDAwMCBu DQowMDAwMTcwNjYxIDAwMDAwIG4NCjAwMDAxNzA4OTAgMDAwMDAgbg0KMDAwMDE3MTExNiAw MDAwMCBuDQowMDAwMTcxMzQzIDAwMDAwIG4NCjAwMDAxNzE1NzEgMDAwMDAgbg0KMDAwMDE3 MTgwMyAwMDAwMCBuDQowMDAwMTcyMDM2IDAwMDAwIG4NCjAwMDAxNzIyNzYgMDAwMDAgbg0K MDAwMDE3MjUxNiAwMDAwMCBuDQowMDAwMTcyNzU0IDAwMDAwIG4NCjAwMDAxNzI5OTcgMDAw MDAgbg0KMDAwMDE3MzIzOCAwMDAwMCBuDQowMDAwMTczNDg3IDAwMDAwIG4NCjAwMDAxNzM3 MzMgMDAwMDAgbg0KMDAwMDE3Mzk4MCAwMDAwMCBuDQowMDAwMTc0MjI1IDAwMDAwIG4NCjAw MDAxNzQ0NzggMDAwMDAgbg0KMDAwMDE3NDczMyAwMDAwMCBuDQowMDAwMTc0OTkwIDAwMDAw IG4NCjAwMDAxNzUyNDcgMDAwMDAgbg0KMDAwMDE3NTUwNyAwMDAwMCBuDQowMDAwMTc1Nzcy IDAwMDAwIG4NCjAwMDAxNzYwMzIgMDAwMDAgbg0KMDAwMDE3NjI5MiAwMDAwMCBuDQowMDAw MTc2NTUwIDAwMDAwIG4NCjAwMDAxNzY4MTcgMDAwMDAgbg0KMDAwMDE3NzA4MCAwMDAwMCBu DQowMDAwMTc3MzQ4IDAwMDAwIG4NCjAwMDAxNzc2MTcgMDAwMDAgbg0KMDAwMDE3Nzg4OSAw MDAwMCBuDQowMDAwMTc4MTU5IDAwMDAwIG4NCjAwMDAxNzg0MzUgMDAwMDAgbg0KMDAwMDE3 ODcxMyAwMDAwMCBuDQowMDAwMTc4OTkyIDAwMDAwIG4NCjAwMDAxNzkyNzcgMDAwMDAgbg0K MDAwMDE3OTU1OSAwMDAwMCBuDQowMDAwMTc5ODQyIDAwMDAwIG4NCjAwMDAxODAxMjcgMDAw MDAgbg0KMDAwMDE4MDQxNSAwMDAwMCBuDQowMDAwMTgwNzAzIDAwMDAwIG4NCjAwMDAxODA5 OTQgMDAwMDAgbg0KMDAwMDE4MTI4NyAwMDAwMCBuDQowMDAwMTgxNTgzIDAwMDAwIG4NCjAw MDAxODE4ODIgMDAwMDAgbg0KMDAwMDE4MjE3OCAwMDAwMCBuDQowMDAwMTgyNDcyIDAwMDAw IG4NCjAwMDAxODI3NjIgMDAwMDAgbg0KMDAwMDE4MzA2NyAwMDAwMCBuDQowMDAwMTgzMzY2 IDAwMDAwIG4NCjAwMDAxODM2NjkgMDAwMDAgbg0KMDAwMDE4Mzk2OCAwMDAwMCBuDQowMDAw MTg0Mjc3IDAwMDAwIG4NCjAwMDAxODQ1ODIgMDAwMDAgbg0KMDAwMDE4NDg5MSAwMDAwMCBu DQowMDAwMTg1MTk3IDAwMDAwIG4NCjAwMDAxODU1MDQgMDAwMDAgbg0KMDAwMDE4NTgxNyAw MDAwMCBuDQowMDAwMTg2MTI2IDAwMDAwIG4NCjAwMDAxODY0NDUgMDAwMDAgbg0KMDAwMDE4 Njc2NCAwMDAwMCBuDQowMDAwMTg3MDg1IDAwMDAwIG4NCjAwMDAxODc0MDUgMDAwMDAgbg0K MDAwMDE4NzcyOSAwMDAwMCBuDQowMDAwMTg4MDgwIDAwMDAwIG4NCjAwMDAxODgzOTcgMDAw MDAgbg0KMDAwMDE4ODcxMyAwMDAwMCBuDQowMDAwMTg5MDMwIDAwMDAwIG4NCjAwMDAxODkz NTAgMDAwMDAgbg0KMDAwMDE4OTY3MyAwMDAwMCBuDQowMDAwMTg5OTk0IDAwMDAwIG4NCjAw MDAxOTAzMTYgMDAwMDAgbg0KMDAwMDE5MDYzNCAwMDAwMCBuDQowMDAwMTkwOTQ5IDAwMDAw IG4NCjAwMDAxOTEyNTggMDAwMDAgbg0KMDAwMDE5MTU3MyAwMDAwMCBuDQowMDAwMTkxODc5 IDAwMDAwIG4NCjAwMDAxOTIxODUgMDAwMDAgbg0KMDAwMDE5MjQ5MyAwMDAwMCBuDQowMDAw MTkyODU2IDAwMDAwIG4NCjAwMDAxOTMxNTcgMDAwMDAgbg0KMDAwMDE5MzQ2MCAwMDAwMCBu DQowMDAwMTkzNzU5IDAwMDAwIG4NCjAwMDAxOTQwNjEgMDAwMDAgbg0KMDAwMDE5NDM1NCAw MDAwMCBuDQowMDAwMTk0NjQ4IDAwMDAwIG4NCjAwMDAxOTQ5NDUgMDAwMDAgbg0KMDAwMDE5 NTI0MiAwMDAwMCBuDQowMDAwMTk1NTM2IDAwMDAwIG4NCjAwMDAxOTU4MzQgMDAwMDAgbg0K MDAwMDE5NjEyNyAwMDAwMCBuDQowMDAwMTk2NDYyIDAwMDAwIG4NCjAwMDAxOTY3NDEgMDAw MDAgbg0KMDAwMDE5NzAyNSAwMDAwMCBuDQowMDAwMTk3MzEwIDAwMDAwIG4NCjAwMDAxOTc1 OTUgMDAwMDAgbg0KMDAwMDE5NzkxNSAwMDAwMCBuDQowMDAwMTk4MTg5IDAwMDAwIG4NCjAw MDAxOTg0NjQgMDAwMDAgbg0KMDAwMDE5ODc3NiAwMDAwMCBuDQowMDAwMTk5MDQ5IDAwMDAw IG4NCjAwMDAxOTkzMTUgMDAwMDAgbg0KMDAwMDE5OTU4MyAwMDAwMCBuDQowMDAwMTk5ODQ0 IDAwMDAwIG4NCjAwMDAyMDAxNDIgMDAwMDAgbg0KMDAwMDIwMDQwNyAwMDAwMCBuDQowMDAw MjAwNjY5IDAwMDAwIG4NCjAwMDAyMDA5MzAgMDAwMDAgbg0KMDAwMDIwMTE4OSAwMDAwMCBu DQowMDAwMjAxNDQ1IDAwMDAwIG4NCjAwMDAyMDE3MDIgMDAwMDAgbg0KMDAwMDIwMTk0OCAw MDAwMCBuDQowMDAwMjAyMTk2IDAwMDAwIG4NCjAwMDAyMDI0NDcgMDAwMDAgbg0KMDAwMDIw MjY5OSAwMDAwMCBuDQowMDAwMjAyOTQzIDAwMDAwIG4NCjAwMDAyMDMxODcgMDAwMDAgbg0K MDAwMDIwMzQyOCAwMDAwMCBuDQowMDAwMjAzNjczIDAwMDAwIG4NCjAwMDAyMDM5MTMgMDAw MDAgbg0KMDAwMDIwNDE0OCAwMDAwMCBuDQowMDAwMjA0Mzg0IDAwMDAwIG4NCjAwMDAyMDQ2 MTMgMDAwMDAgbg0KMDAwMDIwNDg0MyAwMDAwMCBuDQowMDAwMjA1MDcyIDAwMDAwIG4NCjAw MDAyMDUzMDMgMDAwMDAgbg0KMDAwMDIwNTUyOSAwMDAwMCBuDQowMDAwMjA1NzU1IDAwMDAw IG4NCjAwMDAyMDU5NzkgMDAwMDAgbg0KMDAwMDIwNjIwMSAwMDAwMCBuDQowMDAwMjA2NDI2 IDAwMDAwIG4NCjAwMDAyMDY2NDIgMDAwMDAgbg0KMDAwMDIwNjg1NyAwMDAwMCBuDQowMDAw MjA3MDY2IDAwMDAwIG4NCjAwMDAyMDcyNzggMDAwMDAgbg0KMDAwMDIwNzQ4NSAwMDAwMCBu DQowMDAwMjA3Njk1IDAwMDAwIG4NCjAwMDAyMDc4ODEgMDAwMDAgbg0KMDAwMDIwODA4MSAw MDAwMCBuDQowMDAwMjA4MjY2IDAwMDAwIG4NCjAwMDAyMDg0NjggMDAwMDAgbg0KMDAwMDIw ODY1MCAwMDAwMCBuDQowMDAwMjA4ODQ2IDAwMDAwIG4NCjAwMDAyMDkwMjggMDAwMDAgbg0K MDAwMDIwOTIyMCAwMDAwMCBuDQowMDAwMjA5NDAyIDAwMDAwIG4NCjAwMDAyMDk1OTQgMDAw MDAgbg0KMDAwMDIwOTc3NiAwMDAwMCBuDQowMDAwMjA5OTY1IDAwMDAwIG4NCjAwMDAyMTAx NDggMDAwMDAgbg0KMDAwMDIxMDMzOCAwMDAwMCBuDQowMDAwMjEwNTIwIDAwMDAwIG4NCjAw MDAyMTA3MDYgMDAwMDAgbg0KMDAwMDIxMDg4OSAwMDAwMCBuDQowMDAwMjExMDc2IDAwMDAw IG4NCjAwMDAyMTEyNTggMDAwMDAgbg0KMDAwMDIxMTQ0NSAwMDAwMCBuDQowMDAwMjExNjI5 IDAwMDAwIG4NCjAwMDAyMTE4MTMgMDAwMDAgbg0KMDAwMDIxMjAwOSAwMDAwMCBuDQowMDAw MjEyMjA3IDAwMDAwIG4NCjAwMDAyMTIzOTkgMDAwMDAgbg0KMDAwMDIxMjU5OSAwMDAwMCBu DQowMDAwMjEyNzk3IDAwMDAwIG4NCjAwMDAyMTI5OTUgMDAwMDAgbg0KMDAwMDIxMzE5MyAw MDAwMCBuDQowMDAwMjEzMzkxIDAwMDAwIG4NCjAwMDAyMTM1ODkgMDAwMDAgbg0KMDAwMDIx Mzc4NyAwMDAwMCBuDQowMDAwMjEzOTcwIDAwMDAwIG4NCjAwMDAyMTQxNTMgMDAwMDAgbg0K MDAwMDIxNDMzNiAwMDAwMCBuDQowMDAwMjE0NTE4IDAwMDAwIG4NCjAwMDAyMTQ3MDAgMDAw MDAgbg0KMDAwMDIxNDg4MiAwMDAwMCBuDQowMDAwMjE1MDY1IDAwMDAwIG4NCjAwMDAyMTUy NDcgMDAwMDAgbg0KMDAwMDIxNTQzMCAwMDAwMCBuDQowMDAwMjE1NjEzIDAwMDAwIG4NCjAw MDAyMTU3OTYgMDAwMDAgbg0KMDAwMDIxNTk3OCAwMDAwMCBuDQowMDAwMjE2MTYwIDAwMDAw IG4NCjAwMDAyMTYzNDIgMDAwMDAgbg0KMDAwMDIxNjUyNCAwMDAwMCBuDQowMDAwMjE2NzA1 IDAwMDAwIG4NCjAwMDAyMTY4OTAgMDAwMDAgbg0KMDAwMDIxNzA3MSAwMDAwMCBuDQowMDAw MjE3MjU0IDAwMDAwIG4NCjAwMDAyMTc0NDIgMDAwMDAgbg0KMDAwMDIxNzYyNCAwMDAwMCBu DQowMDAwMjE3ODA5IDAwMDAwIG4NCjAwMDAyMTc5OTYgMDAwMDAgbg0KMDAwMDIxODE3OCAw MDAwMCBuDQowMDAwMjE4MzYzIDAwMDAwIG4NCjAwMDAyMTg1NTIgMDAwMDAgbg0KMDAwMDIx ODczNCAwMDAwMCBuDQowMDAwMjE4OTIwIDAwMDAwIG4NCjAwMDAyMTkxMTIgMDAwMDAgbg0K MDAwMDIxOTI5MyAwMDAwMCBuDQowMDAwMjE5NDgxIDAwMDAwIG4NCjAwMDAyMTk2NzMgMDAw MDAgbg0KMDAwMDIxOTg1NSAwMDAwMCBuDQowMDAwMjIwMDQ2IDAwMDAwIG4NCjAwMDAyMjAy NDEgMDAwMDAgbg0KMDAwMDIyMDQyMiAwMDAwMCBuDQowMDAwMjIwNjE0IDAwMDAwIG4NCjAw MDAyMjA4MDggMDAwMDAgbg0KMDAwMDIyMDk5MCAwMDAwMCBuDQowMDAwMjIxMTg1IDAwMDAw IG4NCjAwMDAyMjEzNzkgMDAwMDAgbg0KMDAwMDIyMTU2MSAwMDAwMCBuDQowMDAwMjIxNzU1 IDAwMDAwIG4NCjAwMDAyMjE5NDggMDAwMDAgbg0KMDAwMDIyMjEzMCAwMDAwMCBuDQowMDAw MjIyMzIyIDAwMDAwIG4NCjAwMDAyMjI1MTcgMDAwMDAgbg0KMDAwMDIyMjY5OCAwMDAwMCBu DQowMDAwMjIyOTE1IDAwMDAwIG4NCjAwMDAyMjMxMzUgMDAwMDAgbg0KMDAwMDIyMzM1NCAw MDAwMCBuDQowMDAwMjIzNTc4IDAwMDAwIG4NCjAwMDAyMjM4MDIgMDAwMDAgbg0KMDAwMDIy NDAyNCAwMDAwMCBuDQowMDAwMjI0MjU0IDAwMDAwIG4NCjAwMDAyMjQ0ODUgMDAwMDAgbg0K MDAwMDIyNDcxNSAwMDAwMCBuDQowMDAwMjI0OTQ0IDAwMDAwIG4NCjAwMDAyMjUxNzggMDAw MDAgbg0KMDAwMDIyNTQxMSAwMDAwMCBuDQowMDAwMjI1NjQ3IDAwMDAwIG4NCjAwMDAyMjU4 ODYgMDAwMDAgbg0KMDAwMDIyNjEyOSAwMDAwMCBuDQowMDAwMjI2Mzc0IDAwMDAwIG4NCjAw MDAyMjY2MTkgMDAwMDAgbg0KMDAwMDIyNjg2OCAwMDAwMCBuDQowMDAwMjI3MTE2IDAwMDAw IG4NCjAwMDAyMjczNjcgMDAwMDAgbg0KMDAwMDIyNzYxOCAwMDAwMCBuDQowMDAwMjI3ODcw IDAwMDAwIG4NCjAwMDAyMjgxMjYgMDAwMDAgbg0KMDAwMDIyODM4NiAwMDAwMCBuDQowMDAw MjI4NjQ4IDAwMDAwIG4NCjAwMDAyMjg5MDYgMDAwMDAgbg0KMDAwMDIyOTE2OSAwMDAwMCBu DQowMDAwMjI5NDM0IDAwMDAwIG4NCjAwMDAyMjk2OTcgMDAwMDAgbg0KMDAwMDIyOTk2MCAw MDAwMCBuDQowMDAwMjMwMjI1IDAwMDAwIG4NCjAwMDAyMzA0OTUgMDAwMDAgbg0KMDAwMDIz MDc2OSAwMDAwMCBuDQowMDAwMjMxMDQxIDAwMDAwIG4NCjAwMDAyMzEzMTQgMDAwMDAgbg0K MDAwMDIzMTU5MSAwMDAwMCBuDQowMDAwMjMxODcxIDAwMDAwIG4NCjAwMDAyMzIxNTAgMDAw MDAgbg0KMDAwMDIzMjQyOSAwMDAwMCBuDQowMDAwMjMyNzEzIDAwMDAwIG4NCjAwMDAyMzI5 OTMgMDAwMDAgbg0KMDAwMDIzMzI3OCAwMDAwMCBuDQowMDAwMjMzNTYzIDAwMDAwIG4NCjAw MDAyMzM4NDQgMDAwMDAgbg0KMDAwMDIzNDEzMiAwMDAwMCBuDQowMDAwMjM0NDIxIDAwMDAw IG4NCjAwMDAyMzQ3MTUgMDAwMDAgbg0KMDAwMDIzNTAwNSAwMDAwMCBuDQowMDAwMjM1MzAw IDAwMDAwIG4NCjAwMDAyMzU1OTQgMDAwMDAgbg0KMDAwMDIzNTg5MiAwMDAwMCBuDQowMDAw MjM2MTkzIDAwMDAwIG4NCjAwMDAyMzY0OTQgMDAwMDAgbg0KMDAwMDIzNjg1OSAwMDAwMCBu DQowMDAwMjM3MTY1IDAwMDAwIG4NCjAwMDAyMzc0NjUgMDAwMDAgbg0KMDAwMDIzNzgxOCAw MDAwMCBuDQowMDAwMjM4MTMyIDAwMDAwIG4NCjAwMDAyMzg0MzggMDAwMDAgbg0KMDAwMDIz ODc1NCAwMDAwMCBuDQowMDAwMjM5MDY5IDAwMDAwIG4NCjAwMDAyMzk0MjAgMDAwMDAgbg0K MDAwMDIzOTczMiAwMDAwMCBuDQowMDAwMjQwMDQ2IDAwMDAwIG4NCjAwMDAyNDAzNjAgMDAw MDAgbg0KMDAwMDI0MDY3NCAwMDAwMCBuDQowMDAwMjQwOTg3IDAwMDAwIG4NCjAwMDAyNDEz MDMgMDAwMDAgbg0KMDAwMDI0MTYxNCAwMDAwMCBuDQowMDAwMjQxOTMxIDAwMDAwIG4NCjAw MDAyNDIyODIgMDAwMDAgbg0KMDAwMDI0MjU5NiAwMDAwMCBuDQowMDAwMjQyOTAzIDAwMDAw IG4NCjAwMDAyNDMyMTYgMDAwMDAgbg0KMDAwMDI0MzUyMCAwMDAwMCBuDQowMDAwMjQzODI1 IDAwMDAwIG4NCjAwMDAyNDQxMjggMDAwMDAgbg0KMDAwMDI0NDQ4NCAwMDAwMCBuDQowMDAw MjQ0Nzg0IDAwMDAwIG4NCjAwMDAyNDUwODcgMDAwMDAgbg0KMDAwMDI0NTQzNyAwMDAwMCBu DQowMDAwMjQ1NzI5IDAwMDAwIG4NCjAwMDAyNDYwMjUgMDAwMDAgbg0KMDAwMDI0NjMxNCAw MDAwMCBuDQowMDAwMjQ2NjA2IDAwMDAwIG4NCjAwMDAyNDY4ODkgMDAwMDAgbg0KMDAwMDI0 NzE3NiAwMDAwMCBuDQowMDAwMjQ3NDY0IDAwMDAwIG4NCjAwMDAyNDc3NDYgMDAwMDAgbg0K MDAwMDI0ODAyOSAwMDAwMCBuDQowMDAwMjQ4MzEwIDAwMDAwIG4NCjAwMDAyNDg1ODkgMDAw MDAgbg0KMDAwMDI0ODg2MyAwMDAwMCBuDQowMDAwMjQ5MTM5IDAwMDAwIG4NCjAwMDAyNDk0 MTQgMDAwMDAgbg0KMDAwMDI0OTY5MiAwMDAwMCBuDQowMDAwMjQ5OTYxIDAwMDAwIG4NCjAw MDAyNTAyMzIgMDAwMDAgbg0KMDAwMDI1MDUwNCAwMDAwMCBuDQowMDAwMjUwNzcyIDAwMDAw IG4NCjAwMDAyNTEwMzYgMDAwMDAgbg0KMDAwMDI1MTI5NiAwMDAwMCBuDQowMDAwMjUxNTU2 IDAwMDAwIG4NCjAwMDAyNTE4MjAgMDAwMDAgbg0KMDAwMDI1MjA4MiAwMDAwMCBuDQowMDAw MjUyMzM4IDAwMDAwIG4NCjAwMDAyNTI1OTYgMDAwMDAgbg0KMDAwMDI1Mjg1MiAwMDAwMCBu DQowMDAwMjUzMTA0IDAwMDAwIG4NCjAwMDAyNTMzNTcgMDAwMDAgbg0KMDAwMDI1MzYwOCAw MDAwMCBuDQowMDAwMjUzODYwIDAwMDAwIG4NCjAwMDAyNTQxMDggMDAwMDAgbg0KMDAwMDI1 NDM1OCAwMDAwMCBuDQowMDAwMjU0NjAxIDAwMDAwIG4NCjAwMDAyNTQ4NDcgMDAwMDAgbg0K MDAwMDI1NTA5MCAwMDAwMCBuDQowMDAwMjU1MzMwIDAwMDAwIG4NCjAwMDAyNTU1NjggMDAw MDAgbg0KMDAwMDI1NTgwNCAwMDAwMCBuDQowMDAwMjU2MDM4IDAwMDAwIG4NCjAwMDAyNTYy NjcgMDAwMDAgbg0KMDAwMDI1NjQ5NiAwMDAwMCBuDQowMDAwMjU2NzI2IDAwMDAwIG4NCjAw MDAyNTY5NTUgMDAwMDAgbg0KMDAwMDI1NzE3NyAwMDAwMCBuDQowMDAwMjU3NDAwIDAwMDAw IG4NCjAwMDAyNTc2MTggMDAwMDAgbg0KMDAwMDI1NzgzNiAwMDAwMCBuDQowMDAwMjU4MDU0 IDAwMDAwIG4NCjAwMDAyNTgyNjQgMDAwMDAgbg0KMDAwMDI1ODQ3MyAwMDAwMCBuDQowMDAw MjU4Njc5IDAwMDAwIG4NCjAwMDAyNTg4OTEgMDAwMDAgbg0KMDAwMDI1OTA3MyAwMDAwMCBu DQowMDAwMjU5MjY5IDAwMDAwIG4NCjAwMDAyNTk0NTggMDAwMDAgbg0KMDAwMDI1OTYzOSAw MDAwMCBuDQowMDAwMjU5ODM1IDAwMDAwIG4NCjAwMDAyNjAwMjIgMDAwMDAgbg0KMDAwMDI2 MDIwNCAwMDAwMCBuDQowMDAwMjYwMzk2IDAwMDAwIG4NCjAwMDAyNjA1ODIgMDAwMDAgbg0K MDAwMDI2MDc2MyAwMDAwMCBuDQowMDAwMjYwOTU3IDAwMDAwIG4NCjAwMDAyNjExNDIgMDAw MDAgbg0KMDAwMDI2MTMyNCAwMDAwMCBuDQowMDAwMjYxNTE3IDAwMDAwIG4NCjAwMDAyNjE2 OTkgMDAwMDAgbg0KMDAwMDI2MTg4MSAwMDAwMCBuDQowMDAwMjYyMDY4IDAwMDAwIG4NCjAw MDAyNjIyNTEgMDAwMDAgbg0KMDAwMDI2MjQzMyAwMDAwMCBuDQowMDAwMjYyNjIwIDAwMDAw IG4NCjAwMDAyNjI4MDIgMDAwMDAgbg0KMDAwMDI2Mjk4NCAwMDAwMCBuDQowMDAwMjYzMTY5 IDAwMDAwIG4NCjAwMDAyNjMzNTEgMDAwMDAgbg0KMDAwMDI2MzUzMyAwMDAwMCBuDQowMDAw MjYzNzE4IDAwMDAwIG4NCjAwMDAyNjM5MDAgMDAwMDAgbg0KMDAwMDI2NDA4MiAwMDAwMCBu DQowMDAwMjY0MjY0IDAwMDAwIG4NCjAwMDAyNjQ0NDcgMDAwMDAgbg0KMDAwMDI2NDYyOSAw MDAwMCBuDQowMDAwMjY0ODExIDAwMDAwIG4NCjAwMDAyNjQ5OTMgMDAwMDAgbg0KMDAwMDI2 NTE3NSAwMDAwMCBuDQowMDAwMjY1MzU3IDAwMDAwIG4NCjAwMDAyNjU1MzkgMDAwMDAgbg0K MDAwMDI2NTcyMSAwMDAwMCBuDQowMDAwMjY1OTA0IDAwMDAwIG4NCjAwMDAyNjYwODcgMDAw MDAgbg0KMDAwMDI2NjI2OSAwMDAwMCBuDQowMDAwMjY2NDUxIDAwMDAwIG4NCjAwMDAyNjY2 MzMgMDAwMDAgbg0KMDAwMDI2NjgxNSAwMDAwMCBuDQowMDAwMjY2OTk3IDAwMDAwIG4NCjAw MDAyNjcxNzkgMDAwMDAgbg0KMDAwMDI2NzM2MiAwMDAwMCBuDQowMDAwMjY3NTQ1IDAwMDAw IG4NCjAwMDAyNjc3MjggMDAwMDAgbg0KMDAwMDI2NzkyNCAwMDAwMCBuDQowMDAwMjY4MTIx IDAwMDAwIG4NCjAwMDAyNjgzMTkgMDAwMDAgbg0KMDAwMDI2ODUxNyAwMDAwMCBuDQowMDAw MjY4NzE0IDAwMDAwIG4NCjAwMDAyNjg5MTIgMDAwMDAgbg0KMDAwMDI3MDcyMCAwMDAwMCBu DQowMDAwMjcyMTg4IDAwMDAwIG4NCjAwMDAyNzI1MDggMDAwMDAgbg0KMDAwMDI3Mjg1MiAw MDAwMCBuDQowMDAwMjczMjA1IDAwMDAwIG4NCjAwMDAyNzM1NTYgMDAwMDAgbg0KMDAwMDI3 MzkxNCAwMDAwMCBuDQowMDAwMjc0MjM2IDAwMDAwIG4NCjAwMDAyNzQ1NTQgMDAwMDAgbg0K MDAwMDI3NDkxMSAwMDAwMCBuDQowMDAwMjc1MjczIDAwMDAwIG4NCjAwMDAyNzU1NzUgMDAw MDAgbg0KMDAwMDI3NTg4MSAwMDAwMCBuDQowMDAwMjc2MjI0IDAwMDAwIG4NCjAwMDAyNzY1 MTMgMDAwMDAgbg0KMDAwMDI3Njc5OSAwMDAwMCBuDQowMDAwMjc3MDgwIDAwMDAwIG4NCjAw MDAyNzczNjMgMDAwMDAgbg0KMDAwMDI3NzYzNiAwMDAwMCBuDQowMDAwMjc3OTA5IDAwMDAw IG4NCjAwMDAyNzgxNzMgMDAwMDAgbg0KMDAwMDI3ODQzNyAwMDAwMCBuDQowMDAwMjc4ODE0 IDAwMDAwIG4NCjAwMDAyNzg4NTUgMDAwMDAgbg0KMDAwMDI4NDIwNiAwMDAwMCBuDQowMDAw Mjg0MjI5IDAwMDAwIG4NCjAwMDAyODQ2MTggMDAwMDAgbg0KMDAwMDI5MDE0NyAwMDAwMCBu DQowMDAwMjkwMTcwIDAwMDAwIG4NCjAwMDAyOTA1MTYgMDAwMDAgbg0KMDAwMDI5NjAxMiAw MDAwMCBuDQowMDAwMjk2MDM1IDAwMDAwIG4NCjAwMDAyOTY0MTAgMDAwMDAgbg0KMDAwMDI5 OTgwMCAwMDAwMCBuDQowMDAwMjk5ODIzIDAwMDAwIG4NCjAwMDAzMDAxNTUgMDAwMDAgbg0K MDAwMDMwMDU5NCAwMDAwMCBuDQowMDAwMzAwNjE2IDAwMDAwIG4NCjAwMDAzMDA3ODMgMDAw MDAgbg0KMDAwMDMwMDgzNCAwMDAwMCBuDQowMDAwMzAwODg1IDAwMDAwIG4NCjAwMDAzMDA5 MzYgMDAwMDAgbg0KMDAwMDMwMDk4NyAwMDAwMCBuDQowMDAwMzAxMDM4IDAwMDAwIG4NCjAw MDAzMDEwODkgMDAwMDAgbg0KMDAwMDMwMTE0MCAwMDAwMCBuDQowMDAwMzAxMTkxIDAwMDAw IG4NCjAwMDAzMDEyNDIgMDAwMDAgbg0KMDAwMDMwMTI5MyAwMDAwMCBuDQowMDAwMzAxMzQ0 IDAwMDAwIG4NCjAwMDAzMDEzOTUgMDAwMDAgbg0KMDAwMDMwMTQ0NiAwMDAwMCBuDQowMDAw MzAxNDk3IDAwMDAwIG4NCjAwMDAzMDE1NDggMDAwMDAgbg0KMDAwMDMwMTU5OSAwMDAwMCBu DQowMDAwMzAxNjUwIDAwMDAwIG4NCjAwMDAzMDE3MDEgMDAwMDAgbg0KMDAwMDMwMTc1MiAw MDAwMCBuDQowMDAwMzAxODAzIDAwMDAwIG4NCjAwMDAzMDE4NTQgMDAwMDAgbg0KMDAwMDMw MTkwNSAwMDAwMCBuDQowMDAwMzAxOTU2IDAwMDAwIG4NCjAwMDAzMDIwMDcgMDAwMDAgbg0K MDAwMDMwMjA1OCAwMDAwMCBuDQowMDAwMzAyMTA5IDAwMDAwIG4NCjAwMDAzMDIxNjEgMDAw MDAgbg0KMDAwMDMwMjIxMyAwMDAwMCBuDQowMDAwMzAyMjY1IDAwMDAwIG4NCjAwMDAzMDIz MTcgMDAwMDAgbg0KMDAwMDMwMjM2OSAwMDAwMCBuDQowMDAwMzAyNDIxIDAwMDAwIG4NCjAw MDAzMDI0NzMgMDAwMDAgbg0KMDAwMDMwMjUyNSAwMDAwMCBuDQowMDAwMzAyNTc3IDAwMDAw IG4NCjAwMDAzMDI2MjkgMDAwMDAgbg0KMDAwMDMwMjY4MSAwMDAwMCBuDQowMDAwMzAyNzMz IDAwMDAwIG4NCjAwMDAzMDI3ODUgMDAwMDAgbg0KMDAwMDMwMjgzNyAwMDAwMCBuDQowMDAw MzAyODg5IDAwMDAwIG4NCjAwMDAzMDI5NDEgMDAwMDAgbg0KMDAwMDMwMjk5MyAwMDAwMCBu DQowMDAwMzAzMDQ1IDAwMDAwIG4NCjAwMDAzMDMwOTcgMDAwMDAgbg0KMDAwMDMwMzE0OSAw MDAwMCBuDQowMDAwMzAzMjAxIDAwMDAwIG4NCjAwMDAzMDMyNTMgMDAwMDAgbg0KMDAwMDMw MzMwNSAwMDAwMCBuDQowMDAwMzAzMzU3IDAwMDAwIG4NCjAwMDAzMDM0MDkgMDAwMDAgbg0K MDAwMDMwMzQ2MSAwMDAwMCBuDQowMDAwMzAzNTEzIDAwMDAwIG4NCjAwMDAzMDM1NjUgMDAw MDAgbg0KMDAwMDMwMzYxNyAwMDAwMCBuDQowMDAwMzAzNjY5IDAwMDAwIG4NCjAwMDAzMDM3 MjEgMDAwMDAgbg0KMDAwMDMwMzc3MyAwMDAwMCBuDQowMDAwMzAzODI1IDAwMDAwIG4NCjAw MDAzMDM4NzcgMDAwMDAgbg0KMDAwMDMwMzkyOSAwMDAwMCBuDQowMDAwMzAzOTgxIDAwMDAw IG4NCjAwMDAzMDQwMzMgMDAwMDAgbg0KMDAwMDMwNDA4NSAwMDAwMCBuDQowMDAwMzA0MTM3 IDAwMDAwIG4NCjAwMDAzMDQxODkgMDAwMDAgbg0KMDAwMDMwNDI0MSAwMDAwMCBuDQowMDAw MzA0MjkzIDAwMDAwIG4NCjAwMDAzMDQzNDUgMDAwMDAgbg0KMDAwMDMwNDM5NyAwMDAwMCBu DQowMDAwMzA0NDQ5IDAwMDAwIG4NCjAwMDAzMDQ1MDEgMDAwMDAgbg0KMDAwMDMwNDU1MyAw MDAwMCBuDQowMDAwMzA0NjA1IDAwMDAwIG4NCjAwMDAzMDQ2NTcgMDAwMDAgbg0KMDAwMDMw NDcwOSAwMDAwMCBuDQowMDAwMzA0NzYxIDAwMDAwIG4NCjAwMDAzMDQ4MTMgMDAwMDAgbg0K MDAwMDMwNDg2NSAwMDAwMCBuDQowMDAwMzA0OTE3IDAwMDAwIG4NCjAwMDAzMDQ5NjkgMDAw MDAgbg0KMDAwMDMwNTAyMSAwMDAwMCBuDQowMDAwMzA1MDczIDAwMDAwIG4NCjAwMDAzMDUx MjUgMDAwMDAgbg0KMDAwMDMwNTE3NyAwMDAwMCBuDQowMDAwMzA1MjMwIDAwMDAwIG4NCjAw MDAzMDUyODMgMDAwMDAgbg0KMDAwMDMwNTMzNiAwMDAwMCBuDQowMDAwMzA1Mzg5IDAwMDAw IG4NCjAwMDAzMDU0NDIgMDAwMDAgbg0KMDAwMDMwNTQ5NSAwMDAwMCBuDQowMDAwMzA1NTQ4 IDAwMDAwIG4NCjAwMDAzMDU2MDEgMDAwMDAgbg0KMDAwMDMwNTY1NCAwMDAwMCBuDQowMDAw MzA1NzA3IDAwMDAwIG4NCjAwMDAzMDU3NjAgMDAwMDAgbg0KMDAwMDMwNTgxMyAwMDAwMCBu DQowMDAwMzA1ODY2IDAwMDAwIG4NCjAwMDAzMDU5MTkgMDAwMDAgbg0KMDAwMDMwNTk3MiAw MDAwMCBuDQowMDAwMzA2MDI1IDAwMDAwIG4NCjAwMDAzMDYwNzggMDAwMDAgbg0KMDAwMDMw NjEzMSAwMDAwMCBuDQowMDAwMzA2MTg0IDAwMDAwIG4NCjAwMDAzMDYyMzcgMDAwMDAgbg0K MDAwMDMwNjI5MCAwMDAwMCBuDQowMDAwMzA2MzQzIDAwMDAwIG4NCjAwMDAzMDYzOTYgMDAw MDAgbg0KMDAwMDMwNjQ0OSAwMDAwMCBuDQowMDAwMzA2NTAyIDAwMDAwIG4NCjAwMDAzMDY1 NTUgMDAwMDAgbg0KMDAwMDMwNjYwOCAwMDAwMCBuDQowMDAwMzA2NjYxIDAwMDAwIG4NCjAw MDAzMDY3MTQgMDAwMDAgbg0KMDAwMDMwNjc2NyAwMDAwMCBuDQowMDAwMzA2ODIwIDAwMDAw IG4NCjAwMDAzMDY4NzMgMDAwMDAgbg0KMDAwMDMwNjkyNiAwMDAwMCBuDQowMDAwMzA2OTc5 IDAwMDAwIG4NCjAwMDAzMDcwMzIgMDAwMDAgbg0KMDAwMDMwNzA4NSAwMDAwMCBuDQowMDAw MzA3MTM4IDAwMDAwIG4NCjAwMDAzMDcxOTEgMDAwMDAgbg0KMDAwMDMwNzI0NCAwMDAwMCBu DQowMDAwMzA3Mjk3IDAwMDAwIG4NCjAwMDAzMDczNTAgMDAwMDAgbg0KMDAwMDMwNzQwMyAw MDAwMCBuDQowMDAwMzA3NDU2IDAwMDAwIG4NCjAwMDAzMDc1MDkgMDAwMDAgbg0KMDAwMDMw NzU2MiAwMDAwMCBuDQowMDAwMzA3NjE1IDAwMDAwIG4NCjAwMDAzMDc2NjggMDAwMDAgbg0K MDAwMDMwNzcyMSAwMDAwMCBuDQowMDAwMzA3Nzc0IDAwMDAwIG4NCjAwMDAzMDc4MjcgMDAw MDAgbg0KMDAwMDMwNzg4MCAwMDAwMCBuDQowMDAwMzA3OTMzIDAwMDAwIG4NCjAwMDAzMDc5 ODYgMDAwMDAgbg0KMDAwMDMwODAzOSAwMDAwMCBuDQowMDAwMzA4MDkyIDAwMDAwIG4NCjAw MDAzMDgxNDUgMDAwMDAgbg0KMDAwMDMwODE5OCAwMDAwMCBuDQowMDAwMzA4MjUxIDAwMDAw IG4NCjAwMDAzMDgzMDQgMDAwMDAgbg0KMDAwMDMwODM1NyAwMDAwMCBuDQowMDAwMzA4NDEw IDAwMDAwIG4NCjAwMDAzMDg0NjMgMDAwMDAgbg0KMDAwMDMwODUxNiAwMDAwMCBuDQowMDAw MzA4NTY5IDAwMDAwIG4NCjAwMDAzMDg2MjIgMDAwMDAgbg0KMDAwMDMwODY3NSAwMDAwMCBu DQowMDAwMzA4NzI4IDAwMDAwIG4NCjAwMDAzMDg3ODEgMDAwMDAgbg0KMDAwMDMwODgzNCAw MDAwMCBuDQowMDAwMzA4ODg3IDAwMDAwIG4NCjAwMDAzMDg5MzkgMDAwMDAgbg0KMDAwMDMw ODk5MiAwMDAwMCBuDQowMDAwMzA5MDQ0IDAwMDAwIG4NCjAwMDAzMDkwOTYgMDAwMDAgbg0K MDAwMDMwOTE0OCAwMDAwMCBuDQowMDAwMzA5MjAwIDAwMDAwIG4NCjAwMDAzMDkyNTIgMDAw MDAgbg0KMDAwMDMwOTMwNCAwMDAwMCBuDQowMDAwMzA5MzU2IDAwMDAwIG4NCjAwMDAzMDk0 MDggMDAwMDAgbg0KMDAwMDMwOTQ2MCAwMDAwMCBuDQowMDAwMzA5NTEyIDAwMDAwIG4NCjAw MDAzMDk1NjQgMDAwMDAgbg0KMDAwMDMwOTYxNiAwMDAwMCBuDQowMDAwMzA5NjY4IDAwMDAw IG4NCjAwMDAzMDk3MjAgMDAwMDAgbg0KMDAwMDMwOTc3MiAwMDAwMCBuDQowMDAwMzA5ODI0 IDAwMDAwIG4NCjAwMDAzMDk4NzYgMDAwMDAgbg0KMDAwMDMwOTkyOCAwMDAwMCBuDQowMDAw MzA5OTgwIDAwMDAwIG4NCjAwMDAzMTAwMzIgMDAwMDAgbg0KMDAwMDMxMDA4NCAwMDAwMCBu DQowMDAwMzEwMTM2IDAwMDAwIG4NCjAwMDAzMTAxODggMDAwMDAgbg0KMDAwMDMxMDI0MCAw MDAwMCBuDQowMDAwMzEwMjkyIDAwMDAwIG4NCjAwMDAzMTAzNDQgMDAwMDAgbg0KMDAwMDMx MDM5NiAwMDAwMCBuDQowMDAwMzEwNDQ4IDAwMDAwIG4NCjAwMDAzMTA1MDAgMDAwMDAgbg0K MDAwMDMxMDU1MiAwMDAwMCBuDQowMDAwMzEwNjA0IDAwMDAwIG4NCjAwMDAzMTA2NTYgMDAw MDAgbg0KMDAwMDMxMDcwOCAwMDAwMCBuDQowMDAwMzEwNzYwIDAwMDAwIG4NCjAwMDAzMTA4 MTIgMDAwMDAgbg0KMDAwMDMxMDg2NCAwMDAwMCBuDQowMDAwMzEwOTE2IDAwMDAwIG4NCjAw MDAzMTA5NjggMDAwMDAgbg0KMDAwMDMxMTAyMCAwMDAwMCBuDQowMDAwMzExMDcyIDAwMDAw IG4NCjAwMDAzMTExMjQgMDAwMDAgbg0KMDAwMDMxMTE3NiAwMDAwMCBuDQowMDAwMzExMjI4 IDAwMDAwIG4NCjAwMDAzMTEyODAgMDAwMDAgbg0KMDAwMDMxMTMzMiAwMDAwMCBuDQowMDAw MzExMzg0IDAwMDAwIG4NCjAwMDAzMTE0MzYgMDAwMDAgbg0KMDAwMDMxMTQ4OCAwMDAwMCBu DQowMDAwMzExNTQwIDAwMDAwIG4NCjAwMDAzMTE1OTIgMDAwMDAgbg0KMDAwMDMxMTY0NCAw MDAwMCBuDQowMDAwMzExNjk2IDAwMDAwIG4NCjAwMDAzMTE3NDggMDAwMDAgbg0KMDAwMDMx MTgwMCAwMDAwMCBuDQowMDAwMzExODUyIDAwMDAwIG4NCjAwMDAzMTE5MDQgMDAwMDAgbg0K MDAwMDMxMTk1NiAwMDAwMCBuDQowMDAwMzEyMDA4IDAwMDAwIG4NCjAwMDAzMTIwNjAgMDAw MDAgbg0KMDAwMDMxMjExMiAwMDAwMCBuDQowMDAwMzEyMTY0IDAwMDAwIG4NCjAwMDAzMTIy MTYgMDAwMDAgbg0KMDAwMDMxMjI2OCAwMDAwMCBuDQowMDAwMzEyMzIwIDAwMDAwIG4NCjAw MDAzMTIzNzIgMDAwMDAgbg0KMDAwMDMxMjQyNCAwMDAwMCBuDQowMDAwMzEyNDc2IDAwMDAw IG4NCjAwMDAzMTI1MjggMDAwMDAgbg0KMDAwMDMxMjU4MCAwMDAwMCBuDQowMDAwMzEyNjMy IDAwMDAwIG4NCjAwMDAzMTI2ODQgMDAwMDAgbg0KMDAwMDMxMjczNiAwMDAwMCBuDQowMDAw MzEyNzg4IDAwMDAwIG4NCjAwMDAzMTI4NDAgMDAwMDAgbg0KMDAwMDMxMjg5MiAwMDAwMCBu DQowMDAwMzEyOTQ1IDAwMDAwIG4NCjAwMDAzMTI5OTggMDAwMDAgbg0KMDAwMDMxMzA1MCAw MDAwMCBuDQowMDAwMzEzMTAzIDAwMDAwIG4NCjAwMDAzMTMxNTYgMDAwMDAgbg0KMDAwMDMx MzIwOSAwMDAwMCBuDQowMDAwMzEzMjYyIDAwMDAwIG4NCjAwMDAzMTMzMTUgMDAwMDAgbg0K MDAwMDMxMzM2OCAwMDAwMCBuDQowMDAwMzEzNDIxIDAwMDAwIG4NCjAwMDAzMTM0NzQgMDAw MDAgbg0KMDAwMDMxMzUyNyAwMDAwMCBuDQowMDAwMzEzNTgwIDAwMDAwIG4NCjAwMDAzMTM2 MzMgMDAwMDAgbg0KMDAwMDMxMzY4NiAwMDAwMCBuDQowMDAwMzEzNzM5IDAwMDAwIG4NCjAw MDAzMTM3OTIgMDAwMDAgbg0KMDAwMDMxMzg0NSAwMDAwMCBuDQowMDAwMzEzODk4IDAwMDAw IG4NCjAwMDAzMTM5NTEgMDAwMDAgbg0KMDAwMDMxNDAwNCAwMDAwMCBuDQowMDAwMzE0MDU3 IDAwMDAwIG4NCjAwMDAzMTQxMTAgMDAwMDAgbg0KMDAwMDMxNDE2MyAwMDAwMCBuDQowMDAw MzE0MjE2IDAwMDAwIG4NCjAwMDAzMTQyNjkgMDAwMDAgbg0KMDAwMDMxNDMyMiAwMDAwMCBu DQowMDAwMzE0Mzc1IDAwMDAwIG4NCjAwMDAzMTQ0MjggMDAwMDAgbg0KMDAwMDMxNDQ4MSAw MDAwMCBuDQowMDAwMzE0NTM0IDAwMDAwIG4NCjAwMDAzMTQ1ODcgMDAwMDAgbg0KMDAwMDMx NDY0MCAwMDAwMCBuDQowMDAwMzE0NjkzIDAwMDAwIG4NCjAwMDAzMTQ3NDYgMDAwMDAgbg0K MDAwMDMxNDc5OSAwMDAwMCBuDQowMDAwMzE0ODUyIDAwMDAwIG4NCjAwMDAzMTQ5MDUgMDAw MDAgbg0KMDAwMDMxNDk1OCAwMDAwMCBuDQowMDAwMzE1MDExIDAwMDAwIG4NCjAwMDAzMTUw NjQgMDAwMDAgbg0KMDAwMDMxNTExNyAwMDAwMCBuDQowMDAwMzE1MTcwIDAwMDAwIG4NCjAw MDAzMTUyMjMgMDAwMDAgbg0KMDAwMDMxNTI3NiAwMDAwMCBuDQowMDAwMzE1MzI5IDAwMDAw IG4NCjAwMDAzMTUzODIgMDAwMDAgbg0KMDAwMDMxNTQzNSAwMDAwMCBuDQowMDAwMzE1NDg4 IDAwMDAwIG4NCjAwMDAzMTU1NDEgMDAwMDAgbg0KMDAwMDMxNTU5NCAwMDAwMCBuDQowMDAw MzE1NjQ3IDAwMDAwIG4NCjAwMDAzMTU3MDAgMDAwMDAgbg0KMDAwMDMxNTc1MyAwMDAwMCBu DQowMDAwMzE1ODA2IDAwMDAwIG4NCjAwMDAzMTU4NTkgMDAwMDAgbg0KMDAwMDMxNTkxMiAw MDAwMCBuDQowMDAwMzE1OTY1IDAwMDAwIG4NCjAwMDAzMTYwMTggMDAwMDAgbg0KMDAwMDMx NjA3MSAwMDAwMCBuDQowMDAwMzE2MTI0IDAwMDAwIG4NCjAwMDAzMTYxNzcgMDAwMDAgbg0K MDAwMDMxNjIzMCAwMDAwMCBuDQowMDAwMzE2MjgzIDAwMDAwIG4NCjAwMDAzMTYzMzYgMDAw MDAgbg0KMDAwMDMxNjM4OSAwMDAwMCBuDQowMDAwMzE2NDQyIDAwMDAwIG4NCjAwMDAzMTY0 OTUgMDAwMDAgbg0KMDAwMDMxNjU0OCAwMDAwMCBuDQowMDAwMzE2NjAxIDAwMDAwIG4NCjAw MDAzMTY2NTQgMDAwMDAgbg0KMDAwMDMxNjcwNyAwMDAwMCBuDQowMDAwMzE2NzYwIDAwMDAw IG4NCjAwMDAzMTY4MTMgMDAwMDAgbg0KMDAwMDMxNjg2NiAwMDAwMCBuDQowMDAwMzE2OTE5 IDAwMDAwIG4NCjAwMDAzMTY5NzIgMDAwMDAgbg0KMDAwMDMxNzAyNSAwMDAwMCBuDQowMDAw MzE3MDc4IDAwMDAwIG4NCjAwMDAzMTcxMzEgMDAwMDAgbg0KMDAwMDMxNzE4NCAwMDAwMCBu DQowMDAwMzE3MjM3IDAwMDAwIG4NCjAwMDAzMTcyOTAgMDAwMDAgbg0KMDAwMDMxNzM0MyAw MDAwMCBuDQowMDAwMzE3Mzk2IDAwMDAwIG4NCjAwMDAzMTc0NDkgMDAwMDAgbg0KMDAwMDMx NzUwMiAwMDAwMCBuDQowMDAwMzE3NTU1IDAwMDAwIG4NCjAwMDAzMTc2MDggMDAwMDAgbg0K MDAwMDMxNzY2MSAwMDAwMCBuDQowMDAwMzE3NzE0IDAwMDAwIG4NCjAwMDAzMTc3NjcgMDAw MDAgbg0KMDAwMDMxNzgyMCAwMDAwMCBuDQowMDAwMzE3ODczIDAwMDAwIG4NCjAwMDAzMTc5 MjYgMDAwMDAgbg0KMDAwMDMxNzk3OSAwMDAwMCBuDQowMDAwMzE4MDMyIDAwMDAwIG4NCjAw MDAzMTgwODUgMDAwMDAgbg0KMDAwMDMxODEzOCAwMDAwMCBuDQowMDAwMzE4MTkxIDAwMDAw IG4NCjAwMDAzMTgyNDQgMDAwMDAgbg0KMDAwMDMxODI5NyAwMDAwMCBuDQowMDAwMzE4MzUw IDAwMDAwIG4NCjAwMDAzMTg0MDMgMDAwMDAgbg0KMDAwMDMxODQ1NiAwMDAwMCBuDQowMDAw MzE4NTA5IDAwMDAwIG4NCjAwMDAzMTg1NjIgMDAwMDAgbg0KMDAwMDMxODYxNSAwMDAwMCBu DQowMDAwMzE4NjY4IDAwMDAwIG4NCjAwMDAzMTg3MjEgMDAwMDAgbg0KMDAwMDMxODc3NCAw MDAwMCBuDQowMDAwMzE4ODI3IDAwMDAwIG4NCjAwMDAzMTg4ODAgMDAwMDAgbg0KMDAwMDMx ODkzMyAwMDAwMCBuDQowMDAwMzE4OTg2IDAwMDAwIG4NCjAwMDAzMTkwMzkgMDAwMDAgbg0K MDAwMDMxOTA5MiAwMDAwMCBuDQowMDAwMzE5MTQ1IDAwMDAwIG4NCjAwMDAzMTkxOTggMDAw MDAgbg0KMDAwMDMxOTI1MSAwMDAwMCBuDQowMDAwMzE5MzA0IDAwMDAwIG4NCjAwMDAzMTkz NTcgMDAwMDAgbg0KMDAwMDMxOTQxMCAwMDAwMCBuDQowMDAwMzE5NDYzIDAwMDAwIG4NCjAw MDAzMTk1MTYgMDAwMDAgbg0KMDAwMDMxOTU2OCAwMDAwMCBuDQowMDAwMzE5NjIxIDAwMDAw IG4NCjAwMDAzMTk2NzMgMDAwMDAgbg0KMDAwMDMxOTcyNSAwMDAwMCBuDQowMDAwMzE5Nzc3 IDAwMDAwIG4NCjAwMDAzMTk4MjkgMDAwMDAgbg0KMDAwMDMxOTg4MSAwMDAwMCBuDQowMDAw MzE5OTMzIDAwMDAwIG4NCjAwMDAzMTk5ODUgMDAwMDAgbg0KMDAwMDMyMDAzNyAwMDAwMCBu DQowMDAwMzIwMDg5IDAwMDAwIG4NCjAwMDAzMjAxNDEgMDAwMDAgbg0KMDAwMDMyMDE5MyAw MDAwMCBuDQowMDAwMzIwMjQ1IDAwMDAwIG4NCjAwMDAzMjAyOTcgMDAwMDAgbg0KMDAwMDMy MDM0OSAwMDAwMCBuDQowMDAwMzIwNDAxIDAwMDAwIG4NCjAwMDAzMjA0NTMgMDAwMDAgbg0K MDAwMDMyMDUwNSAwMDAwMCBuDQowMDAwMzIwNTU3IDAwMDAwIG4NCjAwMDAzMjA2MDkgMDAw MDAgbg0KMDAwMDMyMDY2MSAwMDAwMCBuDQowMDAwMzIwNzEzIDAwMDAwIG4NCjAwMDAzMjA3 NjUgMDAwMDAgbg0KMDAwMDMyMDgxNyAwMDAwMCBuDQowMDAwMzIwODY5IDAwMDAwIG4NCjAw MDAzMjA5MjEgMDAwMDAgbg0KMDAwMDMyMDk3MyAwMDAwMCBuDQowMDAwMzIxMDI1IDAwMDAw IG4NCjAwMDAzMjEwNzcgMDAwMDAgbg0KMDAwMDMyMTEyOSAwMDAwMCBuDQowMDAwMzIxMTgx IDAwMDAwIG4NCjAwMDAzMjEyMzMgMDAwMDAgbg0KMDAwMDMyMTI4NSAwMDAwMCBuDQowMDAw MzIxMzM3IDAwMDAwIG4NCjAwMDAzMjEzODkgMDAwMDAgbg0KMDAwMDMyMTQ0MSAwMDAwMCBu DQowMDAwMzIxNDkzIDAwMDAwIG4NCjAwMDAzMjE1NDUgMDAwMDAgbg0KMDAwMDMyMTU5NyAw MDAwMCBuDQowMDAwMzIxNjQ5IDAwMDAwIG4NCjAwMDAzMjE3MDEgMDAwMDAgbg0KMDAwMDMy MTc1MyAwMDAwMCBuDQowMDAwMzIxODA1IDAwMDAwIG4NCjAwMDAzMjE4NTcgMDAwMDAgbg0K MDAwMDMyMTkwOSAwMDAwMCBuDQowMDAwMzIxOTYxIDAwMDAwIG4NCjAwMDAzMjIwMTMgMDAw MDAgbg0KMDAwMDMyMjA2NSAwMDAwMCBuDQowMDAwMzIyMTE3IDAwMDAwIG4NCjAwMDAzMjIx NjkgMDAwMDAgbg0KMDAwMDMyMjIyMSAwMDAwMCBuDQowMDAwMzIyMjczIDAwMDAwIG4NCjAw MDAzMjIzMjUgMDAwMDAgbg0KMDAwMDMyMjM3OCAwMDAwMCBuDQowMDAwMzIyNDMxIDAwMDAw IG4NCjAwMDAzMjI0ODQgMDAwMDAgbg0KMDAwMDMyMjUzNyAwMDAwMCBuDQowMDAwMzIyNTkw IDAwMDAwIG4NCjAwMDAzMjI2NDMgMDAwMDAgbg0KMDAwMDMyMjY5NiAwMDAwMCBuDQowMDAw MzIyNzQ5IDAwMDAwIG4NCjAwMDAzMjI4MDIgMDAwMDAgbg0KMDAwMDMyMjg1NSAwMDAwMCBu DQowMDAwMzIyOTA4IDAwMDAwIG4NCjAwMDAzMjI5NjEgMDAwMDAgbg0KMDAwMDMyMzAxNCAw MDAwMCBuDQowMDAwMzIzMDY3IDAwMDAwIG4NCjAwMDAzMjMxMjAgMDAwMDAgbg0KMDAwMDMy MzE3MyAwMDAwMCBuDQowMDAwMzIzMjI2IDAwMDAwIG4NCjAwMDAzMjMyNzkgMDAwMDAgbg0K MDAwMDMyMzM0OCAwMDAwMCBuDQowMDAwMzIzNDE3IDAwMDAwIG4NCjAwMDAzMjM0ODMgMDAw MDAgbg0KMDAwMDMyMzU0NiAwMDAwMCBuDQowMDAwMzIzNjEyIDAwMDAwIG4NCjAwMDAzMjM2 NzUgMDAwMDAgbg0KMDAwMDMyMzc1MCAwMDAwMCBuDQowMDAwMzIzODEzIDAwMDAwIG4NCjAw MDAzMjM4ODIgMDAwMDAgbg0KMDAwMDMyMzk0OCAwMDAwMCBuDQowMDAwMzI0MDIwIDAwMDAw IG4NCjAwMDAzMjQwNzkgMDAwMDAgbg0KMDAwMDMyNDE1NCAwMDAwMCBuDQowMDAwMzI0MjE3 IDAwMDAwIG4NCjAwMDAzMjQyODkgMDAwMDAgbg0KMDAwMDMyNDM1MiAwMDAwMCBuDQowMDAw MzI0NDI3IDAwMDAwIG4NCjAwMDAzMjQ0OTMgMDAwMDAgbg0KMDAwMDMyNDU2OCAwMDAwMCBu DQowMDAwMzI0NjMxIDAwMDAwIG4NCjAwMDAzMjQ3MDkgMDAwMDAgbg0KMDAwMDMyNDc3NSAw MDAwMCBuDQowMDAwMzI0ODU2IDAwMDAwIG4NCjAwMDAzMjQ5NDAgMDAwMDAgbg0KMDAwMDMy NTAyNCAwMDAwMCBuDQowMDAwMzI1MTA4IDAwMDAwIG4NCjAwMDAzMjUxOTUgMDAwMDAgbg0K MDAwMDMyNTI4MiAwMDAwMCBuDQowMDAwMzI1Mzc1IDAwMDAwIG4NCjAwMDAzMjU0NjIgMDAw MDAgbg0KMDAwMDMyNTU1OCAwMDAwMCBuDQowMDAwMzI1NjUxIDAwMDAwIG4NCjAwMDAzMjU3 NDEgMDAwMDAgbg0KMDAwMDMyNTgzNCAwMDAwMCBuDQowMDAwMzI1OTMzIDAwMDAwIG4NCjAw MDAzMjYwMjkgMDAwMDAgbg0KMDAwMDMyNjEzMSAwMDAwMCBuDQowMDAwMzI2MjMzIDAwMDAw IG4NCjAwMDAzMjYzMzUgMDAwMDAgbg0KMDAwMDMyNjQ0MyAwMDAwMCBuDQowMDAwMzI2NTUx IDAwMDAwIG4NCjAwMDAzMjY2NjIgMDAwMDAgbg0KMDAwMDMyNjc3MyAwMDAwMCBuDQowMDAw MzI2ODg3IDAwMDAwIG4NCjAwMDAzMjcwMDEgMDAwMDAgbg0KMDAwMDMyNzExNSAwMDAwMCBu DQowMDAwMzI3MjM1IDAwMDAwIG4NCjAwMDAzMjczNTggMDAwMDAgbg0KMDAwMDMyNzQ4NCAw MDAwMCBuDQowMDAwMzI3NjEzIDAwMDAwIG4NCjAwMDAzMjc3MzkgMDAwMDAgbg0KMDAwMDMy Nzg2NSAwMDAwMCBuDQowMDAwMzI3OTkxIDAwMDAwIG4NCjAwMDAzMjgxMjAgMDAwMDAgbg0K MDAwMDMyODI0NiAwMDAwMCBuDQowMDAwMzI4Mzc1IDAwMDAwIG4NCjAwMDAzMjg1MDcgMDAw MDAgbg0KMDAwMDMyODY2MCAwMDAwMCBuDQowMDAwMzI4ODEzIDAwMDAwIG4NCjAwMDAzMjg5 NjggMDAwMDAgbg0KMDAwMDMyOTEyMCAwMDAwMCBuDQowMDAwMzI5Mjc1IDAwMDAwIG4NCjAw MDAzMjk0MzQgMDAwMDAgbg0KMDAwMDMyOTU5MyAwMDAwMCBuDQowMDAwMzI5NzU0IDAwMDAw IG4NCjAwMDAzMjk5MTcgMDAwMDAgbg0KMDAwMDMzMDA4NCAwMDAwMCBuDQowMDAwMzMwMjQy IDAwMDAwIG4NCjAwMDAzMzA0MDQgMDAwMDAgbg0KMDAwMDMzMDU3MCAwMDAwMCBuDQowMDAw MzMwNzM4IDAwMDAwIG4NCjAwMDAzMzA5MDkgMDAwMDAgbg0KMDAwMDMzMTA4NyAwMDAwMCBu DQowMDAwMzMxMjU0IDAwMDAwIG4NCjAwMDAzMzE0MjIgMDAwMDAgbg0KMDAwMDMzMTYwMyAw MDAwMCBuDQowMDAwMzMxNzgzIDAwMDAwIG4NCjAwMDAzMzE5NzEgMDAwMDAgbg0KMDAwMDMz MjE0OCAwMDAwMCBuDQowMDAwMzMyMzMzIDAwMDAwIG4NCjAwMDAzMzI1MjIgMDAwMDAgbg0K MDAwMDMzMjcxNCAwMDAwMCBuDQowMDAwMzMyOTA1IDAwMDAwIG4NCjAwMDAzMzMwOTEgMDAw MDAgbg0KMDAwMDMzMzI5NCAwMDAwMCBuDQowMDAwMzMzNDgyIDAwMDAwIG4NCjAwMDAzMzM2 ODEgMDAwMDAgbg0KMDAwMDMzMzg4MiAwMDAwMCBuDQowMDAwMzM0MDgyIDAwMDAwIG4NCjAw MDAzMzQyNzkgMDAwMDAgbg0KMDAwMDMzNDQ5MCAwMDAwMCBuDQowMDAwMzM0Njk2IDAwMDAw IG4NCjAwMDAzMzQ5MDQgMDAwMDAgbg0KMDAwMDMzNTEwMyAwMDAwMCBuDQowMDAwMzM1MzE0 IDAwMDAwIG4NCjAwMDAzMzU1MTMgMDAwMDAgbg0KMDAwMDMzNTcyMiAwMDAwMCBuDQowMDAw MzM1OTIyIDAwMDAwIG4NCjAwMDAzMzYxMjEgMDAwMDAgbg0KMDAwMDMzNjMyNyAwMDAwMCBu DQowMDAwMzM2NTIwIDAwMDAwIG4NCjAwMDAzMzY3MTcgMDAwMDAgbg0KMDAwMDMzNjkxNiAw MDAwMCBuDQowMDAwMzM3MTExIDAwMDAwIG4NCjAwMDAzMzcyOTggMDAwMDAgbg0KMDAwMDMz NzQ5NCAwMDAwMCBuDQowMDAwMzM3Njg2IDAwMDAwIG4NCjAwMDAzMzc4NzMgMDAwMDAgbg0K MDAwMDMzODA2MyAwMDAwMCBuDQowMDAwMzM4MjQyIDAwMDAwIG4NCjAwMDAzMzg0MTggMDAw MDAgbg0KMDAwMDMzODU5OCAwMDAwMCBuDQowMDAwMzM4Nzc1IDAwMDAwIG4NCjAwMDAzMzg5 NDUgMDAwMDAgbg0KMDAwMDMzOTExNSAwMDAwMCBuDQowMDAwMzM5MjgyIDAwMDAwIG4NCjAw MDAzMzk0NTUgMDAwMDAgbg0KMDAwMDMzOTYyNiAwMDAwMCBuDQowMDAwMzM5NzkyIDAwMDAw IG4NCjAwMDAzMzk5NDkgMDAwMDAgbg0KMDAwMDM0MDEwNyAwMDAwMCBuDQowMDAwMzQwMjcw IDAwMDAwIG4NCjAwMDAzNDA0MzQgMDAwMDAgbg0KMDAwMDM0MDU5NyAwMDAwMCBuDQowMDAw MzQwNzUxIDAwMDAwIG4NCjAwMDAzNDA5MDQgMDAwMDAgbg0KMDAwMDM0MTA1OCAwMDAwMCBu DQowMDAwMzQxMTkxIDAwMDAwIG4NCjAwMDAzNDEzMjEgMDAwMDAgbg0KMDAwMDM0MTQ1MSAw MDAwMCBuDQowMDAwMzQxNTc1IDAwMDAwIG4NCjAwMDAzNDE3MDIgMDAwMDAgbg0KMDAwMDM0 MTgyOSAwMDAwMCBuDQowMDAwMzQxOTUzIDAwMDAwIG4NCjAwMDAzNDIwNzQgMDAwMDAgbg0K MDAwMDM0MjE5OCAwMDAwMCBuDQowMDAwMzQyMzE5IDAwMDAwIG4NCjAwMDAzNDI0MzcgMDAw MDAgbg0KMDAwMDM0MjU0NiAwMDAwMCBuDQowMDAwMzQyNjU1IDAwMDAwIG4NCjAwMDAzNDI3 NzAgMDAwMDAgbg0KMDAwMDM0Mjg3OSAwMDAwMCBuDQowMDAwMzQyOTg1IDAwMDAwIG4NCjAw MDAzNDMwODggMDAwMDAgbg0KMDAwMDM0MzE5NCAwMDAwMCBuDQowMDAwMzQzMjk3IDAwMDAw IG4NCjAwMDAzNDMzOTQgMDAwMDAgbg0KMDAwMDM0MzQ5MSAwMDAwMCBuDQowMDAwMzQzNTg1 IDAwMDAwIG4NCjAwMDAzNDM2NzkgMDAwMDAgbg0KMDAwMDM0Mzc3NiAwMDAwMCBuDQowMDAw MzQzODcwIDAwMDAwIG4NCjAwMDAzNDM5NjEgMDAwMDAgbg0KMDAwMDM0NDA1MiAwMDAwMCBu DQowMDAwMzQ0MTQzIDAwMDAwIG4NCjAwMDAzNDQyMjggMDAwMDAgbg0KMDAwMDM0NDMxOSAw MDAwMCBuDQowMDAwMzQ0NDAxIDAwMDAwIG4NCjAwMDAzNDQ0ODMgMDAwMDAgbg0KMDAwMDM0 NDU2MiAwMDAwMCBuDQowMDAwMzQ0NjQ0IDAwMDAwIG4NCjAwMDAzNDQ3MjMgMDAwMDAgbg0K MDAwMDM0NDgwNSAwMDAwMCBuDQowMDAwMzQ0ODcyIDAwMDAwIG4NCjAwMDAzNDQ5NTEgMDAw MDAgbg0KMDAwMDM0NTAxNSAwMDAwMCBuDQowMDAwMzQ1MDk0IDAwMDAwIG4NCjAwMDAzNDUx NTggMDAwMDAgbg0KMDAwMDM0NTIzNCAwMDAwMCBuDQowMDAwMzQ1MzA0IDAwMDAwIG4NCjAw MDAzNDUzNjggMDAwMDAgbg0KMDAwMDM0NTQzOCAwMDAwMCBuDQowMDAwMzQ1NDk4IDAwMDAw IG4NCjAwMDAzNDU1NjggMDAwMDAgbg0KMDAwMDM0NTYzNSAwMDAwMCBuDQowMDAwMzQ1NzAy IDAwMDAwIG4NCjAwMDAzNDU3NjYgMDAwMDAgbg0KMDAwMDM0NTgzNiAwMDAwMCBuDQowMDAw MzQ1OTAwIDAwMDAwIG4NCjAwMDAzNDU5NjcgMDAwMDAgbg0KMDAwMDM0NjAzMSAwMDAwMCBu DQowMDAwMzQ2MDk4IDAwMDAwIG4NCjAwMDAzNDYxNjUgMDAwMDAgbg0KMDAwMDM0NjIzNSAw MDAwMCBuDQowMDAwMzQ2MzAyIDAwMDAwIG4NCjAwMDAzNDYzNjkgMDAwMDAgbg0KMDAwMDM0 NjQzNiAwMDAwMCBuDQowMDAwMzQ2NTAwIDAwMDAwIG4NCjAwMDAzNDY1NjQgMDAwMDAgbg0K MDAwMDM0NjYyOCAwMDAwMCBuDQowMDAwMzQ2Njk1IDAwMDAwIG4NCjAwMDAzNDY3NTkgMDAw MDAgbg0KMDAwMDM0NjgyNiAwMDAwMCBuDQowMDAwMzQ2ODkzIDAwMDAwIG4NCjAwMDAzNDY5 NjAgMDAwMDAgbg0KMDAwMDM0NzAyNCAwMDAwMCBuDQowMDAwMzQ3MDg4IDAwMDAwIG4NCjAw MDAzNDcxNTIgMDAwMDAgbg0KMDAwMDM0NzIxNiAwMDAwMCBuDQowMDAwMzQ3Mjc2IDAwMDAw IG4NCjAwMDAzNDczNDMgMDAwMDAgbg0KMDAwMDM0NzQwMyAwMDAwMCBuDQowMDAwMzQ3NDcw IDAwMDAwIG4NCjAwMDAzNDc1NDAgMDAwMDAgbg0KMDAwMDM0NzYwNCAwMDAwMCBuDQowMDAw MzQ3NjcxIDAwMDAwIG4NCjAwMDAzNDc3NDEgMDAwMDAgbg0KMDAwMDM0NzgwNSAwMDAwMCBu DQowMDAwMzQ3ODcyIDAwMDAwIG4NCjAwMDAzNDc5NDIgMDAwMDAgbg0KMDAwMDM0ODAwNiAw MDAwMCBuDQowMDAwMzQ4MDczIDAwMDAwIG4NCjAwMDAzNDgxNDYgMDAwMDAgbg0KMDAwMDM0 ODIwNiAwMDAwMCBuDQowMDAwMzQ4Mjc5IDAwMDAwIG4NCjAwMDAzNDgzNTUgMDAwMDAgbg0K MDAwMDM0ODQxOSAwMDAwMCBuDQowMDAwMzQ4NDkyIDAwMDAwIG4NCjAwMDAzNDg1NzQgMDAw MDAgbg0KMDAwMDM0ODYzNCAwMDAwMCBuDQowMDAwMzQ4NzEwIDAwMDAwIG4NCjAwMDAzNDg3 ODkgMDAwMDAgbg0KMDAwMDM0ODg1MyAwMDAwMCBuDQowMDAwMzQ4OTMyIDAwMDAwIG4NCjAw MDAzNDkwMTEgMDAwMDAgbg0KMDAwMDM0OTA3NSAwMDAwMCBuDQowMDAwMzQ5MTU0IDAwMDAw IG4NCjAwMDAzNDkyMzMgMDAwMDAgbg0KMDAwMDM0OTI5NyAwMDAwMCBuDQowMDAwMzQ5Mzcz IDAwMDAwIG4NCjAwMDAzNDk0NTIgMDAwMDAgbg0KMDAwMDM0OTUxMiAwMDAwMCBuDQowMDAw MzQ5NjAwIDAwMDAwIG4NCjAwMDAzNDk2ODggMDAwMDAgbg0KMDAwMDM0OTc3MyAwMDAwMCBu DQowMDAwMzQ5ODY0IDAwMDAwIG4NCjAwMDAzNDk5NTIgMDAwMDAgbg0KMDAwMDM1MDA0MCAw MDAwMCBuDQowMDAwMzUwMTM0IDAwMDAwIG4NCjAwMDAzNTAyMzEgMDAwMDAgbg0KMDAwMDM1 MDMyNSAwMDAwMCBuDQowMDAwMzUwNDIyIDAwMDAwIG4NCjAwMDAzNTA1MTkgMDAwMDAgbg0K MDAwMDM1MDYxNiAwMDAwMCBuDQowMDAwMzUwNzE5IDAwMDAwIG4NCjAwMDAzNTA4MjIgMDAw MDAgbg0KMDAwMDM1MDkyNSAwMDAwMCBuDQowMDAwMzUxMDMxIDAwMDAwIG4NCjAwMDAzNTEx NDAgMDAwMDAgbg0KMDAwMDM1MTI1MiAwMDAwMCBuDQowMDAwMzUxMzY0IDAwMDAwIG4NCjAw MDAzNTE0NzYgMDAwMDAgbg0KMDAwMDM1MTU4OCAwMDAwMCBuDQowMDAwMzUxNzAwIDAwMDAw IG4NCjAwMDAzNTE4MTggMDAwMDAgbg0KMDAwMDM1MTkzOSAwMDAwMCBuDQowMDAwMzUyMDYw IDAwMDAwIG4NCjAwMDAzNTIxNzUgMDAwMDAgbg0KMDAwMDM1MjI5NiAwMDAwMCBuDQowMDAw MzUyNDIwIDAwMDAwIG4NCjAwMDAzNTI1NDQgMDAwMDAgbg0KMDAwMDM1MjY3MSAwMDAwMCBu DQowMDAwMzUyNzk1IDAwMDAwIG4NCjAwMDAzNTI5MjUgMDAwMDAgbg0KMDAwMDM1MzA1OCAw MDAwMCBuDQowMDAwMzUzMTg4IDAwMDAwIG4NCjAwMDAzNTMzMTggMDAwMDAgbg0KMDAwMDM1 MzQ3MSAwMDAwMCBuDQowMDAwMzUzNjI1IDAwMDAwIG4NCjAwMDAzNTM3NzggMDAwMDAgbg0K MDAwMDM1MzkzNiAwMDAwMCBuDQowMDAwMzU0MDk3IDAwMDAwIG4NCjAwMDAzNTQyNTggMDAw MDAgbg0KMDAwMDM1NDQxNSAwMDAwMCBuDQowMDAwMzU0NTc0IDAwMDAwIG4NCjAwMDAzNTQ3 MzAgMDAwMDAgbg0KMDAwMDM1NDg4OCAwMDAwMCBuDQowMDAwMzU1MDUzIDAwMDAwIG4NCjAw MDAzNTUyMjMgMDAwMDAgbg0KMDAwMDM1NTM4NCAwMDAwMCBuDQowMDAwMzU1NTU2IDAwMDAw IG4NCjAwMDAzNTU3MjEgMDAwMDAgbg0KMDAwMDM1NTg4OCAwMDAwMCBuDQowMDAwMzU2MDcw IDAwMDAwIG4NCjAwMDAzNTYyNDQgMDAwMDAgbg0KMDAwMDM1NjQzMSAwMDAwMCBuDQowMDAw MzU2NjIxIDAwMDAwIG4NCjAwMDAzNTY3OTggMDAwMDAgbg0KMDAwMDM1Njk4OSAwMDAwMCBu DQowMDAwMzU3MTgxIDAwMDAwIG4NCjAwMDAzNTczNTkgMDAwMDAgbg0KMDAwMDM1NzU1MiAw MDAwMCBuDQowMDAwMzU3NzQ4IDAwMDAwIG4NCjAwMDAzNTc5NDYgMDAwMDAgbg0KMDAwMDM1 ODEzNyAwMDAwMCBuDQowMDAwMzU4MzIyIDAwMDAwIG4NCjAwMDAzNTg1MjIgMDAwMDAgbg0K MDAwMDM1ODcxNyAwMDAwMCBuDQowMDAwMzU4OTE1IDAwMDAwIG4NCjAwMDAzNTkxMDcgMDAw MDAgbg0KMDAwMDM1OTI5MiAwMDAwMCBuDQowMDAwMzU5NDkzIDAwMDAwIG4NCjAwMDAzNTk2 ODcgMDAwMDAgbg0KMDAwMDM1OTg4MSAwMDAwMCBuDQowMDAwMzYwMDYwIDAwMDAwIG4NCjAw MDAzNjAyNTAgMDAwMDAgbg0KMDAwMDM2MDQzMiAwMDAwMCBuDQowMDAwMzYwNjE0IDAwMDAw IG4NCjAwMDAzNjA3OTcgMDAwMDAgbg0KMDAwMDM2MDk4NSAwMDAwMCBuDQowMDAwMzYxMTU0 IDAwMDAwIG4NCjAwMDAzNjEzMzcgMDAwMDAgbg0KMDAwMDM2MTUxOSAwMDAwMCBuDQowMDAw MzYxNjg4IDAwMDAwIG4NCjAwMDAzNjE4NjggMDAwMDAgbg0KMDAwMDM2MjA0MCAwMDAwMCBu DQowMDAwMzYyMjAxIDAwMDAwIG4NCjAwMDAzNjIzNjMgMDAwMDAgbg0KMDAwMDM2MjUzMiAw MDAwMCBuDQowMDAwMzYyNjk3IDAwMDAwIG4NCjAwMDAzNjI4NTggMDAwMDAgbg0KMDAwMDM2 MzAxNyAwMDAwMCBuDQowMDAwMzYzMTUwIDAwMDAwIG4NCjAwMDAzNjMzMTQgMDAwMDAgbg0K MDAwMDM2MzQ3NCAwMDAwMCBuDQowMDAwMzYzNjMyIDAwMDAwIG4NCjAwMDAzNjM3NTkgMDAw MDAgbg0KMDAwMDM2Mzg5MiAwMDAwMCBuDQowMDAwMzY0MDIyIDAwMDAwIG4NCjAwMDAzNjQx NTIgMDAwMDAgbg0KMDAwMDM2NDI3MyAwMDAwMCBuDQowMDAwMzY0Mzk3IDAwMDAwIG4NCjAw MDAzNjQ1MjEgMDAwMDAgbg0KMDAwMDM2NDY0OCAwMDAwMCBuDQowMDAwMzY0NzcyIDAwMDAw IG4NCjAwMDAzNjQ4ODcgMDAwMDAgbg0KMDAwMDM2NTAwNSAwMDAwMCBuDQowMDAwMzY1MTIz IDAwMDAwIG4NCjAwMDAzNjUyMzggMDAwMDAgbg0KMDAwMDM2NTM1MCAwMDAwMCBuDQowMDAw MzY1NDY1IDAwMDAwIG4NCjAwMDAzNjU1ODAgMDAwMDAgbg0KMDAwMDM2NTY4OSAwMDAwMCBu DQowMDAwMzY1Nzk4IDAwMDAwIG4NCjAwMDAzNjU5MDQgMDAwMDAgbg0KMDAwMDM2NjAxMyAw MDAwMCBuDQowMDAwMzY2MTE5IDAwMDAwIG4NCjAwMDAzNjYyMjIgMDAwMDAgbg0KMDAwMDM2 NjMyMiAwMDAwMCBuDQowMDAwMzY2NDE5IDAwMDAwIG4NCjAwMDAzNjY1MTkgMDAwMDAgbg0K MDAwMDM2NjYxNiAwMDAwMCBuDQowMDAwMzY2NzA3IDAwMDAwIG4NCjAwMDAzNjY3OTggMDAw MDAgbg0KMDAwMDM2Njg5NSAwMDAwMCBuDQowMDAwMzY2OTgzIDAwMDAwIG4NCjAwMDAzNjcw NzQgMDAwMDAgbg0KMDAwMDM2NzE1OSAwMDAwMCBuDQowMDAwMzY3MjQ3IDAwMDAwIG4NCjAw MDAzNjczMzIgMDAwMDAgbg0KMDAwMDM2NzQxNCAwMDAwMCBuDQowMDAwMzY3NDkzIDAwMDAw IG4NCjAwMDAzNjc1NzIgMDAwMDAgbg0KMDAwMDM2NzY1NyAwMDAwMCBuDQowMDAwMzY3NzE3 IDAwMDAwIG4NCjAwMDAzNjc3OTMgMDAwMDAgbg0KMDAwMDM2Nzg2NiAwMDAwMCBuDQowMDAw MzY3OTI2IDAwMDAwIG4NCjAwMDAzNjgwMDUgMDAwMDAgbg0KMDAwMDM2ODA3NSAwMDAwMCBu DQowMDAwMzY4MTM5IDAwMDAwIG4NCjAwMDAzNjgyMTUgMDAwMDAgbg0KMDAwMDM2ODI4NSAw MDAwMCBuDQowMDAwMzY4MzQ1IDAwMDAwIG4NCjAwMDAzNjg0MjEgMDAwMDAgbg0KMDAwMDM2 ODQ4OCAwMDAwMCBuDQowMDAwMzY4NTY0IDAwMDAwIG4NCjAwMDAzNjg2MjQgMDAwMDAgbg0K MDAwMDM2ODY4NCAwMDAwMCBuDQowMDAwMzY4NzU0IDAwMDAwIG4NCjAwMDAzNjg4MTggMDAw MDAgbg0KMDAwMDM2ODg3OCAwMDAwMCBuDQowMDAwMzY4OTQ1IDAwMDAwIG4NCjAwMDAzNjkw MDUgMDAwMDAgbg0KMDAwMDM2OTA2OSAwMDAwMCBuDQowMDAwMzY5MTMzIDAwMDAwIG4NCjAw MDAzNjkxOTcgMDAwMDAgbg0KMDAwMDM2OTI2MSAwMDAwMCBuDQowMDAwMzY5MzI4IDAwMDAw IG4NCjAwMDAzNjkzOTIgMDAwMDAgbg0KMDAwMDM2OTQ1NiAwMDAwMCBuDQowMDAwMzY5NTIw IDAwMDAwIG4NCjAwMDAzNjk1ODcgMDAwMDAgbg0KMDAwMDM2OTY0NyAwMDAwMCBuDQowMDAw MzY5NzA3IDAwMDAwIG4NCjAwMDAzNjk3NjcgMDAwMDAgbg0KMDAwMDM2OTgzMSAwMDAwMCBu DQowMDAwMzY5ODk1IDAwMDAwIG4NCjAwMDAzNjk5NTkgMDAwMDAgbg0KMDAwMDM3MDAyMyAw MDAwMCBuDQowMDAwMzcwMDkwIDAwMDAwIG4NCjAwMDAzNzAxNTcgMDAwMDAgbg0KMDAwMDM3 MDIyMSAwMDAwMCBuDQowMDAwMzcwMjg1IDAwMDAwIG4NCjAwMDAzNzAzNDkgMDAwMDAgbg0K MDAwMDM3MDQxMyAwMDAwMCBuDQowMDAwMzcwNDc3IDAwMDAwIG4NCjAwMDAzNzA1NDEgMDAw MDAgbg0KMDAwMDM3MDYwOCAwMDAwMCBuDQowMDAwMzcwNjc1IDAwMDAwIG4NCjAwMDAzNzA3 NDIgMDAwMDAgbg0KMDAwMDM3MDkwMCAwMDAwMCBuDQowMDAwMzcxMDczIDAwMDAwIG4NCjAw MDAzNzEyNjEgMDAwMDAgbg0KMDAwMDM3MTQ1NCAwMDAwMCBuDQowMDAwMzcxNjU2IDAwMDAw IG4NCjAwMDAzNzE4NTkgMDAwMDAgbg0KMDAwMDM3MjA2MSAwMDAwMCBuDQowMDAwMzcyMjY1 IDAwMDAwIG4NCjAwMDAzNzI0NjYgMDAwMDAgbg0KMDAwMDM3MjY0NSAwMDAwMCBuDQowMDAw MzcyODMwIDAwMDAwIG4NCjAwMDAzNzMwMDkgMDAwMDAgbg0KMDAwMDM3MzE2OCAwMDAwMCBu DQowMDAwMzczMzMwIDAwMDAwIG4NCjAwMDAzNzM0ODcgMDAwMDAgbg0KMDAwMDM3MzYyMCAw MDAwMCBuDQowMDAwMzczNzUzIDAwMDAwIG4NCjAwMDAzNzM4ODAgMDAwMDAgbg0KMDAwMDM3 NDA5NiAwMDAwMCBuDQowMDAwMzgwMjExIDAwMDAwIG4NCjAwMDAzODA0NDAgMDAwMDAgbg0K MDAwMDM4MDczMiAwMDAwMCBuDQowMDAwMzgwODk1IDAwMDAwIG4NCjAwMDAzODA5NTQgMDAw MDAgbg0KMDAwMDM4MTExNiAwMDAwMCBuDQowMDAwMzgxMTc1IDAwMDAwIG4NCjAwMDAzODEy NTggMDAwMDAgbg0KMDAwMDM4MTU2MyAwMDAwMCBuDQowMDAwMzgxNjQ3IDAwMDAwIG4NCjAw MDAzODE4MDAgMDAwMDAgbg0KMDAwMDM4MTkwMCAwMDAwMCBuDQowMDAwMzgxOTU4IDAwMDAw IG4NCjAwMDAzODIwNTggMDAwMDAgbg0KMDAwMDM4MjExNiAwMDAwMCBuDQowMDAwMzgyMjE2 IDAwMDAwIG4NCjAwMDAzODIyNzQgMDAwMDAgbg0KMDAwMDM4MjM1NSAwMDAwMCBuDQowMDAw MzgyNDU1IDAwMDAwIG4NCjAwMDAzODI2MDkgMDAwMDAgbg0KMDAwMDM4MjY2NyAwMDAwMCBu DQowMDAwMzgyNzY3IDAwMDAwIG4NCjAwMDAzODI4MjUgMDAwMDAgbg0KMDAwMDM4Mjk0MCAw MDAwMCBuDQowMDAwMzgyOTk4IDAwMDAwIG4NCjAwMDAzODMxMDkgMDAwMDAgbg0KMDAwMDM4 MzE5NiAwMDAwMCBuDQowMDAwMzgzMjk3IDAwMDAwIG4NCjAwMDAzODMzNTUgMDAwMDAgbg0K MDAwMDM4MzQ1NiAwMDAwMCBuDQowMDAwMzgzNTE0IDAwMDAwIG4NCjAwMDAzODM2MTUgMDAw MDAgbg0KMDAwMDM4MzY3MyAwMDAwMCBuDQowMDAwMzgzNzc0IDAwMDAwIG4NCjAwMDAzODM4 MzIgMDAwMDAgbg0KMDAwMDM4MzkzMyAwMDAwMCBuDQowMDAwMzgzOTkxIDAwMDAwIG4NCjAw MDAzODQwOTIgMDAwMDAgbg0KMDAwMDM4NDE1MCAwMDAwMCBuDQowMDAwMzg0MjUxIDAwMDAw IG4NCjAwMDAzODQzMDkgMDAwMDAgbg0KMDAwMDM4NDQxMCAwMDAwMCBuDQowMDAwMzg0NDY4 IDAwMDAwIG4NCjAwMDAzODQ1NjkgMDAwMDAgbg0KMDAwMDM4NDYyNyAwMDAwMCBuDQowMDAw Mzg0NzExIDAwMDAwIG4NCjAwMDAzODQ3OTUgMDAwMDAgbg0KMDAwMDM4NDg3NyAwMDAwMCBu DQowMDAwMzg0OTYxIDAwMDAwIG4NCjAwMDAzODUwNDUgMDAwMDAgbg0KMDAwMDM4NTEyOSAw MDAwMCBuDQowMDAwMzg1MjEzIDAwMDAwIG4NCjAwMDAzODUyOTcgMDAwMDAgbg0KMDAwMDM4 NTM5NyAwMDAwMCBuDQowMDAwMzg1NTA4IDAwMDAwIG4NCjAwMDAzODU1OTYgMDAwMDAgbg0K MDAwMDM4NTY4MCAwMDAwMCBuDQowMDAwMzg1NzY0IDAwMDAwIG4NCjAwMDAzODU4NDggMDAw MDAgbg0KMDAwMDM4NTk0MiAwMDAwMCBuDQowMDAwMzg2MDM2IDAwMDAwIG4NCjAwMDAzODYx ODkgMDAwMDAgbg0KMDAwMDM4NjI4MyAwMDAwMCBuDQowMDAwMzg2Mzc3IDAwMDAwIG4NCjAw MDAzODY0NzEgMDAwMDAgbg0KMDAwMDM4NjU2NSAwMDAwMCBuDQowMDAwMzg2NjU5IDAwMDAw IG4NCjAwMDAzODY3NTMgMDAwMDAgbg0KMDAwMDM4Njg0NyAwMDAwMCBuDQowMDAwMzg2OTM3 IDAwMDAwIG4NCjAwMDAzODcwMjcgMDAwMDAgbg0KMDAwMDM4NzExNyAwMDAwMCBuDQowMDAw Mzg3MjA3IDAwMDAwIG4NCjAwMDAzODcyOTcgMDAwMDAgbg0KMDAwMDM4NzM4NyAwMDAwMCBu DQowMDAwMzg3NDc3IDAwMDAwIG4NCjAwMDAzODc1NjcgMDAwMDAgbg0KMDAwMDM4NzY1NyAw MDAwMCBuDQowMDAwMzg3NzQ3IDAwMDAwIG4NCjAwMDAzODc4MzggMDAwMDAgbg0KMDAwMDM4 NzkyOSAwMDAwMCBuDQowMDAwMzg4MDIwIDAwMDAwIG4NCjAwMDAzODgxMTEgMDAwMDAgbg0K MDAwMDM4ODIwMiAwMDAwMCBuDQowMDAwMzg4MjkzIDAwMDAwIG4NCjAwMDAzODgzODQgMDAw MDAgbg0KMDAwMDM4ODQ3NSAwMDAwMCBuDQowMDAwMzg4NTY2IDAwMDAwIG4NCjAwMDAzODg2 NTcgMDAwMDAgbg0KMDAwMDM4ODc0OCAwMDAwMCBuDQowMDAwMzg4ODM5IDAwMDAwIG4NCjAw MDAzODg5MzAgMDAwMDAgbg0KMDAwMDM4OTAyMSAwMDAwMCBuDQowMDAwMzg5MTEyIDAwMDAw IG4NCjAwMDAzODkyMDMgMDAwMDAgbg0KMDAwMDM4OTI5NCAwMDAwMCBuDQowMDAwMzg5Mzg1 IDAwMDAwIG4NCjAwMDAzODk0ODcgMDAwMDAgbg0KMDAwMDM4OTU2NSAwMDAwMCBuDQowMDAw Mzg5NjY3IDAwMDAwIG4NCjAwMDAzODk3NDUgMDAwMDAgbg0KMDAwMDM4OTg0NyAwMDAwMCBu DQowMDAwMzg5OTI1IDAwMDAwIG4NCjAwMDAzOTAwMjcgMDAwMDAgbg0KMDAwMDM5MDEwNSAw MDAwMCBuDQowMDAwMzkwMjA3IDAwMDAwIG4NCjAwMDAzOTAyODUgMDAwMDAgbg0KMDAwMDM5 MDM3NiAwMDAwMCBuDQowMDAwMzkwNDY3IDAwMDAwIG4NCjAwMDAzOTA1NTcgMDAwMDAgbg0K MDAwMDM5MDY0NyAwMDAwMCBuDQowMDAwMzkwNzM3IDAwMDAwIG4NCjAwMDAzOTA4MzggMDAw MDAgbg0KMDAwMDM5MDkxNiAwMDAwMCBuDQowMDAwMzkxMDE3IDAwMDAwIG4NCjAwMDAzOTEw OTUgMDAwMDAgbg0KMDAwMDM5MTE5NiAwMDAwMCBuDQowMDAwMzkxMjc0IDAwMDAwIG4NCjAw MDAzOTEzNjQgMDAwMDAgbg0KMDAwMDM5MTQ1NCAwMDAwMCBuDQowMDAwMzkxNTQ0IDAwMDAw IG4NCjAwMDAzOTE2MzQgMDAwMDAgbg0KMDAwMDM5MTcyNSAwMDAwMCBuDQowMDAwMzkxODE2 IDAwMDAwIG4NCjAwMDAzOTE5MDcgMDAwMDAgbg0KMDAwMDM5MTk5OCAwMDAwMCBuDQowMDAw MzkyMDg5IDAwMDAwIG4NCjAwMDAzOTIxODAgMDAwMDAgbg0KMDAwMDM5MjI3MSAwMDAwMCBu DQowMDAwMzkyMzYyIDAwMDAwIG4NCjAwMDAzOTI0NTMgMDAwMDAgbg0KMDAwMDM5MjU0NCAw MDAwMCBuDQowMDAwMzkyNjM1IDAwMDAwIG4NCjAwMDAzOTI3MjYgMDAwMDAgbg0KMDAwMDM5 MjgxNyAwMDAwMCBuDQowMDAwMzkyOTA4IDAwMDAwIG4NCjAwMDAzOTI5OTkgMDAwMDAgbg0K MDAwMDM5MzA5MCAwMDAwMCBuDQowMDAwMzkzMTgxIDAwMDAwIG4NCjAwMDAzOTMyNzIgMDAw MDAgbg0KMDAwMDM5MzM2MyAwMDAwMCBuDQowMDAwMzkzNDU0IDAwMDAwIG4NCjAwMDAzOTM1 NDUgMDAwMDAgbg0KMDAwMDM5MzYzNiAwMDAwMCBuDQowMDAwMzkzNzI3IDAwMDAwIG4NCjAw MDAzOTM4MTggMDAwMDAgbg0KMDAwMDM5MzkwOSAwMDAwMCBuDQowMDAwMzk0MDAwIDAwMDAw IG4NCjAwMDAzOTQwOTEgMDAwMDAgbg0KMDAwMDM5NDE4MiAwMDAwMCBuDQowMDAwMzk0Mjcz IDAwMDAwIG4NCjAwMDAzOTQzNjMgMDAwMDAgbg0KMDAwMDM5NDQ1MyAwMDAwMCBuDQowMDAw Mzk0NTQzIDAwMDAwIG4NCjAwMDAzOTQ2MzMgMDAwMDAgbg0KMDAwMDM5NDcyMyAwMDAwMCBu DQowMDAwMzk0ODEzIDAwMDAwIG4NCjAwMDAzOTQ5MDMgMDAwMDAgbg0KMDAwMDM5NDk5MyAw MDAwMCBuDQowMDAwMzk1MDgzIDAwMDAwIG4NCjAwMDAzOTUxODcgMDAwMDAgbg0KMDAwMDM5 NTQ4MCAwMDAwMCBuDQowMDAwMzk1NTcxIDAwMDAwIG4NCjAwMDAzOTU2NjIgMDAwMDAgbg0K MDAwMDM5NTc1MyAwMDAwMCBuDQowMDAwMzk1ODQ0IDAwMDAwIG4NCjAwMDAzOTU5NzYgMDAw MDAgbg0KMDAwMDM5NjA2OCAwMDAwMCBuDQowMDAwMzk2MTYwIDAwMDAwIG4NCjAwMDAzOTYy NTIgMDAwMDAgbg0KMDAwMDM5NjM1NSAwMDAwMCBuDQowMDAwMzk2NDMzIDAwMDAwIG4NCjAw MDAzOTY1MzYgMDAwMDAgbg0KMDAwMDM5NjYxNCAwMDAwMCBuDQowMDAwMzk2NzE3IDAwMDAw IG4NCjAwMDAzOTY3OTUgMDAwMDAgbg0KMDAwMDM5Njg4NyAwMDAwMCBuDQowMDAwMzk2OTc5 IDAwMDAwIG4NCjAwMDAzOTcwNzEgMDAwMDAgbg0KMDAwMDM5NzE2NCAwMDAwMCBuDQowMDAw Mzk3MjU3IDAwMDAwIG4NCjAwMDAzOTczNTAgMDAwMDAgbg0KMDAwMDM5NzQ0MyAwMDAwMCBu DQowMDAwMzk3NTM2IDAwMDAwIG4NCjAwMDAzOTc2MjkgMDAwMDAgbg0KMDAwMDM5NzcyMiAw MDAwMCBuDQowMDAwMzk3ODE1IDAwMDAwIG4NCjAwMDAzOTc5MDggMDAwMDAgbg0KMDAwMDM5 ODAwMSAwMDAwMCBuDQowMDAwMzk4MDk0IDAwMDAwIG4NCjAwMDAzOTgyMTUgMDAwMDAgbg0K MDAwMDM5ODMyNSAwMDAwMCBuDQowMDAwMzk4NDEyIDAwMDAwIG4NCjAwMDAzOTg1MjIgMDAw MDAgbg0KMDAwMDM5ODYwOSAwMDAwMCBuDQowMDAwMzk4NzAyIDAwMDAwIG4NCjAwMDAzOTg3 OTUgMDAwMDAgbg0KMDAwMDM5ODg4OCAwMDAwMCBuDQowMDAwMzk4OTgxIDAwMDAwIG4NCjAw MDAzOTkwNzQgMDAwMDAgbg0KMDAwMDM5OTE2NyAwMDAwMCBuDQowMDAwMzk5MjYwIDAwMDAw IG4NCjAwMDAzOTkzNTMgMDAwMDAgbg0KMDAwMDM5OTQ0NiAwMDAwMCBuDQowMDAwMzk5NTUw IDAwMDAwIG4NCjAwMDAzOTk2MjggMDAwMDAgbg0KMDAwMDM5OTczMiAwMDAwMCBuDQowMDAw Mzk5ODEwIDAwMDAwIG4NCjAwMDAzOTk5MDMgMDAwMDAgbg0KMDAwMDM5OTk5NiAwMDAwMCBu DQowMDAwNDAwMDg5IDAwMDAwIG4NCjAwMDA0MDAxODIgMDAwMDAgbg0KMDAwMDQwMDI3NSAw MDAwMCBuDQowMDAwNDAwMzY3IDAwMDAwIG4NCjAwMDA0MDA0NTkgMDAwMDAgbg0KMDAwMDQw MDU1MSAwMDAwMCBuDQowMDAwNDAwNjQzIDAwMDAwIG4NCjAwMDA0MDA3MzUgMDAwMDAgbg0K MDAwMDQwMDgyNyAwMDAwMCBuDQowMDAwNDAwOTE5IDAwMDAwIG4NCjAwMDA0MDEwMTEgMDAw MDAgbg0KMDAwMDQwMTEwMyAwMDAwMCBuDQowMDAwNDAxMTk1IDAwMDAwIG4NCjAwMDA0MDEy ODggMDAwMDAgbg0KMDAwMDQwMTM4MSAwMDAwMCBuDQowMDAwNDAxNDc0IDAwMDAwIG4NCjAw MDA0MDE1NjcgMDAwMDAgbg0KMDAwMDQwMTY2MCAwMDAwMCBuDQowMDAwNDAxNzUzIDAwMDAw IG4NCjAwMDA0MDE4NDYgMDAwMDAgbg0KMDAwMDQwMTkzOSAwMDAwMCBuDQowMDAwNDAyMDQz IDAwMDAwIG4NCjAwMDA0MDIxMjEgMDAwMDAgbg0KMDAwMDQwMjIyNSAwMDAwMCBuDQowMDAw NDAyMzAzIDAwMDAwIG4NCjAwMDA0MDI0MDcgMDAwMDAgbg0KMDAwMDQwMjQ4NSAwMDAwMCBu DQowMDAwNDAyNTc4IDAwMDAwIG4NCjAwMDA0MDI2NzEgMDAwMDAgbg0KMDAwMDQwMjc2NCAw MDAwMCBuDQowMDAwNDAyODU3IDAwMDAwIG4NCjAwMDA0MDI5NTAgMDAwMDAgbg0KMDAwMDQw MzA0MyAwMDAwMCBuDQowMDAwNDAzMTM2IDAwMDAwIG4NCjAwMDA0MDMyMjkgMDAwMDAgbg0K MDAwMDQwMzMyMiAwMDAwMCBuDQowMDAwNDAzNDE1IDAwMDAwIG4NCjAwMDA0MDM1MDggMDAw MDAgbg0KMDAwMDQwMzYwMSAwMDAwMCBuDQowMDAwNDAzNjk0IDAwMDAwIG4NCjAwMDA0MDM3 ODcgMDAwMDAgbg0KMDAwMDQwMzg4MCAwMDAwMCBuDQowMDAwNDAzOTczIDAwMDAwIG4NCjAw MDA0MDQwNjYgMDAwMDAgbg0KMDAwMDQwNDE1OSAwMDAwMCBuDQowMDAwNDA0MjUyIDAwMDAw IG4NCjAwMDA0MDQzNDUgMDAwMDAgbg0KMDAwMDQwNDQzNyAwMDAwMCBuDQowMDAwNDA0NTI5 IDAwMDAwIG4NCjAwMDA0MDQ2MjEgMDAwMDAgbg0KMDAwMDQwNDcxMyAwMDAwMCBuDQowMDAw NDA0ODA1IDAwMDAwIG4NCjAwMDA0MDQ4OTcgMDAwMDAgbg0KMDAwMDQwNDk4OSAwMDAwMCBu DQowMDAwNDA1MDgxIDAwMDAwIG4NCjAwMDA0MDUxODQgMDAwMDAgbg0KMDAwMDQwNTI2MiAw MDAwMCBuDQowMDAwNDA1MzY1IDAwMDAwIG4NCjAwMDA0MDU0NDMgMDAwMDAgbg0KMDAwMDQw NTU0NyAwMDAwMCBuDQowMDAwNDA1NjI1IDAwMDAwIG4NCjAwMDA0MDU3MjkgMDAwMDAgbg0K MDAwMDQwNTgwNyAwMDAwMCBuDQowMDAwNDA1OTExIDAwMDAwIG4NCjAwMDA0MDU5ODkgMDAw MDAgbg0KMDAwMDQwNjA5MyAwMDAwMCBuDQowMDAwNDA2MTcxIDAwMDAwIG4NCjAwMDA0MDYy NzUgMDAwMDAgbg0KMDAwMDQwNjM1MyAwMDAwMCBuDQowMDAwNDA2NDU3IDAwMDAwIG4NCjAw MDA0MDY1MzUgMDAwMDAgbg0KMDAwMDQwNjYzOSAwMDAwMCBuDQowMDAwNDA2NzE3IDAwMDAw IG4NCjAwMDA0MDY4MTAgMDAwMDAgbg0KMDAwMDQwNjkwMyAwMDAwMCBuDQowMDAwNDA2OTk2 IDAwMDAwIG4NCjAwMDA0MDcwODkgMDAwMDAgbg0KMDAwMDQwNzE4MiAwMDAwMCBuDQowMDAw NDA3Mjc1IDAwMDAwIG4NCjAwMDA0MDczNjggMDAwMDAgbg0KMDAwMDQwNzQ2MSAwMDAwMCBu DQowMDAwNDA3NTU0IDAwMDAwIG4NCjAwMDA0MDc2NDcgMDAwMDAgbg0KMDAwMDQwNzc0MCAw MDAwMCBuDQowMDAwNDA3ODMzIDAwMDAwIG4NCjAwMDA0MDc5MjYgMDAwMDAgbg0KMDAwMDQw ODAxOSAwMDAwMCBuDQowMDAwNDA4MTEyIDAwMDAwIG4NCjAwMDA0MDgyMDUgMDAwMDAgbg0K MDAwMDQwODI5OCAwMDAwMCBuDQowMDAwNDA4MzkxIDAwMDAwIG4NCjAwMDA0MDg0ODQgMDAw MDAgbg0KMDAwMDQwODU3NiAwMDAwMCBuDQowMDAwNDA4NjY4IDAwMDAwIG4NCjAwMDA0MDg3 NjAgMDAwMDAgbg0KMDAwMDQwODg1MiAwMDAwMCBuDQowMDAwNDA4OTQ0IDAwMDAwIG4NCjAw MDA0MDkwMzYgMDAwMDAgbg0KMDAwMDQwOTEyOCAwMDAwMCBuDQowMDAwNDA5MjIwIDAwMDAw IG4NCjAwMDA0MDkzMTIgMDAwMDAgbg0KMDAwMDQwOTQwNCAwMDAwMCBuDQowMDAwNDA5NDk3 IDAwMDAwIG4NCjAwMDA0MDk1OTAgMDAwMDAgbg0KMDAwMDQwOTY4MyAwMDAwMCBuDQowMDAw NDA5Nzc2IDAwMDAwIG4NCjAwMDA0MDk4NjkgMDAwMDAgbg0KMDAwMDQwOTk2MiAwMDAwMCBu DQowMDAwNDEwMDU1IDAwMDAwIG4NCjAwMDA0MTAxNDggMDAwMDAgbg0KMDAwMDQxMDI0MSAw MDAwMCBuDQowMDAwNDEwMzM0IDAwMDAwIG4NCjAwMDA0MTA0MjcgMDAwMDAgbg0KMDAwMDQx MDUyMCAwMDAwMCBuDQowMDAwNDEwNjEzIDAwMDAwIG4NCjAwMDA0MTA3MDYgMDAwMDAgbg0K MDAwMDQxMDc5OSAwMDAwMCBuDQowMDAwNDEwODkyIDAwMDAwIG4NCjAwMDA0MTA5ODUgMDAw MDAgbg0KMDAwMDQxMTA3OCAwMDAwMCBuDQowMDAwNDExMTcxIDAwMDAwIG4NCjAwMDA0MTEy NzUgMDAwMDAgbg0KMDAwMDQxMTM1MyAwMDAwMCBuDQowMDAwNDExNDQ2IDAwMDAwIG4NCjAw MDA0MTE1NTAgMDAwMDAgbg0KMDAwMDQxMTYyOCAwMDAwMCBuDQowMDAwNDExNzM4IDAwMDAw IG4NCjAwMDA0MTE3OTMgMDAwMDAgbg0KMDAwMDQxMTg5NyAwMDAwMCBuDQowMDAwNDExOTc1 IDAwMDAwIG4NCjAwMDA0MTIwNjggMDAwMDAgbg0KMDAwMDQxMjE3MiAwMDAwMCBuDQowMDAw NDEyMjUwIDAwMDAwIG4NCjAwMDA0MTIzNDMgMDAwMDAgbg0KMDAwMDQxMjQzNiAwMDAwMCBu DQowMDAwNDEyNTI5IDAwMDAwIG4NCjAwMDA0MTI2MTIgMDAwMDAgbg0KMDAwMDQxMjY5NSAw MDAwMCBuDQowMDAwNDEyNzc4IDAwMDAwIG4NCjAwMDA0MTI4NjEgMDAwMDAgbg0KMDAwMDQx Mjk0NCAwMDAwMCBuDQowMDAwNDEzMDI3IDAwMDAwIG4NCjAwMDA0MTMxMTAgMDAwMDAgbg0K MDAwMDQxMzE5MyAwMDAwMCBuDQowMDAwNDEzMjc2IDAwMDAwIG4NCjAwMDA0MTMzNTggMDAw MDAgbg0KMDAwMDQxNTg2MCAwMDAwMCBuDQowMDAwNDE1OTU5IDAwMDAwIG4NCjAwMDA0MTYw MTkgMDAwMDAgbg0KMDAwMDQxNjA3OSAwMDAwMCBuDQowMDAwNDE2MTM5IDAwMDAwIG4NCjAw MDA0MTYxOTkgMDAwMDAgbg0KMDAwMDQxNjI1OSAwMDAwMCBuDQowMDAwNDE2MzQwIDAwMDAw IG4NCjAwMDA0MTY0MDAgMDAwMDAgbg0KMDAwMDQxNjQ2MCAwMDAwMCBuDQowMDAwNDE2NTIw IDAwMDAwIG4NCjAwMDA0MTY2MDEgMDAwMDAgbg0KMDAwMDQxNjY2MSAwMDAwMCBuDQowMDAw NDE2NzIxIDAwMDAwIG4NCjAwMDA0MTY3ODEgMDAwMDAgbg0KMDAwMDQxNjg1MyAwMDAwMCBu DQowMDAwNDE2OTEzIDAwMDAwIG4NCjAwMDA0MTY5NzMgMDAwMDAgbg0KMDAwMDQxNzA1NCAw MDAwMCBuDQowMDAwNDE3MTE0IDAwMDAwIG4NCjAwMDA0MTcxNzQgMDAwMDAgbg0KMDAwMDQx NzIzNCAwMDAwMCBuDQowMDAwNDE3MzYxIDAwMDAwIG4NCjAwMDA0MTc0MjEgMDAwMDAgbg0K MDAwMDQxNzQ4MSAwMDAwMCBuDQowMDAwNDE3NTQxIDAwMDAwIG4NCjAwMDA0MTc2MDEgMDAw MDAgbg0KMDAwMDQxNzY2MSAwMDAwMCBuDQowMDAwNDE3NzMzIDAwMDAwIG4NCjAwMDA0MTc3 OTMgMDAwMDAgbg0KMDAwMDQxNzg1MyAwMDAwMCBuDQowMDAwNDE3OTEzIDAwMDAwIG4NCjAw MDA0MTc5NzMgMDAwMDAgbg0KMDAwMDQxODA2MyAwMDAwMCBuDQowMDAwNDE4MTIzIDAwMDAw IG4NCjAwMDA0MTgxODMgMDAwMDAgbg0KMDAwMDQxODI0MyAwMDAwMCBuDQowMDAwNDE4MzAz IDAwMDAwIG4NCjAwMDA0MTg0ODggMDAwMDAgbg0KMDAwMDQxODg5NSAwMDAwMCBuDQowMDAw NDE4OTY1IDAwMDAwIG4NCjAwMDA0MTkwMzUgMDAwMDAgbg0KMDAwMDQxOTM3OCAwMDAwMCBu DQowMDAwNDE5NzU3IDAwMDAwIG4NCjAwMDA0MjA1MDEgMDAwMDAgbg0KMDAwMDQyMDU4NSAw MDAwMCBuDQowMDAwNDIwOTkyIDAwMDAwIG4NCjAwMDA0MjEwNjIgMDAwMDAgbg0KMDAwMDQy MTEzMiAwMDAwMCBuDQowMDAwNDIxNTMwIDAwMDAwIG4NCjAwMDA0MjE4ODIgMDAwMDAgbg0K MDAwMDQyMjM0NCAwMDAwMCBuDQowMDAwNDIyMzc3IDAwMDAwIG4NCjAwMDA0MjI0MTAgMDAw MDAgbg0KMDAwMDQyMjQ1OCAwMDAwMCBuDQowMDAwNDIzMDc1IDAwMDAwIG4NCjAwMDA0MjQ0 NDYgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAxNzU5DS9JRFs8YWUzNmY2MmJiNDIyNDRj NTE0NzE2MzI1MTU0MmM2OGM+PDQ0YzZhMWJjMjAyNTJkYjI2NzQ1MzZhN2E5ZGYwOThmPl0N Pj4Nc3RhcnR4cmVmDTE3Mw0lJUVPRg0= --------------010408030501050905060009-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 18 13:50:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13454 for ; Mon, 18 Feb 2002 13:50:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05221 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 13:50:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04172; Mon, 18 Feb 2002 13:22:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04141 for ; Mon, 18 Feb 2002 13:22:52 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12437 for ; Mon, 18 Feb 2002 13:22:43 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1IIMFh16794 for ; Mon, 18 Feb 2002 10:22:15 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACM62443; Mon, 18 Feb 2002 10:22:14 -0800 (PST) Date: Mon, 18 Feb 2002 10:20:54 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] comments on srv draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, below are some comments on the SRV draft. apologies in advance for any dups: thanks, -rohan comments on SRV draft: page 5 3rd para: proposed rewrite: The procedures here are invoked when a client need to send a request to a server identified by a SIP URI (frequently the Request-URI); or when a client wishes to send a request to a specifically configured outbound proxy server, which is identified by a domain name instead of a numeric IP address. The procedures defined here, in no way affect any URI processing (i.e. the client will never rewrite the Request-URI or other SIP URIs with the result of the DNS lookups); they only provide a list of IP address, port, and transport protocol tuples to which the request can be sent. page 6 after 2nd para: insert: If the no transport is specified, but the resulting UDP would exceed the MTU-related size limitations described in Section 19.1.1 of [1], the client MUST use TCP. page 8 4th para: proposed rewrite: The client SHOULD maintain a table indicating the status of a particular host (that is, whether attempts to contact it resulted in success or failure). The table is indexed with the IP address, port, and transport for a particular host. If a request fails to a particular host, the client updates the table to reflect that this host should not be contacted for some protocol-determined or policy-determined period of time. A client SHOULD honor the time proposed in any Retry-After header in a 503 response. A RECOMMENDED default period of time is one hour. page 10 1st full para: should insert a brief reminder of the procedure used before a failure. for example: Recall that when a server first attempts to send a response, it checks ...... page 11 1st para: remind the reader that low values are "better" than high values. NITS: page 3 3rd para: s/Transport Protocol/The choice of transport protocol/ page 4 2nd para: the following text is redundant duplication of the previous sentence: "The request would fail, and that would be detected by proxy 1. Proxy 1 would then try proxy 2.2" page 4 4th line from bottom: "a SIP response" -> "some SIP responses" or "responses to INVITE requests" top of page 5: SHALLNOT page 5 para 6: s/domain/domain name/ page 6 para 5 ("The NAPTR records"): s/domain to/domain, to/ page 7 near bottom: s/where, where/where/ page 9 last para: s/RFC 2543bis/SIP/ page 10 3rd para: s/tred/tried/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 18 14:05:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13915 for ; Mon, 18 Feb 2002 14:05:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06270 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 14:06:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05030; Mon, 18 Feb 2002 13:43:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04995 for ; Mon, 18 Feb 2002 13:43:36 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13145 for ; Mon, 18 Feb 2002 13:43:32 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1IIhd6Y006790; Mon, 18 Feb 2002 13:43:41 -0500 (EST) Message-ID: <3C714B2B.4998427E@dynamicsoft.com> Date: Mon, 18 Feb 2002 13:42:51 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Beck01, Wolfgang" CC: ekr@rtfm.com, sip@ietf.org Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Can someone explain why this entire conversation isn't completely MOOT? SMIME is a MAY now. Yes, it doesn't work for every single possible scenario, but there are unquestionably places where it IS useful. Thus, this argument about whether its good or bad is just a plain WASTE OF TIME. I would appreciate if, instead, people could focus on reading and reviewing the text, to make sure that when people do use the S/MIME mechanisms, it is done properly. -Jonathan R. "Beck01, Wolfgang" wrote: > > Eric Rescorla write: > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@rtfm.com] > > Michael Thomas writes: > > > I'm well aware of that. I had to code up a BER > > > parser in the late 80's for SNMP. It's still a > > > pig.> It takes quite a bit of effort to hand > > > code ASN.1, and even then you get messes like > > > MIT's Kerberos code which is not only hand > > > coded, but bloated on top of it. > > I'm sorry, but I don't see the relevance of this. Anything we > > require will force the embedded guys to change something and > > I'm certainly in favor of making that something as minimal as > > possible, consistent with the requirements of decent security. > > > > What's presently at issue here is the actual impact of adding > > S/MIME as opposed to some non-S/MIME messaging system with > > similar functionality. Your argument about the piggishness > > of ASN.1 notwithstanding, my experience implementing such > > systems leads me to believe that the footprint of such a system > > will be roughly the same as S/MIME. > > > When I had a first look at the TLS and S/MIME RfCs, I had similar > feelings > as Mike. Both protocols appear as huge tasks, which require a lot of > extra > development time. Your [Eric's] code size estimation indicate something > different, but for someone less experienced in security protocols it is > hard to decide what can be left off. It might be helpful to write down > the minimum TLS and S/MIME feature sets with respect to SIP in some > informational draft. I fear that with TLS and S/MIME a lot of > implementors > will balk and end up without any encryption. > > -- > Wolfgang Beck > T-Systems Nova GmbH > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 18 14:06:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13947 for ; Mon, 18 Feb 2002 14:06:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06285 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 14:06:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05086; Mon, 18 Feb 2002 13:44:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05054 for ; Mon, 18 Feb 2002 13:44:16 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13163 for ; Mon, 18 Feb 2002 13:44:12 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1IIV9n01117; Mon, 18 Feb 2002 12:31:09 -0600 Message-ID: <3C71486D.5060706@dynamicsoft.com> Date: Mon, 18 Feb 2002 12:31:09 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Hisham Khartabil CC: sip@ietf.org, jdrosen@dynamicsoft.com, "gonzalo.camarillo" Subject: Expires heade field in REGISTER responses: (was Re: [Sip] comments and nits on bis-07) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hisham Khartabil wrote: > >>-----Original Message----- >>From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >>Sent: Monday, 18 February 2002 1:17 AM >>To: Hisham Khartabil >>Cc: sip@ietf.org; jdrosen@dynamicsoft.com; gonzalo.camarillo >>Subject: Re: [Sip] comments and nits on bis-07 >> > >>>- line 1697: why is it a MUST for a contact header to contain >>> >>an "expires" >> >>>parameter? >>> >> >>This is how the registrar communicates how much longer the >>binding will last >>back to the client. >> > > You misunderstood my question. Anyway, from your comment, I gather that an > Expires header in a 200 response to a REGISTER is Optional. Is that correct? > Can an entry in table 2 be added to reflect that? The table already says that (and empty cell in the "where" column means requests and responses. Yes - the Expires header field in a 200 response to a REGISTER request is allowed. It also has no meaning with respect to the Contacts in the response since each provided Contact MUST contain an ;expires= parameter. (Note to casual readers - this is a statement about the _response_, not the REGISTER request) So - help me understand your original question. Is it "why don't you allow the "use the expires parameter if present, otherwise use the Expires header value in REGISTER responses like you do in REGISTER requests?". I can't think of a good reason right now. Jonathan? I will note that its critically important for Contact values in 3xx responses to contain their own expires parameter (since proxies can aggregate contacts from multiple 3xx's received at a fork-point). 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 daemon@optimus.ietf.org Mon Feb 18 14:19:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14397 for ; Mon, 18 Feb 2002 14:19:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06616 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 14:19:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05360; Mon, 18 Feb 2002 13:55:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05326 for ; Mon, 18 Feb 2002 13:55:11 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13569 for ; Mon, 18 Feb 2002 13:55:06 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 18 Feb 2002 18:55:23 UT Received: from jolaptop ([80.3.216.239]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Mon, 18 Feb 2002 18:57:19 +0000 From: "Jo Hornsby" To: "Robert Sparks" Cc: Subject: RE: [Sip] Comments on bis-06 Date: Mon, 18 Feb 2002 18:58:59 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3C6F2BBA.80208@dynamicsoft.com> X-OriginalArrivalTime: 18 Feb 2002 18:57:19.0343 (UTC) FILETIME=[1709E7F0:01C1B8AE] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > For the 500 vs 4xx below - as far as I know, the choice > was arbitrary. Jonathan points out that 500 makes a little > more sense than 4xx since a 5xx class response means > "This request may succeed if you send it again at a later > time". The current text still says 500. Fair enough. Actually, from that point-of-view, a 5xx is certainly more desirable semantically. And since there is really little other distinction, seems most sensible. Good good. - Jo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 18 14:28:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14777 for ; Mon, 18 Feb 2002 14:28:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06985 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 14:28:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05494; Mon, 18 Feb 2002 13:59:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05465 for ; Mon, 18 Feb 2002 13:59:51 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13784 for ; Mon, 18 Feb 2002 13:59:46 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1IIkjn01123; Mon, 18 Feb 2002 12:46:45 -0600 Message-ID: <3C714C14.7030704@dynamicsoft.com> Date: Mon, 18 Feb 2002 12:46:44 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Hisham Khartabil CC: sip@ietf.org, jdrosen@dynamicsoft.com, "gonzalo.camarillo" Subject: No useful contacts in a 3xx to an INVITE (was Re: [Sip] comments and nits on bis-07) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The 3xx may also contain no contacts the UAC is willing to try to use. Through policy or asking the user or whatever, it determines that it has nowhere else to go, so it just stops. This is what would happen in the case that a 3xx with no contacts showed up (though again, that should never happen). Also remember that while we expect most URIs provided in 3xx responses (to INVITE anyhow) to contain sip: URIs, other schemes (like mailto: and http:) are allowed. I will adjust 13.3.1.2 to reflect that a UAS won't be attempting to redirect unless it has at least one URI to redirect towards and reflect that more than one alternate locations may be provided. RjS Hisham Khartabil wrote: >>>- line 2166: section 13.3.1.2 does not talk about what happens >>> >>if a 3xx is >> >>>returned with no contacts. >>> >> >>How would that happen? The sections on generating 3xx specify returning a >>different response if there are no alternate URIs to try. >> >> > > I was referring to the "SHOULD", the spec in that line says "301 or 302 > response SHOULD contain a Contact header field...". The SHOULD gives the > impression that a 3xx response with no contacts is possible, hence the > question, how does a UAC handle this? > > Table 2 also specifies it as Optional. > > In any case, it should read "301 or 302 response SHOULD contain at least one > Contact header field..." > ^^^^^^^^^^^^ > > 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 daemon@optimus.ietf.org Mon Feb 18 14:31:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14885 for ; Mon, 18 Feb 2002 14:31:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA07408 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 14:31:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06168; Mon, 18 Feb 2002 14:03:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06137 for ; Mon, 18 Feb 2002 14:03:30 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13878 for ; Mon, 18 Feb 2002 14:03:26 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1IJ0tQl004027; Mon, 18 Feb 2002 14:00:55 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 14:02:58 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630067@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Fairlie-Cuninghame, Robert'" , Adam Roach , "'sip@ietf.org'" Cc: Jonathan Rosenberg Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! Date: Mon, 18 Feb 2002 14:02:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > Basically I disagree with Jonathan that all of error-reasons should be > clumped into the "rejected". Currently "rejected" covers: > - initial authorization failed > - authorization failed at a later time due to change > authorization policy > - Event resource does not exists > - Event resource no longer exists I believe a "reason" code could only conceivably cover the second and fourth cases. In the first and third cases, you would never get as far as a NOTIFY; the SUBSCRIBE would be answered with a suitable error code, and no NOTIFY would ever be sent. > My suggestion is that the following error-reason is needed: > > -- > "noresource": The subscription has been terminated because > the resource > identified by the request-uri and/or the SUBSCRIBE request's > message body is > unknown or is indefinitely unavailable. Clients SHOULD NOT attempt to > re-subscribe unless a "retry-after" parameter is also present. I'll wait for Jonathan to reply before taking action. While I agree that the distinction you make is useful, I think it's far, far more important to have sip-events synced with watcherinfo than it is to have another reason code for this case. > Other comments: This is only a small nit but I think the > "rejected" reason > comment in 4.2.4 should be changed to state that the > termination is due to a > initial authorization failure OR a change in the > authorization policy. It > currently only says that the error-reason covers the later reason. As I point out above, "reason" could never apply due to an initial authorization failure; if a user is not authorized at the time of subscription (and the notifier is going to let the subscriber know of such a failure), the SUBSCRIBE is answered with a "403 Forbidden." If the SUBSCRIBE isn't answered with a 403, then any authorization-related event that causes the subscription to be rejected later is, by definition, a change in authorization policy. Thanks for reading over the draft! /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 daemon@optimus.ietf.org Mon Feb 18 14:42:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15291 for ; Mon, 18 Feb 2002 14:42:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA07767 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 14:42:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06665; Mon, 18 Feb 2002 14:19:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06634 for ; Mon, 18 Feb 2002 14:19:44 -0500 (EST) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14414 for ; Mon, 18 Feb 2002 14:19:39 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 11:19:37 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Adam Roach'" , "'sip@ietf.org'" Cc: Jonathan Rosenberg Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! Date: Mon, 18 Feb 2002 11:19:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Adam, > > Basically I disagree with Jonathan that all of > error-reasons should be > > clumped into the "rejected". Currently "rejected" covers: > > - initial authorization failed > > - authorization failed at a later time due to change > > authorization policy > > - Event resource does not exists > > - Event resource no longer exists > > I believe a "reason" code could only conceivably cover the second > and fourth cases. In the first and third cases, you would never > get as far as a NOTIFY; the SUBSCRIBE would be answered with a > suitable error code, and no NOTIFY would ever be sent. > This assumes that authorization and resource location occurs instantaneously - which cannot be assumed. If either of these operations take non-negligible time then the Notifier MUST send an immediate NOTIFY (which "Subscription-State: pending"). You therefore needs an appropriate terminate reason-code - the SUBSCRIBE response codes cannot be used for this. Regards, Robert. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 18 14:42:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15331 for ; Mon, 18 Feb 2002 14:42:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA07795 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 14:42:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06393; Mon, 18 Feb 2002 14:12:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06368 for ; Mon, 18 Feb 2002 14:12:53 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14152 for ; Mon, 18 Feb 2002 14:12:48 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1IJAFQl004145; Mon, 18 Feb 2002 14:10:16 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 14:12:18 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630068@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Christer Holmberg'" , sip@ietf.org Subject: RE: [Sip] Bis-7: Question on brackets Date: Mon, 18 Feb 2002 14:12:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > A long time there was a discussion (it has also been discussed at > bake-off/SIPit events) on how to separate URI parameters from header > parameters in the To- and From headers. > > To my understanding, it was agreed that if header parameters (eg the > tag) are used, the URI MUST be inside brackets. Nope. You had it backwards. If the *URI* has parameters, then the URI must be in angle brackets. It's been that way since before SIP was published as RFC2543. /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 daemon@optimus.ietf.org Mon Feb 18 15:00:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15997 for ; Mon, 18 Feb 2002 15:00:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08594 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 15:00:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07691; Mon, 18 Feb 2002 14:36:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07657 for ; Mon, 18 Feb 2002 14:36:22 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15015 for ; Mon, 18 Feb 2002 14:36:16 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1IJXcQl004337; Mon, 18 Feb 2002 14:33:38 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGG70>; Mon, 18 Feb 2002 14:35:41 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630069@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Fairlie-Cuninghame, Robert'" Cc: "'sip@ietf.org'" Date: Mon, 18 Feb 2002 14:35:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Event ID (was RE: Events Last Call.) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Copying SIP mailing list... > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > The Event id parameter seems to add a lot of complication to > the draft - why was it added ? There's a rather ugly problem we're trying to solve, and it's probably been the hardest thing to get to work correctly in the whole sip-events draft. The basic setup is this: I'm in an INVITE-initiated session with you. That INVITE transaction set up a dialog with a route path and other goodies that make sure that subsequent requests from me to you end up on exactly the same UA on your end, and that subsequent requests from you to me end up on exactly the same UA on my end. Now, for whatever reason, you want to subscribe to some resource state relating exactly to the terminal that your INVITE landed on. How do you do this? You can't use the contact, since the user-portion may very well contain state information that isn't valid outside the dialog. You can't just copy the route set for this reason and the additional reason that proxies may have done the same sort of trick with the user portion of URIs in the route set. So, what's the solution? As Rohan suggested, you can re-use the same dialog that was created by the INVITE. Problem solved. You just send the SUBSCRIBE on the dialog -- which includes the same route-set and same contact -- and you hit the same UA. But this ends up meaning that you need to be extremely careful about how you define dialog termination. Does the dialog terminate when the BYE comes across, as bis has (until recently) said? That would be bad -- what if one of the events yet to be reported is some sort of end-of-call statistics? So, after much discussion, arguing, and heartburn with a variety of people (including a discussion during my presentation in SLC), we determined that the only reasonable thing to do would be that termination of the last "thing" in a dialog would terminate the dialog. So, we added language to bis to say that BYE doesn't *necessarily* terminate the dialog, and a lengthy discussion in sip-events to talk about dialog lifetimes. To summarize, we need to be able to send SUBSCRIBEs on existing dialogs so that we can reach the same terminal that the dialog "connects" us to. So far, so good. But there's one more scary, ugly problem: what if we need to send *two* subscriptions down this same dialog? In the sunshine case, you can perform demultiplexing based on the event package name. But let's imagine that there's an event package that defines a body for the SUBSCRIBE message. This body gives a filter for what types of events we want to know about. It is quite possible that the easiest (or only) way to subscribe to the events I'm interested in would be to install two subscriptions to the same package with different filter criteria. But when I get a NOTIFY back, how on earth am I going to be able to tell which subscriptoin it corresponds to? The answer we came up with was the "id" parameter. It uniquely identifies a subscription within a dialog. It's easy to implement, not really that confusing, and finally ties up the huge barrel of worms we opened up seven paragraphs ago. /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 daemon@optimus.ietf.org Mon Feb 18 15:09:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16360 for ; Mon, 18 Feb 2002 15:09:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09162 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 15:09:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07858; Mon, 18 Feb 2002 14:43:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07827 for ; Mon, 18 Feb 2002 14:43:20 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15383 for ; Mon, 18 Feb 2002 14:43:13 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1IJglt12496 for ; Mon, 18 Feb 2002 11:42:47 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACM62821; Mon, 18 Feb 2002 11:42:46 -0800 (PST) Date: Mon, 18 Feb 2002 11:41:25 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] comments on 100rel Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, 100rel flows very nicely in spite of being in again/out again. specific comments below. most deal with consistency between section 3 and section 5. thanks, -rohan comments on 100rel-04.9: - page 2 first para: append: "but are not sent reliably in RFC BBBB." - page 5 first sentence: If the PRACK contained a body, ... ^ insert: "session description, it is processed as described in Section 5 of this document. If the PRACK instead containedany other type of" - page 5 4th para: revise the beginning as follows to make consistent with Section 5: Note that the UAS MAY send a final response to the initial request before having recevied PRACKs for all unacknowleged reliable responses, unless any of the unacknowleged reliable provisional response contained a session description. If the UAS does send a final response when reliable responses are still unacknowledged, it SHOULD NOT..... - section 4 first paragraph. seems to missing a sentence between 100rel and requests page 7 para 3: s/One an/Once an/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 18 15:17:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16670 for ; Mon, 18 Feb 2002 15:17:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09529 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 15:17:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08227; Mon, 18 Feb 2002 14:52:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08202 for ; Mon, 18 Feb 2002 14:52:37 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15685 for ; Mon, 18 Feb 2002 14:52:31 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1IJqk6Y006885 for ; Mon, 18 Feb 2002 14:52:47 -0500 (EST) Message-ID: <3C715B5B.81B97BDA@dynamicsoft.com> Date: Mon, 18 Feb 2002 14:51:55 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Note: minor change in transaction ID Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, Bis-08 will reflect a minor change in the way transaction matching is done. The current text in -07 basically uses the combination of the branch ID and source address/port as a transaction ID. We decided to use the two, rather than branch ID alone, to help avoid collisions between branch IDs from different proxies, whether intentionally or maliciously. Usage of the actual source address has some problems, however: 1. For SCTP, the sender can switch between multiple interfaces when sending, 2. It is possible that a routing change could alter the choice of the source interface for sending a request, at a proxy that is running ontop of a routing process (like gated) which is commonly done. The use of network addresses from packets as identifiers is, generally speaking, plagued with such problems, are we are best advised to avoid them. SO, instead, the transaction ID will be based on the branch ID and the value of the sent-by parameter of the top Via. This has similar spacial uniqueness properties as the source address, but SIP mandates its consistency throughout a transaction, thus avoiding many of the pitfalls above. I also made the branch ID unique in space and time, rather than just time, as was mandated by -07. The reasons it that the sent-by field might contain a cluster address, and thus the requests from each proxy in the cluster would contain the same sent-by value, potentially. I think this property is very useful and very important. COmments, questions, as always... THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 18 15:34:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17082 for ; Mon, 18 Feb 2002 15:34:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11022 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 15:34:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09275; Mon, 18 Feb 2002 15:12:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09243 for ; Mon, 18 Feb 2002 15:12:28 -0500 (EST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16490 for ; Mon, 18 Feb 2002 15:12:22 -0500 (EST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Mon, 18 Feb 2002 12:11:19 -0800 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Feb 2002 12:11:19 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Feb 2002 12:11:19 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Feb 2002 12:11:18 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Mon, 18 Feb 2002 12:09:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] SMIME in SIP Date: Mon, 18 Feb 2002 12:09:13 -0800 Message-ID: Thread-Topic: [Sip] SMIME in SIP thread-index: AcG3WfRanp3PILLAS9qdtVCSY5pbtQBXDfJA From: "Christian Huitema" To: , "Michael Thomas" Cc: "Rohan Mahy" , X-OriginalArrivalTime: 18 Feb 2002 20:09:13.0844 (UTC) FILETIME=[22AE8340:01C1B8B8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA09244 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > > 4) TLS doesn't address UDP. IPsec WG is working on > > NAT traversal > > > > Also will break firewall implementations, that have/are being developed by > many well > known vendors, to address SIP....would require that they also decrypt to > peform > pinhole allocation. Would most likely also affect SIP infrastructures > already built > today based on UDP if we must suddenly implement TCP based SIP (Would have > actually > been nice from the start). In fact, we should seriously consider that we reverse the priorities between transport: make TLS a MUST, at least for proxies; make TCP a SHOULD and make UDP a MAY. In fact, I would argue for a "SHOULD NOT support UDP, at least in the absence of IPSEC. There are just way too many ways to attack a UDP based system -- spoof the source address of a proxy and send whatever you wish to the UA, spoof the source address of a third party and mount a denial of service attack against a proxy, etc. Using S/MIME for end-to-end security is certainly a very good idea, but using TLS is probably the only secure solution that we can deploy right now. However, if we want to use TLS seriously, we need to resolve a security issue that is caused by the use of SRV records as specified in draft-ietf-sip-srv-04.txt. In short, DNS records can be spoofed. A hacker can manage to spoof the SRV record for "_sip._tls.microsoft.com" to point to "hackers-are-us.tv", thus intercepting all the SIP traffic to Microsoft. The basic usage of TLS will only guarantee that the name to address mapping is genuine, i.e. that the target is really the authorized server for "hackers-are-us.tv", but that will not make us a whole lot of good. So, when we say "check the certificate", we should really check for a link to the initial domain, pre-SRV. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 18 15:38:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17277 for ; Mon, 18 Feb 2002 15:38:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11106 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 15:38:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09468; Mon, 18 Feb 2002 15:17:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09437 for ; Mon, 18 Feb 2002 15:17:18 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16640 for ; Mon, 18 Feb 2002 15:17:12 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1IKHY6Y006950; Mon, 18 Feb 2002 15:17:34 -0500 (EST) Message-ID: <3C71612A.5C5B1EA6@dynamicsoft.com> Date: Mon, 18 Feb 2002 15:16:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: "'Fairlie-Cuninghame, Robert'" , "'sip@ietf.org'" Subject: Re: [Sip] Event ID (was RE: Events Last Call.) References: <9BF66EBF6BEFD942915B4D4D45C051F3630069@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline. Adam Roach wrote: > > > The Event id parameter seems to add a lot of complication to > > the draft - why was it added ? > > There's a rather ugly problem we're trying to solve, and it's > probably been the hardest thing to get to work correctly in the > whole sip-events draft. > > The basic setup is this: I'm in an INVITE-initiated session with > you. That INVITE transaction set up a dialog with a route path > and other goodies that make sure that subsequent requests from > me to you end up on exactly the same UA on your end, and that > subsequent requests from you to me end up on exactly the same UA > on my end. Now, for whatever reason, you want to subscribe to > some resource state relating exactly to the terminal that your > INVITE landed on. How do you do this? > > You can't use the contact, since the user-portion may very well > contain state information that isn't valid outside the dialog. > You can't just copy the route set for this reason and the additional > reason that proxies may have done the same sort of trick with the > user portion of URIs in the route set. Indeed, the spec only requires that the scope of the URI in the record-route be within the dialog. THat is actually not true for contact, which need to be globally scoped, in order to enable transfer, for example. > But there's one more scary, ugly problem: what if we need to send > *two* subscriptions down this same dialog? In the sunshine case, > you can perform demultiplexing based on the event package name. > But let's imagine that there's an event package that defines a > body for the SUBSCRIBE message. This body gives a filter for > what types of events we want to know about. It is quite possible > that the easiest (or only) way to subscribe to the events I'm > interested in would be to install two subscriptions to the same > package with different filter criteria. But when I get a NOTIFY > back, how on earth am I going to be able to tell which subscriptoin > it corresponds to? There is a bigger issue here, one we are beginning to scratch the surface of. We will only (and should only) touch it a little in bis, but it is something that requires much more thought. A subject for draft standard, I think. The issue is that we are realizing that there is a great deal of value in very cleanly separating the SIP state from the state of the things established through it. One such case is the session. Our big pain with early media was trying to couple sip state (whcih drives applications and services) with the sesison state. One of the ideas in UNIFY that vastly simplified the problem was to view them as separate things. Now, the same is true for a subscription. Its state exists as a separate thing from the sip state. The problem we are running into here is that we want one sip dialog to effectively act as a "conduit" for several "application layer" state processing, such as a subscription or a session. SIP has never had a clean separation between these layers, either in management of state, or separation of header functionality. I think others have made this observation as well, including Dean. So, for now, we just need to make sure we've got separate identifiers for these things (we've always had it for sessions; the SDP has a session ID), and make sure the lifetimes are well specified, even if mangled a bit. -08 of bis does a much better job of this; I've rewritten the terminate.tex section such that it really views BYE as termination of the sesison, not the dialog (of course, termination of the session implies termination of the dialog, unless an extension, like subscribe, put others application state within the dialog). So, the functional behavior is unchanged, but the presentation is more consistent with the proper split, I think. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Mon Feb 18 15:40:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17351 for ; Mon, 18 Feb 2002 15:40:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11133 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 15:40:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09649; Mon, 18 Feb 2002 15:18:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09546 for ; Mon, 18 Feb 2002 15:18:04 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16686 for ; Mon, 18 Feb 2002 15:17:59 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Mon, 18 Feb 2002 12:16:57 -0800 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Feb 2002 12:17:31 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Feb 2002 12:16:56 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Feb 2002 12:16:56 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Mon, 18 Feb 2002 12:14:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] re: SMIME in SIP Date: Mon, 18 Feb 2002 12:14:51 -0800 Message-ID: Thread-Topic: [Sip] re: SMIME in SIP thread-index: AcG3vBtyTde5gUMCTXWALs45SUut+QA/LBCw From: "Christian Huitema" To: "Ofir Arkin" , "Rohan Mahy" Cc: , X-OriginalArrivalTime: 18 Feb 2002 20:14:51.0427 (UTC) FILETIME=[EBE59730:01C1B8B8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA09548 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > > UDP doesn't work well in the Internet at large anyway. It's support is > > still around for backwards compatibility, and for use in specialized > > layer2 domains where RTT is expensive; these domains usually run what > > amounts to a private network. IPsec is probably a good thing in those > > networks, and the spec allows for that. > > > Umm, DNS? Streaming Media? Actually, SIP's traffic is more analogous to DNS than to streaming media and, yes, DNS does not work well. See http://www.huitema.net/papers/NetMeasureV2.doc for the gory details. Streaming is a different problem -- if you have a constant stream of packet, you can use redundancy or FEC to cope with losses of packets. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 18 15:40:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17414 for ; Mon, 18 Feb 2002 15:40:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11176 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 15:40:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09875; Mon, 18 Feb 2002 15:22:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09844 for ; Mon, 18 Feb 2002 15:22:04 -0500 (EST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16763 for ; Mon, 18 Feb 2002 15:21:58 -0500 (EST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Mon, 18 Feb 2002 12:20:56 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Feb 2002 12:20:56 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Feb 2002 12:20:55 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Feb 2002 12:20:55 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Mon, 18 Feb 2002 12:18:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] SIP-TLS Travesty (another perspective) Date: Mon, 18 Feb 2002 12:18:50 -0800 Message-ID: Thread-Topic: [Sip] SIP-TLS Travesty (another perspective) thread-index: AcG4TcMVS/cVb3q7RTeA3RtOz7m3hAAa+UEw From: "Christian Huitema" To: "Danyuu Wuu" , X-OriginalArrivalTime: 18 Feb 2002 20:18:50.0998 (UTC) FILETIME=[7AB13960:01C1B8B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA09845 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Here is what I don't seem to understand about SIP > and TLS. SIP is trying to make TLS a 'MUST'. > I feel this prevents individuals from hosting > their own SIP domains. One has to go through hoops > to get a certificate from Verisign etc. etc. > Actually as an individual you simply cannot get a > security certificate (type 3?). Even as a business > there are some requirements before a cert is issued. > Once issued you must pay $400/year maintenance fees. Does not have to be so -- there are multiple certification authorities. Besides, if you use S/MIME, you also need a certificate... -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 18 15:52:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17882 for ; Mon, 18 Feb 2002 15:52:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11514 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 15:52:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10507; Mon, 18 Feb 2002 15:30:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10456 for ; Mon, 18 Feb 2002 15:30:15 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16982 for ; Mon, 18 Feb 2002 15:30:10 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1IKTh003006; Mon, 18 Feb 2002 14:29:43 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4SHF>; Mon, 18 Feb 2002 14:29:38 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF75@VA02> From: "Peterson, Jon" To: "'Christian Huitema'" Cc: sip@ietf.org Subject: RE: [Sip] SMIME in SIP Date: Mon, 18 Feb 2002 14:29:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org One note below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Monday, February 18, 2002 12:09 PM > To: cmartin@dasecurenetworks.com; Michael Thomas > Cc: Rohan Mahy; sip@ietf.org > Subject: RE: [Sip] SMIME in SIP > [snip] > > However, if we want to use TLS seriously, we need to resolve a security > issue that is caused by the use of SRV records as specified in > draft-ietf-sip-srv-04.txt. In short, DNS records can be spoofed. A > hacker can manage to spoof the SRV record for "_sip._tls.microsoft.com" > to point to "hackers-are-us.tv", thus intercepting all the SIP traffic > to Microsoft. The basic usage of TLS will only guarantee that the name > to address mapping is genuine, i.e. that the target is really the > authorized server for "hackers-are-us.tv", but that will not make us a > whole lot of good. So, when we say "check the certificate", we should > really check for a link to the initial domain, pre-SRV. We hope that the new SIPS mechanism can help to address the DNS attack problem; it has been integrated into sip-srv-05. Also, if you look at the security solutions in bis07 (specifically 22.3.2.2), we recommend exactly the reference integrity check you describe above - that when you check the certificate of a remote party in a transaction, that you compare the identity/hostname asserted by the certificate with the resource you are attempting to contact. > > -- Christian Huitema > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Mon Feb 18 15:55:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17945 for ; Mon, 18 Feb 2002 15:55:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11597 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 15:55:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10708; Mon, 18 Feb 2002 15:30:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10677 for ; Mon, 18 Feb 2002 15:30:42 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16996 for ; Mon, 18 Feb 2002 15:30:36 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1IKU9E18488; Mon, 18 Feb 2002 12:30:09 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX33731; Mon, 18 Feb 2002 12:29:40 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA29192; Mon, 18 Feb 2002 12:30:08 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15473.25680.100368.520615@thomasm-u1.cisco.com> Date: Mon, 18 Feb 2002 12:30:08 -0800 (PST) To: "Christian Huitema" Cc: , "Michael Thomas" , "Rohan Mahy" , Subject: RE: [Sip] SMIME in SIP In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian Huitema writes: > In fact, we should seriously consider that we reverse the priorities > between transport: make TLS a MUST, at least for proxies; make TCP a > SHOULD and make UDP a MAY. In fact, I would argue for a "SHOULD NOT > support UDP, at least in the absence of IPSEC. There are just way too > many ways to attack a UDP based system -- spoof the source address of a > proxy and send whatever you wish to the UA, spoof the source address of > a third party and mount a denial of service attack against a proxy, etc. Thus far, arguments about the insecurity of UDP have been falling on deaf ears. I have proposed that either we deprecate UDP or we endorse IPsec. Instead, we've been told that digest authentication is adequate for UDP. I kid you not. 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 daemon@optimus.ietf.org Mon Feb 18 15:55:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17984 for ; Mon, 18 Feb 2002 15:55:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11625 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 15:55:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10188; Mon, 18 Feb 2002 15:25:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10150 for ; Mon, 18 Feb 2002 15:25:17 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16842 for ; Mon, 18 Feb 2002 15:25:11 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1IKOYZ18955; Mon, 18 Feb 2002 12:24:34 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX33670; Mon, 18 Feb 2002 12:24:15 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA29188; Mon, 18 Feb 2002 12:24:42 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15473.25354.832878.276438@thomasm-u1.cisco.com> Date: Mon, 18 Feb 2002 12:24:42 -0800 (PST) To: "Christian Huitema" Cc: "Ofir Arkin" , "Rohan Mahy" , , Subject: RE: [Sip] re: SMIME in SIP In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian Huitema writes: > Actually, SIP's traffic is more analogous to DNS than to streaming media > and, yes, DNS does not work well. See > http://www.huitema.net/papers/NetMeasureV2.doc for the gory details. Well, I don't get it. Why is it that MGCP used UDP? And I seem to recall Van speaking up in Oslo during MEGACO saying that using UDP and ALF was not only OK, but a Good Thing. 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 daemon@optimus.ietf.org Mon Feb 18 16:02:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18149 for ; Mon, 18 Feb 2002 16:02:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12211 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 16:02:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11269; Mon, 18 Feb 2002 15:41:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11234 for ; Mon, 18 Feb 2002 15:40:58 -0500 (EST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17455 for ; Mon, 18 Feb 2002 15:40:55 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Mon, 18 Feb 2002 12:39:53 -0800 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Feb 2002 12:39:53 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Feb 2002 12:39:53 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Feb 2002 12:39:52 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Mon, 18 Feb 2002 12:37:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] re: SMIME in SIP Date: Mon, 18 Feb 2002 12:37:47 -0800 Message-ID: Thread-Topic: [Sip] re: SMIME in SIP thread-index: AcG4ufQ+aU2/LjJ6SU2ANmdrsGWuQQAAOGtw From: "Christian Huitema" To: "Michael Thomas" Cc: "Ofir Arkin" , "Rohan Mahy" , X-OriginalArrivalTime: 18 Feb 2002 20:37:48.0056 (UTC) FILETIME=[206E8180:01C1B8BC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA11235 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Christian Huitema writes: > > Actually, SIP's traffic is more analogous to DNS than to streaming > media > > and, yes, DNS does not work well. See > > http://www.huitema.net/papers/NetMeasureV2.doc for the gory details. > > Well, I don't get it. Why is it that MGCP used > UDP? And I seem to recall Van speaking up in Oslo > during MEGACO saying that using UDP and ALF was > not only OK, but a Good Thing. UDP & ALF relate to the possibility to tie the network behavior closely with the application priorities, e.g. to not retransmit messages that are now obsolete, to replace retransmissions by summaries of the new state, etc. This is OK, if you can verify two hypotheses: 1) that there is a long term association between the two parties, so you can build up some resiliency mechanism in the exchange; 2) that you have some form of underlying security to provide protection against spoofing attacks. Number (1) is true for MGCP, since there is a long term association between the gateway and the controller. Deploying MGCP without some response to (2) is indeed insecure. Neither hypothesis is true for DNS: packets pop out of the blue from random locations; you suffer from the Internet wide packet loss rate of about 3%, and have no better way to cope than coarse timer retransmission; source and response spoofing can be used in all kinds of attacks. We can argue that this is a necessary evil in the case of DNS, be we don't have to by that for SIP. We could argue that there hypothesis (1) is verified between a UA and the local proxy, but you will still need security; in the case of random proxy-proxy exchanges, neither hypothesis stands, so you really want to use security + reliability, hence TLS. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 18 16:22:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19027 for ; Mon, 18 Feb 2002 16:22:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13056 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 16:22:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12084; Mon, 18 Feb 2002 16:00:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12038 for ; Mon, 18 Feb 2002 16:00:43 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18077 for ; Mon, 18 Feb 2002 16:00:40 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 18 Feb 2002 21:00:57 UT Received: from jolaptop ([80.3.216.239]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Mon, 18 Feb 2002 21:02:53 +0000 From: "Jo Hornsby" To: "Jonathan Rosenberg" , Subject: RE: [Sip] Note: minor change in transaction ID Date: Mon, 18 Feb 2002 21:04:33 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3C715B5B.81B97BDA@dynamicsoft.com> X-OriginalArrivalTime: 18 Feb 2002 21:02:54.0043 (UTC) FILETIME=[A211E2B0:01C1B8BF] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Bis-08 will reflect a minor change in the way transaction matching > is done. The current text in -07 basically uses the combination of > the branch ID and source address/port as a transaction ID. We > decided to use the two, rather than branch ID alone, to help avoid > collisions between branch IDs from different proxies, whether > intentionally or maliciously. > > Usage of the actual source address has some problems, however: > > 1. For SCTP, the sender can switch between multiple interfaces when > sending, 2. It is possible that a routing change could alter the > choice of the source interface for sending a request, at a proxy > that is running ontop of a routing process (like gated) which is > commonly done. > > The use of network addresses from packets as identifiers is, generally > speaking, plagued with such problems, are we are best advised to > avoid them. > > SO, instead, the transaction ID will be based on the branch ID and the > value of the sent-by parameter of the top Via. This has similar > spacial uniqueness properties as the source address, but SIP > mandates its consistency throughout a transaction, thus avoiding > many of the pitfalls above. Hmmm.... I wonder if it might be worth mentioning that a proxy may use other [meta]data, too. For instance, if it were to key based on branch ID and sent-by and local port (that the request was received over), for instance, then it would be impossible for a rogue proxy to screw-up another proxy's transaction when using e.g., TCP and TLS, right? In fact, in such a case, I guess that the sent-by doesn't even matter. I'm not sure how of a problem being able to "hide" requests is; that is, how useful it would be for an attacker in practice. However, it doesn't seem too harmful to allow an extra degree of freedom. The only problem I can see with such an approach is with ol' CANCEL and ACK, such that I guess it's not technically illegal that these could be received over a different "connection". But I can't see that would be difficult to work around. In any case, it's perhaps slightly suspicious that an upstream element would be doing such a thing. > I also made the branch ID unique in space and time, rather than just > time, as was mandated by -07. The reasons it that the sent-by field > might contain a cluster address, and thus the requests from each > proxy in the cluster would contain the same sent-by value, > potentially. I think this property is very useful and very > important. Indeed. And realistically, it's generally not-a-lot of effort to move from uniqueintime to uniqueinspaceandtime. A prefix of "potato" normally works, IMHO. &:) - Jo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 18 16:33:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19326 for ; Mon, 18 Feb 2002 16:33:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13780 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 16:33:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12349; Mon, 18 Feb 2002 16:05:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12320 for ; Mon, 18 Feb 2002 16:05:16 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18277 for ; Mon, 18 Feb 2002 16:05:12 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1IL4XI03186; Mon, 18 Feb 2002 15:04:33 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <19H22T8L>; Mon, 18 Feb 2002 15:04:33 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187908@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jonathan Rosenberg'" Cc: sip@ietf.org Subject: RE: [Sip] use of TCP in bis07 Date: Mon, 18 Feb 2002 15:04:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B8BF.DC812500" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B8BF.DC812500 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sanjoy Sen wrote: > > > > lines 3587-3590: If a request is within 500 bytes of the > path MTU, or if > > it is larger > > than 1000 bytes when the path MTU is unknown, it MUST be > sent using > > TCP. This is to prevent fragmentation of messages over > UDP, and to > > provide congestion control for larger messages. > > > > Although I agree with the intent, this would force > terminals to use TCP > > in many cases - this may not be suitable for many smaller mobile > > terminals. This should be relaxed from MUST to SHOULD. > > That is not acceptable based on IESG feedback on this question > specifically. I think that is a fair position; we really want to make > sure TCP is used for messages that would otherwise fragment. > Why is using UDP for any request message < MTU, and using TCP for transmitting the response if the response > MTU, not acceptable? ------_=_NextPart_001_01C1B8BF.DC812500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] use of TCP in bis07

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>
> Sanjoy Sen wrote:
> >
> > lines 3587-3590: If a request is within = 500 bytes of the
> path MTU, or if
> > it is larger
> >    than 1000 bytes when the = path MTU is unknown, it MUST be
> sent using
> >    TCP. This is to prevent = fragmentation of messages over
> UDP, and to
> >    provide congestion = control for larger messages.
> >
> > Although I agree with the intent, this = would force
> terminals to use TCP
> > in many cases - this may not be suitable = for many smaller mobile
> > terminals. This should be relaxed from = MUST to SHOULD.
>
> That is not acceptable based on IESG feedback = on this question
> specifically. I think that is a fair position; = we really want to make
> sure TCP is used for messages that would = otherwise fragment.
>
Why is using UDP for any request message < MTU, = and using TCP for transmitting the response if the response > MTU, = not acceptable?

 
 

------_=_NextPart_001_01C1B8BF.DC812500-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 18 16:33:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19345 for ; Mon, 18 Feb 2002 16:33:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13794 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 16:33:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12257; Mon, 18 Feb 2002 16:03:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12227 for ; Mon, 18 Feb 2002 16:03:15 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18173 for ; Mon, 18 Feb 2002 16:03:11 -0500 (EST) Received: (qmail 14501 invoked from network); 18 Feb 2002 21:06:30 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 18 Feb 2002 21:06:30 -0000 Received: from stake.com (unknown [10.1.64.73]) by cam-relay.atstake.com (Postfix) with SMTP id DB08E22817; Mon, 18 Feb 2002 16:02:25 -0500 (EST) Message-ID: <3C716D02.8070802@stake.com> Date: Mon, 18 Feb 2002 21:07:14 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christian Huitema Cc: cmartin@dasecurenetworks.com, Michael Thomas , Rohan Mahy , sip@ietf.org Subject: Re: [Sip] SMIME in SIP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian, Let's examine several things here: TLS and DNS Reverse Lookup What we need with TLS is a DNS Reverse Lookup so we will be able to determine that the IP address which generated the traffic (or the presumable target) is really sip.microsoft.com (in your case) and not some other domain. This is futile when the malicious party poisoned the DNS you query for both for name to IP and for IP to name records. But it is another check missing from our specs. As well as a MUST for verifying certificates for a client. No UDP Any More? UDP is not secure, and nothing will make it secure with the current offered standard. What is wired for me is that UDP was the winning transport protocol and suddenly TCP made a remarkable comeback... So decide what you want to do, just remember the TCP has it's own weirdness. Don't come running when implementing TCP in large scale networks will be problematic... Slow start, retransmit, more time to bill the user and any other nice things. Let the user's discover they pay too much (1-several seconds more) for each call, cause miracle happen. I am not saying there is something else to do with UDP here, but the way all try to justify TCP. And I cannot finish without S/MIME rent: Another little note for S/MIME. In my opinion it might be useless in what it tries to do. If I wish to determine some details about your target, I will just connect to that host and send a BYE after the ACK. I will have all I need (as well as the IP for the peer-to-peer, etc). So what are we trying to defend here?... BTW - I might gain that info from the RTP channel (YES I know that there are efforts to secure that as well - ENJOY). We need to encrypt everything not just parts... We need also to forget about pre-shared keys (god help me here). I will wait for the flames to come. I am getting use to it here :P P.S. 1 - UDP does work P.S. 2 - It is about time people will look at the bigger picture here. and if you are tired do not answer for the email... btw - sorry for the english. Enjoy Ofir Christian Huitema wrote: >>>4) TLS doesn't address UDP. IPsec WG is working on >>> NAT traversal >>> >>> >>Also will break firewall implementations, that have/are being >> > developed by > >>many well >>known vendors, to address SIP....would require that they also decrypt >> > to > >>peform >>pinhole allocation. Would most likely also affect SIP infrastructures >>already built >>today based on UDP if we must suddenly implement TCP based SIP (Would >> > have > >>actually >>been nice from the start). >> > > In fact, we should seriously consider that we reverse the priorities > between transport: make TLS a MUST, at least for proxies; make TCP a > SHOULD and make UDP a MAY. In fact, I would argue for a "SHOULD NOT > support UDP, at least in the absence of IPSEC. There are just way too > many ways to attack a UDP based system -- spoof the source address of a > proxy and send whatever you wish to the UA, spoof the source address of > a third party and mount a denial of service attack against a proxy, etc. > Using S/MIME for end-to-end security is certainly a very good idea, but > using TLS is probably the only secure solution that we can deploy right > now. > > However, if we want to use TLS seriously, we need to resolve a security > issue that is caused by the use of SRV records as specified in > draft-ietf-sip-srv-04.txt. In short, DNS records can be spoofed. A > hacker can manage to spoof the SRV record for "_sip._tls.microsoft.com" > to point to "hackers-are-us.tv", thus intercepting all the SIP traffic > to Microsoft. The basic usage of TLS will only guarantee that the name > to address mapping is genuine, i.e. that the target is really the > authorized server for "hackers-are-us.tv", but that will not make us a > whole lot of good. So, when we say "check the certificate", we should > really check for a link to the initial domain, pre-SRV. > > -- Christian Huitema > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 18 16:34:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19383 for ; Mon, 18 Feb 2002 16:34:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13824 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 16:34:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12465; Mon, 18 Feb 2002 16:09:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12429 for ; Mon, 18 Feb 2002 16:09:32 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18499 for ; Mon, 18 Feb 2002 16:09:28 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1IL98io025710; Mon, 18 Feb 2002 23:09:08 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15473.28020.463171.252308@harjus.eng.song.fi> Date: Mon, 18 Feb 2002 23:09:08 +0200 To: Michael Thomas Cc: "Christian Huitema" , , "Rohan Mahy" , Subject: RE: [Sip] SMIME in SIP In-Reply-To: <15473.25680.100368.520615@thomasm-u1.cisco.com> References: <15473.25680.100368.520615@thomasm-u1.cisco.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas writes: > Thus far, arguments about the insecurity of UDP > have been falling on deaf ears. I have proposed that > either we deprecate UDP or we endorse IPsec. Instead, > we've been told that digest authentication is adequate > for UDP. I kid you not. i fully support deprecating udp even in the presence of ipsec due to the message size problems. -- 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 daemon@ns.ietf.org Mon Feb 18 17:09:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20445 for ; Mon, 18 Feb 2002 17:09:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15527 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 17:09:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14293; Mon, 18 Feb 2002 16:49:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14262 for ; Mon, 18 Feb 2002 16:49:03 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19730 for ; Mon, 18 Feb 2002 16:48:58 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1ILmuio025746; Mon, 18 Feb 2002 23:48:56 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15473.30408.81990.382800@harjus.eng.song.fi> Date: Mon, 18 Feb 2002 23:48:56 +0200 To: "Sanjoy Sen" Cc: "'Jonathan Rosenberg'" , sip@ietf.org Subject: RE: [Sip] use of TCP in bis07 In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187908@zrc2c012.us.nortel.com> References: <933FADF5E673D411B8A30002A5608A0E01187908@zrc2c012.us.nortel.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sanjoy Sen writes: > Why is using UDP for any request message < MTU, and using TCP for > transmitting the response if the response > MTU, not acceptable? i asked this same question long time ago, i.e., why can't sip be transport independent. i don't remember the details why it didn't work, but it didn't. the answer can be found in the archives. -- 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 daemon@ns.ietf.org Mon Feb 18 17:14:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20607 for ; Mon, 18 Feb 2002 17:14:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15694 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 17:14:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14220; Mon, 18 Feb 2002 16:47:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14188 for ; Mon, 18 Feb 2002 16:47:39 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19687 for ; Mon, 18 Feb 2002 16:47:35 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1ILkxZ14519 for ; Mon, 18 Feb 2002 13:46:59 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACM63441; Mon, 18 Feb 2002 13:47:06 -0800 (PST) Date: Mon, 18 Feb 2002 13:45:45 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] comments on UPDATE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, comments on UPDATE below. I'm concerned about the Reason header. I think maybe we should put it in sip-events? Also the Requires header stuff bothers me. anyway... thanks, -rohan comments on UPDATE below: page 4 last para: ... the request is generally acceptable , the procedures ^ insert "or would result in a non-repairable error" page 5 paras 2 and 3: I think sending the Reason header is a MUST. This is being pulled out so that REFER can also reference it? Maybe this needs to go in bis or sip-events? page 5 para 4: i think the Require here is totally unnecessary and I would even go so far as to make it a MUST NOT or SHOULD NOT. page 6 para 7: i get no sense of why the UAS would repond with a session description in a 155. is this a 488? page 6 last sentence: please re-emphasize this last sentence in the offer/answer section section 6.2 2nd para: if the dialog state is non-existent there is no way to route the UPDATE to the UAS page 10, first para: I don't think you can do this. If the proxy sends the same request with a different branch, won't the UA still treat this as a retransmission? NITS: global: s/a Accept/an Accept/ page 2 2nd para: 1st sentence append: "while the dialog is still an early dialog" 2nd para: 3rd sentence s/call is answered/dialog is in the confirmed state/ 2nd para: last line s/call/dialog/ page 2 3rd para: s/ther/there/ and s/service at the proxy/forking service at the proxy/ page 2 4th para: s/before a response/before a final response/ page 4 3rd sentence: append "it" page 4 8th sentence: s/it is answered/the UPDATE request is answered/ page 4 2nd para from bottom: s/5.3.1 is performed/5.2.1 is performed/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 18 17:32:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21163 for ; Mon, 18 Feb 2002 17:32:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17021 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 17:32:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15675; Mon, 18 Feb 2002 17:13:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15642 for ; Mon, 18 Feb 2002 17:13:45 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20596 for ; Mon, 18 Feb 2002 17:13:40 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1IMDQio025770; Tue, 19 Feb 2002 00:13:30 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15473.31878.491755.490593@harjus.eng.song.fi> Date: Tue, 19 Feb 2002 00:13:26 +0200 To: "Miguel A. Garcia" Cc: Dean Willis , sip@ietf.org, roahn@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? In-Reply-To: <3C6FAF91.3F27DEE@ericsson.com> References: <011b01c1b65c$5b579f00$b3036e3f@dfw.dynamicsoft.com> <3C6FAF91.3F27DEE@ericsson.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Miguel A. Garcia writes: > > The basic requirements being met are to 1) allow a UA to REGISTER a > > contact which requires traversing a sequence of proxies on future > > messages between the registrar and the UA, with that sequence > > dynamically discovered during the REGISTER, why does it matter via which proxies (other than the UA's outbound proxy) the register message goes to the registrar? why can't the UA's outbound proxy add the desired source route to the messages? > > and 2) allow a UA to > > discover from a REGISTER response a sequence of proxies between it > > and a known proxy offering outbound services for that UA. why can't the UA learn its outboud proxy via regular means, such as dhcp? -- 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 daemon@ns.ietf.org Mon Feb 18 18:31:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23192 for ; Mon, 18 Feb 2002 18:31:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA19835 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 18:31:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18745; Mon, 18 Feb 2002 18:10:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18717 for ; Mon, 18 Feb 2002 18:10:03 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22518 for ; Mon, 18 Feb 2002 18:09:58 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1IN7UQl006363; Mon, 18 Feb 2002 18:07:31 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 18:09:32 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630072@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Fairlie-Cuninghame, Robert'" , "'sip@ietf.org'" Cc: Adam Roach Date: Mon, 18 Feb 2002 18:09:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Warnings headers in requests. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > Also, are Warnings restricted only to errors stemming from > application/sdp > message bodies. Is it reasonable for Warning's to be used for errors > stemming from other message body Content-Types? > > If so, given that a NOTIFY request is effectively the only > reliable response > to a SUBSCRIBE request, Warning headers should also be > allowed in NOTIFY > requests. [Here's another Last Call comment for you Adam. :)] I see no reason why "Warning" headers can't appear in NOTIFY requests. Accordingly, I've modified the table to allow this. Any objections should be raised at this time, as WGLC ends tomorrow. /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 daemon@ns.ietf.org Mon Feb 18 18:32:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23222 for ; Mon, 18 Feb 2002 18:32:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA19911 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 18:32:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18535; Mon, 18 Feb 2002 18:04:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18434 for ; Mon, 18 Feb 2002 18:04:17 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22187 for ; Mon, 18 Feb 2002 18:04:12 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1IN1iQl006328; Mon, 18 Feb 2002 18:01:45 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGHBW>; Mon, 18 Feb 2002 18:03:45 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630071@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Fairlie-Cuninghame, Robert'" , Adam Roach , "'sip@ietf.org'" Cc: Jonathan Rosenberg Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! Date: Mon, 18 Feb 2002 18:03:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > > - initial authorization failed > > > - authorization failed at a later time due to change > > > authorization policy > > > - Event resource does not exists > > > - Event resource no longer exists > > > > I believe a "reason" code could only conceivably cover the second > > and fourth cases. In the first and third cases, you would never > > get as far as a NOTIFY; the SUBSCRIBE would be answered with a > > suitable error code, and no NOTIFY would ever be sent. > > > > This assumes that authorization and resource location occurs > instantaneously > - which cannot be assumed. If either of these operations take > non-negligible > time then the Notifier MUST send an immediate NOTIFY (which > "Subscription-State: pending"). You therefore needs an > appropriate terminate > reason-code - the SUBSCRIBE response codes cannot be used for this. Going from "pending" (which means that authorization state is undefined -- user is neither authorized nor forbiddden) to "terminated" with reason of "rejected" (which means that authorization is forbidden) *is* a change in authorization state: from undefined to forbidden. /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 daemon@ns.ietf.org Mon Feb 18 18:34:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23322 for ; Mon, 18 Feb 2002 18:34:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA20022 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 18:34:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17925; Mon, 18 Feb 2002 18:00:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17871 for ; Mon, 18 Feb 2002 18:00:12 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22047 for ; Mon, 18 Feb 2002 18:00:04 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1IMvaQl006291; Mon, 18 Feb 2002 17:57:36 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGHBP>; Mon, 18 Feb 2002 17:59:37 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630070@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'James Undery'" , Adam Roach , sip@ietf.org Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! Date: Mon, 18 Feb 2002 17:59:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for the detailed comments. I've incorporated them, except as noted below. A few responses: > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > 5.3.2. 4th para. State Deltas if a subscriber has missed sequence > numbers surely the subscription will have been silently cancelled ala > 4.2.2. (Not sure this is a nit or me thinking aloud) Removal of a subscription on timeout is a SHOULD, not a MUST... so, the simple answer is "no." > 5.4.7. 1st para. It may be worth noting explicitly that "fake" or > "neutral" state information isn't required Actually, I think it is. The need to provide this sort of authentication hiding comes down more to a policy decision that will be made on a per-deployment basis than a package- related attribute that a package author can decide to neglect. > 6.1. s/user/resource/ (also section 3 might do with a consistent name > for the entity the state describes) Actually, we really mean user. Human. The person who owns the resource, not the resource itself. It's an important distinction. > 6.3. 3rd para. s/of notifiers/accepting subscriptions/ Notifiers is a defined term; we describe accepting SUBSCRIBE messages in the definition of a notifier. I think your suggested change would actually cause more confusion than it avoids. > 7. Ensure first bracketed sentence goes The actual e-mail address and policy for IANA registration will be decided by IANA review. Presumably, the disclaimer will be removed at that point in the process. Thanks for the reminder, though. > 7.4. Should Allow-Events be mandatory in 2xx responses to an OPTIONS Only sort of. When interacting with UAs not supporting SIP-Events, you won't see "Allow-Events" in OPTIONS responses. Putting an "m" in the table would imply a global change. > 7.4. Why isn't Accept "m*" for SUBSCRIBE Because not all event packages will define bodies for conveying state. > 4.6.1. Reference [4] rfc2616 might be a better choice Whoa! Good catch! I don't know how I got the obsoleted spec # in there... /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 daemon@ns.ietf.org Mon Feb 18 18:58:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23975 for ; Mon, 18 Feb 2002 18:57:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA20815 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 18:58:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19195; Mon, 18 Feb 2002 18:24:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19164 for ; Mon, 18 Feb 2002 18:24:42 -0500 (EST) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22900 for ; Mon, 18 Feb 2002 18:24:37 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 15:24:36 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Adam Roach'" Cc: "'sip@ietf.org'" Date: Mon, 18 Feb 2002 15:24:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Event ID (was RE: Events Last Call.) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Adam, Thank you for the explanation on the design purpose for the Event header Id parameter. I wonder though if this seems to be running in the same direction that transporting DTMF in INFO was heading - catering only to application servers which are B2BUA's. Why should B2BUA's get special treatment? Surely this is only encouraging them - if you want to make sure that a SUBSCRIBE works then your applications server should be a B2BUA. What if a proxy on an INVITE dialog wants to subscribe? Now I don't think this is necessarily contrary to the Id parameter but the way you justify the complexity added by the Id parameter scares me. Basically, if you are solving the problem for an UA endpoint delivering a subscription through an existing INVITE dialog then IMO you must also address how a proxy can also accomplish this in an equally guaranteed manner. I will say it again, otherwise the only reliable way application developers have of **reliably** creating a subscription that is associated to an INVITE-initiated dialog is to build their server as a B2BUA. [Actually I believe that in most cases you actually want to associate the subscription to the user endpoint's conversation-space rather than to the INVITE-dialog itself ... but that's a whole different email and is largely independent to how the SUBSCRIBE is delivered. :)] So, yes, it's a little messy but not too conceptually difficult and REALLY, REALLY needs to be done to avoid huge headaches when people start trying to use advanced call control primitives and multiple application interactions with B2BUA's. [all part of Jonathan's big ball of pain] That's my view at any rate - we really don't want to encourage B2BUA's anymore than we have to. :) Regards, Robert. > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 18 February 2002 19:36 > To: 'Fairlie-Cuninghame, Robert' > Cc: 'sip@ietf.org' > Subject: Event ID (was RE: Events Last Call.) > > > Copying SIP mailing list... > > > -----Original Message----- > > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > > > The Event id parameter seems to add a lot of complication to > > the draft - why was it added ? > > There's a rather ugly problem we're trying to solve, and it's > probably been the hardest thing to get to work correctly in the > whole sip-events draft. > > The basic setup is this: I'm in an INVITE-initiated session with > you. That INVITE transaction set up a dialog with a route path > and other goodies that make sure that subsequent requests from > me to you end up on exactly the same UA on your end, and that > subsequent requests from you to me end up on exactly the same UA > on my end. Now, for whatever reason, you want to subscribe to > some resource state relating exactly to the terminal that your > INVITE landed on. How do you do this? > > You can't use the contact, since the user-portion may very well > contain state information that isn't valid outside the dialog. > You can't just copy the route set for this reason and the additional > reason that proxies may have done the same sort of trick with the > user portion of URIs in the route set. > > So, what's the solution? As Rohan suggested, you can re-use the > same dialog that was created by the INVITE. Problem solved. > You just send the SUBSCRIBE on the dialog -- which includes the > same route-set and same contact -- and you hit the same UA. But > this ends up meaning that you need to be extremely careful about > how you define dialog termination. Does the dialog terminate when > the BYE comes across, as bis has (until recently) said? That would > be bad -- what if one of the events yet to be reported is some > sort of end-of-call statistics? > > So, after much discussion, arguing, and heartburn with a variety > of people (including a discussion during my presentation in SLC), > we determined that the only reasonable thing to do would be that > termination of the last "thing" in a dialog would terminate the > dialog. So, we added language to bis to say that BYE doesn't > *necessarily* terminate the dialog, and a lengthy discussion in > sip-events to talk about dialog lifetimes. > > To summarize, we need to be able to send SUBSCRIBEs on existing > dialogs so that we can reach the same terminal that the dialog > "connects" us to. So far, so good. > > But there's one more scary, ugly problem: what if we need to send > *two* subscriptions down this same dialog? In the sunshine case, > you can perform demultiplexing based on the event package name. > But let's imagine that there's an event package that defines a > body for the SUBSCRIBE message. This body gives a filter for > what types of events we want to know about. It is quite possible > that the easiest (or only) way to subscribe to the events I'm > interested in would be to install two subscriptions to the same > package with different filter criteria. But when I get a NOTIFY > back, how on earth am I going to be able to tell which subscriptoin > it corresponds to? > > The answer we came up with was the "id" parameter. It uniquely > identifies a subscription within a dialog. It's easy to implement, > not really that confusing, and finally ties up the huge barrel of > worms we opened up seven paragraphs ago. > > /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 daemon@ns.ietf.org Mon Feb 18 18:58:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23993 for ; Mon, 18 Feb 2002 18:58:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA20835 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 18:59:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19878; Mon, 18 Feb 2002 18:31:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19847 for ; Mon, 18 Feb 2002 18:31:38 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23208 for ; Mon, 18 Feb 2002 18:31:33 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1INT5Ql006550; Mon, 18 Feb 2002 18:29:05 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGHCK>; Mon, 18 Feb 2002 18:31:06 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630074@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Fairlie-Cuninghame, Robert'" , Adam Roach Cc: "'sip@ietf.org'" Date: Mon, 18 Feb 2002 18:31:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Event ID (was RE: Events Last Call.) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > Now I don't think this is necessarily contrary to the Id > parameter but the > way you justify the complexity added by the Id parameter scares me. > Basically, if you are solving the problem for an UA endpoint > delivering a > subscription through an existing INVITE dialog then IMO you must also > address how a proxy can also accomplish this in an equally guaranteed > manner. I hat B2BUAs at least as much as you do, and fully understand your objection. As soon as you propose something that works, I'll incorporate it. /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 daemon@ns.ietf.org Mon Feb 18 18:59:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24015 for ; Mon, 18 Feb 2002 18:59:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA20853 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 18:59:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19951; Mon, 18 Feb 2002 18:32:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19923 for ; Mon, 18 Feb 2002 18:32:51 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23239 for ; Mon, 18 Feb 2002 18:32:46 -0500 (EST) Received: from DWILLISS1 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1INWGB22745; Mon, 18 Feb 2002 17:32:17 -0600 Message-ID: <01d201c1b8d4$7bfc89d0$f1029bd4@DWILLISS1> From: "Dean Willis" To: "EKR" Cc: References: <70565611B164D511957A001083FCDD56CAAF3D@VA02> <15469.10196.338294.88758@thomasm-u1.cisco.com> <15469.12740.716729.637034@thomasm-u1.cisco.com> <15469.15321.73192.780819@thomasm-u1.cisco.com> <15469.27332.878903.549127@thomasm-u1.cisco.com> <01b101c1b6b8$45dc7cc0$8a1b6e0a@arenanet.fi> Subject: RPID signing improvement inspiration (Re: [Sip] 'sips' URI scheme (comments on proposal?)) Date: Mon, 18 Feb 2002 17:32:05 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric said: > (III) Anti-replay protection and challenges. . . . > However, it would be relatively straightforward to adapt the > Digest prompting and anti-replay mechanisms to S/MIME. You know, if we added this same anti-replay mechanism to the signature I've been proposing on RPID (possibly along with the inetgrity-protection fom enhanced digest), we'd fix the whole RPID signing security problem! Conversely, is it appropriate to solve the RPID problem with another S/MIME body? Would the S/MIME body need to be evaluated by proxies? I suspect that parsing and evaluation of S/MIME bodies on SIP messages would by a two-order-of-magnitude performance hit on SIP proxies, relative to a simple header approach. -- 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 daemon@ns.ietf.org Mon Feb 18 19:13:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24292 for ; Mon, 18 Feb 2002 19:13:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA21840 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 19:13:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20527; Mon, 18 Feb 2002 18:50:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20497 for ; Mon, 18 Feb 2002 18:50:46 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23738 for ; Mon, 18 Feb 2002 18:50:41 -0500 (EST) Received: from DWILLISS1 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1INnhB22850; Mon, 18 Feb 2002 17:49:43 -0600 Message-ID: <020101c1b8d6$ec426190$f1029bd4@DWILLISS1> From: "Dean Willis" To: "EKR" , "Ofir Arkin" Cc: "Michael Thomas" , "Rohan Mahy" , References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <15470.58825.137948.175526@thomasm-u1.cisco.com> <3C6EF34B.5050904@stake.com> Subject: Trust the Client? Sortof (Re: [Sip] SMIME in SIP) Date: Mon, 18 Feb 2002 17:49:32 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit EKR asks: > Ofir Arkin writes: > > 4. There is no client security, and we NEVER need to trust the client side. > Huh? No known cryptographic system does not require some trust on > the client side, at least to protect the symmetric encryption keys. This generally means that one can expect the client to run malicious code, for example probing with dictionary attack to find other people's keys, running known plain-text attacks, and so on. They're users, with a financial incentive. Money and prestige are on the table. That makes them vicious and clever. On the other hand, you can at least HOPE that they won't give away their secrets, because there is no direct financial incentive. On the gripping hand, they usually have holes that enable third parties to steal their secrets, which they wish to do because of similar financial incentives. Witness the push for smart-card authentication techniques that combine "something known" with "something owned". 3GPP security assumes that the client software outside of the SIM card is fundamentally evil and that ever hacker has a spare supecomputer to play with, but not a tunneling electroscope. That is, they trust only the vendor-supplied SIM card, not the rest of the software in a phone. -- Dean -- 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 daemon@ns.ietf.org Mon Feb 18 19:13:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24312 for ; Mon, 18 Feb 2002 19:13:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA21862 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 19:13:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20125; Mon, 18 Feb 2002 18:36:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20081 for ; Mon, 18 Feb 2002 18:36:32 -0500 (EST) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23371 for ; Mon, 18 Feb 2002 18:36:26 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 15:36:26 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Adam Roach'" , "'sip@ietf.org'" Cc: Jonathan Rosenberg Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! Date: Mon, 18 Feb 2002 15:36:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > > I believe a "reason" code could only conceivably cover the second > > > and fourth cases. In the first and third cases, you would never > > > get as far as a NOTIFY; the SUBSCRIBE would be answered with a > > > suitable error code, and no NOTIFY would ever be sent. > > > > > > > This assumes that authorization and resource location occurs > > instantaneously > > - which cannot be assumed. If either of these operations take > > non-negligible > > time then the Notifier MUST send an immediate NOTIFY (which > > "Subscription-State: pending"). You therefore needs an > > appropriate terminate > > reason-code - the SUBSCRIBE response codes cannot be used for this. > > Going from "pending" (which means that authorization state > is undefined -- user is neither authorized nor forbiddden) to > "terminated" with reason of "rejected" (which means that > authorization is forbidden) *is* a change in authorization > state: from undefined to forbidden. > Adam, Two cases: * using "rejected" due to the failure of authorization: sure it is a change in authorization _state_ but the description for "rejected" says that the error-reason is used when there is a change in authorization _policy_. I'm sure you can justify this by your definition of authorization policy but I think it is confusing and should be reworded to more clearly state that "rejected" also covers the initial authorization failure case. * using "rejected" to cover unavailable/non-existing resource: I think this is just plain wrong. It has nothing to do with authorization policy; resubscribing with new credentials will not improve the situation - the resource is unavailable. Hence, my proposal to introduce the "noresource" error-reason. Subscriber response codes are not sufficient as resource location is not necessarily a synchronous operation. Cheers, Robert. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 18 19:21:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24507 for ; Mon, 18 Feb 2002 19:21:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA22113 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 19:21:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20787; Mon, 18 Feb 2002 18:56:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20757 for ; Mon, 18 Feb 2002 18:56:52 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23948 for ; Mon, 18 Feb 2002 18:56:46 -0500 (EST) Received: from DWILLISS1 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1INuIB22910; Mon, 18 Feb 2002 17:56:18 -0600 Message-ID: <022f01c1b8d7$d7954d10$f1029bd4@DWILLISS1> From: "Dean Willis" To: "Miguel A. Garcia" Cc: , , , References: <011b01c1b65c$5b579f00$b3036e3f@dfw.dynamicsoft.com> <3C6FAF91.3F27DEE@ericsson.com> Subject: Re: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? Date: Mon, 18 Feb 2002 17:56:06 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks. Although I would like to point out that this isn't "my" proposal -- I just took the liberty of writing down what I though 3GPP was asking for (although I think I might have made one tiny impovement in the process). Feel free to kick it around. It's not MY baby! In fact, if somebody (esp. from 3GPP, or one of the "service route" guys who also inspired it) wants to take over as editor, I'll happily consider offers. -- Dean ----- Original Message ----- From: "Miguel A. Garcia" To: "Dean Willis" Cc: ; ; ; Sent: Sunday, February 17, 2002 7:26 AM Subject: Re: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? > Hi Dean: > > I also agree with your proposals. I think we should take your document as a WG item. Definitely needed by 3GPP. > > /Miguel > > Dean Willis wrote: > > > > The document draft-willis-sip-path-01.txt introduces the Path extension header suggested by 3GPP in the Garcia 3GPP requirements draft in SIPPING. > > > > The basic requirements being met are to 1) allow a UA to REGISTER a contact which requires traversing a sequence of proxies on future messages between the registrar and the UA, with that sequence dynamically discovered during the REGISTER, and 2) allow a UA to discover from a REGISTER response a sequence of proxies between it and a known proxy offering outbound services for that UA. > > > > > > The approach taken in the draft generalizes the 3GPP requirements by allowing the sequences to be asymetric-- for example, the inbound and outbound sequences might traverse different proxies, or there might only be a sequence in one direction (A firewall proxy sits between UA and its registrar, but UA does not use the registrar for outbound services). > > > > I'd like to poll for three things: > > > > 1) Do we want to address the requirements raised by 3GPP? > > > > 2) Do we have a general consensus on something like the PATH header as an appopriate mechanism? > > > > 3) Is draft-willis-sip-path-01.txt a reasonable baseline document? > > > > If we have consensus on all three accounts, I propose to accept draft-willis-sip-path-01.txt as a working group document, and pursue future revisions as draft-ietf-sip.xx. > > > > If not, then please make a counterproposal. > > > > Opinions, please. > > > > -- > > Dean > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Mon Feb 18 19:21:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24533 for ; Mon, 18 Feb 2002 19:21:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA22135 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 19:21:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20710; Mon, 18 Feb 2002 18:55:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20681 for ; Mon, 18 Feb 2002 18:55:35 -0500 (EST) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23921 for ; Mon, 18 Feb 2002 18:55:30 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 15:55:26 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Adam Roach'" Cc: "'sip@ietf.org'" Date: Mon, 18 Feb 2002 15:55:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Event ID (was RE: Events Last Call.) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Adam, We did propose something in the key-events draft (draft-culpepper-key-events-00.txt) whereby a proxy extracts the Route set from the INVITE-initiated dialog for all hops between itself and the intended UA [Section 7.10]. It would need to be adapted to work with your sub-dialog approach (rather than as Pre-loaded Routes). It is a bit messy but I would rather have a slightly messy mechanism for proxies to create subscription sub-dialogs than for all application proxies to become B2BUA's!!! The goal of the mechanism is simply for proxies to ensure that the message gets to the right UA and that the UA can correlate the subscription as being delivered as a sub-dialog of the other dialog. Now handling the UA is easy - this can be done explicitly with headers at worst. The Route-snatching should take care of the proxies described in Section 7.10. Regards, Robert. PS. We are currently heavily reworking the draft to bring it into line with the new SIP Events draft (for instance the Applies-To header will be removed). > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 18 February 2002 23:31 > To: 'Fairlie-Cuninghame, Robert'; Adam Roach > Cc: 'sip@ietf.org' > Subject: RE: Event ID (was RE: Events Last Call.) > > > > -----Original Message----- > > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > > > Now I don't think this is necessarily contrary to the Id > > parameter but the > > way you justify the complexity added by the Id parameter scares me. > > Basically, if you are solving the problem for an UA endpoint > > delivering a > > subscription through an existing INVITE dialog then IMO you > must also > > address how a proxy can also accomplish this in an equally > guaranteed > > manner. > > I hat B2BUAs at least as much as you do, and fully understand your > objection. As soon as you propose something that works, I'll > incorporate it. > > /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 daemon@ns.ietf.org Mon Feb 18 19:22:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24626 for ; Mon, 18 Feb 2002 19:22:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA22174 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 19:22:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21394; Mon, 18 Feb 2002 19:04:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21348 for ; Mon, 18 Feb 2002 19:04:20 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24122 for ; Mon, 18 Feb 2002 19:04:16 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1J01lQl006765; Mon, 18 Feb 2002 19:01:47 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGHDG>; Mon, 18 Feb 2002 19:03:48 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630075@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Fairlie-Cuninghame, Robert'" , Adam Roach , "'sip@ietf.org'" Cc: Jonathan Rosenberg Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! Date: Mon, 18 Feb 2002 19:03:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > * using "rejected" due to the failure of authorization: sure > it is a change in authorization _state_ but the description for > "rejected" says that the error-reason is used when there is a > change in authorization _policy_. I'm sure you can justify this > by your definition of authorization policy but I think it is > confusing and should be reworded to more clearly state that > "rejected" also covers the initial authorization failure case. I don't want to put that language in there because it will cause more confusion than it avoids. People will be unclear about whether an unauthorized subscription should be refused with a 403 or created with a 2xx and then killed with a NOTIFY/terminated/refused. > * using "rejected" to cover unavailable/non-existing > resource: I think this > is just plain wrong. It has nothing to do with authorization policy; > resubscribing with new credentials will not improve the > situation - the > resource is unavailable. Hence, my proposal to introduce the > "noresource" > error-reason. Subscriber response codes are not sufficient as resource > location is not necessarily a synchronous operation. You need to take up this argument with Jonathan, not me. My #1 priority on the reason codes is to sync with watcherinfo. If you can get Jonathan to add it to watcherinfo, I'll add it to events. /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 daemon@ns.ietf.org Mon Feb 18 19:29:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24742 for ; Mon, 18 Feb 2002 19:29:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA22354 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 19:29:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21453; Mon, 18 Feb 2002 19:06:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21423 for ; Mon, 18 Feb 2002 19:06:07 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24137 for ; Mon, 18 Feb 2002 19:06:04 -0500 (EST) Received: from DWILLISS1 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1J05QB22971; Mon, 18 Feb 2002 18:05:26 -0600 Message-ID: <024001c1b8d9$1e9a7ea0$f1029bd4@DWILLISS1> From: "Dean Willis" To: "Juha Heinanen" , "Miguel A. Garcia" Cc: , , , References: <011b01c1b65c$5b579f00$b3036e3f@dfw.dynamicsoft.com><3C6FAF91.3F27DEE@ericsson.com> <15473.31878.491755.490593@harjus.eng.song.fi> Subject: Re: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? Date: Mon, 18 Feb 2002 18:05:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Juha Heinanen" To: "Miguel A. Garcia" Cc: "Dean Willis" ; ; ; ; Sent: Monday, February 18, 2002 4:13 PM Subject: Re: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? > Miguel A. Garcia writes: > > > > The basic requirements being met are to 1) allow a UA to REGISTER a > > > contact which requires traversing a sequence of proxies on future > > > messages between the registrar and the UA, with that sequence > > > dynamically discovered during the REGISTER, > > why does it matter via which proxies (other than the UA's outbound > proxy) the register message goes to the registrar? why can't the > UA's outbound proxy add the desired source route to the messages? It can, it it knows the route, without using the aproach described in this draft. The first-hop-default-local-outbound proxy can also use the technique described in this draft to learn the service route from the REGISTER response. This of course requires it to be a "registration stateful" proxy, which is probably appropriate in mobile environments using proxy-level sgnaling compression. > > > and 2) allow a UA to > > > discover from a REGISTER response a sequence of proxies between it > > > and a known proxy offering outbound services for that UA. > > why can't the UA learn its outboud proxy via regular means, such as > dhcp? It learns its first-hop default local outbound proxy from DHCP just fine. However, this occurs in the visited network, which one assumes has no knowledge of the services needed by the user in the user's home network. In the situation addressed by Path combined with loose routing, the user wants outbound services from some remote proxy (the "home proxy") , and it doesn't yet know what other proxies (there may be many more than one) must be traversed before its messages will get to the home proxy. -- Dean > -- 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 daemon@ns.ietf.org Mon Feb 18 19:30:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24784 for ; Mon, 18 Feb 2002 19:30:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA22705 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 19:31:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20637; Mon, 18 Feb 2002 18:53:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20612 for ; Mon, 18 Feb 2002 18:53:47 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23873 for ; Mon, 18 Feb 2002 18:53:41 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1INs6d11856; Mon, 18 Feb 2002 15:54:06 -0800 (PST) To: "Dean Willis" Cc: "Ofir Arkin" , "Michael Thomas" , "Rohan Mahy" , Subject: Re: Trust the Client? Sortof (Re: [Sip] SMIME in SIP) References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <15470.58825.137948.175526@thomasm-u1.cisco.com> <3C6EF34B.5050904@stake.com> <020101c1b8d6$ec426190$f1029bd4@DWILLISS1> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 18 Feb 2002 15:54:06 -0800 In-Reply-To: "Dean Willis"'s message of "Mon, 18 Feb 2002 17:49:32 -0600" Message-ID: Lines: 24 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org "Dean Willis" writes: > EKR asks: > > Ofir Arkin writes: > > > 4. There is no client security, and we NEVER need to trust the client > side. > > Huh? No known cryptographic system does not require some trust on > > the client side, at least to protect the symmetric encryption keys. > > This generally means that one can expect the client to run malicious code, > for example probing with dictionary attack to find other people's keys, > running known plain-text attacks, and so on. They're users, with a financial > incentive. Money and prestige are on the table. That makes them vicious and > clever. Yes, of course. This is part of the standard Internet threat model. However, this assumption is not well captured by saying you cannot trust the client. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@ns.ietf.org Mon Feb 18 19:36:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24943 for ; Mon, 18 Feb 2002 19:36:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA22942 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 19:36:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21601; Mon, 18 Feb 2002 19:07:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21493 for ; Mon, 18 Feb 2002 19:07:42 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24152 for ; Mon, 18 Feb 2002 19:07:38 -0500 (EST) Received: (qmail 15279 invoked from network); 19 Feb 2002 00:10:55 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 19 Feb 2002 00:10:55 -0000 Received: from stake.com (unknown [10.1.64.73]) by cam-relay.atstake.com (Postfix) with SMTP id 8C4D522817; Mon, 18 Feb 2002 19:07:17 -0500 (EST) Message-ID: <3C719855.2000301@stake.com> Date: Tue, 19 Feb 2002 00:12:05 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Willis Cc: EKR , Michael Thomas , Rohan Mahy , sip@ietf.org Subject: Re: Trust the Client? Sortof (Re: [Sip] SMIME in SIP) References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <15470.58825.137948.175526@thomasm-u1.cisco.com> <3C6EF34B.5050904@stake.com> <020101c1b8d6$ec426190$f1029bd4@DWILLISS1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit You completely misunderstood what I was saying. And I was not referring to the situation with Crypto. So next time before you shout and scream just read. Imagine the following in a Carrier SIP-Based Solution: Your SIP IP Phone/Softswitch is configured to use an outbound SIP Proxy through a manual configuration that a technician put in your phone. So, you are a lamer who does not understand too much in IP phones but you know how to read the manual. The carrier you are using is also a lame security aware one. So, you go to your manual, look up how you would change the configuration (G no vendor can lock the damn configuration file - Oh G we need to add that), and change your outbound proxy to your friends IP address. G. Another example, you are a smart guy who understand how stuff work. You do not wish to go through the SIP Proxy, but the Record-Route header is written... Just reprogram your softwitch to erase that line when you generate further signaling (of course if you are looking for IP based fraud you need to look at other things as well... as the actual data on the wire - if you are from the fraud side). Now, if you use TLS and you use certificate and validate then for BOTH the server and the CLIENT than we are 95% on the safe side. If you use TLS like the bis-7 suggest and the client is not validating the certificate you are not doing anything... If you need further more explanations, tutorials, understandings I will be more than willing to explain. All I see here is people miss understand what is about security and who you do not need to trust. Secure signaling between proxies is good idea but we need not forget the clients. What if I am able to mangle anything between an IP Phone to the Gateway - Use your imagination brother. If you cannot understand that if someone gets to the wire especially when you are not encrypting... G wiz. I do not thing I am THAT stupid. Enjoy your evening Ofir Dean Willis wrote: > EKR asks: > >>Ofir Arkin writes: >> >>>4. There is no client security, and we NEVER need to trust the client >>> > side. > >>Huh? No known cryptographic system does not require some trust on >>the client side, at least to protect the symmetric encryption keys. >> > > This generally means that one can expect the client to run malicious code, > for example probing with dictionary attack to find other people's keys, > running known plain-text attacks, and so on. They're users, with a financial > incentive. Money and prestige are on the table. That makes them vicious and > clever. > > On the other hand, you can at least HOPE that they won't give away their > secrets, because there is no direct financial incentive. On the gripping > hand, they usually have holes that enable third parties to steal their > secrets, which they wish to do because of similar financial incentives. > Witness the push for smart-card authentication techniques that combine > "something known" with "something owned". > > 3GPP security assumes that the client software outside of the SIM card is > fundamentally evil and that ever hacker has a spare supecomputer to play > with, but not a tunneling electroscope. That is, they trust only the > vendor-supplied SIM card, not the rest of the software in a phone. > > -- > Dean > > -- > Dean > > -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 18 19:49:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25150 for ; Mon, 18 Feb 2002 19:49:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA23343 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 19:49:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21959; Mon, 18 Feb 2002 19:17:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21928 for ; Mon, 18 Feb 2002 19:17:18 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24364 for ; Mon, 18 Feb 2002 19:17:12 -0500 (EST) Received: from DWILLISS1 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1J0GgB23060; Mon, 18 Feb 2002 18:16:43 -0600 Message-ID: <027d01c1b8da$b0aaa800$f1029bd4@DWILLISS1> From: "Dean Willis" To: "Danyuu Wuu" , References: <20020218072833.59274.qmail@web20104.mail.yahoo.com> Subject: Re: [Sip] SIP-TLS Travesty (another perspective) Date: Mon, 18 Feb 2002 18:16:31 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Danyuu Wuu" To: Sent: Monday, February 18, 2002 1:28 AM Subject: [Sip] SIP-TLS Travesty (another perspective) > Here is what I don't seem to understand about SIP > and TLS. SIP is trying to make TLS a 'MUST'. > I feel this prevents individuals from hosting > their own SIP domains. One has to go through hoops > to get a certificate from Verisign etc. etc. > Actually as an individual you simply cannot get a > security certificate (type 3?). Even as a business > there are some requirements before a cert is issued. > Once issued you must pay $400/year maintenance fees. > > I can host an SMTP server and a web server BUT I will > never be able to host a SIP domain for myself without > jumping through hoops and paying dearly. Is > that not a SIP travesty. I think SIP-TLS cannot > be a 'MUST' in the base protocol. In fact TLS > has no business to be in the base protocol. Please > keep that for "sips:". Well, actually, one can use a self-signed cert, or set oneself up as a CA and give certs to other people, using a free package like openssl. People may not take you seriously, but it works fine for personal use or for smaller user groups. I used this to set up imap/ssl on my self-hosted site (hey, it runs the SIP WG supplemental web site), and it works without a hitch. It did take me almost a half-hour of reading man pages to get set up, so it's not trivial, but I got it done and I'm not too bright. Of course, I might have just gotten lucky. OpenSSL looks like a pretty good package. As Jobe-Bob Briggs says "Check it out!" -- 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 daemon@ns.ietf.org Mon Feb 18 20:00:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25338 for ; Mon, 18 Feb 2002 20:00:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA23863 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 20:00:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22316; Mon, 18 Feb 2002 19:27:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22285 for ; Mon, 18 Feb 2002 19:27:42 -0500 (EST) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24721 for ; Mon, 18 Feb 2002 19:27:38 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 16:27:36 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Adam Roach'" , "'sip@ietf.org'" Cc: Jonathan Rosenberg Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! Date: Mon, 18 Feb 2002 16:27:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > * using "rejected" to cover unavailable/non-existing > > resource: I think this > > is just plain wrong. It has nothing to do with authorization policy; > > resubscribing with new credentials will not improve the > > situation - the > > resource is unavailable. Hence, my proposal to introduce the > > "noresource" > > error-reason. Subscriber response codes are not sufficient > as resource > > location is not necessarily a synchronous operation. > > You need to take up this argument with Jonathan, not me. My #1 > priority on the reason codes is to sync with watcherinfo. If you > can get Jonathan to add it to watcherinfo, I'll add it to events. Adam, Let em add the following observation that (and I quote from the watcherinfo Abstract) "Watcher information refers to the set of users subcribed to a particular resource within a particular event package." So when watcherinfo is used, you have already performed the resource location process. Of course, it does not make sense for watcherinfo to include an error-reason to say that a subscriber couldn't locate the resource that the watcher is already watching. However we are talking about the SIP Events draft here where this DOES make a sense (and IS of definite use) to have a "noresource" error-reason. Jonathan, what's your opinion on this? Robert. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 18 20:11:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25633 for ; Mon, 18 Feb 2002 20:11:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA24499 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 20:12:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23027; Mon, 18 Feb 2002 19:38:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22981 for ; Mon, 18 Feb 2002 19:38:14 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24990 for ; Mon, 18 Feb 2002 19:38:08 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1J0cWK11894; Mon, 18 Feb 2002 16:38:32 -0800 (PST) To: Ofir Arkin Cc: Dean Willis , Michael Thomas , Rohan Mahy , sip@ietf.org Subject: Re: Trust the Client? Sortof (Re: [Sip] SMIME in SIP) References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <15470.58825.137948.175526@thomasm-u1.cisco.com> <3C6EF34B.5050904@stake.com> <020101c1b8d6$ec426190$f1029bd4@DWILLISS1> <3C719855.2000301@stake.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 18 Feb 2002 16:38:32 -0800 In-Reply-To: Ofir Arkin's message of "Tue, 19 Feb 2002 00:12:05 +0000" Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Ofir Arkin writes: > You completely misunderstood what I was saying. Obviously. > If you need further more explanations, tutorials, understandings I will > be more than willing to explain. All I see here is people miss > understand what is about security and who you do not need to trust. What's necessary here is not that you provide a tutorial but rather that you write clearly enough that people can understand what point you're trying to make. In this particular case, your point was a relatively obvious one that was phrased so confusingly that I wasn't able to make out what you were trying to say. -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 daemon@ns.ietf.org Mon Feb 18 20:13:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25670 for ; Mon, 18 Feb 2002 20:13:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA24554 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 20:14:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23072; Mon, 18 Feb 2002 19:38:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23041 for ; Mon, 18 Feb 2002 19:38:55 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24994 for ; Mon, 18 Feb 2002 19:38:51 -0500 (EST) Received: from DWILLISS1 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1J0cMB23177; Mon, 18 Feb 2002 18:38:22 -0600 Message-ID: <02d501c1b8dd$b74fad60$f1029bd4@DWILLISS1> From: "Dean Willis" To: "Ofir Arkin" Cc: References: <15470.57122.730272.48839@thomasm-u1.cisco.com> <15470.58825.137948.175526@thomasm-u1.cisco.com> <3C6EF34B.5050904@stake.com> <020101c1b8d6$ec426190$f1029bd4@DWILLISS1> <3C719855.2000301@stake.com> Subject: Re: Trust the Client? Sortof (Re: [Sip] SMIME in SIP) Date: Mon, 18 Feb 2002 18:38:11 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Good examples! That's what I mean by the client running malicious code or otherwise not behaving as expected. Of course, I've also maintained that anyone billing on SIP transactions in the way you propose is at best fortunate and at worst a complete idiot. Unless they're very fortunate, somebody is going to abuse them (as you have demonstrated approaches for doing), but a lot of eople keep proposing it. I think you can only charge for things to which you add value, and only in proportion to the perceived value added (and the corrollary, the difficulty in getting comarable value without paying) . I've got a standard presentation on this somewhere if you want a primer on my amazing business philosophy. Amazing? Well, I'm amazed anybody listens to it, considering my poor stock portfolio performance . . . Sorry you're feeling touchy. Please take three deep breaths and vent at me some more -- it'll probably help. I shout at myself all the time, and look at how I feel. Of course, it's 01:30 AM here in France and I have an 0700 meeting with a pastry, so I'm headed to bed, but I promise to be amused again tomorrow night. Good night. -- Dean ----- Original Message ----- From: "Ofir Arkin" To: "Dean Willis" Cc: "EKR" ; "Michael Thomas" ; "Rohan Mahy" ; Sent: Monday, February 18, 2002 6:12 PM Subject: Re: Trust the Client? Sortof (Re: [Sip] SMIME in SIP) > You completely misunderstood what I was saying. > > And I was not referring to the situation with Crypto. So next time > before you shout and scream just read. > > Imagine the following in a Carrier SIP-Based Solution: > > Your SIP IP Phone/Softswitch is configured to use an outbound SIP Proxy > through a manual configuration that a technician put in your phone. So, > you are a lamer who does not understand too much in IP phones but you > know how to read the manual. The carrier you are using is also a lame > security aware one. > > So, you go to your manual, look up how you would change the > configuration (G no vendor can lock the damn configuration file - Oh G > we need to add that), and change your outbound proxy to your friends IP > address. G. . . . more excellent examples elided in the interest of bandwidth conservation. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 18 20:31:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26040 for ; Mon, 18 Feb 2002 20:31:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA25290 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 20:31:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23626; Mon, 18 Feb 2002 19:59:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23599 for ; Mon, 18 Feb 2002 19:59:20 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25323 for ; Mon, 18 Feb 2002 19:59:16 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1J0x76Y007323; Mon, 18 Feb 2002 19:59:08 -0500 (EST) Message-ID: <3C71A329.E06EEA8E@dynamicsoft.com> Date: Mon, 18 Feb 2002 19:58:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dror@vocaltec.com CC: sip@ietf.org Subject: Re: [Sip] Some more ABNF issues - bis07 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dror@vocaltec.com wrote: > > 1. TEXT-UTF8-TRIM - while the text claims it does not allow leading WS, > it > actually does. should be redefined as: > TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) > (added "1" before "*") Good point. Fixed. > > 2. token - isn't there a requirement for a token to start with alphanum > ? > (e.g. current definition allows -.+!' as a valid token) I don't think there is such a requirement. Certainly not as far as the parser is concerned. > > 3. SIP-Version - "SIP/2.0" is the current version, but I believe > SIP-Version = "SIP/" 1*DIGIT "." 1*DIGIT > is the general term. I think this is also correct. I am not sure why the BNF was made to forcefully limit the version to 2.0, since there are torture tests for higher versions, and a response code to deal with it to. > > 4. line-breaks: Many places allow LWS (e.g. surrounding the "=" in any > URL parameter) I don't know what gives you that impression that there is LWS in the URI; there is no LWS in the BNF for any of the URI parameters. They cannot contain LWS. ANyway, I don't see the specific problem. Of course there is LWS in places...? > - which are converted into a single space when parsed. > The > table characters should be used sparingly (if at all) We cannot remove them arbitrarily. rfc 2543 allowed optional LWS between separators and tokens, and between separators and separators. The SWS expresses this optionality. Removing it would break backwards compatibility with RFC 2543. > > 4. method-extension allows "token". see (1) above There is nothing wrong with this. The method +&$ may be ugly, but it will parse just fine. Asthetic beauty is not important for method names.... ;) > > 5. parameter ambiguity for URI's. e.g: > from-spec = ( name-addr = addr-spec ) *( SEMI from-param ) > Cannot tell if a parameter is "from-spec" parameter, or "addr-spec" > (actually, SIP-URI) parameter. This is discussed in the text. > Also, the format suggests that all SIP-URI parameters MUST appear before > > all "from-spec" parameters (otherwise, they are parsed as "extension" > parameters of the "from-spec". Yes. > This actually might be a "good thing" - but should be documented in > English as well... Its mentioned something like three times, once in the header sections for the From, To and Contact. We don't need yet another mention. Thanks for your comments, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Mon Feb 18 20:37:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26224 for ; Mon, 18 Feb 2002 20:37:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA25766 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 20:37:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24619; Mon, 18 Feb 2002 20:14:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24577 for ; Mon, 18 Feb 2002 20:14:21 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25697 for ; Mon, 18 Feb 2002 20:14:16 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 19 Feb 2002 01:14:34 UT Received: from jolaptop ([80.3.216.239]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 19 Feb 2002 01:16:30 +0000 From: "Jo Hornsby" To: Cc: "Jonathan Rosenberg" Date: Tue, 19 Feb 2002 01:18:09 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-OriginalArrivalTime: 19 Feb 2002 01:16:30.0448 (UTC) FILETIME=[0FC10700:01C1B8E3] Content-Transfer-Encoding: 7bit Subject: [Sip] Comments on SIP SRV Draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi. So a few things that I noticed. Apologies for re-reports. I bet it's ever-so-slightly anoying. * Section 1; 2nd Paragraph: First use of "DNS" on the second line. Dunno if this merits a pointer to any of the DNS RFCs or perhaps just the abbreviation broken out. * Section 2; 2nd Paragraph: First use of: "TCP, UDP, TLS, SCTP" and "IP". (Well, "IP" also occurs in the abstract, but.) Again, I don't know whether it's really necessary to spell these out (in particular, a reader not knowing all of { "IP", "UDP", "TCP" } I suspect is going to be the exception), but just in case, they're here. * Section 2; 2nd Paragraph; Sentence "All proxies must implement both UDP and TCP [...]": Is it worthwhile throwing "TLS" into the pot here now? * Section 2; 3rd Paragraph; Sentence "It is important to note [...]": s/processing/the processing/ ? * Section 4; 1st Paragraph: First use of "UAC". * Section 4; 2nd Paragraph: Well, Rohan's suggested new text, which I do find easier to parse. However, being First-Use Boy, I detect this unknown "URI". * Section 4; 3rd Paragraph; Sentence "That is, once a server [...]": s/responses/INVITE responses/ [This may be being a little keen.] * Section 4; 4th Paragraph; Sentence "Because the ACK request for [...]": s/responses/responses to INVITEs/ [Again, this may be being a little keen.] * Section 4; 4th Paragraph; Sentence "Because the ACK request for [...]": Perhaps s/most definitely/probably/ ? "most definitely not" sounds like a wager to me. &:) * Section 4.1; 3rd Paragraph; Sentence "Otherwise, if no transport protocol [...]": Well, there may well be no bug here, or the bug may be in a different Section; however, I am wondering why there was particular need to explicitly rule out using these procedures when using an outbound proxy identified by an IP as opposed to a domain name? I possibly wrong, but I think that bis exclusively defers to this document for rules on how to determine the server to contact, so I would perceive this to be a hole. * Section 4.1; 4th Paragraph; Sentence "Otherwise, if no transport protocol [...]": s/target/TARGET/ * Section 4.1; BINDish Zone File: I'm guessing that the last entry should have been "SIP+D2L"? Also, is there any reason why this entry does not look particular SRVish; i.e., has a distinct lack of "_"s? I guess the whole TLS-isn't-a-transport thing is problematic here.... * Section 4.1; 7th Paragraph; Sentence "If the client supports [...]": Personally, I would find it helpful to do something like: s/UDP and TLS/UDP and TLS only/ I might also note that this is a non-conforming implementation. &;) * Section 4.1; Last Paragraph: Is the implication here that once a client has decided on a transport, then only results from a query of that SRV record should be used, and no other transports considered? If so, especially if we're talking "MUST NOT", this could probably be a little clearer. * Section 4.2; Paragraph 4 (Indented): I am actually slightly confused, as a result of this paragraph, on how these steps fit together. I would have thought that in some ways 4.1 was end-of-the-road; i.e., because the NAPTR RFC specifies the "s" flag, the use of SRV, and then thus A, I guess, was sorta automatic. Otherwise, may be 4.1 should specify that the result of the NAPTR lookup is applied to TARGET? In any case, thouls this paragraph be s/SRV/NAPTR/ ? * Section 4.3; Paragraph 2: Rohan's text is good here, I think. * Section 4.3; Paragraph 3: Doesn't it always come down to A/AAAA in the end? [I might be exposing a blatant misunderstanding of SRV, here.] * Section 4.3: In general, don't these rules apply to multiple records of any type? In particular, I'm thinking multiple-A records. The Section title would seem to preclude this? * Section 4.4: Paragraph 1: Sentence 2: I would suggest: "When a server is contacted successfully, all retransmissions for the transaction, as well as ACK/CANCEL requests for that transaction, MUST go to the same server." * Section 5; Paragraph 4: Sentence 1: s,A,A/AAAA, ? * Section 5; Last Paragraph: Ah, I guess this relates to my earlier comment. Since we do "SIP/2.0/TLS" (or did I imagine this), then does this imply _sip._tls.this-domain-is-so.invalid ? I'm trying to work out if this conflicts with 2782, but since it says (under the bit talking about the "Proto" component of the SRV RR): "though any name defined by Assigned Numbers or _locally_ may be used", I guess it's okay (though "locally" doesn't seem to be so well defined). And I suppose a name collision should be v. unlikely [thanks to Mr. Oberg?].... * Section 6: I feel that this section is too fond of "maddr", since we now know better. It's potential role as "TARGET" is already explicit. I doubt there is a need to dwell here. Cheers, - Jo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Feb 18 21:00:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26667 for ; Mon, 18 Feb 2002 21:00:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA26876 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 21:00:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24888; Mon, 18 Feb 2002 20:29:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24857 for ; Mon, 18 Feb 2002 20:29:23 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25979 for ; Mon, 18 Feb 2002 20:29:18 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1J1T96Y007337; Mon, 18 Feb 2002 20:29:10 -0500 (EST) Message-ID: <3C71AA33.E7D1BF50@dynamicsoft.com> Date: Mon, 18 Feb 2002 20:28:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner CC: dror@vocaltec.com, sip@ietf.org Subject: Re: [Sip] Some more ABNF issues - bis07 References: <200202041625.IAA14563@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bill Fenner wrote: > > >Did anyone ran an automated ABNF parser, and passed the "torture test" > >messages ? > > I've been running the one from http://www.ops.ietf.org/, but I've > been fixing parser bugs as well as grammar bugs, so don't take > everything > it says to heart. > > Problems I've found in sipbis-07 so far: > > Jonathan's suspicion was correct, <"> doesn't work; my guess is you > should use %x22 . Done. > > There's still a | seperator before ttl-param. Probably didn't catch > it because of the lack of whitespace. No, its because I fixed this last minute and did it manually, missed the first one. > > "nextnonce" and "composite-type" are missing an '=' between the rule > name > and definition. Oops. Thanks. > > Here are the warnings at the end: > > rquest-uri: Used 1 times, but not defined > > This is the reference to HTTP/1.1 . Yeah, not much I can do about it. > > start-line: Used 1 times, but not defined > > This is from the ABNF in section 7, defining generic-message, but > there's > no ABNF defining start-line. Is this ABNF still supposed to be in > section > 7, or should it have moved to section 27 too? The idea was to have the top-level parts of the BNF in section 7 to aid in understanding of the basic structure. However, it appears that this BNF was never updated to use explicit LWS, or checked for correctness. So, I've added a definition of start-line there, and corrected the BNF (for example, there were no SP in the request-line). > > telephone-subscriber: Used 1 times, but not defined > > This is imported from RFC 2806. Yup. > > ATSIGN: Defined but not used > BANG: Defined but not used > BAR: Defined but not used Deleted. > BIT: Defined but not used BIT??? I didn't see that one anywhere... > CHAR: Defined but not used Same - where is this one? > CTL: Defined but not used THis one is not in there either. > > digest-uri-value: Multiply defined > > This is from the ABNF in section 7 and 27; they both have the same > definition. I think you mean section 20 and 27. I think this is OK. > > DOT: Defined but not used > DQUOT: Defined but not used > DQUOTE: Defined but not used I don't find a DQUOTE either.... > generic-message: Defined but not used This one needs to stay :) > LANGLE: Defined but not used > LBRACK: Defined but not used Deleted. > LWSP: Defined but not used Not in here either; maybe these are incorporated from 2234? > MINUS: Defined but not used > PERCENT: Defined but not used > PLUS: Defined but not used > RANGLE: Defined but not used > RBRACK: Defined but not used Deleted. > separators: Defined but not used Its not used, but its discussed, so I'd like to keep it. > SIP-message: Defined but not used This needs to stay too. > TEXT-UTF8: Defined but not used Deleted. An artifact of pre-explicit-LWS. I also changed the text below to talk about TEXT-UTF8-TRIM instead of TEXT-UTF8. > TILDE: Defined but not used Deleted. > VCHAR: Defined but not used Not in here. > TEXT-UTF8char: Referred to as TEXT-UTF8CHAR I changed the second to lowercase to be consistent. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Mon Feb 18 21:11:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26865 for ; Mon, 18 Feb 2002 21:11:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA27256 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 21:12:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25499; Mon, 18 Feb 2002 20:34:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25468 for ; Mon, 18 Feb 2002 20:34:28 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26141 for ; Mon, 18 Feb 2002 20:34:24 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1J1Yk6Y007340; Mon, 18 Feb 2002 20:34:46 -0500 (EST) Message-ID: <3C71AB84.3FF843DB@dynamicsoft.com> Date: Mon, 18 Feb 2002 20:33:56 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner CC: sip@ietf.org Subject: Re: [Sip] Some more ABNF issues - bis07 References: <200202062312.PAA19363@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bill Fenner wrote: > > So, this may seem a little weird, but I wrote my own ABNF parser > and ran the bis07 ABNF through it, and came up with another couple of > fairly subtle issues: > > - "word" is missing slashes between "~" and "(", and between ">" and > ":". > This makes these elements concatenate, i.e. > ... "'" / ( "~" "(" ) / ")" / "<" / ( ">" ":" ) / "\" / <"> ... > which is clearly bad. Yikes, good catch there. Fixed. > > - Similar precedence issue: concatenation binds more tightly than > alternation, so despite the whitespace, you need a grouping > around the second line of Contact: > > Contact = ("Contact" / "m" ) HCOLON > STAR / (contact-param *(COMMA contact-param)) > > else it really means > (("Contact" / "m" ) HCOLON STAR) / (contact-param *(COMMA > contact-param)) Another excellent catch. Fixed. > Also, I'm sure this is redundant by now, but to continue earlier > thoughts > on representing the double quote character, there's a DQUOTE element in > the ABNF core that can be used instead of <"> or %x22 . OK, that sounds like the best plan. I changed to DQUOTE. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Mon Feb 18 22:34:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29899 for ; Mon, 18 Feb 2002 22:34:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA00267 for sip-archive@odin.ietf.org; Mon, 18 Feb 2002 22:34:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA29474; Mon, 18 Feb 2002 22:13:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA29445 for ; Mon, 18 Feb 2002 22:13:38 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28722 for ; Mon, 18 Feb 2002 22:13:32 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 19 Feb 2002 03:13:50 UT Received: from jolaptop ([80.3.216.239]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 19 Feb 2002 03:15:47 +0000 From: "Jo Hornsby" To: Cc: "Jonathan Rosenberg" Date: Tue, 19 Feb 2002 03:17:25 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-OriginalArrivalTime: 19 Feb 2002 03:15:47.0319 (UTC) FILETIME=[B994E070:01C1B8F3] Content-Transfer-Encoding: 7bit Subject: [Sip] Comments on 100rel pre-release Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sorry. Again with the disclaimer about my poor ability to notice re-reports. * Section 1; Paragraph 3: First use of "TU". * Section 1; Paragraph 4: First use of "UAC". * Section 3: First use of "UAS". * Section 3; Paragraph 10: Missing closing parenthesis after "RFC BBBB". [Dunno how generous the RFC Editor will be, eh? (:&] * Section 3; Paragraph 13; Sentence 1: It might be helpful to s/If a PRACK request/If a new PRACK request/ to emphasise that this doesn't apply to retransmissions of a PRACK? * Section 4; Paragraph 2: "100rel" is quoted here. Not sure what the preferred apprach should be, but I guess it should be consistent. * Section 4; Paragraph 8: s/TU/UAC ? * Section 5; Paragraph 3: For consistency, I would have thought s/a session description/an offer/ ? But this might make the sentence a little hard to parse. * Section 5; Paragraph 4: s/a session description/an offer or an answer/ Perhaps? * Table 1: - Accept/415: I suspect should be "m"? * Table 2: - Record-Route: s/,401,484// - To: c(1) -- I don't see how it's possible that there could be no tag. - Unsupported/420: Shouldn't this read "m"? * Table 3: - RSeq: Only INV should be "o", right? The rest "-"? * Section 9: I'm not sure how valid a concern this is, but I might perceive a vague DoS attack based on a MitM adding the option tag "100rel" to the Require: in a request. Seems like the UAS might have to transmit a lot more responses that it would usually in this case? Cheers, - Jo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Feb 19 00:23:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01803 for ; Tue, 19 Feb 2002 00:23:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA04165 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 00:23:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02901; Mon, 18 Feb 2002 23:56:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02874 for ; Mon, 18 Feb 2002 23:56:16 -0500 (EST) Received: from services.dasecurenetworks.com (adsl-64-219-169-88.dsl.rcsntx.swbell.net [64.219.169.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01600 for ; Mon, 18 Feb 2002 23:56:11 -0500 (EST) Received: from dasecurenetworks.com (main1.dasecurenetworks.com [192.168.0.151] (may be forged)) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g1J4J8X29029; Mon, 18 Feb 2002 22:19:09 -0600 Message-ID: <3C71DD9B.E7368B93@dasecurenetworks.com> Date: Mon, 18 Feb 2002 23:07:39 -0600 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: Danyuu Wuu , sip@ietf.org Subject: Re: [Sip] SIP-TLS Travesty (another perspective) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > > Here is what I don't seem to understand about SIP > > and TLS. SIP is trying to make TLS a 'MUST'. > > I feel this prevents individuals from hosting > > their own SIP domains. One has to go through hoops > > to get a certificate from Verisign etc. etc. > > Actually as an individual you simply cannot get a > > security certificate (type 3?). Even as a business > > there are some requirements before a cert is issued. > > Once issued you must pay $400/year maintenance fees. > > Does not have to be so -- there are multiple certification authorities. > Besides, if you use S/MIME, you also need a certificate... > > -- Christian Huitema > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Just for my own info, since I did jump in in the middle of this thread, are we discussing the authentication mechanism of SIP and/or the encryption of certain SIP headers? And as Christian points out all of the mechansims, even IPSec can utilize certs...and there are many ca's out there, including the fact that anyone can create their own certificate and sign it, this is a danger in itself, but if we are merely wanting to protect the information in transit this method could be utilized to perform this function, as many web sites do today, many of them are not signed by a trusted ca, yet the users typically accept them anyway....bad move as this may be, it is fairly simple and semi-transparent for the average user to have a slight bit of security. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Feb 19 00:35:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02386 for ; Tue, 19 Feb 2002 00:35:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA04840 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 00:35:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA03918; Tue, 19 Feb 2002 00:14:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA03813 for ; Tue, 19 Feb 2002 00:14:04 -0500 (EST) Received: from services.dasecurenetworks.com (adsl-64-219-169-88.dsl.rcsntx.swbell.net [64.219.169.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01753 for ; Tue, 19 Feb 2002 00:14:03 -0500 (EST) Received: from dasecurenetworks.com (main1.dasecurenetworks.com [192.168.0.151] (may be forged)) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g1J4asX29059; Mon, 18 Feb 2002 22:36:54 -0600 Message-ID: <3C71E1C4.B95176F5@dasecurenetworks.com> Date: Mon, 18 Feb 2002 23:25:24 -0600 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema , Danyuu Wuu , sip@ietf.org Subject: Re: [Sip] SIP-TLS Travesty (another perspective) References: <3C71DD9B.E7368B93@dasecurenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Chris Martin wrote: > > Christian Huitema wrote: > > > > > Here is what I don't seem to understand about SIP > > > and TLS. SIP is trying to make TLS a 'MUST'. > > > I feel this prevents individuals from hosting > > > their own SIP domains. One has to go through hoops > > > to get a certificate from Verisign etc. etc. > > > Actually as an individual you simply cannot get a > > > security certificate (type 3?). Even as a business > > > there are some requirements before a cert is issued. > > > Once issued you must pay $400/year maintenance fees. > > > > Does not have to be so -- there are multiple certification authorities. > > Besides, if you use S/MIME, you also need a certificate... > > > > -- Christian Huitema > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > Just for my own info, since I did jump in in the middle of this thread, > are we discussing the authentication mechanism of SIP and/or the > encryption of certain SIP headers? > > And as Christian points out all of the mechansims, Christian points out SMIME, I am adding the rest...before everyone reads this and says...Christian didnt point that out... I am merely adding to his statement.... :^) even IPSec can > utilize certs...and there are many ca's out there, including the fact > that anyone can create their own certificate and sign it, this is a > danger in itself, but if we are merely wanting to protect the > information in transit this method could be utilized to perform this > function, as many web sites do today, many of them are not signed by a > trusted ca, yet the users typically accept them anyway....bad move as > this may be, it is fairly simple and semi-transparent for the average > user to have a slight bit of security. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Tue Feb 19 00:46:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02516 for ; Tue, 19 Feb 2002 00:46:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA05174 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 00:46:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA04284; Tue, 19 Feb 2002 00:25:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA04240 for ; Tue, 19 Feb 2002 00:25:18 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02199 for ; Tue, 19 Feb 2002 00:25:17 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1J5Pa6Y007499 for ; Tue, 19 Feb 2002 00:25:37 -0500 (EST) Message-ID: <3C71E19F.F309F939@dynamicsoft.com> Date: Tue, 19 Feb 2002 00:24:47 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] draft-ietf-sip-rfc2543bis-07.9 now available Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, We've decided to do a "pre-release" of the -08 spec a few days before -08 issues and it goes to IESG. That spec is now available at: http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-07.9.pdf http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-07.9.txt http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-07.9.ps It will *not* appear in the archives, as it represents an interim working version. This text, through the miracle of caffeine and many tireless nights (including weekends), includes pretty much all of the hundreds of comments (and I think its MANY hundreds of comments) that we got on the list and in private on bis-07 and bis-06. It also: * includes the new sips scheme that has been discussed * only uses tags as dialog ID, not URIs anymore * URI comparison rules consistently don't have explicit default equal no value * consistent use of routing and next hop determination terminology * restriction on forking when route present has been lifted * termination section now says BYE terminates a session * 100rel is gone * thorough review of tables 2/3 to bring to consistency with the text * source ip/port not used as part of transaction ID * use TCP if you are in within 200 bytes of MTU (used to be 500) * backwards compatibility mechanisms for older, TCP-only implementations added * removed RTT estimation * downgrade SMIME to MAY * added application/sip mime registration We've had some problems in the text versions of -06,-07 with the split references section, which I think are finally ironed out. Howver, I NEED a volunteer to check the references in the text, to make sure that every reference is the same in txt and pdf, and that it references the right thing. Note that I will not be entertaining comments about improving formatting bugs in the pdf/ps, since that document is not authoritative. Any last minute items on this, speak now.... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Tue Feb 19 02:32:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11726 for ; Tue, 19 Feb 2002 02:32:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA18161 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 02:32:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17341; Tue, 19 Feb 2002 02:09:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17313 for ; Tue, 19 Feb 2002 02:09:03 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11371 for ; Tue, 19 Feb 2002 02:09:01 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1J78HhM009706; Tue, 19 Feb 2002 08:08:17 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1J78Gr6023135; Tue, 19 Feb 2002 09:08:16 +0200 (EET) Message-ID: <3C71FA19.8292510D@lmf.ericsson.se> Date: Tue, 19 Feb 2002 09:09:13 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: sip@ietf.org Subject: Re: [Sip] Bis-7: Question on brackets References: <3C70DC40.88E2A75E@lmf.ericsson.se> <3C712B68.4000400@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > > Hi, > > > > A long time there was a discussion (it has also been discussed at > > bake-off/SIPit events) on how to separate URI parameters from header > > parameters in the To- and From headers. > > > > To my understanding, it was agreed that if header parameters (eg the > > tag) are used, the URI MUST be inside brackets. > > > > Its the other way around - without brackets any parameters are considered > header parameters., so if URI parameters are used, the URI MUST be inside > brackets. True. Sorry, my misstake. Regards, Christer Holmberg Ericsson 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 daemon@ns.ietf.org Tue Feb 19 03:07:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12246 for ; Tue, 19 Feb 2002 03:07:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA19595 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 03:07:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18600; Tue, 19 Feb 2002 02:46:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18573 for ; Tue, 19 Feb 2002 02:46:17 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11927 for ; Tue, 19 Feb 2002 02:46:15 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1J7k5io026277; Tue, 19 Feb 2002 09:46:05 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.701.458392.961132@harjus.eng.song.fi> Date: Tue, 19 Feb 2002 09:46:05 +0200 To: "Dean Willis" Cc: "Miguel A. Garcia" , , , , Subject: Re: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? In-Reply-To: <024001c1b8d9$1e9a7ea0$f1029bd4@DWILLISS1> References: <011b01c1b65c$5b579f00$b3036e3f@dfw.dynamicsoft.com> <3C6FAF91.3F27DEE@ericsson.com> <15473.31878.491755.490593@harjus.eng.song.fi> <024001c1b8d9$1e9a7ea0$f1029bd4@DWILLISS1> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit i still don't get it. lets assume that my mobile phone (like any UA) has been configured with its sip uri, e.g., sip:123456@mobile.com. when it registers, it sets the request uri to sip:mobile.com and sends the register message either to its outbound proxy (which it had learned via dhcp when it was turned on) or it makes a dns query and asks who is the proxy for mobile.com and sends it directly there. it should not matter at all to the UA or the registar through which proxies the message got to the registrar of mobile.com. the same for invites. when the UA makes an invite, it can choose to use its outbound proxy with or without a loose source route containing an entry for its home proxy or send the invite directly to its home 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 daemon@ns.ietf.org Tue Feb 19 04:16:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12915 for ; Tue, 19 Feb 2002 04:16:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA22200 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 04:16:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21127; Tue, 19 Feb 2002 03:51:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21101 for ; Tue, 19 Feb 2002 03:51:51 -0500 (EST) Received: from hotmail.com (f81.law3.hotmail.com [209.185.241.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12662 for ; Tue, 19 Feb 2002 03:51:49 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 19 Feb 2002 00:51:20 -0800 Received: from 199.182.24.126 by lw3fd.law3.hotmail.msn.com with HTTP; Tue, 19 Feb 2002 08:51:10 GMT X-Originating-IP: [199.182.24.126] From: "Samir Srivastava" To: rsparks@dynamicsoft.com Cc: sip@ietf.org Date: Tue, 19 Feb 2002 08:51:10 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Feb 2002 08:51:20.0746 (UTC) FILETIME=[9A0A08A0:01C1B922] Subject: [Sip] Multiple REFER requests in a dialog, Event header ? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, draft-ietf-sip-refer-2. Under section 3.5.3.3 second para "Thus, for the second and subsequent REFER requests a UA receives in a given dialog, it MUST include a cseq parameter in the Event header. " Why don't we have above approach irrespective of the no of occurence in the call. That is for the Ist REFER, it should also have the Cseq in the event header. This will be uniform approach from the UA prespective. If there is any reason about this, pl mention it in a line or two. Thx Samir _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 04:45:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13187 for ; Tue, 19 Feb 2002 04:45:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA23683 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 04:45:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21984; Tue, 19 Feb 2002 04:08:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21953 for ; Tue, 19 Feb 2002 04:08:15 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12871 for ; Tue, 19 Feb 2002 04:08:13 -0500 (EST) Received: (qmail 16923 invoked from network); 19 Feb 2002 09:11:27 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 19 Feb 2002 09:11:27 -0000 Received: from stake.com (unknown [10.50.1.35]) by cam-relay.atstake.com (Postfix) with SMTP id D504022818 for ; Tue, 19 Feb 2002 04:06:09 -0500 (EST) Message-ID: <3C7216A6.3030400@stake.com> Date: Tue, 19 Feb 2002 09:11:02 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] HTML version of Section 22 - Security Considerations (draft-ietf-sip-rfc2543bis-07) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit You can view the Security review I made of draft-ietf-sip-rfc2543bis-07 in html format using this link: www.sys-security.com/archive/research/draft-ietf-sip-rfc2543bis-07_Review_of_section_22.htm -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 04:51:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13254 for ; Tue, 19 Feb 2002 04:51:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA23937 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 04:51:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22386; Tue, 19 Feb 2002 04:22:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22356 for ; Tue, 19 Feb 2002 04:22:20 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12961 for ; Tue, 19 Feb 2002 04:22:18 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 19 Feb 2002 09:22:34 UT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Tue, 19 Feb 2002 09:24:31 -0000 Message-ID: <45730E094814E44488F789C1CDED27AEC552AA@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Reminder: SIP Events WGLC Ending Soon! Thread-Index: AcG40D+HxgOisG48QiGRrhFa2CIRegAVIqLw From: "James Undery" To: "Adam Roach" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA22357 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I am not hung up on any of this as it's non-normative and can be ignored ;-) > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > 5.4.7. 1st para. It may be worth noting explicitly that "fake" or > > "neutral" state information isn't required > > Actually, I think it is. The need to provide this sort of > authentication hiding comes down more to a policy decision > that will be made on a per-deployment basis than a package- > related attribute that a package author can decide to neglect. In general if you mean no state in the NOTIFY is neutral okay, otherwise I've a problem. Fake state is for polite refusal a rather rare problem (i.e. presence); the existance of a neutral state or identity for deltas is something my limited set theory would suggest may not apply. > > 6.1. s/user/resource/ (also section 3 might do with a > consistent name > > for the entity the state describes) > > Actually, we really mean user. Human. The person who owns the > resource, not the resource itself. It's an important distinction. In that case may I suggest s/user/local policy/ as it is REALLY important a human need not be involved. > > 6.3. 3rd para. s/of notifiers/accepting subscriptions/ > > Notifiers is a defined term; we describe accepting > SUBSCRIBE messages in the definition of a notifier. > I think your suggested change would actually cause more > confusion than it avoids. Where as I'd hate to introduce the braindead arguments people have over location servers, registrars and proxies. The entity that accepts the subscription and the entity that's the notifier are logically distinct. > > 7.4. Should Allow-Events be mandatory in 2xx responses to an OPTIONS > > Only sort of. When interacting with UAs not supporting SIP-Events, > you won't see "Allow-Events" in OPTIONS responses. Putting an "m" > in the table would imply a global change. Surely only for people implementing Sub/Not, it's like Max-Forwards mandatory, yet only bis aware UAs will be guaranteed to do it. 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 daemon@optimus.ietf.org Tue Feb 19 04:58:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13389 for ; Tue, 19 Feb 2002 04:58:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA24110 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 04:58:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23089; Tue, 19 Feb 2002 04:31:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23043 for ; Tue, 19 Feb 2002 04:31:36 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13053 for ; Tue, 19 Feb 2002 04:31:34 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 19 Feb 2002 09:31:50 UT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Tue, 19 Feb 2002 09:33:46 -0000 Message-ID: <45730E094814E44488F789C1CDED27AEC552AB@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Reminder: SIP Events WGLC Ending Soon! Thread-Index: AcG40D+HxgOisG48QiGRrhFa2CIRegAVIqLwAADKPHA= From: "James Undery" To: "James Undery" , "Adam Roach" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA23044 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Ooops hit send too soon another v. minor nit; the BNF uses '|' instead of the rfc2234 '/' the bis has now adopted. 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 daemon@optimus.ietf.org Tue Feb 19 07:47:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16376 for ; Tue, 19 Feb 2002 07:47:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA02787 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 07:47:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01150; Tue, 19 Feb 2002 07:10:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01121 for ; Tue, 19 Feb 2002 07:10:38 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15427; Tue, 19 Feb 2002 07:10:37 -0500 (EST) Message-Id: <200202191210.HAA15427@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 19 Feb 2002 07:10:37 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-update-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : The SIP UPDATE Method Author(s) : J. Rosenberg Filename : draft-ietf-sip-update-00.txt Pages : 14 Date : 18-Feb-02 This specification defines the new UPDATE method for the Session Initiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs), or provide SIP level information (such as credentials), but has no impact on the state of a dialog. This is very useful for updating information about a call before the call has been accepted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-update-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-update-00.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-update-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020218134424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020218134424.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 10:30:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23989 for ; Tue, 19 Feb 2002 10:30:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12416 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 10:30:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10405; Tue, 19 Feb 2002 09:57:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10374 for ; Tue, 19 Feb 2002 09:57:56 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22030 for ; Tue, 19 Feb 2002 09:57:52 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1JEvOt01827 for ; Tue, 19 Feb 2002 06:57:24 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX40238; Tue, 19 Feb 2002 06:56:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA29471; Tue, 19 Feb 2002 06:57:23 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.26579.149575.12910@thomasm-u1.cisco.com> Date: Tue, 19 Feb 2002 06:57:23 -0800 (PST) To: sip@ietf.org X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [Sip] replays and SMIME Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit So I'm not terribly familiar with SMIME so I was curious how replay detection was performed. There doesn't seem to be a specific section which talks about it, but section 2.7.1 does talk about cipher suite selection as well as timestamp handling, which is I think is the relevant text. According to the document, you are supposed to keep a list of all of the known SMIME senders, their last timestamp and their cipher suites. If you receive something before the last recorded time stamp, you should reject it. So, on an el-cheapo hard drive this is probably not much of an issue, but I don't think it would work very well on a SIP UA which only has flash memory. Also: I'm not sure I buy the mechanism since reordering could come into play with SIP (though it seems pretty unlikely with mail). In any case, if we're going to have replay detection for SMIME bodies, I think we're going to need a better scheme here. 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 daemon@optimus.ietf.org Tue Feb 19 10:34:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24139 for ; Tue, 19 Feb 2002 10:34:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13145 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 10:34:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10081; Tue, 19 Feb 2002 09:54:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10036 for ; Tue, 19 Feb 2002 09:54:29 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21818 for ; Tue, 19 Feb 2002 09:54:26 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1JEfLm01240; Tue, 19 Feb 2002 08:41:21 -0600 Message-ID: <3C726410.4050601@dynamicsoft.com> Date: Tue, 19 Feb 2002 08:41:20 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Samir Srivastava CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Multiple REFER requests in a dialog, Event header ? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It was introduced as an (at the time) last minute fix - allowing those people who had already implemented systems that would only send one REFER to not modify their code. In the interim, we discovered the same problem lived in the events draft, leading to the introduction of the "id" parameter. In sip-events, if the value in the Event header field of a SUBSCRIBE request contains an "id" parameter, it must be reflected in the Event header fields of NOTIFYs corresponding to that subscription. For alignment, we should probably use "id" instead of "cseq" as the parameter name in REFER. The value of the parameter will still be the CSeq of the REFER that brought the implicit subscription into being. Having fewer exceptions also argues for including this parameter in ALL NOTIFYs to Event: refer, not just NOTIFYs for the second and subsequent implicit subscriptions in a dialog. Comments? RjS Samir Srivastava wrote: > > Hi, > draft-ietf-sip-refer-2. > Under section 3.5.3.3 second para > > "Thus, for the second and subsequent REFER requests a UA receives > in a given dialog, it MUST include a cseq parameter in the Event > header. " > Why don't we have above approach irrespective of the no of > occurence in the call. That is for the Ist REFER, it should also > have the Cseq in the event header. This will be uniform approach > from the UA prespective. If there is any reason about this, pl > mention it in a line or two. > > Thx > Samir > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 10:40:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24324 for ; Tue, 19 Feb 2002 10:40:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13379 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 10:40:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11557; Tue, 19 Feb 2002 10:12:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11527 for ; Tue, 19 Feb 2002 10:12:48 -0500 (EST) Received: from lineus14.lineus.net ([200.246.26.150]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22944 for ; Tue, 19 Feb 2002 10:12:42 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B957.F4CF596A" Date: Tue, 19 Feb 2002 12:13:16 -0300 Message-ID: <9350A1230A95DA4A9B7D712177E77840F20A9E@lineus14.lineus.net> Thread-Topic: Java based SIP stack Thread-Index: AcG5V7+KzXNlVepiRm+xhWMFCt/TEQ== From: "Danillo Marcondes" To: Subject: [Sip] Java based SIP stack Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1B957.F4CF596A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to know where I can find a free Java based SIP stack. Could anyone help me please? Thanks, Danillo. ------_=_NextPart_001_01C1B957.F4CF596A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Java based SIP stack

Hi,

I would like to know where I can find a = free Java based SIP stack.

Could anyone help me please?

Thanks,

Danillo.

------_=_NextPart_001_01C1B957.F4CF596A-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 10:43:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24443 for ; Tue, 19 Feb 2002 10:43:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13596 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 10:43:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11633; Tue, 19 Feb 2002 10:14:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11602 for ; Tue, 19 Feb 2002 10:14:04 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23005 for ; Tue, 19 Feb 2002 10:14:00 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1JFE5g20715; Tue, 19 Feb 2002 07:14:05 -0800 (PST) To: Michael Thomas Cc: sip@ietf.org Subject: Re: [Sip] replays and SMIME References: <15474.26579.149575.12910@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 19 Feb 2002 07:14:05 -0800 In-Reply-To: Michael Thomas's message of "Tue, 19 Feb 2002 06:57:23 -0800 (PST)" Message-ID: Lines: 22 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Retransmitting, since I sent the first reply to Michael alone. Michael Thomas writes: > So I'm not terribly familiar with SMIME so I was > curious how replay detection was performed. In general, S/MIME doesn't worry much about replay protection. >In >any case, if we're going to have replay detection >for SMIME bodies, I think we're going to need a >better scheme here. I agree. What I had in mind was using essentially the same mechanism that is use with Digest: a series of nonces that must be echoed in the message to ensure freshness. The alternative, of course, is to use sequence numbers a la IPsec, but this requires storage for each client. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Tue Feb 19 11:04:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25325 for ; Tue, 19 Feb 2002 11:04:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15146 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 11:04:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13298; Tue, 19 Feb 2002 10:38:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13268 for ; Tue, 19 Feb 2002 10:38:24 -0500 (EST) Received: from mandy.eunet.fi (mandy.eunet.fi [193.66.1.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24259 for ; Tue, 19 Feb 2002 10:38:16 -0500 (EST) Received: from HASH (ip212-226-136-1.adsl.kpnqwest.fi [212.226.136.1]) by mandy.eunet.fi (Postfix) with SMTP id 43ECDA1E5; Tue, 19 Feb 2002 17:38:16 +0200 (EET) (envelope-from hisham.khartabil@pp.fi) From: "Hisham Khartabil" To: "Robert Sparks" Cc: , , "gonzalo.camarillo" Subject: RE: Expires heade field in REGISTER responses: (was Re: [Sip] comments and nits on bis-07) Date: Tue, 19 Feb 2002 17:38:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C71486D.5060706@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, 18 February 2002 8:31 PM > To: Hisham Khartabil > Cc: sip@ietf.org; jdrosen@dynamicsoft.com; gonzalo.camarillo > Subject: Expires heade field in REGISTER responses: (was Re: [Sip] > comments and nits on bis-07) > > > > > Hisham Khartabil wrote: > > > > >>-----Original Message----- > >>From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > >>Sent: Monday, 18 February 2002 1:17 AM > >>To: Hisham Khartabil > >>Cc: sip@ietf.org; jdrosen@dynamicsoft.com; gonzalo.camarillo > >>Subject: Re: [Sip] comments and nits on bis-07 > >> > > > >>>- line 1697: why is it a MUST for a contact header to contain > >>> > >>an "expires" > >> > >>>parameter? > >>> > >> > >>This is how the registrar communicates how much longer the > >>binding will last > >>back to the client. > >> > > > > You misunderstood my question. Anyway, from your comment, I > gather that an > > Expires header in a 200 response to a REGISTER is Optional. Is > that correct? > > Can an entry in table 2 be added to reflect that? > > > The table already says that (and empty cell in the "where" column means > requests and responses. > > Yes - the Expires header field in a 200 response to a REGISTER request is > allowed. It also has no meaning with respect to the Contacts in > the response > since each provided Contact MUST contain an ;expires= parameter. > (Note to casual readers - this is a statement about the _response_, not > the REGISTER request) > > So - help me understand your original question. Is it "why don't you allow > the "use the expires parameter if present, otherwise use the > Expires header > value in REGISTER responses like you do in REGISTER requests?". Yes, that was exactly what I asked. If its not so, what does an Expires header in a 200 OK for a REGISTER mean? > > I can't think of a good reason right now. Jonathan? > > I will note that its critically important for Contact values in > 3xx responses > to contain their own expires parameter (since proxies can > aggregate contacts > from multiple 3xx's received at a fork-point). > > 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 daemon@optimus.ietf.org Tue Feb 19 11:05:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25421 for ; Tue, 19 Feb 2002 11:05:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15215 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 11:05:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13352; Tue, 19 Feb 2002 10:39:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13319 for ; Tue, 19 Feb 2002 10:39:12 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24294 for ; Tue, 19 Feb 2002 10:39:10 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA06092; Tue, 19 Feb 2002 10:38:50 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1JFcnNB008816 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Feb 2002 10:38:50 -0500 (EST) Message-ID: <3C727182.9C5130E5@cs.columbia.edu> Date: Tue, 19 Feb 2002 10:38:42 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: EKR CC: Michael Thomas , sip@ietf.org Subject: Re: [Sip] replays and SMIME References: <15474.26579.149575.12910@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit While limiting the time interval for replay via nonces is clearly a good thing, most stand-alone devices will probably get a few dozen calls a day, at most, and the ones I know already log those calls for user convenience. Thus, I doubt that this is a big problem in practice, given that the amount that needs to be logged is probably a few tens of bytes per call (the Call-ID would do, in all likelihood). Beyond that, a Date header that's more than a day out of whack is probably a good-enough clue. There's no reason not to have SNTP on a UA - we don't have to repeat the ISDN mistake where you buy a $500 ISDN phone and then have to set the time manually. Eric Rescorla wrote: > > Retransmitting, since I sent the first reply to Michael alone. > > Michael Thomas writes: > > So I'm not terribly familiar with SMIME so I was > > curious how replay detection was performed. > In general, S/MIME doesn't worry much about replay protection. > > >In > >any case, if we're going to have replay detection > >for SMIME bodies, I think we're going to need a > >better scheme here. > I agree. What I had in mind was using essentially the same mechanism > that is use with Digest: a series of nonces that must be echoed in the > message to ensure freshness. The alternative, of course, is to use > sequence numbers a la IPsec, but this requires storage for each > client. > > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.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 daemon@optimus.ietf.org Tue Feb 19 11:10:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25619 for ; Tue, 19 Feb 2002 11:10:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15458 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 11:10:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13839; Tue, 19 Feb 2002 10:48:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13810 for ; Tue, 19 Feb 2002 10:48:18 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24594 for ; Tue, 19 Feb 2002 10:48:13 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1JCaHhM014190 for ; Tue, 19 Feb 2002 13:36:17 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1JCaGr6014879 for ; Tue, 19 Feb 2002 14:36:16 +0200 (EET) Message-ID: <3C7246F9.6E84500B@lmf.ericsson.se> Date: Tue, 19 Feb 2002 14:37:13 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] MINOR comment on bis-7.9 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A very small comment on bis-7.9. Chapter 8.2.2.2 says: "If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the To tag, From tag, Call-ID, CSeq exactly match (including tags)..." Since the text in the beginning says that this apply when there is no tag in the To header, I don't think it is needed to later mention that the To tag needs to match. I also think the "(including tags)" part is not needed. Regards, Christer Holmberg Ericsson 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 daemon@optimus.ietf.org Tue Feb 19 11:13:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25790 for ; Tue, 19 Feb 2002 11:13:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15673 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 11:13:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13959; Tue, 19 Feb 2002 10:50:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13928 for ; Tue, 19 Feb 2002 10:50:36 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24738 for ; Tue, 19 Feb 2002 10:50:34 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 19 Feb 2002 15:50:50 UT content-class: urn:content-classes:message Subject: RE: [Sip] replays and SMIME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Tue, 19 Feb 2002 15:52:48 -0000 Message-ID: <45730E094814E44488F789C1CDED27AEC552AD@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] replays and SMIME Thread-Index: AcG5WPdTKX4NTFPLSXaAIEwO/vFiZAAAi+MA From: "James Undery" To: "EKR" , "Michael Thomas" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA13929 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Michael Thomas writes: > > So I'm not terribly familiar with SMIME so I was > > curious how replay detection was performed. > In general, S/MIME doesn't worry much about replay protection. > > >In > >any case, if we're going to have replay detection > >for SMIME bodies, I think we're going to need a > >better scheme here. > I agree. What I had in mind was using essentially the same mechanism > that is use with Digest: a series of nonces that must be echoed in the > message to ensure freshness. The alternative, of course, is to use > sequence numbers a la IPsec, but this requires storage for each > client. Without wishing to sound pedantic or put words into your mouth, what your looking for is just a nonce distribution scheme. For the I-D draft-undery-sip-auth-00.txt we tried to get away from digest and generalise the HTTP authentication framework; from the little I understand of SMIME something along the lines of... challenge = "SMIME" nonce credentials "SMIME" nonce cnonce scheme = "SMIME" info-credentials = nextnonce cnonce is all that is needed to work with our framework only leaving how the nonce is included into the SMIME body, which superficially would be to include the relevant headers. Obviously this is off the top of my head and should be taken as the ramblings of an idiot. 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 daemon@optimus.ietf.org Tue Feb 19 11:35:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26471 for ; Tue, 19 Feb 2002 11:35:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17192 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 11:35:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14587; Tue, 19 Feb 2002 11:00:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14556 for ; Tue, 19 Feb 2002 11:00:20 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25220 for ; Tue, 19 Feb 2002 11:00:17 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1JG0c120851; Tue, 19 Feb 2002 08:00:38 -0800 (PST) To: "James Undery" Cc: "Michael Thomas" , Subject: Re: [Sip] replays and SMIME References: <45730E094814E44488F789C1CDED27AEC552AD@GBNEWP0758M.eu.ubiquity.net> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 19 Feb 2002 08:00:38 -0800 In-Reply-To: "James Undery"'s message of "Tue, 19 Feb 2002 15:52:48 -0000" Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org "James Undery" writes: > is all that is needed to work with our framework only leaving how the > nonce is included into the SMIME body, which superficially would be to > include the relevant headers. Obviously this is off the top of my head > and should be taken as the ramblings of an idiot. Yes, this is more or less what I had in mind, but your draft is a lot more complicated than what we'd need for this purpose, I suspect. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Tue Feb 19 11:35:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26494 for ; Tue, 19 Feb 2002 11:35:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17208 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 11:35:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15050; Tue, 19 Feb 2002 11:02:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14944 for ; Tue, 19 Feb 2002 11:01:57 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25268 for ; Tue, 19 Feb 2002 11:01:55 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1JG1l420854; Tue, 19 Feb 2002 08:01:47 -0800 (PST) To: Henning Schulzrinne Cc: Michael Thomas , sip@ietf.org Subject: Re: [Sip] replays and SMIME References: <15474.26579.149575.12910@thomasm-u1.cisco.com> <3C727182.9C5130E5@cs.columbia.edu> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 19 Feb 2002 08:01:47 -0800 In-Reply-To: Henning Schulzrinne's message of "Tue, 19 Feb 2002 10:38:42 -0500" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Henning Schulzrinne writes: > While limiting the time interval for replay via nonces is clearly a good > thing, most stand-alone devices will probably get a few dozen calls a > day, at most, and the ones I know already log those calls for user > convenience. Thus, I doubt that this is a big problem in practice, given > that the amount that needs to be logged is probably a few tens of bytes > per call (the Call-ID would do, in all likelihood). Beyond that, a Date > header that's more than a day out of whack is probably a good-enough > clue. There's no reason not to have SNTP on a UA - we don't have to > repeat the ISDN mistake where you buy a $500 ISDN phone and then have to > set the time manually. I'm thinking of a future where Digest has been displaced by S/MIME with a shared key. In this instance proxies would have a lot of traffic and the storage requirements could be substantial. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Tue Feb 19 11:42:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26742 for ; Tue, 19 Feb 2002 11:42:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17613 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 11:42:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15537; Tue, 19 Feb 2002 11:10:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15508 for ; Tue, 19 Feb 2002 11:10:32 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25638 for ; Tue, 19 Feb 2002 11:10:30 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 19 Feb 2002 16:10:47 UT content-class: urn:content-classes:message Subject: RE: [Sip] replays and SMIME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Tue, 19 Feb 2002 16:12:45 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE012F827C@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] replays and SMIME Thread-Index: AcG5XsUJVnLo/SSNTzKGSB9464+CwQAARXHA From: "James Undery" To: "EKR" Cc: "Michael Thomas" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA15509 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > "James Undery" writes: > > is all that is needed to work with our framework only > leaving how the > > nonce is included into the SMIME body, which superficially > would be to > > include the relevant headers. Obviously this is off the top > of my head > > and should be taken as the ramblings of an idiot. > Yes, this is more or less what I had in mind, but your draft is > a lot more complicated than what we'd need for this purpose, > I suspect. Ironically I might argue the reverse ;-), however, back to the point, in my opinion the complexity of our draft is in the Digest portion, the framework itself is light. 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 daemon@optimus.ietf.org Tue Feb 19 11:50:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27009 for ; Tue, 19 Feb 2002 11:50:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17924 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 11:51:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15855; Tue, 19 Feb 2002 11:17:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15826 for ; Tue, 19 Feb 2002 11:17:42 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25890 for ; Tue, 19 Feb 2002 11:17:40 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1JG4Ym01372; Tue, 19 Feb 2002 10:04:34 -0600 Message-ID: <3C727792.9050105@dynamicsoft.com> Date: Tue, 19 Feb 2002 10:04:34 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Hisham Khartabil CC: sip@ietf.org, jdrosen@dynamicsoft.com, "gonzalo.camarillo" Subject: Re: Expires heade field in REGISTER responses: (was Re: [Sip] comments and nits on bis-07) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit (trimming) >>Yes - the Expires header field in a 200 response to a REGISTER request is >>allowed. It also has no meaning with respect to the Contacts in >>the response >>since each provided Contact MUST contain an ;expires= parameter. >>(Note to casual readers - this is a statement about the _response_, not >> the REGISTER request) >> >>So - help me understand your original question. Is it "why don't you allow >>the "use the expires parameter if present, otherwise use the >>Expires header >>value in REGISTER responses like you do in REGISTER requests?". >> > > Yes, that was exactly what I asked. If its not so, what does an Expires > header in a 200 OK for a REGISTER mean? As I note above, with the current text an Expire header field has no meaning if it appears in a 200 response to a REGISTER request. > > > >>I can't think of a good reason right now. Jonathan? >> >>I will note that its critically important for Contact values in >>3xx responses >>to contain their own expires parameter (since proxies can >>aggregate contacts >>from multiple 3xx's received at a fork-point). >> >>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 daemon@optimus.ietf.org Tue Feb 19 11:56:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27353 for ; Tue, 19 Feb 2002 11:56:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18488 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 11:56:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16219; Tue, 19 Feb 2002 11:26:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16189 for ; Tue, 19 Feb 2002 11:26:45 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26248 for ; Tue, 19 Feb 2002 11:26:43 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1JGPih16402; Tue, 19 Feb 2002 08:25:44 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX41536; Tue, 19 Feb 2002 08:25:15 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA29477; Tue, 19 Feb 2002 08:25:42 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.31878.619345.756332@thomasm-u1.cisco.com> Date: Tue, 19 Feb 2002 08:25:42 -0800 (PST) To: Henning Schulzrinne Cc: EKR , Michael Thomas , sip@ietf.org Subject: Re: [Sip] replays and SMIME In-Reply-To: <3C727182.9C5130E5@cs.columbia.edu> References: <15474.26579.149575.12910@thomasm-u1.cisco.com> <3C727182.9C5130E5@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > While limiting the time interval for replay via nonces is clearly a good > thing, most stand-alone devices will probably get a few dozen calls a > day, at most, and the ones I know already log those calls for user > convenience. Thus, I doubt that this is a big problem in practice, given > that the amount that needs to be logged is probably a few tens of bytes > per call (the Call-ID would do, in all likelihood). Beyond that, a Date > header that's more than a day out of whack is probably a good-enough > clue. There's no reason not to have SNTP on a UA - we don't have to > repeat the ISDN mistake where you buy a $500 ISDN phone and then have to > set the time manually. Uh, no. You're supposed to record it by public key which are, what, 128 bytes? Even the if you recorded it by DN, it would probably chew quite a bit more than 10's of bytes. In any case, this is an entropy problem; every call you get with SMIME would need to be recorded forever. I don't know what the current parameter flash sectors are today, but last I looked they were typically < 10kb. Not good. 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 daemon@optimus.ietf.org Tue Feb 19 12:02:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27597 for ; Tue, 19 Feb 2002 12:02:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20189 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 12:02:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16368; Tue, 19 Feb 2002 11:29:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16337 for ; Tue, 19 Feb 2002 11:29:39 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26317 for ; Tue, 19 Feb 2002 11:29:36 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1JGTqk20879; Tue, 19 Feb 2002 08:29:52 -0800 (PST) To: Michael Thomas Cc: Henning Schulzrinne , sip@ietf.org Subject: Re: [Sip] replays and SMIME References: <15474.26579.149575.12910@thomasm-u1.cisco.com> <3C727182.9C5130E5@cs.columbia.edu> <15474.31878.619345.756332@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 19 Feb 2002 08:29:52 -0800 In-Reply-To: Michael Thomas's message of "Tue, 19 Feb 2002 08:25:42 -0800 (PST)" Message-ID: Lines: 34 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > Henning Schulzrinne writes: > > While limiting the time interval for replay via nonces is clearly a good > > thing, most stand-alone devices will probably get a few dozen calls a > > day, at most, and the ones I know already log those calls for user > > convenience. Thus, I doubt that this is a big problem in practice, given > > that the amount that needs to be logged is probably a few tens of bytes > > per call (the Call-ID would do, in all likelihood). Beyond that, a Date > > header that's more than a day out of whack is probably a good-enough > > clue. There's no reason not to have SNTP on a UA - we don't have to > > repeat the ISDN mistake where you buy a $500 ISDN phone and then have to > > set the time manually. > > Uh, no. You're supposed to record it by public key > which are, what, 128 bytes? Even the if you > recorded it by DN, it would probably chew quite > a bit more than 10's of bytes. > > In any case, this is an entropy problem; every > call you get with SMIME would need to be > recorded forever. I don't know what the current > parameter flash sectors are today, but last I > looked they were typically < 10kb. Not good. Well, you could always record by digest of public key instead of DN or PK, which alleviates the problem some. But I agree with your main point. Replay-detection systems must require only limited storage on the recipient's side. This generally means nonces. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Tue Feb 19 12:06:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27734 for ; Tue, 19 Feb 2002 12:06:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20659 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 12:06:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17283; Tue, 19 Feb 2002 11:36:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17251 for ; Tue, 19 Feb 2002 11:36:35 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26527 for ; Tue, 19 Feb 2002 11:36:33 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA10804; Tue, 19 Feb 2002 11:36:12 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1JGaBNB011877 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Feb 2002 11:36:12 -0500 (EST) Message-ID: <3C727EF4.44A8861D@cs.columbia.edu> Date: Tue, 19 Feb 2002 11:36:04 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: EKR , sip@ietf.org Subject: Re: [Sip] replays and SMIME References: <15474.26579.149575.12910@thomasm-u1.cisco.com> <3C727182.9C5130E5@cs.columbia.edu> <15474.31878.619345.756332@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > In any case, this is an entropy problem; every > call you get with SMIME would need to be > recorded forever. I don't know what the current Not true; if you read my message, you might note that I said that if you assume even the most loose of clock synchronization constraints (one day), you could automatically discard any message that's off by more than a day. > parameter flash sectors are today, but last I > looked they were typically < 10kb. Not good. > > 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 daemon@optimus.ietf.org Tue Feb 19 12:13:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28003 for ; Tue, 19 Feb 2002 12:13:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21207 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 12:13:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17141; Tue, 19 Feb 2002 11:34:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17107 for ; Tue, 19 Feb 2002 11:34:21 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26454 for ; Tue, 19 Feb 2002 11:34:19 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1JGVlQl010819; Tue, 19 Feb 2002 11:31:47 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Feb 2002 11:33:50 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F363007A@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'James Undery'" , Adam Roach , sip@ietf.org Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! Date: Tue, 19 Feb 2002 11:33:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks. This has now been corrected. (We also use a hex notation now for the method names, like bis-07). /a > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Tuesday, February 19, 2002 3:34 AM > To: James Undery; Adam Roach; sip@ietf.org > Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! > > > Ooops hit send too soon another v. minor nit; the BNF uses '|' instead > of the rfc2234 '/' the bis has now adopted. > > 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 daemon@optimus.ietf.org Tue Feb 19 12:29:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28375 for ; Tue, 19 Feb 2002 12:29:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22015 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 12:29:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18592; Tue, 19 Feb 2002 11:57:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18562 for ; Tue, 19 Feb 2002 11:57:23 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27417 for ; Tue, 19 Feb 2002 11:57:21 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1JGugZ20791; Tue, 19 Feb 2002 08:56:42 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX42105; Tue, 19 Feb 2002 08:56:23 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA29489; Tue, 19 Feb 2002 08:56:51 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.33746.916872.717934@thomasm-u1.cisco.com> Date: Tue, 19 Feb 2002 08:56:50 -0800 (PST) To: EKR Cc: Michael Thomas , Henning Schulzrinne , sip@ietf.org Subject: Re: [Sip] replays and SMIME In-Reply-To: References: <15474.26579.149575.12910@thomasm-u1.cisco.com> <3C727182.9C5130E5@cs.columbia.edu> <15474.31878.619345.756332@thomasm-u1.cisco.com> <15474.33166.333666.470948@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric Rescorla writes: > Michael Thomas writes: > > The main problem with nonces is that they add the > > challenge, which amounts to another round trip. > Yes. Of course, we've already sucked this up with Digest, so > it doesn't bother me that much. Right, though eliminating the need for a challenge would still be helpful even there. I don't know if you've seen the call flows with preconditions, etc, but the number of messages flying by is getting pretty horrendous. > > Another way we could do this is to use > > a Kerberos-like replay detection which requires > > loose time synchronization. This retains the > > ability to send signed data blindly. Given the > > ability to reject things which are out of the > > window, it reverts to the same behavior of > > nonces, but if clocks are generally close you > > wouldn't normally need the initial challenge. > I'm assuming you're thinking that you'd retain a list of all > messages received within the window? > > This sounds like a reasonable approach. Yes, that's what Kerberos' replay cache presumes. Typically it's about 5 minutes worth. That should be pretty workable for UA's... 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 daemon@optimus.ietf.org Tue Feb 19 12:29:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28389 for ; Tue, 19 Feb 2002 12:29:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22036 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 12:29:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18033; Tue, 19 Feb 2002 11:51:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17996 for ; Tue, 19 Feb 2002 11:51:31 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27035 for ; Tue, 19 Feb 2002 11:51:29 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1JGoFZ17602; Tue, 19 Feb 2002 08:50:18 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX41974; Tue, 19 Feb 2002 08:49:57 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA29486; Tue, 19 Feb 2002 08:50:24 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.33360.439318.809377@thomasm-u1.cisco.com> Date: Tue, 19 Feb 2002 08:50:24 -0800 (PST) To: Henning Schulzrinne Cc: Michael Thomas , EKR , sip@ietf.org Subject: Re: [Sip] replays and SMIME In-Reply-To: <3C727EF4.44A8861D@cs.columbia.edu> References: <15474.26579.149575.12910@thomasm-u1.cisco.com> <3C727182.9C5130E5@cs.columbia.edu> <15474.31878.619345.756332@thomasm-u1.cisco.com> <3C727EF4.44A8861D@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > > In any case, this is an entropy problem; every > > call you get with SMIME would need to be > > recorded forever. I don't know what the current > > Not true; if you read my message, you might note that I said that if you > assume even the most loose of clock synchronization constraints (one > day), you could automatically discard any message that's off by more > than a day. Um, Henning. It might help if you actually read the section. This is not what it says at all. 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 daemon@optimus.ietf.org Tue Feb 19 12:34:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28532 for ; Tue, 19 Feb 2002 12:34:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22673 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 12:34:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17830; Tue, 19 Feb 2002 11:47:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17799 for ; Tue, 19 Feb 2002 11:47:46 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26886 for ; Tue, 19 Feb 2002 11:47:44 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1JGlBE24053; Tue, 19 Feb 2002 08:47:11 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX41899; Tue, 19 Feb 2002 08:46:42 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA29483; Tue, 19 Feb 2002 08:47:10 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.33166.333666.470948@thomasm-u1.cisco.com> Date: Tue, 19 Feb 2002 08:47:10 -0800 (PST) To: EKR Cc: Michael Thomas , Henning Schulzrinne , sip@ietf.org Subject: Re: [Sip] replays and SMIME In-Reply-To: References: <15474.26579.149575.12910@thomasm-u1.cisco.com> <3C727182.9C5130E5@cs.columbia.edu> <15474.31878.619345.756332@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric Rescorla writes: > Michael Thomas writes: > > In any case, this is an entropy problem; every > > call you get with SMIME would need to be > > recorded forever. I don't know what the current > > parameter flash sectors are today, but last I > > looked they were typically < 10kb. Not good. > Well, you could always record by digest of public key instead of > DN or PK, which alleviates the problem some. But I agree with your > main point. Replay-detection systems must require only limited > storage on the recipient's side. This generally means nonces. The main problem with nonces is that they add the challenge, which amounts to another round trip. If you extended this for the middle-middle case (eg for caller ID), this starts looking pretty messy, and eliminates the ability to take advantage of one of the really nice features of public key crypto -- that is, you can sign something without knowing its ultimate destination. This is actually pretty useful in some cases, especially if the UA and/or proxy knows that some piece of data will need authenticated a priori. Another way we could do this is to use a Kerberos-like replay detection which requires loose time synchronization. This retains the ability to send signed data blindly. Given the ability to reject things which are out of the window, it reverts to the same behavior of nonces, but if clocks are generally close you wouldn't normally need the initial challenge. 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 daemon@optimus.ietf.org Tue Feb 19 12:37:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28611 for ; Tue, 19 Feb 2002 12:37:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22820 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 12:37:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17987; Tue, 19 Feb 2002 11:51:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17956 for ; Tue, 19 Feb 2002 11:51:25 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27031 for ; Tue, 19 Feb 2002 11:51:22 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1JGpVb20930; Tue, 19 Feb 2002 08:51:31 -0800 (PST) To: Michael Thomas Cc: Henning Schulzrinne , sip@ietf.org Subject: Re: [Sip] replays and SMIME References: <15474.26579.149575.12910@thomasm-u1.cisco.com> <3C727182.9C5130E5@cs.columbia.edu> <15474.31878.619345.756332@thomasm-u1.cisco.com> <15474.33166.333666.470948@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 19 Feb 2002 08:51:31 -0800 In-Reply-To: Michael Thomas's message of "Tue, 19 Feb 2002 08:47:10 -0800 (PST)" Message-ID: Lines: 38 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > Eric Rescorla writes: > > Michael Thomas writes: > > > In any case, this is an entropy problem; every > > > call you get with SMIME would need to be > > > recorded forever. I don't know what the current > > > parameter flash sectors are today, but last I > > > looked they were typically < 10kb. Not good. > > Well, you could always record by digest of public key instead of > > DN or PK, which alleviates the problem some. But I agree with your > > main point. Replay-detection systems must require only limited > > storage on the recipient's side. This generally means nonces. > > The main problem with nonces is that they add the > challenge, which amounts to another round trip. Yes. Of course, we've already sucked this up with Digest, so it doesn't bother me that much. > Another way we could do this is to use > a Kerberos-like replay detection which requires > loose time synchronization. This retains the > ability to send signed data blindly. Given the > ability to reject things which are out of the > window, it reverts to the same behavior of > nonces, but if clocks are generally close you > wouldn't normally need the initial challenge. I'm assuming you're thinking that you'd retain a list of all messages received within the window? This sounds like a reasonable approach. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Tue Feb 19 12:38:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28675 for ; Tue, 19 Feb 2002 12:38:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22881 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 12:38:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19971; Tue, 19 Feb 2002 12:01:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19921 for ; Tue, 19 Feb 2002 12:01:20 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27560 for ; Tue, 19 Feb 2002 12:01:18 -0500 (EST) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA12536 for ; Tue, 19 Feb 2002 12:01:20 -0500 (EST) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1JH1KtN008156 for ; Tue, 19 Feb 2002 12:01:20 -0500 (EST) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.1/8.12.1/Submit) id g1JH1J3h008153; Tue, 19 Feb 2002 12:01:19 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.34014.724733.320958@grandcentral.cs.columbia.edu> Date: Tue, 19 Feb 2002 12:01:18 -0500 To: sip@ietf.org X-Mailer: VM 6.98 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit Subject: [Sip] Remaining uses of <"> in bis-07.9 BNF Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit A minor nit: bis-07.9 still uses the prose value <"> to represent a double-quote its BNF in a few places, even though it was supposed to switch to DQUOTE. This appears in the BNF definitions of 'word', 'separators', and 'quoted-string' (twice). -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 12:45:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28879 for ; Tue, 19 Feb 2002 12:45:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23344 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 12:45:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20554; Tue, 19 Feb 2002 12:04:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20495 for ; Tue, 19 Feb 2002 12:04:54 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27689 for ; Tue, 19 Feb 2002 12:04:52 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA12805; Tue, 19 Feb 2002 12:04:47 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1JH4kNB013331 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Feb 2002 12:04:47 -0500 (EST) Message-ID: <3C7285A7.B69F780E@cs.columbia.edu> Date: Tue, 19 Feb 2002 12:04:39 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: EKR , sip@ietf.org Subject: Re: [Sip] replays and SMIME References: <15474.26579.149575.12910@thomasm-u1.cisco.com> <3C727182.9C5130E5@cs.columbia.edu> <15474.31878.619345.756332@thomasm-u1.cisco.com> <3C727EF4.44A8861D@cs.columbia.edu> <15474.33360.439318.809377@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit You said "forever", I said "that's not true", which you then confirmed in the Kerberos case, for an even smaller window. I'm lost as to what I'm missing. Michael Thomas wrote: > > Henning Schulzrinne writes: > > > In any case, this is an entropy problem; every > > > call you get with SMIME would need to be > > > recorded forever. I don't know what the current > > > > Not true; if you read my message, you might note that I said that if you > > assume even the most loose of clock synchronization constraints (one > > day), you could automatically discard any message that's off by more > > than a day. > > Um, Henning. It might help if you actually read > the section. This is not what it says at all. > > 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 daemon@optimus.ietf.org Tue Feb 19 12:48:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28958 for ; Tue, 19 Feb 2002 12:48:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23414 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 12:48:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21121; Tue, 19 Feb 2002 12:12:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21092 for ; Tue, 19 Feb 2002 12:12:16 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27935 for ; Tue, 19 Feb 2002 12:12:13 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1JHCFT20958; Tue, 19 Feb 2002 09:12:15 -0800 (PST) To: Michael Thomas Cc: Henning Schulzrinne , sip@ietf.org Subject: Re: [Sip] replays and SMIME References: <15474.26579.149575.12910@thomasm-u1.cisco.com> <3C727182.9C5130E5@cs.columbia.edu> <15474.31878.619345.756332@thomasm-u1.cisco.com> <15474.33166.333666.470948@thomasm-u1.cisco.com> <15474.33746.916872.717934@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 19 Feb 2002 09:12:15 -0800 In-Reply-To: Michael Thomas's message of "Tue, 19 Feb 2002 08:56:50 -0800 (PST)" Message-ID: Lines: 20 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > Eric Rescorla writes: > > Michael Thomas writes: > > > The main problem with nonces is that they add the > > > challenge, which amounts to another round trip. > > Yes. Of course, we've already sucked this up with Digest, so > > it doesn't bother me that much. > > Right, though eliminating the need for a challenge > would still be helpful even there. I don't know > if you've seen the call flows with preconditions, > etc, but the number of messages flying by is > getting pretty horrendous. It looked pretty horrendous to me too :( -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Tue Feb 19 12:50:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29018 for ; Tue, 19 Feb 2002 12:50:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23497 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 12:50:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21493; Tue, 19 Feb 2002 12:18:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21462 for ; Tue, 19 Feb 2002 12:18:27 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28112 for ; Tue, 19 Feb 2002 12:18:24 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1JHHpE14948 for ; Tue, 19 Feb 2002 09:17:55 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX42527; Tue, 19 Feb 2002 09:17:23 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA29503; Tue, 19 Feb 2002 09:17:50 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.35006.716924.153511@thomasm-u1.cisco.com> Date: Tue, 19 Feb 2002 09:17:50 -0800 (PST) To: sip@ietf.org X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [Sip] restatement of required ciphers in section 21 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Right now, there is a restatement of the required ciphers in section 21. RFC 2633 already specifies the minimum so I don't see a huge to further profile it. The big downside, however, is that we want to move to AES in the future so saying something about 3des in bis will further complicate this. This text should just be removed. 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 daemon@optimus.ietf.org Tue Feb 19 12:54:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29208 for ; Tue, 19 Feb 2002 12:54:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23689 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 12:54:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21419; Tue, 19 Feb 2002 12:17:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21385 for ; Tue, 19 Feb 2002 12:17:10 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28037 for ; Tue, 19 Feb 2002 12:14:29 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1JHDLZ29600; Tue, 19 Feb 2002 09:13:21 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX42434; Tue, 19 Feb 2002 09:13:03 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA29500; Tue, 19 Feb 2002 09:13:30 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.34746.467747.496076@thomasm-u1.cisco.com> Date: Tue, 19 Feb 2002 09:13:30 -0800 (PST) To: Henning Schulzrinne Cc: Michael Thomas , EKR , sip@ietf.org Subject: Re: [Sip] replays and SMIME In-Reply-To: <3C7285A7.B69F780E@cs.columbia.edu> References: <15474.26579.149575.12910@thomasm-u1.cisco.com> <3C727182.9C5130E5@cs.columbia.edu> <15474.31878.619345.756332@thomasm-u1.cisco.com> <3C727EF4.44A8861D@cs.columbia.edu> <15474.33360.439318.809377@thomasm-u1.cisco.com> <3C7285A7.B69F780E@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > You said "forever", I said "that's not true", which you then confirmed > in the Kerberos case, for an even smaller window. I'm lost as to what > I'm missing. SMIME doesn't say anything about deleting entries of this list. It's assumed they be kept indefinitely. This is also tied up with cipher suite agreement. Read RFC 2633. As for use of a nonce or time based replay detection, those are potential ways of getting around this problem with RFC 2633 SMIME. They are not standard. Mike > > Michael Thomas wrote: > > > > Henning Schulzrinne writes: > > > > In any case, this is an entropy problem; every > > > > call you get with SMIME would need to be > > > > recorded forever. I don't know what the current > > > > > > Not true; if you read my message, you might note that I said that if you > > > assume even the most loose of clock synchronization constraints (one > > > day), you could automatically discard any message that's off by more > > > than a day. > > > > Um, Henning. It might help if you actually read > > the section. This is not what it says at all. > > > > 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 daemon@optimus.ietf.org Tue Feb 19 12:54:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29226 for ; Tue, 19 Feb 2002 12:54:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23710 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 12:54:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21683; Tue, 19 Feb 2002 12:21:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21652 for ; Tue, 19 Feb 2002 12:21:10 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28155 for ; Tue, 19 Feb 2002 12:21:08 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1JHIbQl011397; Tue, 19 Feb 2002 12:18:37 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGHM8>; Tue, 19 Feb 2002 12:20:38 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F363007E@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'James Undery'" , Adam Roach , sip@ietf.org Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! Date: Tue, 19 Feb 2002 12:20:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > > 6.1. s/user/resource/ (also section 3 might do with a > > consistent name > > > for the entity the state describes) > > > > Actually, we really mean user. Human. The person who owns the > > resource, not the resource itself. It's an important distinction. > > In that case may I suggest s/user/local policy/ as it is REALLY > important a human need not be involved. Perhaps in some sort of a post-apocalyptic world portrayed in the movie "Terminator" and its sequels, this would be correct. For the time being -- and until machines acheive a frightening level of sentience -- I'd expect humans to be in charge of determining what does and does not constitute an acceptable subscription. I don't mean real-time, and I don't mean for every single subscription on a one-by-one basis. Installing a local policy would place the ability to accept subscriptions under the direct control of the user, which is all this section suggests. > > > 6.3. 3rd para. s/of notifiers/accepting subscriptions/ > > > > Notifiers is a defined term; we describe accepting > > SUBSCRIBE messages in the definition of a notifier. > > I think your suggested change would actually cause more > > confusion than it avoids. > > Where as I'd hate to introduce the braindead arguments people > have over > location servers, registrars and proxies. The entity that accepts the > subscription and the entity that's the notifier are logically > distinct. Do you see the term "UA" as useful? It has component parts that are individually a UAS and a UAC, but we use the term "UA" all over the place. Notifiers are a special kind of UA -- ones which accept SUBSCRIBE messages and generate NOTIFY messages. I don't really want to invent new terms to describe the two halves of this special UA; it would be inventing terms for the sake of inventing terms instead of for clarity. /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 daemon@optimus.ietf.org Tue Feb 19 13:07:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29695 for ; Tue, 19 Feb 2002 13:07:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24580 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 13:07:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22948; Tue, 19 Feb 2002 12:39:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22922 for ; Tue, 19 Feb 2002 12:39:14 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28712 for ; Tue, 19 Feb 2002 12:39:11 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA16505; Tue, 19 Feb 2002 12:39:02 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1JHd1NB014794 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Feb 2002 12:39:02 -0500 (EST) Message-ID: <3C728DAE.4B3DE992@cs.columbia.edu> Date: Tue, 19 Feb 2002 12:38:54 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: EKR , sip@ietf.org Subject: Re: [Sip] replays and SMIME References: <15474.26579.149575.12910@thomasm-u1.cisco.com> <3C727182.9C5130E5@cs.columbia.edu> <15474.31878.619345.756332@thomasm-u1.cisco.com> <3C727EF4.44A8861D@cs.columbia.edu> <15474.33360.439318.809377@thomasm-u1.cisco.com> <3C7285A7.B69F780E@cs.columbia.edu> <15474.34746.467747.496076@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit For SMTP, that makes sense, as SMTP messages can stick around for days, if not longer. Nothing keeps us from modifying the replay detection behavior for SIP, with its much shorter maximum message lifetimes measured in seconds. Michael Thomas wrote: > > Henning Schulzrinne writes: > > You said "forever", I said "that's not true", which you then confirmed > > in the Kerberos case, for an even smaller window. I'm lost as to what > > I'm missing. > > SMIME doesn't say anything about deleting entries > of this list. It's assumed they be kept indefinitely. > This is also tied up with cipher suite agreement. > Read RFC 2633. > > As for use of a nonce or time based replay detection, > those are potential ways of getting around this > problem with RFC 2633 SMIME. They are not standard. > > Mike > > > > > Michael Thomas wrote: > > > > > > Henning Schulzrinne writes: > > > > > In any case, this is an entropy problem; every > > > > > call you get with SMIME would need to be > > > > > recorded forever. I don't know what the current > > > > > > > > Not true; if you read my message, you might note that I said that if you > > > > assume even the most loose of clock synchronization constraints (one > > > > day), you could automatically discard any message that's off by more > > > > than a day. > > > > > > Um, Henning. It might help if you actually read > > > the section. This is not what it says at all. > > > > > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 13:14:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29975 for ; Tue, 19 Feb 2002 13:14:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24811 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 13:14:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23064; Tue, 19 Feb 2002 12:40:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23023 for ; Tue, 19 Feb 2002 12:40:45 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28746 for ; Tue, 19 Feb 2002 12:40:42 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 19 Feb 2002 17:40:59 UT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Tue, 19 Feb 2002 17:42:58 -0000 Message-ID: <45730E094814E44488F789C1CDED27AEC552AE@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Reminder: SIP Events WGLC Ending Soon! Thread-Index: AcG5ahDNWW7QrXw1RnCVuF847vgYmAAAJt+A From: "James Undery" To: "Adam Roach" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA23024 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 19 February 2002 17:21 > To: James Undery; Adam Roach; sip@ietf.org > Subject: RE: [Sip] Reminder: SIP Events WGLC Ending Soon! > > > > > > 6.1. s/user/resource/ (also section 3 might do with a > > > consistent name > > > > for the entity the state describes) > > > > > > Actually, we really mean user. Human. The person who owns the > > > resource, not the resource itself. It's an important distinction. > > > > In that case may I suggest s/user/local policy/ as it is REALLY > > important a human need not be involved. > > Perhaps in some sort of a post-apocalyptic world portrayed in > the movie "Terminator" and its sequels, this would be correct. > > For the time being -- and until machines acheive a frightening > level of sentience -- I'd expect humans to be in charge of > determining what does and does not constitute an acceptable > subscription. I don't mean real-time, and I don't mean for > every single subscription on a one-by-one basis. Installing a > local policy would place the ability to accept subscriptions > under the direct control of the user, which is all this section > suggests. user implies user interaction to my mind otherwise, I could describe your draft to the a user generates SUBSCRIBE messages a user responds, the user generates a NOTIFY a user generates a response. Very few packages are likely to require human interaction at an operator sits at his terminal fingers poised of the 'y' and 'n' keys level, which is why I object to this. It strikes me as very presence biased, but as I said non-normative text so I don't care. > > > > 6.3. 3rd para. s/of notifiers/accepting subscriptions/ > > > > > > Notifiers is a defined term; we describe accepting > > > SUBSCRIBE messages in the definition of a notifier. > > > I think your suggested change would actually cause more > > > confusion than it avoids. > > > > Where as I'd hate to introduce the braindead arguments people > > have over > > location servers, registrars and proxies. The entity that > accepts the > > subscription and the entity that's the notifier are logically > > distinct. > > Do you see the term "UA" as useful? It has component parts that > are individually a UAS and a UAC, but we use the term "UA" all > over the place. Notifiers are a special kind of UA -- ones which > accept SUBSCRIBE messages and generate NOTIFY messages. I don't > really want to invent new terms to describe the two halves of > this special UA; it would be inventing terms for the sake of > inventing terms instead of for clarity. The distinction is critical the entity accepting the SUBSCRIBE is a UAS, the entity generating a NOTIFY is a UAC. In the proxy world acting as a UAS is familiar registrar teritorry, UAC is new and frightening unless you're a b2bua weirdo. Without getting into architectual discussions I believe these are separate network components, but again non-normative text so I don't really care. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 13:22:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00258 for ; Tue, 19 Feb 2002 13:22:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25008 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 13:22:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23769; Tue, 19 Feb 2002 12:55:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23738 for ; Tue, 19 Feb 2002 12:55:23 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29272 for ; Tue, 19 Feb 2002 12:55:22 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1JHsLh20785; Tue, 19 Feb 2002 09:54:21 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX43451; Tue, 19 Feb 2002 09:53:52 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA29509; Tue, 19 Feb 2002 09:54:19 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.37195.720142.605994@thomasm-u1.cisco.com> Date: Tue, 19 Feb 2002 09:54:19 -0800 (PST) To: Henning Schulzrinne Cc: Michael Thomas , EKR , sip@ietf.org Subject: Re: [Sip] replays and SMIME In-Reply-To: <3C728DAE.4B3DE992@cs.columbia.edu> References: <15474.26579.149575.12910@thomasm-u1.cisco.com> <3C727182.9C5130E5@cs.columbia.edu> <15474.31878.619345.756332@thomasm-u1.cisco.com> <3C727EF4.44A8861D@cs.columbia.edu> <15474.33360.439318.809377@thomasm-u1.cisco.com> <3C7285A7.B69F780E@cs.columbia.edu> <15474.34746.467747.496076@thomasm-u1.cisco.com> <3C728DAE.4B3DE992@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > For SMTP, that makes sense, as SMTP messages can stick around for days, > if not longer. Nothing keeps us from modifying the replay detection > behavior for SIP, with its much shorter maximum message lifetimes > measured in seconds. The less loose you require clock syncrhonization, the more likely you are to have a time-skew rejection. This is the classic tradeoff with Kerberos-like replay detection. In general, clock skew is the rule, not the exception. Also: there is no way currently to tell the other side of a clock skew error. With Kerberos, this is a necessary component since it allows for adaptation to clock skew. Any time-based replay detection in SIP must do something similar. Mike > > Michael Thomas wrote: > > > > Henning Schulzrinne writes: > > > You said "forever", I said "that's not true", which you then confirmed > > > in the Kerberos case, for an even smaller window. I'm lost as to what > > > I'm missing. > > > > SMIME doesn't say anything about deleting entries > > of this list. It's assumed they be kept indefinitely. > > This is also tied up with cipher suite agreement. > > Read RFC 2633. > > > > As for use of a nonce or time based replay detection, > > those are potential ways of getting around this > > problem with RFC 2633 SMIME. They are not standard. > > > > Mike > > > > > > > > Michael Thomas wrote: > > > > > > > > Henning Schulzrinne writes: > > > > > > In any case, this is an entropy problem; every > > > > > > call you get with SMIME would need to be > > > > > > recorded forever. I don't know what the current > > > > > > > > > > Not true; if you read my message, you might note that I said that if you > > > > > assume even the most loose of clock synchronization constraints (one > > > > > day), you could automatically discard any message that's off by more > > > > > than a day. > > > > > > > > Um, Henning. It might help if you actually read > > > > the section. This is not what it says at all. > > > > > > > > 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 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Tue Feb 19 13:37:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00747 for ; Tue, 19 Feb 2002 13:37:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26105 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 13:37:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23878; Tue, 19 Feb 2002 12:58:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23853 for ; Tue, 19 Feb 2002 12:58:42 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29440 for ; Tue, 19 Feb 2002 12:58:41 -0500 (EST) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA21370 for ; Tue, 19 Feb 2002 12:58:41 -0500 (EST) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1JHwetN008788 for ; Tue, 19 Feb 2002 12:58:41 -0500 (EST) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.1/8.12.1/Submit) id g1JHweOM008785; Tue, 19 Feb 2002 12:58:40 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.37455.623505.609513@grandcentral.cs.columbia.edu> Date: Tue, 19 Feb 2002 12:58:39 -0500 To: sip@ietf.org X-Mailer: VM 6.98 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit Subject: [Sip] Another bis-07.9 BNF nit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The Bis 07.9 BNF doesn't allow for extension parameters to Accept-Language and Accept-Encoding. I assume this is accidental? (Discovered because a bug in my BNF parser is choking on those two headers, and I was trying to figure out how they were different than other grammar constructs in the syntax.) -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 15:06:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03655 for ; Tue, 19 Feb 2002 15:06:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00254 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 15:06:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28269; Tue, 19 Feb 2002 14:26:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28235 for ; Tue, 19 Feb 2002 14:26:41 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02257; Tue, 19 Feb 2002 14:26:39 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1JJO8Ql012819; Tue, 19 Feb 2002 14:24:09 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGH3R>; Tue, 19 Feb 2002 14:26:09 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630083@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach Reply-To: sip@ietf.org To: "'sip@ietf.org'" Cc: "'simple@ietf.org'" Date: Tue, 19 Feb 2002 14:26:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] draft-ietf-sip-events-03.txt available Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks to everyone who reviewed the SIP Events draft for WGLC. A new version of the draft taking these comments into account is now available. Until it appears in the archives, you can get a copy from: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-03.txt And, of course, the unofficial PDF version with changebars: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-03.pdf /Adam _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 15:14:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03919 for ; Tue, 19 Feb 2002 15:14:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00543 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 15:14:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29284; Tue, 19 Feb 2002 14:49:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29252 for ; Tue, 19 Feb 2002 14:49:32 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03139 for ; Tue, 19 Feb 2002 14:49:30 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.europe.nortel.com [47.164.128.120]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1JJmrr29999; Tue, 19 Feb 2002 14:48:53 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1JJmoj16024; Tue, 19 Feb 2002 20:48:50 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1JJmOg28802; Tue, 19 Feb 2002 19:48:24 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS8GVDN>; Tue, 19 Feb 2002 19:48:52 -0000 Message-ID: From: "Mark Watson" To: Jonathan Rosenberg Cc: sip@ietf.org Date: Tue, 19 Feb 2002 19:48:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B97E.724C85C0" Subject: [Sip] Unify & offers in responses (Question on bis-07) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B97E.724C85C0 Content-Type: text/plain Jonathan, If I understand rightly, the Unify proposal rules out SDP offers in responses to the INVITE, except the first offer (in the case of no offer in the INVITE). This is on the basis that after the initial offer/answer exchange, we would need to be able to reject such offers to deal with 'offer glare', and we have no means of rejecting an offer in a response, right ? (NB: it is just the SDP offer that we would need to reject, not the whole response) Is it possible that future extensions might plug this hole, and allow 'subsequent offers' in responses ? Or, are we requiring now that any such subsequent offers from the UAS use UPDATE ? I am wondering whether there are requirements for a new SDP offer to be semantically linked with a response to the INVITE, and in particular the 200 OK. e.g. your Early Media is 'sendonly' and the UAS wants to change the stream to 'sendrecv' on Answer. Is it OK to have separate operations for the change in dialog state and the change in media state ? or might these need to be linked in a single operation ? Regards...Mark ------_=_NextPart_001_01C1B97E.724C85C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Unify & offers in responses (Question on bis-07)

Jonathan,

If I understand rightly, the Unify proposal rules out = SDP offers in responses to the INVITE, except the first offer (in the = case of no offer in the INVITE).

This is on the basis that after the initial = offer/answer exchange, we would need to be able to reject such offers = to deal with 'offer glare', and we have no means of rejecting an offer = in a response, right ? (NB: it is just the SDP offer that we would need = to reject, not the whole response)

Is it possible that future extensions might plug this = hole, and allow 'subsequent offers' in responses ? Or, are we requiring = now that any such subsequent offers from the UAS use UPDATE = ?

I am wondering whether there are requirements for a = new SDP offer to be semantically linked with a response to the INVITE, = and in particular the 200 OK. e.g. your Early Media is 'sendonly' and = the UAS wants to change the stream to 'sendrecv' on Answer. Is it OK to = have separate operations for the change in dialog state and the change = in media state ? or might these need to be linked in a single operation = ?

Regards...Mark

------_=_NextPart_001_01C1B97E.724C85C0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 15:40:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04780 for ; Tue, 19 Feb 2002 15:40:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01850 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 15:40:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29563; Tue, 19 Feb 2002 14:57:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29538 for ; Tue, 19 Feb 2002 14:57:32 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03392 for ; Tue, 19 Feb 2002 14:57:30 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1JJv1S15561 for ; Tue, 19 Feb 2002 13:57:01 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1JJv1m07073 for ; Tue, 19 Feb 2002 13:57:01 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g1JJv0E14404 for ; Tue, 19 Feb 2002 14:57:00 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Feb 2002 14:57:16 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC5EE5E6@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'sip@ietf.org'" Date: Tue, 19 Feb 2002 14:56:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] [Sip]Question on Section 16.5 Section 7 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I am quoting second paragrapgh of step 7, pdf version lines 2724-2729: In the absence of such an overriding mechanism, the proxy applies the procedures listed in [4] as follows to determine where to send the request. If the proxy has reformatted the request to send to a strict-routing element as described in step 6 above, the proxy MUST apply those procedures to the Request-URI of the request. Otherwise, the proxy MUST apply the procedures to the first value in the Route header field, if present, else the Request-URI. My question: Is the Request-URI refered to in the last line the same as the one placed in the target set in section 16.5 . In general, the relation between that step and what got placed in the target set (section 16.5) is unclear. Regards. George Foti Ericsson Canada _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 15:44:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04927 for ; Tue, 19 Feb 2002 15:44:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02000 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 15:44:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00593; Tue, 19 Feb 2002 15:15:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00562 for ; Tue, 19 Feb 2002 15:15:05 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03954 for ; Tue, 19 Feb 2002 15:15:02 -0500 (EST) Received: from dynamicsoft.com (rjs.dynamicsoft.com [127.0.0.1]) by rjs.dynamicsoft.com (8.11.2/8.11.2) with ESMTP id g1JKEWL01574; Tue, 19 Feb 2002 14:14:32 -0600 Message-ID: <3C72B228.4000807@dynamicsoft.com> Date: Tue, 19 Feb 2002 14:14:32 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 To: "George Foti (LMC)" CC: "'sip@ietf.org'" Subject: Re: [Sip] [Sip]Question on Section 16.5 Section 7 References: <32CD630F6CBED411AE180008C7894CBC5EE5E6@lmc37.lmc.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The Request-URI referred to is the Request-URI in the request at that point in processing. The step you are looking at gets run on a copy of the message for each URI placed in the target set. The URI was taken from the target set and placed in the Request-URI of the copy in step 2. RjS George Foti (LMC) wrote: > Hi, > > I am quoting second paragrapgh of step 7, pdf version lines 2724-2729: > > In the absence of such an overriding mechanism, the proxy applies the > procedures listed in [4] as follows to determine where to send the request. > If the proxy has reformatted the request to send to a strict-routing element > as described in step 6 above, the proxy MUST apply those procedures to the > Request-URI of the request. Otherwise, the proxy MUST apply the procedures > to the first value in the Route header field, if present, else the > Request-URI. > My question: > Is the Request-URI refered to in the last line the same as the one placed in > the target set in section 16.5 . In general, the relation between that step > and what got placed in the target set (section 16.5) is unclear. > Regards. > George Foti > Ericsson Canada > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Tue Feb 19 16:20:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05899 for ; Tue, 19 Feb 2002 16:20:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03769 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 16:20:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02107; Tue, 19 Feb 2002 15:47:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02076 for ; Tue, 19 Feb 2002 15:47:46 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05020 for ; Tue, 19 Feb 2002 15:47:43 -0500 (EST) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA09164; Tue, 19 Feb 2002 15:47:39 -0500 (EST) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1JKlbtN009637; Tue, 19 Feb 2002 15:47:38 -0500 (EST) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.1/8.12.1/Submit) id g1JKlbEP009634; Tue, 19 Feb 2002 15:47:37 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.47592.173996.28663@grandcentral.cs.columbia.edu> Date: Tue, 19 Feb 2002 15:47:36 -0500 To: Jonathan Rosenberg Cc: Dror@vocaltec.com, sip@ietf.org Subject: Re: [Sip] Some more ABNF issues - bis07 In-Reply-To: <3C71A329.E06EEA8E@dynamicsoft.com> References: <3C71A329.E06EEA8E@dynamicsoft.com> X-Mailer: VM 6.98 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Monday, February 18 2002, "Jonathan Rosenberg" wrote to "Dror@vocaltec.com, sip@ietf.org" saying: > > > Dror@vocaltec.com wrote: > > > > 1. TEXT-UTF8-TRIM - while the text claims it does not allow leading WS, > > it > > actually does. should be redefined as: > > TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) > > (added "1" before "*") > > Good point. Fixed. Unfortunately, as a side effect, this forbids TEXT-UTF8-TRIM from matching the empty string. Not intended, I assume. You need either to stick the whole thing in brackets, or add an explicit / ; empty afterwards. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 17:19:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06846 for ; Tue, 19 Feb 2002 17:19:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA06890 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 17:19:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05107; Tue, 19 Feb 2002 16:42:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05004 for ; Tue, 19 Feb 2002 16:42:19 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06323 for ; Tue, 19 Feb 2002 16:42:14 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1JLfMhM002081; Tue, 19 Feb 2002 22:41:23 +0100 (MET) Received: from ericsson.com (ppp28.lmf.ericsson.se [131.160.102.28]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1JLfJr6011358; Tue, 19 Feb 2002 23:41:20 +0200 (EET) Message-ID: <3C72C6BA.34C7C56@ericsson.com> Date: Tue, 19 Feb 2002 23:42:18 +0200 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Juha Heinanen CC: Dean Willis , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? References: <011b01c1b65c$5b579f00$b3036e3f@dfw.dynamicsoft.com> <3C6FAF91.3F27DEE@ericsson.com> <15473.31878.491755.490593@harjus.eng.song.fi> <024001c1b8d9$1e9a7ea0$f1029bd4@DWILLISS1> <15474.701.458392.961132@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Juhan: Your UA will send the INVITE to your outbound proxy. However, that outbound will not be able to route the INVITE to your home server that provides you with services, IF you didn't include some preloaded Routes. How did you find this preloaded Routes? Through the mechanism described in the path header draft. So, let's go back: a) Your switch on your mobile phone and DHCP will return you the address of your outbound proxy. b) You send a REGISTER to your outbound proxy, that will route it to another proxy in the same visited network that is controlling a firewall. This other one finds the entry point in your home network, and finally your registrar gets the REGISTER. 4 proxies were involved for this example This are returned back in the 200 OK response. c) When you send an INVITE, your UAC will add 4 Route headers to traverse your outbound proxy, the firewall controller, the entry point in your home network and the proxy/registrar that is providing you with services. After that, the INVITE is routed based on the destination. This was an extreme example, but it may be possible. DHCP will only provide you with the first outbound proxy address, but not with the vector of proxies to traverse. /Miguel Juha Heinanen wrote: > > i still don't get it. lets assume that my mobile phone (like any UA) has > been configured with its sip uri, e.g., sip:123456@mobile.com. > > when it registers, it sets the request uri to sip:mobile.com and sends > the register message either to its outbound proxy (which it had learned > via dhcp when it was turned on) or it makes a dns query and asks who is > the proxy for mobile.com and sends it directly there. it should not > matter at all to the UA or the registar through which proxies the > message got to the registrar of mobile.com. > > the same for invites. when the UA makes an invite, it can choose to use > its outbound proxy with or without a loose source route containing an > entry for its home proxy or send the invite directly to its home proxy. > > -- juha -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 17:32:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07656 for ; Tue, 19 Feb 2002 17:32:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA07600 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 17:32:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06411; Tue, 19 Feb 2002 17:02:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06380 for ; Tue, 19 Feb 2002 17:02:26 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06623 for ; Tue, 19 Feb 2002 17:02:22 -0500 (EST) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA25251 for ; Tue, 19 Feb 2002 17:02:24 -0500 (EST) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1JM2NtN009838 for ; Tue, 19 Feb 2002 17:02:24 -0500 (EST) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.1/8.12.1/Submit) id g1JM2N5K009835; Tue, 19 Feb 2002 17:02:23 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.52078.657069.18537@grandcentral.cs.columbia.edu> Date: Tue, 19 Feb 2002 17:02:22 -0500 To: sip@ietf.org X-Mailer: VM 6.98 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit Subject: [Sip] Two more bis-07.9 BNF nits Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Two more bis-07.9 BNF nits; I think this is the last of them. 1. The BNF for Accept requires that the 'q' parameter appear before any other parameter. Even though RFC 2616 does this, it's inconsistent with the way things work anywhere else in SIP, and so should probably be fixed. Suggested BNF: Accept = "Accept" HCOLON ( accept-range *(COMMA accept-range) ) accept-range = media-range *( SEMI accept-param) accept-param = ( "q" EQUAL qvalue ) / generic-param qvalue and generic-param should also probably move up to be defined near their first reference. The same syntax forms can be used for the generic parameters for Accept-Encoding and Accept-Language, which I mentioned in my earlier mail. 2. User-Agent and Server seem to have been overlooked in the explicit-whitespace conversion -- there's nothing specifying LWS between consecutive 'product' values. One possible BNF representation would be Server = "Server" HCOLON *( product LWS / comment ) ( product / comment ) (and similarly for User-Agent) but this isn't quite right, I don't think; you need LWS between consecutive product tokens, but you don't need them between product and comment or vice-versa, as comment's inherent SWS is sufficient. I'm not sure how exactly to specify this. With these changes, my BNF parser is happy parsing the sample SIP messages I've thrown at it. I haven't tested complete coverage, but I'm pretty sure all the high points have been hit. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 19 18:27:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08351 for ; Tue, 19 Feb 2002 18:27:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA09376 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 18:27:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08373; Tue, 19 Feb 2002 17:56:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08348 for ; Tue, 19 Feb 2002 17:56:52 -0500 (EST) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08034 for ; Tue, 19 Feb 2002 17:56:49 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Feb 2002 14:56:45 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Adam Roach'" , "'jdrosen@dynamicsoft.com'" , "'rsparks@dynamicsoft.com'" Cc: "'sip@ietf.org'" Subject: Dialog Tunnelling == bad (Was: [SIP] Event ID) Date: Tue, 19 Feb 2002 14:56:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi all, My food for thought for the day: This is not so much an objection to the Event header Id parameter but I wanted to raise my concern that this idea of tunnelling subscriptions (or other sub-dialog, e.g. REFERs) through INVITE initiated dialogs (or other any dialog) - I believe it is running in the wrong direction. I completely agree with Jonathan that we need to separate session state from sip dialog state. I believe you are trying to accomplish this with your concept of extending a "session dialog" concept by encompassing all tunnelled sub-dialogs. I believe this is analogous to trying to implement call-control by doing "funky" stuff in B2BUA's using a single dialog - e.g. DTMF in INFO - it works _very_ well for some application models but falls down quickly when you try to use MUTLIPLE DIALOGS! This is why it is so hard to kick DTMF in INFO - it works so well for the B2BUA model but falls apart when you start using REFER/Replaces/etc/etc. The separation of session state from dialog state should revolve around SESSIONs being defined in terms of CONVERSATION-SPACEs. Now conversation spaces revolve around the call-control primitives and MULTIPLE dialogs. Encouraging REFER's and SUBSCRIBE's to be tunnelled through INVITE initiated dialogs makes it very difficult to work with conversation spaces. The reason for this is that you have now muddied the association between the original INVITE dialog and existence of the residual dialog where the dialog would not otherwise be in the conversation-space. This approach simply complicates conversation spaces and the use of call-control primitives such as REFER/Replaces/Join, etc - an area which is already complicated enough. So let me give a couple of rough examples. For starters the conversation space model must be rewritten to differentiated between what is a "real conversation space dialog" participant and what is a "residual dialog that has been terminated but is still hanging around because it is acting as a conduit for a SUBSCRIBE or REFER" dialog. This is a TERRIBLE complication to the conversation space concept - perhaps terminally. For instance, unless you redefine the conversation space very carefully, a INVITE-initiated dialog that is currently only being used by a subscription to a conversation-space will stop a conversation space (as currently written) from ending. The conversation-space must be redefined not in terms of dialogs but in terms of sub-dialogs which incidentally usually won't even exist when the INVITE dialog is first received. Obviously this is not an unsolvable problem but it shows the tip of the iceberg in terms of wide ranging complications introduced. Likewise, the handling of all call-control primitives such as Replace/Join/etc etc is complicated by the fact that an INVITE-initiated dialog may exist but its no longer being used for an INVITE sip session. So what are we trying to accomplish? We are trying to guarantee that if a path for an INVITE dialog is established, then subsequent dialogs from some entity along that call path can also establish a new dialog fairly reliably. So the requirement is that the network and UA treats the new dialog identically for routing purposes but is recognized as *NOT* the same dialog (so that it won't be torn down at the same time). This is a problem with backward compatibility but I feel it is better than going down the other road of sub-dialogs!! Shouldn't we be working not making sure that we put together guidelines so that Route headers are portable/usable by "companion dialogs" from entities on the same call path. IMO, this is the direction we should be heading and not to the B2BUA infested waters of sub-dialogs. I would say even that (perhaps counter-intuitively) backwards compatibly is MORE of a problem with this new sub-dialog concept than with trying to do things correctly with Route headers. At least you know if a set of pre-loaded Route header fail when everything has its own dialog (and probably has a good chance of working even with today's proxies); however, when trying to have multiple sub-dialogs use the same call transaction id you have NO idea whether a proxy will drop all sub-dialogs when the first BYE comes along! I think that is something worth thinking about! Cheers, Robert. > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 18 February 2002 23:31 > To: 'Fairlie-Cuninghame, Robert'; Adam Roach > Cc: 'sip@ietf.org' > Subject: RE: Event ID (was RE: Events Last Call.) > > > > -----Original Message----- > > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > > > Now I don't think this is necessarily contrary to the Id > > parameter but the > > way you justify the complexity added by the Id parameter scares me. > > Basically, if you are solving the problem for an UA endpoint > > delivering a > > subscription through an existing INVITE dialog then IMO you > must also > > address how a proxy can also accomplish this in an equally > guaranteed > > manner. > > I hat B2BUAs at least as much as you do, and fully understand your > objection. As soon as you propose something that works, I'll > incorporate it. > > /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 daemon@optimus.ietf.org Tue Feb 19 21:14:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10396 for ; Tue, 19 Feb 2002 21:14:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA15934 for sip-archive@odin.ietf.org; Tue, 19 Feb 2002 21:14:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14721; Tue, 19 Feb 2002 20:42:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14657 for ; Tue, 19 Feb 2002 20:42:02 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10074; Tue, 19 Feb 2002 20:42:00 -0500 (EST) Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1K1fVh17588; Tue, 19 Feb 2002 17:41:31 -0800 (PST) Date: Tue, 19 Feb 2002 17:41:31 -0800 (PST) From: Rohan Mahy To: , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Draft Naming Conventions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Folks, In the next few days, many of you will submit Internet Drafts. Please remember that per the Transport Area SIP change policy all new proposed extensions, requirements, and usage drafts should go through the SIPPING WG. This means that if you have a proposed extension that is not already a SIP WG Milestone, it needs to be submitted with a file name like this draft-lastname-sipping-description-00.txt for example: draft-mahy-sipping-gaming-reqs-00.txt would be an appropriately named draft for internet gaming requirements on the SIP protocol. Please note that merely submitting an internet draft does not result in discussion time for your draft at a meeting. Meeting time in the SIP WG is for chartered work only, and meeting time in SIPPING is for discussion of work already discussed on the mailing list (and must be requested). Requests for Agenda time in SIPPING are being tracked on the SIPPING supplemental website: http://www.softarmor.com/sipping/meets/ietf53/requests.html many 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 daemon@optimus.ietf.org Wed Feb 20 01:50:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15994 for ; Wed, 20 Feb 2002 01:50:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA05242 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 01:50:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04047; Wed, 20 Feb 2002 01:23:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04016 for ; Wed, 20 Feb 2002 01:22:58 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15740 for ; Wed, 20 Feb 2002 01:22:56 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1K6NC6Y010363; Wed, 20 Feb 2002 01:23:12 -0500 (EST) Message-ID: <3C73409D.A9D279A7@dynamicsoft.com> Date: Wed, 20 Feb 2002 01:22:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" CC: "'Adam Roach'" , "'sip@ietf.org'" Subject: Re: [Sip] RE: Event ID (was RE: Events Last Call.) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > > Hi Adam, > > We did propose something in the key-events draft > (draft-culpepper-key-events-00.txt) whereby a proxy extracts the Route > set > from the INVITE-initiated dialog for all hops between itself and the > intended UA [Section 7.10]. It would need to be adapted to work with > your > sub-dialog approach (rather than as Pre-loaded Routes). It is a bit > messy > but I would rather have a slightly messy mechanism for proxies to create > subscription sub-dialogs than for all application proxies to become > B2BUA's!!! There are a lot of issues that need to be resolved before this works. First and foremost, bis states that the URI inserted into record-routes are scoped just for that dialog. In other words, you can only use those URI within that specific dialog. An entity along the path which tries to use those URI as pre-loaded routes into a new dialog, that may not work with bis as specified. I think the scoping of RR in this way is really important, since the user part, or other params, can be populated with dialog specific state that the proxy wants to get back. So, if the UAS wants to subscribe to the caller along the same path, it pretty much has to embed the SUBSCRIBE in the dialog, and thus the problem.. Another interesting problem is this - how does a UA authenticate and then authorize a subscription from an application along the call path? This is a really hard problem, and certainly one solution is that if the element was a b2bua, it can use our normal (?) e2e authentication mechanisms. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 20 02:12:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24016 for ; Wed, 20 Feb 2002 02:12:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA06360 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 02:12:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05355; Wed, 20 Feb 2002 01:51:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05324 for ; Wed, 20 Feb 2002 01:51:42 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16034 for ; Wed, 20 Feb 2002 01:51:40 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1K6pPio027210; Wed, 20 Feb 2002 08:51:26 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15475.18285.950287.495990@harjus.eng.song.fi> Date: Wed, 20 Feb 2002 08:51:25 +0200 To: "Miguel A. Garcia" Cc: Dean Willis , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Subject: Re: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? In-Reply-To: <3C72C6BA.34C7C56@ericsson.com> References: <011b01c1b65c$5b579f00$b3036e3f@dfw.dynamicsoft.com> <3C6FAF91.3F27DEE@ericsson.com> <15473.31878.491755.490593@harjus.eng.song.fi> <024001c1b8d9$1e9a7ea0$f1029bd4@DWILLISS1> <15474.701.458392.961132@harjus.eng.song.fi> <3C72C6BA.34C7C56@ericsson.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Miguel A. Garcia writes: > a) Your switch on your mobile phone and DHCP will return you the address > of your outbound proxy. fine, or as bis says, if the UA is dns capable, it doesn't even need the proxy returned by dhcp, because it can directly send the register to its home proxy. > b) You send a REGISTER to your outbound proxy, that will route it to another > proxy in the same visited network that is controlling a firewall. This > other one finds the entry point in your home network, and finally your > registrar gets the REGISTER. 4 proxies were involved for this example > This are returned back in the 200 OK response. this sounds ok if the UAC doesn't want to send the register directly to its home proxy. > c) When you send an INVITE, your UAC will add 4 Route headers to traverse > your outbound proxy, the firewall controller, the entry point in your > home network and the proxy/registrar that is providing you with > services. After that, the INVITE is routed based on the destination. if the UAC wants (which is its option) to use the services of a proxy in its home domain, it can be either configured with the domain name of the proxy of its home domain or it can make a dns query to find it out. i don't see any need for the registrar to provide that information to the UAC with some new protocol mechanism. -- 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 daemon@optimus.ietf.org Wed Feb 20 03:21:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24773 for ; Wed, 20 Feb 2002 03:21:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA09155 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 03:21:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07765; Wed, 20 Feb 2002 02:49:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07742 for ; Wed, 20 Feb 2002 02:49:07 -0500 (EST) Received: from obsoft.com (sdsl-64-139-4-113.dsl.sca.megapath.net [64.139.4.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24414 for ; Wed, 20 Feb 2002 02:49:04 -0500 (EST) Received: (from sardana@localhost) by obsoft.com (8.11.6/8.11.6) id g1K7sHY07824; Tue, 19 Feb 2002 23:54:17 -0800 Date: Tue, 19 Feb 2002 23:54:17 -0800 From: Bobby Sardana Message-Id: <200202200754.g1K7sHY07824@obsoft.com> To: danillo.marcondes@tropiconet.com.br, sip@ietf.org Subject: Re: [Sip] Java based SIP stack Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Try: http://www.antd.nist.gov/cgi-bin/nist-sip-distribution.pl I am not sure about its licensing. regards, Bobby Sardana. sardana@obsoft.com >Hi, >I would like to know where I can find a free Java based SIP stack. >Could anyone help me please? >Thanks, >Danillo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 20 04:41:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25953 for ; Wed, 20 Feb 2002 04:41:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA13282 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 04:41:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11997; Wed, 20 Feb 2002 04:16:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11966 for ; Wed, 20 Feb 2002 04:16:52 -0500 (EST) Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25672 for ; Wed, 20 Feb 2002 04:16:49 -0500 (EST) Received: (qmail 10397 invoked by alias); 20 Feb 2002 09:16:52 -0000 Received: from unknown (HELO indigosw.com) (194.78.202.25) by 0 with SMTP; 20 Feb 2002 09:16:52 -0000 Message-ID: <3C7369BE.8090408@indigosw.com> Date: Wed, 20 Feb 2002 10:17:50 +0100 From: Torrey Searle Organization: Indigo Software, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020206 X-Accept-Language: en-us MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] 423 and sip-events-03 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There seems to be an inconsistancey in the new draft, in 4.1.6.1 the reason phrase for the 423 respose is "Interval too small", but later on in 4.1.6.1 and in 4.1.6.4 it has the reason phrase still being "Subscription Too Brief". Since the "Interval too small" was just added in -03 is it correct to assume that is the proper reason phrase to give for the 423 response? Torrey Searle Indigo Software tsearle@indigosw.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 daemon@optimus.ietf.org Wed Feb 20 06:24:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26950 for ; Wed, 20 Feb 2002 06:24:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA17656 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 06:24:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16415; Wed, 20 Feb 2002 05:59:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16383 for ; Wed, 20 Feb 2002 05:58:58 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26652 for ; Wed, 20 Feb 2002 05:58:54 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1KAwQhM026746 for ; Wed, 20 Feb 2002 11:58:27 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1KAwQr6020896 for ; Wed, 20 Feb 2002 12:58:26 +0200 (EET) Message-ID: <3C73818A.66E0BC98@lmf.ericsson.se> Date: Wed, 20 Feb 2002 12:59:23 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] 491 issues Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A couple of small issues on 491 Request pending. 1. Chapter 14.2 defines that a node receiving an INVITE shall return 491 if it has a pending INVITE transaction in progress for the same dialog. Chapter 25.4.27, however, says that 491 shall be returned for any received request if the node has a pending request (the text doesn't even mention if the request methods are the same or not) within the same dialog. I think it shall be more clarified that 491 shall be returned only in the case of INVITE requests (and any other request where there may be a functional race condition). For example, if a node receives INFO, and has a pending INFO within the same dialog, there may be no need to return 491... 2. This is just to clarify. If a node sends an INVITE request, it may by a proxy be looped back to the same node. However, even if the Call-ID is the same, but the local- and remote tags are different for the incoming and outgoing INVITE, they will represent different dialogs, and there is no risk a 491 would be returned for the incoming INVITE. Correct? Regards, Christer Holmberg Ericsson 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 daemon@optimus.ietf.org Wed Feb 20 07:27:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28243 for ; Wed, 20 Feb 2002 07:27:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA20083 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 07:27:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19733; Wed, 20 Feb 2002 07:08:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19703 for ; Wed, 20 Feb 2002 07:08:20 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27955; Wed, 20 Feb 2002 07:08:17 -0500 (EST) Message-Id: <200202201208.HAA27955@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 20 Feb 2002 07:08:17 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-events-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : SIP-Specific Event Notification Author(s) : A. Roach et al. Filename : draft-ietf-sip-events-03.txt Pages : 39 Date : 19-Feb-02 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Concrete uses of the mechanism described in this document may be standardized in the future. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-events-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-events-03.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-events-03.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020219151149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-events-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-events-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020219151149.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 20 08:33:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00036 for ; Wed, 20 Feb 2002 08:33:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA23563 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 08:33:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22141; Wed, 20 Feb 2002 08:11:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22110 for ; Wed, 20 Feb 2002 08:11:29 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29438 for ; Wed, 20 Feb 2002 08:11:26 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA13196; Wed, 20 Feb 2002 08:11:19 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-43-10.mad.east.verizon.net [138.89.43.10]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1KDBHNB003559 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Feb 2002 08:11:18 -0500 (EST) Message-ID: <3C73A202.47BDABA3@cs.columbia.edu> Date: Wed, 20 Feb 2002 08:17:54 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bobby Sardana CC: danillo.marcondes@tropiconet.com.br, sip@ietf.org Subject: Re: [Sip] Java based SIP stack References: <200202200754.g1K7sHY07824@obsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Obligatory reference: http://www.cs.columbia.edu/sip has an implementation section, as do the http://www.sipforum.org and http://www.sipcenter.com sites. Please consult them first, to avoid a lot of "I have a stack, too" postings. Bobby Sardana wrote: > > Try: > > http://www.antd.nist.gov/cgi-bin/nist-sip-distribution.pl > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 20 09:22:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01277 for ; Wed, 20 Feb 2002 09:22:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25660 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 09:22:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24484; Wed, 20 Feb 2002 08:58:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24453 for ; Wed, 20 Feb 2002 08:58:19 -0500 (EST) Received: from localhost ([211.226.155.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00645 for ; Wed, 20 Feb 2002 08:58:04 -0500 (EST) Message-Id: <200202201358.IAA00645@ietf.org> Reply-To: gtech01@gtech21.com From: (주)지텍 To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 20 Feb 2002 22:58:13 +0900 Subject: [Sip] 신개념 휴대폰용 이어폰 -마이크/이어폰/스위치 한몸에..[광고] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org mail02-1
⊙ 허락없이 메일을 보내서 죄송합니다.
⊙ 본메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다.
⊙ e-mail 주소는 인터넷상에서 취득하였으며, 주소외 어떠한 개인 정보도 가지고 있지 않습니다.
⊙ 수신을 원치 않으시면 '수신거부'를 눌러주세요. [수신거부]
 
 
 
 
(주)지텍 인천광역시 계양구 작전동 852-73 Tel:(032)552-7222
E-mail : gtech@gtech21.com    Homepage : http://www.gtech21.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 daemon@optimus.ietf.org Wed Feb 20 09:53:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02367 for ; Wed, 20 Feb 2002 09:53:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27272 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 09:53:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25890; Wed, 20 Feb 2002 09:25:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25787 for ; Wed, 20 Feb 2002 09:24:58 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01424 for ; Wed, 20 Feb 2002 09:24:54 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1KEOuh02607; Wed, 20 Feb 2002 08:24:56 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1KEOtm05739; Wed, 20 Feb 2002 08:24:55 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g1KEOsE21993; Wed, 20 Feb 2002 09:24:55 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 09:25:11 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC5EE5EA@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Robert Sparks'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] Question on Section 16.5 Step 7 Date: Wed, 20 Feb 2002 09:24:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks. One more. Quoting the same paragraph in step 7: lines 2725-2729. If the proxy has reformatted the request to send to a strict-routing element as described in step 6 above, the proxy MUST apply those procedures to the Request-URI of the request. Otherwise, the proxy MUST apply those precdures to the first value in the Route header fiedl if present, else the Request-URI. Why is the else needed. Isn't that already covered in the first line? Rgds. George Foti Ericsson Canada > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Tuesday, February 19, 2002 3:15 PM > To: George Foti (LMC) > Cc: 'sip@ietf.org' > Subject: Re: [Sip] Question on Section 16.5 Section 7 > > > The Request-URI referred to is the Request-URI in the request > at that point > in processing. > > The step you are looking at gets run on a copy of the message for each > URI placed in the target set. The URI was taken from the > target set and > placed in the Request-URI of the copy in step 2. > > RjS > > George Foti (LMC) wrote: > > Hi, > > > > I am quoting second paragrapgh of step 7, pdf version lines > 2724-2729: > > > > In the absence of such an overriding mechanism, the proxy > applies the > > procedures listed in [4] as follows to determine where to > send the request. > > If the proxy has reformatted the request to send to a > strict-routing element > > as described in step 6 above, the proxy MUST apply those > procedures to the > > Request-URI of the request. Otherwise, the proxy MUST apply > the procedures > > to the first value in the Route header field, if present, else the > > Request-URI. > > My question: > > Is the Request-URI refered to in the last line the same as > the one placed in > > the target set in section 16.5 . In general, the relation > between that step > > and what got placed in the target set (section 16.5) is unclear. > > Regards. > > George Foti > > Ericsson Canada > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Wed Feb 20 10:26:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03579 for ; Wed, 20 Feb 2002 10:26:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29562 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 10:27:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27383; Wed, 20 Feb 2002 09:54:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27352 for ; Wed, 20 Feb 2002 09:54:54 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02440 for ; Wed, 20 Feb 2002 09:54:49 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.19]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1KEt96Y010559; Wed, 20 Feb 2002 09:55:11 -0500 (EST) Message-ID: <3C73B88B.46654F03@dynamicsoft.com> Date: Wed, 20 Feb 2002 09:54:03 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "George Foti (LMC)" CC: "'Robert Sparks'" , "'sip@ietf.org'" Subject: Re: [Sip] Question on Section 16.5 Step 7 References: <32CD630F6CBED411AE180008C7894CBC5EE5EA@lmc37.lmc.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "George Foti (LMC)" wrote: > > Thanks. One more. > Quoting the same paragraph in step 7: lines 2725-2729. > > If the proxy has reformatted the request to send to a strict-routing > element as described in step 6 above, the proxy MUST apply those > procedures > to the Request-URI of the request. Otherwise, the proxy MUST apply > those > precdures to the first value in the Route header fiedl if present, else > the > Request-URI. > > Why is the else needed. Isn't that already covered in the first line? No. The rule is basically: if(there are Route headers) { if(the request is heading to a strict router) { do DNS on the r-uri; } else { do DNS on top route; } } else { do DNS on r-uri; } -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 20 10:38:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04014 for ; Wed, 20 Feb 2002 10:38:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00377 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 10:38:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28397; Wed, 20 Feb 2002 10:05:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28334 for ; Wed, 20 Feb 2002 10:05:15 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02798 for ; Wed, 20 Feb 2002 10:05:11 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.19]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1KF5Q6Y010578; Wed, 20 Feb 2002 10:05:27 -0500 (EST) Message-ID: <3C73BAF5.3E9FF185@dynamicsoft.com> Date: Wed, 20 Feb 2002 10:04:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Undery CC: EKR , Michael Thomas , sip@ietf.org Subject: Re: [Sip] replays and SMIME References: <45730E094814E44488F789C1CDED27AE012F827C@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit James Undery wrote: > > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@rtfm.com] > > > "James Undery" writes: > > > is all that is needed to work with our framework only > > leaving how the > > > nonce is included into the SMIME body, which superficially > > would be to > > > include the relevant headers. Obviously this is off the top > > of my head > > > and should be taken as the ramblings of an idiot. > > Yes, this is more or less what I had in mind, but your draft is > > a lot more complicated than what we'd need for this purpose, > > I suspect. > > Ironically I might argue the reverse ;-), however, back to the point, in > my opinion the complexity of our draft is in the Digest portion, the > framework itself is light. I don't even think you need anything beyond whats in bis, and you can have the ability to provide challenges. The UAS receives an SMIME signed request, rejects with a 401, requesting digest, providing a nonce, and a random realm, like "foobar.invalid". The UAC, based on the procedures in bis, will have no credentials for this realm, and thus it will use the anonymous username and password. This would go into an Authorization header, which the UAC would include as part of the signed message. The key feature of the anonymous authentication is that it reflects back the nonce, which is all you want to do here. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 20 10:38:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04034 for ; Wed, 20 Feb 2002 10:38:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00395 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 10:38:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28818; Wed, 20 Feb 2002 10:13:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28785 for ; Wed, 20 Feb 2002 10:13:25 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03077 for ; Wed, 20 Feb 2002 10:13:22 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1KFDPh02877 for ; Wed, 20 Feb 2002 09:13:25 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1KFDPc25762 for ; Wed, 20 Feb 2002 09:13:25 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g1KFDOE25618 for ; Wed, 20 Feb 2002 10:13:24 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 10:13:41 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC5EE5EB@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'sip@ietf.org'" Date: Wed, 20 Feb 2002 10:13:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Tables 2&3 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Line 4015 says The next six columns relate to the presence of a header field in a method. According to that description all headers that belong to responses should have a "-", i.e not applicable for all methods. This is not case (Error-info for example, etc..) If the intent of showing something other than "-" under the method is to reflect the header presence in a repsonse for that particular method, then line 4015 should say so. Rgds George Foti Ericsson Canada _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 20 12:00:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06652 for ; Wed, 20 Feb 2002 12:00:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06204 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 12:00:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03072; Wed, 20 Feb 2002 11:30:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03017 for ; Wed, 20 Feb 2002 11:30:08 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05512 for ; Wed, 20 Feb 2002 11:30:05 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AF0471F014E; Wed, 20 Feb 2002 11:29:56 -0500 Message-ID: <006501c1ba2b$a76d4200$2300000a@acmepacket.com> From: "Bob Penfield" To: "Jonathan Rosenberg" , References: <3C71E19F.F309F939@dynamicsoft.com> Subject: Re: [Sip] a couple problems in draft-ietf-sip-rfc2543bis-07.9 Date: Wed, 20 Feb 2002 11:28:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Two problems in draft-ietf-sip-rfc2543bis-07.9 1) The definitions of "Header field" and "Header field value" (at lines 635-637) do not match their usage in the text. A "Header field" is a field name plus a colon followed by one or more header field values separated by comma. The "Header field value" is simply a singular field-value (or header-value) in a Header field. 2) At line 1222, the "less preferred URI" is the "lowest" q value, not the "highest". I am still reviewing the spec and will have more comments (mostly nits) later today. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.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 daemon@optimus.ietf.org Wed Feb 20 12:03:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06730 for ; Wed, 20 Feb 2002 12:03:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06686 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 12:03:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03934; Wed, 20 Feb 2002 11:37:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03903 for ; Wed, 20 Feb 2002 11:37:40 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05810 for ; Wed, 20 Feb 2002 11:37:36 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42260) id <0GRU00001BH9QL@firewall.wcom.com> for sip@ietf.org; Wed, 20 Feb 2002 16:36:45 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GRU00MHOBH9DT@firewall.wcom.com>; Wed, 20 Feb 2002 16:36:45 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GRU00I01BH52T@pmismtp01.wcomnet.com>; Wed, 20 Feb 2002 16:36:45 +0000 (GMT) Received: from ajohnston ([166.42.32.152]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GRU00G9LBGT9E@pmismtp01.wcomnet.com>; Wed, 20 Feb 2002 16:36:30 +0000 (GMT) Date: Wed, 20 Feb 2002 10:35:59 -0600 From: Alan Johnston Subject: RE: [Sip] Tables 2&3 In-reply-to: <32CD630F6CBED411AE180008C7894CBC5EE5EB@lmc37.lmc.ericsson.se> To: "'George Foti (LMC)'" , sip@ietf.org Message-id: <000c01c1ba2c$add131a0$98202aa6@ajohnston> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi George, Thanks for your comments. See Line 4005: "2xx, 4xx, etc.: A numerical value or range indicates response codes with which the header field can be used;" Obviously, a response code does not have a method, but are generated in response to a particular method. I think it is clear enough that Error-Info is optional in 300-699 responses to INVITE, BYE, etc. with the exception of ACK (since a response is never sent to an ACK). Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of George Foti (LMC) > Sent: Wednesday, February 20, 2002 9:13 AM > To: 'sip@ietf.org' > Subject: [Sip] Tables 2&3 > > > Line 4015 says > The next six columns relate to the presence of a header field > in a method. > > According to that description all headers that belong to > responses should have a "-", i.e not applicable for all > methods. This is not case (Error-info for example, etc..) > > If the intent of showing something other than "-" under the > method is to reflect the header presence in a repsonse for > that particular method, then line 4015 should say so. > > Rgds > > George Foti > Ericsson Canada > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Wed Feb 20 12:07:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06947 for ; Wed, 20 Feb 2002 12:06:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA07041 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 12:07:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03298; Wed, 20 Feb 2002 11:30:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03236 for ; Wed, 20 Feb 2002 11:30:39 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05548 for ; Wed, 20 Feb 2002 11:30:35 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id g1KGU8U02093 for ; Wed, 20 Feb 2002 17:30:08 +0100 Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.1/8.12.1) with ESMTP id g1KGU7kv026068 for ; Wed, 20 Feb 2002 17:30:07 +0100 (MET) Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 17:30:05 +0100 Message-ID: From: Brazier Lachlan To: "'sip@ietf.org'" Date: Wed, 20 Feb 2002 17:30:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA2B.D9E79F00" Subject: [Sip] draft-ietf-sip-refer-02 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BA2B.D9E79F00 Content-Type: text/plain; charset="iso-8859-1" Hello, sorry if these questions have occured before. 1) Page 6: Is a "SIP INVITE URL" a normal sip url which results in a INVITE request? This means, a sip URL results in a INVITE request when not stated otherwise through a parameter in the Refer-to header? 2) "REFERs occurring outside an existing dialog effectively create a new dialog following the behavior of SUBSCRIBE specified [2]." a) When a Proxy inserts a Record-Route header into the REFER request, and the Refer-To header contained a SIP INVITE URL, does the resulting INVITE request follow the Route set established by the REFER? OR b) If the proxy wants to be in the route of the resulting INVITE request, does it need to add a Route header parameter to the Refer-To header? Example: Refer-To: sip:alice@atlanta.com?Route: p1.atlanta.com Is a proxy allowed to change the Refer-To header? 3) How long is a dialog opened with a REFER request? Until the response to the NOTIFY was received? That's what I would think. Thanks Lachlan ------_=_NextPart_001_01C1BA2B.D9E79F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+ZHJhZnQt aWV0Zi1zaXAtcmVmZXItMDI8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJ WkU9MiBGQUNFPSJBcmlhbCI+SGVsbG8sPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB cmlhbCI+c29ycnkgaWYgdGhlc2UgcXVlc3Rpb25zIGhhdmUgb2NjdXJlZCBiZWZvcmUuPC9GT05U Pg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjEpIFBhZ2UgNjogSXMgYSAm cXVvdDtTSVAgSU5WSVRFIFVSTCZxdW90OyBhIG5vcm1hbCBzaXAgdXJsIHdoaWNoIHJlc3VsdHMg aW4gYSBJTlZJVEUgcmVxdWVzdD8gVGhpcyBtZWFucywgYSBzaXAgVVJMIHJlc3VsdHMgaW4gYSBJ TlZJVEUgcmVxdWVzdCB3aGVuIG5vdCBzdGF0ZWQgb3RoZXJ3aXNlIHRocm91Z2ggYSBwYXJhbWV0 ZXIgaW4gdGhlIFJlZmVyLXRvIGhlYWRlcj88L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIg RkFDRT0iQXJpYWwiPjIpICZxdW90OzwvRk9OVD48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBO ZXciPlJFRkVScyBvY2N1cnJpbmcgb3V0c2lkZSBhbiBleGlzdGluZyBkaWFsb2cgZWZmZWN0aXZl bHkgY3JlYXRlIGEgbmV3IGRpYWxvZyBmb2xsb3dpbmcgdGhlIGJlaGF2aW9yIG9mIFNVQlNDUklC RSBzcGVjaWZpZWQgWzJdLiZxdW90OzwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNF PSJBcmlhbCI+YSkgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+V2hlbiBh IFByb3h5IGluc2VydHMgYSBSZWNvcmQtUm91dGUgaGVhZGVyIGludG8gdGhlIFJFRkVSIHJlcXVl c3QsIGFuZCB0aGUgUmVmZXItVG8gaGVhZGVyIGNvbnRhaW5lZCBhIFNJUCBJTlZJVEUgVVJMLCBk b2VzIHRoZSByZXN1bHRpbmcgSU5WSVRFIHJlcXVlc3QgZm9sbG93IHRoZSBSb3V0ZSBzZXQgZXN0 YWJsaXNoZWQgYnkgdGhlIFJFRkVSPzwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNF PSJBcmlhbCI+T1I8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ YikgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SWYgdGhlIHByb3h5IHdh bnRzIHRvIGJlIGluIHRoZSByb3V0ZSBvZiB0aGUgcmVzdWx0aW5nIElOVklURSByZXF1ZXN0LCBk b2VzIGl0IG5lZWQgdG8gYWRkIGEgUm91dGUgaGVhZGVyIHBhcmFtZXRlciB0byB0aGUgUmVmZXIt VG8gaGVhZGVyPzwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RXhh bXBsZTo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5SZWZlci1Ubzogc2lw OmFsaWNlQGF0bGFudGEuY29tP1JvdXRlOiBwMS5hdGxhbnRhLmNvbTwvRk9OVD4NCjwvUD4NCg0K PFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JcyBhIHByb3h5IGFsbG93ZWQgdG8gY2hhbmdl IHRoZSBSZWZlci1UbyBoZWFkZXI/PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFD RT0iQXJpYWwiPjMpIEhvdyBsb25nIGlzIGEgZGlhbG9nIG9wZW5lZCB3aXRoIGEgUkVGRVIgcmVx dWVzdD8gVW50aWwgdGhlIHJlc3BvbnNlIHRvIHRoZSBOT1RJRlkgd2FzIHJlY2VpdmVkPyBUaGF0 J3Mgd2hhdCBJIHdvdWxkIHRoaW5rLjwvRk9OVD48L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9 MiBGQUNFPSJBcmlhbCI+VGhhbmtzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh bCI+TGFjaGxhbjwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C1BA2B.D9E79F00-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 20 12:19:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07513 for ; Wed, 20 Feb 2002 12:19:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA07935 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 12:19:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03791; Wed, 20 Feb 2002 11:36:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03731 for ; Wed, 20 Feb 2002 11:36:01 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05765 for ; Wed, 20 Feb 2002 11:35:58 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1KGZKE22302 for ; Wed, 20 Feb 2002 08:35:27 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX65084; Wed, 20 Feb 2002 08:34:52 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA29853; Wed, 20 Feb 2002 08:35:19 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15475.53319.640011.994162@thomasm-u1.cisco.com> Date: Wed, 20 Feb 2002 08:35:19 -0800 (PST) To: sip@ietf.org X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [Sip] SMIME and active MITM attacks Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit First of all, the comparison of SIP's use of SMIME and SSH is flat out wrong. SSH is a peer to peer protocol which does not have intermediaries (or at least the last time I checked, but regardless when one thinks of SSH, one does not think of active proxies). The reason that this is important is because SIP, unlike SSH is trivially subject to active MITM attacks. Indeed, the entire raison d'etre for SMIME is to thwart active MITM attacks from hostile proxies. Unfortunately, I think the current text falls short of the mark, both from a specification standpoint as well as a practical standpoint. In particular, there is nothing which prevents a proxy from removing a SMIME attachment and adding its own. Assuming the proxy's cert is rooted in some CA's namespace, it would verify just fine. An evil proxy is perfect capable of rewriting any headers it feels like, so the comparison of inner or outer From: addresses is essentially useless. It's not enforcing any security policy. That is, unless there is some ultimate differentiation of authorization to particular authenticated identities, nothing is being enforced. Second, the entire concept of using self-signed certs in the face of active MITM attacks is bogus. At least with rooted certs, you can at least show a user that the identity presented is provably part of a known CA's namespace. Self-signed certs have no such insurance, so they provide no additional authentication benefit in this case. This is in contrast to SSH-like leap's of faith. For SSH, the plausibility of an active MITM is explicitly discounted because of the general difficultly of mounting such an attack on the Internet. However, proxy routed SIP makes this kind of attack trivial for evil proxies -- the exact thing that we are protect ourselves from. As such, any form of opportunism with self-signed, or unknown CA's is extremely suspect, and subject to simple substitution by a proxy. The third thing I notice is that the reverse path seems to be completely broken. In it, the text in 22.1 says that although the message may signed against some certificate, the UAC cannot expect that the TO: address and the cert identity will will be the same. So, what security property is being enforced then? What prevents a hostile proxy from changing the contact address? How does the UAC know that it actually contacted who they expected? The answer seems to be "nothing" and "it can't". In summary, I don't think this section has had nearly enough review to determine whether it is actually providing any real security benefits wrt. authenticating UA's, and I'm dubious how real UA's will actually do anything useful with the asserted identities. This is in stark contrast to UA-proxy authentication which generally involves an authorization operation after the UA is authenticated. 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 daemon@optimus.ietf.org Wed Feb 20 12:25:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09007 for ; Wed, 20 Feb 2002 12:25:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA08408 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 12:26:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05180; Wed, 20 Feb 2002 11:59:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05149 for ; Wed, 20 Feb 2002 11:59:06 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06547 for ; Wed, 20 Feb 2002 11:59:02 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1KGuXQl020316; Wed, 20 Feb 2002 11:56:33 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGHZY>; Wed, 20 Feb 2002 11:58:35 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F363008F@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Torrey Searle'" , sip Subject: RE: [Sip] 423 and sip-events-03 Date: Wed, 20 Feb 2002 11:58:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Yes, this should be made consistent, and will be fixed in the next version. Thanks for the comment. (You can actually give your favorite Swahili insult as the reason phrase and it all works. The 423 is the important part, from a protocol perspective. In my previous job, I railed against the blind use of reason codes to the point that I was instructing our engineers *not* to use them *ever*, and to instead come up with something reasonable that would make sense to an average end user if it popped up on their terminal display.) /a > -----Original Message----- > From: Torrey Searle [mailto:tsearle@indigosw.com] > Sent: Wednesday, February 20, 2002 3:18 AM > To: sip > Subject: [Sip] 423 and sip-events-03 > > > There seems to be an inconsistancey in the new draft, in 4.1.6.1 the > reason phrase for the 423 respose is "Interval too small", > but later on > in 4.1.6.1 and in 4.1.6.4 it has the reason phrase still being > "Subscription Too Brief". > > Since the "Interval too small" was just added in -03 is it correct to > assume that is the proper reason phrase to give for the 423 response? > > Torrey Searle > Indigo Software > tsearle@indigosw.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 daemon@optimus.ietf.org Wed Feb 20 12:33:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10199 for ; Wed, 20 Feb 2002 12:33:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09396 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 12:33:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07339; Wed, 20 Feb 2002 12:11:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07310 for ; Wed, 20 Feb 2002 12:11:32 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07138 for ; Wed, 20 Feb 2002 12:11:28 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1KHBo6Y010736; Wed, 20 Feb 2002 12:11:51 -0500 (EST) Message-ID: <3C73D8A5.8E6196D5@dynamicsoft.com> Date: Wed, 20 Feb 2002 12:11:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] comments on 100rel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > comments on 100rel-04.9: > > - page 2 first para: append: > > "but are not sent reliably in RFC BBBB." Fixed. > > - page 5 first sentence: If the PRACK contained a body, ... > ^ > insert: > > "session description, it is processed as described in Section 5 of > this > document. > If the PRACK instead containedany other type of" Good point. Fixed. > > - page 5 4th para: revise the beginning as follows to make consistent > with Section 5: > > Note that the UAS MAY send a final response to the initial request > before > having recevied PRACKs for all unacknowleged reliable responses, unless > any of the unacknowleged reliable provisional response contained a > session > description. If the UAS does send a final response when reliable > responses are still unacknowledged, it SHOULD NOT..... Another good catch, thanks. Text now reads: The UAS {\MAY} send a final response to the initial request before having recevied {\PRACK}s for all unacknowleged reliable provisional responses, unless any of the unacknowleged reliable provisional responses contained a session description. In that case, it {\MUSTNOT} send a final response until those provisional responses are acknowledged. If the UAS does send a final response when reliable responses are still unacknowledged, it {\SHOULDNOT} continue to retransmit the unacknowledged reliable provisional responses, but it {\MUST} be prepared to process {\PRACK} requests for those outstanding responses. A UAS {\MUSTNOT} send new reliable provisional responses (as opposed to retransmissions of unacknowledged ones) after sending a final response to a request. > > - section 4 first paragraph. seems to missing a sentence between 100rel > and requests Grrr... one of the known converter bugs, which I now (finally) can programmatically discover and eliminate. Its fixed, and I will check for others before issuing -05. > > page 7 para 3: s/One an/Once an/ Fixed. Thanks for your comments, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 20 12:46:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10796 for ; Wed, 20 Feb 2002 12:46:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10237 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 12:46:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08317; Wed, 20 Feb 2002 12:25:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08286 for ; Wed, 20 Feb 2002 12:25:12 -0500 (EST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08863 for ; Wed, 20 Feb 2002 12:25:07 -0500 (EST) Received: from aslan ([12.224.107.17]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020220172433.HBRD2626.rwcrmhc51.attbi.com@aslan> for ; Wed, 20 Feb 2002 17:24:33 +0000 Reply-To: From: "Jack W. Lix" To: Subject: RE: [Sip] Some Loose Routing feedback Date: Wed, 20 Feb 2002 09:32:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <3C707DBC.1040209@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit >> >> 16.11.1.2 Traversing a strict-routing proxy >> >> In this scanario, a dialog is established across four proxies, each >> of which adds Record-Route header field values. The third proxy >> implements the strict-routing proceedures specified in RFC2543 and >> the bis drafts up to bis-05. >> >> >> U1->P1->P2->P3->P4>U2 >> >> I hope there no mistakes...:-) >Nope - I'm making the suggested changes to the example. The last > should be an -> >> U1->P1->P2->P3->P4>U2 Should Be >> U1->P1->P2->P3->P4->U2 Yes?? Jack _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 20 12:57:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11169 for ; Wed, 20 Feb 2002 12:57:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10757 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 12:57:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09478; Wed, 20 Feb 2002 12:34:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09447 for ; Wed, 20 Feb 2002 12:34:42 -0500 (EST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10276 for ; Wed, 20 Feb 2002 12:34:37 -0500 (EST) Received: from ALAYari ([192.168.209.22]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id JAA29163 for ; Wed, 20 Feb 2002 09:33:59 -0800 (PST) From: "Jack Lix" To: Date: Wed, 20 Feb 2002 09:37:25 -0800 Message-ID: <002b01c1ba35$43532500$16d1a8c0@ALAYari> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] 100rel Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, RFC2543: Section 8.1.3.2 Unrecognized Responses: The UAC MUST treat any response it does not recognize as being equivalent to the x00 response code of that class. So, if a new provisional response code is defined, 100rel can not be used with it until code updates are done at the UA's to "recognize" the new response code. 100 (Trying) is specifically excluded from the 100rel method. My guess is that most of the code in existance will allow any 1xx other than 100 to pass thru to the user and that it will allow 100rel - but that does not adhere to the specification. I suggest that the wording in the 100rel draft specifically allow the 100rel method for any 1xx (other than 100) response even if the UA does not specifically "recognize" the response code. The wording for excluding 100 Trying comes close but, IMHO, doesn't do the job. Thanks, Jack _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 20 12:58:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11312 for ; Wed, 20 Feb 2002 12:58:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10836 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 12:58:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08494; Wed, 20 Feb 2002 12:27:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08460 for ; Wed, 20 Feb 2002 12:26:56 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09157 for ; Wed, 20 Feb 2002 12:26:52 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1KHQQh29049 for ; Wed, 20 Feb 2002 09:26:26 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX66090; Wed, 20 Feb 2002 09:25:57 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA29862; Wed, 20 Feb 2002 09:26:24 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15475.56384.704095.62370@thomasm-u1.cisco.com> Date: Wed, 20 Feb 2002 09:26:24 -0800 (PST) To: sip@ietf.org X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [Sip] more SMIME comments Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit 1) You cannot put RFC 822 addresses into X.509 distinguished names (DN's). You either need to have a mapping function, or place requirements in subject-alt-name, etc. 2) The general requirements for a "keyring" for non-disk based UA's is, essentially, impossible. Unlike what Henning said yesterday, use for encryption requires that both the distinguished name and the entire public key (not a hash!) need to be stored. Considering that phones typically receive calls from anywhere, the storage needs are unbound. I'm willing to believe that this isn't an issue for a multi-gigabyte disk. For flash based UA's, however, this is an unreasonable requirement. 3) There is no suggestions about what UA's should do about root CA's. Why should a particular UA install a root cert? 4) in section 22.1 says that you verify with a certificate authority. This is misleading as it implies something you actively do with the CA. 5) 22.1: you can verify self-signed certificates just fine. You just don't know whether you trust the namespace. 6) 22.1: you don't verify certificates. You verify signatures. 7) A change in certificates stored is not necessarily an error. I don't think the normative text here is helpful because this is probably a revocation issue. As in, the UA complains to the user, and the user is supposed to do what, exactly? This seems loaded with the ability for abuse. More later. 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 daemon@optimus.ietf.org Wed Feb 20 13:10:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12391 for ; Wed, 20 Feb 2002 13:10:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11510 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 13:10:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10085; Wed, 20 Feb 2002 12:44:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10039 for ; Wed, 20 Feb 2002 12:44:03 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10687 for ; Wed, 20 Feb 2002 12:44:00 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1KHi3e23387; Wed, 20 Feb 2002 09:44:03 -0800 (PST) To: Michael Thomas Cc: sip@ietf.org Subject: Re: [Sip] more SMIME comments References: <15475.56384.704095.62370@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 20 Feb 2002 09:44:02 -0800 In-Reply-To: Michael Thomas's message of "Wed, 20 Feb 2002 09:26:24 -0800 (PST)" Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > 1) You cannot put RFC 822 addresses into X.509 > distinguished names (DN's). You either need to > have a mapping function, or place requirements > in subject-alt-name, etc. The SubjectAltName is the conventional location (see RFC 2632 S 4.4.3.). -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Wed Feb 20 13:10:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12427 for ; Wed, 20 Feb 2002 13:10:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11530 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 13:10:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09948; Wed, 20 Feb 2002 12:42:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09917 for ; Wed, 20 Feb 2002 12:42:47 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10630 for ; Wed, 20 Feb 2002 12:42:42 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1KHgpO23384; Wed, 20 Feb 2002 09:42:51 -0800 (PST) To: Michael Thomas Cc: sip@ietf.org Subject: Re: [Sip] SMIME and active MITM attacks References: <15475.53319.640011.994162@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 20 Feb 2002 09:42:51 -0800 In-Reply-To: Michael Thomas's message of "Wed, 20 Feb 2002 08:35:19 -0800 (PST)" Message-ID: Lines: 33 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > Second, the entire concept of using self-signed > certs in the face of active MITM attacks is bogus. > At least with rooted certs, you can at least show > a user that the identity presented is provably > part of a known CA's namespace. Self-signed certs > have no such insurance, so they provide no > additional authentication benefit in this case. > This is in contrast to SSH-like leap's of faith. > For SSH, the plausibility of an active MITM is > explicitly discounted because of the general > difficultly of mounting such an attack on the > Internet. I'm not sure that I agree with your assessment here, not so much because I don't think the threat of active attack is serious in the SIP context, than because I'm not really that sanguine about it's difficulty in the context of SSH. It's pretty easy to get code to mount hijacking attacks. As I see it, SSH's key management is intended to protect against semi-reactive attacks, where an attacker decides to impersonate a given party at a given time. Caching keys protects you from this attack. An attacker must perform the MITM attack at the time when the peers first communicate. This means either knowing in advance that you're going to attack a given party or mounting a global MITM attack so you can impersonate someone later. Similar comments apply to SIP. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Wed Feb 20 13:12:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12472 for ; Wed, 20 Feb 2002 13:12:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11589 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 13:12:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10519; Wed, 20 Feb 2002 12:52:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10488 for ; Wed, 20 Feb 2002 12:52:02 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11022 for ; Wed, 20 Feb 2002 12:52:00 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 3CA6E1E034 for ; Wed, 20 Feb 2002 12:52:02 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA28316; Wed, 20 Feb 2002 12:51:59 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id MAA81322; Wed, 20 Feb 2002 12:51:57 -0500 (EST) Date: Wed, 20 Feb 2002 12:51:57 -0500 (EST) Message-Id: <200202201751.MAA81322@fish.research.att.com> To: sip@ietf.org Subject: [Sip] bis-07.9: q values in Contact headers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Maybe I've been backwards in my understanding of "q" values, but it seems that line 1222 says the highest value is the less preferred. Lines 1176-1181 generate the ordered list from highest qvalue to lowest, but line 1183 just says to "contact each URI in the ordered list in turn...". I assumed "in turn" meant the highest qvalues first; if so, then line 1222 needs adjusting. Bill Marshall wtm@research.att.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 daemon@optimus.ietf.org Wed Feb 20 13:20:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12673 for ; Wed, 20 Feb 2002 13:20:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11915 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 13:20:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10720; Wed, 20 Feb 2002 12:56:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10694 for ; Wed, 20 Feb 2002 12:56:41 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11112 for ; Wed, 20 Feb 2002 12:56:34 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1KHu3h16951; Wed, 20 Feb 2002 09:56:03 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX66996; Wed, 20 Feb 2002 09:55:34 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA29869; Wed, 20 Feb 2002 09:56:02 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15475.58161.978119.327383@thomasm-u1.cisco.com> Date: Wed, 20 Feb 2002 09:56:01 -0800 (PST) To: EKR Cc: Michael Thomas , sip@ietf.org Subject: Re: [Sip] SMIME and active MITM attacks In-Reply-To: References: <15475.53319.640011.994162@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric Rescorla writes: > Michael Thomas writes: > > Second, the entire concept of using self-signed > > certs in the face of active MITM attacks is bogus. > > At least with rooted certs, you can at least show > > a user that the identity presented is provably > > part of a known CA's namespace. Self-signed certs > > have no such insurance, so they provide no > > additional authentication benefit in this case. > > This is in contrast to SSH-like leap's of faith. > > For SSH, the plausibility of an active MITM is > > explicitly discounted because of the general > > difficultly of mounting such an attack on the > > Internet. > I'm not sure that I agree with your assessment here, not > so much because I don't think the threat of active attack > is serious in the SIP context, than because I'm not really > that sanguine about it's difficulty in the context of SSH. > It's pretty easy to get code to mount hijacking attacks. > > As I see it, SSH's key management is intended to protect > against semi-reactive attacks, where an attacker decides > to impersonate a given party at a given time. Caching keys > protects you from this attack. An attacker must perform > the MITM attack at the time when the peers first communicate. > This means either knowing in advance that you're going to > attack a given party or mounting a global MITM attack so > you can impersonate someone later. Similar comments apply to SIP. The problem is that the path to the UAS is likely to always involve the same entities which may in fact be compromised. Unlike routers which have a pretty strong disincentive to track things (if nothing else, volume), it's not clear that proxies to a particular UAS wouldn't *always* mount active MITM attacks. Consider countries with low/non-existent civil rights which just as a matter of fact capture and/or re-write bodies to prevent subversives. In this case -- and I think it's probably a case naive users might think that a leap of faith might give better security than nothing -- it would not only be useless, it would be very dangerous since the perceived security was, in fact, an illusion. Considering that the object of this exercise is to thwart these kinds of abuses, I find the current text quite frightening, especially when you consider that the set of people who actually understand these kinds of attacks are vanishingly small. 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 daemon@optimus.ietf.org Wed Feb 20 13:48:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15598 for ; Wed, 20 Feb 2002 13:48:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13627 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 13:47:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12248; Wed, 20 Feb 2002 13:25:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12217 for ; Wed, 20 Feb 2002 13:25:46 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13175 for ; Wed, 20 Feb 2002 13:25:44 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AA29DE7B014E; Wed, 20 Feb 2002 13:25:45 -0500 Message-ID: <003101c1ba3b$d3c19300$2300000a@acmepacket.com> From: "Bob Penfield" To: "Jack Lix" , References: <002b01c1ba35$43532500$16d1a8c0@ALAYari> Subject: Re: [Sip] 100rel Date: Wed, 20 Feb 2002 13:24:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jack Lix" > Hi, > > RFC2543: Section 8.1.3.2 Unrecognized Responses: The UAC MUST treat any > response it does not recognize as being equivalent to the x00 response code > of that class. FYI, this has been changed in the latest bis spec to state that unrecognized 1xx are treated like 183 since 100 has many special rules. The x00 rule now only applies to final responses. > > So, if a new provisional response code is defined, 100rel can not be used > with it until code updates are done at the UA's to "recognize" the new > response code. 100 (Trying) is specifically excluded from the 100rel > method. > > My guess is that most of the code in existance will allow any 1xx other than > 100 to pass thru to the user and that it will allow 100rel - but that does > not adhere to the specification. > > I suggest that the wording in the 100rel draft specifically allow the 100rel > method for any 1xx (other than 100) response even if the UA does not > specifically "recognize" the response code. The wording for excluding 100 > Trying comes close but, IMHO, doesn't do the job. > > Thanks, > > Jack > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Wed Feb 20 13:58:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16022 for ; Wed, 20 Feb 2002 13:58:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14059 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 13:58:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11778; Wed, 20 Feb 2002 13:14:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11748 for ; Wed, 20 Feb 2002 13:14:28 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12568 for ; Wed, 20 Feb 2002 13:14:26 -0500 (EST) Received: from mira-sjc5-7.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1KIE3516986; Wed, 20 Feb 2002 13:14:03 -0500 (EST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX67487; Wed, 20 Feb 2002 10:12:02 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA29875; Wed, 20 Feb 2002 10:12:29 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15475.59149.508383.36054@thomasm-u1.cisco.com> Date: Wed, 20 Feb 2002 10:12:29 -0800 (PST) To: Jonathan Rosenberg Cc: James Undery , EKR , Michael Thomas , sip@ietf.org Subject: Re: [Sip] replays and SMIME In-Reply-To: <3C73BAF5.3E9FF185@dynamicsoft.com> References: <45730E094814E44488F789C1CDED27AE012F827C@GBNEWP0758M.eu.ubiquity.net> <3C73BAF5.3E9FF185@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > I don't even think you need anything beyond whats in bis, and you can > have the ability to provide challenges. The UAS receives an SMIME signed > request, rejects with a 401, requesting digest, providing a nonce, and a > random realm, like "foobar.invalid". The UAC, based on the procedures in > bis, will have no credentials for this realm, and thus it will use the > anonymous username and password. This would go into an Authorization > header, which the UAC would include as part of the signed message. The > key feature of the anonymous authentication is that it reflects back the > nonce, which is all you want to do here. 1) This is not in the text or obvious 2) It's not clear that the nonce can be shipped in the clear 3) Yuck 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 daemon@optimus.ietf.org Wed Feb 20 14:18:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16800 for ; Wed, 20 Feb 2002 14:18:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA15668 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 14:18:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13927; Wed, 20 Feb 2002 13:56:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13897 for ; Wed, 20 Feb 2002 13:56:45 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15939 for ; Wed, 20 Feb 2002 13:56:42 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1KIu8h04831; Wed, 20 Feb 2002 10:56:08 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX68866; Wed, 20 Feb 2002 10:55:38 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA29882; Wed, 20 Feb 2002 10:56:05 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15475.61765.863074.741623@thomasm-u1.cisco.com> Date: Wed, 20 Feb 2002 10:56:05 -0800 (PST) To: EKR Cc: Michael Thomas , sip@ietf.org Subject: Re: [Sip] SMIME and active MITM attacks In-Reply-To: References: <15475.53319.640011.994162@thomasm-u1.cisco.com> <15475.58161.978119.327383@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric Rescorla writes: > Michael Thomas writes: > > Considering that the object of this exercise > > is to thwart these kinds of abuses, I find the > > current text quite frightening, especially when > > you consider that the set of people who > > actually understand these kinds of attacks are > > vanishingly small. > I agree that this is a serious concern, but I'm not sure what > to do about it. It seems to me that we could adopt at least > three postures: > > (1) We require that all certificates be based on known CAs. > This seems unrealistic. > (2) Allow use of self-signed certs with SSH-style caching (more or > less as described in the text) which, as you point out, has serious > security holes. > (3) Allow use of self-signed certs with SSH-style caching but forbid > implementations to represent the peer as authenticated, while throwing > errors if the cert changes. > > This seems to be inherent in any certificate-based authentication > system. Is there some other option I've missed? No, you seem to capture the possibilities exactly right. I find the last two pretty scary since your average user is very likely to be completely gullible. If e2e security is the stated requirement from the IESG, I don't see any other alternative to (1) [1]. Mike [1] and yes I agree that it's unrealistic due to the "global PKI" problem, but that's why I think the utility of this is suspect in the first place... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 20 14:28:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17262 for ; Wed, 20 Feb 2002 14:28:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA15957 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 14:28:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14936; Wed, 20 Feb 2002 14:03:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14902 for ; Wed, 20 Feb 2002 14:03:17 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16286 for ; Wed, 20 Feb 2002 14:03:14 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1KJ3T623546; Wed, 20 Feb 2002 11:03:29 -0800 (PST) To: Michael Thomas Cc: sip@ietf.org Subject: Re: [Sip] SMIME and active MITM attacks References: <15475.53319.640011.994162@thomasm-u1.cisco.com> <15475.58161.978119.327383@thomasm-u1.cisco.com> <15475.61765.863074.741623@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 20 Feb 2002 11:03:29 -0800 In-Reply-To: Michael Thomas's message of "Wed, 20 Feb 2002 10:56:05 -0800 (PST)" Message-ID: Lines: 17 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > No, you seem to capture the possibilities > exactly right. I find the last two pretty scary > since your average user is very likely to be > completely gullible. If e2e security is the > stated requirement from the IESG, I don't see > any other alternative to (1) [1]. There's always possibility 1(a), where we require PKI but then put in text explaining the self-signed alternative in excruciating detail. All in the interest of explaining why you wouldn't want to do it, of course. :) -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Wed Feb 20 14:36:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17542 for ; Wed, 20 Feb 2002 14:36:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16581 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 14:36:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15647; Wed, 20 Feb 2002 14:18:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15613 for ; Wed, 20 Feb 2002 14:18:30 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16787 for ; Wed, 20 Feb 2002 14:18:26 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1KJHwh03227; Wed, 20 Feb 2002 11:17:58 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX69562; Wed, 20 Feb 2002 11:17:30 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA29885; Wed, 20 Feb 2002 11:17:57 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15475.63077.490425.210239@thomasm-u1.cisco.com> Date: Wed, 20 Feb 2002 11:17:57 -0800 (PST) To: EKR Cc: Michael Thomas , sip@ietf.org Subject: Re: [Sip] SMIME and active MITM attacks In-Reply-To: References: <15475.53319.640011.994162@thomasm-u1.cisco.com> <15475.58161.978119.327383@thomasm-u1.cisco.com> <15475.61765.863074.741623@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric Rescorla writes: > Michael Thomas writes: > > No, you seem to capture the possibilities > > exactly right. I find the last two pretty scary > > since your average user is very likely to be > > completely gullible. If e2e security is the > > stated requirement from the IESG, I don't see > > any other alternative to (1) [1]. > There's always possibility 1(a), where we require PKI but then put in > text explaining the self-signed alternative in excruciating detail. > All in the interest of explaining why you wouldn't want to do it, > of course. :) Right now, I doubt that I would trust an implementation which did what was recommended in bis to provide me authentication or confidentiality, mainly because it would be very hard to determine how the developers interpreted the spec. Given that the likelihood is that it will be SIP developers integrating SMIME into their product, I fear the worst because most of these considerations are pretty opaque in my experience of having to explain this kind of stuff to them. :-( 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 daemon@optimus.ietf.org Wed Feb 20 14:55:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18104 for ; Wed, 20 Feb 2002 14:55:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17357 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 14:55:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16625; Wed, 20 Feb 2002 14:37:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16597 for ; Wed, 20 Feb 2002 14:37:06 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17556 for ; Wed, 20 Feb 2002 14:37:02 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g1KJb0io027838; Wed, 20 Feb 2002 21:37:00 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15475.64220.653014.245001@harjus.eng.song.fi> Date: Wed, 20 Feb 2002 21:37:00 +0200 To: EKR Cc: Michael Thomas , sip@ietf.org Subject: Re: [Sip] SMIME and active MITM attacks In-Reply-To: References: <15475.53319.640011.994162@thomasm-u1.cisco.com> <15475.58161.978119.327383@thomasm-u1.cisco.com> <15475.61765.863074.741623@thomasm-u1.cisco.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Eric Rescorla writes: > There's always possibility 1(a), where we require PKI but then put in > text explaining the self-signed alternative in excruciating detail. > All in the interest of explaining why you wouldn't want to do it, > of course. :) no matter how much the text would push for global pki, it simply won't happen. realistically the user needs to rely on transitive trust or communicate e2e in the same way as we do today with ssh. -- 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 daemon@optimus.ietf.org Wed Feb 20 15:12:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16799 for ; Wed, 20 Feb 2002 14:18:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA15666 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 14:18:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13500; Wed, 20 Feb 2002 13:45:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13469 for ; Wed, 20 Feb 2002 13:45:45 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15543 for ; Wed, 20 Feb 2002 13:45:41 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1KIjrG23527; Wed, 20 Feb 2002 10:45:53 -0800 (PST) To: Michael Thomas Cc: sip@ietf.org Subject: Re: [Sip] SMIME and active MITM attacks References: <15475.53319.640011.994162@thomasm-u1.cisco.com> <15475.58161.978119.327383@thomasm-u1.cisco.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 20 Feb 2002 10:45:53 -0800 In-Reply-To: Michael Thomas's message of "Wed, 20 Feb 2002 09:56:01 -0800 (PST)" Message-ID: Lines: 29 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Michael Thomas writes: > Considering that the object of this exercise > is to thwart these kinds of abuses, I find the > current text quite frightening, especially when > you consider that the set of people who > actually understand these kinds of attacks are > vanishingly small. I agree that this is a serious concern, but I'm not sure what to do about it. It seems to me that we could adopt at least three postures: (1) We require that all certificates be based on known CAs. This seems unrealistic. (2) Allow use of self-signed certs with SSH-style caching (more or less as described in the text) which, as you point out, has serious security holes. (3) Allow use of self-signed certs with SSH-style caching but forbid implementations to represent the peer as authenticated, while throwing errors if the cert changes. This seems to be inherent in any certificate-based authentication system. Is there some other option I've missed? -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Wed Feb 20 15:41:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19354 for ; Wed, 20 Feb 2002 15:41:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20029 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 15:41:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18663; Wed, 20 Feb 2002 15:20:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18635 for ; Wed, 20 Feb 2002 15:20:57 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18700 for ; Wed, 20 Feb 2002 15:20:53 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1KKLF6Y011138; Wed, 20 Feb 2002 15:21:16 -0500 (EST) Message-ID: <3C740508.5E7A28DB@dynamicsoft.com> Date: Wed, 20 Feb 2002 15:20:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Comments on 100rel pre-release Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jo Hornsby wrote: > > Sorry. Again with the disclaimer about my poor > ability to notice re-reports. > > * Section 1; Paragraph 3: > First use of "TU". > > * Section 1; Paragraph 4: > First use of "UAC". > > * Section 3: > First use of "UAS". These are all terms defined in bis. There is a dependency on bis, IMHO, for both semantics and acronym expansion. I am not really inclined to re-expand acronyms which you can get out of the definitions section of bis. > > * Section 3; Paragraph 10: > Missing closing parenthesis after "RFC BBBB". > [Dunno how generous the RFC Editor will be, > eh? (:&] Fixed. > > * Section 3; Paragraph 13; Sentence 1: > It might be helpful to > s/If a PRACK request/If a new PRACK request/ > to emphasise that this doesn't apply to > retransmissions of a PRACK? Yeah, good point. That aspect is better handled by saying "If a PRACK request is received by the UA core", since the transaction layer will handle the retransmit issues. > > * Section 4; Paragraph 2: > "100rel" is quoted here. Not sure what the > preferred apprach should be, but I guess it > should be consistent. Right. Removed all quotes. > > * Section 4; Paragraph 8: > s/TU/UAC ? Hmm. UAC is probably better. > > * Section 5; Paragraph 3: > For consistency, I would have thought > s/a session description/an offer/ ? > But this might make the sentence a little > hard to parse. I think offer is better. Fixed. > > * Section 5; Paragraph 4: > s/a session description/an offer or an answer/ > Perhaps? I think you mean paragraph 5 here. I think "session description" is OK. > > * Table 1: > - Accept/415: I suspect should be "m"? I looked in bis, and its "o" there for Accept, Accept-Encoding, and Accept-Language. The text in the spec is inconsistent. The UA section says that a UAS MUST insert Accept when it rejects a request because the body wasn't understood. The Accept header section says its a SHOULD. I think its a MUST. However, table 2 cannot just say "m"; thats not sufficient. The reason is that the 415 could have been sent because of an invalid encoding, so that the 415 would need to have an Accept-Encoding, but not Accept. The basic problem is that the constraints that dictate whether or not a header needs to be included in a message, can be more complicated than just the method or response code. Here, its response code along with some other condition. My proposal to fix this, is to take the "c" value from table 2, and generalize it. A value of "c" means that there are conditions which will make this header have different strengths for inclusion in this message, and that you need to read the text to figure it out. Then, the rows for Accept, Accept-Encoding, Accept-Language for the 415 code would all be "c". Existing "c" values in the table would remain "c". > > * Table 2: > - Record-Route: s/,401,484// Egads... good point. I copied table 2/3 from bis before the editors did a serious sweep through the table, cleaning it up. I'll have to back-propagate those changes, inclduing this one. > - To: c(1) -- I don't see how it's possible > that there could be no tag. Forgot to change that in the copy-paste. > - Unsupported/420: Shouldn't this read "m"? Yup. Its still wrong in bis too. Grrr, I thought we fixed it... > > * Table 3: > - RSeq: Only INV should be "o", right? The > rest "-"? Right, thanks. > > * Section 9: > I'm not sure how valid a concern this is, but > I might perceive a vague DoS attack based on > a MitM adding the option tag "100rel" to the > Require: in a request. Seems like the UAS > might have to transmit a lot more responses > that it would usually in this case? Only if the uas would otherwise send a provisional response (not 100, of course). Having Require:100rel doesn't force sending of provisional resposnes, on sending provisional responses that are sent, to be sent reliably. No worse than if you just used TCP w/o this extension. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 20 15:41:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19372 for ; Wed, 20 Feb 2002 15:41:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20059 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 15:41:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18812; Wed, 20 Feb 2002 15:22:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18709 for ; Wed, 20 Feb 2002 15:22:14 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18736 for ; Wed, 20 Feb 2002 15:22:10 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Wed, 20 Feb 2002 12:21:04 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 20 Feb 2002 12:21:42 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Feb 2002 12:21:04 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Feb 2002 12:21:04 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Wed, 20 Feb 2002 12:19:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] draft-ietf-sip-rfc2543bis-07.9 now available Date: Wed, 20 Feb 2002 12:19:00 -0800 Message-ID: Thread-Topic: [Sip] draft-ietf-sip-rfc2543bis-07.9 now available thread-index: AcG5BYnsHNN2pnUaTdGapm2i3tdAngBQyxAA From: "Christian Huitema" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 20 Feb 2002 20:19:01.0270 (UTC) FILETIME=[D5A41B60:01C1BA4B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA18710 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit In the Security section, the draft identifies the threat of "Impersonating a Server" (26.1.2). I would suggest that we document a variant of this threat, DNS poisoning, and add text such as: A possible way to impersonate a server is to use attacks against the Domain Name System, such as "DNS poisoning." As explained in the section 4, Overview of Operation, we expect that a particular type of DNS queries can be used to find the SIP server that serves a specific domain; attacking the DNS can induce a proxy or a UA to route the message towards an impersonating server. The threat to the UA is addressed in section 26.3.2.1 by stating that the certificate must "correspond with the domain in which the UA intends to register", which is explained next as "must identify a host within the atlanta.com domain (such as sip.atlanta.com)." This is reasonable, but weak. With this rule, any host in the atlanta.com domain could fake a registration server; there is no way for the domain manager to hand out certificates that specifically designate the recipient as "an authorized SIP server for the domain." An easily implemented protection would be a host name convention, such as having a certificate that actually identifies the host as "sip.". A similar text is used in section 26.3.2.2, Interdomain Requests: "The atlanta.com proxy server, for example, SHOULD verify at this stage that the certificate received from the remote side corresponds with the biloxi.com domain." This is again a bit underspecified, since it would potentially allow any compromised host in the "biloxi.com" domain to impersonate a server. Again, a formal host name convention would be more effective. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 20 15:45:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19511 for ; Wed, 20 Feb 2002 15:45:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20340 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 15:45:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18957; Wed, 20 Feb 2002 15:25:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18926 for ; Wed, 20 Feb 2002 15:25:16 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18830 for ; Wed, 20 Feb 2002 15:25:13 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1KKMhQl022646 for ; Wed, 20 Feb 2002 15:22:43 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGH85>; Wed, 20 Feb 2002 15:24:46 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630092@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'sip@ietf.org'" Date: Wed, 20 Feb 2002 15:24:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] bis-07.9 nit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Line 3728/3729 says: "...UDP on a particular address and port just because it is listening on that same address and port for UDP." I beleive the second "UDP" should be "TCP." /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 daemon@optimus.ietf.org Wed Feb 20 16:23:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20725 for ; Wed, 20 Feb 2002 16:23:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21994 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 16:23:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21525; Wed, 20 Feb 2002 16:04:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21492 for ; Wed, 20 Feb 2002 16:04:15 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20105 for ; Wed, 20 Feb 2002 16:04:10 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1KL1fQl023042 for ; Wed, 20 Feb 2002 16:01:41 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGH9P>; Wed, 20 Feb 2002 16:03:41 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630093@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'sip@ietf.org'" Date: Wed, 20 Feb 2002 16:03:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] bis-07.9 "sips:" additions (actually about "SIPS," not S/MIME). Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Some comments on the new "sips" URI stuff added to the bis-07.9 draft; line numbers, of course, come from the PS/PDF versions. ---------------------------------------------------------------------- (line 990) When a pre-existing route set is present, the procedures for populating the Request-URI and Route header field detailed in Section 12.2.1.1 MUST be followed, even though there is no dialog. If the Request-URI specifies a SIPS URI, all the SIP URI in the route set MUST be converted to SIPS URI (by changing the scheme to SIPS) before performing the processing of Section 12.2.1.1. Is this a safe transform to define this way? It's certainly *not* how HTTP tends to work. (Applies also to line 2010, 2700, 3705). It is also not consistently applied, as certain passages require nodes to upgrade URIs from "sip" to "sips", and certain other passages require the rejection of "sip" URIs without even trying their "sips" equivalents. (line 1174) If the original request had a SIPS URI in the Request-URI, the client MUST discard any Contact header fields which do not contain SIPS URIs. I would propose this end in "...do not contain a method that will be used over an appropriately secured channel." If I send an INVITE with a "sips" URI as the Req-URI, I should be able to pursue an "https" uri if it is returned in a 380 response. (Same comment on lines 1424, 1599, 1719, 1879, 2559, and probably others). For some of the registrar-related things, I think you need to completely relax the restrictions, since the registrar won't necessarily know what types of URIs point to resources that can be contacted in a secure fashion. (If I send an INVITE and get a 380 back with a mailto: URI, my client might be able to deduce that, since I have a PGP key for the address in the mailto: URI, popping up a mailer with PGP enabled would be a reasonable thing to do). Further, if the rule I object to above (about the validity of just changing "sip:" to "sips:") is actually in force, can't we just expect the UAC (or the registrar) to swap out the scheme and just expect everything to magically work (as I allude to above)? ---------------------------------------------------------------------- In all, I see the need for a "sips" scheme, but I'm worried that it hasn't been thought out well enough. The conversion from "sip" to "sips" (and its inconsistent application) as well as the overly- restrictive non-future-proof "MUST" strength rules that pervade the draft about "sips" URIs only ever being able to map to other "sips" URIs are worrisome, and I beleive that my forgoing objections demonstrate that insufficient analysis has gone into their design. If *at* *all* possible, I think we could avoid a huge, earth-shaking, several-year-long-regret-inducing mistake by moving the "sips" stuff into a seperate draft and allowing it to mature for longer than two weeks before cementing it into an RFC. If that's not feasible for reasons of parlimentary procedure and other red-tape related BS, we should at least make sure we spend a good long time thinking about the ramifications of automatically swapping out "sips" for "sip" and are comforatble with them; making sure that *if* such rules exist, they are applied in as many places possible to aid interoperability; and ensuring that that "sips" plays well with other schemes, so long as those schemes can be appropriately secured. In particular, saying that 3xx responses to requests that have "sips" URIs MUST NOT contain non-"sips" URIs seems completely unacceptable, since it fails to acknowlege that the client might just know better than the server what all other schemes mean. Further, saying that clients MUST NOT act on non-"sips" URIs returned in such a fashion is a rather embarassing oversight of the fact that the client may know quite well how to secure communications over channels established using non-"sips" URIs. /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 daemon@optimus.ietf.org Wed Feb 20 17:22:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22210 for ; Wed, 20 Feb 2002 17:22:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25421 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 17:22:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23209; Wed, 20 Feb 2002 16:53:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23182 for ; Wed, 20 Feb 2002 16:53:24 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21476 for ; Wed, 20 Feb 2002 16:53:19 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1KLrg6Y011390; Wed, 20 Feb 2002 16:53:42 -0500 (EST) Message-ID: <3C741AB3.E212D68C@dynamicsoft.com> Date: Wed, 20 Feb 2002 16:52:51 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: "'sip@ietf.org'" Subject: Re: [Sip] bis-07.9 nit References: <9BF66EBF6BEFD942915B4D4D45C051F3630092@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Yup, we (actually, Robert) noticed this and it will be fixed. Adam Roach wrote: > > Line 3728/3729 says: "...UDP on a particular address and > port just because it is listening on that same address and > port for UDP." > > I beleive the second "UDP" should be "TCP." > > /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 -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 20 17:23:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22231 for ; Wed, 20 Feb 2002 17:23:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25455 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 17:23:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23586; Wed, 20 Feb 2002 16:58:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23557 for ; Wed, 20 Feb 2002 16:58:05 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21605 for ; Wed, 20 Feb 2002 16:58:00 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1KLwM6Y011397; Wed, 20 Feb 2002 16:58:22 -0500 (EST) Message-ID: <3C741BCB.F2FC6C6C@dynamicsoft.com> Date: Wed, 20 Feb 2002 16:57:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: James Undery , EKR , sip@ietf.org Subject: Re: [Sip] replays and SMIME References: <15475.59149.508383.36054@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > This would go into an Authorization > > header, which the UAC would include as part of the signed message. > The > > key feature of the anonymous authentication is that it reflects back > the > > nonce, which is all you want to do here. > > 1) This is not in the text or obvious Agreed. Its one of these things that doesn't require additional specification, but would likely not work unless it is explicitly pointed out. > 2) It's not clear that the nonce can be shipped in the clear Why not? We ship it in the clear for normal digest. Can you point to a specific problem? > 3) Yuck Thats not very useful. Neither is your comment (2). I am looking for statements of conrete problems, and then proposals of concrete solutions, not the kinds of statements above which don't help this working group. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 20 17:37:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22604 for ; Wed, 20 Feb 2002 17:37:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA26442 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 17:37:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25133; Wed, 20 Feb 2002 17:19:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25099 for ; Wed, 20 Feb 2002 17:19:27 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22131 for ; Wed, 20 Feb 2002 17:19:21 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1KMImh21848; Wed, 20 Feb 2002 14:18:48 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX74587; Wed, 20 Feb 2002 14:18:19 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA29911; Wed, 20 Feb 2002 14:18:47 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15476.8391.87857.477584@thomasm-u1.cisco.com> Date: Wed, 20 Feb 2002 14:18:47 -0800 (PST) To: Jonathan Rosenberg Cc: Michael Thomas , James Undery , EKR , sip@ietf.org Subject: Re: [Sip] replays and SMIME In-Reply-To: <3C741BCB.F2FC6C6C@dynamicsoft.com> References: <15475.59149.508383.36054@thomasm-u1.cisco.com> <3C741BCB.F2FC6C6C@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > > > Michael Thomas wrote: > > > > This would go into an Authorization > > > header, which the UAC would include as part of the signed message. > > The > > > key feature of the anonymous authentication is that it reflects back > > the > > > nonce, which is all you want to do here. > > > > 1) This is not in the text or obvious > > Agreed. Its one of these things that doesn't require additional > specification, but would likely not work unless it is explicitly pointed > out. > > > > 2) It's not clear that the nonce can be shipped in the clear > > Why not? We ship it in the clear for normal digest. Can you point to a > specific problem? > > > 3) Yuck > > Thats not very useful. Neither is your comment (2). I am looking for > statements of conrete problems, and then proposals of concrete > solutions, not the kinds of statements above which don't help this > working group. Jonathan, I have sent out serveral pieces of mail about *concrete* problems over the last few days, and I made a proposal of a potential way to fix this particular issue yesterday. Apparently that was not enough. And it's still not clear that what you've proposed is correct. An active attacker in the middle could capture the nonce and create a new signature. Is that secure? You are not solving a proxy authentication problem here. You are making claims that somebody can use these e2e security mechanism which pass through proxies and have a reasonable degree of certainty that they will not be easily compromised through proxies where there may well be significant incentive for bad guys to do very bad things. And please don't cop attitude that this is not without performance impact. "Yuck" is a perfectly reasonable response to something that increases the ever escalating message load for a simple call even more. However, if what you're really asking for me to do is shut up because it's too close to deadlines, fine. I'll unsubscribe until the working group feels like actually solving security problems instead of throwing in last minute, not well thought out or reviewed, feel-good security mechanisms for the benefit of the AD's, and the detriment of SIP. 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 daemon@optimus.ietf.org Wed Feb 20 18:15:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23506 for ; Wed, 20 Feb 2002 18:15:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28568 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 18:15:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26745; Wed, 20 Feb 2002 17:43:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26718 for ; Wed, 20 Feb 2002 17:43:21 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22766 for ; Wed, 20 Feb 2002 17:43:18 -0500 (EST) Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g1KMhY323750; Wed, 20 Feb 2002 14:43:34 -0800 (PST) To: Jonathan Rosenberg Cc: Michael Thomas , James Undery , sip@ietf.org Subject: Re: [Sip] replays and SMIME References: <15475.59149.508383.36054@thomasm-u1.cisco.com> <3C741BCB.F2FC6C6C@dynamicsoft.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 20 Feb 2002 14:43:34 -0800 In-Reply-To: Jonathan Rosenberg's message of "Wed, 20 Feb 2002 16:57:31 -0500" Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan Rosenberg writes: > Michael Thomas wrote: > > 2) It's not clear that the nonce can be shipped in the clear > > Why not? We ship it in the clear for normal digest. Can you point to a > specific problem? This could use some analysis but I think it's safe. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 daemon@optimus.ietf.org Wed Feb 20 18:17:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23549 for ; Wed, 20 Feb 2002 18:17:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28611 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 18:17:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27073; Wed, 20 Feb 2002 17:48:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27042 for ; Wed, 20 Feb 2002 17:48:14 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22884 for ; Wed, 20 Feb 2002 17:48:11 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A7AEA439014A; Wed, 20 Feb 2002 17:48:14 -0500 Message-ID: <001b01c1ba60$7554c100$2300000a@acmepacket.com> From: "Bob Penfield" To: "Jonathan Rosenberg" , Subject: [Sip] comments on draft-ietf-sip-rfc2543bis-07.9 Date: Wed, 20 Feb 2002 17:46:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Here are my comments (so far) on bis-07.9. Mostly nits. line 526: having "(sip:bob@biloxi.com)" immediately follow "SIPS URI" might mislead people into thinking it is an example SIPS URI instead of a SIP URI. line 731: Do we need a definition of "Remote Target"? line 853-856: The sentence "Multiple header field rows with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list (that is, if follows the grammar defined in Section 7.3)" does not make sense to me. I think the sentence that follows it says what it was trying to say. I suggest removing this sentence and placing "Multiple header field rows with the same field-name MAY be present in a message." before "The relative order ...." at line 853. line 890: Does the fact that the '=parameter-value' part is optional (e.g. the lr parameter) need to be expressed here? line 997: s/MUST support the SIP and URI/MUST support the SIP URI/ line 1059-1060: suggest adding a "see section 10.2 and 10.3" to point the reader to REGISTER CSeq rules/usage. line 1098 & 1100: does it need to say "SIP or SIPS URI" instead of just "SIP URI"? line 1286 says "if the request has no To tag", but line 1287 includes "To tag" in the match. Also, "(including tags)" is no longer needed if we're only comparing the tags. Or do we need to keep the full To/From header comparison for the Merged Request test? line 1610-1611 suggests a default of one hour, but line 1726 indicates a locally-configured default. Since 1610-1611 really mean what the UAS/Register should assume, but section 10.2.1.1 is about how a client constructs a request, 1610-1611 should be removed. If we want to suggest a default of one hour, it should be mentioned near line 1726. Line 1626 says that the "*" contact allows a UA to remove *its* bindings, but actually all bindings from all UAs will be removed. Also, you may want to add "for the address-of-record" after "all registrations" at line 1624 so that it is clear that all bindings from all UAs are removed. line 1729 & line 4299: s/Registration Too Brief/Interval Too Brief/ That's all for now. I'll probably have more tomorrow. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.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 daemon@optimus.ietf.org Wed Feb 20 20:56:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25883 for ; Wed, 20 Feb 2002 20:56:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA05807 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 20:56:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04306; Wed, 20 Feb 2002 20:26:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04239 for ; Wed, 20 Feb 2002 20:26:33 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25534; Wed, 20 Feb 2002 20:26:30 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1L1PmO02510; Wed, 20 Feb 2002 20:25:48 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAF54788; Wed, 20 Feb 2002 20:28:40 -0500 (EST) Message-ID: <3C744B13.95D7A388@cisco.com> Date: Wed, 20 Feb 2002 20:19:15 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: mmusic@ietf.org, sip@ietf.org, sip-implementors@cs.columbia.edu References: <3C5986B7.8DB8FF31@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] updated offer/answer draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sorry to be slow commenting - I am backed up on my reading. I have one possible nit. You have incorporated a:inactive as the replacement for c=0.0.0.0 for hold, and indicated that use of c=0.0.0.0 is deprecated though it still must be supported by recipients. I think it is a bit strong to say that it is deprecated. There are still cases where it is *needed*. In particular, a B2BUA may need to offer on hold to solicit an answer, with the intent to make a new offer later after another offer/answer exchange with another party. In this case, it may not desire or be capable of receiving RTCP, or of providing an address/port to do so. The C=0.0.0.0 provides an effective solution in this case. So, rather than being deprecated for all use, I think the use of c=0.0.0.0 ought to be be more narrowly restricted. Paul Jonathan Rosenberg wrote: > > Folks, > > I have just submitted an update to the offer/answer model draft. Until > it appears in the archives, you can pick it up at: > > http://www.jdrosen.net/papers/draft-ietf-mmusic-sdp-offer-answer-00.txt > > This draft includes all of the changes agreed to since IETF 52 and on > the list since then. There are no open issues that I am aware of. > > Perhaps the most substantial change is the allowance of different > payload type numbers in each direction, as per list discussion on > mmusic. Other changes are noted in the changes section. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/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 daemon@optimus.ietf.org Wed Feb 20 23:23:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29774 for ; Wed, 20 Feb 2002 23:23:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA12233 for sip-archive@odin.ietf.org; Wed, 20 Feb 2002 23:23:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10111; Wed, 20 Feb 2002 22:48:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10086 for ; Wed, 20 Feb 2002 22:48:02 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29197 for ; Wed, 20 Feb 2002 22:47:58 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L3mM6Y011940; Wed, 20 Feb 2002 22:48:22 -0500 (EST) Message-ID: <3C746DD3.E881C0A2@dynamicsoft.com> Date: Wed, 20 Feb 2002 22:47:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: "'sip@ietf.org'" Subject: compromising on sips and finishing bis, was: Re: [Sip] bis-07.9 "sips:" additions (actually about "SIPS," not S/MIME). References: <9BF66EBF6BEFD942915B4D4D45C051F3630093@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, The sip editors, along with Allison, had a conference call this evening to discuss the concerns, well stated by Adam in his note below, that have been raised about sips. We think we have a set of changes that will be made which should achieve a good tradeoff between perfect security, and specification risk/flexibility. Specific changes that we plan on making for bis-08: 1. a proxy that receives a request with a sips request-URI, and runs a location service, SHOULD translate that to a sips URI (and similarly, a UA SHOULD only put a sips URI in the contacts of a registration for a sips address-of-record, the registrar will accept what it is told). In the pre-release, this was a MUST. There will be accompanying text that explains why you really, really do want to use a sips contact. However, we leave the door open to configurations where there is sufficient security through other, non TLS means. We think that having the appropriate words that explain the motivation for this, ultimately provide better security than a MUST without explanation (since implementors might ignore it). 2. You can redirect a sips URI to anything you like, but a proxy SHOULD NOT recurse on it unless its sips URI too. If its not, the proxy just passes it upstream. This would allow the user to make a decision. This means we can continue to redirect to mailto, http, and so on, but preserve end-to-end path security if the user desires. 3. When a client (UA or proxy) has a pre-loaded route set, and it has a sips URI in the request-URI, it doesn't "convert" any sip URI in the route set to a sips URI. Rather, when it does the normal NAPTR processing on that URI in the route header, it MUST only use the "SIPS+D2X" services, so that the request gets sent securely. If there is no DNS or NAPTR, it just uses TLS on port 5061. The spec will mandate that a proxy listen for TLS on 5061, so that this will always work. 4. The issues about a UA converting the record-routes to sips will also go away. Rather, a UA that receives a request over SIPS will need to put a sips URI in the Contact header, presuming that the top record-route, or contact if there is no record-route, is also a sips URI. If the top record-route (or contact if not present) is not a sips URI, it has to put a sip URI in there (otherwise, you may have an interop failure). Similarly, a proxy can only record-route with a sips URI if the thing to its left/right (in Record-route or contact) has a sips URI. This is the same as the rules for record-routing with transport=tcp that we've had all along. The rules have the property that if the originator uses sips, the whole path will be secure. If sips was used in the middle (i.e., someone translated a sip URI to sips), you may not have security for the entire path, either at call setup or for mid-dialog requests. 5. Overall, we believe that the security of using sips:user@domain, as opposed to sip:user@domain;transport=tls, is very significant. In fact, I think its a fair statement that the old transport=tls mechanism provided insufficient guarantees to be truly useful. As such, we strongly feel that the sips mechanisms, with the changes above, should remain in bis. SPecific responses to Adam, based on this: Adam Roach wrote: > > Some comments on the new "sips" URI stuff added to the bis-07.9 draft; > line numbers, of course, come from the PS/PDF versions. > > ---------------------------------------------------------------------- > > (line 990) > When a pre-existing route set is present, the procedures for populating > the > Request-URI and Route header field detailed in Section 12.2.1.1 MUST be > followed, even though there is no dialog. If the Request-URI specifies a > SIPS URI, all the SIP URI in the route set MUST be converted to SIPS URI > (by > changing the scheme to SIPS) before performing the processing of Section > 12.2.1.1. > > Is this a safe transform to define this way? It's certainly *not* > how HTTP tends to work. (Applies also to line 2010, 2700, 3705). As per above, the route set would not be changed. All that would change is the NAPTR processing - you have to use the "SIPS+D2X" records when you resolve that sip URI in the top route header. > It is also not consistently applied, as certain passages require > nodes to upgrade URIs from "sip" to "sips", and certain other > passages require the rejection of "sip" URIs without even trying > their "sips" equivalents. I think that, with the above change, there is no longer any rejections or conversions. Rather, rules that constrain what gets put in (sips URI v. sip URI) and what DNS records you can use. > > (line 1174) > If the original request had a SIPS URI in the Request-URI, the client > MUST > discard any Contact header fields which do not contain SIPS URIs. > > I would propose this end in "...do not contain a method that will > be used over an appropriately secured channel." If I send an INVITE > with a "sips" URI as the Req-URI, I should be able to pursue an > "https" uri if it is returned in a 380 response. (Same comment on > lines 1424, 1599, 1719, 1879, 2559, and probably others). As per above, this constraint is relaxed. You can redirect to anything you like, but a proxy cannot recurse on a non-sips URI. (at SHOULD NOT strength). This mirrors the behavior for proxying in general. > > For some of the registrar-related things, I think you need to > completely relax the restrictions, since the registrar won't > necessarily know what types of URIs point to resources that can > be contacted in a secure fashion. (If I send an INVITE and get a > 380 back with a mailto: URI, my client might be able to deduce that, > since I have a PGP key for the address in the mailto: URI, popping > up a mailer with PGP enabled would be a reasonable thing to do). This was the essence of the long debate we had on the subject, with the compromise above. You SHOULD register sips URIs, but you can register other things so long as they can be secured. Basically, by registering against a sips URI, the UA is making a commitment that the contact it is registering is reachable with sufficient security. > > Further, if the rule I object to above (about the validity of just > changing "sip:" to "sips:") is actually in force, can't we just > expect the UAC (or the registrar) to swap out the scheme and just > expect everything to magically work (as I allude to above)? > > ---------------------------------------------------------------------- > > In all, I see the need for a "sips" scheme, but I'm worried that it > hasn't been thought out well enough. I have a lot more confidence myself in it as a result of the discussions this evening that will reflect in bis-08. Although things are moving fast, it is not without careful consideration. > The conversion from "sip" to > "sips" (and its inconsistent application) as well as the overly- > restrictive non-future-proof "MUST" strength rules that pervade > the draft about "sips" URIs only ever being able to map to other > "sips" URIs are worrisome, and I beleive that my forgoing objections > demonstrate that insufficient analysis has gone into their design. I hope the changes above will satisfy your concerns. > > If *at* *all* possible, I think we could avoid a huge, earth-shaking, > several-year-long-regret-inducing mistake by moving the "sips" stuff > into a seperate draft and allowing it to mature for longer than two > weeks before cementing it into an RFC. Well, that is unavoidable. Its really simple - we NEED a TLS mechanism (we've had one in bis for a long time). The previous mechanism was found to have holes (specifically, it didn't allow for a more rigorous notion of transitive trust through multiple hops, and it didn't work well with DNS (being subject to DNS attacks), and it didn't work well with multiple TLS transports, like TCP and SCTP). The sips approach maintains the TLS capabilities we always had before, but fixes those holes. Thus, there will be a sips mechanism in bis. I think that, with the above changes, it still allows us flexibility (including the ability to upgrade that SHOULD to a MUST down the road), with a pretty good security story. > > If that's not feasible for reasons of parlimentary procedure and other > red-tape related BS, Its not procedure or BS. Its a simple fact that a spec cannot proceed with broken mechanisms, or without sufficient security. Our TLS usage did not provide sufficient security, and had enough flaws that it needed to be fixed. > we should at least make sure we spend a good long > time thinking about the ramifications of automatically swapping out > "sips" for "sip" and are comforatble with them; making sure that *if* > such rules exist, they are applied in as many places possible to > aid interoperability; and ensuring that that "sips" plays well with > other schemes, so long as those schemes can be appropriately secured. I think the changes described above meet your goals. > > In particular, saying that 3xx responses to requests that have "sips" > URIs MUST NOT contain non-"sips" URIs seems completely unacceptable, > since it fails to acknowlege that the client might just know better > than the server what all other schemes mean. Further, saying that > clients MUST NOT act on non-"sips" URIs returned in such a fashion is > a rather embarassing oversight of the fact that the client may know > quite well how to secure communications over channels established > using non-"sips" URIs. Both of these suggestions (with the caveat that "client" does NOT include a proxy; only the caller can decide whether to pursue a non-secure redirection) have been reflected in the proposed changes. One final note. One of the most valuable things I learned from executive at my former employer is this pearl of wisdom, "Finished is a feature, and arguably the most important one". I am certain that, even with these changes, there are still questions and issues with the sips mechanism (and indeed, everything else). However, we need to finish bis, and we have customers anxiously waiting its arrival. Indeed, the ramifications of not finishing are quite severe. Like everything else, it is a tradeoff. I believe we are at the point where we have achieved a very good tradeoff between just finishing it, and getting it perfect. That tradeoff is not something the sip group has been very good at, so it is sometimes a bit of a hard pill to swallow. Do not take that to mean that I don't feel bis is ready; the confidence that I have that bis is very solid is extremely high. Indeed, the increase in length of the spec is almost entirely attributed to a very well specified, very complete protocol. Being initimately familiar with this document at a level of detail which is often frightening, I personally believe that WE ARE FINISHED. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 00:07:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00870 for ; Thu, 21 Feb 2002 00:07:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA15013 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 00:07:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12990; Wed, 20 Feb 2002 23:33:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12883 for ; Wed, 20 Feb 2002 23:33:34 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00285 for ; Wed, 20 Feb 2002 23:33:30 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L4Xo6Y011976; Wed, 20 Feb 2002 23:33:50 -0500 (EST) Message-ID: <3C74787C.FD447B57@dynamicsoft.com> Date: Wed, 20 Feb 2002 23:33:00 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] comments on srv draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan, Thanks for your comments. Responses inline. Rohan Mahy wrote: > > Hi, > > below are some comments on the SRV draft. apologies in advance for any > dups: > > thanks, > -rohan > > comments on SRV draft: > > page 5 3rd para: proposed rewrite: > > The procedures here are invoked when a client need to send a request to > a > server identified by a SIP URI (frequently the Request-URI); or when a > client wishes to send a request to a specifically configured outbound > proxy server, which is identified by a domain name instead of a numeric > IP > address. The procedures defined here, in no way affect any URI > processing > (i.e. the client will never rewrite the Request-URI or other SIP URIs > with > the result of the DNS lookups); they only provide a list of IP address, > port, and transport protocol tuples to which the request can be sent. This paragraph had to be rewritten already to reflect the loose route stuff and the SIPS URI. It now reads: The procedures here are invoked when a client needs to send a request to a resource identified by a SIP or SIPS (secure SIP) URI. This URI can identify the desired resource to which the request is targeted (in which case, the URI is found in the \header{Request-URI}, or it can identify an intermediate hop towards that resource (in which case, the URI is found in the \header{Route} header). The procedures defined here in no way affect this URI (i.e., the URI is not rewritten with the result of the DNS lookup), they only result in an IP address, port and transport protocol where the request can be sent. SIP \cite{draft-ietf-sip-rfc2543bis} provides guidelines on determining which URI needs to be resolved in DNS to determine the host that the request needs to be sent to. In some cases, also documented in \cite{draft-ietf-sip-rfc2543bis}, the request can be sent to a specific intermediate proxy not identified by a SIP URI, but rather, by a hostname or numeric IP address. In that case, a temporary URI, used for purposes of this specification, is constructed. That URI is of the form sip:, where is the domain or numeric IP address of the next-hop proxy. As a result, in all cases, the problem boils down to resolution of a SIP or SIPS URI in DNS to determine the IP address, port, and transport of the host to which the request is to be sent. > > page 6 after 2nd para: insert: > > If the no transport is specified, but the resulting UDP would exceed the > MTU-related size limitations described in Section 19.1.1 of [1], the > client MUST use TCP. Excellent catch. You are correct. This little exception needed some words both here and in the transport section of bis (it is already there in the pre-release). The text here now reads: Otherwise, if no transport protocol is specified, but the TARGET is a numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI. Similarly, if no target is specified, and the TARGET is not numeric, but an explicit port is provided, the client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI. This is because UDP is the only mandatory transport in RFC 2543 \cite{rfc2543}, and thus the only one guaranteed to be interoperable for a SIP URI. It was also specified as the default transport in RFC 2543 when no transport was present in the SIP URI. However, another transport, such as TCP, {\MAY} be used if the guidelines of SIP mandate it for this particular request. That is the case, for example, for requests that exceed the path MTU. It is better to point to bis for the proper guidelines on strengths for using TCP, than repeating them in sip-srv. > > page 8 4th para: proposed rewrite: > > The client SHOULD maintain a table indicating the status of a particular > host (that is, whether attempts to contact it resulted in success or > failure). The table is indexed with the IP address, port, and transport > for a particular host. If a request fails to a particular host, the > client updates the table to reflect that this host should not be > contacted > for some protocol-determined or policy-determined period of time. A > client SHOULD honor the time proposed in any Retry-After header in a 503 > response. A RECOMMENDED default period of time is one hour. Actually, this entire bit is gone. This reflects private comments received from two independent readers. Here are the reasons: 1. its an implementation choice. There is actually no need to specify this behavior at all. 2. It is really easy to get this wrong. Henning found all kinds of odd failure cases that arise. For example, if ad administrator updates a cluster by taking each element down, one at a time, over a period of an hour, a client might end up seeing the entire cluster as failed, even though no more than one element has been down at once! Generally, negative caching is hard if not done properly. Rather than try to work through all of the details, since it is an implementation choice, it has been removed. > > page 10 1st full para: should insert a brief reminder of the procedure > used before a failure. for example: > > Recall that when a server first attempts to send a response, it checks > ...... Text now reads: A server, according to RFC BBBB \cite{draft-ietf-sip-rfc2543bis}, will send a response on the connection it arrived on (in the case of reliable transport protocols), and for unreliable transport protocols, to the source address of the request, and port in the \header{Via} header field. The procedures here are invoked when a server attempts to send to that location and that response fails (the specific conditions are detailed in RFC BBBB). "Fails" is defined as any closure of the transport connection the request came in on before the response can be sent, or communication of a fatal error from the transport layer. > > page 11 1st para: remind the reader that low values are "better" than > high values. Done. > > NITS: > page 3 3rd para: s/Transport Protocol/The choice of transport protocol/ Fixed. > > page 4 2nd para: the following text is redundant duplication of the > previous sentence: > > "The request would fail, and that would be detected by proxy 1. > Proxy 1 would then try proxy 2.2" Already fixed. > > page 4 4th line from bottom: "a SIP response" -> "some SIP responses" > or > "responses to INVITE > requests" Changed to "some SIP responses". > top of page 5: SHALLNOT Fixed. > > page 5 para 6: s/domain/domain name/ FQDN is even better. > > page 6 para 5 ("The NAPTR records"): s/domain to/domain, to/ Fixed. > > page 7 near bottom: s/where, where/where/ This whole paragraph is gone, since the weird case is also gone (based on feedback from DNS folks). Basically, if you have an explicit port, you don't do NAPTR to figure out the transport, you use A records with the default transport. > > page 9 last para: s/RFC 2543bis/SIP/ Fixed. > > page 10 3rd para: s/tred/tried/ Fixed. Thanks for your comments, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 00:26:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01114 for ; Thu, 21 Feb 2002 00:26:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA15471 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 00:26:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13919; Wed, 20 Feb 2002 23:55:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13874 for ; Wed, 20 Feb 2002 23:55:49 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00678 for ; Wed, 20 Feb 2002 23:55:44 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L4u56Y011998; Wed, 20 Feb 2002 23:56:05 -0500 (EST) Message-ID: <3C747DB2.80674120@dynamicsoft.com> Date: Wed, 20 Feb 2002 23:55:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Boris Perlov CC: "'sip@ietf.org'" Subject: Re: [Sip] Question according to draft-ietf-sip-srv-04 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Boris, This is an excellent catch. In the many rewrites of this text, the fallback to A records was lost. You are correct, that if no SRV records are found, A/AAAA records are used. This will reflect in -05. Thanks, Jonathan R. Boris Perlov wrote: > > Hi all, > > in "draft-ietf-sip-srv-04" paragraph "4.2 Determining Port and IP" of > the > client DNS usage, it is specified that "...If the TARGET was not a > numeric > IP address, and no port was present in the URI the client performs an > SRV > query using the service identifier _sip and the transport protocol as > determined from section 4.1 ...". > > It is not clear what should be done if no SRV records are found. > > Previous version of the rfc2543 (bis 05), in case when no SRV records > are > found, requires to apply 'A'/'AAAA' class DNS query. > > Thanks, > Boris Perlov > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 01:08:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01530 for ; Thu, 21 Feb 2002 01:08:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA20958 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 01:08:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15549; Thu, 21 Feb 2002 00:29:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15516 for ; Thu, 21 Feb 2002 00:29:12 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01139 for ; Thu, 21 Feb 2002 00:29:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L5TP6Y012010; Thu, 21 Feb 2002 00:29:26 -0500 (EST) Message-ID: <3C748583.513C218F@dynamicsoft.com> Date: Thu, 21 Feb 2002 00:28:35 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Comments on SIP SRV Draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jo, Thanks for your comments. Responses inline. Jo Hornsby wrote: > > Hi. > > So a few things that I noticed. Apologies for > re-reports. I bet it's ever-so-slightly anoying. > > * Section 1; 2nd Paragraph: > First use of "DNS" on the second line. Dunno > if this merits a pointer to any of the DNS > RFCs or perhaps just the abbreviation broken > out. No, its not needed. > > * Section 2; 2nd Paragraph: > First use of: "TCP, UDP, TLS, SCTP" and "IP". > (Well, "IP" also occurs in the abstract, but.) > Again, I don't know whether it's really > necessary to spell these out (in particular, > a reader not knowing all of { "IP", "UDP", > "TCP" } I suspect is going to be the exception), > but just in case, they're here. Also not needed. Thats the opinion of our tech writer as well, when this issue has come up in bis. If you don't know what IP is, you shouldn't be reading this document ;) > > * Section 2; 2nd Paragraph; Sentence "All proxies > must implement both UDP and TCP [...]": > Is it worthwhile throwing "TLS" into the pot > here now? OK. > > * Section 2; 3rd Paragraph; Sentence "It is > important to note [...]": > s/processing/the processing/ ? Fixed. > > * Section 4; 1st Paragraph: > First use of "UAC". I'll bite on this one. The reason is that this document will be (and has been) read by people in other groups (HTTP, DIAMETER) who are working on usage of DNS for their protocols. SO, I cannot assume deep SIP knowledge, which is why there is so much tutorial material. > > * Section 4; 2nd Paragraph: > Well, Rohan's suggested new text, which I do > find easier to parse. However, being > First-Use Boy, I detect this unknown "URI". See my response to him, with the rewrite. I'll pass on the URI expansion. > > * Section 4; 3rd Paragraph; Sentence "That > is, once a server [...]": > s/responses/INVITE responses/ > [This may be being a little keen.] Fixed. > > * Section 4; 4th Paragraph; Sentence "Because > the ACK request for [...]": > s/responses/responses to INVITEs/ > [Again, this may be being a little keen.] > Fixed. > * Section 4; 4th Paragraph; Sentence "Because > the ACK request for [...]": > Perhaps s/most definitely/probably/ ? > "most definitely not" sounds like a wager to > me. &:) I think just "not get the ACK" is OK. > > * Section 4.1; 3rd Paragraph; Sentence "Otherwise, > if no transport protocol [...]": > Well, there may well be no bug here, or the > bug may be in a different Section; however, I > am wondering why there was particular need to > explicitly rule out using these procedures > when using an outbound proxy identified by > an IP as opposed to a domain name? > I possibly wrong, but I think that bis > exclusively defers to this document for rules > on how to determine the server to contact, > so I would perceive this to be a hole. Huh? I am lost. What "procedures" are ruled out by an outbound proxy? If your output proxy is an IP address, of course you won't look up anything in DNS. > > * Section 4.1; 4th Paragraph; Sentence "Otherwise, > if no transport protocol [...]": > s/target/TARGET/ Fixed. > > * Section 4.1; BINDish Zone File: > I'm guessing that the last entry should have > been "SIP+D2L"? > Also, is there any reason why this entry does > not look particular SRVish; i.e., has a > distinct lack of "_"s? I guess the whole > TLS-isn't-a-transport thing is problematic > here.... The example has changed due to SIPS. Basically, if you use TLS, you would look for "SIPS+D2T". Thus, the record above is gone. > > * Section 4.1; 7th Paragraph; Sentence "If the > client supports [...]": > Personally, I would find it helpful to do > something like: > s/UDP and TLS/UDP and TLS only/ > I might also note that this is a non-conforming > implementation. &;) This was fixed as part of the change in the example. > > * Section 4.1; Last Paragraph: > Is the implication here that once a client > has decided on a transport, then only results > from a query of that SRV record should be used, > and no other transports considered? Yes. We used to have the client lookup SRV records for all transports it supported, and merge the priority values across records. This turned out to be a big no-no for various administrative problems. If so, > especially if we're talking "MUST NOT", this > could probably be a little clearer. Changed to: \motivation{This is a change from RFC 2543. It specified that a client would lookup SRV records for all transports it supported, and merge the priority values across those records. Then, it would choose the most preferred record.} > > * Section 4.2; Paragraph 4 (Indented): > I am actually slightly confused, as a result > of this paragraph, on how these steps fit > together. I would have thought that in > some ways 4.1 was end-of-the-road; i.e., > because the NAPTR RFC specifies the "s" > flag, the use of SRV, and then thus A, I > guess, was sorta automatic. Otherwise, > may be 4.1 should specify that the result > of the NAPTR lookup is applied to TARGET? > In any case, thouls this paragraph be > s/SRV/NAPTR/ ? You are talking about this "weird case" paragraph? That weird case is gone now. If there is an explicit port, you do an A/AAAA, and you are done. > > * Section 4.3; Paragraph 2: > Rohan's text is good here, I think. See my response to him; its nuked. > > * Section 4.3; Paragraph 3: > Doesn't it always come down to A/AAAA in > the end? [I might be exposing a blatant > misunderstanding of SRV, here.] No, you are correct. However, this paragraph is not relevant any longer. This whole section is much thinnger now. All it really does is define "failure" as used in rfc2782. > > * Section 4.3: > In general, don't these rules apply to > multiple records of any type? > In particular, I'm thinking multiple-A > records. The Section title would seem > to preclude this? Great point. With the new text thats there, the section title should say the same. What needs to change is that the references from above that start with a list of A/AAAA records, should simply say "try one, and if it fails, based on the definition of failur ein Section XXX, try another". > > * Section 4.4: Paragraph 1: Sentence 2: > I would suggest: "When a server is > contacted successfully, all retransmissions > for the transaction, as well as ACK/CANCEL > requests for that transaction, MUST go > to the same server." Reworded to: The process of the previous sections is highly stateful. When a server is contacted successfully, all retransmissions of the request for the transaction, as well as {\ACK} for a non-2xx final response, and {\CANCEL} requests for that transaction, {\MUST} go to the same server. > > * Section 5; Paragraph 4: Sentence 1: > s,A,A/AAAA, ? Good catch. Thats an IESG hot-button.... > > * Section 5; Last Paragraph: > Ah, I guess this relates to my earlier > comment. Since we do "SIP/2.0/TLS" (or > did I imagine this), then does this > imply _sip._tls.this-domain-is-so.invalid > ? Well, its _sips._tcp, but why would it be .invalid? > I'm trying to work out if this conflicts > with 2782, but since it says (under the > bit talking about the "Proto" component > of the SRV RR): "though any name defined > by Assigned Numbers or _locally_ may be > used", I guess it's okay (though "locally" > doesn't seem to be so well defined). > And I suppose a name collision should be > v. unlikely [thanks to Mr. Oberg?].... You've totally lost me. If the Via is: SIP/2.0/TLS proxyfarm.example.com you'd look up: _sips._tcp.proxyfarm.example.com. > > * Section 6: > I feel that this section is too fond of > "maddr", since we now know better. It's > potential role as "TARGET" is already > explicit. I doubt there is a need to > dwell here. GOod point. maddr examples removed. Thanks for your comments, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 02:02:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04849 for ; Thu, 21 Feb 2002 02:02:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA29013 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 02:02:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27702; Thu, 21 Feb 2002 01:31:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27646 for ; Thu, 21 Feb 2002 01:31:49 -0500 (EST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01726 for ; Thu, 21 Feb 2002 01:31:48 -0500 (EST) Received: from axsppc65 (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with SMTP id g1L6VIs29943 for ; Thu, 21 Feb 2002 00:31:18 -0600 (CST) Message-ID: <003501c1baa2$3c1e1fc0$7301ff0a@axsppc65> From: "Jagannathan R" To: Date: Thu, 21 Feb 2002 12:07:27 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01C1BAD0.54418AF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [Sip] SIP - PSTN Interconnection Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0032_01C1BAD0.54418AF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a some basic doubts regarding the SIP-PSTN Interworking. Can any = one clarify these doubts please. 1. Proxy server is connected to MGC (point of SIP-PSTN Interconnection), = is there a way proxy server registering itself with MGC. This is = required at MGC to know what are the SIP phone numbers this proxy can = service, so that the PSTN originated call can be correctly terminated to = the Proxy.=20 1b. And also the MGC should know the status of Proxy (In-Service or = Out-of-Service) to terminate the call. 1c. How many Proxy servers with different/same set of SIP phone numbers = can be linked to MGC. 2. When SIP call arrives at MGC, MGC requires NOA (Nature of Address) in = order to translate the called number and route the call to the correct = PSTN Trunk Group. How the NOA address (more specifically + 0, - 0, = 0+IDDD, IDDD, DDD calls) can be represented in the SIP messages. 3. For SIP-PSTN call, how different digit sequences like ANI, = Authorization code, Account code (these are required for billing at MGC = and to have Dialing plan) can be send to MGC in SIP Messages.=20 Thanks in advance, jagannathan ------=_NextPart_000_0032_01C1BAD0.54418AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have a some basic doubts regarding = the SIP-PSTN=20 Interworking. Can any one clarify these doubts please.
 
1. Proxy server is connected to MGC = (point of=20 SIP-PSTN Interconnection), is there a way proxy server registering = itself with=20 MGC. This is required at MGC to = know what=20 are the SIP phone numbers this proxy can service, so that the PSTN = originated=20 call can be correctly terminated to the Proxy.
1b. And also the MGC should know = the status of=20 Proxy (In-Service or Out-of-Service) to terminate the call.
1c. How many Proxy servers with = different/same set=20 of SIP phone numbers can be linked to MGC.
 
2. When SIP call arrives at MGC, MGC = requires NOA=20 (Nature of Address) in order to translate the called number and route = the call=20 to the correct PSTN Trunk Group. How the NOA address (more specifically = + 0, -=20 0, 0+IDDD, IDDD, DDD calls) can be represented in the SIP = messages.
 
3. For SIP-PSTN call, how different = digit sequences=20 like ANI, Authorization code, Account code (these are required for = billing at=20 MGC and to have Dialing plan) can be send to MGC in SIP Messages. =
 
 
Thanks in advance,
 
jagannathan
 
------=_NextPart_000_0032_01C1BAD0.54418AF0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 21 03:17:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10713 for ; Thu, 21 Feb 2002 03:17:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA02490 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 03:17:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00956; Thu, 21 Feb 2002 02:47:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00929 for ; Thu, 21 Feb 2002 02:47:39 -0500 (EST) Received: from blaze.hcltech.com ([61.11.73.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10336 for ; Thu, 21 Feb 2002 02:47:32 -0500 (EST) Received: from Badri (badri.hclt-guindy.co.in [192.168.201.82]) by blaze.hcltech.com (8.9.3/8.9.3) with SMTP id MAA28967 for ; Thu, 21 Feb 2002 12:53:52 +0530 From: "Badri Srinivasan S" To: Date: Thu, 21 Feb 2002 12:24:41 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] Different From tags in INVITEs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: section 19.3 , line 3988 of bis 07.9 says, "Two INVITE's for different calls will have different From tags".. I am not able to understand this necessity as the Call-Id will any way be different and the combination of CallId+From tag + To tag will be unique for that dialog. sorry if i had misunderstood. please clarify. Thanks, Badri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 21 03:18:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10731 for ; Thu, 21 Feb 2002 03:18:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA02507 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 03:18:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00685; Thu, 21 Feb 2002 02:44:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00660 for ; Thu, 21 Feb 2002 02:44:13 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10289 for ; Thu, 21 Feb 2002 02:44:12 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L7iX6Y012346 for ; Thu, 21 Feb 2002 02:44:33 -0500 (EST) Message-ID: <3C74A530.B9BF0A04@dynamicsoft.com> Date: Thu, 21 Feb 2002 02:43:44 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] sip-srv update submitted Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I've just submitted draft-ietf-sip-srv-05.txt. Until it appears, you can grab it at: http://www.jdrosen.net/papers/draft-ietf-sip-srv-05.txt This represents the version that will go to IESG last call. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 03:48:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11061 for ; Thu, 21 Feb 2002 03:48:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA04307 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 03:48:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02887; Thu, 21 Feb 2002 03:27:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02856 for ; Thu, 21 Feb 2002 03:27:31 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10817 for ; Thu, 21 Feb 2002 03:27:29 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L8Rp6Y012363 for ; Thu, 21 Feb 2002 03:27:51 -0500 (EST) Message-ID: <3C74AF57.A4C29108@dynamicsoft.com> Date: Thu, 21 Feb 2002 03:27:03 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] updated I-D: draft-ietf-sip-100rel-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I've just submitted draft-ietf-sip-100rel-05.txt to the archives. Until it appears, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-sip-100rel-05.txt This document is the result of comments received during WGLC and will be sent to IESG for consideration as proposed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 04:00:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11260 for ; Thu, 21 Feb 2002 04:00:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA04882 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 04:00:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03669; Thu, 21 Feb 2002 03:38:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03642 for ; Thu, 21 Feb 2002 03:38:50 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10980 for ; Thu, 21 Feb 2002 03:38:48 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L8d76Y012369; Thu, 21 Feb 2002 03:39:08 -0500 (EST) Message-ID: <3C74B1F9.B0BB7B93@dynamicsoft.com> Date: Thu, 21 Feb 2002 03:38:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Unify & offers in responses (Question on bis-07) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson wrote: > > Jonathan, > > If I understand rightly, the Unify proposal rules out SDP offers in > responses to the INVITE, except the first offer (in the case of no offer > in the INVITE). Correct. > > This is on the basis that after the initial offer/answer exchange, we > would need to be able to reject such offers to deal with 'offer glare', > and we have no means of rejecting an offer in a response, right ? (NB: > it is just the SDP offer that we would need to reject, not the whole > response) Yes; there are also ordering problems, since you can't order responses with requests in the same direction. > > Is it possible that future extensions might plug this hole, and allow > 'subsequent offers' in responses ? Or, are we requiring now that any > such subsequent offers from the UAS use UPDATE ? Extensions can relax constraints if there are ways to do so in a backwards compatible manner. I believe that would be possible here, but I don't think its needed. > > I am wondering whether there are requirements for a new SDP offer to be > semantically linked with a response to the INVITE, and in particular the > 200 OK. e.g. your Early Media is 'sendonly' and the UAS wants to change > the stream to 'sendrecv' on Answer. Is it OK to have separate operations > for the change in dialog state and the change in media state ? or might > these need to be linked in a single operation ? Separate is just fine! One of the big ideas of the unify draft was to separate the evolution of dialog state from session state. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 04:01:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11295 for ; Thu, 21 Feb 2002 04:01:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA05306 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 04:01:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03875; Thu, 21 Feb 2002 03:41:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03795 for ; Thu, 21 Feb 2002 03:40:56 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10999 for ; Thu, 21 Feb 2002 03:40:50 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g1L8epd02441; Thu, 21 Feb 2002 09:40:51 +0100 (MET) Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g1L8eop08661; Thu, 21 Feb 2002 09:40:51 +0100 (MET) Received: from mhpaba5c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail-k.mchp.siemens.de with ESMTP id g1L8eomQ020768; Thu, 21 Feb 2002 09:40:50 +0100 (MET) From: "Steffen Fries" Organization: Siemens AG To: jundery@ubiquity.net Date: Thu, 21 Feb 2002 09:43:12 +0100 MIME-Version: 1.0 Subject: [Sip] Questions to draft-undery-sip-auth-00.txt Reply-to: steffen.fries@mchp.siemens.de CC: sip@ietf.org Message-ID: <3C74C130.24511.502AE44@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT James, I just went through the extensions to HTTP Digest Authentication. I've got some questions to draft-undery-sip- auth-00.txt: 1. How does the nextnonce mechanism deal with packet loss? It might be that a response to a UA gets lost when using UDP. When the UA sends the next request, which nonce will be used here? The nextnonce sent in the last respone the UA received? How is a proxy supposed to react in this case? 2. Does this scheme require a call stateful proxy storing nonces and nextnonces for a certain time? Regards Steffen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 21 04:15:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11521 for ; Thu, 21 Feb 2002 04:15:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA06141 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 04:15:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04360; Thu, 21 Feb 2002 03:48:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04333 for ; Thu, 21 Feb 2002 03:48:50 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11077 for ; Thu, 21 Feb 2002 03:48:48 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L8fR6Y012372; Thu, 21 Feb 2002 03:41:27 -0500 (EST) Message-ID: <3C74B285.DE19B5C7@dynamicsoft.com> Date: Thu, 21 Feb 2002 03:40:37 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Badri Srinivasan S CC: sip@ietf.org Subject: Re: [Sip] Different From tags in INVITEs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I answered this quesiton on the list just a few days ago. Please check the archives. -Jonathan R. Badri Srinivasan S wrote: > > Hi: > > section 19.3 , line 3988 of bis 07.9 says, "Two INVITE's for different > calls > will have different From tags".. > I am not able to understand this necessity as the Call-Id will any way > be > different and the combination of CallId+From tag + To tag will be unique > for > that dialog. > sorry if i had misunderstood. please clarify. > > Thanks, > Badri > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 04:40:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12004 for ; Thu, 21 Feb 2002 04:40:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA08317 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 04:40:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05970; Thu, 21 Feb 2002 04:13:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05945 for ; Thu, 21 Feb 2002 04:13:06 -0500 (EST) Received: from blaze.hcltech.com ([61.11.73.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11497 for ; Thu, 21 Feb 2002 04:12:59 -0500 (EST) Received: from Badri (badri.hclt-guindy.co.in [192.168.201.82]) by blaze.hcltech.com (8.9.3/8.9.3) with SMTP id PAA00879 for ; Thu, 21 Feb 2002 15:04:22 +0530 From: "Badri Srinivasan S" To: Date: Thu, 21 Feb 2002 14:35:10 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit Subject: [Sip] FW: Questions on To tags (was Re: [Sipping] Comments on draft-ietf-sip-rfcbis-05.pdf) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi: This is was the latest reply given for the query on "Different From tags for 2 different calls (INVITE's)". But the "Call-Id + From tag + To tag always remaining unique for a dialog" makes it unnecessary for the From tag for 2 different INVITE's to be different.Even the To tag in the case of 2 different calls (INVITE's) can be the same as the combination of Call-id + From tag + To tag will disambiguate the dialogs. I understand that the To tag need not be different for the two different INVITE's the same UAS responds. When such is the case, why the reason of Symmetry is cited for making the From tag different for 2 diff INVITE's ?. Thanks, Badri -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Peter P�ppinghaus Sent: Tuesday, February 19, 2002 1:56 PM To: Jonathan Rosenberg Cc: Sipping@ietf.org Subject: Re: Questions on To tags (was Re: [Sipping] Comments on draft-ietf-sip-rfcbis-05.pdf) I realize the incredible workload you are taking, and I really don't want to abuse your precious time. But could you help me to understand why I am mistaken in my inline comment below? Sorry for this. Peter P. Jonathan Rosenberg wrote: > > Peter P�ppinghaus wrote: > > In bis-07, section 23.3, lines 4896-4897, now in fact say: > > "Similarly, two INVITEs for different calls will have different From > > tags." > > > > This really surprises me for two reasons. > > > > Firstly, if the From tag has to be unique across all calls, then it > > uniquely identifies a call, so what would the Call-ID be needed for? > > If we were able to start SIP from scratch, I would probably agree that > the Call-ID and from tag are redundant. But, we can't. So, the real > question is this - given we have a unique call-id, and that people have > been putting them in that way, and relying on their uniqueness, is there > also a need for the from tag/to tag to be unique? > > There, there answer is in fact yes, but for subtle reasons. Certainly, > the to tag in a response needs to be unique. What you really, really > need is for both participants in the dialog to contribute unique > identifiers, such that the combination of the two are the dialog ID. According to my understanding, what you really, really need is for both participants in the dialog to contribute unique identifiers, such that the combination of the two *together with the Call-ID* are the dialog ID. And if all of the following hold: 1) the From tag uniquely identifies a UAC (unique in space and role as a request-issuing entity), 2) the To tag uniquely identifies a UAS (unique in space and role as a response-issuing entity), 3) the Call-ID used for the request is unique "over time", i.e. as a minimal requirement: the same UAC ("same" as identified by the From tag) never issues another dialog-initiating request with the same Call-ID value, then the dialog ID consisting of Call-ID, From tag, and To tag, will uniquely identify a dialog, won't it? > So, the to tag has to be unique, OK. Now, in requests in the reverse > direction that the dialog was established, the To and From field values > are reversed. This means that what was in the From in the initial > request, is now in the To, and vice a versa. This means that elements > which might like to take advantage of the fact that the to tag is > unique, really cannot, since it wouldn't be in the reverse direction > unless the from tag in the original request was also unique. And thus > the requirement for unique from tags as well. > > So, simply put, the from tag is unique to provide symmetry wiht the to > tag, which must be unique. > > -Jonathan R. -- Dr. Peter P�ppinghaus Siemens AG | Phone: +49 89 - 722 40065 ICM N PG U ID A1 | Fax: +49 89 - 722 58726 Hofmannstr. 51 | Visitors: Building 1702 / Room 530 D - 81359 M�nchen | Email: peter.paeppinghaus@icn.siemens.de _______________________________________________ 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 21 04:44:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12059 for ; Thu, 21 Feb 2002 04:44:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA08467 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 04:44:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06418; Thu, 21 Feb 2002 04:17:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06375 for ; Thu, 21 Feb 2002 04:17:52 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11598 for ; Thu, 21 Feb 2002 04:17:49 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L9Hg6Y012390; Thu, 21 Feb 2002 04:17:42 -0500 (EST) Message-ID: <3C74BB04.D49AA2B4@dynamicsoft.com> Date: Thu, 21 Feb 2002 04:16:52 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox CC: sip@ietf.org Subject: Re: [Sip] Remaining uses of <"> in bis-07.9 BNF References: <15474.34014.724733.320958@grandcentral.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit THanks, fixed. -Jonathan R. Jonathan Lennox wrote: > > A minor nit: bis-07.9 still uses the prose value <"> to represent a > double-quote its BNF in a few places, even though it was supposed to > switch > to DQUOTE. > > This appears in the BNF definitions of 'word', 'separators', and > 'quoted-string' (twice). > > -- > Jonathan Lennox > lennox@cs.columbia.edu > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 04:45:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12082 for ; Thu, 21 Feb 2002 04:45:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA08498 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 04:45:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06804; Thu, 21 Feb 2002 04:24:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06709 for ; Thu, 21 Feb 2002 04:24:35 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11712 for ; Thu, 21 Feb 2002 04:24:31 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 21 Feb 2002 09:24:49 UT content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Questions to draft-undery-sip-auth-00.txt Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Thu, 21 Feb 2002 09:26:49 -0000 Message-ID: <45730E094814E44488F789C1CDED27AEC552B0@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Questions to draft-undery-sip-auth-00.txt Thread-Index: AcG6s84xwU7bvL2gTw6D6kosVfmb0AAAuOpQ From: "James Undery" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA06710 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Steffen Fries [mailto:steffen.fries@mchp.siemens.de] > 1. How does the nextnonce mechanism deal with packet loss? It > might be that a response to a UA gets lost when using UDP. > When the UA sends the next request, which nonce will be used > here? The nextnonce sent in the last respone the UA > received? How is a proxy supposed to react in this case? The nextnonce mechanism deals with packet loss by being carried in SIP. The standard SIP retransmission mechanism cover this. The UA MAY cache nonces however it likes although SHOULD follow the guidelines in the bis. If a UA is within a dialog I'd hope it used the freshest nonce it had, i.e. nextnonce if that was provided. How the proxy deals with nonces is really a matter of local policy. I.e. On receiving and challanging a REGISTER the registrar may wish to store the nextnonce allowing one time long duration nonces. A generic proxy may want stateless behaviour where nonces are generated with a secret only it knows and time limited or tied to a dialog. > 2. Does this scheme require a call stateful proxy storing > nonces and nextnonces for a certain time? Definately not, the possible implementation in section 6.1 demonstrates a nonce that need not be stored and can be verfied as fresh. The format even allows preliminary checking of the freshness without preforming a hash. 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 daemon@optimus.ietf.org Thu Feb 21 04:48:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12161 for ; Thu, 21 Feb 2002 04:48:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA08848 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 04:48:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06910; Thu, 21 Feb 2002 04:25:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06869 for ; Thu, 21 Feb 2002 04:25:53 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11734 for ; Thu, 21 Feb 2002 04:25:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L9Pe6Y012393; Thu, 21 Feb 2002 04:25:40 -0500 (EST) Message-ID: <3C74BCE2.8D714539@dynamicsoft.com> Date: Thu, 21 Feb 2002 04:24:50 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox CC: sip@ietf.org Subject: Re: [Sip] Another bis-07.9 BNF nit References: <15474.37455.623505.609513@grandcentral.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > > The Bis 07.9 BNF doesn't allow for extension parameters to > Accept-Language > and Accept-Encoding. I assume this is accidental? As far as I can tell, yes. I think all should have the same parameter grammar. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 04:55:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12275 for ; Thu, 21 Feb 2002 04:55:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09347 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 04:55:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07833; Thu, 21 Feb 2002 04:35:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07804 for ; Thu, 21 Feb 2002 04:35:09 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11916 for ; Thu, 21 Feb 2002 04:35:05 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L9Yw6Y012397; Thu, 21 Feb 2002 04:34:58 -0500 (EST) Message-ID: <3C74BF11.BCB1372@dynamicsoft.com> Date: Thu, 21 Feb 2002 04:34:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox CC: sip@ietf.org Subject: Re: [Sip] Two more bis-07.9 BNF nits References: <15474.52078.657069.18537@grandcentral.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > > Two more bis-07.9 BNF nits; I think this is the last of them. > > 1. The BNF for Accept requires that the 'q' parameter appear before any > other parameter. Even though RFC 2616 does this, it's inconsistent > with > the way things work anywhere else in SIP, and so should probably be > fixed. > > Suggested BNF: > > Accept = "Accept" HCOLON > ( accept-range *(COMMA accept-range) ) > accept-range = media-range *( SEMI accept-param) > accept-param = ( "q" EQUAL qvalue ) / generic-param > > qvalue and generic-param should also probably move up to be defined > near > their first reference. > > The same syntax forms can be used for the generic parameters for > Accept-Encoding and Accept-Language, which I mentioned in my earlier > mail. Agreed. All fixed. > > 2. User-Agent and Server seem to have been overlooked in the > explicit-whitespace conversion -- there's nothing specifying LWS > between > consecutive 'product' values. > > One possible BNF representation would be > > Server = "Server" HCOLON *( product LWS / comment ) > ( product / comment ) > > (and similarly for User-Agent) > > but this isn't quite right, I don't think; you need LWS between > consecutive product tokens, but you don't need them between product > and > comment or vice-versa, as comment's inherent SWS is sufficient. I'm > not > sure how exactly to specify this. I think its reasonable here to say that there needs to be a mandatory LWS between the product and comment, even if its not strictly necessary. This would mean Server = "Server" HCOLON server-value *(LWS server-value) server-value = product / comment Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 04:57:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12307 for ; Thu, 21 Feb 2002 04:57:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09449 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 04:57:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07890; Thu, 21 Feb 2002 04:35:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07857 for ; Thu, 21 Feb 2002 04:35:28 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11920 for ; Thu, 21 Feb 2002 04:35:25 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1L9Xg218944; Thu, 21 Feb 2002 04:34:06 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Feb 2002 03:33:21 -0600 Message-ID: <70565611B164D511957A001083FCDD56018700E3@VA02> From: "Peterson, Jon" To: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] more SMIME comments Date: Thu, 21 Feb 2002 03:33:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for these last-minute nits, Mike. The appropriate changes will be applied. Some notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, February 20, 2002 9:26 AM > To: sip@ietf.org > Subject: [Sip] more SMIME comments > > > > 1) You cannot put RFC 822 addresses into X.509 > distinguished names (DN's). You either need to > have a mapping function, or place requirements > in subject-alt-name, etc. Yeah, we talk pretty casually about having the 'subject' of the certificate be an identity. I think EKR spoke to this already in another mail; I believe 2633 characterizes this. Maybe we should at least once in the spec not speak casually about this. > > 2) The general requirements for a "keyring" for > non-disk based UA's is, essentially, > impossible. Unlike what Henning said yesterday, > use for encryption requires that both the > distinguished name and the entire public key > (not a hash!) need to be stored. Considering > that phones typically receive calls from > anywhere, the storage needs are unbound. I'm > willing to believe that this isn't an issue for > a multi-gigabyte disk. For flash based UA's, > however, this is an unreasonable requirement. Agreed that it won't be reasonable for all user agents. For the same reason, managing a large set of root certificates in a tiny UA is infeasible. We need to strike a balance somewhere in the middle. Maybe smallish handsets will only have room for a few certificates (like, 10 seats worth). Maybe some handsets won't be able to use it at all. I long for the day when an iPaq-strength handheld wireless device gets provider subsidies like cell-phones do. I'm not sure if we really need to add anything to the text to capture your thinking here, though. > > 3) There is no suggestions about what UA's should > do about root CA's. Why should a particular UA > install a root cert? This is a good question, and represents something that it is difficult to address in the text. We obviously can't call out to CAs by name and say you MUST or SHOULD buy their products. I asked around and got a general sense that you could say "well-known" certificate authorities comparable to those that supply root certificates for web browsers should be used for TLS/IPSec. I'm not really sure how to get any better leverage on this. Then I suggested that these be reused for S/MIME. Getting root CAs specifically for S/MIME is a MAY now. > > 4) in section 22.1 says that you verify with a > certificate authority. This is misleading as it > implies something you actively do with the CA. > > 5) 22.1: you can verify self-signed certificates > just fine. You just don't know whether you > trust the namespace. > > 6) 22.1: you don't verify certificates. You verify > signatures. I appreciate your cracking down on casual language. We'll hit these points. > > 7) A change in certificates stored is not > necessarily an error. I don't think the > normative text here is helpful because this > is probably a revocation issue. As in, the > UA complains to the user, and the user is > supposed to do what, exactly? This seems > loaded with the ability for abuse. The user could reject the request. Hang up and call back, maybe. It is a good point that we should probably recommend some behavior to users here. I agree that a change in certificates is not necessarily a security breach, but I think it is certainly a cause for alarm if it is unexpected. Revocation for self-signed certificates is clearly a pretty ad-hoc matter; we do recommend that users keep certs for a long time, but there isn't much you can do if some new Outlook virus posts your private key to rec.humor.funny. You have to make a new key and re-establish trust with any users who had your old key. > > More later. > > 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 daemon@optimus.ietf.org Thu Feb 21 04:59:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12335 for ; Thu, 21 Feb 2002 04:59:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09525 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 04:59:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08162; Thu, 21 Feb 2002 04:39:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08125 for ; Thu, 21 Feb 2002 04:39:06 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11967 for ; Thu, 21 Feb 2002 04:39:03 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L9cP6Y012400; Thu, 21 Feb 2002 04:38:26 -0500 (EST) Message-ID: <3C74BFE1.6642AC6D@dynamicsoft.com> Date: Thu, 21 Feb 2002 04:37:37 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox CC: Dror@vocaltec.com, sip@ietf.org Subject: Re: [Sip] Some more ABNF issues - bis07 References: <15474.47592.173996.28663@grandcentral.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > > On Monday, February 18 2002, "Jonathan Rosenberg" wrote to > "Dror@vocaltec.com, sip@ietf.org" saying: > > > > > > > Dror@vocaltec.com wrote: > > > > > > 1. TEXT-UTF8-TRIM - while the text claims it does not allow leading > WS, > > > it > > > actually does. should be redefined as: > > > TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) > > > (added "1" before "*") > > > > Good point. Fixed. > > Unfortunately, as a side effect, this forbids TEXT-UTF8-TRIM from > matching > the empty string. Not intended, I assume. I was debating it, but rfc2543 does allow an empty string in Subject and Organization, so that is the intent. > > You need either to stick the whole thing in brackets, or add an explicit > > / ; empty > afterwards. I took a slightly different approach, which was to put brackets around TEXT-UTF8-TRIM in the two headers which use it. THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 05:39:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12845 for ; Thu, 21 Feb 2002 05:39:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12037 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 05:40:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09970; Thu, 21 Feb 2002 05:00:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09923 for ; Thu, 21 Feb 2002 05:00:40 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12375 for ; Thu, 21 Feb 2002 05:00:37 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1L9wv219294; Thu, 21 Feb 2002 04:59:22 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Feb 2002 03:58:36 -0600 Message-ID: <70565611B164D511957A001083FCDD56018700E4@VA02> From: "Peterson, Jon" To: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] SMIME and active MITM attacks Date: Thu, 21 Feb 2002 03:58:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for your last-minute comments, Mike. Some good points here. To your whole 'S/MIME self-signed cert key exchange in SIP is hopeless' point, as we've discussed here many times before, we believe it's better than nothing. Your message is getting through, but I still think we need this S/MIME mechanism. I also speak to one point below that I don't think we've discussed here before. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, February 20, 2002 8:35 AM > To: sip@ietf.org > Subject: [Sip] SMIME and active MITM attacks > > [snip] > > The third thing I notice is that the reverse path > seems to be completely broken. In it, the text in > 22.1 says that although the message may signed > against some certificate, the UAC cannot expect > that the TO: address and the cert identity will > will be the same. So, what security property is > being enforced then? What prevents a hostile proxy > from changing the contact address? How does the > UAC know that it actually contacted who they > expected? The answer seems to be "nothing" and "it > can't". > This is a general fact about SIP - that you can send a request To: Alice and it can be legitimately retargeted To: Bob, and since the UAS doesn't generate the identity in the To header of responses, you'll get a response from Bob with a To: Alice header. Just like, say, call forwarding in the PSTN. The caller has no idea whether Alice set up the call-forwarding herself or if Bob broke into her PBX and hacked it in. In SIP, of course, the caller can cryptographically authenticate the proxy server that manages Alice's contacts (to make sure it really is Alice's proxy), and fortunately thanks to S/MIME the caller can inspect a signature supplied by Bob as well. Of course, bis does suggest in 22.1 that the UAC should notify the user when this sort of retargeting happens (when the response comes from an unexpected user), and that the client's user has to decide whether they trust and/or want to talk to Bob. Maybe they have seen Bob's identity and credentials before and they have some reason to trust Bob. Or maybe they feel like talking to a total stranger. I think all we can do is report the break in reference integrity to the client's user and allow them to treat it as they like. Consider this: What if rather than proxying the request to Bob directly, Alice's proxy server instead propagates a 302 back to the client, redirecting to Bob's AoR? How has this changed the security implications of this scenario? You would then be sending out a Request-URI to Bob's AoR, and Bob could answer with reference integrity. Ultimately this just means that you have to trust the proxy server that manages Alice's contacts to apply them reliably. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 21 05:46:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12891 for ; Thu, 21 Feb 2002 05:46:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12190 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 05:46:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10753; Thu, 21 Feb 2002 05:14:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10722 for ; Thu, 21 Feb 2002 05:14:17 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12580 for ; Thu, 21 Feb 2002 05:14:13 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id g1LADjU01371 for ; Thu, 21 Feb 2002 11:13:45 +0100 Received: from vies194a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.1/8.12.1) with ESMTP id g1LADgkw018804 for ; Thu, 21 Feb 2002 11:13:44 +0100 (MET) Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Feb 2002 11:13:41 +0100 Message-ID: From: Brazier Lachlan To: "'sip@ietf.org'" Date: Thu, 21 Feb 2002 11:13:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BAC0.6E8B61C0" Subject: [Sip] Small bits on sip-srv Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BAC0.6E8B61C0 Content-Type: text/plain; charset="iso-8859-1" Hello, some bits I've seen while reading the draft draft-ietf-sip-srv-05.txt 4.1 Third paragraph: Similarly, if no TARGET is specified, and the TARGET is not numeric,... No TARGET, and it's even not numeric. Am I missing something? 4.1 - page 9 - second paragraph: The reason s It is not necessary .... 4.2: third paragraph: The client SHOULD try the one of the records. Which one? The first, isn't it? Bye Lachlan ------_=_NextPart_001_01C1BAC0.6E8B61C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+U21hbGwg Yml0cyBvbiBzaXAtc3J2PC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpF PTIgRkFDRT0iQXJpYWwiPkhlbGxvLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZB Q0U9IkFyaWFsIj5zb21lIGJpdHMgSSd2ZSBzZWVuIHdoaWxlIHJlYWRpbmcgdGhlIGRyYWZ0PC9G T05UPiA8Rk9OVCBGQUNFPSJBcmlhbCI+ZHJhZnQtaWV0Zi1zaXAtc3J2LTA1LnR4dDwvRk9OVD4N CjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj40LjEgVGhpcmQgcGFyYWdyYXBo OiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5TaW1pbGFybHks IGlmIG5vIFRBUkdFVCBpcyBzcGVjaWZpZWQsIGFuZCB0aGUgVEFSR0VUIGlzPC9GT05UPjxGT05U IEZBQ0U9IkNvdXJpZXIgTmV3Ij4gbm90IG51bWVyaWMsLi4uPC9GT05UPg0KPC9QPg0KDQo8UD48 Rk9OVCBGQUNFPSJBcmlhbCI+Tm8gVEFSR0VULCBhbmQgaXQncyBldmVuIG5vdCBudW1lcmljLiBB bSBJIG1pc3Npbmcgc29tZXRoaW5nPzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgRkFDRT0iQXJp YWwiPjQuMSAtIHBhZ2UgOSAtIHNlY29uZCBwYXJhZ3JhcGg6PC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+VGhlIHJlYXNvbiBzIEl0IGlzIG5vdCBuZWNlc3Nhcnkg Li4uLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj40LjI6IHRo aXJkIHBhcmFncmFwaDo8L0ZPTlQ+DQo8QlI+PEZPTlQgRkFDRT0iQ291cmllciBOZXciPlRoZSBj bGllbnQgU0hPVUxEIHRyeSB0aGUgb25lIG9mIHRoZSByZWNvcmRzLjwvRk9OVD4NCjwvUD4NCg0K PFA+PEZPTlQgRkFDRT0iQXJpYWwiPldoaWNoIG9uZT8gVGhlIGZpcnN0LCBpc24ndCBpdD88L0ZP TlQ+DQo8L1A+DQoNCjxQPjxGT05UIEZBQ0U9IkFyaWFsIj5CeWU8L0ZPTlQ+DQo8QlI+PEZPTlQg RkFDRT0iQXJpYWwiPkxhY2hsYW48L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjwvQk9EWT4NCjwvSFRN TD4= ------_=_NextPart_001_01C1BAC0.6E8B61C0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 21 06:19:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13241 for ; Thu, 21 Feb 2002 06:19:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13421 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 06:19:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12456; Thu, 21 Feb 2002 05:56:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12425 for ; Thu, 21 Feb 2002 05:55:58 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13001 for ; Thu, 21 Feb 2002 05:55:54 -0500 (EST) Received: (qmail 8046 invoked from network); 21 Feb 2002 10:59:02 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 21 Feb 2002 10:59:02 -0000 Received: from stake.com (unknown [10.50.1.35]) by cam-relay.atstake.com (Postfix) with SMTP id 7701222817; Thu, 21 Feb 2002 05:54:44 -0500 (EST) Message-ID: <3C74D1F1.3070306@stake.com> Date: Thu, 21 Feb 2002 10:54:41 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Peterson, Jon" Cc: "'Michael Thomas'" , sip@ietf.org Subject: Re: [Sip] SMIME and active MITM attacks References: <70565611B164D511957A001083FCDD56018700E4@VA02> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jon, Using a self signed cert will give us nothing... Proving Identity is what we are looking for... Ofir Peterson, Jon wrote: > Thanks for your last-minute comments, Mike. Some good points here. To your > whole 'S/MIME self-signed cert key exchange in SIP is hopeless' point, as > we've discussed here many times before, we believe it's better than nothing. > Your message is getting through, but I still think we need this S/MIME > mechanism. > > I also speak to one point below that I don't think we've discussed here > before. > > Jon Peterson > NeuStar, Inc. > > >>-----Original Message----- >>From: Michael Thomas [mailto:mat@cisco.com] >>Sent: Wednesday, February 20, 2002 8:35 AM >>To: sip@ietf.org >>Subject: [Sip] SMIME and active MITM attacks >> >> >> > [snip] > >>The third thing I notice is that the reverse path >>seems to be completely broken. In it, the text in >>22.1 says that although the message may signed >>against some certificate, the UAC cannot expect >>that the TO: address and the cert identity will >>will be the same. So, what security property is >>being enforced then? What prevents a hostile proxy >>from changing the contact address? How does the >>UAC know that it actually contacted who they >>expected? The answer seems to be "nothing" and "it >>can't". >> >> > > This is a general fact about SIP - that you can send a request To: Alice and > it can be legitimately retargeted To: Bob, and since the UAS doesn't > generate the identity in the To header of responses, you'll get a response > from Bob with a To: Alice header. Just like, say, call forwarding in the > PSTN. The caller has no idea whether Alice set up the call-forwarding > herself or if Bob broke into her PBX and hacked it in. In SIP, of course, > the caller can cryptographically authenticate the proxy server that manages > Alice's contacts (to make sure it really is Alice's proxy), and fortunately > thanks to S/MIME the caller can inspect a signature supplied by Bob as well. > > Of course, bis does suggest in 22.1 that the UAC should notify the user when > this sort of retargeting happens (when the response comes from an unexpected > user), and that the client's user has to decide whether they trust and/or > want to talk to Bob. Maybe they have seen Bob's identity and credentials > before and they have some reason to trust Bob. Or maybe they feel like > talking to a total stranger. > > I think all we can do is report the break in reference integrity to the > client's user and allow them to treat it as they like. > > Consider this: What if rather than proxying the request to Bob directly, > Alice's proxy server instead propagates a 302 back to the client, > redirecting to Bob's AoR? How has this changed the security implications of > this scenario? You would then be sending out a Request-URI to Bob's AoR, and > Bob could answer with reference integrity. > > Ultimately this just means that you have to trust the proxy server that > manages Alice's contacts to apply them reliably. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 21 08:58:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17407 for ; Thu, 21 Feb 2002 08:58:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22451 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 08:59:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20106; Thu, 21 Feb 2002 08:25:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20077 for ; Thu, 21 Feb 2002 08:25:57 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16269 for ; Thu, 21 Feb 2002 08:25:52 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1LDPNB01747 for ; Thu, 21 Feb 2002 14:25:23 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1LDPMr6012280 for ; Thu, 21 Feb 2002 15:25:22 +0200 (EET) Message-ID: <3C74F57C.6F6FC2EC@lmf.ericsson.se> Date: Thu, 21 Feb 2002 15:26:20 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Bis-7.9: Chapter 17.2.3 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A small issue on chapter 17.2.3 bis-7.9 Q1: "The ACK request matches a transaction if the Request- URI, From tag, Call-ID, CSeq number (not the method), and top Via header field match those of the INVITE request which created the transaction,..." Does the top Via match also in ACKs for transactions which created a 2xx response? Aren't the branch-ids different in the INVITE and ACK? "...and the To tag of the ACK matches the To tag of the response sent by the server transaction. Matching is done based on the matching rules defined for each of those header fields. The usage of the tag in the To header field helps disambiguate ACK for 2xx from ACK for other responses at a proxy, which may have forwarded both responses (which can occur in unusual conditions)." Q2: Should it be mentioned that ACKs for re-INVITEs will include a To tag, even if a non-2xx responses is acked (I KNOW re-INVITEs aren't forked, and that the To tag is not needed for the same purpose in that case). Regards, Christer Holmberg Ericsson 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 daemon@optimus.ietf.org Thu Feb 21 09:01:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17493 for ; Thu, 21 Feb 2002 09:01:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA23089 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 09:01:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21085; Thu, 21 Feb 2002 08:40:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21054 for ; Thu, 21 Feb 2002 08:40:24 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16689 for ; Thu, 21 Feb 2002 08:40:20 -0500 (EST) Received: (qmail 8595 invoked from network); 21 Feb 2002 13:43:26 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 21 Feb 2002 13:43:26 -0000 Received: from stake.com (unknown [10.50.1.35]) by cam-relay.atstake.com (Postfix) with SMTP id 5337822817; Thu, 21 Feb 2002 08:39:35 -0500 (EST) Message-ID: <3C74F893.5060200@stake.com> Date: Thu, 21 Feb 2002 13:39:31 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christian Huitema Cc: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-rfc2543bis-07.9 now available References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit What about adding a Reverse DNS lookup so we can, not only, check the certificate domain against the domain we contacted but also the IP Source Address of the reply if it is corresponding with the domain name as well... Ofir Christian Huitema wrote: > In the Security section, the draft identifies the threat of > "Impersonating a Server" (26.1.2). I would suggest that we document a > variant of this threat, DNS poisoning, and add text such as: > > A possible way to impersonate a server is to use attacks against the > Domain Name System, such as "DNS poisoning." As explained in the > section > 4, Overview of Operation, we expect that a particular type of DNS > queries > can be used to find the SIP server that serves a specific domain; > attacking the DNS can induce a proxy or a UA to route the message > towards > an impersonating server. > > The threat to the UA is addressed in section 26.3.2.1 by stating that > the certificate must "correspond with the domain in which the UA intends > to register", which is explained next as "must identify a host within > the atlanta.com domain (such as sip.atlanta.com)." This is reasonable, > but weak. With this rule, any host in the atlanta.com domain could fake > a registration server; there is no way for the domain manager to hand > out certificates that specifically designate the recipient as "an > authorized SIP server for the domain." An easily implemented protection > would be a host name convention, such as having a certificate that > actually identifies the host as "sip.". > > A similar text is used in section 26.3.2.2, Interdomain Requests: "The > atlanta.com proxy server, for example, SHOULD verify at this stage that > the certificate received from the remote side corresponds with the > biloxi.com domain." This is again a bit underspecified, since it would > potentially allow any compromised host in the "biloxi.com" domain to > impersonate a server. Again, a formal host name convention would be more > effective. > > -- Christian Huitema > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 21 09:08:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17742 for ; Thu, 21 Feb 2002 09:08:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA23473 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 09:08:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21605; Thu, 21 Feb 2002 08:50:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21536 for ; Thu, 21 Feb 2002 08:50:14 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16989; Thu, 21 Feb 2002 08:50:11 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1LDoW6Y012483; Thu, 21 Feb 2002 08:50:32 -0500 (EST) Message-ID: <3C74FAF6.10C136F5@dynamicsoft.com> Date: Thu, 21 Feb 2002 08:49:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mmusic@ietf.org, sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] updated offer/answer draft available Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I've just submitted an update to the offer/answer draft. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-mmusic-sdp-offer-answer-01.txt This is based on comments received during working group last call, and is the version which will go into IESG last call. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 09:53:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19155 for ; Thu, 21 Feb 2002 09:53:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26355 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 09:53:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23895; Thu, 21 Feb 2002 09:17:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23868 for ; Thu, 21 Feb 2002 09:17:52 -0500 (EST) Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17980 for ; Thu, 21 Feb 2002 09:17:47 -0500 (EST) Received: from il-tlv-mbdg2.icomverse.com (il-tlv-mbdg2.icomverse.com [10.115.244.42]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id g1LEFsa23613 for ; Thu, 21 Feb 2002 16:15:54 +0200 Received: by IL-TLV-MBDG2 with Internet Mail Service (5.5.2650.21) id <1VCDSFR6>; Thu, 21 Feb 2002 16:17:44 +0200 Message-ID: From: "Fuxbruner, Amihay" To: sip@ietf.org Subject: [Sip] 491 Retry-After missing bis 07 Date: Thu, 21 Feb 2002 16:17:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Retry-After in Table 3 (Summary of header fields) missed 491. Regards, Amihay Fuxbruner System Engineering - Signaling R&D Comverse _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 21 10:40:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20804 for ; Thu, 21 Feb 2002 10:40:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29604 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 10:40:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27280; Thu, 21 Feb 2002 10:07:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27248 for ; Thu, 21 Feb 2002 10:07:56 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19594 for ; Thu, 21 Feb 2002 10:07:51 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AD48429D0108; Thu, 21 Feb 2002 10:07:52 -0500 Message-ID: <000f01c1bae9$2d7d0980$2300000a@acmepacket.com> From: "Bob Penfield" To: Cc: "Jonathan Rosenberg" Date: Thu, 21 Feb 2002 10:05:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] bis-07.9: proxies are not allowed to modify message body Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Lines 2622-2623 say that "The proxy MUST NOT add to, modify, or remove the message body". Does this mean that all existing Firewall Control Proxies which update the SDP (like example 3.1.5 in draft-ietf-call-flows-05.txt) non-compliant? I guess they will all have to be turned into B2BUAs. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.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 daemon@optimus.ietf.org Thu Feb 21 11:02:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22096 for ; Thu, 21 Feb 2002 11:02:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01316 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 11:02:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29391; Thu, 21 Feb 2002 10:37:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29290 for ; Thu, 21 Feb 2002 10:37:49 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20731 for ; Thu, 21 Feb 2002 10:37:46 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1LFb5h07614; Thu, 21 Feb 2002 07:37:05 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX88304; Thu, 21 Feb 2002 07:36:36 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA00233; Thu, 21 Feb 2002 07:37:03 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15477.5151.840647.459352@thomasm-u1.cisco.com> Date: Thu, 21 Feb 2002 07:37:03 -0800 (PST) To: "Peterson, Jon" Cc: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] SMIME and active MITM attacks In-Reply-To: <70565611B164D511957A001083FCDD56018700E4@VA02> References: <70565611B164D511957A001083FCDD56018700E4@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > Thanks for your last-minute comments, Mike. Some good points here. To your > whole 'S/MIME self-signed cert key exchange in SIP is hopeless' point, as > we've discussed here many times before, we believe it's better than nothing. > Your message is getting through, but I still think we need this S/MIME > mechanism. My comment was only focused on the self-signed certs. In fact, bad security is often worse than no security. At least with no security, people realize that they aren't protected instead of being lulled into a false sense of security. What you propose with self-signed certs is, in fact, much worse than nothing because it is so trivially defeated by that which you claim to be defending against: rogue proxies. Eric thinks it might be OK so long as enough text is put in to tell people not to do it, but I find even that potentially misleading, and in the end harmful if people gloss over the guidance in a rush to have a "secure" SIP widget. > This is a general fact about SIP - that you can send a request To: Alice and > it can be legitimately retargeted To: Bob, and since the UAS doesn't > generate the identity in the To header of responses, you'll get a response > from Bob with a To: Alice header. Just like, say, call forwarding in the > PSTN. The caller has no idea whether Alice set up the call-forwarding > herself or if Bob broke into her PBX and hacked it in. In SIP, of course, > the caller can cryptographically authenticate the proxy server that manages > Alice's contacts (to make sure it really is Alice's proxy), and fortunately > thanks to S/MIME the caller can inspect a signature supplied by Bob > as well. In general, the draft goes to some length to describe how to check identities in a way that actually causes normative behavior. I believe that that is generally wrong. If the application does not differentiate and take action based on identities, then the identity assertion is just informational. In either case, I do not see why it requires normative text beyond a way to reject calls or bad signatures. The comparisons using From/To: address in particular are suspect. The trustable identity is in the DN/SubAltName of the cert. The proper thing to do say in the spec, I expect, is just to *ignore* the To/From: addresses in the fact of SMIME. 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 daemon@optimus.ietf.org Thu Feb 21 11:12:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22515 for ; Thu, 21 Feb 2002 11:12:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01966 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 11:12:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00134; Thu, 21 Feb 2002 10:50:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00104 for ; Thu, 21 Feb 2002 10:50:27 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21388 for ; Thu, 21 Feb 2002 10:50:23 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1LFngh17267; Thu, 21 Feb 2002 07:49:42 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX88464; Thu, 21 Feb 2002 07:49:14 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA00236; Thu, 21 Feb 2002 07:49:42 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15477.5910.43612.897076@thomasm-u1.cisco.com> Date: Thu, 21 Feb 2002 07:49:42 -0800 (PST) To: "Peterson, Jon" Cc: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] more SMIME comments In-Reply-To: <70565611B164D511957A001083FCDD56018700E3@VA02> References: <70565611B164D511957A001083FCDD56018700E3@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > > Thanks for these last-minute nits, Mike. The appropriate changes will be > applied. Some notes below. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Wednesday, February 20, 2002 9:26 AM > > To: sip@ietf.org > > Subject: [Sip] more SMIME comments > > > > > > > > 1) You cannot put RFC 822 addresses into X.509 > > distinguished names (DN's). You either need to > > have a mapping function, or place requirements > > in subject-alt-name, etc. > > Yeah, we talk pretty casually about having the 'subject' of the certificate > be an identity. I think EKR spoke to this already in another mail; I believe > 2633 characterizes this. Maybe we should at least once in the spec not speak > casually about this. > > > > > 2) The general requirements for a "keyring" for > > non-disk based UA's is, essentially, > > impossible. Unlike what Henning said yesterday, > > use for encryption requires that both the > > distinguished name and the entire public key > > (not a hash!) need to be stored. Considering > > that phones typically receive calls from > > anywhere, the storage needs are unbound. I'm > > willing to believe that this isn't an issue for > > a multi-gigabyte disk. For flash based UA's, > > however, this is an unreasonable requirement. > > Agreed that it won't be reasonable for all user agents. For the same reason, > managing a large set of root certificates in a tiny UA is infeasible. We > need to strike a balance somewhere in the middle. Maybe smallish handsets > will only have room for a few certificates (like, 10 seats worth). Maybe > some handsets won't be able to use it at all. I long for the day when an > iPaq-strength handheld wireless device gets provider subsidies like > cell-phones do. I'm not sure if we really need to add anything to the text > to capture your thinking here, though. Well, on the one hand we have a general requirement that we build a protocol suitable for SIP widgets of all shapes and sizes, and on the other hand we know that some shapes and sizes won't be able to provide this feature. What's wrong with picture? Unlike code footprint which is a one-time expendature, this is, in fact, unbound. What that says is that the proposed mechanism is either inappropriate for the requirements, or that the problem is generally infeasible. I don't think it's the latter because it clear that you don't need to store per client anything for, say, IKE/TLS. Thus I guess we're left with wondering whether this is the right answer for SIP. And spare me that "good enough" argument again. That has never been the standard around here before. > > 7) A change in certificates stored is not > > necessarily an error. I don't think the > > normative text here is helpful because this > > is probably a revocation issue. As in, the > > UA complains to the user, and the user is > > supposed to do what, exactly? This seems > > loaded with the ability for abuse. > > The user could reject the request. Hang up and call back, maybe. It is a > good point that we should probably recommend some behavior to users here. > > I agree that a change in certificates is not necessarily a security breach, > but I think it is certainly a cause for alarm if it is unexpected. > Revocation for self-signed certificates is clearly a pretty ad-hoc matter; > we do recommend that users keep certs for a long time, but there isn't much > you can do if some new Outlook virus posts your private key to > rec.humor.funny. You have to make a new key and re-establish trust with any > users who had your old key. Again, this points to a structural problem with the mechanisms you've defined. The answer to a listing tower is not to get everybody to move to one side. 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 daemon@optimus.ietf.org Thu Feb 21 11:50:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24003 for ; Thu, 21 Feb 2002 11:50:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04454 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 11:50:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02750; Thu, 21 Feb 2002 11:27:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02698 for ; Thu, 21 Feb 2002 11:27:25 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23001 for ; Thu, 21 Feb 2002 11:26:36 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1LGQ1h17245; Thu, 21 Feb 2002 08:26:01 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACM94876; Thu, 21 Feb 2002 08:25:59 -0800 (PST) Date: Thu, 21 Feb 2002 08:24:32 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org cc: jdrosen@dynamicsoft.com Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Decrement Max-Forwards when acting on a 3xx Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Last minute suggestion... I think the text which describes 3xx behavior (8.1.3.4) should add a sentence saying that you SHOULD or MUST copy the Max-Forwards from the response and decrement by one before sending your request to the new Contact. This would help prevent redirect loops. 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 daemon@optimus.ietf.org Thu Feb 21 12:27:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25499 for ; Thu, 21 Feb 2002 12:27:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10610 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 12:27:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08313; Thu, 21 Feb 2002 12:13:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08279 for ; Thu, 21 Feb 2002 12:13:12 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24973 for ; Thu, 21 Feb 2002 12:13:08 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AAA7FE190108; Thu, 21 Feb 2002 12:13:11 -0500 Message-ID: <001f01c1bafa$a763a400$2300000a@acmepacket.com> From: "Bob Penfield" To: Date: Thu, 21 Feb 2002 12:10:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] bis-07.9: SDP in 1xx responses Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The rules in section 13.2.1 (lines 2113-2123) appear to disallow SDP in unreliable provisional responses. I know there are a lot of implementation out there that send SDP in 1xx responses. Should it say that SDP MAY be present in 1xx when an offer is sent in the INVITE, but it SHOULD match the SDP that the UAS will/would send in a 2xx (is that your final answer :) in order to be backwardly compatible with existing UAs. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.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 daemon@optimus.ietf.org Thu Feb 21 12:49:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26295 for ; Thu, 21 Feb 2002 12:49:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14654 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 12:49:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13719; Thu, 21 Feb 2002 12:30:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13672 for ; Thu, 21 Feb 2002 12:30:43 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25603 for ; Thu, 21 Feb 2002 12:30:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1LHUO6Y012760; Thu, 21 Feb 2002 12:30:24 -0500 (EST) Message-ID: <3C752E7B.7D2098A9@dynamicsoft.com> Date: Thu, 21 Feb 2002 12:29:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] bis-08 is born Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I'm pleased to announce that I've just submitted bis-08 to the archives. Until it appears, you can pick up a copy in the usual places: http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-08.txt http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-08.ps http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-08.pdf or: http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-08.txt http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-08.ps http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-08.pdf Changebars represent diffs from -07, NOT -07.9. This completes the first "bundle" of drafts which are now off to IESG last call for consideration as proposed: draft-ietf-sip-rfc2543bis draft-ietf-sip-100rel draft-ietf-sip-srv draft-ietf-mmusic-sdp-offer-answer draft-ietf-sip-events These drafts are right on time based on the scheduling worked out to meet 3gpp timelines. There will almost certainly be a bis-09 which incorporates further iesg and reviewer comment; however, it is our expectation that the changes from -08 to -09 will be small, primarily nits/grammar and improved wordings on some of the newer stuff, like sips. I would like to once again thank the bis editors team for the tremendous amount of effort that went into this document. The editors have been working weekends and into the wee hours of the night to make sure we meet our deadlines. Last night was the biggest stretch of all, with several of us, including myself, pulling all nighters (I have not slept in about 30 hours). To make things more interesting, the Columbia fileserver where our text converter lives crashed in the middle of the final build of bis-08 this morning! Very scary. I'd like to thank the working group as a whole for the tremendous efforts that went into reviewing the document. The hundreds of comments we received from many of you are a big part of bringing the spec to the level of quality it is at today. I'd also like to thank Jean Mahoney, a technical writer from dynamicsoft who has volunteered her time to improve the quality of the text. Many (if not most) of the reviewer comments that were grammatical and stylistic in nature were handled by her. However, there is no time to rest on our laurels. We have the next bundle of deliverables coming up for 3gpp - update, manyfolks, privacy, call-auth and (possibly) path. I would encourage the group to provide the same focus on those drafts that was given to the drafts in the first bundle. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 21 13:24:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27962 for ; Thu, 21 Feb 2002 13:24:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17311 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 13:24:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16091; Thu, 21 Feb 2002 13:06:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16062 for ; Thu, 21 Feb 2002 13:06:28 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27094 for ; Thu, 21 Feb 2002 13:06:26 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E1FEC6A909; Thu, 21 Feb 2002 20:06:21 +0200 (EET) Message-ID: <3C7535DE.40704@piuha.net> Date: Thu, 21 Feb 2002 20:01:02 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: sip@ietf.org Subject: Re: [Sip] more SMIME comments References: <15475.56384.704095.62370@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > 2) The general requirements for a "keyring" for > non-disk based UA's is, essentially, > impossible. Unlike what Henning said yesterday, > use for encryption requires that both the > distinguished name and the entire public key > (not a hash!) need to be stored. I'm not sure why you say we need to store the public key. Theoretically, you need to store the SubjAltName and a hash, I think, because on reception you can (hope) to receive the cert from the peer, and verify the SubjAltName - Certificate - Public Key - Hash relationship. For sending if you swapped out the public key you could request the peer to give you that using OPTIONS, and then do the same verification, and send the real message. In essence, this is a RTT vs. memory tradeoff. The current bis text seems pretty clear RTT is prioritized, which I think I support. Or do we need to clarify some of this in the text? Or perhaps leave this for low-cost device implementors to figure out? I also scanned through the bis limitations text and it doesn't talk about the replay protection limitation for S/MIME. This should be added, if it can't be fixed now. Also, at some point we need to be able to do S/MIME like functionality e2m, and the current text doesn't describe how. Well, maybe B2BUAs could be used, but I'm not sure all text is there yet. Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 21 13:34:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28474 for ; Thu, 21 Feb 2002 13:34:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18486 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 13:35:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16136; Thu, 21 Feb 2002 13:06:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16105 for ; Thu, 21 Feb 2002 13:06:40 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27099 for ; Thu, 21 Feb 2002 13:06:37 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3FAE46A90A; Thu, 21 Feb 2002 20:06:22 +0200 (EET) Message-ID: <3C753725.1030701@piuha.net> Date: Thu, 21 Feb 2002 20:06:29 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: EKR Cc: Michael Thomas , sip@ietf.org Subject: Re: [Sip] SMIME and active MITM attacks References: <15475.53319.640011.994162@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think the leap-of-faith, with its problems, still makes sense for SIP. It does work in the case where you train your laptop and your friend's laptop to know each other at YourSecureDomain.Com and then you move to BadGovermentOrOperator.Org since the original exchange was in a secure place. I do think though that the dangers must be very clearly described, in the bis rfc, as well as in product documentation... though I'm not sure much more can be said that 22.4.2 already says. Jari Eric Rescorla wrote: > Michael Thomas writes: > >>Second, the entire concept of using self-signed >>certs in the face of active MITM attacks is bogus. >>At least with rooted certs, you can at least show >>a user that the identity presented is provably >>part of a known CA's namespace. Self-signed certs >>have no such insurance, so they provide no >>additional authentication benefit in this case. >>This is in contrast to SSH-like leap's of faith. >>For SSH, the plausibility of an active MITM is >>explicitly discounted because of the general >>difficultly of mounting such an attack on the >>Internet. >> > I'm not sure that I agree with your assessment here, not > so much because I don't think the threat of active attack > is serious in the SIP context, than because I'm not really > that sanguine about it's difficulty in the context of SSH. > It's pretty easy to get code to mount hijacking attacks. > > As I see it, SSH's key management is intended to protect > against semi-reactive attacks, where an attacker decides > to impersonate a given party at a given time. Caching keys > protects you from this attack. An attacker must perform > the MITM attack at the time when the peers first communicate. > This means either knowing in advance that you're going to > attack a given party or mounting a global MITM attack so > you can impersonate someone later. Similar comments apply to SIP. > > -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 daemon@optimus.ietf.org Thu Feb 21 13:49:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29072 for ; Thu, 21 Feb 2002 13:49:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19258 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 13:49:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17720; Thu, 21 Feb 2002 13:30:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17676 for ; Thu, 21 Feb 2002 13:30:01 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28204 for ; Thu, 21 Feb 2002 13:29:58 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1LITJt07766; Thu, 21 Feb 2002 10:29:19 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX92160; Thu, 21 Feb 2002 10:28:51 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA00253; Thu, 21 Feb 2002 10:29:18 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15477.15486.301937.177944@thomasm-u1.cisco.com> Date: Thu, 21 Feb 2002 10:29:18 -0800 (PST) To: jari.arkko@piuha.net Cc: Michael Thomas , sip@ietf.org Subject: Re: [Sip] more SMIME comments In-Reply-To: <3C7535DE.40704@piuha.net> References: <15475.56384.704095.62370@thomasm-u1.cisco.com> <3C7535DE.40704@piuha.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jari Arkko writes: > Michael Thomas wrote: > > > > 2) The general requirements for a "keyring" for > > non-disk based UA's is, essentially, > > impossible. Unlike what Henning said yesterday, > > use for encryption requires that both the > > distinguished name and the entire public key > > (not a hash!) need to be stored. > > > I'm not sure why you say we need to store the public key. Encryption. 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 daemon@optimus.ietf.org Thu Feb 21 13:54:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29368 for ; Thu, 21 Feb 2002 13:54:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19602 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 13:54:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18819; Thu, 21 Feb 2002 13:39:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18788 for ; Thu, 21 Feb 2002 13:39:18 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28681 for ; Thu, 21 Feb 2002 13:39:15 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1LIchE21728; Thu, 21 Feb 2002 10:38:43 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX92418; Thu, 21 Feb 2002 10:38:14 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA00257; Thu, 21 Feb 2002 10:38:42 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15477.16050.106482.275093@thomasm-u1.cisco.com> Date: Thu, 21 Feb 2002 10:38:42 -0800 (PST) To: jari.arkko@piuha.net Cc: EKR , Michael Thomas , sip@ietf.org Subject: Re: [Sip] SMIME and active MITM attacks In-Reply-To: <3C753725.1030701@piuha.net> References: <15475.53319.640011.994162@thomasm-u1.cisco.com> <3C753725.1030701@piuha.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jari Arkko writes: > I think the leap-of-faith, with its problems, still > makes sense for SIP. It does work in the case where > you train your laptop and your friend's laptop to know > each other at YourSecureDomain.Com and then you move to > BadGovermentOrOperator.Org since the original exchange > was in a secure place. ??? But this isn't a leap of faith, right? You've provisioned yourself while not exposing yourself to the active MITM attackers, right? Leap of faith -- to me at least -- means that you're willing to expose yourself once to a MITM attack, on the general premise that the likelihood of being subject to an active MITM attack at any particular time is relatively low. (or that you can decide not to do it when you feel that it is too risky). In the cases that SMIME needs to protect against, I think that is a *very* dangerous proposition. I like leap of faith in some cases because I think it provides reasonable ease-of-use vs. security tradeoff. However, I don't think this is one of those cases given the ease to mount an active attack. At some point, you just need to bite the bullet. 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 daemon@optimus.ietf.org Thu Feb 21 14:27:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00766 for ; Thu, 21 Feb 2002 14:27:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21476 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 14:27:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19845; Thu, 21 Feb 2002 14:00:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19791 for ; Thu, 21 Feb 2002 14:00:04 -0500 (EST) Received: from imo-d03.mx.aol.com (imo-d03.mx.aol.com [205.188.157.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29571 for ; Thu, 21 Feb 2002 14:00:01 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d03.mx.aol.com (mail_out_v32.5.) id 7.72.180e7809 (3936); Thu, 21 Feb 2002 13:58:46 -0500 (EST) Message-ID: <72.180e7809.29a69d65@aol.com> Date: Thu, 21 Feb 2002 13:58:45 EST Subject: Re: [Sip] Comments on Resource Priority Header To: hgs@cs.columbia.edu CC: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In a message dated 2/17/02 5:48:47 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > > Mpierce1@aol.com wrote: > > > > I have the following comments on draft-polk-sip-resource-01: > > > > 4. IANA > > > > Why is a restriction needed that an existing list not be extended? If the dsn > > wishes to later add a new level below "Routine", it should be allowed to do > > so. > > The reasoning is simple: If my implementation believes it understands > namespace 'foo' based on an IANA registration at the time I built the > system, I shouldn't be surprised by some new value in that same name > space. How can the implementation deal with this sensibly? If you say > that any new value has to have priority below the current lowest one, > that would indeed work. Having new values added later that fall > somewhere in the middle is not possible without risking interoperability > surprises. Is that what you had in mind? > > > Mike Pierce > An implementation would already need to have a procedure to follow if it got a priority it did not understand, like defaulting to the lowest it knows. So if a new value were defined and an old implemenation received that new value, that is what it would do. It just seems too restrictive to say that a "domain" or network could never in the future add a new priority value. Granted, the proper use of that new value would require upgrading any equipment that might use the value in its processing, but then I suspect the same will be true for many other improvements/extensions to the protocol in the future. Isn't it true that the current situation is that a device must ignore any thing it doesn't understand, just like http? I guess the use of "SHOULD NOT" in the draft in fact indicates that it could be done, but it is not recommended, so I suppose this wording is acceptable. 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 daemon@optimus.ietf.org Thu Feb 21 14:54:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01486 for ; Thu, 21 Feb 2002 14:54:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22686 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 14:54:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21921; Thu, 21 Feb 2002 14:31:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21884 for ; Thu, 21 Feb 2002 14:31:08 -0500 (EST) Received: from web21411.mail.yahoo.com (web21411.mail.yahoo.com [216.136.232.80]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00960 for ; Thu, 21 Feb 2002 14:31:05 -0500 (EST) Message-ID: <20020221193105.31631.qmail@web21411.mail.yahoo.com> Received: from [12.146.131.5] by web21411.mail.yahoo.com via HTTP; Thu, 21 Feb 2002 11:31:05 PST Date: Thu, 21 Feb 2002 11:31:05 -0800 (PST) From: Venkatasubramanian Tiruthani To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] REGISTER Method: How does proxy interpret the address associations Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The REGISTER method allows a UAC to associate the address-of-record with the one or more contact addresses. Each of the contact address could correspond to a transport address or it could simply be another name. For example let us say, that the following contact addresses are associated with the user with address-of-record sip:jdoe@acme.com: sip:5555@scn.acme.com sip:+1-408-5555555@pstn.acme.com sip:jdoe@mycomputer.acme.com The above register method can have two possible interpretations: 1) When a call is made to jdoe@acme.com, the proxy should place a call to either 5555@scn.acme.com, or +1-408-5555555@pstn.acme.com (or) jdoe@mycomputer.acme.com. This interpretation is more like a follow me service, where the contact addresses represent alternative addresses where the user can be reached. 2) When a call is made to jdoe@acme.com or +1-408-5555555@pstn.acme.com or 5555@scn.acme,com the call should always be placed at jdoe@mycomputer.com. In this interpretation, the contact addresses represent the same person. Is there a way for a proxy to unambiguously interpret using existing provisions in SIP Protocol If there is no such provisions, should future versions consider them? Or, is this outside the scope of SIP protocol - and is left to proxy implementors. Your input on this will be very much appreciated. Regards, Saran Tiruthani __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.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 daemon@optimus.ietf.org Thu Feb 21 16:20:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04691 for ; Thu, 21 Feb 2002 16:20:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA26873 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 16:20:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25603; Thu, 21 Feb 2002 15:57:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25572 for ; Thu, 21 Feb 2002 15:57:05 -0500 (EST) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03843 for ; Thu, 21 Feb 2002 15:57:00 -0500 (EST) Received: from office.snowshore.com (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g1LKv0B02599; Thu, 21 Feb 2002 15:57:00 -0500 (EST) Message-Id: <200202212057.g1LKv0B02599@flyingfox.snowshore.com> From: Jeff Van Dyke To: Aaron Lo , sip@ietf.org Subject: RE: [Sip] 200 for INFO Date: Thu, 21 Feb 2002 15:56:46 -0500 X-Mailer: CorporateTime Outlook Connector 3.1.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=-------6d7a4ee66d7a4ee6 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format ---------6d7a4ee66d7a4ee6 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Aaron, The RFC specifically mentions that it only addresses the behaviors for = INFO requests that do not contain a message body. Message bodies are allow= ed, just not covered by the RFC. So after reviewing this passage several t= imes, we've interpreted this to mean that a UAS must send a 200 OK response= to an INFO request that does not contain a message body. The 200 OK is re= quired even if the UAS does not understand any additional headers that may = have been sent. The 200 OK simply acknowledges that the INFO was received = successfully. If the INFO request does contain a message body, additional semantics m= ay apply and these are not addressed by the RFC. In this case the UAS may = send a response containing a message body or not, depending on the situatio= n. Regards, Jeff -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Aaron Lo= Sent: Friday, December 21, 2001 4:38 AM To: 'sip@ietf.org' Subject: [Sip] 200 for INFO Hi all, In RFC2976 SIP INFO Method sec 2.2 page 3, it reads = A 200 OK response MUST be sent by a UAS for an INFO request with no message body if the INFO request was successfully received for an existing call. Beyond that, no additional operations are required. Does it mean that the 200 OK should not contain a message body, or does i= t mean that a 200 OK should be sent even if the INFO does not contain a mes= sage body? Can someone clarify? Thanks. Aaron ---------6d7a4ee66d7a4ee6 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Aaron,
    The RFC specifically mentions that it only address= es the = behaviors for INFO requests that do not contain a message body.  Messa= ge = bodies are allowed, just not covered by the RFC.  So after reviewing t= his = passage several times, we've interpreted this to mean that a UAS must send = a 200 = OK response to an INFO request that does not contain a message body.  = The = 200 OK is required even if the UAS does not understand any additional heade= rs = that may have been sent.  The 200 OK simply acknowledges that the INFO= was = received successfully.
    If the INFO request does contain a message body= , = additional semantics may apply and these are not addressed by the RFC. = ; In = this case the UAS may send a response containing a message body or not, = depending on the situation.
Regards,
    Jeff
-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of Aaron Lo
Sent: = Friday, December 21, 2001 4:38 AM
To: = 'sip@ietf.org'
Subject: [Sip] 200 for INFO

=

Hi all,

 

In RFC2976 SIP INFO Method = sec 2.2 = page 3, it reads

 

 = ;  A 200 OK response MUST be sent by a UAS for an INFO request with
   no message body if the INFO request was success=
fully received for
   an existing call.  Beyo=
nd that, no additional operations are
   require=
d.

 

Does it mean that the 200 O= K = should not contain a message body, or does it mean that a 200 OK should b= e = sent even if the INFO does not contain a message body? Can someone clarif= y? = Thanks.

 

Aaron

---------6d7a4ee66d7a4ee6-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Feb 21 20:53:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09067 for ; Thu, 21 Feb 2002 20:53:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA09010 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 20:53:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07549; Thu, 21 Feb 2002 20:21:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07521 for ; Thu, 21 Feb 2002 20:21:33 -0500 (EST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08602 for ; Thu, 21 Feb 2002 20:21:28 -0500 (EST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 21 Feb 2002 17:20:19 -0800 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 21 Feb 2002 17:20:19 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 17:20:19 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 17:20:18 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Thu, 21 Feb 2002 17:18:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] draft-ietf-sip-rfc2543bis-07.9 now available Date: Thu, 21 Feb 2002 17:18:14 -0800 Message-ID: Thread-Topic: [Sip] draft-ietf-sip-rfc2543bis-07.9 now available thread-index: AcG63Qr+LLlEGd3aQKSZclXnGv6KggAYftYg From: "Christian Huitema" To: "Ofir Arkin" Cc: "Jonathan Rosenberg" , X-OriginalArrivalTime: 22 Feb 2002 01:18:15.0027 (UTC) FILETIME=[CD53C430:01C1BB3E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA07522 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Use reverse DNS lookup as a protection against DNS poisoning? You must be kidding! -- Christian Huitema > From: Ofir Arkin [mailto:ofir@stake.com] > > What about adding a Reverse DNS lookup so we can, not only, check the > certificate domain against the domain we contacted but also the IP > Source Address of the reply if it is corresponding with the domain name > as well... > > Ofir > > Christian Huitema wrote: > > > In the Security section, the draft identifies the threat of > > "Impersonating a Server" (26.1.2). I would suggest that we document a > > variant of this threat, DNS poisoning, and add text such as: > > > > A possible way to impersonate a server is to use attacks against the > > Domain Name System, such as "DNS poisoning." As explained in the > > section > > 4, Overview of Operation, we expect that a particular type of DNS > > queries > > can be used to find the SIP server that serves a specific domain; > > attacking the DNS can induce a proxy or a UA to route the message > > towards > > an impersonating server. > > > > The threat to the UA is addressed in section 26.3.2.1 by stating that > > the certificate must "correspond with the domain in which the UA intends > > to register", which is explained next as "must identify a host within > > the atlanta.com domain (such as sip.atlanta.com)." This is reasonable, > > but weak. With this rule, any host in the atlanta.com domain could fake > > a registration server; there is no way for the domain manager to hand > > out certificates that specifically designate the recipient as "an > > authorized SIP server for the domain." An easily implemented protection > > would be a host name convention, such as having a certificate that > > actually identifies the host as "sip.". > > > > A similar text is used in section 26.3.2.2, Interdomain Requests: "The > > atlanta.com proxy server, for example, SHOULD verify at this stage that > > the certificate received from the remote side corresponds with the > > biloxi.com domain." This is again a bit underspecified, since it would > > potentially allow any compromised host in the "biloxi.com" domain to > > impersonate a server. Again, a formal host name convention would be more > > effective. > > > > -- Christian Huitema > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > -- > Ofir Arkin > Managing Security Architect > @stake, Limited. > http://www.atstake.com > email: > ofir@stake.com > Tel: > +44 (0) 207 495 7002 > Fax: > +44 (0) 207 495 7062 > Mobile: +44 (0) 779 630 8632 > > ----------------------------- > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, re transmission, 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 any computer. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Thu Feb 21 20:59:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09119 for ; Thu, 21 Feb 2002 20:59:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA09166 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 20:59:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08460; Thu, 21 Feb 2002 20:38:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08428 for ; Thu, 21 Feb 2002 20:38:25 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08827 for ; Thu, 21 Feb 2002 20:38:22 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1M1bXj18527; Thu, 21 Feb 2002 20:37:33 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAF61074; Thu, 21 Feb 2002 20:40:25 -0500 (EST) Message-ID: <3C759F50.6685D5B0@cisco.com> Date: Thu, 21 Feb 2002 20:30:56 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org, sip-implementors@cs.columbia.edu References: <3C752E7B.7D2098A9@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] bis-08 is born Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jon, Still behind in my reading - this is a question about a change that must have first appeared in bis-06 or -07. But I will refer to -08 here: In lines 1709-1710 (section 10.3 item 6) is a rule that a REGISTER containing Contact:* must not contain any other contact lines. Why has this restriction been added? I don't see any great benefit to imposing this restriction, and it could be inconvenient. If there might be a prior registration, and the intent is for a new registration to supercede that, life becomes difficult. Either this requires two REGISTERs, one with Contact:* and then another with the desired new values, or else the exact set of prior contact headers must be known, and the new REGISTER must repeat all the old contact addresses, with expires=0. Why not simply state that if a Contact:* is present it must be processed before the other Contact entries? - I also have another register related issue that should have been raised sooner. It is presumably too late to deal with now, but I raise it in hopes that there will be an opportunity to consider it at some future time: In lines 1733-1739 (section 10.3 item 7) the rules are specified for matching and replacement of individual bindings. As worded, I believe this would result in aborting any REGISTER that contains multiple Contact entries with the same address. Back in bis-05 and before the handling of this case was ambiguous. It is still slightly ambiguous because it isn't entirely clear if items that have been tentatively added are to be searched. Of course it is silly to have two Contact entries with the same address if there is nothing else to be different about them. But the built in extension mechanisms permit the construction of different contact headers with the same address but different parameters, and the callerprefs draft does so. With that draft is is indeed useful to be able to do so. A minor change to the wording in this section would permit multiple contact entries with the same address to be delivered in a single REGISTER: "For each address, the registrar then searches the list of current bindings using the URI comparison rules, excluding those tentatively added while processing this request. If no matching binding exists, one is tentatively added. If one or more matching bindings do exist, the registrar checks the Call-ID value of each. If the Call-ID value in a matching binding differs from the Call-ID value in the request, the binding MUST be removed if the expiration time is zero and updated otherwise. If they are the same, the registrar compares the CSeq value. If the value is higher than that of the existing binding, it MUST update or remove the binding as above. If not, the update MUST be aborted and the request fails." (There may be clearer wordings, but this is a minimal change.) In the earlier discussion Jon and others suggested hacks to work around this, such as using addresses distinguished by a URL parameter. But those are hacks, while this is not. Sorry to stir the pot now, 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 daemon@ns.ietf.org Thu Feb 21 22:34:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12088 for ; Thu, 21 Feb 2002 22:34:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA13464 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 22:34:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12656; Thu, 21 Feb 2002 22:17:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12528 for ; Thu, 21 Feb 2002 22:16:48 -0500 (EST) Received: from services.dasecurenetworks.com (adsl-64-219-171-33.dsl.rcsntx.swbell.net [64.219.171.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10879 for ; Thu, 21 Feb 2002 22:16:40 -0500 (EST) Received: from dasecurenetworks.com (main1.dasecurenetworks.com [192.168.0.151] (may be forged)) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g1M2ffX02305; Thu, 21 Feb 2002 20:41:41 -0600 Message-ID: <3C75BA7A.B67130A9@dasecurenetworks.com> Date: Thu, 21 Feb 2002 21:26:50 -0600 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Ofir Arkin CC: Christian Huitema , Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-rfc2543bis-07.9 now available References: <3C74F893.5060200@stake.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ofir Arkin wrote: > > What about adding a Reverse DNS lookup so we can, not only, check the > certificate domain against the domain we contacted but also the IP > Source Address of the reply if it is corresponding with the domain name > as well... If the DNS Server has been a victim of poisoning, any type of querie response would be suspect. > > Ofir > > Christian Huitema wrote: > > > In the Security section, the draft identifies the threat of > > "Impersonating a Server" (26.1.2). I would suggest that we document a > > variant of this threat, DNS poisoning, and add text such as: > > > > A possible way to impersonate a server is to use attacks against the > > Domain Name System, such as "DNS poisoning." As explained in the > > section > > 4, Overview of Operation, we expect that a particular type of DNS > > queries > > can be used to find the SIP server that serves a specific domain; > > attacking the DNS can induce a proxy or a UA to route the message > > towards > > an impersonating server. > > > > The threat to the UA is addressed in section 26.3.2.1 by stating that > > the certificate must "correspond with the domain in which the UA intends > > to register", which is explained next as "must identify a host within > > the atlanta.com domain (such as sip.atlanta.com)." This is reasonable, > > but weak. With this rule, any host in the atlanta.com domain could fake > > a registration server; there is no way for the domain manager to hand > > out certificates that specifically designate the recipient as "an > > authorized SIP server for the domain." An easily implemented protection > > would be a host name convention, such as having a certificate that > > actually identifies the host as "sip.". > > > > A similar text is used in section 26.3.2.2, Interdomain Requests: "The > > atlanta.com proxy server, for example, SHOULD verify at this stage that > > the certificate received from the remote side corresponds with the > > biloxi.com domain." This is again a bit underspecified, since it would > > potentially allow any compromised host in the "biloxi.com" domain to > > impersonate a server. Again, a formal host name convention would be more > > effective. > > > > -- Christian Huitema > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > Ofir Arkin > Managing Security Architect > @stake, Limited. > http://www.atstake.com > email: > ofir@stake.com > Tel: > +44 (0) 207 495 7002 > Fax: > +44 (0) 207 495 7062 > Mobile: +44 (0) 779 630 8632 > > ----------------------------- > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, re transmission, 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 any computer. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Thu Feb 21 23:22:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12892 for ; Thu, 21 Feb 2002 23:22:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA15105 for sip-archive@odin.ietf.org; Thu, 21 Feb 2002 23:22:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14770; Thu, 21 Feb 2002 23:06:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14739 for ; Thu, 21 Feb 2002 23:06:44 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12621 for ; Thu, 21 Feb 2002 23:06:39 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1M46CE18270 for ; Thu, 21 Feb 2002 20:06:12 -0800 (PST) Received: from oranlt ([161.44.238.49]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACC17188; Thu, 21 Feb 2002 20:06:21 -0800 (PST) From: "David R. Oran" To: Subject: RE: [Sip] multicast restricted to ttl=1 Date: Thu, 21 Feb 2002 23:05:44 -0500 Organization: Cisco Systems Message-ID: <002801c1bb56$33e48380$31ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C6FFFCB.14D4B253@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Jonathan Rosenberg > Sent: Sunday, February 17, 2002 2:09 PM > To: sip@ietf.org > Subject: [Sip] multicast restricted to ttl=1 > > > Folks, > > As a result of IESG review, there were concerns about the > multicast usage of SIP. In particular, for the things we were > using it for, it was felt that a limitation of scope to ttl=1 > was needed. As such, I have modified the transport chapter to > reflect a SHOULD level usage of ttl=1. > Well, according to bis-08, multicast can be used to find a registrar if you don't have a DNS-discoverable proxy to route your register to. If that's the purpose, what leads one to believe that the registrar is likely to be on your local subnet? Seems if multicast for regisration is useful at all, it makes more sense for the discovery to either be via expanding ring broadcast and/or an admin-scoped group. BTW: bis-08 does not prohibit multicasting INVITES, which is equally useful (which could be to say not very...) as multicasting registrations, for completely infrastructure-less small configurations. The same question about single-hop applies. What am I missing? If I'm not missing anything and the SHOULD is an attempt balance utility against danger, I'm not sure the balance is right, since violating a SHOULD makes you only conditionally compliant, whereas I can think of quite a few configurations which are small enough to want to use this (e.g. for minimal functioality when your proxy/registrar is pooched) yet span more than one subnet. Does an admin scope on the multicast strike a better balance? I don't feel strongly about this, BTW. Dave. > Comments or questions welcome. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 daemon@ns.ietf.org Fri Feb 22 04:17:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24942 for ; Fri, 22 Feb 2002 04:17:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA07219 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 04:18:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06018; Fri, 22 Feb 2002 03:52:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05994 for ; Fri, 22 Feb 2002 03:52:22 -0500 (EST) Received: from smtp01ffm.de.uu.net (smtp01ffm.de.uu.net [192.76.144.150]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24718 for ; Fri, 22 Feb 2002 03:52:19 -0500 (EST) Received: from penelope.materna.de (penelope.materna.de [193.96.115.65]) by smtp01ffm.de.uu.net (5.5.5/5.5.5) with ESMTP id JAA06544 for ; Fri, 22 Feb 2002 09:52:53 +0100 (MET) Received: from ganymed (ganymed.materna.de [139.2.34.141]) by penelope.materna.de (Postfix) with ESMTP id 10B8767F5 for ; Fri, 22 Feb 2002 09:52:20 +0100 (MET) Received: from thurn.materna.de (actually localhost) by ganymed with Internet with ESMTP; Fri, 22 Feb 2002 09:52:20 +0100 Received: by thurn.materna.de with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 09:52:18 +0100 Message-ID: <73B855B4F72FD411A1CF009027B113C40199F69E@taxis.materna.de> From: "Nagel, Thomas" To: "'sip@ietf.org'" Date: Fri, 22 Feb 2002 09:52:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Q: SIP Encapsulation in XML? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello SIP-gurus ;) what do you think of an encapsulation of SIP messages into XML? If would enable the transport over HTTP, processing by Java Servlets, and constucting a HTTP-client for Java 2 Micro Edition MIDlets (which per default only mandate HTTP-connections). Has this been done somewhere already? If so, what are the experiences? What would be the drawbacks of such an encapsulation? Thanks in advance, Thomas Nagel -- Thomas Nagel Research Business Unit Communications MATERNA GmbH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Feb 22 05:07:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25873 for ; Fri, 22 Feb 2002 05:07:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA10788 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 05:07:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08566; Fri, 22 Feb 2002 04:40:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08536 for ; Fri, 22 Feb 2002 04:40:43 -0500 (EST) Received: from carbon.btinternet.com (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25195 for ; Fri, 22 Feb 2002 04:40:34 -0500 (EST) Received: from host213-1-171-44.btinternet.com ([213.1.171.44] helo=tkw) by carbon.btinternet.com with smtp (Exim 3.22 #8) id 16eCBu-0000Ev-00; Fri, 22 Feb 2002 09:40:34 +0000 Message-ID: <002701c1bb85$081198e0$0200000a@tkw> From: "Pete Cordell" To: "Bob Penfield" , Cc: "Jonathan Rosenberg" References: <000f01c1bae9$2d7d0980$2300000a@acmepacket.com> Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body Date: Fri, 22 Feb 2002 09:40:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Bob Penfield > Lines 2622-2623 say that "The proxy MUST NOT add to, modify, or remove the > message body". Does this mean that all existing Firewall Control Proxies > which update the SDP (like example 3.1.5 in draft-ietf-call-flows-05.txt) > non-compliant? I guess they will all have to be turned into B2BUAs. I too think that this is overly restrictive, and may come to bite us in the future. There are many things that you can do, firewall control for one, that require you to change the SDP, but don't necessitate a full back to back UAC / UAS. For example, a proxy in an enterprise context might want to remove high bandwidth codecs from the SDP so that it doesn't use too much bandwidth on the access link. This seems quite legitimate policy, and helpful. I'm sure that there are many other things that will become attractive in the future that we can't think of at the moment. In fact, from simple proxy to full B2BUA there is a whole spectrum of devices, of which they are only two points. Indeed, at some phases intermediaries may act as stateless proxies, and other phases they maybe full B2BUAs. Making a device non-compliant just because it doesn't fit into one of those definitions doesn't seem helpful. Such restrictions are not the route to service utopia. I understand that this is in part determined by some of the security issues, but I see this as a defect in the security, rather than anything fundamentally wrong. (In fact, in the case of VoIP I see very little benefit in securing the SDP as there are so many additional ways that you can corrupt the media that it really doesn't buy you much. This may not be the case for instant messaging.) I would also warn against forcing users to choose between security and connectivity, as connectivity will almost always win. After all, the PSTN has very little authentication and for most of the people, most of the time it works just fine. (Call tracing is about the only thing from a PSTN style service that authentication would help with. But you'd just drop your authentication if you were doing malicious calls. Another observation is that e-mail spoofing is dead easy, but it doesn't seem to be a major problem even though it has been around for years.) So maybe the spec should say 'SHOULD NOT change the payload if it's secured in some way'. 'SHOULD NOT' is sufficient because the UAS is the one that makes the final decision whether to accept the modified payload or not. (I would imagine that most of the time it doesn't even check - either because the user doesn't care, or due to PKI and shared secret problems that have been mentioned in the e-mail exchanges.) Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.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 daemon@ns.ietf.org Fri Feb 22 05:10:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25951 for ; Fri, 22 Feb 2002 05:10:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA10903 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 05:11:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07574; Fri, 22 Feb 2002 04:29:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07548 for ; Fri, 22 Feb 2002 04:29:27 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24981 for ; Fri, 22 Feb 2002 04:25:52 -0500 (EST) Received: (qmail 15029 invoked from network); 22 Feb 2002 09:28:56 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 22 Feb 2002 09:28:56 -0000 Received: from stake.com (unknown [10.50.1.35]) by cam-relay.atstake.com (Postfix) with SMTP id 1AB3722817; Fri, 22 Feb 2002 04:25:21 -0500 (EST) Message-ID: <3C760E85.6010308@stake.com> Date: Fri, 22 Feb 2002 09:25:25 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christian Huitema Cc: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-rfc2543bis-07.9 now available References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian, Did my 3 sentence post had the words "if the DNS server is poisoned" in it?... and by the way there are some who only compromise the name-to-IP venue and forget the IP-to-name, but this is another thing (and I bet it does not interest you). Next time you jump and scream FIRE FIRE just read it slowly. What I was referring to is another check that one can do, and it is extremely helpful if there is a host in the same domain which pertains to be a SIP entity (with the current certificate and all) or any other entity that you relay upon its certificate. It is clear that if the DNS is poisoned this is game-over. Ofir Christian Huitema wrote: > Use reverse DNS lookup as a protection against DNS poisoning? You must > be kidding! > > -- Christian Huitema > > >>From: Ofir Arkin [mailto:ofir@stake.com] >> >>What about adding a Reverse DNS lookup so we can, not only, check the >>certificate domain against the domain we contacted but also the IP >>Source Address of the reply if it is corresponding with the domain >> > name > >>as well... >> >>Ofir >> >>Christian Huitema wrote: >> >> >>>In the Security section, the draft identifies the threat of >>>"Impersonating a Server" (26.1.2). I would suggest that we document >>> > a > >>>variant of this threat, DNS poisoning, and add text such as: >>> >>> A possible way to impersonate a server is to use attacks against >>> > the > >>> Domain Name System, such as "DNS poisoning." As explained in the >>>section >>> 4, Overview of Operation, we expect that a particular type of DNS >>>queries >>> can be used to find the SIP server that serves a specific domain; >>> attacking the DNS can induce a proxy or a UA to route the message >>>towards >>> an impersonating server. >>> >>>The threat to the UA is addressed in section 26.3.2.1 by stating >>> > that > >>>the certificate must "correspond with the domain in which the UA >>> > intends > >>>to register", which is explained next as "must identify a host >>> > within > >>>the atlanta.com domain (such as sip.atlanta.com)." This is >>> > reasonable, > >>>but weak. With this rule, any host in the atlanta.com domain could >>> > fake > >>>a registration server; there is no way for the domain manager to >>> > hand > >>>out certificates that specifically designate the recipient as "an >>>authorized SIP server for the domain." An easily implemented >>> > protection > >>>would be a host name convention, such as having a certificate that >>>actually identifies the host as "sip.". >>> >>>A similar text is used in section 26.3.2.2, Interdomain Requests: >>> > "The > >>>atlanta.com proxy server, for example, SHOULD verify at this stage >>> > that > >>>the certificate received from the remote side corresponds with the >>>biloxi.com domain." This is again a bit underspecified, since it >>> > would > >>>potentially allow any compromised host in the "biloxi.com" domain to >>>impersonate a server. Again, a formal host name convention would be >>> > more > >>>effective. >>> >>>-- Christian Huitema >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >>> >> >>-- >>Ofir Arkin >>Managing Security Architect >>@stake, Limited. >>http://www.atstake.com >>email: >>ofir@stake.com >>Tel: >>+44 (0) 207 495 7002 >>Fax: >>+44 (0) 207 495 7062 >>Mobile: +44 (0) 779 630 8632 >> >>----------------------------- >>The information transmitted is intended only for the person or entity >> > to > >>which it is addressed and may contain confidential and/or privileged >>material. Any review, re transmission, 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 any computer. >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP 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 > -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Feb 22 05:53:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26480 for ; Fri, 22 Feb 2002 05:53:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12958 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 05:53:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10949; Fri, 22 Feb 2002 05:11:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10917 for ; Fri, 22 Feb 2002 05:11:21 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25969 for ; Fri, 22 Feb 2002 05:11:17 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1MAAmZc014138 for ; Fri, 22 Feb 2002 11:10:48 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1MAAmr6011563 for ; Fri, 22 Feb 2002 12:10:48 +0200 (EET) Message-ID: <3C761961.8C5E7408@lmf.ericsson.se> Date: Fri, 22 Feb 2002 12:11:45 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Bis-8: To tag question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Chapter 8.2.6.2 says that a server MUST use the same To tag in all responses, both provisional and final. So, if a UAS eg sends 18x with a To tag, and then 4xx, my understanding is that the To tag must be in BOTH of those responses. However, chapter 17.2.3 says: "The usage of the tag in the To header field helps disambiguate ACK for 2xx from ACK for other responses at a proxy, which may have forwarded both responses (which can occur in unusual conditions)." Is this really true? IF the non-2xx responses had a To tag, shouldn't the ACK for that response use the same To tag? In that case a server can't use the To tag in the ACK to check if the ACK was for a 2xx-, or non-2xx-,response. Is there a bug, or have I missunderstood something? Regards, Christer Holmberg Ericsson 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 daemon@ns.ietf.org Fri Feb 22 05:54:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26501 for ; Fri, 22 Feb 2002 05:54:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA13036 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 05:54:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11414; Fri, 22 Feb 2002 05:21:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11382 for ; Fri, 22 Feb 2002 05:21:02 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26111 for ; Fri, 22 Feb 2002 05:20:56 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1MAJmB15333; Fri, 22 Feb 2002 11:19:48 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1MAJlr6012105; Fri, 22 Feb 2002 12:19:47 +0200 (EET) Message-ID: <3C761B7C.E910E53@lmf.ericsson.se> Date: Fri, 22 Feb 2002 12:20:44 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete Cordell CC: Bob Penfield , sip@ietf.org, Jonathan Rosenberg Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body References: <000f01c1bae9$2d7d0980$2300000a@acmepacket.com> <002701c1bb85$081198e0$0200000a@tkw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, It's not too long since we had this same discussion. Then it was realized, that if a proxy is allowed to modify the message body, one could argue it should also be allowed to modify one or more of the Content-Xxx headers (in most cases Content-Lenght, but maybe also others), maybe encode/decode the message body etc etc etc. It was then decided that the spec should NOT define such behaviour for a basic proxy, and that IF a proxy wants to do something like that it will have some kind of B2BUA behaviour (nobody says you have to implement "full" B2BUA behaviour). Regards, Christer Holmberg Ericsson Finland Pete Cordell wrote: > ----- Original Message ----- > From: Bob Penfield > > > Lines 2622-2623 say that "The proxy MUST NOT add to, modify, or remove the > > message body". Does this mean that all existing Firewall Control Proxies > > which update the SDP (like example 3.1.5 in draft-ietf-call-flows-05.txt) > > non-compliant? I guess they will all have to be turned into B2BUAs. > > I too think that this is overly restrictive, and may come to bite us in the > future. > > There are many things that you can do, firewall control for one, that > require you to change the SDP, but don't necessitate a full back to back UAC > / UAS. > > For example, a proxy in an enterprise context might want to remove high > bandwidth codecs from the SDP so that it doesn't use too much bandwidth on > the access link. This seems quite legitimate policy, and helpful. I'm sure > that there are many other things that will become attractive in the future > that we can't think of at the moment. > > In fact, from simple proxy to full B2BUA there is a whole spectrum of > devices, of which they are only two points. Indeed, at some phases > intermediaries may act as stateless proxies, and other phases they maybe > full B2BUAs. Making a device non-compliant just because it doesn't fit into > one of those definitions doesn't seem helpful. Such restrictions are not > the route to service utopia. > > I understand that this is in part determined by some of the security issues, > but I see this as a defect in the security, rather than anything > fundamentally wrong. (In fact, in the case of VoIP I see very little > benefit in securing the SDP as there are so many additional ways that you > can corrupt the media that it really doesn't buy you much. This may not be > the case for instant messaging.) > > I would also warn against forcing users to choose between security and > connectivity, as connectivity will almost always win. After all, the PSTN > has very little authentication and for most of the people, most of the time > it works just fine. (Call tracing is about the only thing from a PSTN style > service that authentication would help with. But you'd just drop your > authentication if you were doing malicious calls. Another observation is > that e-mail spoofing is dead easy, but it doesn't seem to be a major problem > even though it has been around for years.) > > So maybe the spec should say 'SHOULD NOT change the payload if it's secured > in some way'. 'SHOULD NOT' is sufficient because the UAS is the one that > makes the final decision whether to accept the modified payload or not. (I > would imagine that most of the time it doesn't even check - either because > the user doesn't care, or due to PKI and shared secret problems that have > been mentioned in the e-mail exchanges.) > > Pete. > > ============================================= > Pete Cordell > Tech-Know-Ware > pete@tech-know-ware.com > +44 1473 635863 > ============================================= > > > cheers, > > (-:bob > > > > Robert F. Penfield > > Chief Software Architect > > Acme Packet, Inc. > > 130 New Boston Street > > Woburn, MA 01801 > > bpenfield@acmepacket.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 daemon@optimus.ietf.org Fri Feb 22 06:34:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27755 for ; Fri, 22 Feb 2002 06:34:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA15457 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 06:34:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13901; Fri, 22 Feb 2002 06:07:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13870 for ; Fri, 22 Feb 2002 06:07:28 -0500 (EST) Received: from avgw.vxserver.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26685 for ; Fri, 22 Feb 2002 06:07:24 -0500 (EST) Received: from ridgeway.ridgeway-sys.com ([10.1.1.1]) by avgw.vxserver.com (NAVGW 2.5.1.16) with SMTP id M2002022211033808653 for ; Fri, 22 Feb 2002 11:03:38 GMT Received: by ThisAddressDoesNotExist with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 11:06:56 -0000 Message-ID: <00533D13955AD411AF3800A0C9B4263994D71B@ThisAddressDoesNotExist> From: Phil Reynolds To: "'sip@ietf.org'" Date: Fri, 22 Feb 2002 11:06:50 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BB91.072D5CF0" Subject: [Sip] bis-80 security requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BB91.072D5CF0 Content-Type: text/plain; charset="ISO-8859-1" pdf line 5965: Proxy servers, redirect servers, and registrars MUST implement TLS Am I missing something or does this break all existing SIP network-elements? --------------------------------------------------------- Phil Reynolds Ridgeway Systems and Software Tel: +44 118 938 1211 Fax: +44 118 935 4444 mailto:preynolds@ridgewaysystems.com http://www.ridgewaysystems.com ------_=_NextPart_001_01C1BB91.072D5CF0 Content-Type: text/html; charset="ISO-8859-1" bis-80 security requirements

pdf line 5965: Proxy servers, redirect servers, and registrars MUST implement TLS

Am I missing something or does this break all existing SIP network-elements?

---------------------------------------------------------
Phil Reynolds
Ridgeway Systems and Software
Tel: +44 118 938 1211
Fax: +44 118 935 4444
mailto:preynolds@ridgewaysystems.com
http://www.ridgewaysystems.com

------_=_NextPart_001_01C1BB91.072D5CF0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 22 06:43:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28000 for ; Fri, 22 Feb 2002 06:43:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA15937 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 06:43:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14467; Fri, 22 Feb 2002 06:22:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14433 for ; Fri, 22 Feb 2002 06:22:25 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27395; Fri, 22 Feb 2002 06:22:22 -0500 (EST) Message-Id: <200202221122.GAA27395@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 22 Feb 2002 06:22:22 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-100rel-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : Reliability of Provisional Responses in SIP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-100rel-05.txt Pages : 14 Date : 21-Feb-02 This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag org.ietf.sip.100rel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-100rel-05.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-100rel-05.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020221155050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-100rel-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-100rel-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020221155050.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 22 06:43:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28017 for ; Fri, 22 Feb 2002 06:43:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA15953 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 06:43:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14503; Fri, 22 Feb 2002 06:22:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14469 for ; Fri, 22 Feb 2002 06:22:29 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27411; Fri, 22 Feb 2002 06:22:27 -0500 (EST) Message-Id: <200202221122.GAA27411@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 22 Feb 2002 06:22:27 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-srv-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : SIP: Locating SIP Servers Author(s) : H. Schulzrinne, J. Rosenberg Filename : draft-ietf-sip-srv-05.txt Pages : 18 Date : 21-Feb-02 The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP URI into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-srv-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-srv-05.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-srv-05.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020221155100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-srv-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-srv-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020221155100.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 22 06:48:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28149 for ; Fri, 22 Feb 2002 06:48:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA16093 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 06:48:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14643; Fri, 22 Feb 2002 06:22:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14509 for ; Fri, 22 Feb 2002 06:22:34 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27427; Fri, 22 Feb 2002 06:22:32 -0500 (EST) Message-Id: <200202221122.GAA27427@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 22 Feb 2002 06:22:31 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-rfc2543bis-08.txt,.ps,.pdf Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart 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 : SIP: Session Initiation Protocol Author(s) : J. Rosenberg, H. Schulzrinne et al. Filename : draft-ietf-sip-rfc2543bis-08.txt,.ps,.pdf Pages : 278 Date : 21-Feb-02 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution and multimedia conferences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2543bis-08.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-rfc2543bis-08.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020221155111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc2543bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc2543bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020221155111.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 22 07:27:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29372 for ; Fri, 22 Feb 2002 07:27:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18407 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 07:27:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16526; Fri, 22 Feb 2002 06:58:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16494 for ; Fri, 22 Feb 2002 06:58:34 -0500 (EST) Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28418 for ; Fri, 22 Feb 2002 06:58:31 -0500 (EST) Received: from host213-122-76-136.in-addr.btopenworld.com ([213.122.76.136] helo=tkw) by tungsten.btinternet.com with smtp (Exim 3.22 #8) id 16eELN-0002UW-00; Fri, 22 Feb 2002 11:58:29 +0000 Message-ID: <001301c1bb98$4be7f380$0200000a@tkw> From: "Pete Cordell" To: "Christer Holmberg" Cc: "Bob Penfield" , , "Jonathan Rosenberg" References: <000f01c1bae9$2d7d0980$2300000a@acmepacket.com> <002701c1bb85$081198e0$0200000a@tkw> <3C761B7C.E910E53@lmf.ericsson.se> Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body Date: Fri, 22 Feb 2002 11:58:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer, I did see that conversation, but it just seemed to fizzle out (maybe I didn't see the end). I quite liked the conclusion where you could change Content-Length (amr), but none of the others. (But then that suited my service today. Generally it's potential limiting to decide what we can and can not change today.) If it comes down to what's in a name, then I don't really see the point. If I'm non-compliant if I call it a proxy, and compliant if I call it a B2BUA, then it seems a bit odd. And I would say that the spec does (try to) stop me building something that is not a proxy and not a full B2BUA. According to the spec I either have to be a proxy in which case I can not change the SDP, or I can be a full back to back UAS / UAC - (there's no partial B2BUA and the definition of B2BUA is quite specific about what it is.). For example, a proxy that wants to limit the bandwidth used on a certain path can operate purely statelessly (and pretty dumbly), but it is not a proxy (by the current definition) nor is it a B2BUA because it doesn't need to maintain dialog state. We could define some more proxy types (such as stateless, transaction stateful, dialog stateful, body modifying stateful), but I don't really think that buys us anything. At the end of the day the body is no different from any of the other headers, and the test of whether it can be modified by a proxy should be similar - if it doesn't break the protocol, and it might be useful, then allow it. On a philosophical note, it seems bad to come up with a protocol that is not NAT or firewall friendly, but even worse to then try and prevent anybody from trying to do something about it (including ALGs in NATs, Midcom, and a number of other schemes you may care to name!) Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Christer Holmberg To: Pete Cordell Cc: Bob Penfield ; ; Jonathan Rosenberg Sent: 22 February 2002 10:20 Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body > > Hi, > > It's not too long since we had this same discussion. > > Then it was realized, that if a proxy is allowed to modify the message body, one > could argue it should also be allowed to modify one or more of the Content-Xxx > headers (in most cases Content-Lenght, but maybe also others), maybe > encode/decode the message body etc etc etc. It was then decided that the spec > should NOT define such behaviour for a basic proxy, and that IF a proxy wants to > do something like that it will have some kind of B2BUA behaviour (nobody says > you have to implement "full" B2BUA behaviour). > > Regards, > > Christer Holmberg > Ericsson Finland > > > Pete Cordell wrote: > > > ----- Original Message ----- > > From: Bob Penfield > > > > > Lines 2622-2623 say that "The proxy MUST NOT add to, modify, or remove the > > > message body". Does this mean that all existing Firewall Control Proxies > > > which update the SDP (like example 3.1.5 in draft-ietf-call-flows-05.txt) > > > non-compliant? I guess they will all have to be turned into B2BUAs. > > > > I too think that this is overly restrictive, and may come to bite us in the > > future. > > > > There are many things that you can do, firewall control for one, that > > require you to change the SDP, but don't necessitate a full back to back UAC > > / UAS. > > > > For example, a proxy in an enterprise context might want to remove high > > bandwidth codecs from the SDP so that it doesn't use too much bandwidth on > > the access link. This seems quite legitimate policy, and helpful. I'm sure > > that there are many other things that will become attractive in the future > > that we can't think of at the moment. > > > > In fact, from simple proxy to full B2BUA there is a whole spectrum of > > devices, of which they are only two points. Indeed, at some phases > > intermediaries may act as stateless proxies, and other phases they maybe > > full B2BUAs. Making a device non-compliant just because it doesn't fit into > > one of those definitions doesn't seem helpful. Such restrictions are not > > the route to service utopia. > > > > I understand that this is in part determined by some of the security issues, > > but I see this as a defect in the security, rather than anything > > fundamentally wrong. (In fact, in the case of VoIP I see very little > > benefit in securing the SDP as there are so many additional ways that you > > can corrupt the media that it really doesn't buy you much. This may not be > > the case for instant messaging.) > > > > I would also warn against forcing users to choose between security and > > connectivity, as connectivity will almost always win. After all, the PSTN > > has very little authentication and for most of the people, most of the time > > it works just fine. (Call tracing is about the only thing from a PSTN style > > service that authentication would help with. But you'd just drop your > > authentication if you were doing malicious calls. Another observation is > > that e-mail spoofing is dead easy, but it doesn't seem to be a major problem > > even though it has been around for years.) > > > > So maybe the spec should say 'SHOULD NOT change the payload if it's secured > > in some way'. 'SHOULD NOT' is sufficient because the UAS is the one that > > makes the final decision whether to accept the modified payload or not. (I > > would imagine that most of the time it doesn't even check - either because > > the user doesn't care, or due to PKI and shared secret problems that have > > been mentioned in the e-mail exchanges.) > > > > Pete. > > > > ============================================= > > Pete Cordell > > Tech-Know-Ware > > pete@tech-know-ware.com > > +44 1473 635863 > > ============================================= > > > > > cheers, > > > (-:bob > > > > > > Robert F. Penfield > > > Chief Software Architect > > > Acme Packet, Inc. > > > 130 New Boston Street > > > Woburn, MA 01801 > > > bpenfield@acmepacket.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 daemon@optimus.ietf.org Fri Feb 22 07:53:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00020 for ; Fri, 22 Feb 2002 07:53:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA19697 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 07:53:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17992; Fri, 22 Feb 2002 07:20:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17961 for ; Fri, 22 Feb 2002 07:20:03 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29159 for ; Fri, 22 Feb 2002 07:19:59 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1MCIcZc006409; Fri, 22 Feb 2002 13:18:38 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1MCIbbB019276; Fri, 22 Feb 2002 14:18:38 +0200 (EET) Message-ID: <3C763757.D070A0C3@lmf.ericsson.se> Date: Fri, 22 Feb 2002 14:19:35 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete Cordell CC: Bob Penfield , sip@ietf.org, Jonathan Rosenberg Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body References: <000f01c1bae9$2d7d0980$2300000a@acmepacket.com> <002701c1bb85$081198e0$0200000a@tkw> <3C761B7C.E910E53@lmf.ericsson.se> <001301c1bb98$4be7f380$0200000a@tkw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Pete, PERSONALLY (I am not sure it's correct from a standard point of view) I would say that even if the basic spec doesn't allow a proxy to modify the SDP, you can always define a "SIP proxy extension" (similar to any other SIP extension) defining a feature/functionality which does allow modification of the SDP - and you could still call your node a proxy ("a proxy supporting the SDP modification extension", or something...). Regards, Christer Holmberg Ericsson Finland Pete Cordell wrote: > Christer, > > I did see that conversation, but it just seemed to fizzle out (maybe I > didn't see the end). > > I quite liked the conclusion where you could change Content-Length (amr), > but none of the others. (But then that suited my service today. Generally > it's potential limiting to decide what we can and can not change today.) > > If it comes down to what's in a name, then I don't really see the point. If > I'm non-compliant if I call it a proxy, and compliant if I call it a B2BUA, > then it seems a bit odd. > > And I would say that the spec does (try to) stop me building something that > is not a proxy and not a full B2BUA. According to the spec I either have to > be a proxy in which case I can not change the SDP, or I can be a full back > to back UAS / UAC - (there's no partial B2BUA and the definition of B2BUA is > quite specific about what it is.). > > For example, a proxy that wants to limit the bandwidth used on a certain > path can operate purely statelessly (and pretty dumbly), but it is not a > proxy (by the current definition) nor is it a B2BUA because it doesn't need > to maintain dialog state. > > We could define some more proxy types (such as stateless, transaction > stateful, dialog stateful, body modifying stateful), but I don't really > think that buys us anything. > > At the end of the day the body is no different from any of the other > headers, and the test of whether it can be modified by a proxy should be > similar - if it doesn't break the protocol, and it might be useful, then > allow it. > > On a philosophical note, it seems bad to come up with a protocol that is not > NAT or firewall friendly, but even worse to then try and prevent anybody > from trying to do something about it (including ALGs in NATs, Midcom, and a > number of other schemes you may care to name!) > > Pete. > > ============================================= > Pete Cordell > Tech-Know-Ware > pete@tech-know-ware.com > +44 1473 635863 > ============================================= > > ----- Original Message ----- > From: Christer Holmberg > To: Pete Cordell > Cc: Bob Penfield ; ; Jonathan > Rosenberg > Sent: 22 February 2002 10:20 > Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body > > > > > Hi, > > > > It's not too long since we had this same discussion. > > > > Then it was realized, that if a proxy is allowed to modify the message > body, one > > could argue it should also be allowed to modify one or more of the > Content-Xxx > > headers (in most cases Content-Lenght, but maybe also others), maybe > > encode/decode the message body etc etc etc. It was then decided that the > spec > > should NOT define such behaviour for a basic proxy, and that IF a proxy > wants to > > do something like that it will have some kind of B2BUA behaviour (nobody > says > > you have to implement "full" B2BUA behaviour). > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > Pete Cordell wrote: > > > > > ----- Original Message ----- > > > From: Bob Penfield > > > > > > > Lines 2622-2623 say that "The proxy MUST NOT add to, modify, or remove > the > > > > message body". Does this mean that all existing Firewall Control > Proxies > > > > which update the SDP (like example 3.1.5 in > draft-ietf-call-flows-05.txt) > > > > non-compliant? I guess they will all have to be turned into B2BUAs. > > > > > > I too think that this is overly restrictive, and may come to bite us in > the > > > future. > > > > > > There are many things that you can do, firewall control for one, that > > > require you to change the SDP, but don't necessitate a full back to back > UAC > > > / UAS. > > > > > > For example, a proxy in an enterprise context might want to remove high > > > bandwidth codecs from the SDP so that it doesn't use too much bandwidth > on > > > the access link. This seems quite legitimate policy, and helpful. I'm > sure > > > that there are many other things that will become attractive in the > future > > > that we can't think of at the moment. > > > > > > In fact, from simple proxy to full B2BUA there is a whole spectrum of > > > devices, of which they are only two points. Indeed, at some phases > > > intermediaries may act as stateless proxies, and other phases they maybe > > > full B2BUAs. Making a device non-compliant just because it doesn't fit > into > > > one of those definitions doesn't seem helpful. Such restrictions are > not > > > the route to service utopia. > > > > > > I understand that this is in part determined by some of the security > issues, > > > but I see this as a defect in the security, rather than anything > > > fundamentally wrong. (In fact, in the case of VoIP I see very little > > > benefit in securing the SDP as there are so many additional ways that > you > > > can corrupt the media that it really doesn't buy you much. This may not > be > > > the case for instant messaging.) > > > > > > I would also warn against forcing users to choose between security and > > > connectivity, as connectivity will almost always win. After all, the > PSTN > > > has very little authentication and for most of the people, most of the > time > > > it works just fine. (Call tracing is about the only thing from a PSTN > style > > > service that authentication would help with. But you'd just drop your > > > authentication if you were doing malicious calls. Another observation > is > > > that e-mail spoofing is dead easy, but it doesn't seem to be a major > problem > > > even though it has been around for years.) > > > > > > So maybe the spec should say 'SHOULD NOT change the payload if it's > secured > > > in some way'. 'SHOULD NOT' is sufficient because the UAS is the one > that > > > makes the final decision whether to accept the modified payload or not. > (I > > > would imagine that most of the time it doesn't even check - either > because > > > the user doesn't care, or due to PKI and shared secret problems that > have > > > been mentioned in the e-mail exchanges.) > > > > > > Pete. > > > > > > ============================================= > > > Pete Cordell > > > Tech-Know-Ware > > > pete@tech-know-ware.com > > > +44 1473 635863 > > > ============================================= > > > > > > > cheers, > > > > (-:bob > > > > > > > > Robert F. Penfield > > > > Chief Software Architect > > > > Acme Packet, Inc. > > > > 130 New Boston Street > > > > Woburn, MA 01801 > > > > bpenfield@acmepacket.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 daemon@optimus.ietf.org Fri Feb 22 08:44:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01706 for ; Fri, 22 Feb 2002 08:44:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22670 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 08:44:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20947; Fri, 22 Feb 2002 08:12:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20897 for ; Fri, 22 Feb 2002 08:12:43 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00627 for ; Fri, 22 Feb 2002 08:12:40 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1MDBdS17235; Fri, 22 Feb 2002 07:11:39 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1MDBcs29983; Fri, 22 Feb 2002 07:11:39 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g1MDBbE29129; Fri, 22 Feb 2002 08:11:38 -0500 (EST) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 08:11:37 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C03746C@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "Christer Holmberg (LMF)" , Pete Cordell Cc: Bob Penfield , sip@ietf.org, Jonathan Rosenberg Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y Date: Fri, 22 Feb 2002 08:11:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org There was the definition of "transperent" B2BUA to allow a proxy to initiate things it is not supposed to do, such as a BYE to terminate a session (in case of prepaid) or deregistration (if the network operator decides to kick somebody out) So while the spec. says as a *pure* proxy you cannot modify SDP, I guess most of us will do B2BUA, as the way out. Regards George Foti Ericsson Canada > -----Original Message----- > From: Christer Holmberg (LMF) > Sent: Friday, February 22, 2002 7:20 AM > To: Pete Cordell > Cc: Bob Penfield; sip@ietf.org; Jonathan Rosenberg > Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message > body > > > > Hi Pete, > > PERSONALLY (I am not sure it's correct from a standard point > of view) I would > say that even if the basic spec doesn't allow a proxy to > modify the SDP, you can > always define a "SIP proxy extension" (similar to any other > SIP extension) > defining a feature/functionality which does allow > modification of the SDP - and > you could still call your node a proxy ("a proxy supporting > the SDP modification > extension", or something...). > > Regards, > > Christer Holmberg > Ericsson Finland > > > > Pete Cordell wrote: > > > Christer, > > > > I did see that conversation, but it just seemed to fizzle > out (maybe I > > didn't see the end). > > > > I quite liked the conclusion where you could change > Content-Length (amr), > > but none of the others. (But then that suited my service > today. Generally > > it's potential limiting to decide what we can and can not > change today.) > > > > If it comes down to what's in a name, then I don't really > see the point. If > > I'm non-compliant if I call it a proxy, and compliant if I > call it a B2BUA, > > then it seems a bit odd. > > > > And I would say that the spec does (try to) stop me > building something that > > is not a proxy and not a full B2BUA. According to the spec > I either have to > > be a proxy in which case I can not change the SDP, or I can > be a full back > > to back UAS / UAC - (there's no partial B2BUA and the > definition of B2BUA is > > quite specific about what it is.). > > > > For example, a proxy that wants to limit the bandwidth used > on a certain > > path can operate purely statelessly (and pretty dumbly), > but it is not a > > proxy (by the current definition) nor is it a B2BUA because > it doesn't need > > to maintain dialog state. > > > > We could define some more proxy types (such as stateless, > transaction > > stateful, dialog stateful, body modifying stateful), but I > don't really > > think that buys us anything. > > > > At the end of the day the body is no different from any of the other > > headers, and the test of whether it can be modified by a > proxy should be > > similar - if it doesn't break the protocol, and it might be > useful, then > > allow it. > > > > On a philosophical note, it seems bad to come up with a > protocol that is not > > NAT or firewall friendly, but even worse to then try and > prevent anybody > > from trying to do something about it (including ALGs in > NATs, Midcom, and a > > number of other schemes you may care to name!) > > > > Pete. > > > > ============================================= > > Pete Cordell > > Tech-Know-Ware > > pete@tech-know-ware.com > > +44 1473 635863 > > ============================================= > > > > ----- Original Message ----- > > From: Christer Holmberg > > To: Pete Cordell > > Cc: Bob Penfield ; > ; Jonathan > > Rosenberg > > Sent: 22 February 2002 10:20 > > Subject: Re: [Sip] bis-07.9: proxies are not allowed to > modify message body > > > > > > > > Hi, > > > > > > It's not too long since we had this same discussion. > > > > > > Then it was realized, that if a proxy is allowed to > modify the message > > body, one > > > could argue it should also be allowed to modify one or more of the > > Content-Xxx > > > headers (in most cases Content-Lenght, but maybe also > others), maybe > > > encode/decode the message body etc etc etc. It was then > decided that the > > spec > > > should NOT define such behaviour for a basic proxy, and > that IF a proxy > > wants to > > > do something like that it will have some kind of B2BUA > behaviour (nobody > > says > > > you have to implement "full" B2BUA behaviour). > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > Pete Cordell wrote: > > > > > > > ----- Original Message ----- > > > > From: Bob Penfield > > > > > > > > > Lines 2622-2623 say that "The proxy MUST NOT add to, > modify, or remove > > the > > > > > message body". Does this mean that all existing > Firewall Control > > Proxies > > > > > which update the SDP (like example 3.1.5 in > > draft-ietf-call-flows-05.txt) > > > > > non-compliant? I guess they will all have to be > turned into B2BUAs. > > > > > > > > I too think that this is overly restrictive, and may > come to bite us in > > the > > > > future. > > > > > > > > There are many things that you can do, firewall control > for one, that > > > > require you to change the SDP, but don't necessitate a > full back to back > > UAC > > > > / UAS. > > > > > > > > For example, a proxy in an enterprise context might > want to remove high > > > > bandwidth codecs from the SDP so that it doesn't use > too much bandwidth > > on > > > > the access link. This seems quite legitimate policy, > and helpful. I'm > > sure > > > > that there are many other things that will become > attractive in the > > future > > > > that we can't think of at the moment. > > > > > > > > In fact, from simple proxy to full B2BUA there is a > whole spectrum of > > > > devices, of which they are only two points. Indeed, at > some phases > > > > intermediaries may act as stateless proxies, and other > phases they maybe > > > > full B2BUAs. Making a device non-compliant just > because it doesn't fit > > into > > > > one of those definitions doesn't seem helpful. Such > restrictions are > > not > > > > the route to service utopia. > > > > > > > > I understand that this is in part determined by some of > the security > > issues, > > > > but I see this as a defect in the security, rather than anything > > > > fundamentally wrong. (In fact, in the case of VoIP I > see very little > > > > benefit in securing the SDP as there are so many > additional ways that > > you > > > > can corrupt the media that it really doesn't buy you > much. This may not > > be > > > > the case for instant messaging.) > > > > > > > > I would also warn against forcing users to choose > between security and > > > > connectivity, as connectivity will almost always win. > After all, the > > PSTN > > > > has very little authentication and for most of the > people, most of the > > time > > > > it works just fine. (Call tracing is about the only > thing from a PSTN > > style > > > > service that authentication would help with. But you'd > just drop your > > > > authentication if you were doing malicious calls. > Another observation > > is > > > > that e-mail spoofing is dead easy, but it doesn't seem > to be a major > > problem > > > > even though it has been around for years.) > > > > > > > > So maybe the spec should say 'SHOULD NOT change the > payload if it's > > secured > > > > in some way'. 'SHOULD NOT' is sufficient because the > UAS is the one > > that > > > > makes the final decision whether to accept the modified > payload or not. > > (I > > > > would imagine that most of the time it doesn't even > check - either > > because > > > > the user doesn't care, or due to PKI and shared secret > problems that > > have > > > > been mentioned in the e-mail exchanges.) > > > > > > > > Pete. > > > > > > > > ============================================= > > > > Pete Cordell > > > > Tech-Know-Ware > > > > pete@tech-know-ware.com > > > > +44 1473 635863 > > > > ============================================= > > > > > > > > > cheers, > > > > > (-:bob > > > > > > > > > > Robert F. Penfield > > > > > Chief Software Architect > > > > > Acme Packet, Inc. > > > > > 130 New Boston Street > > > > > Woburn, MA 01801 > > > > > bpenfield@acmepacket.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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 22 08:56:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02017 for ; Fri, 22 Feb 2002 08:56:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA23009 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 08:56:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22242; Fri, 22 Feb 2002 08:33:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22213 for ; Fri, 22 Feb 2002 08:33:26 -0500 (EST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01422 for ; Fri, 22 Feb 2002 08:33:05 -0500 (EST) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g1MDWVW07745 for ; Fri, 22 Feb 2002 08:32:37 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029) id 3C069505014A1217; Fri, 22 Feb 2002 08:30:49 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y Date: Fri, 22 Feb 2002 08:31:55 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F901727107@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] bis-07.9: proxies are not allowed to modify message bod y X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcG7o3yt1driQExTQziKaJKfN4yYQgAAWHfA From: "Roy, Radhika R, ALASO" To: "George Foti (LMC)" , "Christer Holmberg (LMF)" , "Pete Cordell" Cc: "Bob Penfield" , , "Jonathan Rosenberg" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA22214 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Inline [RRR] -----Original Message----- From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] Sent: Friday, February 22, 2002 8:12 AM To: Christer Holmberg (LMF); Pete Cordell Cc: Bob Penfield; sip@ietf.org; Jonathan Rosenberg Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y There was the definition of "transperent" B2BUA to allow a proxy to initiate things it is not supposed to do, such as a BYE to terminate a session (in case of prepaid) or deregistration (if the network operator decides to kick somebody out) So while the spec. says as a *pure* proxy you cannot modify SDP, I guess most of us will do B2BUA, as the way out. [RRR] Is not better to clarify in the spec: "Pure" Proxy vs. "Transparent" B2BUA Proxy? Regards George Foti Ericsson Canada _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 22 09:09:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02499 for ; Fri, 22 Feb 2002 09:09:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA23971 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 09:09:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22446; Fri, 22 Feb 2002 08:40:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22415 for ; Fri, 22 Feb 2002 08:39:58 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01629 for ; Fri, 22 Feb 2002 08:39:54 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1MDdqh16139; Fri, 22 Feb 2002 07:39:52 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1MDdph08504; Fri, 22 Feb 2002 07:39:52 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g1MDdpE00136; Fri, 22 Feb 2002 08:39:51 -0500 (EST) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 08:39:51 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C03746D@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Roy, Radhika R, ALASO'" , "Christer Holmberg (LMF)" , Pete Cordell Cc: Bob Penfield , sip@ietf.org, Jonathan Rosenberg Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y Date: Fri, 22 Feb 2002 08:39:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I guess, its up to the editors to consider including such a definition. But its already in people's mind, may be thats why it is not explicitly defined rgds/gf > -----Original Message----- > From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] > Sent: Friday, February 22, 2002 8:32 AM > To: George Foti (LMC); Christer Holmberg (LMF); Pete Cordell > Cc: Bob Penfield; sip@ietf.org; Jonathan Rosenberg > Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message > bod y > > > Inline [RRR] > > -----Original Message----- > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > Sent: Friday, February 22, 2002 8:12 AM > To: Christer Holmberg (LMF); Pete Cordell > Cc: Bob Penfield; sip@ietf.org; Jonathan Rosenberg > Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message > bod y > > > There was the definition of "transperent" B2BUA to allow a > proxy to initiate > things it is not supposed to do, such as a BYE to terminate > a session (in > case of prepaid) or deregistration (if the network operator > decides to kick > somebody out) > > So while the spec. says as a *pure* proxy you cannot modify > SDP, I guess > most of us will do B2BUA, as the way out. > > [RRR] Is not better to clarify in the spec: "Pure" Proxy vs. > "Transparent" B2BUA Proxy? > > Regards > > George Foti > Ericsson Canada > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 22 09:20:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02982 for ; Fri, 22 Feb 2002 09:20:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24303 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 09:20:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22653; Fri, 22 Feb 2002 08:43:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22550 for ; Fri, 22 Feb 2002 08:43:40 -0500 (EST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01689 for ; Fri, 22 Feb 2002 08:43:36 -0500 (EST) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g1MDh4n02135 for ; Fri, 22 Feb 2002 08:43:06 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029) id 3C069505014A1EF1; Fri, 22 Feb 2002 08:41:41 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] multicast restricted to ttl=1 Date: Fri, 22 Feb 2002 08:42:47 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F9017B1C24@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Sip] multicast restricted to ttl=1 Thread-Index: AcG7WBdwDNRLI4vIS/+GNun+V803IwATh/XQ From: "Roy, Radhika R, ALASO" To: "David R. Oran" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA22551 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Inline [RRR] -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Thursday, February 21, 2002 11:06 PM To: sip@ietf.org Subject: RE: [Sip] multicast restricted to ttl=1 > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Jonathan Rosenberg > Sent: Sunday, February 17, 2002 2:09 PM > To: sip@ietf.org > Subject: [Sip] multicast restricted to ttl=1 > > > Folks, > > As a result of IESG review, there were concerns about the > multicast usage of SIP. In particular, for the things we were > using it for, it was felt that a limitation of scope to ttl=1 > was needed. As such, I have modified the transport chapter to > reflect a SHOULD level usage of ttl=1. > Well, according to bis-08, multicast can be used to find a registrar if you don't have a DNS-discoverable proxy to route your register to. If that's the purpose, what leads one to believe that the registrar is likely to be on your local subnet? Seems if multicast for regisration is useful at all, it makes more sense for the discovery to either be via expanding ring broadcast and/or an admin-scoped group. BTW: bis-08 does not prohibit multicasting INVITES, which is equally useful (which could be to say not very...) as multicasting registrations, for completely infrastructure-less small configurations. The same question about single-hop applies. What am I missing? If I'm not missing anything and the SHOULD is an attempt balance utility against danger, I'm not sure the balance is right, since violating a SHOULD makes you only conditionally compliant, whereas I can think of quite a few configurations which are small enough to want to use this (e.g. for minimal functioality when your proxy/registrar is pooched) yet span more than one subnet. Does an admin scope on the multicast strike a better balance? [RRR] How about another suggestion: ttl=1 is a default behavior while the administrative scope can also be used? I don't feel strongly about this, BTW. Dave. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 22 09:25:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03298 for ; Fri, 22 Feb 2002 09:25:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24605 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 09:25:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22755; Fri, 22 Feb 2002 08:47:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22724 for ; Fri, 22 Feb 2002 08:47:28 -0500 (EST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01809 for ; Fri, 22 Feb 2002 08:47:23 -0500 (EST) Received: from attrh1i.attrh.att.com ([135.71.62.10]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g1MDklZ21396 for ; Fri, 22 Feb 2002 08:46:48 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029) id 3C62A10C000C9123; Fri, 22 Feb 2002 08:46:09 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y Date: Fri, 22 Feb 2002 08:46:09 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F9017B1C26@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] bis-07.9: proxies are not allowed to modify message bod y X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcG7pmmYbi/kLRdVQfGA6zGSfRkp3gAAI41w From: "Roy, Radhika R, ALASO" To: "George Foti (LMC)" , "Christer Holmberg (LMF)" , "Pete Cordell" Cc: "Bob Penfield" , , "Jonathan Rosenberg" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA22725 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit You are right. However, a clarification in the spec would foster interoperability. regards/RRR -----Original Message----- From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] Sent: Friday, February 22, 2002 8:40 AM To: Roy, Radhika R, ALASO; Christer Holmberg (LMF); Pete Cordell Cc: Bob Penfield; sip@ietf.org; Jonathan Rosenberg Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y I guess, its up to the editors to consider including such a definition. But its already in people's mind, may be thats why it is not explicitly defined rgds/gf > -----Original Message----- > From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] > Sent: Friday, February 22, 2002 8:32 AM > To: George Foti (LMC); Christer Holmberg (LMF); Pete Cordell > Cc: Bob Penfield; sip@ietf.org; Jonathan Rosenberg > Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message > bod y > > > Inline [RRR] > > -----Original Message----- > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > Sent: Friday, February 22, 2002 8:12 AM > To: Christer Holmberg (LMF); Pete Cordell > Cc: Bob Penfield; sip@ietf.org; Jonathan Rosenberg > Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message > bod y > > > There was the definition of "transperent" B2BUA to allow a > proxy to initiate > things it is not supposed to do, such as a BYE to terminate > a session (in > case of prepaid) or deregistration (if the network operator > decides to kick > somebody out) > > So while the spec. says as a *pure* proxy you cannot modify > SDP, I guess > most of us will do B2BUA, as the way out. > > [RRR] Is not better to clarify in the spec: "Pure" Proxy vs. > "Transparent" B2BUA Proxy? > > Regards > > George Foti > Ericsson Canada > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 22 09:36:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03678 for ; Fri, 22 Feb 2002 09:36:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25644 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 09:36:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23712; Fri, 22 Feb 2002 09:02:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23688 for ; Fri, 22 Feb 2002 09:02:34 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02254 for ; Fri, 22 Feb 2002 09:02:30 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AF777CB70134; Fri, 22 Feb 2002 09:02:31 -0500 Message-ID: <009001c1bba8$c3d06980$2300000a@acmepacket.com> From: "Bob Penfield" To: "Pete Cordell" Cc: References: <000f01c1bae9$2d7d0980$2300000a@acmepacket.com> <002701c1bb85$081198e0$0200000a@tkw> <3C761B7C.E910E53@lmf.ericsson.se> <001301c1bb98$4be7f380$0200000a@tkw> Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body Date: Fri, 22 Feb 2002 08:56:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Pete Cordell" > Christer, > > I did see that conversation, but it just seemed to fizzle out (maybe I > didn't see the end). > > I quite liked the conclusion where you could change Content-Length (amr), > but none of the others. (But then that suited my service today. Generally > it's potential limiting to decide what we can and can not change today.) In bis-08, Content-Length is (ar) not (amr). Thus a proxy is not allowed to change the length, it can only add it. I think in general, I'm OK with this. The basic issue is how much call/dialog state does the intermediary need to hold on to. Anything that is doing firewall/NAT operations will need to be dialog/call stateful to some extent because it will need to remove any bindings/pinholes when the dialog terminates. The only messy part is that if the B2BUA "proxies" the request (i.e. it only does normal proxy stuff PLUS changing the SDP) the outgoing request will have extra Via and possibly extra Record-Route headers. I don't see any obvious interoperability problems with this. However, many folks want to hide their internal Via & Record-Route stuff anyway, so you would have to remove them in that case which makes it more or less a normal B2BUA. You have to hold onto the Vias & Record-Routes or somehow encode them into the message you send. Now, the moment this intermediary needs to inject a request (like a BYE), it needs to maintain CSeq numbers. Otherwise it would be possible for a UAC and the intermediary to generate separate requests with the same CSeq number. And the moment you do that, the intermediary needs to generate a unique Call-ID, otherwise it might be possible for requests originated by the UA and the intermediary that happen to have the same CSeq number to collide if there is a spiral somewhere in the network. In your previous example of an element that wants to limit the set of codecs in the SDP, wouldn't you need to re-issue the INVITE with another set of codecs if the far end did not have any matches? There would be no way for the UA to know which of the codecs it originally offered might be acceptable. In that case, the intermediary will need to bump the CSeq number. Therefore, you need to be a B2BUA which generates a unique Call-ID and its own CSeq numbers. cheers, (-:bob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Feb 22 10:29:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05891 for ; Fri, 22 Feb 2002 10:29:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28991 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 10:29:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27927; Fri, 22 Feb 2002 10:03:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27864 for ; Fri, 22 Feb 2002 10:03:35 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04841; Fri, 22 Feb 2002 10:03:30 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #47837) id <0GRX00F01WGZRX@firewall.wcom.com>; Fri, 22 Feb 2002 15:02:59 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GRX00F81WGY3S@firewall.wcom.com>; Fri, 22 Feb 2002 15:02:59 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GRX00D01WGOPA@pmismtp03.wcomnet.com>; Fri, 22 Feb 2002 15:02:58 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GRX00C7ZWGDBT@pmismtp03.wcomnet.com>; Fri, 22 Feb 2002 15:02:38 +0000 (GMT) Date: Fri, 22 Feb 2002 09:02:37 -0600 From: Henry Sinnreich To: sipping@ietf.org, sip@ietf.org Message-id: <000201c1bbb1$f7e0e0c0$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Content-Transfer-Encoding: 7bit Subject: [Sip] Drafts on SIP Telephony Devices Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi folks! Two related drafts on SIP devices have been submitted for the SIPPING and SIP WGs. They can be retrieved here until they will appear in the IETF archive. http://www.pingtel.com/docs/draft-sinnreich-sipping-device-requirements- 00.txt SIP Telephony Device Requirements Abstract The SIP Telephony Device Requirements in this document are aimed to enable users to procure SIP phones from various vendors and install them using a configuration process over the network, though still allowing manual configuration data input if desired. SIP telephony devices are also required to be updated up automatically, without the intervention of the end user. The requirements are aimed to allow service providers to support large numbers of SIP telephony devices from different vendors and SHOULD be used as a checklist for developers of SIP phones. SIP telephony devices may support basic telephony as well as advanced services such as PBX and Centrex-like telephony, third party call control, presence based services, roaming and other applications. The requirements aim to insure multi-vendor interoperability over the Internet and in private IP networks for such services. A Framework for SIP User Agent Configuration http://www.ietf.org/internet-drafts/draft-petrie-sip-config-framework-01 .txt Abstract This document defines the application of a set of protocols for configuring a SIP user agent. The SIP user agent must discover how and from where to retrieve its initial configuration and be notified of changes and updates which impact its configuration. The objective is to define a means for automatically configuring a user agent such that it can be functional without user or administrative intervention. The framework for discovery, delivery, notification and updates of user agent configuration is defined here. This framework is also intended to ease ongoing administration, configuration and upgrading of large scale deployments of SIP user agents. The contents and format of the configuration data to be defined is outside the scope of this document. It would be nice to discuss these two together. Comments and discussions are most welcome. Thanks, Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 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 daemon@ns.ietf.org Fri Feb 22 11:42:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09683 for ; Fri, 22 Feb 2002 11:42:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05084 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 11:42:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02693; Fri, 22 Feb 2002 11:14:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02623 for ; Fri, 22 Feb 2002 11:14:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08091; Fri, 22 Feb 2002 11:14:00 -0500 (EST) Message-Id: <200202221614.LAA08091@ietf.org> To: IETF-Announce: ; Cc: sip@ietf.org, mmusic@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Fri, 22 Feb 2002 11:13:59 -0500 Subject: [Sip] Last Call: SIP: Session Initiation Protocol to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has received a request from the Session Initiation Protocol Working Group and the Multiparty Multimedia Session Control Working Group to consider publication of the following Internet-Drafts as Proposed Standards: o SIP: Session Initiation Protocol o Reliability of Provisional Responses in SIP o SIP: Locating SIP Servers o SIP-Specific Event Notification o An Offer/Answer Model with SDP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 8, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-08.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-05.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-srv-05.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-events-03.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-offer-answer-01.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Feb 22 11:49:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10083 for ; Fri, 22 Feb 2002 11:49:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05673 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 11:49:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03709; Fri, 22 Feb 2002 11:29:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03676 for ; Fri, 22 Feb 2002 11:28:59 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08851 for ; Fri, 22 Feb 2002 11:28:56 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.138]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1MGTH6Y014301; Fri, 22 Feb 2002 11:29:18 -0500 (EST) Message-ID: <3C7671AB.F1EDE080@dynamicsoft.com> Date: Fri, 22 Feb 2002 11:28:27 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Reynolds CC: "'sip@ietf.org'" Subject: Re: [Sip] bis-80 security requirements References: <00533D13955AD411AF3800A0C9B4263994D71B@ThisAddressDoesNotExist> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Phil Reynolds wrote: > > pdf line 5965: Proxy servers, redirect servers, and registrars MUST > implement TLS > > Am I missing something Certainly. > or does this break all existing SIP > network-elements? First off, this requirement was in bis-07. And bis-06. That means you have had a month to say something. Thank you for your timely feedback. Its not like we are on a schedule or anything. Secondly, you are most certainly wrong. An element which decides to send using TLS as a hBh mechanism (as its described in older versions of bis) will need to use DNS to look for SIPS NAPTR records; presuming you don't have any since you have a server that doesn't support TLS, then UDP or TCP will be used. Default in the absence of anything remains UDP as it has always been. I recommend you actually read some of the documents we are producing, rather than make bold sweeping claims which tend to generate lots of FUD. If you want to participate in loose routing, you'll need to do TLS in case someone has decided to loose route to a sips resource through your proxy. As loose routing is new, and it is known you can't loose route through unknown (in the sense of loose v. strict) elements, its not an issue anyway. Initiating a call to a sips resource will also require TLS (and sips) support for outbound proxies in front of the element that owns that URI. However, as there are no sips URIs being handed out yet, its not an issue. There is fallback (with user prompting preferred) should a sips resource be called when a non-bis proxy sits in front, so their is a reasonable migration story. I will also note that TLS has been in bis itself for quite some time. We've found it particularly helpful for many network scenarios that we have used our products in. I suspect that, in fact, many mature proxy server products do support it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Fri Feb 22 11:53:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10461 for ; Fri, 22 Feb 2002 11:53:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05978 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 11:53:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03997; Fri, 22 Feb 2002 11:30:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03949 for ; Fri, 22 Feb 2002 11:30:27 -0500 (EST) Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08938 for ; Fri, 22 Feb 2002 11:30:23 -0500 (EST) Received: from host213-122-45-211.in-addr.btopenworld.com ([213.122.45.211] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #8) id 16eIaR-0005E9-00; Fri, 22 Feb 2002 16:30:20 +0000 Message-ID: <005101c1bbbe$450aca80$0200000a@tkw> From: "Pete Cordell" To: "Bob Penfield" Cc: References: <000f01c1bae9$2d7d0980$2300000a@acmepacket.com> <002701c1bb85$081198e0$0200000a@tkw> <3C761B7C.E910E53@lmf.ericsson.se> <001301c1bb98$4be7f380$0200000a@tkw> <009001c1bba8$c3d06980$2300000a@acmepacket.com> Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body Date: Fri, 22 Feb 2002 16:29:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit From: Bob Penfield > From: "Pete Cordell" > > > I quite liked the conclusion where you could change Content-Length (amr), > > but none of the others. (But then that suited my service today. > Generally > > it's potential limiting to decide what we can and can not change today.) > > In bis-08, Content-Length is (ar) not (amr). Thus a proxy is not allowed to > change the length, it can only add it. > When I said 'the conclusion' I really meant Robert's conclusion, which was more of 'a conclusion' than the final conclusion ! > I think in general, I'm OK with this. The basic issue is how much > call/dialog state does the intermediary need to hold on to. Anything that is > doing firewall/NAT operations will need to be dialog/call stateful to some > extent because it will need to remove any bindings/pinholes when the dialog > terminates. > > The only messy part is that if the B2BUA "proxies" the request (i.e. it only > does normal proxy stuff PLUS changing the SDP) the outgoing request will > have extra Via and possibly extra Record-Route headers. I don't see any > obvious interoperability problems with this. Nor do I, but if someone assumes that it can't change then potentially they may come up with some cunning plan that inadvertantly introduces interoperability problems. So I think its safer for the definition of a proxy to reflect this - especially as people will do it anyway. > However, many folks want to > hide their internal Via & Record-Route stuff anyway, so you would have to > remove them in that case which makes it more or less a normal B2BUA. You > have to hold onto the Vias & Record-Routes or somehow encode them into the > message you send. As an aside, there used to be via hiding, but that was removed because it complicated loop-detection (I think). It could probably be put back in now that we're looking at Max-Forwards to do this. But back to the plot, theoretically, you can go a long way down the route of making an anonimiser that messes around with all sorts of SIP headers, but still knows nothing more about SIP states than your average stateless SIP proxy. This is another example of why I think it is premature at this stage to be too bullish about what a proxy can and can not change. We might just inadvertantly kill off that killer app. (Mind you, looking at the table I can't see immediately what I would change - other than Content-Length.) > > Now, the moment this intermediary needs to inject a request (like a BYE), it > needs to maintain CSeq numbers. Otherwise it would be possible for a UAC and > the intermediary to generate separate requests with the same CSeq number. > And the moment you do that, the intermediary needs to generate a unique > Call-ID, otherwise it might be possible for requests originated by the UA > and the intermediary that happen to have the same CSeq number to collide if > there is a spiral somewhere in the network. True, that is a whole new beasty. > > In your previous example of an element that wants to limit the set of codecs > in the SDP, wouldn't you need to re-issue the INVITE with another set of > codecs if the far end did not have any matches? There would be no way for > the UA to know which of the codecs it originally offered might be > acceptable. In that case, the intermediary will need to bump the CSeq > number. Therefore, you need to be a B2BUA which generates a unique Call-ID > and its own CSeq numbers. All I was thinking was, if it saw something like: m=audio 3456 RTP/AVP 0 7 a=rtpmap:0 PCMU/8000 a=rtpmap:7 LPC/44100/2 # Whatever linear CD quality is m=video 2232 RTP/AVP 51 b=6000 # Haven't checked SDP, but looking for 6 Mbits/s a=rtpmap:51 H262/90000 in the messages that zipped past it, then it could change it to: m=audio 3456 RTP/AVP 0 # No CD quality a=rtpmap:0 PCMU/8000 m=video 2232 RTP/AVP 51 b=128 # Limited to 128kbits/s a=rtpmap:51 H262/90000 If no match was found by the remote UAS, then the call would be dropped 'cos you're not using that much bandwidth whatever the reason !' > > cheers, > (-:bob Back to philosophical points again, in the case of VoIP, the whole package comes in two halves, invitation/membership control, and media control. SIP does the former, and SDP does most of the latter. To arbitrarily say that you will need to mess around with the invitation aspects, but not the media control aspects seems hard to justify at this early stage. I think it's also messing policy with protocol design. But I won't worry about it too much, as I'll just get on with it and do what I have to do like everybody else out there, which at the end of the day is the reality of the situation. It just seems a shame that having put so much work into the spec, it doesn't reflect what is really going to happen in the real world. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Feb 22 12:00:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10858 for ; Fri, 22 Feb 2002 12:00:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06877 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 12:00:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04834; Fri, 22 Feb 2002 11:40:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04809 for ; Fri, 22 Feb 2002 11:40:28 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09543 for ; Fri, 22 Feb 2002 11:40:24 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1MGbpQl009092; Fri, 22 Feb 2002 11:37:51 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNG2Y2>; Fri, 22 Feb 2002 11:39:54 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F363009B@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Pete Cordell'" , Bob Penfield Cc: sip@ietf.org Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y Date: Fri, 22 Feb 2002 11:39:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > > All I was thinking was, if it saw something like: > > m=audio 3456 RTP/AVP 0 7 > a=rtpmap:0 PCMU/8000 > a=rtpmap:7 LPC/44100/2 # Whatever linear CD quality is > m=video 2232 RTP/AVP 51 > b=6000 # Haven't checked SDP, but looking for 6 Mbits/s > a=rtpmap:51 H262/90000 > > in the messages that zipped past it, then it could change it to: > > m=audio 3456 RTP/AVP 0 # No CD quality > a=rtpmap:0 PCMU/8000 > m=video 2232 RTP/AVP 51 > b=128 # Limited to 128kbits/s > a=rtpmap:51 H262/90000 Trying to do this sort of enforcement in the SIP signalling layer is horribly, horribly misguided. If you need to enforce this sort of policy, you'll need support at the access level; there are a whole suite of protocols (RSVP, COPS, etc) designed for exactly this. If you try to do this with a SIP proxy, I will personally be one of the first people on your network to build a client that interprets "PCMU/8000" as "cd-quality-audio," give it to my friends, and send whatever media I feel like, regardless of what your meddlesome proxy thinks it has to say about it. And I guarantee that I won't be the last. /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 daemon@ns.ietf.org Fri Feb 22 12:24:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12418 for ; Fri, 22 Feb 2002 12:24:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09054 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 12:24:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06241; Fri, 22 Feb 2002 11:55:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06210 for ; Fri, 22 Feb 2002 11:55:44 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10554 for ; Fri, 22 Feb 2002 11:55:40 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.138]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1MGtq6Y014324; Fri, 22 Feb 2002 11:55:56 -0500 (EST) Message-ID: <3C7677E5.64358609@dynamicsoft.com> Date: Fri, 22 Feb 2002 11:55:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Roy, Radhika R, ALASO" CC: "George Foti (LMC)" , "Christer Holmberg (LMF)" , Pete Cordell , Bob Penfield , sip@ietf.org Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body References: <62DA45D4963FA747BA1B253E266760F9017B1C26@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Roy, Radhika R, ALASO" wrote: > > You are right. > > However, a clarification in the spec would foster interoperability. Well, while we are at it, how about this. Let us design a whole family of B2BUA definitions, each with selective pieces of the specification from proxy as opposed to UA! We could detail a wide array of call flows and everything. Fun fun!! Please. The essence of the SIP model is that it is a protocol for faciliating end-to-end negotiation of sessions of some sort. The ->LOGICAL<- role of a proxy server is to facilitate those exchanges through routing, location and policy services. A thing that implements that role needs to consider those requirements. Simple fact is, a thing that mucks with bodies needs to consider UA requirements. As a simple example, if I send a request like this as a UAC: INVITE sip:user@example.com Require: m-lines-in-SDP-mean-something-else .... The thing that mucks with the body needs to know about it. There are other pitfalls, security being another one. Another is the need to do the various content handling in bis (what if the INVITE comes with sdp-ng? What if its been gzipped and has content encodings that are not understood by this "proxy"?) So, a logical proxy can't muck with these bodies or the entire model of SIP begins to fall apart. It has become a logical UA by the result of its needing to follow UA requirements for the protocol to properly operate. So, such a thing will need to take the logical role of a UA. Now, you can build stupid B2BUA, or smart ones. A smart one might realize that it can perform its functions without call state. A stupid one might not. THe market will pick the winners. I found it astounding how much people look to IETF and other standards bodies to do their engineering work for them - to specify the system and implementations so fully that their is little room for error (or innovation or differentiation). That is not the IETF way, and it is not the SIP way. Being a B2BUA means - WARNING - you need to think about things UAs think about. How you implement that is your own choice. I am continually shocked that people assume that because something is a B2BUA its a hulking bear that prevents services. ONLY is that true when you buy products from people who do a bad job at such things. If your sdp-mucking-server-product breaks services, even though its a b2bua, get a new one. There is a marketing issue, that such things can't rightly be called "proxy servers". I hope, Pete, you and others are not arguing for a feature to facilitate your marcom. Maybe you should hire some of those people that have managed to convince the industry that their products are "sofswitches". Here, we worry about technology. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@ns.ietf.org Fri Feb 22 14:24:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17843 for ; Fri, 22 Feb 2002 14:24:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18058 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 14:24:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16340; Fri, 22 Feb 2002 14:02:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16251 for ; Fri, 22 Feb 2002 14:02:12 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16971; Fri, 22 Feb 2002 14:02:09 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1MJ27h23200; Fri, 22 Feb 2002 13:02:07 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1MJ26h18617; Fri, 22 Feb 2002 13:02:07 -0600 (CST) Received: from lmf.ericsson.se (rmt160139.am.ericsson.se [138.85.160.139]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA08779; Fri, 22 Feb 2002 13:02:04 -0600 (CST) Message-ID: <3C769D54.C3B4923A@lmf.ericsson.se> Date: Fri, 22 Feb 2002 21:34:44 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip , mmusic CC: "Fredrik Lindholm (ERA)" , Jonathan Rosemberg , wtm@research.att.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Removing security preconditions from manyfolks Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, we are thinking of removing security preconditions from manyfolks. Right now manyfolks handles QoS and security preconditions. However, with MIKEY, this feature seems useless to establish secure channels. If somebody thinks that removing security preconditions from manyfolks is a bad idea, please speak up. Regards, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@ns.ietf.org Fri Feb 22 14:52:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19292 for ; Fri, 22 Feb 2002 14:52:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21036 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 14:52:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18207; Fri, 22 Feb 2002 14:26:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18134 for ; Fri, 22 Feb 2002 14:26:19 -0500 (EST) Received: from mail.siemenscom.com (mail.siemenscom.com [12.146.131.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17911 for ; Fri, 22 Feb 2002 14:26:16 -0500 (EST) Received: from mail-stc.rolm.com (mail-stc.siemenscom.com [12.146.131.7]) by mail.siemenscom.com (8.9.3/8.9.3) with ESMTP id LAA18982 for ; Fri, 22 Feb 2002 11:23:03 -0800 (PST) Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com [165.218.68.180]) by mail-stc.rolm.com (8.11.6/8.11.6) with ESMTP id g1MJLO213825 for ; Fri, 22 Feb 2002 11:21:24 -0800 (PST) Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 11:26:15 -0800 Message-ID: From: "Tiruthani, Saravanakumar" To: "'sip@ietf.org'" Date: Fri, 22 Feb 2002 11:25:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBD6.B71D9810" Subject: [Sip] Interpretation of headers in REGISTER message Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BBD6.B71D9810 Content-Type: text/plain Hi, I understand that the REGISTER method provides a way of associating one address-of-record with one or more contact address. However it is not clear for me whether the contact addresses correspond to the transport address of the UAC or just other names for the same user. For example, let us say sip:jdoe@acme.com has the following contact addresses: Sip:jdoe@mycomputer.acme.com Tel:14085555555 From the proxy perspective there are two interpretations possible: 1) The proxy interprets that all INVITEs to jdoe@acme.com has to be delivered to jdoe@mycomputer.acme.com and to a PSTN terminal 1408555555 (through a gateway) [say by forking the request] 2) The proxy interprets that jdoe@mycomputer.acme.com represents both the SIP URI (jdoe@.acme.com ) as well as the PSTN terminal Is there a provision in existing SIP protocol to differentiate two cases? If so, could someone please point it to me? Otherwise, is it worth adding to the spec? Your input will be greatly appreciated. Regards, Sarvan Tirurthani PS: I sent an earlier mail on the same subject from my yahoo account, though I did not see the message on the reflector. Is there any restriction on sending mails to the reflector from free e-mail accounts? ------_=_NextPart_001_01C1BBD6.B71D9810 Content-Type: text/html

Hi,

 

I understand that the REGISTER method provides a way of associating one address-of-record with one or more contact address. However it is not clear for me whether the contact addresses correspond to the transport address of the UAC or just other names for the same user.

 

For example, let us say sip:jdoe@acme.com has the following contact addresses:

Sip:jdoe@mycomputer.acme.com

Tel:14085555555

 

From the proxy perspective there are two interpretations possible:

1)     The proxy interprets that all INVITEs to jdoe@acme.com has to be delivered to jdoe@mycomputer.acme.com and to a PSTN terminal 1408555555 (through a gateway) [say by forking the request]

2)     The proxy interprets that jdoe@mycomputer.acme.com represents both the SIP URI (jdoe@.acme.com) as well as the PSTN terminal

 

Is there a provision in existing SIP protocol to differentiate two cases? If so, could someone please point it to me? Otherwise, is it worth adding to the spec?

 

Your input will be greatly appreciated.

Regards,

Sarvan Tirurthani

 

PS: I sent an earlier mail on the same subject from my yahoo account, though I did not see the message on the reflector. Is there any restriction on sending mails to the reflector from free e-mail accounts?

------_=_NextPart_001_01C1BBD6.B71D9810-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Feb 22 14:56:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19473 for ; Fri, 22 Feb 2002 14:56:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21287 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 14:56:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19263; Fri, 22 Feb 2002 14:32:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19226 for ; Fri, 22 Feb 2002 14:32:09 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18292 for ; Fri, 22 Feb 2002 14:32:06 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1MJSrQl010894; Fri, 22 Feb 2002 14:28:54 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNG262>; Fri, 22 Feb 2002 14:30:57 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F363009C@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Tiruthani, Saravanakumar'" , "'sip@ietf.org'" Subject: RE: [Sip] Interpretation of headers in REGISTER message Date: Fri, 22 Feb 2002 14:30:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org >PS: I sent an earlier mail on the same subject from my yahoo >account, though I did not see the message on the reflector. >Is there any restriction on sending mails to the reflector >from free e-mail accounts? No, that mail showed up. The reason no one is answering you can be deduced from the blurb added to the bottom of every single message that goes through the list. I'll repeat the relevant part so as to bring it more squarely to your attention. *** This list is for NEW development of the core SIP Protocol *** Use sip-implementors@cs.columbia.edu for questions on current sip /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 daemon@ns.ietf.org Fri Feb 22 14:59:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19627 for ; Fri, 22 Feb 2002 14:59:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21504 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 14:59:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18548; Fri, 22 Feb 2002 14:29:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18519 for ; Fri, 22 Feb 2002 14:29:40 -0500 (EST) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18129 for ; Fri, 22 Feb 2002 14:29:36 -0500 (EST) Received: from host213-122-131-67.in-addr.btopenworld.com ([213.122.131.67] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 16eLNk-00027K-00; Fri, 22 Feb 2002 19:29:25 +0000 Message-ID: <003f01c1bbd7$49034b80$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" , "Roy, Radhika R, ALASO" Cc: "George Foti (LMC)" , "Christer Holmberg (LMF)" , "Bob Penfield" , References: <62DA45D4963FA747BA1B253E266760F9017B1C26@OCCLUST04EVS1.ugd.att.com> <3C7677E5.64358609@dynamicsoft.com> Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body Date: Fri, 22 Feb 2002 19:29:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Just when I was thinking of calling it a day.... ----- Original Message ----- From: Jonathan Rosenberg > The essence of the SIP model is that it is a protocol for faciliating > end-to-end negotiation of sessions of some sort. The ->LOGICAL<- role of > a proxy server is to facilitate those exchanges through routing, > location and policy services. A thing that implements that role needs to > consider those requirements. Simple fact is, a thing that mucks with > bodies needs to consider UA requirements. I really think you are being too restrictive in your definition of what a proxy can do. Especially as SIP is a general mechanism, not just for VoIP or Instant Messaging. For example, hypothetically again, but imagine something like a SIP service that notifies you when a co-operatively edited document has changed. Perhaps it also diffs the changes, zips them up, and puts them in the body of a SIP INVITE (or possibly a NOTIFY) so that an automated system can automatically update a local copy of the document so that next time I look at it the changes are already incorporated. Now I want to get notifications on my mobile phone when the document is changed. I don't want to get a huge file downloaded when it comes in because I'll probably just go straight to my laptop and look at it there. Therefore the proxy could erase the MIME attachment for me, perhaps store the file on its hard disk and insert a URL into the body. To do this it just needs to tweak the body as it passes through. It doesn't need to be a back to back UA, and it doesn't need to be dialog stateful. It does have to understand what it is doing though, and it needs to do it in full knowledge of what impact it will have on other UAs in the dialog. (Let's ignore the opes issues for the time being and assume that's a solved problem, which I assume it will be soon.) True, there maybe better ways to cut such a service, but for five minutes thinking it vaguely sounds like a useful service. My real point is not that this particular service is useful, but that there are likely to be many services out there that we just haven't thought of yet, that would really benefit from changing the body. Saying that we can't change the body prevents that. > As a simple example, if I send > a request like this as a UAC: > > INVITE sip:user@example.com > Require: m-lines-in-SDP-mean-something-else > .... > > > The thing that mucks with the body needs to know about it. There are > other pitfalls, security being another one. So far I find the security arguments somewhat circular: I can't change the body because it's been integrity checked, I can integrity check the body because it can't be changed. That's not much of an argument to me. I guess integrity checking the body is a hang over from HTTP. There it makes sense to integrity check the body as that is the actual thing that is being delivered. In the case of SIP, the SDP simply points to something else (RTP). There's not much point in integrity checking a pointer if you can then just change what's pointed to. > Another is the need to do > the various content handling in bis (what if the INVITE comes with > sdp-ng? What if its been gzipped and has content encodings that are not > understood by this "proxy"?) So, a logical proxy can't muck with these > bodies or the entire model of SIP begins to fall apart. It has become a > logical UA by the result of its needing to follow UA requirements for > the protocol to properly operate. Not being able, and not being willing to handle any body makes it an application specific proxy, not a B2BUA with dialog state etc. One way to deal with this would be to send 415 and send Accepts headers back. That doesn't seem to be asking much more of a proxy than sending 404 Not Found back, and I don't see that that automatically makes it a B2BUA. Also, just because the proxy decides to tweak SDP, doesn't mean it can't let through other things, such as IM, that it knows about and is happy with (assuming a firewall type role here. If it's not doing firewalling, say just NAT facilitation, then it could just let anything through that it doesn't understand - screws up if it was sdp-ng, but at least we tried and it wouldn't have worked anyway. Hopefully sdp-ng is on most peoples radar scope though.). > > So, such a thing will need to take the logical role of a UA. Now, you > can build stupid B2BUA, or smart ones. A smart one might realize that it > can perform its functions without call state. A stupid one might not. > THe market will pick the winners. > > I found it astounding how much people look to IETF and other standards > bodies to do their engineering work for them - to specify the system and > implementations so fully that their is little room for error (or > innovation or differentiation). My point is the opposite, that the IETF is actually limiting my innovation and differentiation here. I'm quite happy to do the engineering work, work through the impact it has on other systems, make sure my product is robust and reliable in the context of all the other SIP UA and proxies it might come across and take my chances in the market place. But the IETF is actually saying that I can't design something this way, and as far as I can see, for no good reason. > That is not the IETF way, and it is not > the SIP way. Being a B2BUA means - WARNING - you need to think about > things UAs think about. How you implement that is your own choice. I am > continually shocked that people assume that because something is a B2BUA > its a hulking bear that prevents services. ONLY is that true when you > buy products from people who do a bad job at such things. Exactly, and you don't have to be a B2BUA to do a bad job of SIP. And it's that word WARNING that is precisely the issue. Why WARNING for B2BUAs, but no warning for other SIP implementations? The market is being poisoned with the notion that B2BUAs are inherently bad, and therefore you shouldn't touch them. With the definition that anything that is not a pure proxy as defined by the standard, is a B2BUA - and therefore unclean in some way - the vitality and take up of SIP in the market place is sure to be restricted. And at the end of that day that will impact the pure as well as the unclean. > If your > sdp-mucking-server-product breaks services, even though its a b2bua, get > a new one. > > There is a marketing issue, that such things can't rightly be called > "proxy servers". I hope, Pete, you and others are not arguing for a > feature to facilitate your marcom. Maybe you should hire some of those > people that have managed to convince the industry that their products > are "sofswitches". Here, we worry about technology. And there was me thinking that you were trying to say that I can't change bodies because it didn't fit in with your business plans. I'm glad we've sorted that out. Let's worry about technology. But let's give that technology a future. Let's not stiffle it's growth due to our limited vision. Give it the chance of a million minds working to make it better. Let it be free. That's all I ask ! Oh - and change Content-Length to amr ! (Well done to you all on getting the spec out by the way. And there was me thinking we could talk about you behind your back because you'd be asleep today !!!) > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Feb 22 15:00:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19771 for ; Fri, 22 Feb 2002 15:00:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA22186 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 15:01:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18493; Fri, 22 Feb 2002 14:29:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18461 for ; Fri, 22 Feb 2002 14:29:29 -0500 (EST) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18124 for ; Fri, 22 Feb 2002 14:29:26 -0500 (EST) Received: from host213-122-131-67.in-addr.btopenworld.com ([213.122.131.67] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 16eLNi-00027K-00; Fri, 22 Feb 2002 19:29:22 +0000 Message-ID: <003e01c1bbd7$4782c600$0200000a@tkw> From: "Pete Cordell" To: "Adam Roach" , "Bob Penfield" Cc: References: <9BF66EBF6BEFD942915B4D4D45C051F363009B@DYN-TX-EXCH-001.dynamicsoft.com> Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body Date: Fri, 22 Feb 2002 18:04:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sure, if I want to be malicious I can do loads of things and I don't have to wait until I receive a SIP INVITE to do it. I can quite easily just fire out loads of UDP packets and gobble up bandwidth that way. After all, saying something is PCMU when it is actually something else is not going to make the dialog of any use to the remote UA. I was really thinking more of a facilitating service rather than one that was enforcing. For example, it might be perfectly reasonable to use CD quality on the internal LAN, but not across the enterprise access link. Therefore a UA would want to declare that it can do CD quality on the off chance that it might be useful, but be happy if some helpful intermediary advised that you were probably going to loose most of your packets in you do it across the access link (not to mention getting your managers upset). Many, many people would be happy to work within those bounds, and something that helps them get the right mix at the right time can only be helpful. Besides, who said there wasn't any stick here. The considerate proxy could have a nasty side to it and actually talk to the firewall, a la Midcom, and tell it to discard packets if this flow goes out of SLA. So go ahead and build your client that interprets "PCMU/8000" as "cd-quality-audio". I'm sure it won't be the worst bastardisation of the SIP spec. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Adam Roach To: 'Pete Cordell' ; Bob Penfield Cc: Sent: 22 February 2002 16:39 Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message body > > -----Original Message----- > > From: Pete Cordell [mailto:pete@tech-know-ware.com] > > > > All I was thinking was, if it saw something like: > > > > m=audio 3456 RTP/AVP 0 7 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:7 LPC/44100/2 # Whatever linear CD quality is > > m=video 2232 RTP/AVP 51 > > b=6000 # Haven't checked SDP, but looking for 6 Mbits/s > > a=rtpmap:51 H262/90000 > > > > in the messages that zipped past it, then it could change it to: > > > > m=audio 3456 RTP/AVP 0 # No CD quality > > a=rtpmap:0 PCMU/8000 > > m=video 2232 RTP/AVP 51 > > b=128 # Limited to 128kbits/s > > a=rtpmap:51 H262/90000 > > Trying to do this sort of enforcement in the SIP signalling > layer is horribly, horribly misguided. If you need to enforce > this sort of policy, you'll need support at the access level; > there are a whole suite of protocols (RSVP, COPS, etc) designed > for exactly this. > > If you try to do this with a SIP proxy, I will personally be > one of the first people on your network to build a client that > interprets "PCMU/8000" as "cd-quality-audio," give it to my > friends, and send whatever media I feel like, regardless of > what your meddlesome proxy thinks it has to say about it. > > And I guarantee that I won't be the last. > > /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 daemon@ns.ietf.org Fri Feb 22 16:38:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26560 for ; Fri, 22 Feb 2002 16:38:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28209 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 16:38:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26836; Fri, 22 Feb 2002 16:11:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26805 for ; Fri, 22 Feb 2002 16:11:37 -0500 (EST) Received: from uni02mr.unity.ncsu.edu (uni02mr.unity.ncsu.edu [152.1.1.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25482 for ; Fri, 22 Feb 2002 16:11:33 -0500 (EST) Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116]) by uni02mr.unity.ncsu.edu (8.8.8/8.8.8/UR01Feb99) with SMTP id QAA20345 for ; Fri, 22 Feb 2002 16:11:35 -0500 (EST) Message-ID: <04b401c1bbe5$82a7bb60$743c0198@ecew2k.ncsu.edu> From: "Prabhas Sinha" To: Date: Fri, 22 Feb 2002 16:11:35 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04B1_01C1BBBB.99991730" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] SIP usage in WAP apps Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_04B1_01C1BBBB.99991730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, Do we think SIP would find its use in WAP applications ? Looking at the WAP architecture I think presence & multimedia support = could be the features which WAP can benefit from SIP. Any other thoughts = ? Prabhas ------=_NextPart_000_04B1_01C1BBBB.99991730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All,
Do we think SIP would find its use in = WAP=20 applications ?
Looking at the WAP architecture I think = presence=20 & multimedia support could be the features which WAP can benefit = from SIP.=20 Any other thoughts ?
 
Prabhas
------=_NextPart_000_04B1_01C1BBBB.99991730-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Feb 22 17:15:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28340 for ; Fri, 22 Feb 2002 17:15:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00544 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 17:15:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28769; Fri, 22 Feb 2002 16:55:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28737 for ; Fri, 22 Feb 2002 16:55:33 -0500 (EST) Received: from localhost ([211.117.146.104]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27343 for ; Fri, 22 Feb 2002 16:55:27 -0500 (EST) Message-Id: <200202222155.QAA27343@ietf.org> Reply-To: hohoho5709@hanmail.net From: 남가현 To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 23 Feb 2002 06:50:57 +0900 Subject: [Sip] (광고)뉴트리션 포 라이프 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org

O 본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다.
O e-mail주소는 인터넷상에서 취득하였으며, 주소외 어떠한 개인 정보도 가지고 있지 않습니다.
O 수신을 원하지 않으시면 수신거부를 클릭하세요.
O 이왕 메일을 여신 것이라면 고급정보가 있으니 꼼꼼히 고려해 주신다면 고맙겠습니다!!

************************************************************************************************


'뉴트리션 포 라이프' 사이트 : 홈페이지 들어가셔서 왼쪽에 클릭하시면 됩니다..


홈페이지클릭


(사이트를 방문해보세요. 현재 인터넷으로 하루 300명씩 가입하고 있어요)


1. 뉴트리션 포 라이프는 어떤 회사인가?


(주)뉴트리션 포 라이프는 암웨이 같은 세계적인 네트워크 마케팅 회사로 드디어

이번 2월 23일에 정식 오픈하며 회원을 받는 중입니다.


2. 인터넷으로 가상 가입이란?


정말 획기적인 방식입니다.^^

인터넷에 무료로 가상 가입한 후 원하면 실제로 가입하게 됩니다.

저희 자동 가입 시스템으로 회원들이 몰려오고 있는 광경을 직접 목격하고 체험

하십시오.

실로 놀라운 일이 일어나고 있습니다.


(가입하시면 자기 홈페이지가 생기고 30분에 자기 하부에 10명씩 늘어 납니다.

자기 홈페이지로 홍보 가능)


☞ 자신의 홈페이지 주소 :

http://ebiz7.net/myteam/index.ph p?id=자신의 아이디



3. 왜 빨리 가입해야 하는가?


지금은 네트워크 마케팅 헤드들이 가입하는 시기입니다.

(예로 암웨이의 상층이라고 보면 됩니다.)


인터넷 가입 시스템을 가동한지 이주일 되었읍니다.

오늘은 300명... 정말 기하급수적으로 가입하고 있읍니다.

3월중순까지 약3만명을 예상하고 있습니다.


4. 무엇을 어떻게 해야 하는가?


후원자 8명만 받으면 당신은 평생 먹고 살수 있는 월급을 받게 될 것입니다.

(저는 인터넷으로 2일동안 10명 받았습니다.^^)


그이상의 노력은 당신을 부자로 만들 것입니다.


사람과 사람이 연결되어 무한 이익이 창출됩니다.


함께 하기 때문에 성공 할 수 있습니다.

홈페이지 들어가셔서 왼쪽에 클릭하시면 됩니다..


홈페이지클릭


지금 바로 접속하세요. 그리고 가상회원등록을 하십시요....

그리고 1시간후에 하부라인을 조회해 보세요.....

증가되는 그 숫자에 뿌듯함을 느끼시게 될 것입니다.

내일이면 그만큼 늦습니다.

----------------------------------

이름:남가현

TEL : 011-9864-8209

메일 : hohoho8209@hanmail.net


_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Feb 22 17:26:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28714 for ; Fri, 22 Feb 2002 17:26:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA01196 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 17:26:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29977; Fri, 22 Feb 2002 17:02:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29952 for ; Fri, 22 Feb 2002 17:02:23 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27846 for ; Fri, 22 Feb 2002 17:02:19 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1MM1oE29341 for ; Fri, 22 Feb 2002 14:01:50 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACN12724; Fri, 22 Feb 2002 14:01:49 -0800 (PST) Date: Fri, 22 Feb 2002 14:00:20 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] draft-ietf-sipping-cc-framework-00.txt (fwd) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, FYI: The new multipart framework draft replaces the old call control framework draft. It will be discussed in the SIPPING working group. thanks, -rohan ---------- Forwarded message ---------- Date: Fri, 22 Feb 2002 13:58:24 -0800 (Pacific Standard Time) From: Rohan Mahy To: sipping@ietf.org Cc: rohan@cisco.com Subject: draft-ietf-sipping-cc-framework-00.txt Hello, The new multiparty application framework document has been submitted. Until it appears in the archives it is available at: ftp://ftpeng.cisco.com/rmahy/draft-ietf-sipping-cc-framework-00.txt Like all work from a design team, this is only *input* to the working group and can (and should) get ripped apart where appropriate, or thrown away if it is not useful (although I hope that is not the case). Unlike most work from a design team, most of the work in this document was summarizing or stitching together text and ideas from other drafts. I hope you like the result. Comments of all varieties are welcome. thanks, -rohan (as an individual contributor) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Feb 22 17:49:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29774 for ; Fri, 22 Feb 2002 17:49:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02636 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 17:49:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01116; Fri, 22 Feb 2002 17:25:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01084 for ; Fri, 22 Feb 2002 17:25:36 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28675 for ; Fri, 22 Feb 2002 17:25:31 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1MMP3t23834 for ; Fri, 22 Feb 2002 14:25:03 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACN13093; Fri, 22 Feb 2002 14:25:01 -0800 (PST) Date: Fri, 22 Feb 2002 14:23:30 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] security preconditions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Gonzalo, I think it is still quite reasonable to signal that such-and-such security is required before I ring. I think the "confirm" part if much less important, because all the security negotiation protocols i know about are reliable. thanks, -rohan To: sip , mmusic Subject: [Sip] Removing security preconditions from manyfolks From: Gonzalo Camarillo Date: Fri, 22 Feb 2002 21:34:44 +0200 CC: "Fredrik Lindholm (ERA)" , Jonathan Rosemberg , wtm@research.att.com List-Id: Session Initiation Protocol Sender: sip-admin@ietf.org -------------------------------------------------------------------------------- Hi, we are thinking of removing security preconditions from manyfolks. Right now manyfolks handles QoS and security preconditions. However, with MIKEY, this feature seems useless to establish secure channels. If somebody thinks that removing security preconditions from manyfolks is a bad idea, please speak up. Regards, 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 daemon@ns.ietf.org Fri Feb 22 18:04:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00360 for ; Fri, 22 Feb 2002 18:04:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA03996 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 18:04:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02423; Fri, 22 Feb 2002 17:45:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02321 for ; Fri, 22 Feb 2002 17:45:46 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29587 for ; Fri, 22 Feb 2002 17:45:41 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1MMjch15261; Fri, 22 Feb 2002 16:45:39 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1MMjcE21042; Fri, 22 Feb 2002 16:45:38 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g1MMjbE03710; Fri, 22 Feb 2002 17:45:37 -0500 (EST) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 17:45:36 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037473@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Pete Cordell'" , Adam Roach , Bob Penfield Cc: sip@ietf.org Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y Date: Fri, 22 Feb 2002 17:45:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Comments inline/gf > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: Friday, February 22, 2002 1:05 PM > To: Adam Roach; Bob Penfield > Cc: sip@ietf.org > Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message > body > > > Sure, if I want to be malicious I can do loads of things and > I don't have to > wait until I receive a SIP INVITE to do it. I can quite > easily just fire > out loads of UDP packets and gobble up bandwidth that way. After all, > saying something is PCMU when it is actually something else > is not going to > make the dialog of any use to the remote UA. > > I was really thinking more of a facilitating service rather > than one that > was enforcing. For example, it might be perfectly reasonable > to use CD > quality on the internal LAN, but not across the enterprise > access link. > Therefore a UA would want to declare that it can do CD > quality on the off > chance that it might be useful, but be happy if some helpful > intermediary > advised that you were probably going to loose most of your > packets in you do > it across the access link (not to mention getting your > managers upset). > Many, many people would be happy to work within those bounds, > and something > that helps them get the right mix at the right time can only > be helpful. > > Besides, who said there wasn't any stick here. The > considerate proxy could > have a nasty side to it and actually talk to the firewall, a > la Midcom, and > tell it to discard packets if this flow goes out of SLA. > Very similar to what 3GPP plan to do to police misbehaving clients. So basically you *ONLY GET* what you *ASK* for. The rest is thrown out. > So go ahead and build your client that interprets "PCMU/8000" as > "cd-quality-audio". I'm sure it won't be the worst > bastardisation of the > SIP spec. > > Pete. > > ============================================= > Pete Cordell > Tech-Know-Ware > pete@tech-know-ware.com > +44 1473 635863 > ============================================= > > ----- Original Message ----- > From: Adam Roach > To: 'Pete Cordell' ; Bob Penfield > > Cc: > Sent: 22 February 2002 16:39 > Subject: RE: [Sip] bis-07.9: proxies are not allowed to > modify message body > > > > > -----Original Message----- > > > From: Pete Cordell [mailto:pete@tech-know-ware.com] > > > > > > All I was thinking was, if it saw something like: > > > > > > m=audio 3456 RTP/AVP 0 7 > > > a=rtpmap:0 PCMU/8000 > > > a=rtpmap:7 LPC/44100/2 # Whatever linear CD quality is > > > m=video 2232 RTP/AVP 51 > > > b=6000 # Haven't checked SDP, but looking for 6 Mbits/s > > > a=rtpmap:51 H262/90000 > > > > > > in the messages that zipped past it, then it could change it to: > > > > > > m=audio 3456 RTP/AVP 0 # No CD quality > > > a=rtpmap:0 PCMU/8000 > > > m=video 2232 RTP/AVP 51 > > > b=128 # Limited to 128kbits/s > > > a=rtpmap:51 H262/90000 > > > > Trying to do this sort of enforcement in the SIP signalling > > layer is horribly, horribly misguided. If you need to enforce > > this sort of policy, you'll need support at the access level; > > there are a whole suite of protocols (RSVP, COPS, etc) designed > > for exactly this. > > > > If you try to do this with a SIP proxy, I will personally be > > one of the first people on your network to build a client that > > interprets "PCMU/8000" as "cd-quality-audio," give it to my > > friends, and send whatever media I feel like, regardless of > > what your meddlesome proxy thinks it has to say about it. > > > > And I guarantee that I won't be the last. > > > > /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 daemon@ns.ietf.org Fri Feb 22 19:00:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01673 for ; Fri, 22 Feb 2002 19:00:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA05985 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 19:00:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05360; Fri, 22 Feb 2002 18:36:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05337 for ; Fri, 22 Feb 2002 18:36:47 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01131 for ; Fri, 22 Feb 2002 18:36:43 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1MNajZc023532 for ; Sat, 23 Feb 2002 00:36:45 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1MNajYm019852 for ; Sat, 23 Feb 2002 01:36:45 +0200 (EET) Message-ID: <3C76D64C.E6564EC6@lmf.ericsson.se> Date: Sat, 23 Feb 2002 01:37:48 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] Bis-7.9: Chapter 17.2.3 References: <3C74F57C.6F6FC2EC@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, More on 17.2.3. If an ACK is received for a 2xx response, the branch-id is not the only parameter which will be different. To my understanding the Request-URI MAY also be different, since the UAC will use possible Record-Route and Contact headers in the 2xx response to create the ACK (the spec says that an ACK for a 2xx response shall be created like any other transaction within the dialog, so...) Regards, Christer Holmberg Ericsson Finland Christer Holmberg wrote: > Hi, > > A small issue on chapter 17.2.3 bis-7.9 > > Q1: > > "The ACK request matches a transaction if the Request- > URI, From tag, Call-ID, CSeq number (not the method), and top Via > header field match those of the INVITE request which created the > transaction,..." > > Does the top Via match also in ACKs for transactions which created a 2xx > response? Aren't the branch-ids different in the INVITE and ACK? > > "...and the To tag of the ACK matches the To tag of the > response sent by the server transaction. Matching is done based on > the matching rules defined for each of those header fields. The usage > > of the tag in the To header field helps disambiguate ACK for 2xx from > > ACK for other responses at a proxy, which may have forwarded both > responses (which can occur in unusual conditions)." > > Q2: > > Should it be mentioned that ACKs for re-INVITEs will include a To tag, > even if a non-2xx responses is acked (I KNOW re-INVITEs aren't forked, > and that the To tag is not needed for the same purpose in that case). > > Regards, > > Christer Holmberg > Ericsson 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 daemon@ns.ietf.org Fri Feb 22 20:11:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03087 for ; Fri, 22 Feb 2002 20:11:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA08993 for sip-archive@odin.ietf.org; Fri, 22 Feb 2002 20:11:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07935; Fri, 22 Feb 2002 19:45:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07908 for ; Fri, 22 Feb 2002 19:45:56 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02563 for ; Fri, 22 Feb 2002 19:45:50 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1N0jME16225; Fri, 22 Feb 2002 16:45:22 -0800 (PST) Received: from fluffyw2k (dhcp-128-107-142-47.cisco.com [128.107.142.47]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACC38197; Fri, 22 Feb 2002 16:45:31 -0800 (PST) From: "Cullen Jennings" To: "Bob Penfield" , Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message body Date: Fri, 22 Feb 2002 16:44:13 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <000f01c1bae9$2d7d0980$2300000a@acmepacket.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks for pointing this out - Updating UDP in a proxy might be a bad idea but some people will do it anyways. However, saying a proxy can't do things with bodies seem like a bad idea. Imagine that to achieve privacy and someone decides to encrypt a body. I don't see the reason to put this "MUST NOT" in. Can someone explain? > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Bob > Penfield > Sent: Thursday, February 21, 2002 7:05 AM > To: sip@ietf.org > Cc: Jonathan Rosenberg > Subject: [Sip] bis-07.9: proxies are not allowed to modify message body > > > Lines 2622-2623 say that "The proxy MUST NOT add to, modify, or remove the > message body". Does this mean that all existing Firewall Control Proxies > which update the SDP (like example 3.1.5 in draft-ietf-call-flows-05.txt) > non-compliant? I guess they will all have to be turned into B2BUAs. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.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 daemon@optimus.ietf.org Sat Feb 23 02:24:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17042 for ; Sat, 23 Feb 2002 02:24:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01562 for sip-archive@odin.ietf.org; Sat, 23 Feb 2002 02:24:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00336; Sat, 23 Feb 2002 01:57:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00304 for ; Sat, 23 Feb 2002 01:57:23 -0500 (EST) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08890 for ; Sat, 23 Feb 2002 01:57:21 -0500 (EST) Received: from jariws1 ([62.248.144.43]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020223065722.VUHL20539.fep06-app.kolumbus.fi@jariws1>; Sat, 23 Feb 2002 08:57:22 +0200 Message-ID: <020601c1bc37$5b2a3340$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Rohan Mahy" , , Cc: References: Subject: Re: [Sip] security preconditions Date: Sat, 23 Feb 2002 08:57:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit With MIKEY, the information about such-and-such security is also available in the SDP, and can be acted upon (and in fact without additional roundtrips). The only question that I have is whether there'd be any other security schemes that could apply, and would they need the preconditions? But I can't think of any practical example, and I think we should reduce overall SIP complexity unless we see a specific and real need for a feature. So, I agree with Gonzalo that the security preconditions should go away. Jari ----- Original Message ----- From: "Rohan Mahy" To: Sent: 23. helmikuuta 2002 0:23 Subject: [Sip] security preconditions > > Hi Gonzalo, > > I think it is still quite reasonable to signal that such-and-such security > is required before I ring. I think the "confirm" part if much less > important, because all the security negotiation protocols i know about are > reliable. > > thanks, > -rohan > > > > To: sip , mmusic > Subject: [Sip] Removing security preconditions from manyfolks > From: Gonzalo Camarillo > Date: Fri, 22 Feb 2002 21:34:44 +0200 > CC: "Fredrik Lindholm (ERA)" , Jonathan > Rosemberg , wtm@research.att.com > List-Id: Session Initiation Protocol > Sender: sip-admin@ietf.org > > -------------------------------------------------------------------------------- > > Hi, > > we are thinking of removing security preconditions from manyfolks. Right > now manyfolks handles QoS and security preconditions. However, with > MIKEY, this feature seems useless to establish secure channels. > > If somebody thinks that removing security preconditions from manyfolks > is a bad idea, please speak up. > > Regards, > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 24 02:22:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08385 for ; Sun, 24 Feb 2002 02:22:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28837 for sip-archive@odin.ietf.org; Sun, 24 Feb 2002 02:22:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27863; Sun, 24 Feb 2002 01:43:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27832 for ; Sun, 24 Feb 2002 01:43:44 -0500 (EST) Received: from dreamwiz.com ([211.187.28.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00255 for ; Sun, 24 Feb 2002 01:42:41 -0500 (EST) Message-Id: <200202240642.BAA00255@ietf.org> Reply-To: sexycodi@dreamwiz.com From: 예쁜코디 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 24 Feb 2002 15:42:59 +0900 Subject: [Sip] [코디정보] "7cm 커진 키"와 "Shark 쟈크 히틀러가방", 정말 멋져요! 새학기엔 새로운 모습으로.. [광고] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org SEXYcodi magazine
 SEXYcodi magazine Feb. 24, 2002 

Nicol Necol
   > 거리스케치 스쿨룩 커플룩 해외스케치 나어때?
This week codi
   > 이번주코디제안 ... 멋진 코디, 이렇게.. 어떠세요? - 앙드레 지니
      > ♣♧♣체형별 코디♧♣♧
      > ◀◀◀문양과 무늬별 코디▶▶▶
   > 섹시코디 이번주 코디 제안 > [뽀대남] [뽀대녀] =>
Magazine
   > 인터뷰 > 흑인음악창작동호회(SNP)-Defconn - 재원,진웅,영민
   > 싸이코 칼럼 > 우리의 사랑, 섹스 후에는 어떻게 달라질까? - 이규환 박사
SEXYcodi Magazine     
무료회원 등록하기     
1-Click만으로 OK!     
Seco Shop
  걍 이뿐 것들이구여~
키가 커지니까 자신감도 커지죠!
1.7~10cm 정도 다리가 길어 보여 쭉쭉빵빵!
2.인체공학적 키높이 까래의 설계로 발바닥의 형태에 알맞은 착용감.
3.하체의 다이어트 및 허리근육을 강화하는 효과.
4.싸이즈 230~270 까지
5.갑피재료:천연가죽, 겉창재료:알파창
화끈한 Shark 쟈크의 히틀러 가방 !
신학기 최고 뽀대 배낭가방입니다.
요모조모 옆에 내부에 다양한 주머니들..
실물 보시고 뿅~!가지 않는 분은 어떤 분일까?
한정수량이므로 서두르세요.












- "정보통신망이용촉진등에관한법률시행규칙개정령"에 의거 제목에 [광고]라 표시된 광고 메일입니다.
- 메일수신거부를 하실 경우 더 이상 메일이 가지 않습니다.
- 귀하의 email ID는 게시판 등 기타 공개된 자료에서 수집된 것으로 이상의 다른 개인정보는 없습니다.
- email 서비스를 원하지 않으시면 [수신거부]를 클릭하세요.
- 섹시코디 매거진 서비스를 계속 받고 싶으시면 [섹시코디 매거진 회원등록]을 한번 클릭하세요.
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Feb 24 11:42:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13076 for ; Sun, 24 Feb 2002 11:42:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17166 for sip-archive@odin.ietf.org; Sun, 24 Feb 2002 11:42:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16341; Sun, 24 Feb 2002 11:18:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16310 for ; Sun, 24 Feb 2002 11:18:02 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12684 for ; Sun, 24 Feb 2002 11:17:58 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1OGHqh02288; Sun, 24 Feb 2002 10:17:52 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1OGHqP06315; Sun, 24 Feb 2002 10:17:52 -0600 (CST) Received: from lmf.ericsson.se (rmt160155.am.ericsson.se [138.85.160.155]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA22350; Sun, 24 Feb 2002 10:17:49 -0600 (CST) Message-ID: <3C7919E4.C0290F95@lmf.ericsson.se> Date: Sun, 24 Feb 2002 18:50:44 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cullen Jennings CC: Bob Penfield , sip@ietf.org Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, If you do that, and you can prefectly do that if you wish, you have a B2BUA... I do not see a problem with that. I think the problem everybody has with this MUST NOT is the following. People think: "If the elements in my architecture are called proxies, I have a very good architecture, but if the elements in my architecture are B2BUAs, my architecture is crap."... and to make every architecture look good, they want to call stretch the concep of proxy so that all their elements are called "proxies". I do not think it is a big deal how we call these elements... let's call everything an OPES-element instead of "proxy" or "B2BUA" and everybody will be happy ;o) Regards, Gonzalo Cullen Jennings wrote: > > Thanks for pointing this out - Updating UDP in a proxy might be a bad idea > but some people will do it anyways. However, saying a proxy can't do things > with bodies seem like a bad idea. Imagine that to achieve privacy and > someone decides to encrypt a body. > > I don't see the reason to put this "MUST NOT" in. Can someone explain? > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Bob > > Penfield > > Sent: Thursday, February 21, 2002 7:05 AM > > To: sip@ietf.org > > Cc: Jonathan Rosenberg > > Subject: [Sip] bis-07.9: proxies are not allowed to modify message body > > > > > > Lines 2622-2623 say that "The proxy MUST NOT add to, modify, or remove the > > message body". Does this mean that all existing Firewall Control Proxies > > which update the SDP (like example 3.1.5 in draft-ietf-call-flows-05.txt) > > non-compliant? I guess they will all have to be turned into B2BUAs. > > > > cheers, > > (-:bob > > > > Robert F. Penfield > > Chief Software Architect > > Acme Packet, Inc. > > 130 New Boston Street > > Woburn, MA 01801 > > bpenfield@acmepacket.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 -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Sun Feb 24 22:33:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21350 for ; Sun, 24 Feb 2002 22:33:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA12397 for sip-archive@odin.ietf.org; Sun, 24 Feb 2002 22:33:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11284; Sun, 24 Feb 2002 22:03:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11254 for ; Sun, 24 Feb 2002 22:03:47 -0500 (EST) Received: from hyuee.hanyang.ac.kr (IDENT:root@hyuee.hanyang.ac.kr [166.104.46.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20157 for ; Sun, 24 Feb 2002 22:03:42 -0500 (EST) Received: from PROTEUS (IDENT:root@hyuee.hanyang.ac.kr [127.0.0.1] (may be forged)) (authenticated) by hyuee.hanyang.ac.kr (8.11.3/8.11.3) with ESMTP id g1P33KG18433 for ; Mon, 25 Feb 2002 12:03:20 +0900 Message-ID: <004e01c1bda8$93d4d980$ccfeffcb@PROTEUS> From: =?ks_c_5601-1987?B?wbbB37HZ?= To: Date: Mon, 25 Feb 2002 12:00:27 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C1BDF4.03A269D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Subject: [Sip] sip-request@ietf.org Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C1BDF4.03A269D0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 c3Vic2NyaWJlIA== ------=_NextPart_000_004B_01C1BDF4.03A269D0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ5MTMuMTEwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+c3Vic2NyaWJlIDwvRElWPjwvQk9E WT48L0hUTUw+DQo= ------=_NextPart_000_004B_01C1BDF4.03A269D0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 25 01:08:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23002 for ; Mon, 25 Feb 2002 01:08:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA22248 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 01:08:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17557; Mon, 25 Feb 2002 00:42:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17482 for ; Mon, 25 Feb 2002 00:42:27 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22757; Mon, 25 Feb 2002 00:42:25 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1P5fkw12442; Sun, 24 Feb 2002 21:41:46 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id VAA15919; Sun, 24 Feb 2002 21:41:44 -0800 (PST) Message-ID: <3C79CE9B.569814EC@cisco.com> Date: Mon, 25 Feb 2002 00:41:47 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip , mmusic , "Fredrik Lindholm (ERA)" , Jonathan Rosemberg , wtm@research.att.com Subject: Re: [Sip] Removing security preconditions from manyfolks References: <3C769D54.C3B4923A@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Not all media streams use RTP or SRTP, and there are other security mechanism than MIKEY. While I don't feel strongly about keeping the "security" precondition, I don't see much gained from removing it. Perhaps more importantly, since you are going to break the existing manyfolks-03 draft mechanism anyway, it would make sense to make the preconditions extensible (with suitable IANA registration procedures of course). -- Flemming Gonzalo Camarillo wrote: > Hi, > > we are thinking of removing security preconditions from manyfolks. Right > now manyfolks handles QoS and security preconditions. However, with > MIKEY, this feature seems useless to establish secure channels. > > If somebody thinks that removing security preconditions from manyfolks > is a bad idea, please speak up. > > Regards, > > Gonzalo > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.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 -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 25 02:59:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01836 for ; Mon, 25 Feb 2002 02:59:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA02344 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 02:59:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01701; Mon, 25 Feb 2002 02:33:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01672 for ; Mon, 25 Feb 2002 02:33:14 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01588 for ; Mon, 25 Feb 2002 02:33:10 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1P7Xii27505 for ; Mon, 25 Feb 2002 09:33:44 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 25 Feb 2002 09:33:12 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 09:33:11 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 25 Feb 2002 09:33:11 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7779073@esebe019.NOE.Nokia.com> Thread-Topic: T4 Thread-Index: AcG9zq2rM9vY43YdTZWEKxjt5thxrA== To: X-OriginalArrivalTime: 25 Feb 2002 07:33:12.0076 (UTC) FILETIME=[ADDA44C0:01C1BDCE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA01673 Subject: [Sip] T4 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I included this in my comments in bis-07, but never got an answer. Why is T4 limited to 5 seconds for timer K in the case of non-INVITE (section 17.1.2.2)? Regards, Hisham Khartabil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 25 05:44:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04128 for ; Mon, 25 Feb 2002 05:44:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA10324 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 05:44:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09270; Mon, 25 Feb 2002 05:23:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09239 for ; Mon, 25 Feb 2002 05:23:47 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03913 for ; Mon, 25 Feb 2002 05:23:43 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1PANEX03271 for ; Mon, 25 Feb 2002 05:23:15 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K40FGKX>; Mon, 25 Feb 2002 10:23:14 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E91D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Dean Willis'" , "'sip@ietf.org'" Subject: RE: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? Date: Mon, 25 Feb 2002 10:23:10 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 1) YES 2) YES 3) YES This of course does not prevent me commenting against a few issues I see as needing resolution which you will see in separate messages. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Dean Willis[SMTP:dean.willis@softarmor.com] > Sent: 15 February 2002 20:07 > To: sip@ietf.org > Cc: roahn@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com > Subject: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? > > The document draft-willis-sip-path-01.txt introduces the Path extension > header suggested by 3GPP in the Garcia 3GPP requirements draft in SIPPING. > > > The basic requirements being met are to 1) allow a UA to REGISTER a > contact which requires traversing a sequence of proxies on future messages > between the registrar and the UA, with that sequence dynamically > discovered during the REGISTER, and 2) allow a UA to discover from a > REGISTER response a sequence of proxies between it and a known proxy > offering outbound services for that UA. > > > The approach taken in the draft generalizes the 3GPP requirements by > allowing the sequences to be asymetric-- for example, the inbound and > outbound sequences might traverse different proxies, or there might only > be a sequence in one direction (A firewall proxy sits between UA and its > registrar, but UA does not use the registrar for outbound services). > > I'd like to poll for three things: > > 1) Do we want to address the requirements raised by 3GPP? > > 2) Do we have a general consensus on something like the PATH header as an > appopriate mechanism? > > 3) Is draft-willis-sip-path-01.txt a reasonable baseline document? > > If we have consensus on all three accounts, I propose to accept > draft-willis-sip-path-01.txt as a working group document, and pursue > future revisions as draft-ietf-sip.xx. > > If not, then please make a counterproposal. > > Opinions, please. > > -- > 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 daemon@optimus.ietf.org Mon Feb 25 06:01:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04256 for ; Mon, 25 Feb 2002 06:01:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA11288 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 06:01:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10293; Mon, 25 Feb 2002 05:44:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10261 for ; Mon, 25 Feb 2002 05:44:09 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04100 for ; Mon, 25 Feb 2002 05:44:04 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1PAhbX09067 for ; Mon, 25 Feb 2002 05:43:37 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K40FHM7>; Mon, 25 Feb 2002 10:43:36 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E922@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@ietf.org'" Date: Mon, 25 Feb 2002 10:43:32 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Sip] Path header: Independent operation in each direction, or common o peration for both directions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I am breaking out the issues that I think need more discussion relating to the proposed Path header. This is the first of those mails. Currently the mechanism specified for 3GPP looks very like Record-Route and it therefore collects the URLs of the proxies that wish to be on the path for future transactions by use of the header within the REGISTER request, and the response is merely a transport mechanism of the gathered information back to the UA from the registrar. This means that proxies so identified are intended to be in the path for both incoming and outgoing requests, as there is no means of distinguishing the two independently (or at least not with a single header, or separate lists within the common header). The mechanism proposed in Deans draft allows independent gathering of information in each direction; a proxy that wishes to be on the path in both incoming and outgoing directions must insert its URL in both the request and the response. This loses the commonality of the procedures with Record-Route. While both mechanisms work, having discussed the requirements with a limited set of people, we cannot think of a situation whereby a proxy would want to be on the incoming path and not on the outgoing path, and vice-versa. Certainly in 3GPP, the requirement needs to apply in both directions. Therefore the real question is are we developing a solution that does more that the requirements need, and therefore losing the commonality with Record-Route as a result. [While there may be advantages of code sharing with Record-Route for implementations, I am thinking more of the advantages to understanding the specification. People are more likely to understand and implement Path correctly if it works the same way as something else.] So, those who need operations independently in both directions, can you shout up and give us some examples. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: 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 From daemon@optimus.ietf.org Mon Feb 25 06:11:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04341 for ; Mon, 25 Feb 2002 06:11:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA11554 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 06:10:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10620; Mon, 25 Feb 2002 05:53:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10593 for ; Mon, 25 Feb 2002 05:53:35 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04194 for ; Mon, 25 Feb 2002 05:53:30 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16fIlB-00020D-00; Mon, 25 Feb 2002 12:53:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15482.6061.161030.257756@harjus.eng.song.fi> Date: Mon, 25 Feb 2002 12:53:33 +0200 To: "Drage, Keith (Keith)" Cc: "'Dean Willis'" , "'sip@ietf.org'" Subject: RE: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439E91D@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00439E91D@en0033exch001u.uk.lucent.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit i don't quite understand how people can say that the working group should introduce a new protocol mechanism (path header) although there has been no technical evidence that the existing mechanism are not enough for the user to accomplish the same thing as the with path header. there was an email exchange about this a few days ago, but i didn't get any response to my email where i described how the same thing can be done without any new message headers. this path header business started BEFORE we had LOOSE source routing in the bis. without loose source routing we would have needed something like path header, but not anymore when loose source routing. therefore there is no more any justification for the path header as a working group item. -- 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 daemon@optimus.ietf.org Mon Feb 25 06:33:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05595 for ; Mon, 25 Feb 2002 06:33:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13098 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 06:33:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11493; Mon, 25 Feb 2002 06:09:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11461 for ; Mon, 25 Feb 2002 06:09:37 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04294 for ; Mon, 25 Feb 2002 06:09:32 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16fJ0h-00020g-00; Mon, 25 Feb 2002 13:09:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15482.7023.873223.408167@harjus.eng.song.fi> Date: Mon, 25 Feb 2002 13:09:35 +0200 To: "Drage, Keith (Keith)" Cc: "'sip@ietf.org'" Subject: [Sip] Path header: Independent operation in each direction, or common o peration for both directions In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439E922@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00439E922@en0033exch001u.uk.lucent.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit we should also discuss if the 3g requirements are at all in line with the basic principles of the sip protocol. in sip, register transactions are independent of invite transactions and therefore there is no relationship between route recording among these two. -- 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 daemon@optimus.ietf.org Mon Feb 25 06:39:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05876 for ; Mon, 25 Feb 2002 06:39:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13601 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 06:39:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12055; Mon, 25 Feb 2002 06:23:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11984 for ; Mon, 25 Feb 2002 06:23:52 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05091; Mon, 25 Feb 2002 06:23:49 -0500 (EST) Message-Id: <200202251123.GAA05091@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 25 Feb 2002 06:23:48 -0500 Subject: [Sip] I-D ACTION:draft-camarillo-sip-sigcomp-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SigComp discovery for SIP Author(s) : G. Camarillo, M. Garcia Filename : draft-camarillo-sip-sigcomp-00.txt Pages : 6 Date : 22-Feb-02 This document defines a mechanism for SIP clients to discover SIP servers that support signalling compression. DNS NAPTR records are used for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-sip-sigcomp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-camarillo-sip-sigcomp-00.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-camarillo-sip-sigcomp-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020222110759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-sip-sigcomp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-sip-sigcomp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020222110759.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 25 08:52:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10063 for ; Mon, 25 Feb 2002 08:52:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20804 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 08:52:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19517; Mon, 25 Feb 2002 08:30:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19470 for ; Mon, 25 Feb 2002 08:30:19 -0500 (EST) Received: from protactinium.btinternet.com (protactinium.btinternet.com [194.73.73.176]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09270 for ; Mon, 25 Feb 2002 08:30:16 -0500 (EST) Received: from host213-122-1-243.in-addr.btopenworld.com ([213.122.1.243] helo=tkw) by protactinium.btinternet.com with smtp (Exim 3.22 #8) id 16fLCZ-0005e6-00; Mon, 25 Feb 2002 13:30:00 +0000 Message-ID: <003c01c1be00$94f5d1e0$0200000a@tkw> From: "Pete Cordell" To: "Gonzalo Camarillo" , "Cullen Jennings" Cc: References: <3C7919E4.C0290F95@lmf.ericsson.se> Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body Date: Mon, 25 Feb 2002 13:29:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo, I think there are two problems here... 1) There are two definitions of a B2BUA floating around. The definition of this list/group is "Any intermediary device that is not a Proxy as defined in bis." And the definition in bis is quite clearly that it is a UAS back to back with a UAC, and it maintains dialog state. There are many devices that fall into the first category that are not necessarily built as defined by the second. 2) The group has managed to create (intentionally or otherwise) a smear campaign against B2BUAs. So the definition becomes "Any intermediary device that is not a proxy as defined in bis. NOTE: these devices are EVIL (c.f. OPES)." For me the main concern about a back to back UAS / UAC implementation (perhaps with the two instances joined by something other than SIP) is that they lose feature transparency. It's the loss of feature transparency that is the problem, not that it is a B2BUA. There are many devices that are not pure proxies that do not lose feature transparency, and even back to back UAS / UACs can be built that still have feature transparency most of the time. Thus people are trying to build innovative products delivering exciting services beyond simple call routing, that are good netizens, but they are getting tarred as bad implementations by people that have never seen them simply because they are not pure proxies. Added to that, there are likely to be many bad implementations of pure proxies, but nothing is said about that. In the light of that, one shouldn't be too surprised that there is some kick back from the people building these devices. After all, wasn't the promise of SIP that it could offer lots of exciting new services? Now an intermediary device can only do what I can already do on my domestic phone line. Anything else comes with a WARNING, which is not very helpful for a technology attempting to build a new world order of exciting, new and radical services ! To move forward, I think we need to:- 1) Either understand that anything that is not a pure proxy is not necessarily a B2BUA (That really is just a matter of definitions. I don't care what you call it. Maybe Application-aware Proxy.), or relax the definition of a proxy at least so it allows changing the body. 2) Have people appreciate that some of the most exciting services, including many that will make SIP worth developing, will end up being implemented with elements of B2BUA in them, and if they want SIP to be successful, they shouldn't be prejudiced against them and perpetuating the smear campaign. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Gonzalo Camarillo To: Cullen Jennings Cc: Bob Penfield ; Sent: 24 February 2002 16:50 Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body > Hi, > > If you do that, and you can prefectly do that if you wish, you have a > B2BUA... I do not see a problem with that. > > I think the problem everybody has with this MUST NOT is the following. > People think: "If the elements in my architecture are called proxies, I > have a very good architecture, but if the elements in my architecture > are B2BUAs, my architecture is crap."... and to make every architecture > look good, they want to call stretch the concep of proxy so that all > their elements are called "proxies". > > I do not think it is a big deal how we call these elements... let's call > everything an OPES-element instead of "proxy" or "B2BUA" and everybody > will be happy ;o) > > Regards, > > Gonzalo > > > Cullen Jennings wrote: > > > > Thanks for pointing this out - Updating UDP in a proxy might be a bad idea > > but some people will do it anyways. However, saying a proxy can't do things > > with bodies seem like a bad idea. Imagine that to achieve privacy and > > someone decides to encrypt a body. > > > > I don't see the reason to put this "MUST NOT" in. Can someone explain? > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Bob > > > Penfield > > > Sent: Thursday, February 21, 2002 7:05 AM > > > To: sip@ietf.org > > > Cc: Jonathan Rosenberg > > > Subject: [Sip] bis-07.9: proxies are not allowed to modify message body > > > > > > > > > Lines 2622-2623 say that "The proxy MUST NOT add to, modify, or remove the > > > message body". Does this mean that all existing Firewall Control Proxies > > > which update the SDP (like example 3.1.5 in draft-ietf-call-flows-05.txt) > > > non-compliant? I guess they will all have to be turned into B2BUAs. > > > > > > cheers, > > > (-:bob > > > > > > Robert F. Penfield > > > Chief Software Architect > > > Acme Packet, Inc. > > > 130 New Boston Street > > > Woburn, MA 01801 > > > bpenfield@acmepacket.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 > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Mon Feb 25 09:48:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12308 for ; Mon, 25 Feb 2002 09:48:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24037 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 09:48:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23439; Mon, 25 Feb 2002 09:32:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23408 for ; Mon, 25 Feb 2002 09:32:02 -0500 (EST) Received: from ws1-6.us4.outblaze.com (205-158-62-53.outblaze.com [205.158.62.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11628 for ; Mon, 25 Feb 2002 09:31:59 -0500 (EST) Received: (qmail 31095 invoked by uid 1001); 25 Feb 2002 14:31:32 -0000 Message-ID: <20020225143132.31094.qmail@mail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [64.208.49.61] by ws1-6.us4.outblaze.com with http for jfr@post.com; Mon, 25 Feb 2002 22:31:32 +0800 From: "JF Rey" To: sip@ietf.org Date: Mon, 25 Feb 2002 22:31:32 +0800 X-Originating-Ip: 64.208.49.61 X-Originating-Server: ws1-6.us4.outblaze.com Content-Transfer-Encoding: 7bit Subject: [Sip] bis08 - telephone-subscriber in rfc2806 and escaped characters Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I know that this topic has already been discussed. I found this in the archives : From: Jonathan Rosenberg To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] bis-06 BNF issues [snip] > > 13) telephone-subscriber should match definition in RFC2806 which also > allows several other characters, for example: > > * # A B C D p w ( ) Yes. That one has been fixed. The spec now points to rfc2806 for the BNF. Not sure thats the right thing either, since that bnf allows for some stuff that is not allowed in the user part... For now, it references 2806 and says you need to escape stuff that is not allowed. Why must these characters be escaped in the user part ? What would be the problem if they were not escaped ? Jean-Francois. -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup 1 cent a minute calls anywhere in the U.S.! http://www.getpennytalk.com/cgi-bin/adforward.cgi?p_key=RG9853KJ&url=http://www.getpennytalk.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 daemon@optimus.ietf.org Mon Feb 25 11:04:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15343 for ; Mon, 25 Feb 2002 11:04:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28921 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 11:04:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27274; Mon, 25 Feb 2002 10:42:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27243 for ; Mon, 25 Feb 2002 10:42:27 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14328 for ; Mon, 25 Feb 2002 10:42:21 -0500 (EST) From: bernhard.honeisen@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PFgXZ06120 for ; Mon, 25 Feb 2002 17:42:34 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Feb 2002 17:42:23 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 17:42:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? Date: Mon, 25 Feb 2002 17:42:23 +0200 Message-ID: Thread-Topic: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? Thread-Index: AcG96tWaZUwZX1i5SPyQT9gQx2oEWgAJdNqg To: , Cc: , X-OriginalArrivalTime: 25 Feb 2002 15:42:23.0610 (UTC) FILETIME=[04BAEDA0:01C1BE13] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA27244 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Juha! In certain network configurations (e.g. the IMS of 3GPP) such behavior makes sense. The registar (let's call it S-CSCF) is one of the hops, every INVITE has to pass, because the S-CSCF is at the same time the element, which has to be visited for the user's outbound services. If there is a security (e.g. firewall) element between the UA and the S-CSCF (let's call this security element I-CSCF), the same mechanism can be used so that the INVITE can be routed smoothly through, without heavy processing in the proxies. These kind of scenarios I believe cannot be solved using your earlier proposal. The LOOSE routing does not fully cover the requirments, which are addressed by the Path header proposal. Conclusion: Your proposal does not fullfill all requirements, which can be solved by the Path header proposal. cheers, Bernie -----Original Message----- From: ext jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] Sent: 25. February 2002 12:54 To: Drage, Keith (Keith) Cc: 'Dean Willis'; 'sip@ietf.org' Subject: RE: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? i don't quite understand how people can say that the working group should introduce a new protocol mechanism (path header) although there has been no technical evidence that the existing mechanism are not enough for the user to accomplish the same thing as the with path header. there was an email exchange about this a few days ago, but i didn't get any response to my email where i described how the same thing can be done without any new message headers. this path header business started BEFORE we had LOOSE source routing in the bis. without loose source routing we would have needed something like path header, but not anymore when loose source routing. therefore there is no more any justification for the path header as a working group item. -- 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 daemon@optimus.ietf.org Mon Feb 25 11:22:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16185 for ; Mon, 25 Feb 2002 11:22:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00064 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 11:22:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28767; Mon, 25 Feb 2002 11:02:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28740 for ; Mon, 25 Feb 2002 11:02:38 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15277 for ; Mon, 25 Feb 2002 11:02:34 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16fNaF-0002dX-00; Mon, 25 Feb 2002 18:02:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15482.24603.827167.353503@harjus.eng.song.fi> Date: Mon, 25 Feb 2002 18:02:35 +0200 To: Cc: , , Subject: RE: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit bernhard.honeisen@nokia.com writes: > In certain network configurations (e.g. the IMS of > 3GPP) such behavior makes sense. > The registar (let's call it S-CSCF) is one of the hops, > every INVITE has to pass, because the S-CSCF is at the > same time the element, which has to be visited for the > user's outbound services. fine, then simply create an SVR record for the home domain of the UA that points to the S-CSCF. if the UA wants to use services of its home domain for an invite, then the UA creates a loose source route that contains this S-CSCF and sends the invite the outbound proxy that it has learned via dhcp from the visited domain. > If there is a security (e.g. firewall) element between > the UA and the S-CSCF (let's call this security element > I-CSCF), the same mechanism can be used so that the > INVITE can be routed smoothly through, without heavy > processing in the proxies. > These kind of scenarios I believe cannot be solved > using your earlier proposal. see above. using the outbound proxy of the visited domain should get the messages through local firewalls. > The LOOSE routing does not fully cover the requirments, > which are addressed by the Path header proposal. > > Conclusion: > Your proposal does not fullfill all requirements, > which can be solved by the Path header proposal. conclusion: you still fail to show why path message is needed. -- 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 daemon@optimus.ietf.org Mon Feb 25 12:13:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19258 for ; Mon, 25 Feb 2002 12:13:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA04807 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 12:13:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02217; Mon, 25 Feb 2002 11:55:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02110 for ; Mon, 25 Feb 2002 11:55:00 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18209 for ; Mon, 25 Feb 2002 11:54:55 -0500 (EST) From: bernhard.honeisen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PGt4Z09797 for ; Mon, 25 Feb 2002 18:55:05 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Feb 2002 18:54:53 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 18:54:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? Date: Mon, 25 Feb 2002 18:54:53 +0200 Message-ID: Thread-Topic: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? Thread-Index: AcG+FdyNYPPYuEltQHuBG6MpUfNvGgAAK9Cg To: Cc: , , X-OriginalArrivalTime: 25 Feb 2002 16:54:53.0876 (UTC) FILETIME=[25B0D740:01C1BE1D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA02111 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Juha! Comments inline... T: Bernie > -----Original Message----- > From: ext jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: 25. February 2002 18:03 > To: Honeisen Bernhard (NET/Helsinki) > Cc: drage@lucent.com; dean.willis@softarmor.com; sip@ietf.org > Subject: RE: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? > > > bernhard.honeisen@nokia.com writes: > > > In certain network configurations (e.g. the IMS of > > 3GPP) such behavior makes sense. > > The registar (let's call it S-CSCF) is one of the hops, > > every INVITE has to pass, because the S-CSCF is at the > > same time the element, which has to be visited for the > > user's outbound services. > > fine, then simply create an SVR record for the home domain of the UA > that points to the S-CSCF. Let's assume, we have 10 million users, which are distributed more of less equally through many instances of S-CSCFs. At registration time, some resources are reserved on a particular instance of S-CSCF, so that the call setup times can be minimized, and security associations can be set up. Thus, the call has to be routed to a specific instance of S-CSCF With your proposal of using the DNS SRV (I guess SVR is a typo) mechanism, it would work only if it would not matter, which instance of S-CSCF is handling the served UA of this INVITE. But in certain architectures it does matter. Note: The S-CSCF are allocated dynamically and could be based on the services, a user has subscribed for. > if the UA wants to use services of its home > domain for an invite, then the UA creates a loose source route that > contains this S-CSCF and sends the invite the outbound proxy > that it has learned via dhcp from the visited domain. How does the user know about the exact instance of the S-CSCF, which is prepared for handling his calls? The Path header can also be used in the terminating case (i.e. registar -> UA) Let's assume, every UA has a default inbound proxy (the same as DOP), and let's call this proxy P-CSCF. When the call arrives at the registrar, it does not only need to insert the registred Contact (i.e. the UA) address, but also the P-CSCF address, which has to be passed before the UA. (The P-CSCF is needed for controlling the radio resources on the air interface.) How would the S-CSCF know, which is the correct P-CSCF of this particular user? I don't think picking the correct Via entry of the register request is a robust solution. Note: Also P-CSCF is allocated dynamically. > > If there is a security (e.g. firewall) element between > > the UA and the S-CSCF (let's call this security element > > I-CSCF), the same mechanism can be used so that the > > INVITE can be routed smoothly through, without heavy > > processing in the proxies. > > These kind of scenarios I believe cannot be solved > > using your earlier proposal. > > see above. using the outbound proxy of the visited domain > should get the messages through local firewalls. > > > The LOOSE routing does not fully cover the requirments, > > which are addressed by the Path header proposal. > > > > Conclusion: > > Your proposal does not fullfill all requirements, > > which can be solved by the Path header proposal. > > conclusion: you still fail to show why path message is needed. What about 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 daemon@optimus.ietf.org Mon Feb 25 13:40:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24013 for ; Mon, 25 Feb 2002 13:40:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA10025 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 13:40:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08628; Mon, 25 Feb 2002 13:23:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08600 for ; Mon, 25 Feb 2002 13:23:28 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23115 for ; Mon, 25 Feb 2002 13:23:24 -0500 (EST) Received: from DWILLISS1 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1PIMWB19520; Mon, 25 Feb 2002 12:22:32 -0600 Message-ID: <000c01c1be29$642b7230$8b036e3f@DWILLISS1> From: "Dean Willis" To: "Gonzalo Camarillo" , "Cullen Jennings" Cc: "Bob Penfield" , References: <3C7919E4.C0290F95@lmf.ericsson.se> Subject: Why Proxies are Good and B2BUAs May Not Be (was Re: [Sip] bis-07.9: proxies are not allowed to modify message body) Date: Sun, 24 Feb 2002 22:49:09 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo wrote: > you have a > B2BUA... I do not see a problem with that. > > I think the problem everybody has with this MUST NOT is the following. > People think: "If the elements in my architecture are called proxies, I > have a very good architecture, but if the elements in my architecture > are B2BUAs, my architecture is crap."... and to make every architecture > look good, they want to call stretch the concep of proxy so that all > their elements are called "proxies". > > I do not think it is a big deal how we call these elements... let's call > everything an OPES-element instead of "proxy" or "B2BUA" and everybody > will be happy ;o) Here's my worry about that. There are REASONS why proxies are as limited as they are in the specification. It's to keep them from breaking other things. This has come up time and time again in 3GPP -- almost every time that we fudge the line between proxy and B2BUA, we end up breaking something else. The proxy rules are, I believe, most effective in providing "forward compatibility" -- a basic proxy will work, as expected, with any reasonable future SIP extension method type, extension header, or payload. In fact, that's part of the rule we use in determining "reasonableness" for extensions. No such restraint applies to B2BUAs. If you "break the rules" of a proxy, all compatibility bets are off, and problems become very likely. It's like running naked through Central Park at night with a bunch of $20 bills taped to your backside -- you MIGHT not have an unfortunate encounter, and if you do you'll hear a whole lot of "I told you so!"s. -- 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 daemon@optimus.ietf.org Mon Feb 25 13:50:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24502 for ; Mon, 25 Feb 2002 13:50:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA10552 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 13:50:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05470; Mon, 25 Feb 2002 12:28:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05439 for ; Mon, 25 Feb 2002 12:28:43 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19950 for ; Mon, 25 Feb 2002 12:28:37 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16fOvX-0002hp-00; Mon, 25 Feb 2002 19:28:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15482.29767.119068.10495@harjus.eng.song.fi> Date: Mon, 25 Feb 2002 19:28:39 +0200 To: Cc: , , Subject: RE: [Sip] Query: Adopt draft-willis-sip-path-xx as WG doc? In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit bernhard.honeisen@nokia.com writes: > Let's assume, we have 10 million users, which are distributed > more of less equally through many instances of S-CSCFs. > At registration time, some resources are reserved on a particular > instance of S-CSCF, so that the call setup times can be minimized, > and security associations can be set up. > Thus, the call has to be routed to a specific instance of S-CSCF i don't buy that argument. you can use dns based load balancing instead of a nailed down s-cscf. nailed down anything is a very bad idea from resiliency point of view. you can also store your security stuff in a database to which all s-cscfs have access. > With your proposal of using the DNS SRV (I guess SVR is a typo) > mechanism, it would work only if it would not matter, which > instance of S-CSCF is handling the served UA of this INVITE. > But in certain architectures it does matter. is should not matter. see above. > How does the user know about the exact instance of the S-CSCF, > which is prepared for handling his calls? according to the sip protocol specification, if an ua gets a list of srv records for a domain, then ALL of them must be able to handle the calls of that domain. what you try to do is something that is against the specification. please call your stuff something else than sip and move the discussion to the 3g list. > The Path header can also be used in the terminating case > (i.e. registar -> UA) > Let's assume, every UA has a default inbound proxy > (the same as DOP), and let's call this proxy P-CSCF. > When the call arrives at the registrar, it does not only > need to insert the registred Contact (i.e. the UA) address, > but also the P-CSCF address, which has to be passed > before the UA. (The P-CSCF is needed for controlling the > radio resources on the air interface.) > > How would the S-CSCF know, which is the correct P-CSCF > of this particular user? this is a matter of implementation. for example, the s-cscf could find out the domain of the visited network and route the invite to its proxy. > What about now? no better than before. if you want to implement the g3 walled garden and force customers messages to be routed via weird ways in stead of the normal way, you get into these kind of weird proposals. -- 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 daemon@optimus.ietf.org Mon Feb 25 14:28:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26198 for ; Mon, 25 Feb 2002 14:28:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12583 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 14:28:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11538; Mon, 25 Feb 2002 14:03:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11509 for ; Mon, 25 Feb 2002 14:03:13 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25139 for ; Mon, 25 Feb 2002 14:03:09 -0500 (EST) Received: from DWILLISS1 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1PJ2fB19792 for ; Mon, 25 Feb 2002 13:02:41 -0600 Message-ID: <003001c1be2e$ffa5e600$8b036e3f@DWILLISS1> From: "Dean Willis" To: References: <15482.24603.827167.353503@harjus.eng.song.fi> Date: Mon, 25 Feb 2002 13:02:39 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Path scenario outside of 3GPP requirements Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Keith and Juha have requested a scenario outside of 3GPP wherein a mechanism like PATH is useful. Keith is specifically interested in services where the PATH may not be symmetric. Here's one. It's the "non-adjacent registrar" problem that I've been I have a SIP phone at home that I use for business purposes. I use a registrar/location server at the office to provide a contact point for the address-of-record sip:dwillis@dynamicsoft.com. Today, my phone sends a REGISTER to this registrar, associating sip:dwillis@63.64.250.83 with sip:dwillis@dynamicsoft.com. Normally, people making a SIP call to me use the SRV procedures and find my location server. They send it an INVITE. It looks in the registration database, finds the registration from my home and office phones, and forks out INVITES to those phones. I don't have outbound services from this proxy/location server, it's just used for inbound calls. Pretty basic so far, right? Ok, being a paranoid sort, I really want a home proxy-firewall that also offers outbound services for calls placed from my home SIP phone. Once I have this installed, the IP address of my phone becomes 192.168.139.3 . . . So, what gets registered on the dynamicsoft registrar? As is, the phone generates a contact of sip:192.168.139.3. It passes this in a REGISTER thru my proxy-firewall.The registrar dutifully records this a a contact for sip:dwillis@dynamicsoft.com But what happens when I get a call? The location server tries to fork the INVITE to the the address 192.168.139.3, finds that it has no route to that address, and fails. What we need is a way to get the incoming INVITE sent from the location server to my proxy-firewall instead of directly to the registered contact. Three proposals have been suggested: 1) Give my home phone knowledge of the proxy it's behind, and have it insert an adjusted Contact: in the REGISTER. This of course requires replacing all the phone software, and is a pain in the behind (I have a 3Com phone right now, no software updates available as far as I know). 2) Have the firewall-proxy patch the contact address in the REGISTER to be dwillis@proxyip. This would probably work, but has the annoying habit of breaking extended-digest authentication (which, since I'm using standard digest, is ok for me, but makes it not a generally good solution). 3) Have the firewall proxy add a Path: header containing its own IP address on the REGISTER. The registrar then stores both the Contact: value and the Path: value from REGISTER. So, assume we use #3. (Warning, I'm using an easy-read synopsis format of SIP messages, so some details are missing) 1) Phone sends REGISTER with Contact: sip:dwillis@192.168.139.3 toward registrar "dynamicsoft.com". 2) Proxy adds Path: 63.6.250.83 to the Register. 3) Registrar stores Contact and Path values for identity dwillis@dynamicsoft.com . . . . we're registered . . . 4) Juha calls sip:dwillis@dynamcisoft.com from his deskphone in Finland 5) Using SRV procedures, INVITE is delivered to location server "dynamicsoft.com". 6) Location server proxies INVITE toward my home phone, preloading the Route: header with the loose route value stored earlier (Path). 7) Loose routing delivers INVITE to my home proxy firewall at 63.64.250.83 8) Proxy firewall strips off loose route element, delivers INVITE to phone at 192.168.39.3 9) My phone rings, I say "Paiva" (caller ID, eh) and Juha and I discuss the magic of Path and tell jokes at Keith's expense. Note that I don't want OUTGOING calls from my home phone routed through my office location server. That would just be a waste of CPU . . . (that's why the asymmetric mechanism, Keith!) -- 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 daemon@optimus.ietf.org Mon Feb 25 16:14:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00184 for ; Mon, 25 Feb 2002 16:14:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA18705 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 16:14:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17412; Mon, 25 Feb 2002 15:47:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17385 for ; Mon, 25 Feb 2002 15:47:20 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29343 for ; Mon, 25 Feb 2002 15:47:17 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1PKidZq005588; Mon, 25 Feb 2002 15:44:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Feb 2002 15:46:44 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36300A4@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Pete Cordell'" , Gonzalo Camarillo , Cullen Jennings Cc: sip@ietf.org Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y Date: Mon, 25 Feb 2002 15:46:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org We're getting a bit far off into a meta-discussion here, but I feel compelled to rebut some of your contentions. > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > For me the main concern about a back to back UAS / UAC implementation > (perhaps with the two instances joined by something other > than SIP) is that > they lose feature transparency. It's the loss of feature > transparency that > is the problem, not that it is a B2BUA. There are many > devices that are not > pure proxies that do not lose feature transparency They can have feature transparancy *for* *certain* *features*. One of the reasons that "proxy" is defined to be such a narrow term is to allow the protocol to evolve without destroying the functionality of nodes in the middle of the network. For example, let's take the imaginary (if somewhat contrived) extension "ip-reversed," which indicates that IP addresses in the SDP will be in reversed order. Now, you have something you claim to be a proxy in the middle of the network, except it helpfully attempts to tweak the SDP if it thinks I'm coming through a NAT. It thinks it's a proxy, so it doesn't feel bound to obey the "Require: ip-reversed" header present in the message. Boom. This thing, no matter how similar it is to a proxy, has just broken the network by doing something that proxies are "not supposed to do." In order to perform this sort of processing in a way that will work into the future, any node that does something that proxies aren't allowed to do MUST pay attention to the "Require" headers. I don't really care about the semantics of what you end up calling these things, as long as you don't confuse the issue by calling them "proxies." > Thus people are trying to build innovative products > delivering exciting > services beyond simple call routing, that are good netizens, > but they are > getting tarred as bad implementations by people that have > never seen them > simply because they are not pure proxies. They're not bad implementations. They *are* throttles to effective deployment of new services, since they must process, honor, and understand everything that comes by in a "Require" header. For example, if I and one of my friends got the newest, spiffiest terminals that had a *really* *cool* service -- one that necessarily used a "Require" header -- but one of the nodes that my call was routed thorough didn't support it, I promise you'd have me calling customer service to figure out why my new $800 phone didn't work as advertised. And you can be *darn* sure that I'd be pissed -- probably even pissed enough to go shopping for a new provider -- when I found out it's because you have a node in your network blocking my spiffy service, and that it'll take several months to a year for you to get an upgrade in place. Is this an intentional smear campaign? No; it's just a statement of the ramifications of nodes pretending to be proxies doing things that proxies are not "supposed" to do. Are such impacts negative? It depends on whether you want to anger your end users; most people would say yes. But I've been the customer to uncountable companies who have taken the decision to piss of their customers (presumably) for some sort of trade off. It really comes down to a business decision. > After all, wasn't the promise of SIP that it could offer lots > of exciting > new services? Now an intermediary device can only do what I > can already do > on my domestic phone line. Of course, exciting services can *only* come from the *middle* of the network. I can't beleive that, until now, I had considered the possibility that the *endpoints* could provide nifty services. How naive of me (and the others who have been working on SIP for the past four years) to think that the web model of providing services might actually work. > 1) Either understand that anything that is not a pure proxy is not > necessarily a B2BUA (That really is just a matter of > definitions. I don't > care what you call it. Maybe Application-aware Proxy.), or relax the > definition of a proxy at least so it allows changing the body. You can't change a body that you can't read or don't understand. Extensions can (and do) create a situation in which the bodies will be different than what is understood by nodes in the middle of the network. If these nodes require comprehension of such information, they are not proxies. It's more than terminology; it's about which parts of the SIP spec apply to the behavior you implement. > 2) Have people appreciate that some of the most exciting > services, including > many that will make SIP worth developing, will end up being > implemented with > elements of B2BUA in them, and if they want SIP to be successful, they > shouldn't be prejudiced against them and perpetuating the > smear campaign. As I said above, it's not a smear campaign; it's an awareness campaign. Once you start doing things that proxies don't do, you aren't a proxy. That makes you liable for following all of the other rules in SIP, such as processing of "Require" headers. That's really *all* it comes down to. Some people think this is a Bad Thing, for the reasons I've described above. You might not. If you want to create and sell, or deploy and maintain such nodes, you are free to do so -- but you really should understand the logical ramifications of doing so. /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 daemon@optimus.ietf.org Mon Feb 25 16:20:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00337 for ; Mon, 25 Feb 2002 16:20:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA18850 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 16:20:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18308; Mon, 25 Feb 2002 16:01:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18279 for ; Mon, 25 Feb 2002 16:01:23 -0500 (EST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29880 for ; Mon, 25 Feb 2002 16:01:20 -0500 (EST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 25 Feb 2002 13:00:04 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Feb 2002 13:00:04 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Feb 2002 12:59:57 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Feb 2002 13:00:04 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Mon, 25 Feb 2002 12:58:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] Path scenario outside of 3GPP requirements Date: Mon, 25 Feb 2002 12:58:05 -0800 Message-ID: Thread-Topic: [Sip] Path scenario outside of 3GPP requirements thread-index: AcG+LzEj6mo/9bceQ8qKhiZAl0jWYAAD9Dpw From: "Christian Huitema" To: "Dean Willis" , X-OriginalArrivalTime: 25 Feb 2002 20:58:05.0748 (UTC) FILETIME=[1F1FCF40:01C1BE3F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA18280 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > 1) Give my home phone knowledge of the proxy it's behind, and have it > insert > an adjusted Contact: in the REGISTER. This of course requires replacing > all > the phone software, and is a pain in the behind (I have a 3Com phone right > now, no software updates available as far as I know). There is actually a spec on how to do just that -- check the UPNP standard for Internet Gateway Devices at http://www.upnp.org/resources/standards.asp. I know of at least one SIP UA that implements this spec. Failing that, your best bet is to migrate to IPv6. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 25 17:43:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02646 for ; Mon, 25 Feb 2002 17:43:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22694 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 17:43:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21429; Mon, 25 Feb 2002 17:12:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21360 for ; Mon, 25 Feb 2002 17:12:40 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01777; Mon, 25 Feb 2002 17:12:36 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1PMBm826379; Mon, 25 Feb 2002 17:11:48 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Feb 2002 16:11:43 -0600 Message-ID: <70565611B164D511957A001083FCDD5601870100@VA02> From: "Peterson, Jon" To: "'Flemming Andreasen'" , Gonzalo Camarillo Cc: sip , mmusic , "Fredrik Lindholm (ERA)" , Jonathan Rosemberg , wtm@research.att.com Subject: RE: [Sip] Removing security preconditions from manyfolks Date: Mon, 25 Feb 2002 16:11:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org One of the reasons why you need a special preconditions flag (and the rest of the manyfolks apparatus) for QoS is because you use a separate protocol (like RSVP) to negotiate the reserved path end-to-end. Nothing about SIP or SDP or RTP would otherwise tell you that reservation of the path has been expected or achieved. IMHO, this would be unwise, and probably infeasible, for a security mechanism. The use of sRTP e2e will be obvious to the respective user agents, for example, and the parameters of the sRTP session should be correlated easily to information in SDP or SIP so the UAs can have verifiable expectations about the session's security. I think all e2e media security mechanisms will probably need to have these sorts of properties (regardless of whether or not you use RTP, secure media will still be secured, and that will always be obvious to the user agents). Therefore, I think that a separate preconditions flag for security should always be superfluous for any useful security mechanism. I think we can ditch it. That much said, I don't necessarily oppose the IANA registration suggested by Flemming below, although I think as a motivation for it we'd need to understand, generally speaking, what sort of other preconditions people might find desirable. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Sunday, February 24, 2002 9:42 PM > To: Gonzalo Camarillo > Cc: sip; mmusic; Fredrik Lindholm (ERA); Jonathan Rosemberg; > wtm@research.att.com > Subject: Re: [Sip] Removing security preconditions from manyfolks > > > Not all media streams use RTP or SRTP, and there are other security > mechanism than MIKEY. While I don't feel strongly about keeping the > "security" precondition, I don't see much gained from removing it. Perhaps > more importantly, since you are going to break the existing manyfolks-03 > draft mechanism anyway, it would make sense to make the preconditions > extensible (with suitable IANA registration procedures of course). > > -- Flemming > > > Gonzalo Camarillo wrote: > > > Hi, > > > > we are thinking of removing security preconditions from > manyfolks. Right > > now manyfolks handles QoS and security preconditions. However, with > > MIKEY, this feature seems useless to establish secure channels. > > > > If somebody thinks that removing security preconditions > from manyfolks > > is a bad idea, please speak up. > > > > Regards, > > > > Gonzalo > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.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 > > -- > Flemming Andreasen > Cisco Systems > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Mon Feb 25 17:58:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03114 for ; Mon, 25 Feb 2002 17:58:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23215 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 17:58:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22736; Mon, 25 Feb 2002 17:44:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22711 for ; Mon, 25 Feb 2002 17:44:20 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02676 for ; Mon, 25 Feb 2002 17:44:16 -0500 (EST) Received: from DWILLISS1 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1PMhlB21337; Mon, 25 Feb 2002 16:43:48 -0600 Message-ID: <013e01c1be4d$e33c1790$8b036e3f@DWILLISS1> From: "Dean Willis" To: "Christian Huitema" , References: Subject: Re: [Sip] Path scenario outside of 3GPP requirements Date: Mon, 25 Feb 2002 16:43:40 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian wrote: > Dea nWrote > > 1) Give my home phone knowledge of the proxy it's behind, and have it > > insert > > an adjusted Contact: in the REGISTER. This of course requires > replacing > > all > > the phone software, and is a pain in the behind (I have a 3Com phone > right > > now, no software updates available as far as I know). > > There is actually a spec on how to do just that -- check the UPNP > standard for Internet Gateway Devices at > http://www.upnp.org/resources/standards.asp. I know of at least one SIP > UA that implements this spec. Don't all the UPNP documents say "Microsoft Corporation. All Rights Reserved" ? ;-) Ok, insert my original example, but instead of a home proxy firewall I'm in a hotel using pay-per-view IP transport and have to register through a proxy that handles policy decisions . . . (gee, sounds exactly like one-half of the 3GPP problem set). The point is, we keep seeing the same pattern again and again -- the need to register a "contact" which is a vector rather than a singular node. > Failing that, your best bet is to migrate to IPv6. yeah, like THAT woudn't impose change requirements on my existing obsolete-but-beloved phone . . . -- 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 daemon@optimus.ietf.org Mon Feb 25 19:31:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05024 for ; Mon, 25 Feb 2002 19:31:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA27674 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 19:31:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26530; Mon, 25 Feb 2002 19:05:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26507 for ; Mon, 25 Feb 2002 19:05:04 -0500 (EST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04664 for ; Mon, 25 Feb 2002 19:05:01 -0500 (EST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 25 Feb 2002 16:03:45 -0800 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Feb 2002 16:03:44 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Feb 2002 16:03:44 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Feb 2002 16:03:43 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Mon, 25 Feb 2002 16:01:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] Path scenario outside of 3GPP requirements Date: Mon, 25 Feb 2002 16:01:46 -0800 Message-ID: Thread-Topic: [Sip] Path scenario outside of 3GPP requirements thread-index: AcG+TYLCYBIxEDoGQoynP27O4vcaUgAChqvQ From: "Christian Huitema" To: "Dean Willis" , X-OriginalArrivalTime: 26 Feb 2002 00:01:46.0693 (UTC) FILETIME=[C81E8F50:01C1BE58] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA26508 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Christian wrote: > > Dea nWrote > > > 1) Give my home phone knowledge of the proxy it's behind, and have it > > > insert > > > an adjusted Contact: in the REGISTER. This of course requires > > replacing > > > all > > > the phone software, and is a pain in the behind (I have a 3Com phone > > right > > > now, no software updates available as far as I know). > > > > There is actually a spec on how to do just that -- check the UPNP > > standard for Internet Gateway Devices at > > http://www.upnp.org/resources/standards.asp. I know of at least one SIP > > UA that implements this spec. > > Don't all the UPNP documents say "Microsoft Corporation. All Rights > Reserved" ? ;-) Actually, according to the text itself, "UPnP Forum Members have rights and licenses defined by Section 3 of the UPnP Membership Agreement to use and reproduce the Standardized DCP in UPnP Compliant Devices", and according to the membership agreement, "There is no fee or other charge to execute this Membership Agreement and thereby become a Member." > Ok, insert my original example, but instead of a home proxy firewall I'm > in > a hotel using pay-per-view IP transport and have to register through a > proxy > that handles policy decisions . . . (gee, sounds exactly like one-half of > the 3GPP problem set). Why exactly would you have to register through such a proxy? What is wrong with using a TLS/SSL connection to your corporate server, and placing the connection through it? > > Failing that, your best bet is to migrate to IPv6. > > yeah, like THAT woudn't impose change requirements on my existing > obsolete-but-beloved phone . . . It would definitely have an impact. OTOH, it would make a number of scenarios much simpler. And, since you mention 3GPP, isn't it the case that 3GPP devices are supposed to use IPv6? -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 25 21:51:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07496 for ; Mon, 25 Feb 2002 21:51:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA03100 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 21:52:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA01863; Mon, 25 Feb 2002 21:20:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA01836 for ; Mon, 25 Feb 2002 21:20:06 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06225 for ; Mon, 25 Feb 2002 21:20:01 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 26 Feb 2002 02:20:20 UT Received: from jolaptop ([80.3.216.239]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 26 Feb 2002 02:22:38 +0000 From: "Jo Hornsby" To: "Christer Holmberg" , Subject: RE: [Sip] Bis-8: To tag question Date: Tue, 26 Feb 2002 02:24:44 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3C761961.8C5E7408@lmf.ericsson.se> X-OriginalArrivalTime: 26 Feb 2002 02:22:38.0317 (UTC) FILETIME=[75AE09D0:01C1BE6C] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Chapter 8.2.6.2 says that a server MUST use the same To tag in all > responses, both provisional and final. So, if a UAS eg sends 18x with a > To tag, and then 4xx, my understanding is that the To tag must be in > BOTH of those responses. > > However, chapter 17.2.3 says: > > "The usage of the tag in the To header field helps disambiguate ACK for > 2xx from > ACK for other responses at a proxy, which may have forwarded both > responses (which can occur in unusual conditions)." > > Is this really true? IF the non-2xx responses had a To tag, shouldn't > the ACK for that response use the same To tag? In that case a server > can't use the To tag in the ACK to check if the ACK was for a 2xx-, or > non-2xx-,response. > > Is there a bug, or have I missunderstood something? I think the parenthesized "which can occur in unusual conditions" is the important thing to note here. Basically, this case arises when a proxy thinks it has exhausted all branches, and returns some non-2xx final response. Then, seemingly out of the blue, a UA returns a 2xx. The proxy is forced to forward this 2xx; however, the tag in the 2xx will be different from the tag in the non-2xx, so any ACKs can be disambiguated. - Jo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Feb 25 21:54:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07546 for ; Mon, 25 Feb 2002 21:54:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA03212 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 21:55:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02461; Mon, 25 Feb 2002 21:30:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02411 for ; Mon, 25 Feb 2002 21:30:46 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06335 for ; Mon, 25 Feb 2002 21:30:41 -0500 (EST) Received: from madrid.ericsson.se (madrid.es.eu.ericsson.se [159.107.53.220]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1Q2USZc028648; Tue, 26 Feb 2002 03:30:28 +0100 (MET) Received: from lmf.ericsson.se by madrid.ericsson.se (SMI-8.6/SMI-SVR4) id DAA27614; Tue, 26 Feb 2002 03:30:15 +0100 Message-ID: <3C7AFAEB.AE788960@lmf.ericsson.se> Date: Tue, 26 Feb 2002 05:03:07 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip CC: Allison Mankin , Dean Willis , Biran Rosen , Joerg Ott , wtm@research.att.com, Jonathan Rosemberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Manyfolks version 04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, I have just submitted a new version of the manyfolks draft. Until it appears in the archives, you can fetch it from: http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.pdf http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.txt About the authorship of this draft, the ADs and the WG chairs decided that all the coauthors of previous versions but Bill had to be moved to a Contributors Section. The deadline for this draft is very close, so I would appreciate that folks read the draft and send comments as soon as possible. I have removed security preconditions (per mailing list discussion), but added a token that can be used to define new precondition types (the only type currently defined is "qos"). The draft uses two attributes: desired-status and current-status. When the current status reaches (or goes beyond) the desired status the preconditions are met. Instead of defining an absolute ordering for these two attributes, I have defined status tables. They are abstractions of the preconditions carried in the SDP. These tables help explain how status synchronization between both user agents is performed and when exactly all the preconditions are met. Feedback is appreciated, Best regards, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Mon Feb 25 23:07:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09499 for ; Mon, 25 Feb 2002 23:07:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA06773 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 23:07:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05611; Mon, 25 Feb 2002 22:44:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05512 for ; Mon, 25 Feb 2002 22:44:20 -0500 (EST) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09155 for ; Mon, 25 Feb 2002 22:44:13 -0500 (EST) From: mgovind@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hss.hns.com (8.11.2/8.11.2) with SMTP id g1Q3P7l22005; Tue, 26 Feb 2002 08:55:07 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B6C.0013A255 ; Tue, 26 Feb 2002 09:04:27 +0530 X-Lotus-FromDomain: HSSBLR To: "JF Rey" cc: sip@ietf.org Message-ID: <65256B6C.0013A067.00@sampark.hss.hns.com> Date: Tue, 26 Feb 2002 09:04:22 +0530 Subject: Re: [Sip] bis08 - telephone-subscriber in rfc2806 and escaped characters Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, The escaping is done primarly to avoid confusions while parsing the url. For more details please refer rfc2396 (Uniform Resource Identifiers (URI): Generic Syntax) regds mahesh "JF Rey" on 02/25/2002 08:01:32 PM To: sip@ietf.org cc: (bcc: Mahesh Govind/HSSBLR) Subject: [Sip] bis08 - telephone-subscriber in rfc2806 and escaped characters I know that this topic has already been discussed. I found this in the archives : From: Jonathan Rosenberg To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] bis-06 BNF issues [snip] > > 13) telephone-subscriber should match definition in RFC2806 which also > allows several other characters, for example: > > * # A B C D p w ( ) Yes. That one has been fixed. The spec now points to rfc2806 for the BNF. Not sure thats the right thing either, since that bnf allows for some stuff that is not allowed in the user part... For now, it references 2806 and says you need to escape stuff that is not allowed. Why must these characters be escaped in the user part ? What would be the problem if they were not escaped ? Jean-Francois. -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup 1 cent a minute calls anywhere in the U.S.! http://www.getpennytalk.com/cgi-bin/adforward.cgi?p_key=RG9853KJ&url=http:/ /www.getpennytalk.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 daemon@optimus.ietf.org Mon Feb 25 23:46:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10383 for ; Mon, 25 Feb 2002 23:46:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA08080 for sip-archive@odin.ietf.org; Mon, 25 Feb 2002 23:46:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07180; Mon, 25 Feb 2002 23:24:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07151 for ; Mon, 25 Feb 2002 23:24:08 -0500 (EST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09684 for ; Mon, 25 Feb 2002 23:24:05 -0500 (EST) From: coreygates@attbi.com Received: from rwcrwbc57 ([204.127.198.46]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020226042338.NOPI2951.rwcrmhc53.attbi.com@rwcrwbc57> for ; Tue, 26 Feb 2002 04:23:38 +0000 Received: from [12.236.42.11] by rwcrwbc57; Tue, 26 Feb 2002 04:23:37 +0000 To: sip@ietf.org Date: Tue, 26 Feb 2002 04:23:37 +0000 X-Mailer: AT&T Message Center Version 1 (Nov 29 2001) Message-Id: <20020226042338.NOPI2951.rwcrmhc53.attbi.com@rwcrwbc57> Subject: [Sip] Retry-After delta-seconds NIT in bis08 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In section 14.2 (line 2321-2324) Retry-After is described as having a value in units of 10 ms. Thus it seems that a decimal value of Retry-After is possible. However, in the BNF, delta-seconds is defined as 1*DIGIT (no decimal point) (line 5704) Thus is seems that only a whole number of seconds is possible. I know this is small, but these two inconsistent descriptions should probably be normalized if possible. Corey _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 00:36:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10865 for ; Tue, 26 Feb 2002 00:36:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA10158 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 00:36:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA09181; Tue, 26 Feb 2002 00:05:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA09150 for ; Tue, 26 Feb 2002 00:05:39 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10601 for ; Tue, 26 Feb 2002 00:05:37 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1Q559800463 for ; Tue, 26 Feb 2002 00:05:09 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Feb 2002 23:05:04 -0600 Message-ID: <70565611B164D511957A001083FCDD5601870103@VA02> From: "Peterson, Jon" To: "'sip@ietf.org'" Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y Date: Mon, 25 Feb 2002 23:05:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Forbidding proxies to modify message bodies does not improve security; it's the other way around. The fact that we can secure messages bodies end-to-end entails that proxies may not be entitled to modify bodies. Mostly, this just reinforces the fact that bodies are intended for end-to-end use. Many of the misconceptions about this issue arise from a belief that the operators of proxy servers are necessarily a privileged participant in a SIP network. Actually, if you are a 'network operator', and you want to inspect and modify bodies, you must have a trust relationship with users - they must accept that you, the network operator, are the appropriate recipient of SIP message bodies, and they must secure MIME bodies with that expectation (any encrypted bodies must be explicitly intended to be decrypted by the network operator). In that sense, the network operator becomes the destination of the request, and thus more or less a user - and this is why the discussion naturally transitions to B2BUAs. I think this in no way diminishes the value of network-based service that require access to SIP message bodies - it just shows that if you want to offer these sorts of services, you require that users trust you in a way that they aren't asked to trust proxy servers, which operate only on headers. Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 03:44:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20781 for ; Tue, 26 Feb 2002 03:44:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA27437 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 03:44:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25631; Tue, 26 Feb 2002 03:07:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25600 for ; Tue, 26 Feb 2002 03:07:53 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20343 for ; Tue, 26 Feb 2002 03:07:49 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA29372; Tue, 26 Feb 2002 09:06:54 +0100 (MET) Subject: Re: Why Proxies are Good and B2BUAs May Not Be (was Re: [Sip] bis-07.9: proxies are not allowed to modify message body) To: "Dean Willis" Cc: "Gonzalo Camarillo" , "Cullen Jennings" , "Bob Penfield" , Date: Tue, 26 Feb 2002 09:06:53 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 02/26/2002 09:06:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dean, This is the definition of a proxy server, taken from bis-08: Proxy, Proxy Server: An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity closer to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it. As you see, the first part is fully inline with your mail: "A proxy server primarily plays the role of routing, ..." However, can you explain me how you apply your mail to the second part : "Proxies are also useful for enforcing policy...", "A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it" Best regards Juan Carlos "Dean Willis" @ietf.org on 25/02/2002 05:49:09 Sent by: sip-admin@ietf.org To: "Gonzalo Camarillo" , "Cullen Jennings" cc: "Bob Penfield" , Subject: Why Proxies are Good and B2BUAs May Not Be (was Re: [Sip] bis-07.9: proxies are not allowed to modify message body) Gonzalo wrote: > you have a > B2BUA... I do not see a problem with that. > > I think the problem everybody has with this MUST NOT is the following. > People think: "If the elements in my architecture are called proxies, I > have a very good architecture, but if the elements in my architecture > are B2BUAs, my architecture is crap."... and to make every architecture > look good, they want to call stretch the concep of proxy so that all > their elements are called "proxies". > > I do not think it is a big deal how we call these elements... let's call > everything an OPES-element instead of "proxy" or "B2BUA" and everybody > will be happy ;o) Here's my worry about that. There are REASONS why proxies are as limited as they are in the specification. It's to keep them from breaking other things. This has come up time and time again in 3GPP -- almost every time that we fudge the line between proxy and B2BUA, we end up breaking something else. The proxy rules are, I believe, most effective in providing "forward compatibility" -- a basic proxy will work, as expected, with any reasonable future SIP extension method type, extension header, or payload. In fact, that's part of the rule we use in determining "reasonableness" for extensions. No such restraint applies to B2BUAs. If you "break the rules" of a proxy, all compatibility bets are off, and problems become very likely. It's like running naked through Central Park at night with a bunch of $20 bills taped to your backside -- you MIGHT not have an unfortunate encounter, and if you do you'll hear a whole lot of "I told you so!"s. -- 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 daemon@optimus.ietf.org Tue Feb 26 04:15:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21242 for ; Tue, 26 Feb 2002 04:15:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA29299 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 04:15:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27921; Tue, 26 Feb 2002 03:53:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27895 for ; Tue, 26 Feb 2002 03:53:41 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20936 for ; Tue, 26 Feb 2002 03:53:37 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1Q8raB17979 for ; Tue, 26 Feb 2002 09:53:36 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1Q8rXmK019151 for ; Tue, 26 Feb 2002 10:53:33 +0200 (EET) Message-ID: <3C7B4D4A.FE2C78DB@lmf.ericsson.se> Date: Tue, 26 Feb 2002 10:54:34 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Bis-8: merged requests Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A small comment on merged requests. Chapter 8.2.2.2 says: "If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the To tag, From tag, Call-ID, CSeq exactly match (including tags) those associated with an ongoing transaction, but the branch-ID in the topmost Via does not match, the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction." The text doesn't say anything about the value of the Request-URI. I think we all know it may be different in the merged request, but shouldn't it be mentioned in the text, since the Request-URI after all IS one of the transaction mapping parameters? Regards, Christer Holmberg Ericsson 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 daemon@optimus.ietf.org Tue Feb 26 04:19:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21336 for ; Tue, 26 Feb 2002 04:19:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA29537 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 04:19:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27755; Tue, 26 Feb 2002 03:49:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27723 for ; Tue, 26 Feb 2002 03:49:49 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20846 for ; Tue, 26 Feb 2002 03:49:44 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1Q8njB14503; Tue, 26 Feb 2002 09:49:45 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1Q8nfmK018975; Tue, 26 Feb 2002 10:49:42 +0200 (EET) Message-ID: <3C7B4C62.2567A4BF@lmf.ericsson.se> Date: Tue, 26 Feb 2002 10:50:42 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby CC: sip@ietf.org Subject: Re: [Sip] Bis-8: To tag question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > >Chapter 8.2.6.2 says that a server MUST use the same To tag in all > >responses, both provisional and final. So, if a UAS eg sends 18x with a > >To tag, and then 4xx, my understanding is that the To tag must be in > >BOTH of those responses. > > > >However, chapter 17.2.3 says: > > > >"The usage of the tag in the To header field helps disambiguate ACK for > >2xx from ACK for other responses at a proxy, which may have forwarded both > > >responses (which can occur in unusual conditions)." > > > >Is this really true? IF the non-2xx responses had a To tag, shouldn't > >the ACK for that response use the same To tag? In that case a server > >can't use the To tag in the ACK to check if the ACK was for a 2xx-, or > >non-2xx-,response. > > > >Is there a bug, or have I missunderstood something? > I think the parenthesized "which can occur in unusual > conditions" is the important thing to note here. True. However, I think the text should still be clear - no matter how unusual the case described is :) > Basically, this case arises when a proxy thinks it has > exhausted all branches, and returns some non-2xx final > response. Then, seemingly out of the blue, a UA returns > a 2xx. The proxy is forced to forward this 2xx; > however, the tag in the 2xx will be different from the > tag in the non-2xx, so any ACKs can be disambiguated. Yes. The tag will be different for each final response, but there will still be a tag in each final response (2xx or non-2xx), so that's why I wondered how the server can decide if an ACK is for a 2xx just by looking if there is a tag or not (that's at least how I understood the text, so I appologise if I missunderstood)... Of course, using the tag in the ACK it will help finding the corresponding INVITE transaction, but that's the case no matter what the final response (2xx or non-2xx) was, so... Thanks for your reply! Regards, Christer Holmberg Ericsson 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 daemon@optimus.ietf.org Tue Feb 26 05:12:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22220 for ; Tue, 26 Feb 2002 05:12:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA02563 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 05:12:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01186; Tue, 26 Feb 2002 04:43:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01156 for ; Tue, 26 Feb 2002 04:43:43 -0500 (EST) Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21791 for ; Tue, 26 Feb 2002 04:43:38 -0500 (EST) Received: from il-tlv-mbdg2.icomverse.com (il-tlv-mbdg2.icomverse.com [10.115.244.42]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g1Q9eBQ26078 for ; Tue, 26 Feb 2002 11:40:11 +0200 Received: by IL-TLV-MBDG2 with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Feb 2002 11:43:40 +0200 Message-ID: From: "Fuxbruner, Amihay" To: sip@ietf.org Subject: [Sip] CANCEL and 100 Trying Question Date: Tue, 26 Feb 2002 11:43:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, Probably answered long ago, but I couldn't find it :-( 2543 says UAC sends CANCEL after receiving 1xx only, to prevent the case where UAS get CANCEL before INVITE. In case UAC sends CANCEL after receiving 100 from next proxy, still UAS may get CANCEL before INVITE. Is this correct? Thanks, Amihay Fuxbruner System Engineering - Signaling R&D Comverse _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 05:37:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22652 for ; Tue, 26 Feb 2002 05:37:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA03940 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 05:37:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02853; Tue, 26 Feb 2002 05:19:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02821 for ; Tue, 26 Feb 2002 05:19:03 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22293 for ; Tue, 26 Feb 2002 05:18:58 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QAJAZ23377 for ; Tue, 26 Feb 2002 12:19:11 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Feb 2002 12:19:01 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 12:19:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Subject: RE: [Sip] CANCEL and 100 Trying Question Date: Tue, 26 Feb 2002 12:19:00 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7779078@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] CANCEL and 100 Trying Question Thread-Index: AcG+qkVEARHwRAeJQRSqDWs5YQdxoAAA/A1A To: , X-OriginalArrivalTime: 26 Feb 2002 10:19:01.0274 (UTC) FILETIME=[027327A0:01C1BEAF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA02822 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Fuxbruner, Amihay [mailto:Amihay_Fuxbruner@icomverse.com] > Sent: Tuesday, February 26, 2002 11:44 AM > To: sip@ietf.org > Subject: [Sip] CANCEL and 100 Trying Question > > > Hello, > > Probably answered long ago, but I couldn't find it :-( > > 2543 says UAC sends CANCEL after receiving 1xx only, to > prevent the case > where UAS get CANCEL before INVITE. > In case UAC sends CANCEL after receiving 100 from next proxy, > still UAS may > get CANCEL before INVITE. > > Is this correct? No, The CANCEL following the exact path as the INVITE. From section 9.1 "The destination address, port, and transport for the CANCEL MUST be identical to those used to send the original request." regards, Hisham > > Thanks, > > Amihay Fuxbruner > System Engineering - Signaling R&D > Comverse > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Tue Feb 26 06:20:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23123 for ; Tue, 26 Feb 2002 06:20:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA05972 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 06:20:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04605; Tue, 26 Feb 2002 05:59:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04576 for ; Tue, 26 Feb 2002 05:58:57 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22868 for ; Tue, 26 Feb 2002 05:58:52 -0500 (EST) Received: (qmail 3241 invoked from network); 26 Feb 2002 11:01:40 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 26 Feb 2002 11:01:40 -0000 Received: from stake.com (unknown [10.50.1.52]) by cam-relay.atstake.com (Postfix) with SMTP id 8522022817; Tue, 26 Feb 2002 05:56:37 -0500 (EST) Message-ID: <3C7B6A0E.5050308@stake.com> Date: Tue, 26 Feb 2002 10:57:18 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Fuxbruner, Amihay" Cc: sip@ietf.org Subject: Re: [Sip] CANCEL and 100 Trying Question References: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Amihay, Nothing to do with the way SIP routing the messages between SIP elements. We are talking about Networking here, so stating that the CANCEL need to follow the same path as the INVITE is half of the pint :P This also depends on the medium you are using. If you are using a closed network which you control the QoS, or at least there is not a lot of latency, than the CANCEL should not arrive before the INVITE. A contributing fact is that CANCEL will follow the same SIP path as the INVITE, and since there are not a lot of IP routing possibilities, than, again, the CANCEL should arrive after the INVITE. In an open environment (Internet) anything can happen, and your messages are more prone to error/routing possibilities on their path to the target. They may take different routing paths from one SIP element to another (IP based). You are not controlling the network, and there are no QoS based mechanisms, so it is possible that your CANCEL arrive before the INVITE. Ofir Fuxbruner, Amihay wrote: > Hello, > > Probably answered long ago, but I couldn't find it :-( > > 2543 says UAC sends CANCEL after receiving 1xx only, to prevent the case > where UAS get CANCEL before INVITE. > In case UAC sends CANCEL after receiving 100 from next proxy, still UAS may > get CANCEL before INVITE. > > Is this correct? > > Thanks, > > Amihay Fuxbruner > System Engineering - Signaling R&D > Comverse > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 06:28:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23240 for ; Tue, 26 Feb 2002 06:28:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA06188 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 06:28:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05478; Tue, 26 Feb 2002 06:08:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05446 for ; Tue, 26 Feb 2002 06:07:59 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22988 for ; Tue, 26 Feb 2002 06:07:55 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA27766; Tue, 26 Feb 2002 12:07:53 +0100 (MET) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA11198; Tue, 26 Feb 2002 12:07:47 +0100 (MET) Received: by mchh159e.mch.pn.siemens.de with Internet Mail Service (5.5.2653.19) id <1M5GBVS2>; Tue, 26 Feb 2002 12:07:27 +0100 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6081795@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Gonzalo Camarillo'" , sip Subject: RE: [Sip] Manyfolks version 04 Date: Tue, 26 Feb 2002 12:07:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Shouldn't this draft include a section to officially define the new method UPDATE ? I can't find any definition of this new method in the list of references of this draft. - Ya-Ching _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 06:28:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23256 for ; Tue, 26 Feb 2002 06:28:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA06203 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 06:28:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05281; Tue, 26 Feb 2002 06:01:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05243 for ; Tue, 26 Feb 2002 06:01:55 -0500 (EST) Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22953 for ; Tue, 26 Feb 2002 06:01:50 -0500 (EST) Received: from host213-122-6-244.in-addr.btopenworld.com ([213.122.6.244] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #8) id 16ffMj-0005pz-00; Tue, 26 Feb 2002 11:01:49 +0000 Message-ID: <001e01c1beb5$0d533740$0200000a@tkw> From: "Pete Cordell" To: "Adam Roach" Cc: References: <9BF66EBF6BEFD942915B4D4D45C051F36300A4@DYN-TX-EXCH-001.dynamicsoft.com> Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body Date: Tue, 26 Feb 2002 11:01:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Adam Roach > We're getting a bit far off into a meta-discussion here, but I feel > compelled to rebut some of your contentions. > > > -----Original Message----- > > From: Pete Cordell [mailto:pete@tech-know-ware.com] > > For me the main concern about a back to back UAS / UAC implementation > > (perhaps with the two instances joined by something other > > than SIP) is that > > they lose feature transparency. It's the loss of feature > > transparency that > > is the problem, not that it is a B2BUA. There are many > > devices that are not > > pure proxies that do not lose feature transparency > > They can have feature transparancy *for* *certain* *features*. > One of the reasons that "proxy" is defined to be such a narrow > term is to allow the protocol to evolve without destroying the > functionality of nodes in the middle of the network. For example, > let's take the imaginary (if somewhat contrived) extension > "ip-reversed," which indicates that IP addresses in the SDP > will be in reversed order. Now, you have something you claim > to be a proxy in the middle of the network, except it > helpfully attempts to tweak the SDP if it thinks I'm coming > through a NAT. It thinks it's a proxy, so it doesn't feel > bound to obey the "Require: ip-reversed" header present in > the message. > > Boom. > > This thing, no matter how similar it is to a proxy, has just broken > the network by doing something that proxies are "not supposed to do." > > In order to perform this sort of processing in a way that will work > into the future, any node that does something that proxies aren't > allowed to do MUST pay attention to the "Require" headers. I don't > really care about the semantics of what you end up calling these > things, as long as you don't confuse the issue by calling them > "proxies." > Would you prefer that you pushed me into producing a full B2BUA and I bumped you because you had a Require: header in there? Would you be happy when you called in to complain when I say "I would liked to have been as transparent to your service as I could, but the standard forced me to reject your transaction." ? It wouldn't make me feel a whole lot better. And why don't I ring you up and say 'your new service broke my proxy'..... This is a protocol design issue and not fundamentally an issue about modifying bodies. For example, you could easily have defined Body-Require:, or you could say that if the body no longer means what it used to mean, then give it a new Content-Type, e.g. Content-Type: application/really-cool-sdp. Or define: Content-Type: application/sdp-with-requires; require=really-cool. Actually this is an excellent example of why we should be honest about what is going to happen in the real world and say that proxies can change bodies. If we don't, then people will design services that will break the system, and that helps no one. > > Thus people are trying to build innovative products > > delivering exciting > > services beyond simple call routing, that are good netizens, > > but they are > > getting tarred as bad implementations by people that have > > never seen them > > simply because they are not pure proxies. > > They're not bad implementations. They *are* throttles to effective > deployment of new services, since they must process, honor, and > understand everything that comes by in a "Require" header. For > example, if I and one of my friends got the newest, spiffiest > terminals that had a *really* *cool* service -- one that necessarily > used a "Require" header -- but one of the nodes that my call was > routed thorough didn't support it, I promise you'd have me calling > customer service to figure out why my new $800 phone didn't work > as advertised. And you can be *darn* sure that I'd be pissed -- > probably even pissed enough to go shopping for a new provider -- > when I found out it's because you have a node in your network > blocking my spiffy service, and that it'll take several months to > a year for you to get an upgrade in place. > Why should your potentially system breaking service be good, while my service is bad. A good protocol should accommodate both service types. (BTW - Surely you paid too much for your phone. Does it do ISDN also ?!) > Is this an intentional smear campaign? No; it's just a statement > of the ramifications of nodes pretending to be proxies doing > things that proxies are not "supposed" to do. But the protocol designers say what a proxy should do. I'm saying that the current situation is not good for the long term. Between what the standard says now, and what people want to do with it, the SIP infrastructure will be broken. > Are such impacts > negative? It depends on whether you want to anger your end users; > most people would say yes. But I've been the customer to uncountable > companies who have taken the decision to piss of their customers > (presumably) for some sort of trade off. It really comes down > to a business decision. > > > After all, wasn't the promise of SIP that it could offer lots > > of exciting > > new services? Now an intermediary device can only do what I > > can already do > > on my domestic phone line. > > Of course, exciting services can *only* come from the *middle* of > the network. I can't beleive that, until now, I had considered the > possibility that the *endpoints* could provide nifty services. > How naive of me (and the others who have been working on SIP for > the past four years) to think that the web model of providing > services might actually work. Typical crap that I would expect from some IETF members: if in trouble - manipulate words and flame. Calm down and consider the following - where did I say that ALL services had to be delivered from the middle. That's correct, no where. Many services will be delivered by end-systems. BUT many services will hopefully be delivered by middle systems also. Hopefully it's not too much of a revelation to you that some services fit better in the end-systems and some fit better in the middle. Blimey, some can even work in both locations !!!! Or are you saying that you KNOW for a fact that the routing that proxies provide is the only service that can be delivered in the middle? ... cut rest as duplicated stuff already covered ... > > /a This is getting us no where. I have raised the issue that services in the middle would like to change bodies. A number of e-mails in this discussion have confirmed this view. I also pointed out that a number of these services are not implemented as full B2BUAs as defined in the standard. This e-mail demonstrates that there is a real issue if people are not aware that bodies might change. I've pointed out that the situation is not improved if body modifying services are made into compliant B2BUAs (they will bump everything that has a Require: header whereas at least body modifying Proxies would carry on). From these observations I have postulated that, if nothing is done the SIP infrastructure will be broken and consequently the services that SIP can offer will not be as rich as some had hoped. I am prepared to help work on solutions to these problems (I don't think it will take much solving), but if the inner circle do not wish to consider these issues, then that's fine by me also. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 06:53:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23606 for ; Tue, 26 Feb 2002 06:53:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA07562 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 06:53:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06150; Tue, 26 Feb 2002 06:25:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06120 for ; Tue, 26 Feb 2002 06:25:32 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23194 for ; Tue, 26 Feb 2002 06:25:29 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1QBP0T21092 for ; Tue, 26 Feb 2002 06:25:00 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K40G3CY>; Tue, 26 Feb 2002 11:24:59 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00468F401@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: sip@ietf.org Date: Tue, 26 Feb 2002 11:24:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Question on Unify draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In this draft, in figure 4 (solution for One-of-N Codecs problem), it uses the a=inactive in the first offer to stop the callee to send media. But is it possible that the callee answers the offer by changing the a=inactive to a=active and starts to send media immediately? If this is possible, then this solution won't work, am I right? Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 09:11:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00403 for ; Tue, 26 Feb 2002 09:11:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA14534 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 09:11:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13278; Tue, 26 Feb 2002 08:47:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13249 for ; Tue, 26 Feb 2002 08:47:44 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29111 for ; Tue, 26 Feb 2002 08:47:39 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1QDle129734 for ; Tue, 26 Feb 2002 08:47:40 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K40G4XK>; Tue, 26 Feb 2002 13:47:39 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00468F456@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Gonzalo Camarillo , sip Cc: Allison Mankin , Dean Willis , Biran Rosen , Joerg Ott , wtm@research.att.com, Jonathan Rosemberg Subject: RE: [Sip] Manyfolks version 04 Date: Tue, 26 Feb 2002 13:47:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The question I have in mind is why we need "local" and "remote" here. "a=des:qos mandatory local sendrecv" generated by the offerer has no meaning to the answerer, because this is something that the answerer can not help, because this is your(offerer's) network not mine(answerer's)! And "a=des:qos mandatory remote sendrecv" generated by the offerer has the same meaning as "a=des:qos mandatory e2e sendrecv" from the anserer's point of view. I think only "e2e" is needed. Because as a user, I don't care what local access network another end is using, actually I even don't know what protocol the other end is using for QoS, what I want is end to end QoS for my the video or audio streams. Therefore, it is up to the user agent to intercept and decide whether e2e condition is met or not. For example, if the answerer receives an offer requiring e2e QoS sendrecv, but the answerer only supports local network QoS protocol and uses Differv in the core network to provide end to end QoS, therefore this call should not fail just because the answerer doesn't support RSVP. So answerer just needs to finish the local network QoS reservation and ACKs the offerer that e2e is met. In a word, for the answerer's point of view, "e2e"="remote". If an offerer doesn't support e2e QoS protocol, it can still put "e2e" in its offer, because from the offerer's point of view, "e2e"="local". Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 26 February 2002 3:03 To: sip Cc: Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott; wtm@research.att.com; Jonathan Rosemberg Subject: [Sip] Manyfolks version 04 Hello, I have just submitted a new version of the manyfolks draft. Until it appears in the archives, you can fetch it from: http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.pdf http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.txt About the authorship of this draft, the ADs and the WG chairs decided that all the coauthors of previous versions but Bill had to be moved to a Contributors Section. The deadline for this draft is very close, so I would appreciate that folks read the draft and send comments as soon as possible. I have removed security preconditions (per mailing list discussion), but added a token that can be used to define new precondition types (the only type currently defined is "qos"). The draft uses two attributes: desired-status and current-status. When the current status reaches (or goes beyond) the desired status the preconditions are met. Instead of defining an absolute ordering for these two attributes, I have defined status tables. They are abstractions of the preconditions carried in the SDP. These tables help explain how status synchronization between both user agents is performed and when exactly all the preconditions are met. Feedback is appreciated, Best regards, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Tue Feb 26 10:21:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02988 for ; Tue, 26 Feb 2002 10:21:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17846 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 10:21:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16473; Tue, 26 Feb 2002 09:55:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16441 for ; Tue, 26 Feb 2002 09:55:01 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02048 for ; Tue, 26 Feb 2002 09:54:58 -0500 (EST) Received: (qmail 4378 invoked from network); 26 Feb 2002 14:57:45 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 26 Feb 2002 14:57:45 -0000 Received: from stake.com (unknown [10.50.1.52]) by cam-relay.atstake.com (Postfix) with SMTP id 9C2E022817 for ; Tue, 26 Feb 2002 09:53:26 -0500 (EST) Message-ID: <3C7BA18E.4070802@stake.com> Date: Tue, 26 Feb 2002 14:54:06 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] 10.3 Processing REGISTER requests Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On step number 6: "..If not, the registrar checks whether the Call-ID agrees with the value stored for each binding. If not, it MUST remove the binding. If it does agree, it MUST remove the binding only if the CSeq in the request is higher than the value stored for that binding". ? As I understood this is: Call-ID in REGISTER = Call-ID stored? NO - remove the binding you have (insert new?) YES - Check for the CSeq if it is higher... So if the Call-ID != Call-ID stored the binding is removed? Is this true? -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 10:25:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03160 for ; Tue, 26 Feb 2002 10:25:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17942 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 10:25:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17423; Tue, 26 Feb 2002 10:07:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17394 for ; Tue, 26 Feb 2002 10:07:14 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02452 for ; Tue, 26 Feb 2002 10:07:07 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QF7JZ09697 for ; Tue, 26 Feb 2002 17:07:19 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Feb 2002 17:07:09 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 17:07:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] 10.3 Processing REGISTER requests Date: Tue, 26 Feb 2002 17:07:09 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7779081@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] 10.3 Processing REGISTER requests Thread-Index: AcG+1aWdlWjUw+6oTW+Gcq0JHYuLHAAAWLHQ To: , X-OriginalArrivalTime: 26 Feb 2002 15:07:09.0577 (UTC) FILETIME=[4314D790:01C1BED7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA17395 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Ofir Arkin [mailto:ofir@stake.com] > Sent: Tuesday, February 26, 2002 4:54 PM > To: sip@ietf.org > Subject: [Sip] 10.3 Processing REGISTER requests > > > On step number 6: > > "..If not, the registrar checks whether the Call-ID agrees with the > value stored for each binding. If not, it MUST remove the > binding. If it > does agree, it MUST remove the binding only if the CSeq in > the request > is higher than the value stored for that binding". > > ? > > As I understood this is: > Call-ID in REGISTER = Call-ID stored? > NO - remove the binding you have (insert new?) replace binding > YES - Check for the CSeq if it is higher... update binding > > So if the Call-ID != Call-ID stored the binding is removed? > > Is this true? Its really the same result. Regards, Hisham > -- > Ofir Arkin > Managing Security Architect > @stake, Limited. > http://www.atstake.com > email: > ofir@stake.com > Tel: > +44 (0) 207 495 7002 > Fax: > +44 (0) 207 495 7062 > Mobile: +44 (0) 779 630 8632 > > ----------------------------- > The information transmitted is intended only for the person > or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, re transmission, 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 any computer. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Tue Feb 26 10:25:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03179 for ; Tue, 26 Feb 2002 10:25:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17957 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 10:25:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17341; Tue, 26 Feb 2002 10:06:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17317 for ; Tue, 26 Feb 2002 10:06:53 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02437 for ; Tue, 26 Feb 2002 10:06:50 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1QF6LS08332; Tue, 26 Feb 2002 09:06:22 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1QF6Lw22064; Tue, 26 Feb 2002 09:06:21 -0600 (CST) Received: from lmf.ericsson.se (rmt160196.am.ericsson.se [138.85.160.196]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA08031; Tue, 26 Feb 2002 09:06:19 -0600 (CST) Message-ID: <3C7BAC2F.25AB0B2F@lmf.ericsson.se> Date: Tue, 26 Feb 2002 17:39:27 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tan Ya-Ching ICM N PG U ID A 1 CC: sip Subject: Re: [Sip] Manyfolks version 04 References: <5B4D0C5BA65ECA46969C1419122317E6081795@mchh161e> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I have a reference to the UPDATE draft in the Latex source, but I did not have time to include that draft in the bibtex file that I used for the references. That's why it does not appear in the txt version and it appears as [?] in the pfd/ps versions. I decided not to hold on to releasing the draft, even without that reference. Anyway, the UPDATE draft can be found at: http://www.ietf.org/internet-drafts/draft-ietf-sip-update-00.txt This will be fixed in the next version. Thanks, Gonzalo Tan Ya-Ching ICM N PG U ID A 1 wrote: > > Shouldn't this draft include a section to officially define the new method > UPDATE ? I can't find any definition of this new method in the list of > references of this draft. > > - Ya-Ching -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Tue Feb 26 10:26:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03211 for ; Tue, 26 Feb 2002 10:26:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17979 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 10:26:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17209; Tue, 26 Feb 2002 10:02:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17102 for ; Tue, 26 Feb 2002 10:02:24 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02291 for ; Tue, 26 Feb 2002 10:02:21 -0500 (EST) Received: from rndex50.software.mitel.com (rndex50 [134.199.17.160]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id KAA15640 for ; Tue, 26 Feb 2002 10:01:54 -0500 (EST) Received: by rndex50.ottawa.mitel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 10:01:53 -0500 Message-ID: <29B5A21C13C8D51190F900805F65B4EC4DE393@rndex50.ottawa.mitel.com> From: "Sloan, Rob" To: "'sip@ietf.org'" Subject: RE: [Sip] bis-08 11.2 Processing of OPTIONS Request Date: Tue, 26 Feb 2002 10:01:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Minor change required: 1794 - the basic state of a UAS, which can be an indication of whether the UAC will accept an INVITE request. Shouldn't it be: "... UAS will accept an INVITE request." Cheers _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 10:42:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04196 for ; Tue, 26 Feb 2002 10:42:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18947 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 10:42:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17779; Tue, 26 Feb 2002 10:19:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17753 for ; Tue, 26 Feb 2002 10:19:40 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02907 for ; Tue, 26 Feb 2002 10:19:36 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1QFJbh02967; Tue, 26 Feb 2002 09:19:37 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1QFJaE20805; Tue, 26 Feb 2002 09:19:36 -0600 (CST) Received: from lmf.ericsson.se (rmt160196.am.ericsson.se [138.85.160.196]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA09226; Tue, 26 Feb 2002 09:19:33 -0600 (CST) Message-ID: <3C7BAF48.CDDAEE14@lmf.ericsson.se> Date: Tue, 26 Feb 2002 17:52:40 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Xin (Xin)" CC: sip , Allison Mankin , Dean Willis , Biran Rosen , Joerg Ott , wtm@research.att.com, Jonathan Rosemberg Subject: Re: [Sip] Manyfolks version 04 References: <475FF955A05DD411980D00508B6D5FB00468F456@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, "Chen, Xin (Xin)" wrote: > > The question I have in mind is why we need "local" and "remote" here. > > "a=des:qos mandatory local sendrecv" generated by the offerer has no meaning > to the answerer, because this is something that the answerer can not help, > because this is your(offerer's) network not mine(answerer's)! The concept of e2e qos has been present in this draft since the beginning. We have now introduced the new segmented type, which includes the tags you are referring to (local and remote). If I (the offerer) reserve network resources for the media stream in my local interface and then send you the INVITE, you are right that this information may be considered useless for the answerer. However, I might want to, first send the INVITE and see if the answerer is willing to establish a session using qos. If the answerer responds to my INVITE accepting my mandatory preconditions, I can begin reserving resources in my local interface. In this case, I need a way to communicate the answerer that I am done with my local interface. That's why we need both tags. > And "a=des:qos mandatory remote sendrecv" generated by the offerer has the > same meaning as "a=des:qos mandatory e2e sendrecv" from the anserer's point > of view. No, they don't. If I am a 3GPP terminal, establishing the appropriate PDP context will meet the first precondition, but not the second. The e2e type is intended for e2e reservation protocols (this is stated in the draft, by the way). > > I think only "e2e" is needed. Because as a user, I don't care what local > access network another end is using, actually I even don't know what > protocol the other end is using for QoS, what I want is end to end QoS for > my the video or audio streams. OK, so you will always use e2e qos. But other folks find it useful to have the segmented type... although this does not mean that you have to use it. Thanks for your comments, Gonzalo >Therefore, it is up to the user agent to > intercept and decide whether e2e condition is met or not. > > For example, if the answerer receives an offer requiring e2e QoS sendrecv, > but the answerer only supports local network QoS protocol and uses Differv > in the core network to provide end to end QoS, therefore this call should > not fail just because the answerer doesn't support RSVP. So answerer just > needs to finish the local network QoS reservation and ACKs the offerer that > e2e is met. In a word, for the answerer's point of view, "e2e"="remote". > > If an offerer doesn't support e2e QoS protocol, it can still put "e2e" in > its offer, because from the offerer's point of view, "e2e"="local". > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 26 February 2002 3:03 > To: sip > Cc: Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott; > wtm@research.att.com; Jonathan Rosemberg > Subject: [Sip] Manyfolks version 04 > > Hello, > > I have just submitted a new version of the manyfolks draft. Until it > appears in the archives, you can fetch it from: > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.pdf > > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.txt > > About the authorship of this draft, the ADs and the WG chairs decided > that all the coauthors of previous versions but Bill had to be moved to > a Contributors Section. > > The deadline for this draft is very close, so I would appreciate that > folks read the draft and send comments as soon as possible. > > I have removed security preconditions (per mailing list discussion), but > added a token that can be used to define new precondition types (the > only type currently defined is "qos"). > > The draft uses two attributes: desired-status and current-status. When > the current status reaches (or goes beyond) the desired status the > preconditions are met. Instead of defining an absolute ordering for > these two attributes, I have defined status tables. They are > abstractions of the preconditions carried in the SDP. These tables help > explain how status synchronization between both user agents is performed > and when exactly all the preconditions are met. > > Feedback is appreciated, > > Best regards, > > Gonzalo > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.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 -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Tue Feb 26 10:47:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04390 for ; Tue, 26 Feb 2002 10:47:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19068 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 10:47:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18039; Tue, 26 Feb 2002 10:27:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18007 for ; Tue, 26 Feb 2002 10:27:29 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03295 for ; Tue, 26 Feb 2002 10:27:26 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GS500M01C8HFE@firewall.wcom.com> for sip@ietf.org; Tue, 26 Feb 2002 15:26:41 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GS500KKKC8HRN@firewall.wcom.com>; Tue, 26 Feb 2002 15:26:41 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GS500201C8FT1@dgismtp04.wcomnet.com>; Tue, 26 Feb 2002 15:26:41 +0000 (GMT) Received: from ajohnston ([166.42.34.12]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GS50020TC83IF@dgismtp04.wcomnet.com>; Tue, 26 Feb 2002 15:26:29 +0000 (GMT) Date: Tue, 26 Feb 2002 09:26:12 -0600 From: Alan Johnston Subject: RE: [Sip] bis-08 11.2 Processing of OPTIONS Request In-reply-to: <29B5A21C13C8D51190F900805F65B4EC4DE393@rndex50.ottawa.mitel.com> To: "'Sloan, Rob'" , sip@ietf.org Message-id: <000a01c1bed9$ecc6d980$0c222aa6@ajohnston> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Minor change required: > > 1794 - the basic state of a UAS, which can be an indication > of whether the UAC will accept an INVITE request. > > > Shouldn't it be: > "... UAS will accept an INVITE request." > Yes. Alan Johnston WorldCom sip:alan@siptest.wcom.com > Cheers > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Tue Feb 26 11:01:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04961 for ; Tue, 26 Feb 2002 11:01:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19865 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 11:01:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18819; Tue, 26 Feb 2002 10:40:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18785 for ; Tue, 26 Feb 2002 10:40:33 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.183]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04103 for ; Tue, 26 Feb 2002 10:40:29 -0500 (EST) Received: (from rjsparks@localhost) by rjs.dynamicsoft.com (8.11.2/8.11.2) id g1QFdx101661; Tue, 26 Feb 2002 09:39:59 -0600 X-Authentication-Warning: rjs.dynamicsoft.com: rjsparks set sender to rsparks@dynamicsoft.com using -f Subject: Re: [Sip] CANCEL and 100 Trying Question From: Robert Sparks To: "Fuxbruner, Amihay" Cc: sip@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Feb 2002 09:39:58 -0600 Message-Id: <1014737998.1325.9.camel@rjs.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit CANCEL is a hop-hop message. In the example you present, the CANCEL will arrive at the stateful proxy that generated the 100 after the INVITE that stimulated that 100. That proxy will in turn generate CANCELs to each branch that it forwarded the INVITE down that has received its own provisional response. In the simple case of A->P->B, A can send a CANCEL to P after P provides a 100. P will not send a CANCEL to B until it sees a provisional response from B (which means B has seen the INVITE). So, no - the UAS will not receive a CANCEL before the INVITE it should be applied to. RjS On Tue, 2002-02-26 at 03:43, Fuxbruner, Amihay wrote: > Hello, > > Probably answered long ago, but I couldn't find it :-( > > 2543 says UAC sends CANCEL after receiving 1xx only, to prevent the case > where UAS get CANCEL before INVITE. > In case UAC sends CANCEL after receiving 100 from next proxy, still UAS may > get CANCEL before INVITE. > > Is this correct? > > Thanks, > > Amihay Fuxbruner > System Engineering - Signaling R&D > Comverse > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Tue Feb 26 11:02:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05043 for ; Tue, 26 Feb 2002 11:02:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19908 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 11:03:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18997; Tue, 26 Feb 2002 10:44:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18970 for ; Tue, 26 Feb 2002 10:44:11 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04254 for ; Tue, 26 Feb 2002 10:44:08 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1QFi3h16887; Tue, 26 Feb 2002 09:44:04 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1QFi3x18940; Tue, 26 Feb 2002 09:44:03 -0600 (CST) Received: from lmf.ericsson.se (rmt160196.am.ericsson.se [138.85.160.196]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA11524; Tue, 26 Feb 2002 09:44:02 -0600 (CST) Message-ID: <3C7BB505.793B1988@lmf.ericsson.se> Date: Tue, 26 Feb 2002 18:17:09 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fuxbruner, Amihay" CC: sip@ietf.org Subject: Re: [Sip] CANCEL and 100 Trying Question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, "Fuxbruner, Amihay" wrote: > > Hello, > > Probably answered long ago, but I couldn't find it :-( > > 2543 says UAC sends CANCEL after receiving 1xx only, to prevent the case > where UAS get CANCEL before INVITE. > In case UAC sends CANCEL after receiving 100 from next proxy, still UAS may > get CANCEL before INVITE. No. CANCEL is a hop-by-hop method, and every proxy in the path will wait until the 100 from the next hop is received before sending the CANCEL. Regards, 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 daemon@optimus.ietf.org Tue Feb 26 11:06:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05215 for ; Tue, 26 Feb 2002 11:06:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20067 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 11:06:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19123; Tue, 26 Feb 2002 10:48:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19092 for ; Tue, 26 Feb 2002 10:48:21 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04475 for ; Tue, 26 Feb 2002 10:48:17 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1QFmJh19577; Tue, 26 Feb 2002 09:48:19 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1QFmJw15883; Tue, 26 Feb 2002 09:48:19 -0600 (CST) Received: from lmf.ericsson.se (rmt160196.am.ericsson.se [138.85.160.196]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA11923; Tue, 26 Feb 2002 09:48:17 -0600 (CST) Message-ID: <3C7BB604.5DF3A991@lmf.ericsson.se> Date: Tue, 26 Feb 2002 18:21:24 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Xin (Xin)" CC: sip@ietf.org Subject: Re: [Sip] Question on Unify draft References: <475FF955A05DD411980D00508B6D5FB00468F401@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, "Chen, Xin (Xin)" wrote: > > In this draft, in figure 4 (solution for One-of-N Codecs problem), it uses > the a=inactive in the first offer to stop the callee to send media. But is > it possible that the callee answers the offer by changing the a=inactive to > a=active and starts to send media immediately? > > If this is possible, then this solution won't work, am I right? > The direction attribute cannot be change in the answer. It has to be the same as in the offer. See: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-offer-answer-01.txt Regards, Gonzalo > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Tue Feb 26 11:37:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08944 for ; Tue, 26 Feb 2002 11:37:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22349 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 11:37:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20140; Tue, 26 Feb 2002 11:08:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20109 for ; Tue, 26 Feb 2002 11:08:49 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05312 for ; Tue, 26 Feb 2002 11:08:46 -0500 (EST) Received: from DWILLISS1 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1QG8IB27226; Tue, 26 Feb 2002 10:08:18 -0600 Message-ID: <002e01c1bedf$ce4b4b70$8b036e3f@DWILLISS1> From: "Dean Willis" To: "Christian Huitema" , References: Subject: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenario outside of 3GPP requirements) Date: Tue, 26 Feb 2002 10:08:18 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > Ok, insert my original example, but instead of a home proxy firewall > I'm > > in > > a hotel using pay-per-view IP transport and have to register through a > > proxy > > that handles policy decisions . . . (gee, sounds exactly like > one-half of > > the 3GPP problem set). > > Why exactly would you have to register through such a proxy? What is > wrong with using a TLS/SSL connection to your corporate server, and > placing the connection through it? > > > > Failing that, your best bet is to migrate to IPv6. > > > > yeah, like THAT woudn't impose change requirements on my existing > > obsolete-but-beloved phone . . . > > It would definitely have an impact. OTOH, it would make a number of > scenarios much simpler. And, since you mention 3GPP, isn't it the case > that 3GPP devices are supposed to use IPv6? > Well, using TLS to the coporate server wouldn't work, because I need to coordinate with the SIP ALG in the proxy-firewall. Yes, Christian, 3GP phones use IPV6, but they find they still have a desire to use a similar pattern. Maybe you missed he discussion of why 3GPP wants to do it this way, so I'll try and recap. They (3GPP) have a requirement to provide, at operator discretion, very strict control of network usage. It's almost as if the entire semantics of ATM SVCs have been transplanted onto IP, with UNI replaced by application-level control. The operators want to do service-senstitive AAA for the traffic. It's not the Internet. The basic model involves: 1) a phone or UE (User Equipment), which has knowledge of link-layer policies that apply to it. 2) a GGSN, which is a policy-enforcement-point firewall router, 3) a P-CSCF, which is a SIP proxy that also has policy-decision-point capabilities and talks to GGSN via COPS-PR or the equivalent thereof. Policy sets are called "PDP Contexts". Each PDP context can be though of as effectively analagous to an SVC between the phone. When the phone turns on, it talks to the GGSN and receives a signaling PDP context for use with SIP. This PDP context's policy in the GGSN allows IP traffic between the UE and the SIP port on the P-CSCF. All SIP traffic goes between the phone and the P-CSCF over this signaling PDP context. The phone literally can't talk any other protocol to any other endpoint. As the phone negotiates sessions by sending and receiving SIP through the P-CSCF, the P-CSCF provisions additional policy into the GGSN to create aditional PDP contexts or alter the policy on existing PDP contexts as needed. This has some implications: 1) The P-CSCF has to see and understand the signaling used to set up any session. If the P-CSCF can't see and understand it, then no PDP context gets provisioned, and the traffic doesn't flow. This breaks SIP-level end-to-end privacy. 2) Given #1, all SIP messages must traverse the P-CSCF. This means it has to a) be magically included in the path for all initial messages, including those inbound to the phone, and b) record-route for inclusion in subsequent messages. 3) There may be lots of SDP that a P-CSCF doesn't understand. If it can't be understood, it can't be provisioned in the GGSN. They therefore need a mechanism to indicate to the phone that the proposed SDP cannot be understood. The current proposal is to "edit" the SDP in various proxies, and allow only conformant SDP offers and answers to be made. This of course breaks end-to-end SIP body security. I'm open to suggestions here . . . There are lots of other obnoxious PTT regulatory stupidities in the model as well, but let's not go into those right now or my spleen might explode. It might be entirely legitimate for people to tell 3GPP "You people are breaking the Internet model completely. You're free to do that, but we don't want to help." On the other hand, that hasn't been the apparent consensus to-date -- we're trying to help them develop as reasonable an implementation as is feasible within the time bounds defined by the market. It's called "business". -- 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 daemon@optimus.ietf.org Tue Feb 26 11:41:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09360 for ; Tue, 26 Feb 2002 11:41:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22615 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 11:41:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20887; Tue, 26 Feb 2002 11:20:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20852 for ; Tue, 26 Feb 2002 11:20:18 -0500 (EST) Received: from commserver.iperia.com ([204.57.52.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05965 for ; Tue, 26 Feb 2002 11:20:14 -0500 (EST) Received: by commserver.erictest.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 11:19:50 -0500 Message-ID: <1A69639B9B6AD511812B00B0D0DE19F60A3451@commserver.erictest.com> From: Gordon Ledgard To: sip Date: Tue, 26 Feb 2002 11:19:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] UPDATE versus (re)INVITE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I've been looking over http://www.ietf.org/internet-drafts/draft-ietf-sip-update-00.txt Is the intent of the UPDATE method to completely obviate the necessity for reinvites? Or would there always be distinct reasons to use one versus another? Gordon Ledgard _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 11:44:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09470 for ; Tue, 26 Feb 2002 11:44:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22953 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 11:44:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21006; Tue, 26 Feb 2002 11:20:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20968 for ; Tue, 26 Feb 2002 11:20:52 -0500 (EST) Received: from smtp02do.de.uu.net (smtp02do.de.uu.net [192.76.144.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06011 for ; Tue, 26 Feb 2002 11:20:48 -0500 (EST) Received: from penelope.materna.de (penelope.materna.de [193.96.115.65]) by smtp02do.de.uu.net (5.5.5/5.5.5) with ESMTP id RAA24048 for ; Tue, 26 Feb 2002 17:20:21 +0100 (MET) Received: from ganymed (ganymed.materna.de [139.2.34.141]) by penelope.materna.de (Postfix) with ESMTP id D7B3167ED for ; Tue, 26 Feb 2002 17:20:17 +0100 (MET) Received: from pdc-gp.materna.de (actually localhost) by ganymed with Internet with ESMTP; Tue, 26 Feb 2002 17:20:18 +0100 Received: by pdc-gp.materna.de with Internet Mail Service (5.5.2653.19) id <16P6TQ8L>; Tue, 26 Feb 2002 17:20:06 +0100 Message-ID: <73B855B4F72FD411A1CF009027B113C40199F6AE@taxis.materna.de> From: thomas.nagel@materna.de To: sip@ietf.org Date: Tue, 26 Feb 2002 16:55:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA20971 Subject: [Sip] AW: Why Proxies are Good and B2BUAs May Not Be --> NO NO NO Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hello, just curious: how would you classify a 'gateway' (my termporary name) that translates SIP-via-XML to and from SIP/2.0/UDP ? Would it be a proxy, iaw a 'good citizen'? Or would it be a B2BUA, a 'bad citizen' ? If you say everything beyond a proxy is a sin, how would SIP itself ever evaluate further? Will it keep it is today forever? My doubts remain. My personal view: I personally feel the term SIP 'proxy' as badly chosen, as it implies that the usual connection model were end-to-end, very much like the original SMTP-model RFC821, where users would work as logged-in users on multi-user machines (SysVR4 whatever;). As with E-Mail, I would expect this model to vanish from the SIP-world, just like it is the far minority for SMTP nowadays. So I'd rather call a SIP 'proxy' a SIP "server". Likewise I'd say a REGISTER will eventually be used like a 'LOGIN'. In the RFC, one can easily imagine, that such a clarification would put away a lot of puzzeling of terms in the REGISTER examples. Regards, Thomas Nagel > -----Urspr�ngliche Nachricht----- > Von: Dean Willis [mailto:dean.willis@softarmor.com] > Gesendet: Montag, 25. Februar 2002 05:49 > An: Gonzalo Camarillo; Cullen Jennings > Cc: Bob Penfield; sip@ietf.org > Betreff: Why Proxies are Good and B2BUAs May Not Be (was Re: [Sip] > bis-07.9: proxies are not allowed to modify message body) > > > Gonzalo wrote: > > you have a > > B2BUA... I do not see a problem with that. > > > > I think the problem everybody has with this MUST NOT is the > following. > > People think: "If the elements in my architecture are > called proxies, I > > have a very good architecture, but if the elements in my > architecture > > are B2BUAs, my architecture is crap."... and to make every > architecture > > look good, they want to call stretch the concep of proxy so that all > > their elements are called "proxies". > > > > I do not think it is a big deal how we call these > elements... let's call > > everything an OPES-element instead of "proxy" or "B2BUA" > and everybody > > will be happy ;o) > > Here's my worry about that. There are REASONS why proxies are > as limited as > they are in the specification. It's to keep them from > breaking other things. > This has come up time and time again in 3GPP -- almost every > time that we > fudge the line between proxy and B2BUA, we end up breaking > something else. > > The proxy rules are, I believe, most effective in providing "forward > compatibility" -- a basic proxy will work, as expected, with > any reasonable > future SIP extension method type, extension header, or > payload. In fact, > that's part of the rule we use in determining "reasonableness" for > extensions. No such restraint applies to B2BUAs. If you > "break the rules" of > a proxy, all compatibility bets are off, and problems become > very likely. > It's like running naked through Central Park at night with a > bunch of $20 > bills taped to your backside -- you MIGHT not have an > unfortunate encounter, > and if you do you'll hear a whole lot of "I told you so!"s. > > -- > 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 daemon@optimus.ietf.org Tue Feb 26 11:45:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09505 for ; Tue, 26 Feb 2002 11:45:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22987 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 11:45:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21406; Tue, 26 Feb 2002 11:27:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21375 for ; Tue, 26 Feb 2002 11:26:59 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06263 for ; Tue, 26 Feb 2002 11:26:55 -0500 (EST) Received: from DWILLISS1 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1QGMqB27344; Tue, 26 Feb 2002 10:22:52 -0600 Message-ID: <004201c1bee1$d7350620$8b036e3f@DWILLISS1> From: "Dean Willis" To: Cc: "Gonzalo Camarillo" , "Cullen Jennings" , "Bob Penfield" , References: Subject: Re: Why Proxies are Good and B2BUAs May Not Be (was Re: [Sip] bis-07.9: proxies are not allowed to modify message body) Date: Tue, 26 Feb 2002 10:22:51 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juan-Carlos wote: > This is the definition of a proxy server, taken from bis-08: > > Proxy, Proxy Server: An intermediary entity that acts as both a server and > a client for the purpose of making requests on behalf of other clients. A > proxy server primarily plays the role of routing, which means its job is to > ensure that a request is sent to another entity closer to the targeted > user. Proxies are also useful for enforcing policy (for example, making > sure a user is allowed to make a call). A proxy interprets, and, if > necessary, rewrites specific parts of a request message before forwarding > it. > > As you see, the first part is fully inline with your mail: "A proxy server > primarily plays the role of routing, ..." > However, can you explain me how you apply your mail to the second part : > "Proxies are also useful for enforcing policy...", "A proxy interprets, > and, if necessary, rewrites specific parts of a request message before > forwarding it" The key bit there is the word "specific". The specification details which parts may be rewritten by a conformant proxy. Mess with the wrong parts, and bad things can happen. As we gain practical experience with working implementations, we learn more about which parts are sensitive. The specification has incorporated this advancing knowledge as the specification itself has advanced. Now, sometimes, it may be necessary to mess with sensitive parts. This is analogous to "surgery" in the medical profession. In general, one uses surgery as a last resort to treat a specific condition, with the full knowledge and expectation that there will be side effects, some of which MAY be life-threatening. If a confomant proxi is like a passenger taxi, then a B2BUA is like an ambulance. There is a big difference between riding in a taxi to a restaurant for dinner, and riding in an ambulance to a hospital for a triple bypass. And I'm afraid that my rhetoric professor will need a triple bypass after reading this discussion. -- 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 daemon@optimus.ietf.org Tue Feb 26 12:00:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10212 for ; Tue, 26 Feb 2002 12:00:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24502 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 12:00:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22336; Tue, 26 Feb 2002 11:37:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22304 for ; Tue, 26 Feb 2002 11:37:31 -0500 (EST) Received: from unity.cisco.com (evvbu-exchange.cisco.com [64.101.140.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08778 for ; Tue, 26 Feb 2002 11:37:27 -0500 (EST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BEE3.CC68B272" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Date: Tue, 26 Feb 2002 10:36:53 -0600 Message-ID: Thread-Topic: [Sip] bis-06 now available! Thread-Index: AcGoTHWLJSRdRkyoQ/Obs4ny3EU0UgWln8MQ From: "Henry Chen" To: Subject: [Sip] Tone control for an existing dialog Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1BEE3.CC68B272 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 Is there any sip extension or mechanism to control a SIP endpoint = in an existing dialog to generate ringback / busy / reorder tones?=20 =20 Thanks,=20 =20 Henry=20 ------_=_NextPart_001_01C1BEE3.CC68B272 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
    Is there any = sip=20 extension or mechanism to control  a SIP endpoint in an = existing=20 dialog to generate ringback / busy / reorder tones?
 
    Thanks, =
 
    Henry=20
------_=_NextPart_001_01C1BEE3.CC68B272-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 12:05:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10483 for ; Tue, 26 Feb 2002 12:05:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25108 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 12:05:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22937; Tue, 26 Feb 2002 11:44:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22908 for ; Tue, 26 Feb 2002 11:44:44 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09465 for ; Tue, 26 Feb 2002 11:44:40 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1QGiDS04325; Tue, 26 Feb 2002 10:44:13 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1QGiDx07063; Tue, 26 Feb 2002 10:44:13 -0600 (CST) Received: from lmf.ericsson.se (rmt160196.am.ericsson.se [138.85.160.196]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA17210; Tue, 26 Feb 2002 10:44:11 -0600 (CST) Message-ID: <3C7B5918.531352CC@lmf.ericsson.se> Date: Tue, 26 Feb 2002 11:44:56 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Gordon Ledgard CC: sip Subject: Re: [Sip] UPDATE versus (re)INVITE References: <1A69639B9B6AD511812B00B0D0DE19F60A3451@commserver.erictest.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, re-INVITEs are still needed. In 3pcc scenarios it is often needed to send an empty re-INVITE in order to get an offer in the response. Regards, Gonzalo Gordon Ledgard wrote: > > I've been looking over > > http://www.ietf.org/internet-drafts/draft-ietf-sip-update-00.txt > > Is the intent of the UPDATE method to completely obviate the > necessity for reinvites? Or would there always be distinct reasons > to use one versus another? > > Gordon Ledgard > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Tue Feb 26 12:08:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10594 for ; Tue, 26 Feb 2002 12:08:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25215 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 12:06:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22864; Tue, 26 Feb 2002 11:43:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22715 for ; Tue, 26 Feb 2002 11:43:22 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09395 for ; Tue, 26 Feb 2002 11:43:01 -0500 (EST) Received: from DWILLISS1 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1QGgVB27465; Tue, 26 Feb 2002 10:42:31 -0600 Message-ID: <005601c1bee4$9603b1d0$8b036e3f@DWILLISS1> From: "Dean Willis" To: , References: <73B855B4F72FD411A1CF009027B113C40199F6AE@taxis.materna.de> Subject: Re: [Sip] AW: Why Proxies are Good and B2BUAs May Not Be --> NO NO NO Date: Tue, 26 Feb 2002 10:42:30 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thomas asks: > just curious: how would you classify a 'gateway' (my termporary name) > that translates SIP-via-XML to and from SIP/2.0/UDP ? > Would it be a proxy, iaw a 'good citizen'? > Or would it be a B2BUA, a 'bad citizen' ? > It's a "gateway". From a SIP perspective, it's just a UA, just as a phone is a UA that translates SIP and RTP to/from user interface and sound. Other gateways include SIMPLE<->Jabber, SIP<->H.323, SIMPLE<->AOL, SIP<->SS7, and so on . . . Gateways are Good Things, but it may not be possible to assure 100% SIP feature transparency across a gateway. Essentially, anything that does SIP->somethingelse->SIP can be considered a form of B2BUA. Feature transparency across such a stucture requires a fully homomorphic mapping between SIP and somethingelse. Any restrictions on that mapping WILL break some kind of feature transaprency. > If you say everything beyond a proxy is a sin, how would SIP itself > ever evaluate further? Will it keep it is today forever? My doubts remain. It's not a sin in my world view, but it is risky (just like surgery is). And I believe at least one major religion declared surgery to be a sin once upon a time . . . > My personal view: > I personally feel the term SIP 'proxy' as badly chosen, as it implies > that the usual connection model were end-to-end, very much like > the original SMTP-model RFC821, where users would work as logged-in > users on multi-user machines (SysVR4 whatever;). > As with E-Mail, I would expect this model to vanish from the > SIP-world, just like it is the far minority for SMTP nowadays. > So I'd rather call a SIP 'proxy' a SIP "server". Actually, the idea is that that SIP proxy functions are very analagous to SMTP relays. They apply some policy control, and forward messages on to their destination using layer 4+ routing information with very little regard for (and hopefully little alteration of) the actual content of the messages. > Likewise I'd say a REGISTER will eventually be used like a 'LOGIN'. > In the RFC, one can easily imagine, that such a clarification would > put away a lot of puzzeling of terms in the REGISTER examples. Yeah, this one really confuses people with a background in GSM mobile phones, where registration IS "login". I probably spend two days a week fighting this hydra, and it grows back its heads faster than can burn them off. My suggestion was to rename the REGISTER message "SETCONTACT", but the lead editors for the spec were not amused. -- 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 daemon@optimus.ietf.org Tue Feb 26 12:25:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11545 for ; Tue, 26 Feb 2002 12:25:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27101 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 12:25:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24996; Tue, 26 Feb 2002 12:03:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24850 for ; Tue, 26 Feb 2002 12:02:05 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10337 for ; Tue, 26 Feb 2002 12:01:56 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16fkzE-00036H-00; Tue, 26 Feb 2002 19:01:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15483.49028.774363.798060@harjus.eng.song.fi> Date: Tue, 26 Feb 2002 19:01:56 +0200 To: "Dean Willis" Cc: "Christian Huitema" , Subject: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenario outside of 3GPP requirements) In-Reply-To: <002e01c1bedf$ce4b4b70$8b036e3f@DWILLISS1> References: <002e01c1bedf$ce4b4b70$8b036e3f@DWILLISS1> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > When the phone turns on, it talks to the GGSN and receives a signaling PDP > context for use with SIP. This PDP context's policy in the GGSN allows IP > traffic between the UE and the SIP port on the P-CSCF. All SIP traffic goes > between the phone and the P-CSCF over this signaling PDP context. The phone > literally can't talk any other protocol to any other endpoint. my gprs phone can already today setup pdp contexts at will and send register and other sip messages to anybody likes to by sending and receiving ip packets over those contexts. i have been told that in the next gprs release, the phone should be able to also tell the qos requirements of these pdp contexts. are you saying that in all ip 3g all this is going to go away and my phone can only talk to the operator's p-cscf? > There are lots of other obnoxious PTT regulatory stupidities in the model as > well, but let's not go into those right now or my spleen might explode. i know the regulations here pretty well and i don't think any of the 3g stupidity is in fact caused by it. it is caused by the operator's and equipment vendors (because the operators feed them) desire to lock the customer in into the walled garden. the sip working group should not play any part in that conspiracy. -- 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 daemon@optimus.ietf.org Tue Feb 26 12:25:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11561 for ; Tue, 26 Feb 2002 12:25:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27115 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 12:25:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25256; Tue, 26 Feb 2002 12:06:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25211 for ; Tue, 26 Feb 2002 12:06:19 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10537 for ; Tue, 26 Feb 2002 12:06:15 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1QH6IK00715 for ; Tue, 26 Feb 2002 12:06:18 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K40HAH6>; Tue, 26 Feb 2002 17:06:17 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00468F4BF@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Gonzalo Camarillo , "Chen, Xin (Xin)" Cc: sip , Allison Mankin , Dean Willis , Biran Rosen , Joerg Ott , wtm@research.att.com, Jonathan Rosemberg Subject: RE: [Sip] Manyfolks version 04 Date: Tue, 26 Feb 2002 17:06:16 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Gonzalo, Thanks for your answer to my offer, See below in line my new offer:-) Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 26 February 2002 15:53 To: Chen, Xin (Xin) Cc: sip; Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott; wtm@research.att.com; Jonathan Rosemberg Subject: Re: [Sip] Manyfolks version 04 Hello, "Chen, Xin (Xin)" wrote: > > The question I have in mind is why we need "local" and "remote" here. > > "a=des:qos mandatory local sendrecv" generated by the offerer has no meaning > to the answerer, because this is something that the answerer can not help, > because this is your(offerer's) network not mine(answerer's)! The concept of e2e qos has been present in this draft since the beginning. We have now introduced the new segmented type, which includes the tags you are referring to (local and remote). If I (the offerer) reserve network resources for the media stream in my local interface and then send you the INVITE, you are right that this information may be considered useless for the answerer. However, I might want to, first send the INVITE and see if the answerer is willing to establish a session using qos. If the answerer responds to my INVITE accepting my mandatory preconditions, I can begin reserving resources in my local interface. In this case, I need a way to communicate the answerer that I am done with my local interface. That's why we need both tags. [XC] Bacially, I think we properly don't need such a parameter--"e2e, local or remote" at all. Becuase the machaism in manyfolks is based on the purely trustship between offerer and answerer. If I tell you that I have done the e2e Qos reservation which I don't, you don't know I am saying the truth or not and you can't verify that. Therefore, the "e2e, local or remote" will only have local meaning based on local UE's interception. There is no way to stop me to send you a confirmation for the e2e QoS reservation even if I am not able to do that. And this is good, because I have some other local means to satify the QoS condition and I don't want the call to fail becuase I don't support an e2e QoS reservation protocol. The only important information carried in the offer is the "mandary", which tells the other end to try your best based on your own capability regardless you can do e2e or not. And the important information in the confirmation is that I have done my best to satisfy the QoS requirement and please trust me! Therefore, in the case you mentioned, you can always send a test offer with "qos sendrecv mandary" to the callee but without the "e2e", "local" or "remote" parameter, let the callee to decide what to do to satify the condition. This will give great flexibilty to the callee to try his best and it is much less chance a call will be failed. > And "a=des:qos mandatory remote sendrecv" generated by the offerer has the > same meaning as "a=des:qos mandatory e2e sendrecv" from the anserer's point > of view. No, they don't. If I am a 3GPP terminal, establishing the appropriate PDP context will meet the first precondition, but not the second. [XC] Then the call may fail, we don't want that happen! We wish the call always successful! This is exactly my worry about the e2e parameter. In 3GPP, the terminal will not do RSVP and it uses PDP which is a local QoS machanism. We have Differv in the middle to provide the end to end QoS. We don't want a call to fail if an incoming offer requiring "e2e" to a 3GPP terminal or a 3GPP terminal initiates an offer with "local" parameter not "e2e". The e2e type is intended for e2e reservation protocols (this is stated in the draft, by the way). > > I think only "e2e" is needed. Because as a user, I don't care what local > access network another end is using, actually I even don't know what > protocol the other end is using for QoS, what I want is end to end QoS for > my the video or audio streams. OK, so you will always use e2e qos. But other folks find it useful to have the segmented type... although this does not mean that you have to use it. [XC] No, my point of view is not to use any of them:e2e, local or remote. Thanks Thanks for your comments, Gonzalo >Therefore, it is up to the user agent to > intercept and decide whether e2e condition is met or not. > > For example, if the answerer receives an offer requiring e2e QoS sendrecv, > but the answerer only supports local network QoS protocol and uses Differv > in the core network to provide end to end QoS, therefore this call should > not fail just because the answerer doesn't support RSVP. So answerer just > needs to finish the local network QoS reservation and ACKs the offerer that > e2e is met. In a word, for the answerer's point of view, "e2e"="remote". > > If an offerer doesn't support e2e QoS protocol, it can still put "e2e" in > its offer, because from the offerer's point of view, "e2e"="local". > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 26 February 2002 3:03 > To: sip > Cc: Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott; > wtm@research.att.com; Jonathan Rosemberg > Subject: [Sip] Manyfolks version 04 > > Hello, > > I have just submitted a new version of the manyfolks draft. Until it > appears in the archives, you can fetch it from: > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.pdf > > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.txt > > About the authorship of this draft, the ADs and the WG chairs decided > that all the coauthors of previous versions but Bill had to be moved to > a Contributors Section. > > The deadline for this draft is very close, so I would appreciate that > folks read the draft and send comments as soon as possible. > > I have removed security preconditions (per mailing list discussion), but > added a token that can be used to define new precondition types (the > only type currently defined is "qos"). > > The draft uses two attributes: desired-status and current-status. When > the current status reaches (or goes beyond) the desired status the > preconditions are met. Instead of defining an absolute ordering for > these two attributes, I have defined status tables. They are > abstractions of the preconditions carried in the SDP. These tables help > explain how status synchronization between both user agents is performed > and when exactly all the preconditions are met. > > Feedback is appreciated, > > Best regards, > > Gonzalo > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.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 -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Tue Feb 26 12:29:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11731 for ; Tue, 26 Feb 2002 12:29:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27355 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 12:29:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25048; Tue, 26 Feb 2002 12:03:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25019 for ; Tue, 26 Feb 2002 12:03:34 -0500 (EST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10441 for ; Tue, 26 Feb 2002 12:03:28 -0500 (EST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 26 Feb 2002 09:02:12 -0800 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 26 Feb 2002 09:02:11 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Feb 2002 09:02:12 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Feb 2002 09:02:09 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Tue, 26 Feb 2002 09:00:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenario outside of 3GPP requirements) Date: Tue, 26 Feb 2002 09:00:10 -0800 Message-ID: Thread-Topic: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenario outside of 3GPP requirements) thread-index: AcG+33I8qS5bJAo7QLulF/4MzWmq0QABr4vA From: "Christian Huitema" To: "Dean Willis" , X-OriginalArrivalTime: 26 Feb 2002 17:00:10.0718 (UTC) FILETIME=[0CF4D7E0:01C1BEE7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA25020 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Well, using TLS to the coporate server wouldn't work, because I need to > coordinate with the SIP ALG in the proxy-firewall. The basic answer is, get a different proxy-firewall. There are two fundamental problems with the "SIP ALG" approach: it breaks security, and it breaks evolution. The security requirement is pretty simple: if you cannot rely on end-to-end signature of the message body, you don't know to whom you are sending the media; if you cannot rely on end to end encryption of the body, you don't know who is snooping your calls. The evolution requirement is also pretty simple: ALG only translate what they understand, and they tend to hard wire that; if I come out with smellovision (as an example ;-) and the ALG does not understand it, poof, the smell is gone. The proper architecture is to use some form of network level signaling to securely open holes in the firewall. > They (3GPP) have a requirement to provide, at operator discretion, very > strict control of network usage. It's almost as if the entire semantics of > ATM SVCs have been transplanted onto IP, with UNI replaced by > application-level control. The operators want to do service-senstitive > AAA > for the traffic. It's not the Internet. Well, you say it: what these operators want to build "is not the Internet." On the other hand, this is the IETF, and the "I" stands precisely for "Internet". As such, we have no requirement to placate groups that want to develop a "not-Internet." They can develop a specification that fits their need, say a "3G voice over IP wireless signaling protocol"; the one thing they should not do is, try to pretend this is an Internet standard. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 12:37:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12286 for ; Tue, 26 Feb 2002 12:37:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05672 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 12:37:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26724; Tue, 26 Feb 2002 12:19:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26693 for ; Tue, 26 Feb 2002 12:18:57 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11170 for ; Tue, 26 Feb 2002 12:18:53 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1QHIth16070; Tue, 26 Feb 2002 11:18:55 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1QHIsE09338; Tue, 26 Feb 2002 11:18:54 -0600 (CST) Received: from lmf.ericsson.se (rmt160196.am.ericsson.se [138.85.160.196]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA20597; Tue, 26 Feb 2002 11:18:49 -0600 (CST) Message-ID: <3C7B6136.3A5F7FD4@lmf.ericsson.se> Date: Tue, 26 Feb 2002 12:19:34 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Xin (Xin)" CC: sip , Allison Mankin , Dean Willis , Biran Rosen , Joerg Ott , wtm@research.att.com, Jonathan Rosemberg Subject: Re: [Sip] Manyfolks version 04 References: <475FF955A05DD411980D00508B6D5FB00468F4BF@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, > > And "a=des:qos mandatory remote sendrecv" generated by the offerer has the > > same meaning as "a=des:qos mandatory e2e sendrecv" from the anserer's > point > > of view. > > No, they don't. If I am a 3GPP terminal, establishing the appropriate > PDP context will meet the first precondition, but not the second. > [XC] Then the call may fail, we don't want that happen! If the preconditions cannot be met, that's exactly what we want: the call does not have to be established. Reading your second mail, what you want is the segmented type: that is, you are telling the other end to do whatever he can on his side, and you will do whatever you can on yours... as you said, in the middle you might have DiffServ, for instance. But if you use the e2e type, you want to make sure that there are resources end to end. Even if you know that you are in a Gigabit ethernet and that your local router uses DiffServ, you still don't know whether or not you have e2e QoS... that's why you need both types. That fact that all you want is the segmented type, does not mean that other people cannot find the e2e type useful. Regards, Gonzalo We wish the call > always successful! This is exactly my worry about the e2e parameter. In > 3GPP, the terminal will not do RSVP and it uses PDP which is a local QoS > machanism. We have Differv in the middle to provide the end to end QoS. We > don't want a call to fail if an incoming offer requiring "e2e" to a 3GPP > terminal or a 3GPP terminal initiates an offer with "local" parameter not > "e2e". > > The e2e type is intended for e2e reservation protocols (this is stated > in the draft, by the way). > > > > I think only "e2e" is needed. Because as a user, I don't care what local > > access network another end is using, actually I even don't know what > > protocol the other end is using for QoS, what I want is end to end QoS for > > my the video or audio streams. > > OK, so you will always use e2e qos. But other folks find it useful to > have the segmented type... although this does not mean that you have to > use it. > [XC] No, my point of view is not to use any of them:e2e, local or remote. > Thanks > > Thanks for your comments, > > Gonzalo > > >Therefore, it is up to the user agent to > > intercept and decide whether e2e condition is met or not. > > > > For example, if the answerer receives an offer requiring e2e QoS sendrecv, > > but the answerer only supports local network QoS protocol and uses Differv > > in the core network to provide end to end QoS, therefore this call should > > not fail just because the answerer doesn't support RSVP. So answerer just > > needs to finish the local network QoS reservation and ACKs the offerer > that > > e2e is met. In a word, for the answerer's point of view, "e2e"="remote". > > > > If an offerer doesn't support e2e QoS protocol, it can still put "e2e" in > > its offer, because from the offerer's point of view, "e2e"="local". > > > > Thanks > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: 26 February 2002 3:03 > > To: sip > > Cc: Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott; > > wtm@research.att.com; Jonathan Rosemberg > > Subject: [Sip] Manyfolks version 04 > > > > Hello, > > > > I have just submitted a new version of the manyfolks draft. Until it > > appears in the archives, you can fetch it from: > > > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.pdf > > > > > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.txt > > > > About the authorship of this draft, the ADs and the WG chairs decided > > that all the coauthors of previous versions but Bill had to be moved to > > a Contributors Section. > > > > The deadline for this draft is very close, so I would appreciate that > > folks read the draft and send comments as soon as possible. > > > > I have removed security preconditions (per mailing list discussion), but > > added a token that can be used to define new precondition types (the > > only type currently defined is "qos"). > > > > The draft uses two attributes: desired-status and current-status. When > > the current status reaches (or goes beyond) the desired status the > > preconditions are met. Instead of defining an absolute ordering for > > these two attributes, I have defined status tables. They are > > abstractions of the preconditions carried in the SDP. These tables help > > explain how status synchronization between both user agents is performed > > and when exactly all the preconditions are met. > > > > Feedback is appreciated, > > > > Best regards, > > > > Gonzalo > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.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 > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Tue Feb 26 13:32:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15004 for ; Tue, 26 Feb 2002 13:32:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA10349 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 13:32:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09014; Tue, 26 Feb 2002 13:14:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08983 for ; Tue, 26 Feb 2002 13:14:31 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14066 for ; Tue, 26 Feb 2002 13:14:28 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id NAA18594; Tue, 26 Feb 2002 13:13:43 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256B6C.00641F03 ; Tue, 26 Feb 2002 13:13:35 -0500 X-Lotus-FromDomain: MITEL To: "Christian Huitema" , Tom_Gray@Mitel.COM cc: "Dean Willis" , sip@ietf.org Message-ID: <85256B6C.00641D54.00@kanmta01.software.mitel.com> Date: Tue, 26 Feb 2002 13:13:33 -0500 Subject: RE: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenario outside of 3GPP requirements) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org From: Tom Gray@MITEL on 02/26/2002 01:13 PM With respect to loss of security by using an ALG at the firewall and end-to-end encryption, wouldn't it be possible to intercept the network level signalling at the firewall that opens pin holes as a means of breaching end-to-end security. Isn't this scenario similar to the ALG one. There must be some degree of trust at a firewall or its purpose is defeated. "Christian Huitema" on 02/26/2002 12:00:10 PM To: "Dean Willis" , sip@ietf.org cc: (bcc: Tom Gray/Kan/Mitel) Subject: RE: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenario outside of 3GPP requirements) > Well, using TLS to the coporate server wouldn't work, because I need to > coordinate with the SIP ALG in the proxy-firewall. The basic answer is, get a different proxy-firewall. There are two fundamental problems with the "SIP ALG" approach: it breaks security, and it breaks evolution. The security requirement is pretty simple: if you cannot rely on end-to-end signature of the message body, you don't know to whom you are sending the media; if you cannot rely on end to end encryption of the body, you don't know who is snooping your calls. The evolution requirement is also pretty simple: ALG only translate what they understand, and they tend to hard wire that; if I come out with smellovision (as an example ;-) and the ALG does not understand it, poof, the smell is gone. The proper architecture is to use some form of network level signaling to securely open holes in the firewall. > They (3GPP) have a requirement to provide, at operator discretion, very > strict control of network usage. It's almost as if the entire semantics of > ATM SVCs have been transplanted onto IP, with UNI replaced by > application-level control. The operators want to do service-senstitive > AAA > for the traffic. It's not the Internet. Well, you say it: what these operators want to build "is not the Internet." On the other hand, this is the IETF, and the "I" stands precisely for "Internet". As such, we have no requirement to placate groups that want to develop a "not-Internet." They can develop a specification that fits their need, say a "3G voice over IP wireless signaling protocol"; the one thing they should not do is, try to pretend this is an Internet standard. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Tue Feb 26 13:43:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15453 for ; Tue, 26 Feb 2002 13:43:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA10958 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 13:43:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09537; Tue, 26 Feb 2002 13:25:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09504 for ; Tue, 26 Feb 2002 13:25:47 -0500 (EST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14679 for ; Tue, 26 Feb 2002 13:25:44 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 26 Feb 2002 10:24:26 -0800 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 26 Feb 2002 10:24:26 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Feb 2002 10:24:26 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Feb 2002 10:24:26 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Tue, 26 Feb 2002 10:22:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenario outside of 3GPP requirements) Date: Tue, 26 Feb 2002 10:22:26 -0800 Message-ID: Thread-Topic: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenario outside of 3GPP requirements) thread-index: AcG+8PWPqQ+xjLDqTZq9U/fnm7jmfAAAUP9A From: "Christian Huitema" To: Cc: "Dean Willis" , X-OriginalArrivalTime: 26 Feb 2002 18:22:27.0087 (UTC) FILETIME=[8B42F9F0:01C1BEF2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA09505 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > From: Tom Gray@MITEL on 02/26/2002 01:13 PM > With respect to loss of security by using an ALG at the firewall and end- > to-end > encryption, wouldn't it be possible to intercept the network level > signalling at > the firewall that opens pin holes as a means of breaching end-to-end > security. > Isn't this scenario similar to the ALG one. There must be some degree of > trust > at a firewall or its purpose is defeated. At some level, every middlebox is a threat to network security. Firewalls can definitely mount a denial of service attack -- in fact we can argue that their main purpose is to mount a selective DOS attack against unapproved traffic. The situation gets better if you have IPv6 and global addressing, since at least you avoid address translation, which means that the firewall is not compelled to lie about your real address. The situation gets even better if you can use end-to-end authentication and encryption of the media streams. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 13:44:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15505 for ; Tue, 26 Feb 2002 13:44:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11097 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 13:44:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09163; Tue, 26 Feb 2002 13:19:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09134 for ; Tue, 26 Feb 2002 13:19:05 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14301 for ; Tue, 26 Feb 2002 13:19:02 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 26 Feb 2002 18:19:20 UT Received: from jolaptop ([80.3.216.239]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 26 Feb 2002 18:21:39 +0000 From: "Jo Hornsby" To: "Christer Holmberg" Cc: Subject: RE: [Sip] Bis-8: To tag question Date: Tue, 26 Feb 2002 18:23:49 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3C7B4C62.2567A4BF@lmf.ericsson.se> Importance: Normal X-OriginalArrivalTime: 26 Feb 2002 18:21:39.0718 (UTC) FILETIME=[6F070A60:01C1BEF2] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit [Regarding 17.2.3] > Yes. The tag will be different for each final response, but there > will still > be a tag in each final response (2xx or non-2xx), so that's why I > wondered how the server can decide if an ACK is for a 2xx just by > looking if > there is a tag or not (that's at least how I understood the text, so I > appologise if I missunderstood)... It's not so much that the proxy can just look at the tag and somehow magically determine that it was in a 2xx response. No, rather it's because the proxy knows the tag it used in the non-2xx it sent; therefore, if the tag in an ACK is not the same, it must be for some 2xx. - Jo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 14:35:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18062 for ; Tue, 26 Feb 2002 14:35:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA14655 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 14:35:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13255; Tue, 26 Feb 2002 14:12:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13145 for ; Tue, 26 Feb 2002 14:11:55 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16942 for ; Tue, 26 Feb 2002 14:11:52 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1QJBNp00041 for ; Tue, 26 Feb 2002 14:11:23 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K40HDR9>; Tue, 26 Feb 2002 19:11:22 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00468F4F3@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Gonzalo Camarillo , "Chen, Xin (Xin)" Cc: sip , Allison Mankin , Dean Willis , Biran Rosen , Joerg Ott , wtm@research.att.com, Jonathan Rosemberg Subject: RE: [Sip] Manyfolks version 04 Date: Tue, 26 Feb 2002 19:11:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Gonzalo, You can only ask and wish there will be e2e QoS on both directions and you can not make sure of this, becuase you always rely on the confirmation from other party and you have to trust it! According to my understanding, SIP is a protocol not used for QoS reservation and it is independent to any QoS reservation protocol, basically I can configure my SIP terminal to accept any offer having "a=des:qos mandatory e2e sendrecv" even if my terminal doesn't not support any QoS reservation protocol and I can still claim that it is a terminal supporting manyfolks, because you can not say that my terminal is not manyfolks supported simply because I don't support an end to end QoS reservation protocol. If you can, then this draft does tide SIP up with QoS protocol. Simple question: What is the "end to end", where is the definition of end to end QoS? In 3GPP network, local QoS (caller) + Differv in the core + local QoS (callee) = end to end In manyfolks, RSVP = end to end Which one is right? I think both are correct depending on the practical situation. The only difference is that in 3GPP network, Differv is pre-agreed based service level agreement, therefore, the user is not aware of that. And for RSVP, the user is aware of that. This is the only difference. But the 3GPP terminal's call will suffer the failing simple becuase of this difference if we use those parameters like "e2e" in SDP. I hope you will not think that I am being aggressive because I really see some hint in this draft to give the definition on what the end to end is and what the local and remote is regarding on QoS reservation and we should not do this. I don't want to hear one day a SIP developper says:"Becuase SIP says this, therefore, we have to use the QoS reservation protocol."! Bascially, SIP should not give any restriction on the terminal's understanding on what end to end QoS. Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 26 February 2002 10:20 To: Chen, Xin (Xin) Cc: sip; Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott; wtm@research.att.com; Jonathan Rosemberg Subject: Re: [Sip] Manyfolks version 04 Hello, > > And "a=des:qos mandatory remote sendrecv" generated by the offerer has the > > same meaning as "a=des:qos mandatory e2e sendrecv" from the anserer's > point > > of view. > > No, they don't. If I am a 3GPP terminal, establishing the appropriate > PDP context will meet the first precondition, but not the second. > [XC] Then the call may fail, we don't want that happen! If the preconditions cannot be met, that's exactly what we want: the call does not have to be established. Reading your second mail, what you want is the segmented type: that is, you are telling the other end to do whatever he can on his side, and you will do whatever you can on yours... as you said, in the middle you might have DiffServ, for instance. But if you use the e2e type, you want to make sure that there are resources end to end. Even if you know that you are in a Gigabit ethernet and that your local router uses DiffServ, you still don't know whether or not you have e2e QoS... that's why you need both types. That fact that all you want is the segmented type, does not mean that other people cannot find the e2e type useful. Regards, Gonzalo We wish the call > always successful! This is exactly my worry about the e2e parameter. In > 3GPP, the terminal will not do RSVP and it uses PDP which is a local QoS > machanism. We have Differv in the middle to provide the end to end QoS. We > don't want a call to fail if an incoming offer requiring "e2e" to a 3GPP > terminal or a 3GPP terminal initiates an offer with "local" parameter not > "e2e". > > The e2e type is intended for e2e reservation protocols (this is stated > in the draft, by the way). > > > > I think only "e2e" is needed. Because as a user, I don't care what local > > access network another end is using, actually I even don't know what > > protocol the other end is using for QoS, what I want is end to end QoS for > > my the video or audio streams. > > OK, so you will always use e2e qos. But other folks find it useful to > have the segmented type... although this does not mean that you have to > use it. > [XC] No, my point of view is not to use any of them:e2e, local or remote. > Thanks > > Thanks for your comments, > > Gonzalo > > >Therefore, it is up to the user agent to > > intercept and decide whether e2e condition is met or not. > > > > For example, if the answerer receives an offer requiring e2e QoS sendrecv, > > but the answerer only supports local network QoS protocol and uses Differv > > in the core network to provide end to end QoS, therefore this call should > > not fail just because the answerer doesn't support RSVP. So answerer just > > needs to finish the local network QoS reservation and ACKs the offerer > that > > e2e is met. In a word, for the answerer's point of view, "e2e"="remote". > > > > If an offerer doesn't support e2e QoS protocol, it can still put "e2e" in > > its offer, because from the offerer's point of view, "e2e"="local". > > > > Thanks > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: 26 February 2002 3:03 > > To: sip > > Cc: Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott; > > wtm@research.att.com; Jonathan Rosemberg > > Subject: [Sip] Manyfolks version 04 > > > > Hello, > > > > I have just submitted a new version of the manyfolks draft. Until it > > appears in the archives, you can fetch it from: > > > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.pdf > > > > > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.txt > > > > About the authorship of this draft, the ADs and the WG chairs decided > > that all the coauthors of previous versions but Bill had to be moved to > > a Contributors Section. > > > > The deadline for this draft is very close, so I would appreciate that > > folks read the draft and send comments as soon as possible. > > > > I have removed security preconditions (per mailing list discussion), but > > added a token that can be used to define new precondition types (the > > only type currently defined is "qos"). > > > > The draft uses two attributes: desired-status and current-status. When > > the current status reaches (or goes beyond) the desired status the > > preconditions are met. Instead of defining an absolute ordering for > > these two attributes, I have defined status tables. They are > > abstractions of the preconditions carried in the SDP. These tables help > > explain how status synchronization between both user agents is performed > > and when exactly all the preconditions are met. > > > > Feedback is appreciated, > > > > Best regards, > > > > Gonzalo > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.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 > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Tue Feb 26 14:59:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19410 for ; Tue, 26 Feb 2002 14:59:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16155 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 14:59:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15186; Tue, 26 Feb 2002 14:41:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15126 for ; Tue, 26 Feb 2002 14:40:59 -0500 (EST) Received: from zctfs063.nortelnetworks.com (h90s131a237n47.user.nortelnetworks.com [47.237.131.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18518 for ; Tue, 26 Feb 2002 14:40:54 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1QJeCL10182; Tue, 26 Feb 2002 20:40:12 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 19:40:16 -0000 Message-ID: From: "Mark Watson" To: "Peterson, Jon" , "'sip@ietf.org'" Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y Date: Tue, 26 Feb 2002 19:40:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BEFD.67A53C50" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BEFD.67A53C50 Content-Type: text/plain; charset="iso-8859-1" Jon, Makes sense, but two points: 1) If I don't encrypt my message body, I am presumably saying that I do trust any element to look at it, or I don't care. A Service Provider offering a service based on network-modification of the message body either forces me to send it un-encrypted (=less customers) or sets up the security systems needed for me to send it encrypted (=more customers) 2) I think the nub of the definition problem is that it is possible to build a device which modifies message bodies, and which deals with all of the 'UA-like' behaviour this entails, but which is stateless. There is no good name for this device as just the 'UA' in B2BUA implies transaction stateful however you define it (it logically contains UAs hence transaction layers). Whether you think something is anathama or an invention of genius, it is always a good idea to have a name for it. ...Mark > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 26 February 2002 05:05 > To: 'sip@ietf.org' > Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message > bod y > > > > Forbidding proxies to modify message bodies does not improve > security; it's > the other way around. The fact that we can secure messages > bodies end-to-end > entails that proxies may not be entitled to modify bodies. > > Mostly, this just reinforces the fact that bodies are intended for > end-to-end use. Many of the misconceptions about this issue > arise from a > belief that the operators of proxy servers are necessarily a > privileged > participant in a SIP network. Actually, if you are a 'network > operator', and > you want to inspect and modify bodies, you must have a trust > relationship > with users - they must accept that you, the network operator, are the > appropriate recipient of SIP message bodies, and they must secure MIME > bodies with that expectation (any encrypted bodies must be explicitly > intended to be decrypted by the network operator). In that sense, the > network operator becomes the destination of the request, and > thus more or > less a user - and this is why the discussion naturally transitions to > B2BUAs. I think this in no way diminishes the value of > network-based service > that require access to SIP message bodies - it just shows > that if you want > to offer these sorts of services, you require that users > trust you in a way > that they aren't asked to trust proxy servers, which operate only on > headers. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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_01C1BEFD.67A53C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] bis-07.9: proxies are not allowed to modify message = bod y

Jon,

Makes sense, but two points:
1) If I don't encrypt my message body, I am = presumably saying that I do trust any element to look at it, or I don't = care. A Service Provider offering a service based on = network-modification of the message body either forces me to send it = un-encrypted (=3Dless customers) or sets up the security systems needed = for me to send it encrypted (=3Dmore customers)

2) I think the nub of the definition problem is that = it is possible to build a device which modifies message bodies, and = which deals with all of the 'UA-like' behaviour this entails, but which = is stateless. There is no good name for this device as just the 'UA' in = B2BUA implies transaction stateful however you define it (it logically = contains UAs hence transaction layers).

Whether you think something is anathama or an = invention of genius, it is always a good idea to have a name for = it.

...Mark

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz= ]
> Sent: 26 February 2002 05:05
> To: 'sip@ietf.org'
> Subject: RE: [Sip] bis-07.9: proxies are not = allowed to modify message
> bod y
>
>
>
> Forbidding proxies to modify message bodies = does not improve
> security; it's
> the other way around. The fact that we can = secure messages
> bodies end-to-end
> entails that proxies may not be entitled to = modify bodies.
>
> Mostly, this just reinforces the fact that = bodies are intended for
> end-to-end use. Many of the misconceptions = about this issue
> arise from a
> belief that the operators of proxy servers are = necessarily a
> privileged
> participant in a SIP network. Actually, if you = are a 'network
> operator', and
> you want to inspect and modify bodies, you must = have a trust
> relationship
> with users - they must accept that you, the = network operator, are the
> appropriate recipient of SIP message bodies, = and they must secure MIME
> bodies with that expectation (any encrypted = bodies must be explicitly
> intended to be decrypted by the network = operator). In that sense, the
> network operator becomes the destination of the = request, and
> thus more or
> less a user - and this is why the discussion = naturally transitions to
> B2BUAs. I think this in no way diminishes the = value of
> network-based service
> that require access to SIP message bodies - it = just shows
> that if you want
> to offer these sorts of services, you require = that users
> trust you in a way
> that they aren't asked to trust proxy servers, = which operate only on
> headers.
>
> Jon Peterson
> NeuStar, Inc.
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP 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_01C1BEFD.67A53C50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 15:04:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19605 for ; Tue, 26 Feb 2002 15:04:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16821 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 15:04:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14925; Tue, 26 Feb 2002 14:39:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14894 for ; Tue, 26 Feb 2002 14:39:41 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18428 for ; Tue, 26 Feb 2002 14:39:35 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1QJdUZc000067; Tue, 26 Feb 2002 20:39:30 +0100 (MET) Received: from lmf.ericsson.se ([131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1QJdUmK029507; Tue, 26 Feb 2002 21:39:30 +0200 (EET) Message-ID: <3C7BE4B7.97DB5F72@lmf.ericsson.se> Date: Tue, 26 Feb 2002 21:40:40 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby CC: sip@ietf.org Subject: Re: [Sip] Bis-8: To tag question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > [Regarding 17.2.3] > >Yes. The tag will be different for each final response, but there > >will still be a tag in each final response (2xx or non-2xx), so that's > why I > >wondered how the server can decide if an ACK is for a 2xx just by > >looking if there is a tag or not (that's at least how I understood the > text, so I > >appologise if I missunderstood)... > > It's not so much that the proxy can just look at the > tag and somehow magically determine that it was in > a 2xx response. No, rather it's because the proxy > knows the tag it used in the non-2xx it sent; therefore, > if the tag in an ACK is not the same, it must be for > some 2xx. True. I just thought the text was a little unclear, giving the impression that the tag as such is an indication that the ACK is for a 2xx response... Thanks! Regards, Christer Holmberg Ericsson Finland > > > - Jo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 15:04:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19633 for ; Tue, 26 Feb 2002 15:04:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16844 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 15:04:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15636; Tue, 26 Feb 2002 14:47:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15606 for ; Tue, 26 Feb 2002 14:47:43 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18819 for ; Tue, 26 Feb 2002 14:47:39 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16fnZJ-0003QT-00; Tue, 26 Feb 2002 21:47:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15483.58953.732617.59623@harjus.eng.song.fi> Date: Tue, 26 Feb 2002 21:47:21 +0200 To: "Chen, Xin (Xin)" Cc: Gonzalo Camarillo , sip , Allison Mankin , Dean Willis , Biran Rosen , Joerg Ott , wtm@research.att.com, Jonathan Rosemberg Subject: RE: [Sip] Manyfolks version 04 In-Reply-To: <475FF955A05DD411980D00508B6D5FB00468F4F3@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00468F4F3@en0033exch001u.uk.lucent.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Chen, Xin (Xin) writes: > In 3GPP network, local QoS (caller) + Differv in the core + local QoS > (callee) = end to end even if i'm not any fan of 3gpp, the above is what i have advocated on this list several times and have thus questioned manyfolk's usefulness. because it is safe to assume that access is the only bottleneck in most networks, manyfolk becomes nothing more than unnecessary overhead. rsvp is one of those DoA ietf creations and i don't see it raising from death with the help of sip either. -- 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 daemon@optimus.ietf.org Tue Feb 26 15:10:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19798 for ; Tue, 26 Feb 2002 15:10:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17107 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 15:10:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15305; Tue, 26 Feb 2002 14:41:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15197 for ; Tue, 26 Feb 2002 14:41:26 -0500 (EST) Received: from zctfs063.nortelnetworks.com (h90s131a237n47.user.nortelnetworks.com [47.237.131.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18534 for ; Tue, 26 Feb 2002 14:41:21 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1QJeFL10190; Tue, 26 Feb 2002 20:40:15 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 19:40:19 -0000 Message-ID: From: "Mark Watson" To: Pete Cordell , Adam Roach Cc: sip@ietf.org Subject: Compatibility (was: RE: [Sip] bis-07.9: proxies are not allowed t o modify message body) Date: Tue, 26 Feb 2002 19:40:14 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BEFD.6960A7F0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BEFD.6960A7F0 Content-Type: text/plain; charset="iso-8859-1" There is an underlying issue here about the compatibility mechanism in SIP, which Pete touches on below. Many of the arguments about proxy modifying SDP breaking things seem to revolve around Require: The assumption in (Proxy-)Require: is that all new extensions will fall into one of the following categories: (i) extensions which can be freely ignored and silently dropped (no '(Proxy-)Require') (ii) extensions where support is required at endpoints only ('Require:') (iii) extensions where support is required at all proxies ('Proxy-require:') (iv) extensions where support is required at all elements (both) On the basis that all elements in the system are either proxies or endpoints, I think this assumption is valid for completely new protocol elements (e.g. new Headers with semantics independent of existing headers). But it is not valid for extensions to existing protocol elements. Suppose an element X already exists and I define an extension to this. This extension could be in one of the above classes, or it could be (v) extensions to existing element X, which can be freely ignored by elements which do not process X, but which MUST be understood by (proxies and/or endpoints) which do process X [Actually, this is really 3 classes because of the 'and/or'] [[By 'process' I mean interpret and/or modify]] SIP has no way of indicating that an extension is of this type. The absence of (v) in SIP has led us to make unchangable assumptions about which entities process existing elements in the protocol. If we assume that X is *only and always* processed by endpoints, then case (v) is equal to (ii) and we have no deficiency in the compatibility rules. Only if we make such assumptions does the compatibility mechanism allow us to make extensions to X. Now, this is not a big problem when X is a particular header. The semantics and scope of a given header are (hopefully) well defined and in many cases it is quite clear that 'such and such a header is always and only processed by endpoints' (*), or all elements etc. The problem arises when we have a large protocol element with no pre-defined semantics and much scope for extension. So, when X=Message Body, there is pressure to require that X cannot be processed by proxies. But people have used Message Bodies for things which other people think should be processed by proxies (e.g. SDP). If we had a compatibility mechanism which could express (v), we would not need to make any such limiting assumptions and the problem would go away. Instead, the solution proposed is that the devices which want to process message bodies must classify themselves as endpoints (for the purposes of compatibility) when manifestly they are not. But now all our assumptions (*) about 'such and such a header is always and only processed by endpoints' are wrong, because we have an 'endpoint' device which does not process most of these headers. Despite this, this device is required to recognise 'Require:' tags for extentions it would otherwise have no dealings with (e.g. 100rel), and even worse, it will choke on future extensions which have been designed to operate transparently between endpoints. This all seems rather backwards. IMHO, addressing the problem of compatibility for extensible protocol elements, would avoid this rat-hole. ...Mark > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: 26 February 2002 11:02 > To: Adam Roach > Cc: sip@ietf.org > Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message > body > > > ----- Original Message ----- > From: Adam Roach > > > We're getting a bit far off into a meta-discussion here, but I feel > > compelled to rebut some of your contentions. > > > > > -----Original Message----- > > > From: Pete Cordell [mailto:pete@tech-know-ware.com] > > > For me the main concern about a back to back UAS / UAC > implementation > > > (perhaps with the two instances joined by something other > > > than SIP) is tha > > > they lose feature transparency. It's the loss of feature > > > transparency that > > > is the problem, not that it is a B2BUA. There are many > > > devices that are not > > > pure proxies that do not lose feature transparency > > > > They can have feature transparancy *for* *certain* *features*. > > One of the reasons that "proxy" is defined to be such a narrow > > term is to allow the protocol to evolve without destroying the > > functionality of nodes in the middle of the network. For example, > > let's take the imaginary (if somewhat contrived) extension > > "ip-reversed," which indicates that IP addresses in the SDP > > will be in reversed order. Now, you have something you claim > > to be a proxy in the middle of the network, except it > > helpfully attempts to tweak the SDP if it thinks I'm coming > > through a NAT. It thinks it's a proxy, so it doesn't feel > > bound to obey the "Require: ip-reversed" header present in > > the message. > > > > Boom. > > > > This thing, no matter how similar it is to a proxy, has just broken > > the network by doing something that proxies are "not > supposed to do." > > > > In order to perform this sort of processing in a way that will work > > into the future, any node that does something that proxies aren't > > allowed to do MUST pay attention to the "Require" headers. I don't > > really care about the semantics of what you end up calling these > > things, as long as you don't confuse the issue by calling them > > "proxies." > > > > Would you prefer that you pushed me into producing a full > B2BUA and I bumped > you because you had a Require: header in there? Would you be > happy when you > called in to complain when I say "I would liked to have been > as transparent > to your service as I could, but the standard forced me to reject your > transaction." ? It wouldn't make me feel a whole lot better. > > And why don't I ring you up and say 'your new service broke > my proxy'..... > > This is a protocol design issue and not fundamentally an issue > about modifying bodies. For example, you could easily have defined > Body-Require:, or you could say that if the body no longer > means what it > used to mean, then give it a new Content-Type, e.g. Content-Type: > application/really-cool-sdp. Or define: Content-Type: > application/sdp-with-requires; require=really-cool. > > Actually this is an excellent example of why we should be > honest about what > is going to happen in the real world and say that proxies can > change bodies. > If we don't, then people will design services that will break > the system, > and that helps no one. > > > > Thus people are trying to build innovative products > > > delivering exciting > > > services beyond simple call routing, that are good netizens, > > > but they are > > > getting tarred as bad implementations by people that have > > > never seen them > > > simply because they are not pure proxies. > > > > They're not bad implementations. They *are* throttles to effective > > deployment of new services, since they must process, honor, and > > understand everything that comes by in a "Require" header. For > > example, if I and one of my friends got the newest, spiffiest > > terminals that had a *really* *cool* service -- one that necessarily > > used a "Require" header -- but one of the nodes that my call was > > routed thorough didn't support it, I promise you'd have me calling > > customer service to figure out why my new $800 phone didn't work > > as advertised. And you can be *darn* sure that I'd be pissed -- > > probably even pissed enough to go shopping for a new provider -- > > when I found out it's because you have a node in your network > > blocking my spiffy service, and that it'll take several months to > > a year for you to get an upgrade in place. > > > > Why should your potentially system breaking service be good, while my > service is bad. A good protocol should accommodate both > service types. > > (BTW - Surely you paid too much for your phone. Does it do > ISDN also ?!) > > > Is this an intentional smear campaign? No; it's just a statement > > of the ramifications of nodes pretending to be proxies doing > > things that proxies are not "supposed" to do. > > But the protocol designers say what a proxy should do. I'm > saying that the > current situation is not good for the long term. Between > what the standard > says now, and what people want to do with it, the SIP infrastructure > will be broken. > > > Are such impacts > > negative? It depends on whether you want to anger your end users; > > most people would say yes. But I've been the customer to uncountable > > companies who have taken the decision to piss of their customers > > (presumably) for some sort of trade off. It really comes down > > to a business decision. > > > > > After all, wasn't the promise of SIP that it could offer lots > > > of exciting > > > new services? Now an intermediary device can only do what I > > > can already do > > > on my domestic phone line. > > > > Of course, exciting services can *only* come from the *middle* of > > the network. I can't beleive that, until now, I had considered the > > possibility that the *endpoints* could provide nifty services. > > How naive of me (and the others who have been working on SIP for > > the past four years) to think that the web model of providing > > services might actually work. > > Typical crap that I would expect from some IETF members: if > in trouble - > manipulate words and flame. > > Calm down and consider the following - where did I say that > ALL services had > to be delivered from the middle. That's correct, no where. > Many services > will be delivered by end-systems. BUT many services will hopefully be > delivered by middle systems also. Hopefully it's not too much of a > revelation to you that some services fit better in the > end-systems and some > fit better in the middle. Blimey, some can even work in both > locations !!!! > > Or are you saying that you KNOW for a fact that the routing > that proxies > provide is the only service that can be delivered in the middle? > > ... cut rest as duplicated stuff already covered ... > > > > > /a > > This is getting us no where. I have raised the issue that > services in the > middle would like to change bodies. A number of e-mails in > this discussion > have confirmed this view. I also pointed out that a number of these > services are not implemented as full B2BUAs as defined in the > standard. > This e-mail demonstrates that there is a real issue if people > are not aware > that bodies might change. I've pointed out that the situation is not > improved if body modifying services are made into compliant > B2BUAs (they > will bump everything that has a Require: header whereas at least body > modifying Proxies would carry on). > > From these observations I have postulated that, if nothing is > done the SIP > infrastructure will be broken and consequently the services > that SIP can > offer will not be as rich as some had hoped. > > I am prepared to help work on solutions to these problems (I > don't think it > will take much solving), but if the inner circle do not wish > to consider > these issues, then that's fine by me also. > > Pete. > > ============================================= > Pete Cordell > Tech-Know-Ware > pete@tech-know-ware.com > +44 1473 635863 > ============================================= > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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_01C1BEFD.6960A7F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Compatibility (was: RE: [Sip] bis-07.9: proxies are not allowed = to modify message body)

There is an underlying issue here about the = compatibility mechanism in SIP, which Pete touches on below.

Many of the arguments about proxy modifying SDP = breaking things seem to revolve around Require:

The assumption in (Proxy-)Require: is that all new = extensions will fall into one of the following categories:
(i) extensions which can be freely ignored and = silently dropped (no '(Proxy-)Require')
(ii) extensions where support is required at = endpoints only ('Require:')
(iii) extensions where support is required at all = proxies ('Proxy-require:')
(iv) extensions where support is required at all = elements (both)

On the basis that all elements in the system are = either proxies or endpoints, I think this assumption is valid for = completely new protocol elements (e.g. new Headers with semantics = independent of existing headers).

But it is not valid for extensions to existing = protocol elements. Suppose an element X already exists and I define an = extension to this. This extension could be in one of the above classes, = or it could be

(v) extensions to existing element X, which can be = freely ignored by elements which do not process X, but which MUST be = understood by (proxies and/or endpoints) which do process X

[Actually, this is really 3 classes because of the = 'and/or']
[[By 'process' I mean interpret and/or = modify]]

SIP has no way of indicating that an extension is of = this type.

The absence of (v) in SIP has led us to make = unchangable assumptions about which entities process existing elements = in the protocol. If we assume that X is *only and always* processed by = endpoints, then case (v) is equal to (ii) and we have no deficiency in = the compatibility rules. Only if we make such assumptions does the = compatibility mechanism allow us to make extensions to X.

Now, this is not a big problem when X is a particular = header. The semantics and scope of a given header are (hopefully) well = defined and in many cases it is quite clear that 'such and such a = header is always and only processed by endpoints' (*), or all elements = etc.

The problem arises when we have a large protocol = element with no pre-defined semantics and much scope for extension. =

So, when X=3DMessage Body, there is pressure to = require that X cannot be processed by proxies. But people have used = Message Bodies for things which other people think should be processed = by proxies (e.g. SDP).

If we had a compatibility mechanism which could = express (v), we would not need to make any such limiting assumptions = and the problem would go away.

Instead, the solution proposed is that the devices = which want to process message bodies must classify themselves as = endpoints (for the purposes of compatibility) when manifestly they are = not. But now all our assumptions (*) about 'such and such a header is = always and only processed by endpoints' are wrong, because we have an = 'endpoint' device which does not process most of these headers. Despite = this, this device is required to recognise 'Require:' tags for = extentions it would otherwise have no dealings with (e.g. 100rel), and = even worse, it will choke on future extensions which have been designed = to operate transparently between endpoints.

This all seems rather backwards.

IMHO, addressing the problem of compatibility for = extensible protocol elements, would avoid this rat-hole.

...Mark



> -----Original Message-----
> From: Pete Cordell [mailto:pete@tech-know-ware.com]
> Sent: 26 February 2002 11:02
> To: Adam Roach
> Cc: sip@ietf.org
> Subject: Re: [Sip] bis-07.9: proxies are not = allowed to modify message
> body
>
>
> ----- Original Message -----
> From: Adam Roach = <adam@dynamicsoft.com>
>
> > We're getting a bit far off into a = meta-discussion here, but I feel
> > compelled to rebut some of your = contentions.
> >
> > > -----Original Message-----
> > > From: Pete Cordell [mailto:pete@tech-know-ware.com]
> > > For me the main concern about a back = to back UAS / UAC
> implementation
> > > (perhaps with the two instances = joined by something other
> > > than SIP) is tha
> > > they lose feature transparency.  = It's the loss of feature
> > > transparency that
> > > is the problem, not that it is a = B2BUA.  There are many
> > > devices that are not
> > > pure proxies that do not lose feature = transparency
> >
> > They can have feature transparancy *for* = *certain* *features*.
> > One of the reasons that "proxy" = is defined to be such a narrow
> > term is to allow the protocol to evolve = without destroying the
> > functionality of nodes in the middle of = the network. For example,
> > let's take the imaginary (if somewhat = contrived) extension
> > "ip-reversed," which indicates = that IP addresses in the SDP
> > will be in reversed order. Now, you have = something you claim
> > to be a proxy in the middle of the = network, except it
> > helpfully attempts to tweak the SDP if it = thinks I'm coming
> > through a NAT. It thinks it's a proxy, so = it doesn't feel
> > bound to obey the "Require: = ip-reversed" header present in
> > the message.
> >
> > Boom.
> >
> > This thing, no matter how similar it is to = a proxy, has just broken
> > the network by doing something that = proxies are "not
> supposed to do."
> >
> > In order to perform this sort of = processing in a way that will work
> > into the future, any node that does = something that proxies aren't
> > allowed to do MUST pay attention to the = "Require" headers. I don't
> > really care about the semantics of what = you end up calling these
> > things, as long as you don't confuse the = issue by calling them
> > "proxies."
> >
>
> Would you prefer that you pushed me into = producing a full
> B2BUA and I bumped
> you because you had a Require: header in = there?  Would you be
> happy when you
> called in to complain when I say "I would = liked to have been
> as transparent
> to your service as I could, but the standard = forced me to reject your
> transaction." ?  It wouldn't make me = feel a whole lot better.
>
> And why don't I ring you up and say 'your new = service broke
> my proxy'.....
>
> This is a protocol design issue and not = fundamentally an issue
> about modifying bodies.  For example, you = could easily have defined
> Body-Require:, or you could say that if the = body no longer
> means what it
> used to mean, then give it a new Content-Type, = e.g. Content-Type:
> application/really-cool-sdp.  Or define: = Content-Type:
> application/sdp-with-requires; = require=3Dreally-cool.
>
> Actually this is an excellent example of why we = should be
> honest about what
> is going to happen in the real world and say = that proxies can
> change bodies.
> If we don't, then people will design services = that will break
> the system,
> and that helps no one.
>
> > > Thus people are trying to build = innovative products
> > > delivering exciting
> > > services beyond simple call routing, = that are good netizens,
> > > but they are
> > > getting tarred as bad implementations = by people that have
> > > never seen them
> > > simply because they are not pure = proxies.
> >
> > They're not bad implementations. They = *are* throttles to effective
> > deployment of new services, since they = must process, honor, and
> > understand everything that comes by in a = "Require" header. For
> > example, if I and one of my friends got = the newest, spiffiest
> > terminals that had a *really* *cool* = service -- one that necessarily
> > used a "Require" header -- but = one of the nodes that my call was
> > routed thorough didn't support it, I = promise you'd have me calling
> > customer service to figure out why my new = $800 phone didn't work
> > as advertised. And you can be *darn* sure = that I'd be pissed --
> > probably even pissed enough to go shopping = for a new provider --
> > when I found out it's because you have a = node in your network
> > blocking my spiffy service, and that it'll = take several months to
> > a year for you to get an upgrade in = place.
> >
>
> Why should your potentially system breaking = service be good, while my
> service is bad.  A good protocol should = accommodate both
> service types.
>
> (BTW - Surely you paid too much for your = phone.  Does it do
> ISDN also ?!)
>
> > Is this an intentional smear campaign? No; = it's just a statement
> > of the ramifications of nodes pretending = to be proxies doing
> > things that proxies are not = "supposed" to do.
>
> But the protocol designers say what a proxy = should do.  I'm
> saying that the
> current situation is not good for the long = term.  Between
> what the standard
> says now, and what people want to do with it, = the SIP infrastructure
> will be broken.
>
> > Are such impacts
> > negative? It depends on whether you want = to anger your end users;
> > most people would say yes. But I've been = the customer to uncountable
> > companies who have taken the decision to = piss of their customers
> > (presumably) for some sort of trade off. = It really comes down
> > to a business decision.
> >
> > > After all, wasn't the promise of SIP = that it could offer lots
> > > of exciting
> > > new services? Now an intermediary = device can only do what I
> > > can already do
> > > on my domestic phone line.
> >
> > Of course, exciting services can *only* = come from the *middle* of
> > the network. I can't beleive that, until = now, I had considered the
> > possibility that the *endpoints* could = provide nifty services.
> > How naive of me (and the others who have = been working on SIP for
> > the past four years) to think that the web = model of providing
> > services might actually work.
>
> Typical crap that I would expect from some IETF = members: if
> in trouble -
> manipulate words and flame.
>
> Calm down and consider the following - where = did I say that
> ALL services had
> to be delivered from the middle.  That's = correct, no where. 
> Many services
> will be delivered by end-systems.  BUT = many services will hopefully be
> delivered by middle systems also.  = Hopefully it's not too much of a
> revelation to you that some services fit better = in the
> end-systems and some
> fit better in the middle.  Blimey, some = can even work in both
> locations !!!!
>
> Or are you saying that you KNOW for a fact that = the routing
> that proxies
> provide is the only service that can be = delivered in the middle?
>
> ... cut rest as duplicated stuff already = covered ...
>
> >
> > /a
>
> This is getting us no where.  I have = raised the issue that
> services in the
> middle would like to change bodies.  A = number of e-mails in
> this discussion
> have confirmed this view.  I also pointed = out that a number of these
> services are not implemented as full B2BUAs as = defined in the
> standard.
> This e-mail demonstrates that there is a real = issue if people
> are not aware
> that bodies might change.  I've pointed = out that the situation is not
> improved if body modifying services are made = into compliant
> B2BUAs (they
> will bump everything that has a Require: header = whereas at least body
> modifying Proxies would carry on).
>
> From these observations I have postulated that, = if nothing is
> done the SIP
> infrastructure will be broken and consequently = the services
> that SIP can
> offer will not be as rich as some had = hoped.
>
> I am prepared to help work on solutions to = these problems (I
> don't think it
> will take much solving), but if the inner = circle do not wish
> to consider
> these issues, then that's fine by me = also.
>
> Pete.
>
> = =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
> Pete Cordell
> Tech-Know-Ware
> pete@tech-know-ware.com
> +44 1473 635863
> = =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 mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP 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_01C1BEFD.6960A7F0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 15:26:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20394 for ; Tue, 26 Feb 2002 15:26:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17865 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 15:26:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17053; Tue, 26 Feb 2002 15:08:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17025 for ; Tue, 26 Feb 2002 15:08:38 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19759 for ; Tue, 26 Feb 2002 15:08:33 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1QK6hS05676 for ; Tue, 26 Feb 2002 15:06:43 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K40H128>; Tue, 26 Feb 2002 20:06:42 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00468F4F8@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: jh@lohi.eng.song.fi, "Chen, Xin (Xin)" Cc: Gonzalo Camarillo , sip , Allison Mankin , Dean Willis , Biran Rosen , Joerg Ott , wtm@research.att.com, Jonathan Rosemberg Subject: RE: [Sip] Manyfolks version 04 Date: Tue, 26 Feb 2002 20:06:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Well, although we shared some of the view, I still think manyfolks is useful but only for the side which needs precondition. Becuase it may take some time for the user to setup the access network QoS, precondition can make sure that the other side will wait for such a period of time. Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] Sent: 26 February 2002 19:47 To: Chen, Xin (Xin) Cc: Gonzalo Camarillo; sip; Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott; wtm@research.att.com; Jonathan Rosemberg Subject: RE: [Sip] Manyfolks version 04 Chen, Xin (Xin) writes: > In 3GPP network, local QoS (caller) + Differv in the core + local QoS > (callee) = end to end even if i'm not any fan of 3gpp, the above is what i have advocated on this list several times and have thus questioned manyfolk's usefulness. because it is safe to assume that access is the only bottleneck in most networks, manyfolk becomes nothing more than unnecessary overhead. rsvp is one of those DoA ietf creations and i don't see it raising from death with the help of sip either. -- 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 daemon@optimus.ietf.org Tue Feb 26 15:34:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20599 for ; Tue, 26 Feb 2002 15:34:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18474 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 15:34:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17465; Tue, 26 Feb 2002 15:14:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17442 for ; Tue, 26 Feb 2002 15:14:17 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19948 for ; Tue, 26 Feb 2002 15:14:12 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1QKDhS28741; Tue, 26 Feb 2002 14:13:43 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1QKDgb25478; Tue, 26 Feb 2002 14:13:42 -0600 (CST) Received: from lmf.ericsson.se (rmt160158.am.ericsson.se [138.85.160.158]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA06623; Tue, 26 Feb 2002 14:13:36 -0600 (CST) Message-ID: <3C7BEC93.F291BAA6@lmf.ericsson.se> Date: Tue, 26 Feb 2002 22:14:11 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Xin (Xin)" CC: sip , Allison Mankin , Dean Willis , Biran Rosen , Joerg Ott , wtm@research.att.com, Jonathan Rosemberg Subject: Re: [Sip] Manyfolks version 04 References: <475FF955A05DD411980D00508B6D5FB00468F4F3@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, "Chen, Xin (Xin)" wrote: > > Hi Gonzalo, > > You can only ask and wish there will be e2e QoS on both directions and you > can not make sure of this, becuase you always rely on the confirmation from > other party and you have to trust it! What is the problem trusting the other party? You also trust that the IP address that you receive in the offer is his real IP address, and that he is listing the codecs he really supports, etc... >According to my understanding, SIP is > a protocol not used for QoS reservation and it is independent to any QoS > reservation protocol, basically I can configure my SIP terminal to accept > any offer having "a=des:qos mandatory e2e sendrecv" even if my terminal > doesn't not support any QoS reservation protocol and I can still claim that > it is a terminal supporting manyfolks, because you can not say that my > terminal is not manyfolks supported simply because I don't support an end to > end QoS reservation protocol. Well, I can build a SIP terminal that receives INVITEs, generates a 200 OK with a correcty formed session description, but that does not alert the user, and does not play the media received thru the speakers, and does not even turn on the mic... it would be a correct SIP implementation from the syntax point of view, but I would be violating the protocol, because the messages I am sending do not reflect what is really happening... This is what you are proposing to do... > If you can, then this draft does tide SIP up > with QoS protocol. Well, that's exactly the idea behind the draft. Until QoS is not provided, the user is not alerted... > Simple question: What is the "end to end", where is the definition of end to > end QoS? > > In 3GPP network, local QoS (caller) + Differv in the core + local QoS > (callee) = end to end OK, you are the caller. How can you know that there is QoS beyond your DiffServ router?? You can only know that if you use the segmented type (the callee will tell you when he has QoS on his access network). You use the end to end type when you can be sure that there is QoS end to end (e.g, RSVP). Gonzalo > > In manyfolks, RSVP = end to end > > Which one is right? I think both are correct depending on the practical > situation. The only difference is that in 3GPP network, Differv is > pre-agreed based service level agreement, therefore, the user is not aware > of that. And for RSVP, the user is aware of that. This is the only > difference. But the 3GPP terminal's call will suffer the failing simple > becuase of this difference if we use those parameters like "e2e" in SDP. > > I hope you will not think that I am being aggressive because I really see > some hint in this draft to give the definition on what the end to end is and > what the local and remote is regarding on QoS reservation and we should not > do this. I don't want to hear one day a SIP developper says:"Becuase SIP > says this, therefore, we have to use the QoS reservation protocol."! > Bascially, SIP should not give any restriction on the terminal's > understanding on what end to end QoS. > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 26 February 2002 10:20 > To: Chen, Xin (Xin) > Cc: sip; Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott; > wtm@research.att.com; Jonathan Rosemberg > Subject: Re: [Sip] Manyfolks version 04 > > Hello, > > > > And "a=des:qos mandatory remote sendrecv" generated by the offerer has > the > > > same meaning as "a=des:qos mandatory e2e sendrecv" from the anserer's > > point > > > of view. > > > > No, they don't. If I am a 3GPP terminal, establishing the appropriate > > PDP context will meet the first precondition, but not the second. > > [XC] Then the call may fail, we don't want that happen! > > If the preconditions cannot be met, that's exactly what we want: the > call does not have to be established. > > Reading your second mail, what you want is the segmented type: that is, > you are telling the other end to do whatever he can on his side, and you > will do whatever you can on yours... as you said, in the middle you > might have DiffServ, for instance. > > But if you use the e2e type, you want to make sure that there are > resources end to end. Even if you know that you are in a Gigabit > ethernet and that your local router uses DiffServ, you still don't know > whether or not you have e2e QoS... that's why you need both types. > > That fact that all you want is the segmented type, does not mean that > other people cannot find the e2e type useful. > > Regards, > > Gonzalo > > We wish the call > > always successful! This is exactly my worry about the e2e parameter. In > > 3GPP, the terminal will not do RSVP and it uses PDP which is a local QoS > > machanism. We have Differv in the middle to provide the end to end QoS. We > > don't want a call to fail if an incoming offer requiring "e2e" to a 3GPP > > terminal or a 3GPP terminal initiates an offer with "local" parameter not > > "e2e". > > > > The e2e type is intended for e2e reservation protocols (this is stated > > in the draft, by the way). > > > > > > I think only "e2e" is needed. Because as a user, I don't care what local > > > access network another end is using, actually I even don't know what > > > protocol the other end is using for QoS, what I want is end to end QoS > for > > > my the video or audio streams. > > > > OK, so you will always use e2e qos. But other folks find it useful to > > have the segmented type... although this does not mean that you have to > > use it. > > [XC] No, my point of view is not to use any of them:e2e, local or remote. > > Thanks > > > > Thanks for your comments, > > > > Gonzalo > > > > >Therefore, it is up to the user agent to > > > intercept and decide whether e2e condition is met or not. > > > > > > For example, if the answerer receives an offer requiring e2e QoS > sendrecv, > > > but the answerer only supports local network QoS protocol and uses > Differv > > > in the core network to provide end to end QoS, therefore this call > should > > > not fail just because the answerer doesn't support RSVP. So answerer > just > > > needs to finish the local network QoS reservation and ACKs the offerer > > that > > > e2e is met. In a word, for the answerer's point of view, "e2e"="remote". > > > > > > If an offerer doesn't support e2e QoS protocol, it can still put "e2e" > in > > > its offer, because from the offerer's point of view, "e2e"="local". > > > > > > Thanks > > > > > > Xin Chen > > > > > > Lucent Technologies > > > Tel: +44 1793 883137 > > > Mobile: +44 7799 034668 > > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: 26 February 2002 3:03 > > > To: sip > > > Cc: Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott; > > > wtm@research.att.com; Jonathan Rosemberg > > > Subject: [Sip] Manyfolks version 04 > > > > > > Hello, > > > > > > I have just submitted a new version of the manyfolks draft. Until it > > > appears in the archives, you can fetch it from: > > > > > > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.pdf > > > > > > > > > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.txt > > > > > > About the authorship of this draft, the ADs and the WG chairs decided > > > that all the coauthors of previous versions but Bill had to be moved to > > > a Contributors Section. > > > > > > The deadline for this draft is very close, so I would appreciate that > > > folks read the draft and send comments as soon as possible. > > > > > > I have removed security preconditions (per mailing list discussion), but > > > added a token that can be used to define new precondition types (the > > > only type currently defined is "qos"). > > > > > > The draft uses two attributes: desired-status and current-status. When > > > the current status reaches (or goes beyond) the desired status the > > > preconditions are met. Instead of defining an absolute ordering for > > > these two attributes, I have defined status tables. They are > > > abstractions of the preconditions carried in the SDP. These tables help > > > explain how status synchronization between both user agents is performed > > > and when exactly all the preconditions are met. > > > > > > Feedback is appreciated, > > > > > > Best regards, > > > > > > Gonzalo > > > -- > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > Columbia University Mobile: +358 40 702 35 35 > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > New York, NY 10027 > > > USA Gonzalo.Camarillo@ericsson.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 > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.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 -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Tue Feb 26 16:40:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22598 for ; Tue, 26 Feb 2002 16:40:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA22733 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 16:40:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20216; Tue, 26 Feb 2002 16:04:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20186 for ; Tue, 26 Feb 2002 16:04:25 -0500 (EST) Received: from localhost ([218.51.121.72]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21603 for ; Tue, 26 Feb 2002 16:04:18 -0500 (EST) Message-Id: <200202262104.QAA21603@ietf.org> Reply-To: you@kimcad.co.kr From: 한국인텔리마케팅 To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 27 Feb 2002 05:59:52 +0900 Subject: [Sip] [광고]국산캐드 캐디안 가정용(학생용)특별보급 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Untitled Document


먼저 허락없이 메일을 발송드려 대단히 죄송합니다.
본 메일은 1회만 발송하는 광고메일입니다.
귀하의 메일 주소는 귀하께서 각종 게시판에 남기신 주소를 발췌한 것입니다.
혹시 도움이 되실까 메일 드렸으며 불쾌하셨다면 용서바랍니다.

연락처: young@kimcad.co.kr


  → AutoCAD와 동일한 명령어
  → AutoCAD의 모든 버전과 양방향 호환
  → AutoCAD와 흡사한 아이콘 사용

  → (매일경제신문,중기청,산자부)우수벤처로 선정(2001년)
  → (전국경제인연합회,국제산업협력재단) 유망벤처 20개 기업에 선정(2001년)
  → (한국경제신문)벤처리더 50인에 선정(2001년)
  → (산업자원부)산업협력대회 대통령상 수상(2000년)
  → (정보통신부)S/W 공모대전 우수상 수상(2000년)

  → VBA(Visual Basic Application)제외
  → 이미지 삽입기능 제외
  → 3D 기능 제한적임.

  평가판은 다음, 라이코스, 엠파스, 드림위즈, 쉐어웨어코리아(아이누리), 한미르, 심마니
  보물섬, 넷츠고, 휴먼컴 등의 자료실 그래픽 관련에서 다운로드 하실 수 있습니다.
 

제품명 제품구성 가격 비고 구매
CADian LT
 CD+교재1권
 25,000원
 AutoCAD 대응
CADian LT ARCH
 CD+교재2권
 45,000원
 건축설계용
CADian LT MECH
 CD+교재2권
 60,000원
 기계부품5,000만개 내장

※ ESD로 구매하시면 5,000원 할인.

  → '한국인텔리마케팅'의 홈페이지 www.kimcad.co.kr의 개인용 라이선스 에서 신청
  → 한글과컴퓨터,휴먼컴,보물섬,쉐어웨어코리아(아이누리) ,소프트비젼-MSshop 등의
... 인터넷 쇼핑
  ※ESD : Electronic Software Delivery(다운로드 구매)
  → 서울시내 대형서점(종로,영풍,코엑스의 서울문고 등)에서 구입
   
 
구입문의:한국인텔리마케팅   http://www.kimcad.co.kr
E-Mail : young@kimcad.co.kr   ☎ 전화:(02)6436-3685
 
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 19:02:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25673 for ; Tue, 26 Feb 2002 19:02:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA00327 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 19:02:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28679; Tue, 26 Feb 2002 18:31:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28576 for ; Tue, 26 Feb 2002 18:31:03 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24958 for ; Tue, 26 Feb 2002 18:30:59 -0500 (EST) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA25556 for ; Tue, 26 Feb 2002 18:31:04 -0500 (EST) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1QNV36X011292 for ; Tue, 26 Feb 2002 18:31:03 -0500 (EST) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.1/8.12.1/Submit) id g1QNV2bN011289; Tue, 26 Feb 2002 18:31:02 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15484.6838.162604.855503@grandcentral.cs.columbia.edu> Date: Tue, 26 Feb 2002 18:31:02 -0500 To: sip@ietf.org X-Mailer: VM 6.98 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit Subject: [Sip] Draft -08 comments, part 1: editorial Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I've just done a full read-through of draft -08. This is the first time I've read the whole document since bis -02 or -3, and I must say, this document is *worlds* better. Congratulations to all the authors and editors! I've divided my comments up into three sections: purely editorial changes, minor clarifications and consistency changes, and major issues where I dislike the normatively defined behavior. This message contains the editorial changes. All my comments use the line numbers from the PS/PDF versions of the spec, but I've quoted all the text from the text version, because it's easier to quote, and to confirm that any problems I've found exist in both versions. (As you requested, I've ignored PDF-only formatting issues.) "Status of this memo" section, line 11 To view the list Internet-Draft Shadow Directories, see ^ add "of" In general (many places throughout the document), first occurance in Section 4, line 430 Draft -08 changed all sorts of usages of un-adorned references [n] to instead read RFC NNNN [n], which is much clearer. However, this wasn't done for the drafts which are going to RFC in the bundle with 2543bis, which it probably should. First example of this is Section 4, line 430; I won't call them all out, since a search-and-replace on the \cite commands will be more effective. Section 8.1.1.2, line 897 All SIP implementations MUST support the SIP and URI scheme. Any ^ drop "and" Section 8.1.3.5, line 1234 server. The client SHOULD retry the request, this time, using a SIP URI. ^ drop "," Section 10.1, line 1530 An illustration of the overall registration process is given in 2. insert "Figure" ^ Section 13.2.1, line 2129 If the Content-Disposition header field is missing, bodies of Content-Type application/sdp imply the disposition "session", while other content types imply "render". This shouldn't be a \motivation (indented, and smaller in the PS/PDF) -- it's a normative statement. Section 16.6, line 2601 4. Optionally add a Record-route header field value ^ change to "R" (convention in the document is to spell it Record-Route) Section 16.6, line 2660 If the Request-URI contains a SIPS URI, or the topmost Route header field (after the post processing of bullet 6 contains a SIPS URI, the URI placed into the ^ insert ")" Record-Route header field MUST be a SIPS URI. Section 16.6, line 2752 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 (Section 16.3 A common way to create this value ^ insert "). " Section 16.7, line 2901 The UAS does not have to be a discreet process from the proxy. ^ change to "discrete", unless the UAS is good at keeping secrets. Section 16.7, line 2903 3-6xx responses are delivered hop-hop. ^ insert "by-" Section 17.1.2.1, line 3360 This is why request retransmissions need to continue even after a provisional response, they are to ensure ^ change to ": " reliable delivery of the final response. Section 20.30, line 4355 Examples of its use with the Route header field are described in Sections 16.12.1. ^ delete "s" Section 22.1, line 4856 A UAC MUST NOT re-attempt requests with the credentials that have just been rejected (though the request may be are retried ^ delete "are" if the nonce was stale). Section 22.3, line 4906 The use of Proxy-Authentication and Proxy-Authorization parallel that described in [17], with one difference. ^ insert "RFC 2617" Section 22.3, line 4914 When the originating UAC receives the 407 (Proxy Authentication Required) it SHOULD, if it is able, re-originate the request ^ insert "response" Section 23.2, line 5087 Note well however, that this key exchange mechanism does not guarantee the secure exchange of keys when self-signed certificates, or certificates signed by an obscure authority, are used - it is change to "--" ( "---" in LaTeX) ^ vulnerable to well-known attacks. Section 23.4.3, line 5308 motivationNote that if this mechanism is used for anonymity, the From ^ "insert '\'" -- i.e., fix LaTeX markup Section 26.1, line 5764 These attacks assume an environment in which attackers can potentially read any packet on the network - it is anticipated that change to "--" ( "---" in LaTeX) ^ Section 26.2, line 5874 Full encryption of messages provides the best means to preserve the confidentiality of signaling - it can also guarantee that messages ^ change to "--" ( "---" in LaTeX) Section 26.2.2, line 5924 A SIPS URI can be used as an address-of-record for a particular user - the URI by which the user is canonically known (on their business ^ change to "--" ( "---" in LaTeX) Section 26.2.2, line 5941 motivationNote that in the SIPS URI scheme, transport is independent ^ "insert '\'" -- i.e., fix LaTeX markup Section 26.3.2.1, line 6033 proxy server - attackers cannot create spoofed requests ^ change to "--" ( "---" in LaTeX) (There are a bunch more of these, but I'll stop mentioning them now. A grep should find them.) Section 28.1, line 6392 It is now well specified; if a request had a Route header field, its CANCEL or ACK for a non-2xx response to the request need to carry the same Route header field values. ^ add "s" Section 28.1, line 6425 o RFC 2543 defined, but did no sufficiently specify, a mechanism ^ add "t" -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 19:05:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25746 for ; Tue, 26 Feb 2002 19:05:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA00372 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 19:05:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28996; Tue, 26 Feb 2002 18:39:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28966 for ; Tue, 26 Feb 2002 18:39:52 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25137 for ; Tue, 26 Feb 2002 18:39:47 -0500 (EST) Received: from there (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1QNcnB30273; Tue, 26 Feb 2002 17:38:49 -0600 Message-Id: <200202262338.g1QNcnB30273@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: jh@lohi.eng.song.fi Subject: Re: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenario outside of 3GPP requirements) Date: Tue, 26 Feb 2002 17:38:48 -0600 X-Mailer: KMail [version 1.3.2] Cc: References: <002e01c1bedf$ce4b4b70$8b036e3f@DWILLISS1> <15483.49028.774363.798060@harjus.eng.song.fi> In-Reply-To: <15483.49028.774363.798060@harjus.eng.song.fi> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit On Tuesday 26 February 2002 11:01 am, jh@lohi.eng.song.fi wrote: Juha asks: > Dean Willis writes: > > When the phone turns on, it talks to the GGSN and receives a > > signaling PDP context for use with SIP. This PDP context's policy > > in the GGSN allows IP traffic between the UE and the SIP port on > > the P-CSCF. All SIP traffic goes between the phone and the P-CSCF > > over this signaling PDP context. The phone literally can't talk > > any other protocol to any other endpoint. > > my gprs phone can already today setup pdp contexts at will and send > register and other sip messages to anybody likes to by sending and > receiving ip packets over those contexts. i have been told that in > the next gprs release, the phone should be able to also tell the qos > requirements of these pdp contexts. are you saying that in all ip 3g > all this is going to go away and my phone can only talk to the > operator's p-cscf? There will be seperate GPRS "subscriptions" for IMS (Internet Multimedia Subsystem) service and for general Internet. You might have one or the other or both. The traffic on the signaling PDP context is probably billed to the IMS operator, rather than being charged to you on a per kB basis. The operator probably doesn't want to pay for your web surfing. And they assume you as a subscriber don't want to pay for all the registration bits and otehr things one expects are "free" on GSM. > > > There are lots of other obnoxious PTT regulatory stupidities in > > the model as well, but let's not go into those right now or my > > spleen might explode. > > i know the regulations here pretty well and i don't think any of the > 3g stupidity is in fact caused by it. it is caused by the operator's > and equipment vendors (because the operators feed them) desire to > lock the customer in into the walled garden. the sip working group > should not play any part in that conspiracy. There seem to be some claims that the regulations in Germany around privacy require that the To: and From: fileds are always encrypted or contain meaningless text. Hey, I don't understand it -- I'm just repeating what they tell me . . . but it's just crazy enough that I believe it. -- 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 daemon@optimus.ietf.org Tue Feb 26 19:05:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25763 for ; Tue, 26 Feb 2002 19:05:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA00389 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 19:05:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29087; Tue, 26 Feb 2002 18:42:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29056 for ; Tue, 26 Feb 2002 18:42:17 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25181 for ; Tue, 26 Feb 2002 18:42:13 -0500 (EST) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA26682 for ; Tue, 26 Feb 2002 18:42:17 -0500 (EST) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1QNgH6X011554 for ; Tue, 26 Feb 2002 18:42:17 -0500 (EST) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.1/8.12.1/Submit) id g1QNgGnZ011551; Tue, 26 Feb 2002 18:42:16 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15484.7512.130861.813280@grandcentral.cs.columbia.edu> Date: Tue, 26 Feb 2002 18:42:16 -0500 To: sip@ietf.org Content-Transfer-Encoding: 7bit Subject: [Sip] Draft -08 comments, part 3: "major" issues Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Here's part three of my comments on draft -08: "major" issues that would either change normative behavior, whose resolution isn't obvious, or that would require a significant amount of additional text to be added. None of them are really *that* major, though. (The line between this section and the previous one is sort of fuzzy, of course.) Again, my comments use the line numbers from the PS/PDF versions of the spec, but all text quotes come from the text version. In general: Do you have permission from the owners of atlanta.com, biloxi.com, and chicago.com for the use of their domains in the examples? All three are registered... Section 8.1.1.7: It'd be nice to have some explanation of what the magic cookie string "z9hG4bK" in the Via branch means and where it came from. Is it purely random? Section 8.3: The text on redirect servers seems a bit troubling. However, redirect servers MUST NOT redirect a request to a URI equal to the one in the Request-URI; instead, provided that the URI does not point to itself, the redirect server SHOULD proxy the request to the destination URI. I have no problem with the MUST NOT, but the SHOULD troubles me -- it means that there's no such thing as an unconditionally compliant pure redirect server, since every redirect server has to have some proxy functionality. I think it'd be better to leave handling of this scenario up to implementor discretion. (The whole concept of using a redirect server as an outbound proxy seems a bit bizarre.) Section 14.2, line 2314, says: A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog MUST return a 500 (Server Internal Error) response to the second INVITE I understand the concept and motivation, but isn't there a better error code than a plain 500 for this? Especially since this is really a client error. I don't see why this can't use 491 (Request Pending), just like the glare situation in the next paragraph does. Also in 14.2, at line 2344: If, however, it [the session description in an re-INVITE] is unacceptable to the UAC, the UAC SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session. This is the only case where a re-INVITE failure can lead to a session being torn down, as far as I can see. Would it be a good idea, therefore, to say that UACs SHOULD NOT do late offer-answer for re-INVITEs, i.e. SHOULD always include the existing session description in the re-INVITE? Section 16.7: The discussion of proxy response handling doesn't discuss the "final response received after a stateful proxy goes stateless" problem. This can happen if a downstream server is frozen, you time out, and then it comes back to life. In this scenario, a proxy can end up sending a non-2xx after a 2xx, multiple non-2xx responses, or multiple 2xx responses to a non-INVITE request. Is this forbidden, and if not, how is it dealt with? (This is mostly relevant for step 5.) On a similar note, does the spec require that you proxy responses upstream statelessly after you've torn down the response context, forbid it, or leave it optional? It's hard to tell... Section 16.7: Step 6 of proxy response handling says A proxy which receives a 503 (Service Unavailable) response SHOULD NOT forward it upstream unless it can determine that any subsequent requests it might proxy will also generate a 503. In other words, forwarding a 503 means that the proxy knows it cannot service any requests, not just the one for the Request-URI in the request which generated the 503. What if you only proxied to a single branch, and you got back a 503? You SHOULD NOT return it, and instead should make up some new response out of the whole cloth? That doesn't make much sense. Section 16.11: The discussion of stateless proxies says o A stateless proxy MUST choose one and only one target from the target set. This choice MUST only rely on fields in the message and time-invariant properties of the server. and Since a stateless proxy must forward retransmitted requests to the same destination and add identical branch parameters to each of them, it can only use information from the message itself and time-invariant configuration data for those calculations. If the configuration state is not time-invariant (for example, if a routing table is updated) any requests that could be affected by the change may not be forwarded statelessly during an interval equal to the transaction timeout window before or after the change. The method of processing the affected requests in that interval is an implementation decision. A common solution is to forward them transaction statefully. It seems from this text that it's not possible to design a stateless proxy server which bases its routing decisions on a REGISTER-based location service, since you can't anticipate the arrival of a REGISTER request and start proxying statefully. Is this true? If so, should it be called out more clearly? If not, what am I missing? Section 18.1.1: The discussion of the transport connection probably ought to mention something along the lines that the transport layer SHOULD NOT close TCP connections prematurely, for backward compatibility with RFC 2543-compliant devices which will interpret this as a CANCEL (client to server) or whatever the other-direction close meant. This might be hard to specify, though. Section 18.3: Should the section on transport framing have a note that multiple messages in a UDP packet has been deprecated, or is the mention of this in the big changes section enough? Section 19.1.4: What was the motivation for making URI comparisons non-transitive, and special casing certain uri-parameters? It seems like it just makes a lot of implementation things much harder. Wouldn't it be simpler just to say that uri parameters must match? This would mean that the URI comparison code could be completely ignorant of the semantics of URI parameter names, and old and new parameters are treated equally. Section 20.26 (Priority): You say that a message with no Priority field SHOULD be treated the same as "non-urgent". This conflicts with CPL, which treats a missing Priority as the same as "normal." These should probably be aligned. Section 20.42 (Via): This section says Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP". "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the protocol still indicates "SIP", and the transport protocol is TLS. What about TLS over SCTP? And is this abuse of the "transport" tag really a good idea here, given that it was decided that it was a bad idea in URIs? Section 20.42 (Via): The discussion of the branch parameter probably ought to re-mention the branch parameter's magic cookie. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 19:07:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25814 for ; Tue, 26 Feb 2002 19:07:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA00421 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 19:08:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28855; Tue, 26 Feb 2002 18:35:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28821 for ; Tue, 26 Feb 2002 18:35:30 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25024 for ; Tue, 26 Feb 2002 18:35:26 -0500 (EST) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA25920 for ; Tue, 26 Feb 2002 18:35:30 -0500 (EST) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1QNZU6X011386 for ; Tue, 26 Feb 2002 18:35:30 -0500 (EST) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.1/8.12.1/Submit) id g1QNZTTC011383; Tue, 26 Feb 2002 18:35:29 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15484.7105.81655.964012@grandcentral.cs.columbia.edu> Date: Tue, 26 Feb 2002 18:35:29 -0500 To: sip@ietf.org Content-Transfer-Encoding: 7bit Subject: [Sip] Draft -08 comments, part 2: clarifications and consistency Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Here's part two of my comments on draft -08: minor clarifications and consistency changes. Part 1 was editorial changes, and part 3 will be major issues. Again, my comments use the line numbers from the PS/PDF versions of the spec, but I've quoted all the text from the text version. Section 3 (or perhaps somewhere else?) There should be a note about the fact that \motivation blocks (the blocks that are indented, and smaller in the PS/PDF version) are non-normative. Also, the way the formatting works in the text version, some motivation blocks (ones in numbered lists) aren't distinguishable from their surrounding text. This would require some nroff hackery to fix, though. Section 4, line 393 / Section 7, line 783 / Normative References > ... [3] ... RFC 2822 is cited as a normative reference. I'm pretty sure it should be informative. Section 4, line 399 > Call-ID contains a globally unique identifier for this call, > generated by the combination of a pseudorandom string and the > softphone's IP address. ^^^^^^^^^^ In the example, the Call-ID is actually based the soft phone's FQDN ("pc33.atlanta.com"), not its IP address. So this should say "fully-qualified domain name", "host name", or similar. Section 6, line 638 > Header field value: A header field value consists of a field > name and a field value, separated by a colon. A header field value contains a field value? This is either wrong or very confusingly worded. I'm not exactly sure how it should be re-worded, because I'm not totally sure what the terminology is supposed to be. Section 6, line 738 > URL-encoded: A character string encoded according to RFC 1738, > Section 2.2 [6]. This should probably cite RFC 2396, section 2.4, instead. I'm pretty sure that section of 2396 entirely updates the corresponding parts of 1738. This will remove RFC 1738 from the normative references. Section 7.1, line 795 > Unlike HTTP/1.1, SIP treats the version number as a > literal string. In practice, this should make no > difference. This clarification obscures more than it clarifies, I think. What does this mean? Section 8.3, line 1298 > For > well-formed CANCEL requests, it SHOULD return a 2xx response. This > response ends the SIP transaction. This section about redirect servers and CANCEL is unclear. I think this would be clearer expressed as "it SHOULD return a 2xx to the CANCEL request, and then return 487 (Request Cancelled) to corresponding original transaction, if it has not yet completed." Alternately, the description of server behavior on CANCEL in section 9.2 should add a description of redirect server behavior. Section 10.2.2, line 1623 > The REGISTER-specific Contact header field value of "*" applies to > all registrations, but it MUST NOT be used unless the Expires header > field is present with a value of "0". An additional clarification would be helpful here, I think: 'Note that this expiration be expressed in an Expires header field, not the "expires" parameter. The ABNF for Contact described in Section 25 disallows header field parameters on "Contact: *".' Section 11, line 1755 > All UAs MUST support the OPTIONS method. This doesn't mention proxies, redirect servers, or registrars -- which I think also ought to support OPTIONS. Section 16.5, line 2553 > If the Request-URI does not provide sufficient information for the > proxy to determine the target set, it SHOULD return a 485 (Ambiguous) > response. This response SHOULD contain a Contact header field > containing URIs of new addresses to be tried. This contradicts section 21.4.23, which says that the 485 response MAY contain Contact headers, but that servers MUST be configurable to suppress them. I think that 21.4.23's requirement strengths should be used, for privacy reasons. Section 16.6, line 2673 > If a proxy needs to be in the path of any type of dialog > (such as one straddling a firewall), it SHOULD add a The wording there is infelicitous -- it's not clear whether the "one" in "one straddling" means "one proxy" or "one dialog". If it's supposed to be the former, the parenthetical phrase should be "(for instance, a proxy straddling a firewall)"; if the latter, "(such as a dialog straddling a firewall)". Section 16.6, line 2690 > The proxy MAY add any other appropriate header fields to > the copy at this point. "Appropriate" here is vague. There should probably be a forward reference to section 20, and in particular to the "proxy" column of tables 2 and 3. Section 16.6, line 2755 > A common way to create this value > is to compute a cryptographic hash of the To tag, From tag, > Call-ID header field, the Request-URI of the request > received (before translation) and the sequence number from > the CSeq header field, in addition to any Proxy-Require and > Proxy-Authorization header fields that may be present. Two sentences earlier, the text mentions that the value placed in the branch parameter SHOULD reflect any Route fields, in addition to the other header fields mentioned here. This should be added, in the list with the Proxy-Require and Proxy-Authorization headers. Section 16.7, line 2903 > 3-6xx responses are delivered hop-hop. When issuing a 3-6xx > response, the element is effectively acting as a UAS, > issuing its own response, usually based on the responses > received from downstream elements. An element SHOULD > preserve the To tag when simply forwarding a 3-6xx response > to a request that did not contain a To tag. While it's implicit here, I think it'd be useful to note that in the case when the element is acting as a UAS for generating 3-6xx, it must (among other things) insert To tags in its responses. This would make the final sentence make a lot more sense in the context, too. Section 16.11, line 3042 > Otherwise, the > first component of the branch ID is computed as a hash of the > topmost Via, the tag in the To header field, the tag in the > From header field, the Call-ID header field, the CSeq number > (but not method), and the Request-URI from the received > request. This should be the same list of headers as in the text from 16.6 I quoted above, right? So it should include Proxy-Require, Proxy-Authorization, and Route, i.e. everything that affects routing decisions. Yes? Section 17, line 3225 > The 2xx response and its ACK receive special treatment. This response > is retransmitted only by a UAS, and its ACK generated only by the > UAC. This end-to-end treatment is needed so that a caller knows the > entire set of users that have accepted the call. Because of this > special handling, retransmissions of the 2xx response are handled by > the UA core, not the transaction layer. Similarly, generation of the > ACK for the 2xx is handled by the UA core. Each proxy along the path > merely forwards each 2xx response to INVITE and its corresponding > ACK. The paragraph implies this, but it probably ought to be made clear that this behavior only applies to INVITE transactions. This is correct in the state machines. Section 17.1.1.1, line 3257 > For each final response that is received at the client > transaction, the client transaction sends an ACK, the purpose of > which is to quench retransmissions of the response. This is only true for non-2xx final responses. This is also correct in the state machines. Section 18, line 3535 > The transport layer is responsible for managing persistent > connections for transport protocols like TCP and SCTP, or TLS over > those, including ones opened to the transport layer. The meaning of "including ones opened to the transport layer" is unclear. Does this mean connections for which this entity is a transaction-layer server -- i.e. the accept() socket call rather than connect()? Section 18.1, line 3575 > If an element sends a request over TCP because of these message size > constraints, and that request would have otherwise been sent over > UDP, if the attempt to establish the connection generates either an > ICMP Protocol Not Supported, or results in a TCP reset, the element > SHOULD retry the request, using UDP. This is only to provide > backwards compatibility with RFC 2543 compliant implementations that > do not support UDP. Should be "that do not support TCP", yes? Section 18.2.1, line 3626 > It is also RECOMMENDED that a > server listen for requests on the default SIP ports (5060 for TCP and > UDP, 5061 for TLS over TCP) on all public interfaces. Shouldn't this specify the default port for SIP over SCTP and SIP over TLS over SCTP? I presume these are also 5060 and 5061 respectively. Section 19.1.2, table 1, note 1 (no line number) > (1): The default port value is transport and scheme dependent. The > default is 5060 for sip: using UDP, TCP, or SCTP. The default is > 5061 for sip: using TLS over TCP and sips: over TCP. Hasn't sip: using TLS over TCP disappeared from this draft, replaced by sips:? Looks like the figures might have been missed in the removal. Also, what about sips: over SCTP? Section 20.2 (Accept-Encoding), line 4050 > The > semantics in SIP are identical to those defined in [H14.3]. This contradicts the statement a few paragraphs down, which says that the semantics of a missing Accept-Encoding are different in SIP from those in HTTP. Section 20.10 (Contact), line 4150 > The second example below shows a Contact header field value > containing both a URI parameter (transport) and a header parameter > (expires). No it doesn't -- none of the examples have URI parameters. One probably should. Section 20.11 (Content-Disposition), line 4172 > If this header field is missing, the MIME type determines the default > content disposition. If there is none, "render" is assumed. This is presumably trying to back-reference section 13.2.1, line 2129, but it's doing a particularly bad job of it. This should explicitly mention which MIME types imply which content dispositions. Section 20.17 (Date), line 4229 > rfc1123-date is case-sensitive. Could this be worded better? You're referencing a BNF component here, which nothing else in section 20 does. Section 20.17 (Date), line 4232 > The Date header field can be used by simple end systems > without a battery-backed clock to acquire a notion of > current time. However, in its GMT form, it requires clients > to know their offset from GMT. "...if the current time is to be presented to a user." Section 20.27 (Proxy-Authenticate), line 4327 [no quote] There's no mention of the fact that the Proxy-Authenticate header field can appear multiple times in a message. I know [H14.33] and section 7.3.1 specify this, but this probably bears repeating here, with similar language to that of section 20.28 (Proxy-Authorization) -- don't comma-separate them. This comment also applies to section 20.44, WWW-Authenticate. Section 20.34 (Route), line 4391 > Examples of the use of the Record-Route > header field are in Section 16.12.1. This is true, but not immediately relevant to this section, which is talking about Route, not Record-Route. Change to "of the use of Route", I presume. Section 20.38 (Timestamp), line 4418 [no quote] This section probably ought to include an example of Timestamp with the optional delay parameter, as well. Section 22.1, line 4839 > For this reason, > any credentials in the INVITE that were accepted by a server MUST be > accepted by that server for the ACK. I'd re-word this as "any credentials in an INVITE that were accepted by a server MUST be accepted by that server for the INVITE's ACK." Or something like that. "The INVITE" in the original wording seems to refer to a specific INVITE, but the surrounding context doesn't imply one. Section 22.1, line 4840 > UACs creating an ACK message > will duplicate all of the Authorization and Proxy-Authorization > header field values that appeared in the INVITE to which the ACK > corresponds. Does this only apply to end-to-end ACKs, or should proxy servers insert Authorization and Proxy-Authorization in hop-by-hop (non-2xx) ACKs as well? Section 25.1, line 5640 > This is intended to behave exactly as HTTP/1.1 as described in RFC > 2616 [8]. I'd change the first "as" to "like" -- it flows better. Section 25.1, table, above line 5682 > transport-param = "transport=" > ( "udp" / "tcp" / "sctp" / "tls" > / other-transport) "tls" should be dropped here. Section 25.1, table, above lines 5695 and 5696 > Accept-Encoding = "Accept-Encoding" HCOLON > ( encoding *(COMMA encoding) ) > encoding = codings *(SEMI accept-param) > Accept-Language = "Accept-Language" HCOLON > ( language *(COMMA language) ) > language = language-range *(SEMI accept-param) When I said in my comment to 07.9 that Accept-Encoding and Accept-Language's parameters should be just like that of Accept, I didn't mean it *this* literally. A-E and A-L ought to have their own grammar elements, probably "a-e-param" and "a-l-param", defined the same as that of accept-param. This allows people adding new header paramers in a SIP extension to just redefine the BNF elements accept-param, a-e-param, or a-l-param, without having their new parameters apply to all three headers. Section 25.1, table, above line 5711 > wkday = "Mon" / "Tue" / "Wed" > / "Thu" / "Fri" / "Sat" / "Sun" > month = "Jan" / "Feb" / "Mar" / "Apr" > / "May" / "Jun" / "Jul" / "Aug" > / "Sep" / "Oct" / "Nov" / "Dec" Since section 20.17 says that the Date is case-sensitive, these grammar elements probably need to be spelled out in hex. Section 26.2.1, line 5907 > TLS provides transport-layer security over connection-oriented > protocols (for the purposes of this document, TCP); "tls" (signifying > TLS over TCP) can be specified as the desired transport protocol > within a Via header field value or a SIP-URI. Looks like a pre-sips remnant. Section 26.2.1, line 5917 > For > purposes of backwards compatibility, proxy servers, redirect servers, > and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Backward compatibility with what? 2543 didn't say anything about TLS, other than that it would be a nice idea to use it. We don't have to keep compatibility with older bis drafts. Section 26.2.2, line 5943 > The use of > "transport=tls" has consequently been deprecated, partly because it > was specific to a single hop of the request. This is a change since > RFC 2543. Again, 2543 didn't say anything about TLS. This is a change since earlier bis drafts, only, and so probably shouldn't be mentioned. Section 28.1, line 6391 > o Comments (expressed with rounded brackets) have been removed > from the grammar of SIP. Comments are still present in Retry-After, Server, and User-Agent. I think this is okay, but the change notice should clarify this. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Feb 26 19:21:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26148 for ; Tue, 26 Feb 2002 19:21:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01028 for sip-archive@odin.ietf.org; Tue, 26 Feb 2002 19:21:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29444; Tue, 26 Feb 2002 18:51:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29415 for ; Tue, 26 Feb 2002 18:51:21 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25422 for ; Tue, 26 Feb 2002 18:51:17 -0500 (EST) Received: from there (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1QNojB30355; Tue, 26 Feb 2002 17:50:46 -0600 Message-Id: <200202262350.g1QNojB30355@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: "Christian Huitema" , Subject: Re: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenario outside of 3GPP requirements) Date: Tue, 26 Feb 2002 17:50:44 -0600 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit On Tuesday 26 February 2002 11:00 am, Christian Huitema wrote: > > Well, using TLS to the coporate server wouldn't work, because I > > need > > to > > > coordinate with the SIP ALG in the proxy-firewall. > > The basic answer is, get a different proxy-firewall. There are two > fundamental problems with the "SIP ALG" approach: it breaks security, > and it breaks evolution. The security requirement is pretty simple: > if you cannot rely on end-to-end signature of the message body, you > don't know to whom you are sending the media; if you cannot rely on > end to end encryption of the body, you don't know who is snooping > your calls. The evolution requirement is also pretty simple: ALG only > translate what they understand, and they tend to hard wire that; if I > come out with smellovision (as an example ;-) and the ALG does not > understand it, poof, the smell is gone. The proper architecture is to > use some form of network level signaling to securely open holes in > the firewall. Well, that requires some sort of signaling coming from the phone to the firewall, which is another whole basket of worms. It also requires some AAA stuff that nobody has figured out how to manager. Also, corporate firewall admins have the same usage senitivity as do mobile operators. For example, coporate firewall administators ALSO require that they have application-level awareness of the firewall traversl. They aren't going to let me open a pinhole I claim is for a phone call and use it to watch streamoporn. At least, not if they have a choice. > > They (3GPP) have a requirement to provide, at operator discretion, > > very > > > strict control of network usage. It's almost as if the entire > > semantics of > > > ATM SVCs have been transplanted onto IP, with UNI replaced by > > application-level control. The operators want to do > > service-senstitive > > > AAA > > for the traffic. It's not the Internet. > > Well, you say it: what these operators want to build "is not the > Internet." On the other hand, this is the IETF, and the "I" stands > precisely for "Internet". As such, we have no requirement to placate > groups that want to develop a "not-Internet." They can develop a > specification that fits their need, say a "3G voice over IP wireless > signaling protocol"; the one thing they should not do is, try to > pretend this is an Internet standard. Well, the important thing is that it interwork cleanly with the Internet. I want a plan in one of those walled gardens to be able to (should the gardner allow them) interact with the rest of the world. They seem to agree, and are trying very hard to figure out how to do this. As we all know, 99% of the usage of Internet protocols is not really "in the Internet" nor is it completely consistent with "Internet Standards". Just look at all the networks out there running Microsoft products -- it's mostly an "enterprise internetworking" kind of world, laden with things like universal-plug-and-pray and not-quite-Kerberos. But it's still a constituency for the use of the protocols we produce. -- 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 daemon@optimus.ietf.org Wed Feb 27 01:50:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04334 for ; Wed, 27 Feb 2002 01:50:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA27705 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 01:50:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26569; Wed, 27 Feb 2002 01:21:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26443 for ; Wed, 27 Feb 2002 01:21:28 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03944 for ; Wed, 27 Feb 2002 01:18:48 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1R6InZc016361 for ; Wed, 27 Feb 2002 07:18:50 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1R6InmK025072 for ; Wed, 27 Feb 2002 08:18:49 +0200 (EET) Message-ID: <3C7C7A85.8E717438@lmf.ericsson.se> Date: Wed, 27 Feb 2002 08:19:49 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Question on draft-ietf-sip-100rel-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A question on draft-ietf-sip-100rel-05.txt. Chapter 3 says: "The UAS MAY send a final response to the initial request before having recevied PRACKs for all unacknowleged reliable provisional responses, unless any of the unacknowleged reliable provisional responses contained a session description. In that case, it MUST NOT send a final response until those provisional responses are acknowledged." If the UAS will generate a non-2xx response, does it still have to wait for a PRACK if the provisional response contained a session description? Why? Ie if the UAC wants to CANCEL the INVITE (a 487 final response will be sent), and receives a provisional response with a session description, why does it have to generate an answer/PRACK to that before it sends the CANCEL? There isn't going to be a session in any case... Regards, Christer Holmberg Ericsson 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 daemon@optimus.ietf.org Wed Feb 27 02:31:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12896 for ; Wed, 27 Feb 2002 02:31:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA29647 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 02:31:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27559; Wed, 27 Feb 2002 01:45:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27528 for ; Wed, 27 Feb 2002 01:45:52 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04253 for ; Wed, 27 Feb 2002 01:45:50 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1R6kB6Y018359; Wed, 27 Feb 2002 01:46:13 -0500 (EST) Message-ID: <3C7C8072.52A8609A@dynamicsoft.com> Date: Wed, 27 Feb 2002 01:45:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] Question on draft-ietf-sip-100rel-05.txt References: <3C7C7A85.8E717438@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > A question on draft-ietf-sip-100rel-05.txt. > > Chapter 3 says: > > "The UAS MAY send a final response to the initial request before > having recevied PRACKs for all unacknowleged reliable provisional > responses, unless any of the unacknowleged reliable provisional > responses contained a session description. In that case, it MUST NOT > send a final response until those provisional responses are > acknowledged." > > If the UAS will generate a non-2xx response, does it still have to wait > for a PRACK if the provisional response contained a session > description? No, actually. This is just for 2xx. I will fix. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 02:39:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12994 for ; Wed, 27 Feb 2002 02:39:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA29875 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 02:39:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27953; Wed, 27 Feb 2002 01:57:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27920 for ; Wed, 27 Feb 2002 01:57:14 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04461 for ; Wed, 27 Feb 2002 01:57:12 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1R6vZ6Y018362; Wed, 27 Feb 2002 01:57:36 -0500 (EST) Message-ID: <3C7C831E.C2E53857@dynamicsoft.com> Date: Wed, 27 Feb 2002 01:56:30 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brazier Lachlan CC: "'sip@ietf.org'" Subject: Re: [Sip] Small bits on sip-srv References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Brazier Lachlan wrote: > > Hello, > > some bits I've seen while reading the draft draft-ietf-sip-srv-05.txt > > 4.1 Third paragraph: > Similarly, if no TARGET is specified, and the TARGET is not numeric,... Oops. That should be "if no transport is specified". > > No TARGET, and it's even not numeric. Am I missing something? > > 4.1 - page 9 - second paragraph: > The reason s It is not necessary .... This is what happens when you edit documents at 4 in the morning. THis is a copy paste leftover. The sentence should start with "it is not necessary" > > 4.2: third paragraph: > The client SHOULD try the one of the records. > > Which one? The first, isn't it? It doesn't really matter, since there is really no prioritization supported with just A records. But, try first is probably best. I changed to indicate that. Thanks for your comments, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 03:11:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13465 for ; Wed, 27 Feb 2002 03:11:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA01694 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 03:11:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00157; Wed, 27 Feb 2002 02:47:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00123 for ; Wed, 27 Feb 2002 02:47:03 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13083 for ; Wed, 27 Feb 2002 02:47:00 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1R7dm6Y018380; Wed, 27 Feb 2002 02:39:49 -0500 (EST) Message-ID: <3C7C8D03.C1D95DA4@dynamicsoft.com> Date: Wed, 27 Feb 2002 02:38:43 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: "Chen, Xin (Xin)" , sip@ietf.org Subject: Re: [Sip] Question on Unify draft References: <475FF955A05DD411980D00508B6D5FB00468F401@en0033exch001u.uk.lucent.com> <3C7BB604.5DF3A991@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > > Hello, > > "Chen, Xin (Xin)" wrote: > > > > In this draft, in figure 4 (solution for One-of-N Codecs problem), it uses > > the a=inactive in the first offer to stop the callee to send media. But is > > it possible that the callee answers the offer by changing the a=inactive to > > a=active and starts to send media immediately? > > > > If this is possible, then this solution won't work, am I right? > > > > The direction attribute cannot be change in the answer. It has to be the > same as in the offer. See: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-offer-answer-01.txt Well, it can change it, but in this specific case, it cannot. If can basically be "downgraded", but not "upgraded" in the answer. Since inactive is the lowest "grade", it cannot be downgraded further and thus cannot change. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 03:16:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13595 for ; Wed, 27 Feb 2002 03:16:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA01963 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 03:16:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00099; Wed, 27 Feb 2002 02:46:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00064 for ; Wed, 27 Feb 2002 02:46:19 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13075 for ; Wed, 27 Feb 2002 02:46:16 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1R7kc6Y018396; Wed, 27 Feb 2002 02:46:39 -0500 (EST) Message-ID: <3C7C8E9D.315FCEF9@dynamicsoft.com> Date: Wed, 27 Feb 2002 02:45:33 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] Bis-8: merged requests References: <3C7B4D4A.FE2C78DB@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > A small comment on merged requests. > > Chapter 8.2.2.2 says: > > "If the request has no tag in the To header field, the UAS core MUST > check the request against ongoing transactions. If the To tag, From > tag, Call-ID, CSeq exactly match (including tags) those associated > with an ongoing transaction, but the branch-ID in the topmost Via > does not match, the UAS core SHOULD generate a 482 (Loop Detected) > response and pass it to the server transaction." > > The text doesn't say anything about the value of the Request-URI. I > think we all know it may be different in the merged request, but > shouldn't it be mentioned > in the text, since the Request-URI after all IS one of the transaction > mapping parameters? What it really needs to say is that if the request does not match that ongoing transaction, based on the transaction matching rules in Sextion XXX, the UAS core SHOULD ..... I'll fix. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 03:40:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13852 for ; Wed, 27 Feb 2002 03:40:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA03181 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 03:40:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01333; Wed, 27 Feb 2002 03:04:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01301 for ; Wed, 27 Feb 2002 03:04:21 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13373 for ; Wed, 27 Feb 2002 03:04:18 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1R84f6Y018400; Wed, 27 Feb 2002 03:04:42 -0500 (EST) Message-ID: <3C7C92D7.6BF192A5@dynamicsoft.com> Date: Wed, 27 Feb 2002 03:03:35 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: coreygates@attbi.com CC: sip@ietf.org Subject: Re: [Sip] Retry-After delta-seconds NIT in bis08 References: <20020226042338.NOPI2951.rwcrmhc53.attbi.com@rwcrwbc57> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit coreygates@attbi.com wrote: > > In section 14.2 (line 2321-2324) Retry-After is > described as having a value in units of 10 ms. Thus it > seems that a decimal value of Retry-After is possible. > > However, in the BNF, delta-seconds is defined as 1*DIGIT > (no decimal point) (line 5704) Thus is seems that only > a whole number of seconds is possible. > > I know this is small, but these two inconsistent > descriptions should probably be normalized if possible. YIKES!!!! This is no nit. This is fundamentally incorrect text in section 14.2. The whole idea of using a new response code (491) is that we wouldn't need to convey the retry intervals in a retry-after header, since its granularity is too coarse (seconds). Thus, all of the text in here on Retry-After is wrong. There is no Retry-AFter in 491. I will correct this section. My apologies for not properly verifying the edits made into the spec. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 03:45:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13959 for ; Wed, 27 Feb 2002 03:45:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA03413 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 03:45:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01935; Wed, 27 Feb 2002 03:15:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01910 for ; Wed, 27 Feb 2002 03:15:54 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13589 for ; Wed, 27 Feb 2002 03:15:52 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1R8GD6Y018404; Wed, 27 Feb 2002 03:16:14 -0500 (EST) Message-ID: <3C7C958D.F30DBA89@dynamicsoft.com> Date: Wed, 27 Feb 2002 03:15:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sip@ietf.org Subject: Re: [Sip] T4 References: <2038BCC78B1AD641891A0D1AE133DBB7779073@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > I included this in my comments in bis-07, but never got an answer. > > Why is T4 limited to 5 seconds for timer K in the case of non-INVITE > (section 17.1.2.2)? Sorry, I thought I had answered this somewhere. The idea is that you've sent a bunch of BYE requests, for example, and now you've got the final response. You want to hang around to catch any retransmits of that final response. How long to wait? The interesting thing about responses to BYE, is that they are not perioidcally sent; they are sent only in response to a request. So, the delay between sending a request, and getting a response, is equal to some value (say T4'), which represents the amount of time it takes for the request to get to the server, for the server to resend the response, and for the response to arrive at the client. Let T4 be the maximum value of T4' you might ever see, which I have set at around 5s. This should be more than sufficient. So, this means that if you've sent a retransmit of the request at time t, you would have received the response by t+T4 with very high probability, or you won't get one at all. So, if a UAC sends requests at times t1,t2,t3,t4, the responses would have arrived at t1+T4, t2+T4, t3+T4, t4+T4. The largest of those is t4+T4. Thus, we need to wait at least T4 seconds after the last request. Instead, we wait T4 after the first response, which is always more time (its simpler that way). Hope that helps. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 04:05:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14436 for ; Wed, 27 Feb 2002 04:05:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA04663 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 04:05:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03134; Wed, 27 Feb 2002 03:39:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03105 for ; Wed, 27 Feb 2002 03:39:41 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13840 for ; Wed, 27 Feb 2002 03:39:38 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1R8Vx6Y018408; Wed, 27 Feb 2002 03:32:00 -0500 (EST) Message-ID: <3C7C993E.9CFE7881@dynamicsoft.com> Date: Wed, 27 Feb 2002 03:30:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Jo Hornsby , sip@ietf.org Subject: Re: [Sip] Bis-8: To tag question References: <3C7BE4B7.97DB5F72@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I added a bit of clarifying text here. -Jonathan R. Christer Holmberg wrote: > > Hi, > > > [Regarding 17.2.3] > > >Yes. The tag will be different for each final response, but there > > >will still be a tag in each final response (2xx or non-2xx), so > that's > > why I > > >wondered how the server can decide if an ACK is for a 2xx just by > > >looking if there is a tag or not (that's at least how I understood > the > > text, so I > > >appologise if I missunderstood)... > > > > It's not so much that the proxy can just look at the > > tag and somehow magically determine that it was in > > a 2xx response. No, rather it's because the proxy > > knows the tag it used in the non-2xx it sent; therefore, > > if the tag in an ACK is not the same, it must be for > > some 2xx. > > True. I just thought the text was a little unclear, giving the > impression > that the tag as such is an indication that the ACK is for a 2xx > response... > > Thanks! > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > - Jo. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 04:07:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14462 for ; Wed, 27 Feb 2002 04:07:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA04695 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 04:07:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03222; Wed, 27 Feb 2002 03:40:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03195 for ; Wed, 27 Feb 2002 03:40:52 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13876 for ; Wed, 27 Feb 2002 03:40:49 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1R8fE6Y018411; Wed, 27 Feb 2002 03:41:15 -0500 (EST) Message-ID: <3C7C9B69.5910934@dynamicsoft.com> Date: Wed, 27 Feb 2002 03:40:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "David R. Oran" CC: sip@ietf.org Subject: Re: [Sip] multicast restricted to ttl=1 References: <002801c1bb56$33e48380$31ee2ca1@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "David R. Oran" wrote: > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of Jonathan Rosenberg > > Sent: Sunday, February 17, 2002 2:09 PM > > To: sip@ietf.org > > Subject: [Sip] multicast restricted to ttl=1 > > > > > > Folks, > > > > As a result of IESG review, there were concerns about the > > multicast usage of SIP. In particular, for the things we were > > using it for, it was felt that a limitation of scope to ttl=1 > > was needed. As such, I have modified the transport chapter to > > reflect a SHOULD level usage of ttl=1. > > > Well, according to bis-08, multicast can be used to find a registrar if > you don't have a DNS-discoverable proxy to route your register to. If > that's the purpose, what leads one to believe that the registrar is > likely to be on your local subnet? Well, more like, if its not on your subnet, multicast register is going to have some problems. > > Seems if multicast for regisration is useful at all, it makes more sense > for the discovery to either be via expanding ring broadcast and/or an > admin-scoped group. Without proper response suppression, reliability, and other multicast specific capabilities, we cannot do this properly. If there is sufficient interest, an extension can be defined to do this. > > BTW: bis-08 does not prohibit multicasting INVITES, which is equally > useful (which could be to say not very...) as multicasting > registrations, for completely infrastructure-less small configurations. > The same question about single-hop applies. Same answer. > > What am I missing? If I'm not missing anything and the SHOULD is an > attempt balance utility against danger, I'm not sure the balance is > right, since violating a SHOULD makes you only conditionally compliant, > whereas I can think of quite a few configurations which are small enough > to want to use this (e.g. for minimal functioality when your > proxy/registrar is pooched) yet span more than one subnet. It is an attempt to balance utility against danger. Unfortunately, SIPs processing at the higher layers is strongly based on a single non-2xx response per request, an assumed invariant that is false as a result of multicast. As such, we are not going to properly process the other responses, leaving transactions hanging, and so on. We also have no response suppression mechanisms. As such, use of multicast except in the most limited confines and use cases is both dangerous and moderately broken. However, enough people whined when I proposed to remove it entirely, that it remains in this more limited form. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 04:21:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14641 for ; Wed, 27 Feb 2002 04:21:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA05319 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 04:21:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03705; Wed, 27 Feb 2002 03:51:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03674 for ; Wed, 27 Feb 2002 03:51:06 -0500 (EST) Received: from smtp01ffm.de.uu.net (smtp01ffm.de.uu.net [192.76.144.150]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14033 for ; Wed, 27 Feb 2002 03:51:02 -0500 (EST) Received: from penelope.materna.de (penelope.materna.de [193.96.115.65]) by smtp01ffm.de.uu.net (5.5.5/5.5.5) with ESMTP id JAA28069; Wed, 27 Feb 2002 09:51:35 +0100 (MET) Received: from ganymed (ganymed.materna.de [139.2.34.141]) by penelope.materna.de (Postfix) with ESMTP id 144F667F5; Wed, 27 Feb 2002 09:51:02 +0100 (MET) Received: from pdc-gp.materna.de (actually localhost) by ganymed with Internet with ESMTP; Wed, 27 Feb 2002 09:51:02 +0100 Received: by pdc-gp.materna.de with Internet Mail Service (5.5.2653.19) id <16P6TRBB>; Wed, 27 Feb 2002 09:50:59 +0100 Message-ID: <73B855B4F72FD411A1CF009027B113C40199F6AF@taxis.materna.de> From: thomas.nagel@materna.de To: dean.willis@softarmor.com Cc: sip@ietf.org Subject: AW: [Sip] AW: Why Proxies are Good and B2BUAs May Not Be --> NO Date: Wed, 27 Feb 2002 09:50:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Dean, perhaps I was a bit struck with the SIMPLE world that I'm currently working on, so it's that pair of glasses that I'm looking through just now. > Thomas asks: > > just curious: how would you classify a 'gateway' (my > termporary name) > > that translates SIP-via-XML to and from SIP/2.0/UDP ? ... > It's a "gateway". From a SIP perspective, it's just a UA, > just as a phone > is a UA that translates SIP and RTP to/from user interface and sound. Oh, I did not talk abaout any transport layer, RTP or whatever. That would be a totally different matter. > Other gateways include SIMPLE<->Jabber, SIP<->H.323, SIMPLE<->AOL, > SIP<->SS7, and so on . . . True. But what about a thing, that would not change the "upper layers" of SIP. Say, translating the SIP messages received over XML/HTTP to standard SIP over UDP. This could be coupled with a "standard" SIP proxy of course. So it would then be a proxy that accepted only a new transfer encoding of SIP. > Essentially, anything that does SIP->somethingelse->SIP can > be considered a > form of B2BUA. No. Only *if* it changes the data. >Feature transparency across such a stucture > requires a fully > homomorphic mapping between SIP and somethingelse. It does not map SIP to something else, it only encapsulates the SIP header fields into XML-tags. ... > > My personal view: > > I personally feel the term SIP 'proxy' as badly chosen, as > it implies > > that the usual connection model were end-to-end, very much like > > the original SMTP-model RFC821, where users would work as logged-in > > users on multi-user machines (SysVR4 whatever;). > > As with E-Mail, I would expect this model to vanish from the > > SIP-world, just like it is the far minority for SMTP nowadays. > > So I'd rather call a SIP 'proxy' a SIP "server". > > Actually, the idea is that that SIP proxy functions are very > analagous to > SMTP relays. They apply some policy control, and forward > messages on to > their destination using layer 4+ routing information with > very little regard > for (and hopefully little alteration of) the actual content > of the messages. I don't really understand how you distinguish a SIP proxy from an RTP streaming server (or any other end-to-end data channel) here. At least, if not talking about in-band user-data, like SIMPLE. > > Likewise I'd say a REGISTER will eventually be used like a 'LOGIN'. > > In the RFC, one can easily imagine, that such a clarification would > > put away a lot of puzzeling of terms in the REGISTER examples. > > Yeah, this one really confuses people with a background in GSM mobile > phones, where registration IS "login". I probably spend two > days a week > fighting this hydra, and it grows back its heads faster than > can burn them > off. My suggestion was to rename the REGISTER message > "SETCONTACT", but the > lead editors for the spec were not amused. > > Dean As I said before, I was a bit stuck to the SIMPLE view... Perhaps the semantics of SIP are a bit strained by SIMPLE with regard to the REGISTER process. And, could you give me a pointer, which 3G doc defines the relation between SIP user registry (shouldn't it be in VHE?) and HSS? Thanks. ;) Anyway, I would still like to know how you think about an XML-transmission of SIP messages. It could do a lot good. Just think about the big number of clients that support XML, and the overwhelming support of servlets, which can easily be used for XML, but not for SIP-over-UDP nor SIP-over-TCP. Best greetings, Thomas Nagel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 04:37:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14859 for ; Wed, 27 Feb 2002 04:37:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA06325 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 04:37:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05112; Wed, 27 Feb 2002 04:13:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05081 for ; Wed, 27 Feb 2002 04:13:43 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14538 for ; Wed, 27 Feb 2002 04:13:39 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1R9E16Y018432; Wed, 27 Feb 2002 04:14:02 -0500 (EST) Message-ID: <3C7CA318.489B1206@dynamicsoft.com> Date: Wed, 27 Feb 2002 04:12:56 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fuxbruner, Amihay" CC: sip@ietf.org Subject: Re: [Sip] 491 Retry-After missing bis 07 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks for the comment. As it turns out, 491 should never have Retry-After in the first place; this is a serious error we found last-minute, and corrected. So, the table is correct at least ;) -Jonathan R. "Fuxbruner, Amihay" wrote: > > Hi, > > Retry-After in Table 3 (Summary of header fields) missed 491. > > Regards, > > Amihay Fuxbruner > System Engineering - Signaling R&D > Comverse > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 04:37:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14875 for ; Wed, 27 Feb 2002 04:37:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA06341 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 04:37:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04791; Wed, 27 Feb 2002 04:08:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04762 for ; Wed, 27 Feb 2002 04:08:50 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14484 for ; Wed, 27 Feb 2002 04:08:46 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1R966Zq017564; Wed, 27 Feb 2002 04:06:07 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGKD0>; Wed, 27 Feb 2002 04:08:11 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36B4633@DYN-TX-EXCH-001.dynamicsoft.com> From: Andrew Allen To: "'Dean Willis'" , Christian Huitema , sip@ietf.org Subject: RE: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenari o outside of 3GPP requirements) Date: Wed, 27 Feb 2002 04:08:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, February 26, 2002 5:51 PM > To: Christian Huitema; sip@ietf.org > Subject: Re: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path > scenario outside of 3GPP requirements) > > > On Tuesday 26 February 2002 11:00 am, Christian Huitema wrote: > > > Well, using TLS to the coporate server wouldn't work, because I > > > need > > > > to > > > > > coordinate with the SIP ALG in the proxy-firewall. > > > > The basic answer is, get a different proxy-firewall. There are two > > fundamental problems with the "SIP ALG" approach: it breaks > security, > > and it breaks evolution. The security requirement is pretty simple: > > if you cannot rely on end-to-end signature of the message body, you > > don't know to whom you are sending the media; if you cannot rely on > > end to end encryption of the body, you don't know who is snooping > > your calls. The evolution requirement is also pretty > simple: ALG only > > translate what they understand, and they tend to hard wire > that; if I > > come out with smellovision (as an example ;-) and the ALG does not > > understand it, poof, the smell is gone. The proper > architecture is to > > use some form of network level signaling to securely open holes in > > the firewall. > > Well, that requires some sort of signaling coming from the > phone to the > firewall, which is another whole basket of worms. It also requires > some AAA stuff that nobody has figured out how to manager. > > Also, corporate firewall admins have the same usage senitivity as do > mobile operators. For example, coporate firewall administators ALSO > require that they have application-level awareness of the firewall > traversl. They aren't going to let me open a pinhole I claim is for > a phone call and use it to watch streamoporn. At least, not if they > have a choice. > > > > They (3GPP) have a requirement to provide, at operator discretion, > > > > very > > > > > strict control of network usage. It's almost as if the entire > > > > semantics of > > > > > ATM SVCs have been transplanted onto IP, with UNI replaced by > > > application-level control. The operators want to do > > > > service-senstitive > > > > > AAA > > > for the traffic. It's not the Internet. > > > > Well, you say it: what these operators want to build "is not the > > Internet." On the other hand, this is the IETF, and the "I" stands > > precisely for "Internet". As such, we have no requirement to placate > > groups that want to develop a "not-Internet." They can develop a > > specification that fits their need, say a "3G voice over IP wireless > > signaling protocol"; the one thing they should not do is, try to > > pretend this is an Internet standard. > > Well, the important thing is that it interwork cleanly with the > Internet. I want a plan in one of those walled gardens to be able to > (should the gardner allow them) interact with the rest of the world. > They seem to agree, and are trying very hard to figure out how to do > this. Agree with Dean. I at least want to see convergence of telecommunications and the internet. It's not the case of one supplanting the other but a merging of the two. The 3GPP operators are not one big monoloithic group. The GSM Association consists of over 400 operators in 171 countries and with 3G this group is going to become even larger. Some of these operators have a very conservative outlook and others have a much more open forward looking view. The 3GPP architecture enables all these different business models to be supported. There is a saying that "rattlesnakes don't commit suicide", does anyone really expect that the existing mobile operators are just going to give away their existing customer base to competitors and relinguish being a player in the services business becoming simply sellers of bits? Especially when in many countries they have paid IN ADVANCE as much as $8 BILLION for a single operating license. That's about as likely as Microsoft opening up all the internals of windows to everyone. Competition will sort out which business models will win for 3G. > > As we all know, 99% of the usage of Internet protocols is not really > "in the Internet" nor is it completely consistent with "Internet > Standards". Just look at all the networks out there running Microsoft > products -- it's mostly an "enterprise internetworking" kind > of world, > laden with things like universal-plug-and-pray and > not-quite-Kerberos. > But it's still a constituency for the use of the protocols we produce. There are about 900 MILLION mobile phones in the world growing towards 1 BILLION. That's more than all the PCs out there. If most of those phones in the future are using SIP what a huge base for enabling a revolution in new services. The 3GPP architecture with the Home network services model (which the Path header is an enabler for) is an enabler for the Virtual Mobile Network Operator (VMNO). These VMNOs already exist in many countries already for instance Virgin Mobile in the UK. These VMNOs do not have a wireless access infrastructure but have a customer base and through a business agreement with another operator that has a wireless infrastructure are able to offer mobile services to it's customers. I look forward to the day when I will have a choice for the supplier of my mobile services from amongst the Microsofts, AOLs, Yahoos of the world as well as from the Vodafones and AT&T's. Andrew > > -- > 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 daemon@optimus.ietf.org Wed Feb 27 04:42:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15024 for ; Wed, 27 Feb 2002 04:42:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA06818 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 04:42:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04995; Wed, 27 Feb 2002 04:11:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04876 for ; Wed, 27 Feb 2002 04:10:53 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14512 for ; Wed, 27 Feb 2002 04:10:49 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1R9BD6Y018428; Wed, 27 Feb 2002 04:11:14 -0500 (EST) Message-ID: <3C7CA270.3DC194F9@dynamicsoft.com> Date: Wed, 27 Feb 2002 04:10:08 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: sip@ietf.org References: <3C759F50.6685D5B0@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] bis-08 is born Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > Jon, > > Still behind in my reading - this is a question about a change that must > have first appeared in bis-06 or -07. But I will refer to -08 here: > > In lines 1709-1710 (section 10.3 item 6) is a rule that a REGISTER > containing Contact:* must not contain any other contact lines. Why has > this restriction been added? I don't see any great benefit to imposing > this restriction, and it could be inconvenient. I had always assumed that if there was a *, it was only *; the change was to merely clarify what I (at least) thought was always the case. > > If there might be a prior registration, and the intent is for a new > registration to supercede that, life becomes difficult. Either this > requires two REGISTERs, one with Contact:* and then another with the > desired new values, or else the exact set of prior contact headers must > be known, and the new REGISTER must repeat all the old contact > addresses, with expires=0. Right. From a particular UA, that will generally be both feasible and the right thing to do. It only ceases to work when you want to cancel a contact from another UA, different from the one which created the contact. This is not likely to be a common case. A UA would not normally delete ALL registrations unless the user explicitly instructed it to. Otherwise, you would never be able to have multiple devices associated with a single AOR. For example, if I log in at work, and then go home, my home PC is not going to normally unregister every other contact. It will merely register and manage its own. Its only if I say "oops! forgot to log out of work, let me delete that registration" that I might select a specific option to delete all registrations. That deletion is quite separate from the registration on that phone itself. So, I have no problem with sending two REGISTER in this case. > > Why not simply state that if a Contact:* is present it must be processed > before the other Contact entries? Another reason - the text says you can only use Contact:* when Expires:0 is there, which further validates my claim that this has always meant to be used alone. > > - > > I also have another register related issue that should have been raised > sooner. It is presumably too late to deal with now, but I raise it in > hopes that there will be an opportunity to consider it at some future > time: > > In lines 1733-1739 (section 10.3 item 7) the rules are specified for > matching and replacement of individual bindings. As worded, I believe > this would result in aborting any REGISTER that contains multiple > Contact entries with the same address. Back in bis-05 and before the > handling of this case was ambiguous. It is still slightly ambiguous > because it isn't entirely clear if items that have been tentatively > added are to be searched. Yes, it is ambigous. I had not considered this case. > > Of course it is silly to have two Contact entries with the same address > if there is nothing else to be different about them. But the built in > extension mechanisms permit the construction of different contact > headers with the same address but different parameters, and the > callerprefs draft does so. With that draft is is indeed useful to be > able to do so. I don't think it would help if the tentative ones are included, since subsequent ones would overwrite. If you exclude tentative ones, then you need to define what it means to tentatively add the same binding twice. Also, the result would be that putting two identical contacts, but with different contact params, in the same register, would be different than if you put the same two in different registers. That seems wrong. Also, how would replacement work? That is, if I register two contacts that are identical URI: COntact: sip:A;param1=val1 Contact: sip:A;param2=val2 What would it mean to later receive a REGISTER like: Contact: sip:A;param3=val3 does this replace one of the two previous, or both? I think that it is easier to have the contacts be different through differing URI parameters or user parts. That gives you the flexibility to effectively register multiple "equivalent" URI to the same binding, but requires no changes to the spec. Furthermore, it allows the UA to know which of its contacts was chosen, which is probably useful. > > A minor change to the wording in this section would permit multiple > contact entries with the same address to be delivered in a single > REGISTER: > > "For each address, the registrar then searches the list of current > bindings using the URI comparison rules, excluding those tentatively > added while processing this request. If no matching binding exists, one > is tentatively added. If one or more matching bindings do exist, the > registrar checks the Call-ID value of each. If the Call-ID value in a > matching binding differs from the Call-ID value in the request, the > binding MUST be removed if the expiration time is zero and updated > otherwise. If they are the same, the registrar compares the CSeq value. > If the value is higher than that of the existing binding, it MUST update > or remove the binding as above. If not, the update MUST be aborted and > the request fails." That text would not be sufficient; see above. A lot more would need to be specified. Since there is an alternative that requires no changes but allows you to meet your requirements, I would prefer that route. > > (There may be clearer wordings, but this is a minimal change.) > > In the earlier discussion Jon and others suggested hacks to work around > this, such as using addresses distinguished by a URL parameter. But > those are hacks, while this is not. I don't think its a hack at all. You need to think of the user part, or that URI parameter as a "cookie" which allows you to register a set of contacts, and then know which one was selected based on the cookie present in the incoming r-uri. With the new loose route stuff, the record-route header has gone in this direction exactly. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 05:07:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15462 for ; Wed, 27 Feb 2002 05:07:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA08033 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 05:07:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06771; Wed, 27 Feb 2002 04:41:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06737 for ; Wed, 27 Feb 2002 04:41:26 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15011 for ; Wed, 27 Feb 2002 04:41:22 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1R9fj6Y018436; Wed, 27 Feb 2002 04:41:46 -0500 (EST) Message-ID: <3C7CA998.81223853@dynamicsoft.com> Date: Wed, 27 Feb 2002 04:40:40 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: sip@ietf.org Subject: Re: [Sip] a couple problems in draft-ietf-sip-rfc2543bis-07.9 References: <006501c1ba2b$a76d4200$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bob Penfield wrote: > > Two problems in draft-ietf-sip-rfc2543bis-07.9 > > 1) The definitions of "Header field" and "Header field value" (at lines > 635-637) do not match their usage in the text. A "Header field" is a > field > name plus a colon followed by one or more header field values separated > by > comma. The "Header field value" is simply a singular field-value (or > header-value) in a Header field. I agree. I'll fix. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 05:39:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15841 for ; Wed, 27 Feb 2002 05:39:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA09622 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 05:39:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07375; Wed, 27 Feb 2002 04:58:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07350 for ; Wed, 27 Feb 2002 04:58:06 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15337 for ; Wed, 27 Feb 2002 04:58:00 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16g0qX-0003n1-00; Wed, 27 Feb 2002 11:58:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15484.44457.526663.207868@harjus.eng.song.fi> Date: Wed, 27 Feb 2002 11:58:01 +0200 To: Andrew Allen Cc: "'Dean Willis'" , Christian Huitema , sip@ietf.org Subject: RE: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenari o outside of 3GPP requirements) In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F36B4633@DYN-TX-EXCH-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F36B4633@DYN-TX-EXCH-001.dynamicsoft.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Andrew Allen writes: > There are about 900 MILLION mobile phones in the world growing towards 1 > BILLION. That's more than all the PCs out there. If most of those phones in > the future are using SIP what a huge base for enabling a revolution in new > services. the 3gpp architecture is not enabling that revolution, but is trying to prevent it by forcing the subscribers to use the services of its home 3g operator. the subscriber should have true freedom to choose services from anywhere on the internet instead. as a started, what freedom is it that i need to register before i can start making calls? the sip spec doesn't force you to do that, but 3gpp does. i think enough bandwidth has already been wasted for this. it should already be clear to everyone, that ietf should not have anything to do with 3gpp's usage of a signaling protocol that they falsely try to claim to be sip. -- 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 daemon@optimus.ietf.org Wed Feb 27 05:40:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15867 for ; Wed, 27 Feb 2002 05:40:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA09665 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 05:40:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08383; Wed, 27 Feb 2002 05:17:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08356 for ; Wed, 27 Feb 2002 05:17:31 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15583 for ; Wed, 27 Feb 2002 05:17:26 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1RAHX6Y018448; Wed, 27 Feb 2002 05:17:34 -0500 (EST) Message-ID: <3C7CB1FC.7C1D7283@dynamicsoft.com> Date: Wed, 27 Feb 2002 05:16:28 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox CC: sip@ietf.org Subject: Re: [Sip] Draft -08 comments, part 3: "major" issues References: <15484.7512.130861.813280@grandcentral.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > > > Section 8.1.1.7: > It'd be nice to have some explanation of what the magic cookie string > "z9hG4bK" in the Via branch means and where it came from. Is it purely > random? Yes. That is generally the meaning of a magic cookie. > > Section 8.3: > The text on redirect servers seems a bit troubling. > However, redirect servers MUST NOT redirect a request to a URI equal > to the one in the Request-URI; instead, provided that the URI does > not point to itself, the redirect server SHOULD proxy the request to > the destination URI. > > I have no problem with the MUST NOT, but the SHOULD troubles me -- it > means > that there's no such thing as an unconditionally compliant pure redirect > server, since every redirect server has to have some proxy > functionality. > I think it'd be better to leave handling of this scenario up to > implementor > discretion. (The whole concept of using a redirect server as an > outbound > proxy seems a bit bizarre.) OK. I think thats a good point. I'd rather keep this tidbit about redirecting outbound proxies, since I know someone will ask eventually. I will change the SHOULD to MAY. The alternative is to reject with a 404. > > Section 14.2, line 2314, says: > A UAS that receives a second INVITE before it sends the final > response to a first INVITE with a lower CSeq sequence number on the > same dialog MUST return a 500 (Server Internal Error) response to the > second INVITE > > I understand the concept and motivation, but isn't there a better error > code > than a plain 500 for this? Especially since this is really a client > error. > I don't see why this can't use 491 (Request Pending), just like the > glare > situation in the next paragraph does. 5xx means that the same request as is, may succeed later, and that is true here. Anyway, this should never happen, since you are not supposed to send a new INVITE until you got an answer to the previous. So, we theoretically don't even need to describe this case. > > Also in 14.2, at line 2344: > If, however, it [the session description in an re-INVITE] is > unacceptable to the UAC, the UAC SHOULD generate an answer with a > valid session description, and then send a BYE to terminate the > session. > > This is the only case where a re-INVITE failure can lead to a session > being > torn down, as far as I can see. Would it be a good idea, therefore, to > say > that UACs SHOULD NOT do late offer-answer for re-INVITEs, i.e. SHOULD > always > include the existing session description in the re-INVITE? No. There are valid cases where an offer needs to be in a 2xx to re-invite, for 3pcc. > > Section 16.7: > The discussion of proxy response handling doesn't discuss the "final > response received after a stateful proxy goes stateless" problem. This > can > happen if a downstream server is frozen, you time out, and then it comes > back to life. In this scenario, a proxy can end up sending a non-2xx > after > a 2xx, multiple non-2xx responses, or multiple 2xx responses to a > non-INVITE > request. Is this forbidden, and if not, how is it dealt with? (This is > mostly relevant for step 5.) It is forbidden. Its all dealt with in the UA. The existing transaction/dialog matching rules will result in only one final response for a non-invite being accepted (the others will look like retransmits). For INVITE, the first 2xx destroys the transaction. A subsequent non-2xx would be passed to the core; the spec does not discuss what to do in this case - it ought to ignore them. I added a sentence to that effect. Receiving a 2xx after a 4xx will result in it being ignored as a retransmit. > > On a similar note, does the spec require that you proxy responses > upstream > statelessly after you've torn down the response context, forbid it, or > leave > it optional? It's hard to tell... lines 2781-4 of bis-08 explicitly state that you MUST act as a stateless proxy for them. > > Section 16.7: > Step 6 of proxy response handling says > A proxy which receives a 503 (Service Unavailable) response > SHOULD NOT forward it upstream unless it can determine that > any subsequent requests it might proxy will also generate a > 503. In other words, forwarding a 503 means that the proxy > knows it cannot service any requests, not just the one for > the Request-URI in the request which generated the 503. > > What if you only proxied to a single branch, and you got back a 503? > You > SHOULD NOT return it, and instead should make up some new response out > of > the whole cloth? That doesn't make much sense. No, that is the right thing. I added a sentence saying it should do that. Yes, its a bit ugly, but it brings a world of value to 503. Without it, we have no overload handling capabilities, and that has been frequently requested. > > Section 16.11: > The discussion of stateless proxies says > o A stateless proxy MUST choose one and only one target from the > target set. This choice MUST only rely on fields in the > message and time-invariant properties of the server. > and > Since a stateless proxy must forward retransmitted requests > to the same destination and add identical branch parameters > to each of them, it can only use information from the > message itself and time-invariant configuration data for > those calculations. If the configuration state is not > time-invariant (for example, if a routing table is updated) > any requests that could be affected by the change may not > be forwarded statelessly during an interval equal to the > transaction timeout window before or after the change. The > method of processing the affected requests in that interval > is an implementation decision. A common solution is to > forward them transaction statefully. > > It seems from this text that it's not possible to design a stateless > proxy > server which bases its routing decisions on a REGISTER-based location > service, since you can't anticipate the arrival of a REGISTER request > and > start proxying statefully. Is this true? If so, should it be called > out > more clearly? If not, what am I missing? The point is that you can never be ALWAYS stateless. In this specific instance, to achieve causality, you would delay the instantiation of the registration update for 32s, go stateful, make the registration change, and then go stateless. That works just fine. I don't think there is a need to go into detail. There is sufficient room for innovation here; we merely need to call out the problem. > > Section 18.1.1: > The discussion of the transport connection probably ought > to mention something along the lines that the transport layer SHOULD NOT > close TCP connections prematurely, for backward compatibility with RFC > 2543-compliant devices which will interpret this as a CANCEL (client to > server) or whatever the other-direction close meant. This might be hard > to > specify, though. THis text exists. Line 3545 of bis-08 already says that its RECOMMENDED (same as SHOULD) to keep the connection open for at least a transaction-intervals worth of time after the last message. That meets the requirement. > > Section 18.3: > Should the section on transport framing have a note that multiple > messages > in a UDP packet has been deprecated, or is the mention of this in the > big > changes section enough? Yes, it is sufficient. We have tried to move all of the text there, rather than scattered. > > Section 19.1.4: > What was the motivation for making URI comparisons non-transitive, and > special casing certain uri-parameters? It seems like it just makes a > lot of > implementation things much harder. Wouldn't it be simpler just to say > that > uri parameters must match? This would mean that the URI comparison code > could be completely ignorant of the semantics of URI parameter names, > and > old and new parameters are treated equally. This is a general mechanism for backwards compatibility. I agree that transitivity would be nice in theory, but it seemed a riskier proposition. > > Section 20.26 (Priority): > You say that a message with no Priority field SHOULD be treated the same > as > "non-urgent". This conflicts with CPL, which treats a missing Priority > as > the same as "normal." These should probably be aligned. Fixed. The problem is that caller prefs actually says non-urgent; thats where I copied it from. I changed bis to normal, and also caller prefs. > > Section 20.42 (Via): > This section says > Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP". > "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the > protocol still indicates "SIP", and the transport protocol is TLS. > > What about TLS over SCTP? When we get there, it'll require a new value. We discussed using: SIPS/2.0/TCP instead, but deemed this too backwards incompatible. > And is this abuse of the "transport" tag > really a > good idea here, given that it was decided that it was a bad idea in > URIs? Compromises, as always. The grammar only allows SIP here, so it would break parsers potentially far away from this proxy. > > Section 20.42 (Via): > The discussion of the branch parameter probably ought to re-mention the > branch parameter's magic cookie. Good idea, since it is easy to miss otherwise, and its really important. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 05:51:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15963 for ; Wed, 27 Feb 2002 05:51:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA10080 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 05:51:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09025; Wed, 27 Feb 2002 05:30:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08978 for ; Wed, 27 Feb 2002 05:30:26 -0500 (EST) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15749 for ; Wed, 27 Feb 2002 05:30:20 -0500 (EST) Received: from host213-122-147-32.in-addr.btopenworld.com ([213.122.147.32] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 16g1LU-0001Jq-00; Wed, 27 Feb 2002 10:30:00 +0000 Message-ID: <00a401c1bf79$c6521260$0200000a@tkw> From: "Pete Cordell" To: "Peterson, Jon" , References: <70565611B164D511957A001083FCDD5601870103@VA02> Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body Date: Wed, 27 Feb 2002 10:29:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I keep thinking about SMTP, which has survived for years without any real security being applied, even though there have been quite a few masquerading viruses out there, and security solutions do exist. As a result I actually think there is more trust floating around than there at first appears. Mail works most of the time because, when I give my message to an outbound proxy, I'm implicitly saying that I trust you to do the right thing with this (or maybe the administrator does), otherwise I wouldn't send the message there. Likewise, the outbound proxy may decide to send the message to a firewall proxy because it trusts it to do the right thing. At the other end, (after leaping through cyberspace) the recipient has typically chosen to be referred to as xyz@wacky-service.com, and in so doing has also said I trust you (wacky-service.com) to do the right thing, otherwise they wouldn't use it. The same arrangement exists as the mail filters through the enterprise network. Much the same arrangement exists for SIP. Hence there is a lot more implicit declaration of trust than a pure worst case threat model might suggest. One reason why security might not have been successful in e-mail is that the viruses work by compromising the user's mail client. Chances are, if the mail client is compromised, then all the authentication and integrity mechanisms will be compromised also, and so not actually offer any benefit. Whether this also applies to SIP remains to be seen. Hence, to use Dean's analogy, there is a place for security, but maybe it should be considered a medicine for when things are going wrong, and generally you wouldn't want to use the medicine all the time as, as we've discussed, there are a number of side effects to it. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Peterson, Jon To: Sent: 26 February 2002 05:05 Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message body > > Forbidding proxies to modify message bodies does not improve security; it's > the other way around. The fact that we can secure messages bodies end-to-end > entails that proxies may not be entitled to modify bodies. > > Mostly, this just reinforces the fact that bodies are intended for > end-to-end use. Many of the misconceptions about this issue arise from a > belief that the operators of proxy servers are necessarily a privileged > participant in a SIP network. Actually, if you are a 'network operator', and > you want to inspect and modify bodies, you must have a trust relationship > with users - they must accept that you, the network operator, are the > appropriate recipient of SIP message bodies, and they must secure MIME > bodies with that expectation (any encrypted bodies must be explicitly > intended to be decrypted by the network operator). In that sense, the > network operator becomes the destination of the request, and thus more or > less a user - and this is why the discussion naturally transitions to > B2BUAs. I think this in no way diminishes the value of network-based service > that require access to SIP message bodies - it just shows that if you want > to offer these sorts of services, you require that users trust you in a way > that they aren't asked to trust proxy servers, which operate only on > headers. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Wed Feb 27 05:55:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16012 for ; Wed, 27 Feb 2002 05:55:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA10229 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 05:55:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08895; Wed, 27 Feb 2002 05:30:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08859 for ; Wed, 27 Feb 2002 05:30:09 -0500 (EST) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15743 for ; Wed, 27 Feb 2002 05:30:04 -0500 (EST) Received: from host213-122-147-32.in-addr.btopenworld.com ([213.122.147.32] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 16g1LQ-0001Jq-00; Wed, 27 Feb 2002 10:29:57 +0000 Message-ID: <00a201c1bf79$c449bf40$0200000a@tkw> From: "Pete Cordell" To: "Dean Willis" Cc: References: <004201c1bee1$d7350620$8b036e3f@DWILLISS1> Subject: Re: Why Proxies are Good and B2BUAs May Not Be (was Re: [Sip] bis-07.9: proxies are not allowed to modify message body) Date: Wed, 27 Feb 2002 08:46:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean, Seeing as you are the king of analogy, I'll try and put my concerns thusly:- You can legislate against drinking, but that doesn't mean that it won't happen. And by trying to bar (!) people from drinking, you may cause problems that are greater than the original problem (such as pushing it underground and having a bunch of hooligans running around creating all sorts of havoc). Sometimes it's better to accept the lesser evil in order to prevent the greater evil. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Dean Willis To: Cc: Gonzalo Camarillo ; Cullen Jennings ; Bob Penfield ; Sent: 26 February 2002 16:22 Subject: Re: Why Proxies are Good and B2BUAs May Not Be (was Re: [Sip] bis-07.9: proxies are not allowed to modify message body) > Juan-Carlos wote: > > This is the definition of a proxy server, taken from bis-08: > > > > Proxy, Proxy Server: An intermediary entity that acts as both a server and > > a client for the purpose of making requests on behalf of other clients. A > > proxy server primarily plays the role of routing, which means its job is > to > > ensure that a request is sent to another entity closer to the targeted > > user. Proxies are also useful for enforcing policy (for example, making > > sure a user is allowed to make a call). A proxy interprets, and, if > > necessary, rewrites specific parts of a request message before forwarding > > it. > > > > As you see, the first part is fully inline with your mail: "A proxy server > > primarily plays the role of routing, ..." > > However, can you explain me how you apply your mail to the second part : > > "Proxies are also useful for enforcing policy...", "A proxy interprets, > > and, if necessary, rewrites specific parts of a request message before > > forwarding it" > > The key bit there is the word "specific". The specification details which > parts may be rewritten by a conformant proxy. Mess with the wrong parts, and > bad things can happen. As we gain practical experience with working > implementations, we learn more about which parts are sensitive. The > specification has incorporated this advancing knowledge as the specification > itself has advanced. > > Now, sometimes, it may be necessary to mess with sensitive parts. This is > analogous to "surgery" in the medical profession. In general, one uses > surgery as a last resort to treat a specific condition, with the full > knowledge and expectation that there will be side effects, some of which MAY > be life-threatening. > > If a confomant proxi is like a passenger taxi, then a B2BUA is like an > ambulance. > > There is a big difference between riding in a taxi to a restaurant for > dinner, and riding in an ambulance to a hospital for a triple bypass. > > And I'm afraid that my rhetoric professor will need a triple bypass after > reading this discussion. > > -- > 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 daemon@optimus.ietf.org Wed Feb 27 05:56:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16044 for ; Wed, 27 Feb 2002 05:56:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA10314 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 05:56:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08952; Wed, 27 Feb 2002 05:30:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08874 for ; Wed, 27 Feb 2002 05:30:12 -0500 (EST) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15746 for ; Wed, 27 Feb 2002 05:30:06 -0500 (EST) Received: from host213-122-147-32.in-addr.btopenworld.com ([213.122.147.32] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 16g1LS-0001Jq-00; Wed, 27 Feb 2002 10:29:58 +0000 Message-ID: <00a301c1bf79$c5564d40$0200000a@tkw> From: "Pete Cordell" To: "Peterson, Jon" , References: <70565611B164D511957A001083FCDD5601870103@VA02> Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message body Date: Wed, 27 Feb 2002 09:30:57 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jon, From: Peterson, Jon > Forbidding proxies to modify message bodies does not improve security; it's > the other way around. The fact that we can secure messages bodies end-to-end > entails that proxies may not be entitled to modify bodies. > > Mostly, this just reinforces the fact that bodies are intended for > end-to-end use. I don't deny that it is anybodies right to encrypt message bodies, but I do feel that people should be aware that if they encrypt message bodies then they may not be able to do some things that they would be able to do if they didn't encrypt the body. For example, there is firewall opening pinholes case mentioned in the draft (BTW, although SIP aware firewalls are rare at the moment I don't think the text should imply they will always be rare. There are many, many firewalls out there, and hopefully some day SIP and firewalls will not be immiscible. If the draft encourages it to become the norm to encrypt what firewalls need to look at to operate successfully then there is little motive for firewall vendors to make their firewalls SIP aware.) This does not require changing of SDP or anything like that, but if you encrypt this, the firewall will not be able to help. I agree that this is a user decision, but people need to have all the arguments in order to make an informed decision. I also don't feel that it follows that just because message bodies can be secured end-to-end then that means message bodies should never be changed. Almost the opposite, securing the message body is a good way of saying don't mess with my body, whereas not securing it means you can do with my body what you feel you need to (Almost back to Dean land here !). To put that in some context, I feel that preventing somebody modifying your SDP by integrity checking actually achieves very little. All SDP says is 'If you send packets to this address I will receive them.' But if the media needs to go through a NAT that case won't be true. Even in the absence of NATs, there may be routing problems that prevent a UA receiving packets that it said it could receive on. I may even be able to do some nasty things with BGP (so I'm told). What you really need it to say is 'stuff you receive identified as such and such is me'. The bigger problem is that, even if the SDP meant something useful, I could just attack the system at the RTP level. I can just send malicious packets to the specified addresses and cause trouble that way. Thus in the case of bodies that are references to other resources (e.g. SDP), there is little point in integrity checking it. Instead you have to secure what is referenced (e.g. use SRTP). Naturally there are bodies that are the final thing and don't point to things (such as IM), and typically these are worth integrity checking. The good thing is that it the mechanisms to do this are already in the standard, but (in my world !) some guidance would be useful. i.e. if the body refers to some other resource(s) then there is little point in using auth_int, and it may even be unhelpful. If the body does not refer to other resources, then you may wish to use auth_int. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 06:22:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16471 for ; Wed, 27 Feb 2002 06:22:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA11952 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 06:22:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10175; Wed, 27 Feb 2002 05:54:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10144 for ; Wed, 27 Feb 2002 05:54:22 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16003 for ; Wed, 27 Feb 2002 05:54:17 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1RAsf6Y018471; Wed, 27 Feb 2002 05:54:42 -0500 (EST) Message-ID: <3C7CBAB0.7FB65D59@dynamicsoft.com> Date: Wed, 27 Feb 2002 05:53:36 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: sip@ietf.org Subject: Re: [Sip] bis-07.9: SDP in 1xx responses References: <001f01c1bafa$a763a400$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bob Penfield wrote: > > The rules in section 13.2.1 (lines 2113-2123) appear to disallow SDP in > unreliable provisional responses. I know there are a lot of > implementation > out there that send SDP in 1xx responses. Right. With bis, they need to be doing so reliably. Its not going to work well enough unless they do. > Should it say that SDP MAY be > present in 1xx when an offer is sent in the INVITE, but it SHOULD match > the > SDP that the UAS will/would send in a 2xx (is that your final answer :) > in > order to be backwardly compatible with existing UAs. Yes, this is a good point. It took me nearly an hour to come up with the proper text, which provides backwards compatibility in both directions, works with reliable provisionals also (which i cannot mention in bis), and yet makes sure everything is a basic series of O/A exchanges. Take a look at the new text in bis-09. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 07:16:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17419 for ; Wed, 27 Feb 2002 07:16:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA14851 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 07:16:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12943; Wed, 27 Feb 2002 06:34:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12847 for ; Wed, 27 Feb 2002 06:34:51 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16696 for ; Wed, 27 Feb 2002 06:34:48 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1RBYH404309 for ; Wed, 27 Feb 2002 06:34:17 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K40HS0B>; Wed, 27 Feb 2002 11:34:04 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00468F5C0@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Gonzalo Camarillo , "Chen, Xin (Xin)" Cc: sip , Allison Mankin , Dean Willis , Biran Rosen , Joerg Ott , wtm@research.att.com, Jonathan Rosemberg Subject: RE: [Sip] Manyfolks version 04 Date: Wed, 27 Feb 2002 11:34:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org First, if you want to use "e2e", "local" or "remote", please give a reference in reference section which gives clear definition on what is end to end QoS. What is the criteria for meeting the requirements of end to end QoS and what is the cirteria for local QoS. We can not talk about this without even knowing what "end to end QoS" really mean! Or alternatively, clear written in this draft what does this draft mean on "end to end QoS" and "local QoS". The offerer and answerer have to share the same view on those difinitions, otherwise, manyfolks will not work as what it is written now. See more commment inline please, Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 26 February 2002 20:14 To: Chen, Xin (Xin) Cc: sip; Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott; wtm@research.att.com; Jonathan Rosemberg Subject: Re: [Sip] Manyfolks version 04 Hello, "Chen, Xin (Xin)" wrote: > > Hi Gonzalo, > > You can only ask and wish there will be e2e QoS on both directions and you > can not make sure of this, becuase you always rely on the confirmation from > other party and you have to trust it! What is the problem trusting the other party? You also trust that the IP address that you receive in the offer is his real IP address, and that he is listing the codecs he really supports, etc... [XC]Yes, you always trust the IP address of the other end, becuase you know you can not restrict how the other end to choose the IP address. And here, in manyfolks, you still aways trust the confirmation from the other end on the QoS condition, but you mandate how the other end to meet the condition. >According to my understanding, SIP is > a protocol not used for QoS reservation and it is independent to any QoS > reservation protocol, basically I can configure my SIP terminal to accept > any offer having "a=des:qos mandatory e2e sendrecv" even if my terminal > doesn't not support any QoS reservation protocol and I can still claim that > it is a terminal supporting manyfolks, because you can not say that my > terminal is not manyfolks supported simply because I don't support an end to > end QoS reservation protocol. Well, I can build a SIP terminal that receives INVITEs, generates a 200 OK with a correcty formed session description, but that does not alert the user, and does not play the media received thru the speakers, and does not even turn on the mic... it would be a correct SIP implementation from the syntax point of view, but I would be violating the protocol, because the messages I am sending do not reflect what is really happening... This is what you are proposing to do... [XC]No, what I am proposing is: Don't use the status type at all. An offer just indicates the desire for QoS, and when another side receives the offer, it will do its best to meeting the QoS condition. If it can do RSVP, then it is fine, if it can not, then it will have other means to do that. If the end user thinks that the qoS is done, it sends you the confirmation. If it can not, it refuses the offer. It is just as simple as this, and this is also all SIP can do. Again, I have to say: SIP MUST NOT be able to tell you whether there is an end to end QoS or not. If it can, SIP is a QoS reservation protocl. All SIP can do in this case is to tell the other end what I wish to have, but regarding how are you going to do (RSVP, Diffserv or whatever) to meet the requirements, SIP doesn't care. > If you can, then this draft does tide SIP up > with QoS protocol. Well, that's exactly the idea behind the draft. Until QoS is not provided, the user is not alerted... [XC]I agree with this. But who is going to judge whether the QoS is provide or not? Let the terminal to juge this, not SIP! > Simple question: What is the "end to end", where is the definition of end to > end QoS? > > In 3GPP network, local QoS (caller) + Differv in the core + local QoS > (callee) = end to end OK, you are the caller. How can you know that there is QoS beyond your DiffServ router?? [XC]Yes, I know. It is written in the contract between me and my ISP. You can only know that if you use the segmented type (the callee will tell you when he has QoS on his access network). You use the end to end type when you can be sure that there is QoS end to end (e.g, RSVP). [XC] This is not correct. RSVP can also be used for local network QoS setup. I can have the RSVP messages terminated on my eggress router of the local network and the eggress router has a link to the Differv domain for the rest of the network. Therefore, even a terminal is using RSVP, it is still not sure it is doing the end to end or not according to your understanding that RSVP = end to end! Thanks Gonzalo > > In manyfolks, RSVP = end to end > > Which one is right? I think both are correct depending on the practical > situation. The only difference is that in 3GPP network, Differv is > pre-agreed based service level agreement, therefore, the user is not aware > of that. And for RSVP, the user is aware of that. This is the only > difference. But the 3GPP terminal's call will suffer the failing simple > becuase of this difference if we use those parameters like "e2e" in SDP. > > I hope you will not think that I am being aggressive because I really see > some hint in this draft to give the definition on what the end to end is and > what the local and remote is regarding on QoS reservation and we should not > do this. I don't want to hear one day a SIP developper says:"Becuase SIP > says this, therefore, we have to use the QoS reservation protocol."! > Bascially, SIP should not give any restriction on the terminal's > understanding on what end to end QoS. > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 26 February 2002 10:20 > To: Chen, Xin (Xin) > Cc: sip; Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott; > wtm@research.att.com; Jonathan Rosemberg > Subject: Re: [Sip] Manyfolks version 04 > > Hello, > > > > And "a=des:qos mandatory remote sendrecv" generated by the offerer has > the > > > same meaning as "a=des:qos mandatory e2e sendrecv" from the anserer's > > point > > > of view. > > > > No, they don't. If I am a 3GPP terminal, establishing the appropriate > > PDP context will meet the first precondition, but not the second. > > [XC] Then the call may fail, we don't want that happen! > > If the preconditions cannot be met, that's exactly what we want: the > call does not have to be established. > > Reading your second mail, what you want is the segmented type: that is, > you are telling the other end to do whatever he can on his side, and you > will do whatever you can on yours... as you said, in the middle you > might have DiffServ, for instance. > > But if you use the e2e type, you want to make sure that there are > resources end to end. Even if you know that you are in a Gigabit > ethernet and that your local router uses DiffServ, you still don't know > whether or not you have e2e QoS... that's why you need both types. > > That fact that all you want is the segmented type, does not mean that > other people cannot find the e2e type useful. > > Regards, > > Gonzalo > > We wish the call > > always successful! This is exactly my worry about the e2e parameter. In > > 3GPP, the terminal will not do RSVP and it uses PDP which is a local QoS > > machanism. We have Differv in the middle to provide the end to end QoS. We > > don't want a call to fail if an incoming offer requiring "e2e" to a 3GPP > > terminal or a 3GPP terminal initiates an offer with "local" parameter not > > "e2e". > > > > The e2e type is intended for e2e reservation protocols (this is stated > > in the draft, by the way). > > > > > > I think only "e2e" is needed. Because as a user, I don't care what local > > > access network another end is using, actually I even don't know what > > > protocol the other end is using for QoS, what I want is end to end QoS > for > > > my the video or audio streams. > > > > OK, so you will always use e2e qos. But other folks find it useful to > > have the segmented type... although this does not mean that you have to > > use it. > > [XC] No, my point of view is not to use any of them:e2e, local or remote. > > Thanks > > > > Thanks for your comments, > > > > Gonzalo > > > > >Therefore, it is up to the user agent to > > > intercept and decide whether e2e condition is met or not. > > > > > > For example, if the answerer receives an offer requiring e2e QoS > sendrecv, > > > but the answerer only supports local network QoS protocol and uses > Differv > > > in the core network to provide end to end QoS, therefore this call > should > > > not fail just because the answerer doesn't support RSVP. So answerer > just > > > needs to finish the local network QoS reservation and ACKs the offerer > > that > > > e2e is met. In a word, for the answerer's point of view, "e2e"="remote". > > > > > > If an offerer doesn't support e2e QoS protocol, it can still put "e2e" > in > > > its offer, because from the offerer's point of view, "e2e"="local". > > > > > > Thanks > > > > > > Xin Chen > > > > > > Lucent Technologies > > > Tel: +44 1793 883137 > > > Mobile: +44 7799 034668 > > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: 26 February 2002 3:03 > > > To: sip > > > Cc: Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott; > > > wtm@research.att.com; Jonathan Rosemberg > > > Subject: [Sip] Manyfolks version 04 > > > > > > Hello, > > > > > > I have just submitted a new version of the manyfolks draft. Until it > > > appears in the archives, you can fetch it from: > > > > > > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.pdf > > > > > > > > > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.txt > > > > > > About the authorship of this draft, the ADs and the WG chairs decided > > > that all the coauthors of previous versions but Bill had to be moved to > > > a Contributors Section. > > > > > > The deadline for this draft is very close, so I would appreciate that > > > folks read the draft and send comments as soon as possible. > > > > > > I have removed security preconditions (per mailing list discussion), but > > > added a token that can be used to define new precondition types (the > > > only type currently defined is "qos"). > > > > > > The draft uses two attributes: desired-status and current-status. When > > > the current status reaches (or goes beyond) the desired status the > > > preconditions are met. Instead of defining an absolute ordering for > > > these two attributes, I have defined status tables. They are > > > abstractions of the preconditions carried in the SDP. These tables help > > > explain how status synchronization between both user agents is performed > > > and when exactly all the preconditions are met. > > > > > > Feedback is appreciated, > > > > > > Best regards, > > > > > > Gonzalo > > > -- > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > Columbia University Mobile: +358 40 702 35 35 > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > New York, NY 10027 > > > USA Gonzalo.Camarillo@ericsson.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 > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.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 -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Wed Feb 27 07:37:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19291 for ; Wed, 27 Feb 2002 07:37:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16707 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 07:37:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14532; Wed, 27 Feb 2002 07:08:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14508 for ; Wed, 27 Feb 2002 07:08:30 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17295 for ; Wed, 27 Feb 2002 07:08:26 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RC8ri01986 for ; Wed, 27 Feb 2002 14:08:53 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 14:08:20 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 14:08:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] T4 Date: Wed, 27 Feb 2002 14:08:19 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7779085@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] T4 Thread-Index: AcG/guO8V3mTZ2qoQqix4WDENj8U0AAA5QYg To: Cc: X-OriginalArrivalTime: 27 Feb 2002 12:08:20.0434 (UTC) FILETIME=[726D4B20:01C1BF87] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA14509 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit All this is fine, but T4 as you define it (Max RRT between request and response) is too short in my opinion. Perhaps it should be set to a higher value. The other alternative is for the spec to say that timer K must be reset after every retransmission. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, February 27, 2002 10:15 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: sip@ietf.org > Subject: Re: [Sip] T4 > > > > > hisham.khartabil@nokia.com wrote: > > > > I included this in my comments in bis-07, but never got an answer. > > > > Why is T4 limited to 5 seconds for timer K in the case of non-INVITE > > (section 17.1.2.2)? > > Sorry, I thought I had answered this somewhere. > > The idea is that you've sent a bunch of BYE requests, for example, and > now you've got the final response. You want to hang around to > catch any > retransmits of that final response. How long to wait? The interesting > thing about responses to BYE, is that they are not perioidcally sent; > they are sent only in response to a request. So, the delay between > sending a request, and getting a response, is equal to some value (say > T4'), which represents the amount of time it takes for the request to > get to the server, for the server to resend the response, and for the > response to arrive at the client. Let T4 be the maximum value > of T4' you > might ever see, which I have set at around 5s. This should be > more than > sufficient. So, this means that if you've sent a retransmit of the > request at time t, you would have received the response by t+T4 with > very high probability, or you won't get one at all. So, if a UAC sends > requests at times t1,t2,t3,t4, the responses would have arrived at > t1+T4, t2+T4, t3+T4, t4+T4. The largest of those is t4+T4. > Thus, we need > to wait at least T4 seconds after the last request. Instead, > we wait T4 > after the first response, which is always more time (its simpler that > way). > > Hope that helps. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 07:39:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19416 for ; Wed, 27 Feb 2002 07:39:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16920 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 07:39:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14584; Wed, 27 Feb 2002 07:08:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14548 for ; Wed, 27 Feb 2002 07:08:46 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17298 for ; Wed, 27 Feb 2002 07:08:42 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1RC8DE01492; Wed, 27 Feb 2002 04:08:13 -0800 (PST) Received: from oranlt (rtp-vpn1-89.cisco.com [10.82.224.89]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACD05270; Wed, 27 Feb 2002 04:08:22 -0800 (PST) From: "David R. Oran" To: "'Jonathan Rosenberg'" Cc: Subject: RE: [Sip] multicast restricted to ttl=1 Date: Wed, 27 Feb 2002 07:08:17 -0500 Organization: Cisco Systems Message-ID: <016301c1bf87$71750870$fa49010a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C7C9B69.5910934@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Jonathan Rosenberg > Sent: Wednesday, February 27, 2002 3:40 AM > To: David R. Oran > Cc: sip@ietf.org > Subject: Re: [Sip] multicast restricted to ttl=1 > > > > > "David R. Oran" wrote: > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > > > Jonathan Rosenberg > > > Sent: Sunday, February 17, 2002 2:09 PM > > > To: sip@ietf.org > > > Subject: [Sip] multicast restricted to ttl=1 > > > > > > > > > Folks, > > > > > > As a result of IESG review, there were concerns about the > multicast > > > usage of SIP. In particular, for the things we were using > it for, it > > > was felt that a limitation of scope to ttl=1 was needed. > As such, I > > > have modified the transport chapter to reflect a SHOULD > level usage > > > of ttl=1. > > > > > Well, according to bis-08, multicast can be used to find a > registrar > > if you don't have a DNS-discoverable proxy to route your > register to. > > If that's the purpose, what leads one to believe that the > registrar is > > likely to be on your local subnet? > > Well, more like, if its not on your subnet, multicast > register is going to have some problems. > The only thing that matters is the total receiver population. 4000 phones (or proxies or registrars) on one subnet is worse than 200 phones on five subnets. What am I missing? > > > > Seems if multicast for regisration is useful at all, it makes more > > sense for the discovery to either be via expanding ring broadcast > > and/or an admin-scoped group. > > Without proper response suppression, reliability, and other > multicast specific capabilities, we cannot do this properly. > If there is sufficient interest, an extension can be defined > to do this. > It isn't clear you can do this "properly" even with these mechanisms. The fact is, in a properly configured system there will be only one or a few respondents, and in a misconfigured system even implosion control will likely be ineffective. > > > > BTW: bis-08 does not prohibit multicasting INVITES, which > is equally > > useful (which could be to say not very...) as multicasting > > registrations, for completely infrastructure-less small > > configurations. The same question about single-hop applies. > > Same answer. > > > > > What am I missing? If I'm not missing anything and the SHOULD is an > > attempt balance utility against danger, I'm not sure the balance is > > right, since violating a SHOULD makes you only conditionally > > compliant, whereas I can think of quite a few > configurations which are > > small enough to want to use this (e.g. for minimal > functioality when > > your proxy/registrar is pooched) yet span more than one subnet. > > It is an attempt to balance utility against danger. > Unfortunately, SIPs processing at the higher layers is > strongly based on a single non-2xx response per request, an > assumed invariant that is false as a result of multicast. As > such, we are not going to properly process the other > responses, leaving transactions hanging, and so on. We also > have no response suppression mechanisms. As such, use of > multicast except in the most limited confines and use cases > is both dangerous and moderately broken. However, enough > people whined when I proposed to remove it entirely, that it > remains in this more limited form. > OK, then leaving it in is silly. Take it out. The ttl=1 piece is a red herring. Dave. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.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 daemon@optimus.ietf.org Wed Feb 27 07:59:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20067 for ; Wed, 27 Feb 2002 07:59:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA17932 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 08:00:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15846; Wed, 27 Feb 2002 07:30:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15797 for ; Wed, 27 Feb 2002 07:30:16 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18976 for ; Wed, 27 Feb 2002 07:30:11 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16g3DZ-0003wX-00; Wed, 27 Feb 2002 14:29:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15484.53572.983374.309557@harjus.eng.song.fi> Date: Wed, 27 Feb 2002 14:29:56 +0200 To: William Marshall Cc: xchen2@lucent.com, Gonzalo.Camarillo@lmf.ericsson.se, sip@ietf.org, mankin@isi.edu, dwillis@dynamicsoft.com, Brian.Rosen@marconi.com, jo@tzi.uni-bremen.de, jdrosen@dynamicsoft.com Subject: RE: [Sip] Manyfolks version 04 In-Reply-To: <200202271221.HAA25364@fish.research.att.com> References: <200202271221.HAA25364@fish.research.att.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall writes: > Which is more DoA - rsvp or bandwidth brokers? both are equally DoA. when you choose your service provider, make sure they peer with right guys and prioritize your media packets over bottleneck links (if any). -- 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 daemon@optimus.ietf.org Wed Feb 27 10:33:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27571 for ; Wed, 27 Feb 2002 10:33:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26529 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 10:33:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25404; Wed, 27 Feb 2002 10:13:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25373 for ; Wed, 27 Feb 2002 10:13:48 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26501 for ; Wed, 27 Feb 2002 10:13:45 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1RFDZx18176; Wed, 27 Feb 2002 10:13:35 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAF85915; Wed, 27 Feb 2002 10:16:27 -0500 (EST) Message-ID: <3C7CF5FD.3A60A92E@cisco.com> Date: Wed, 27 Feb 2002 10:06:37 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org References: <3C759F50.6685D5B0@cisco.com> <3C7CA270.3DC194F9@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] bis-08 is born Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan - see below. Paul Jonathan Rosenberg wrote: > > > In lines 1709-1710 (section 10.3 item 6) is a rule that a REGISTER > > containing Contact:* must not contain any other contact lines. Why has > > this restriction been added? I don't see any great benefit to imposing > > this restriction, and it could be inconvenient. > > I had always assumed that if there was a *, it was only *; the change > was to merely clarify what I (at least) thought was always the case. > > > > > If there might be a prior registration, and the intent is for a new > > registration to supercede that, life becomes difficult. Either this > > requires two REGISTERs, one with Contact:* and then another with the > > desired new values, or else the exact set of prior contact headers must > > be known, and the new REGISTER must repeat all the old contact > > addresses, with expires=0. > > Right. From a particular UA, that will generally be both feasible and > the right thing to do. It only ceases to work when you want to cancel a > contact from another UA, different from the one which created the > contact. This is not likely to be a common case. A UA would not normally > delete ALL registrations unless the user explicitly instructed it to. > Otherwise, you would never be able to have multiple devices associated > with a single AOR. For example, if I log in at work, and then go home, > my home PC is not going to normally unregister every other contact. It > will merely register and manage its own. Its only if I say "oops! forgot > to log out of work, let me delete that registration" that I might select > a specific option to delete all registrations. That deletion is quite > separate from the registration on that phone itself. So, I have no > problem with sending two REGISTER in this case. > > > > > Why not simply state that if a Contact:* is present it must be processed > > before the other Contact entries? > > Another reason - the text says you can only use Contact:* when Expires:0 > is there, which further validates my claim that this has always meant to > be used alone. To deal with the last first - this language always seemed odd/unreasonable to me. What seems important is that the Contact:* must not have a non-zero effective expiration time, because the behavior before it expired would be undefined. The Expires: header in general provides a default value for the expires= parameter in the Contact header, and can be overridden. That language about Contact:* fails to exclude the semantically invalid case of: REGISTER ... ... Expires: 0 Contact:*;expires=3600 And yet it does exclude the semantically valid case: REGISTER ... ... Expires: 3600 Contact:*;expires=0 Even so, what I was suggesting was legal syntax before: REGISTER ... ... Expires: 0 Contact: * Contact: ;expires=3600 Regarding the other comments above: I agree that a UA requesting to remove all prior registrations must know what it is doing. But when it does know this, like when it wants to be the exclusive target, then combining a global deletion with a new registration would be useful. If it is important to prevent unknowing deletions, then the Contact:* construction should be removed entirely. (A UA intent on doing so at any cost could always request the old contacts and then construct a new registration that sent expired forms of each back.) But I think the Contact:* form is indeed appropriate, and shouldn't have special restrictions on its applicability. > > > > > - > > > > I also have another register related issue that should have been raised > > sooner. It is presumably too late to deal with now, but I raise it in > > hopes that there will be an opportunity to consider it at some future > > time: > > > > In lines 1733-1739 (section 10.3 item 7) the rules are specified for > > matching and replacement of individual bindings. As worded, I believe > > this would result in aborting any REGISTER that contains multiple > > Contact entries with the same address. Back in bis-05 and before the > > handling of this case was ambiguous. It is still slightly ambiguous > > because it isn't entirely clear if items that have been tentatively > > added are to be searched. > > Yes, it is ambigous. I had not considered this case. > > > > > Of course it is silly to have two Contact entries with the same address > > if there is nothing else to be different about them. But the built in > > extension mechanisms permit the construction of different contact > > headers with the same address but different parameters, and the > > callerprefs draft does so. With that draft is is indeed useful to be > > able to do so. > > I don't think it would help if the tentative ones are included, since > subsequent ones would overwrite. If you exclude tentative ones, then you > need to define what it means to tentatively add the same binding twice. It isn't the same binding if it has different params. It would be stupid to put one in twice that had identical params, but even then the treatment seems clear - just go ahead and add it. The rules for handling contacts later should deal with it just fine. > Also, the result would be that putting two identical contacts, but with > different contact params, in the same register, would be different than > if you put the same two in different registers. That seems wrong. The reason I responded about that now is that your new language about processing Contacts in REGISTER gives a well defined way to deal with this. It isn't so terribly wrong - a given contact *address* must be defined in a single REGISTER message, whether it takes one Contact header or several to describe it. > > Also, how would replacement work? That is, if I register two contacts > that are identical URI: > > COntact: sip:A;param1=val1 > Contact: sip:A;param2=val2 > > What would it mean to later receive a REGISTER like: > > Contact: sip:A;param3=val3 > > does this replace one of the two previous, or both? Both. The wording changes I suggested clarify this. > I think that it is > easier to have the contacts be different through differing URI > parameters or user parts. That gives you the flexibility to effectively > register multiple "equivalent" URI to the same binding, but requires no > changes to the spec. Furthermore, it allows the UA to know which of its > contacts was chosen, which is probably useful. Consider the following: 1) REGISTER ... ... Contact: sip:A;class=business Contact: sip:A;class=personal;priority=urgent I might set my work phone to register this way during meetings. When not in a meeting, I might want it to simply register as: 2) REGISTER ... ... Contact: sip:A But if I must make the contact addresses unique, then the best I can do is probably: 1a) REGISTER ... ... Contact: ;class=business Contact: ;class=personal;priority=urgent 2a) REGISTER ... ... Contact: Contact: ;expires=0 and I must remember how many "slots" I used last time. The Contact:* discussion has some relevance here as well. If Contact:* can be combined with other contacts, then the above could be done as: 1b) REGISTER ... ... Contact: *;expires=0 Contact: ;class=business Contact: ;class=personal;priority=urgent 2b) REGISTER ... ... Contact: *;expires=0 Contact: sip:A (Of course I could only do this if I knew there were no other UAs registering my address of record.) > > > > > A minor change to the wording in this section would permit multiple > > contact entries with the same address to be delivered in a single > > REGISTER: > > > > "For each address, the registrar then searches the list of current > > bindings using the URI comparison rules, excluding those tentatively > > added while processing this request. If no matching binding exists, one > > is tentatively added. If one or more matching bindings do exist, the > > registrar checks the Call-ID value of each. If the Call-ID value in a > > matching binding differs from the Call-ID value in the request, the > > binding MUST be removed if the expiration time is zero and updated > > otherwise. If they are the same, the registrar compares the CSeq value. > > If the value is higher than that of the existing binding, it MUST update > > or remove the binding as above. If not, the update MUST be aborted and > > the request fails." > > That text would not be sufficient; see above. A lot more would need to > be specified. Since there is an alternative that requires no changes but > allows you to meet your requirements, I would prefer that route. I don't think much (if anything) more needs specification, though more text might help clarify subtleties. 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 daemon@optimus.ietf.org Wed Feb 27 10:50:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28572 for ; Wed, 27 Feb 2002 10:50:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27115 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 10:50:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25958; Wed, 27 Feb 2002 10:27:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25921 for ; Wed, 27 Feb 2002 10:27:56 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27274 for ; Wed, 27 Feb 2002 10:27:50 -0500 (EST) Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1RFRlB28263; Wed, 27 Feb 2002 16:27:47 +0100 (MET) Received: from novack.danubius by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA24964; Wed, 27 Feb 2002 16:27:45 +0100 (MET) Received: from localhost (ethgfs@localhost) by novack.danubius (8.8.8+Sun/8.8.8) with ESMTP id QAA10040; Wed, 27 Feb 2002 16:27:45 +0100 (MET) X-Authentication-Warning: novack.danubius: ethgfs owned process doing -bs Date: Wed, 27 Feb 2002 16:27:44 +0100 (MET) From: Gabor Fenyes To: cc: , Subject: Re: [Sip] SIP version related statement in bis-08 In-Reply-To: <65256B6D.0053A237.00@sampark.hss.hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, > I see following statement in bis-08 pdf version page number 21. > > "The SIP-Version string is case- insensitive, but implementations MUST send > upper-case." > > Why is the statement so? > > either we must say : > "The SIP-Version string is case- insensitive, but implementations SHOULD > send upper-case." > > ======== > or > "The SIP-Version string is case- sensitive, but implementations MUST send > upper-case." > ========= > > The statement in the current form doesnt make sence. > please correct. It makes perfect sense for backwards compatibility. You must be prepared to receive it case insensitively, but if you conform to the new standard you MUST send all upper-case. Regards, Gabor ----- Gabor Fenyes gabor.fenyes@eth.ericsson.se Support Engineer Phone: +36-1-437-7834 Conformance Center (ETH/RLS) Fax: +36-1-437-7767 Ericsson Hungary Ltd. PO Box 107, 1300 Budapest, Hungary ----- "Nothing so fortifies a friendship as a belief on the part of one friend that he is superior to the other." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 10:59:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28934 for ; Wed, 27 Feb 2002 10:59:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27528 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 10:59:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25727; Wed, 27 Feb 2002 10:23:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25696 for ; Wed, 27 Feb 2002 10:23:23 -0500 (EST) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27057 for ; Wed, 27 Feb 2002 10:23:17 -0500 (EST) From: sshetti@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hss.hns.com (8.11.2/8.11.2) with SMTP id g1RF3sl29123 for ; Wed, 27 Feb 2002 20:33:54 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B6D.0053A329 ; Wed, 27 Feb 2002 20:43:32 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org cc: ramakrishna@hss.hns.com Message-ID: <65256B6D.0053A237.00@sampark.hss.hns.com> Date: Wed, 27 Feb 2002 20:43:29 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] SIP version related statement in bis-08 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi all, I see following statement in bis-08 pdf version page number 21. "The SIP-Version string is case- insensitive, but implementations MUST send upper-case." Why is the statement so? either we must say : "The SIP-Version string is case- insensitive, but implementations SHOULD send upper-case." ======== or "The SIP-Version string is case- sensitive, but implementations MUST send upper-case." ========= The statement in the current form doesnt make sence. please correct. regards, Shetti _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 11:01:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29131 for ; Wed, 27 Feb 2002 11:01:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28168 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 11:01:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26754; Wed, 27 Feb 2002 10:40:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26721 for ; Wed, 27 Feb 2002 10:40:32 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27966 for ; Wed, 27 Feb 2002 10:40:29 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA29160; Wed, 27 Feb 2002 10:40:12 -0500 (EST) Received: from bart.cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1RFeBiD007924; Wed, 27 Feb 2002 10:40:11 -0500 (EST) Received: (from lennox@localhost) by bart.cs.columbia.edu (8.12.1/8.12.1/Submit) id g1RFeB4R007921; Wed, 27 Feb 2002 10:40:11 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15484.64986.605083.538859@bart.cs.columbia.edu> Date: Wed, 27 Feb 2002 10:40:10 -0500 To: Paul Kyzivat Cc: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Re: [Sip-implementors] bis-08 is born In-Reply-To: <3C7CF5FD.3A60A92E@cisco.com> References: <3C759F50.6685D5B0@cisco.com> <3C7CA270.3DC194F9@dynamicsoft.com> <3C7CF5FD.3A60A92E@cisco.com> X-Mailer: VM 6.98 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Wednesday, February 27 2002, "Paul Kyzivat" wrote to "Jonathan Rosenberg, sip@ietf.org" saying: > That language about Contact:* fails to exclude the semantically invalid > case of: > > REGISTER ... > ... > Expires: 0 > Contact:*;expires=3600 This is forbidden by the Contact BNF. If you read it closely, you'll see that "Contact: *" can't have any parameters at all. I don't know if this is necessarily a good idea, but it's what the spec says, and it resolves the issue. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 11:17:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29918 for ; Wed, 27 Feb 2002 11:17:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29289 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 11:17:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27439; Wed, 27 Feb 2002 10:57:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27408 for ; Wed, 27 Feb 2002 10:57:50 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28835 for ; Wed, 27 Feb 2002 10:57:47 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA04226; Wed, 27 Feb 2002 10:57:49 -0500 (EST) Received: from bart.cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1RFvniD008002; Wed, 27 Feb 2002 10:57:49 -0500 (EST) Received: (from lennox@localhost) by bart.cs.columbia.edu (8.12.1/8.12.1/Submit) id g1RFvmSU007999; Wed, 27 Feb 2002 10:57:48 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15485.507.891867.980497@bart.cs.columbia.edu> Date: Wed, 27 Feb 2002 10:57:47 -0500 To: Jonathan Rosenberg Cc: sip@ietf.org Subject: Re: [Sip] Draft -08 comments, part 3: "major" issues In-Reply-To: <3C7CB1FC.7C1D7283@dynamicsoft.com> References: <15484.7512.130861.813280@grandcentral.cs.columbia.edu> <3C7CB1FC.7C1D7283@dynamicsoft.com> X-Mailer: VM 6.98 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Wednesday, February 27 2002, "Jonathan Rosenberg" wrote to "Jonathan Lennox, sip@ietf.org" saying: > Jonathan Lennox wrote: > > > > > > Section 8.1.1.7: > > It'd be nice to have some explanation of what the magic cookie string > > "z9hG4bK" in the Via branch means and where it came from. Is it purely > > random? > > Yes. That is generally the meaning of a magic cookie. Okay. I thought it might have been somebody's birthday, base64-encoded, or something cute like that. :-) > > Section 14.2, line 2314, says: > > A UAS that receives a second INVITE before it sends the final > > response to a first INVITE with a lower CSeq sequence number on the > > same dialog MUST return a 500 (Server Internal Error) response to the > > second INVITE > > > > I understand the concept and motivation, but isn't there a better error > > code than a plain 500 for this? Especially since this is really a > > client error. I don't see why this can't use 491 (Request Pending), > > just like the glare situation in the next paragraph does. > > 5xx means that the same request as is, may succeed later, and that is > true here. Anyway, this should never happen, since you are not supposed > to send a new INVITE until you got an answer to the previous. So, we > theoretically don't even need to describe this case. Okay. So if I want to send 4xx instead (on the grounds that this is the other guy's fault, not my fault, and so a client error), it's okay? > > Section 16.7: > > The discussion of proxy response handling doesn't discuss the "final > > response received after a stateful proxy goes stateless" problem. This > > can happen if a downstream server is frozen, you time out, and then it > > comes back to life. In this scenario, a proxy can end up sending a > > non-2xx after a 2xx, multiple non-2xx responses, or multiple 2xx > > responses to a non-INVITE request. Is this forbidden, and if not, how > > is it dealt with? (This is mostly relevant for step 5.) > > It is forbidden. Its all dealt with in the UA. The existing > transaction/dialog matching rules will result in only one final response > for a non-invite being accepted (the others will look like retransmits). > For INVITE, the first 2xx destroys the transaction. A subsequent non-2xx > would be passed to the core; the spec does not discuss what to do in > this case - it ought to ignore them. I added a sentence to that effect. > Receiving a 2xx after a 4xx will result in it being ignored as a > retransmit. It seems like ignoring a 2xx after a 4xx is a good way to get blasted with an RTP stream you don't have any way of shutting up. But I suppose this is an exceptional case, and so undefined by the spec, so an entity can do what it likes. > > Section 19.1.4: > > What was the motivation for making URI comparisons non-transitive, and > > special casing certain uri-parameters? It seems like it just makes a > > lot of implementation things much harder. Wouldn't it be simpler just > > to say that uri parameters must match? This would mean that the URI > > comparison code could be completely ignorant of the semantics of URI > > parameter names, and old and new parameters are treated equally. > > This is a general mechanism for backwards compatibility. I agree that > transitivity would be nice in theory, but it seemed a riskier > proposition. I realized last night the real problem with this. It means you can't canonicalize a SIP URI. Here's an example. In our server, we use a SQL database as the back end to our registration service. Since SQL doesn't understand SIP URIs, only strings, we convert all URIs into a canonical string form before inserting them into the database. In the previous spec this meant case-smashing all CI elements, deleting default parameters, and lexicographically sorting all the parameters and headers. Then, to accomplish registration updates, we just use the address-of-record and the contact URI as database keys, and the database does everything correctly. With bis-08's URI comparison rules, there's *no way* to do this. (Trivial proof: string equality is an equivalence relation.) We'd have to somehow put knowledge of these URI comparison rules into the database access code. I *guess* this means putting both a all-nonstandard-parameters-stripped form and a nonstandard-parameters-present form in the database, querying for both, updating both, deleting as necessary...it's going to be a rat's nest, and probably a lot less efficient. I imagine a whole lot of implementations are using string or hash comparisons of canonicalized URIs, in some form or another, for their location services... -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 11:20:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00126 for ; Wed, 27 Feb 2002 11:20:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29462 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 11:20:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28160; Wed, 27 Feb 2002 11:01:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28028 for ; Wed, 27 Feb 2002 11:01:18 -0500 (EST) Received: from zctfs063.nortelnetworks.com (h90s131a237n47.user.nortelnetworks.com [47.237.131.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29118 for ; Wed, 27 Feb 2002 11:01:14 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1RFxo728431; Wed, 27 Feb 2002 16:59:50 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 15:59:53 -0000 Message-ID: From: "Mark Watson" To: jh@lohi.eng.song.fi, Andrew Allen Cc: "'Dean Willis'" , Christian Huitema , sip@ietf.org Subject: RE: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenari o outside of 3GPP requirements) Date: Wed, 27 Feb 2002 15:59:44 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BFA7.C62483D0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BFA7.C62483D0 Content-Type: text/plain Juha, There is nothing to stop you getting an Internet Access subscription on your 3G GPRS phone and registering with any SIP Service Provider of your choice. You will pay for the wireless QoS you request on a per kb basis - the mobile operator will have no idea what you are using these bits for. Now exactly how you get the QoS you need for real-time services from the edge of the Wireless Access network to your destination is another question. If on the other hand you subscribe to a 3G IP Multimedia Subsystem service, then the establishment of the access QoS that you need is part of the IMS service you are invoking, not just a request for a bit-pipe. Operators will have the flexibility to charge based on the *service* you are invoking, not just on the bit-pipe provision. My guess is that it may be cheaper to make a voice call via the IMS than it is to set up a bit-pipe to the Internet with real-time QoS suitable for voice. [I don't just mean cheaper *per minute*, though this may be the case. You also have to take into account cost of handset etc. I imagine operators will subsidise handsets which are locked in to their own services, as they do for GSM today] There are also various radio optimisations that the access operator can provide if it knows what the bit-pipe is being used for. As noted by Andrew, the IMS separates out the operator providing the wireless access to the IMS (Visited operator) from that providing the services (Home operator), with whom you register. There is no requirement that the Home Operator have a wireless infrastructure. (Although there are some technicalities regarding the separation of the GPRS subscription and IMS subscription on the SIM card(s).) There are many restrictions and considerations which are special to cellular wireless access. Bandwidth is a very scarce resource in this context and needs to be carefully managed. 3GPP takes the view that in order to provide high quality real-time services over cellular wireless access needs interaction with the network providing that access, and that it is not sufficient for this interation to be entirely controlled by the user. The 3GPP IMS is a platform for providing that interaction between Home and Visited network, or Service Provider and Access Provider, using SIP. So, noone is preventing you from doing whatever you want with your GPRS Internet Access. Nor are they preventing competing operators from setting up 'Virtual' mobile service providers - in fact these virtual operators are a good source of revenue for some networks, rather than direct competitors. It is not surprising that SIP in this application needs some extensions that are not necessarily required in the Internet - although Dean has given some good examples where Internet-based scenarios approach the same architecture as the 3GPP IMS. If you prefer that the IETF have no say in how 3GPP use SIP for this application, you can bury your head in the sand and leave 3GPP to get on with it. On the other hand, if you think that it would be valuable for this potentially vast constituency of SIP users to be able to interwork with other SIP users on the Internet, and for the 3GPP extensions to be designed in a way which aligns with the principles of SIP, you would be wise to take the opportunity that is offered to influence the 3GPP work. This implies constructive suggestions on how to meet the 3GPP requirements, which is what most people on this list have been devoting their time to, rather than repeated statements that 3GPP has the wrong arhitecture. Regards...Mark > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: 27 February 2002 09:58 > To: Andrew Allen > Cc: 'Dean Willis'; Christian Huitema; sip@ietf.org > Subject: RE: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path > scenari o outside of 3GPP requirements) > > > Andrew Allen writes: > > > There are about 900 MILLION mobile phones in the world > growing towards 1 > > BILLION. That's more than all the PCs out there. If most > of those phones in > > the future are using SIP what a huge base for enabling a > revolution in new > > services. > > the 3gpp architecture is not enabling that revolution, but is > trying to > prevent it by forcing the subscribers to use the services of its home > 3g operator. the subscriber should have true freedom to > choose services > from anywhere on the internet instead. > > as a started, what freedom is it that i need to register before i can > start making calls? the sip spec doesn't force you to do > that, but 3gpp > does. > > i think enough bandwidth has already been wasted for this. it should > already be clear to everyone, that ietf should not have anything to do > with 3gpp's usage of a signaling protocol that they falsely > try to claim > to be sip. > > -- 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 > ------_=_NextPart_001_01C1BFA7.C62483D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path = scenari o outside of 3GPP requirements)

Juha,

There is nothing to stop you getting an Internet = Access subscription on your 3G GPRS phone and registering with any SIP = Service Provider of your choice.

You will pay for the wireless QoS you request on a = per kb basis - the mobile operator will have no idea what you are using = these bits for. Now exactly how you get the QoS you need for real-time = services from the edge of the Wireless Access network to your = destination is another question.

If on the other hand you subscribe to a 3G IP = Multimedia Subsystem service, then the establishment of the access QoS = that you need is part of the IMS service you are invoking, not just a = request for a bit-pipe. Operators will have the flexibility to charge = based on the *service* you are invoking, not just on the bit-pipe = provision.

My guess is that it may be cheaper to make a voice = call via the IMS than it is to set up a bit-pipe to the Internet with = real-time QoS suitable for voice. [I don't just mean cheaper *per = minute*, though this may be the case. You also have to take into = account cost of handset etc. I imagine operators will subsidise = handsets which are locked in to their own services, as they do for GSM = today]

There are also various radio optimisations that the = access operator can provide if it knows what the bit-pipe is being used = for.

As noted by Andrew, the IMS separates out the = operator providing the wireless access to the IMS (Visited operator) = from that providing the services (Home operator), with whom you = register. There is no requirement that the Home Operator have a = wireless infrastructure. (Although there are some technicalities = regarding the separation of the GPRS subscription and IMS subscription = on the SIM card(s).)

There are many restrictions and considerations which = are special to cellular wireless access. Bandwidth is a very scarce = resource in this context and needs to be carefully managed. 3GPP takes = the view that in order to provide high quality real-time services over = cellular wireless access needs interaction with the network providing = that access, and that it is not sufficient for this interation to be = entirely controlled by the user. The 3GPP IMS is a platform for = providing that interaction between Home and Visited network, or Service = Provider and Access Provider, using SIP.

So, noone is preventing you from doing whatever you = want with your GPRS Internet Access. Nor are they preventing competing = operators from setting up 'Virtual' mobile service providers - in fact = these virtual operators are a good source of revenue for some networks, = rather than direct competitors.

It is not surprising that SIP in this application = needs some extensions that are not necessarily required in the Internet = - although Dean has given some good examples where Internet-based = scenarios approach the same architecture as the 3GPP IMS.

If you prefer that the IETF have no say in how 3GPP = use SIP for this application, you can bury your head in the sand and = leave 3GPP to get on with it. On the other hand, if you think that it = would be valuable for this potentially vast constituency of SIP users = to be able to interwork with other SIP users on the Internet, and for = the 3GPP extensions to be designed in a way which aligns with the = principles of SIP, you would be wise to take the opportunity that is = offered to influence the 3GPP work. This implies constructive = suggestions on how to meet the 3GPP requirements, which is what most = people on this list have been devoting their time to, rather than = repeated statements that 3GPP has the wrong arhitecture.

Regards...Mark









> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: 27 February 2002 09:58
> To: Andrew Allen
> Cc: 'Dean Willis'; Christian Huitema; = sip@ietf.org
> Subject: RE: 3GPP Arch. Why use a local proxy? = (was Re: [Sip] Path
> scenari o outside of 3GPP requirements)
>
>
> Andrew Allen writes:
>
>  > There are about 900 MILLION mobile = phones in the world
> growing towards 1
>  > BILLION. That's more than all the = PCs out there. If most
> of those phones in
>  > the future are using SIP what a huge = base for enabling a
> revolution in new
>  > services.
>
> the 3gpp architecture is not enabling that = revolution, but is
> trying to
> prevent it by forcing the subscribers to use = the services of its home
> 3g operator. the subscriber should have true = freedom to
> choose services
> from anywhere on the internet instead.
>
> as a started, what freedom is it that i need to = register before i can
> start making calls?  the sip spec doesn't = force you to do
> that, but 3gpp
> does.
>
> i think enough bandwidth has already been = wasted for this.  it should
> already be clear to everyone, that ietf should = not have anything to do
> with 3gpp's usage of a signaling protocol that = they falsely
> try to claim
> to be sip.
>
> -- 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
>

------_=_NextPart_001_01C1BFA7.C62483D0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 11:38:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01045 for ; Wed, 27 Feb 2002 11:38:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00746 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 11:38:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29025; Wed, 27 Feb 2002 11:12:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28994 for ; Wed, 27 Feb 2002 11:12:51 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.174]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29674 for ; Wed, 27 Feb 2002 11:12:47 -0500 (EST) Received: (from rjsparks@localhost) by rjs.dynamicsoft.com (8.11.2/8.11.2) id g1RGBcW07594; Wed, 27 Feb 2002 10:11:38 -0600 X-Authentication-Warning: rjs.dynamicsoft.com: rjsparks set sender to rsparks@dynamicsoft.com using -f Subject: Re: [Sip] Draft -08 comments, part 3: "major" issues From: Robert Sparks To: Jonathan Lennox Cc: Jonathan Rosenberg , sip@ietf.org In-Reply-To: <15485.507.891867.980497@bart.cs.columbia.edu> References: <15484.7512.130861.813280@grandcentral.cs.columbia.edu> <3C7CB1FC.7C1D7283@dynamicsoft.com> <15485.507.891867.980497@bart.cs.columbia.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Feb 2002 10:11:38 -0600 Message-Id: <1014826298.1201.5.camel@rjs.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Look at lines 1703-1707 of bis-08.pdf > > > Section 19.1.4: > > > What was the motivation for making URI comparisons non-transitive, and > > > special casing certain uri-parameters? It seems like it just makes a > > > lot of implementation things much harder. Wouldn't it be simpler just > > > to say that uri parameters must match? This would mean that the URI > > > comparison code could be completely ignorant of the semantics of URI > > > parameter names, and old and new parameters are treated equally. > > > > This is a general mechanism for backwards compatibility. I agree that > > transitivity would be nice in theory, but it seemed a riskier > > proposition. > > I realized last night the real problem with this. It means you can't > canonicalize a SIP URI. > > Here's an example. In our server, we use a SQL database as the back end to > our registration service. Since SQL doesn't understand SIP URIs, only > strings, we convert all URIs into a canonical string form before inserting > them into the database. In the previous spec this meant case-smashing all > CI elements, deleting default parameters, and lexicographically sorting all > the parameters and headers. Then, to accomplish registration updates, we > just use the address-of-record and the contact URI as database keys, and the > database does everything correctly. > > With bis-08's URI comparison rules, there's *no way* to do this. (Trivial > proof: string equality is an equivalence relation.) We'd have to somehow > put knowledge of these URI comparison rules into the database access code. > I *guess* this means putting both a all-nonstandard-parameters-stripped form > and a nonstandard-parameters-present form in the database, querying for > both, updating both, deleting as necessary...it's going to be a rat's nest, > and probably a lot less efficient. > > I imagine a whole lot of implementations are using string or hash > comparisons of canonicalized URIs, in some form or another, for their > location services... > > -- > Jonathan Lennox > lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 11:44:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01416 for ; Wed, 27 Feb 2002 11:44:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00989 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 11:44:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29889; Wed, 27 Feb 2002 11:26:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29857 for ; Wed, 27 Feb 2002 11:26:34 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00394 for ; Wed, 27 Feb 2002 11:26:29 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16g6uN-0004MS-00; Wed, 27 Feb 2002 18:26:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15485.2223.696388.295457@harjus.eng.song.fi> Date: Wed, 27 Feb 2002 18:26:23 +0200 To: "Mark Watson" Cc: Andrew Allen , "'Dean Willis'" , Christian Huitema , sip@ietf.org Subject: RE: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenari o outside of 3GPP requirements) In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > If you prefer that the IETF have no say in how 3GPP use SIP for this > application, you can bury your head in the sand and leave 3GPP to get on > with it. On the other hand, if you think that it would be valuable for this > potentially vast constituency of SIP users to be able to interwork with > other SIP users on the Internet, and for the 3GPP extensions to be designed > in a way which aligns with the principles of SIP, you would be wise to take > the opportunity that is offered to influence the 3GPP work. This implies > constructive suggestions on how to meet the 3GPP requirements, which is what > most people on this list have been devoting their time to, rather than > repeated statements that 3GPP has the wrong arhitecture. i have no desire to influence 3gpp work. they have already made up their minds to build yet another walled garden, this time using ip to do it. if they would have wanted an open architecture, then they would have designed generic means by which *anyone* on equal terms can request the qos that is needed to setup real time session. these means would have been independent of the "home" or "visited" wireless *network* service provider and would have allows anyone on the internet to provide the value added services. this is how internet operates today and this is how 3gpp should have designed their architecture. it is totally unacceptable for 3gpp folks to waste sip working group's time with proposals that in numerous ways break the sip service model. if that service model is not acceptable to 3gpp, then please destroy it on your own mailing lists. -- 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 daemon@optimus.ietf.org Wed Feb 27 12:32:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04992 for ; Wed, 27 Feb 2002 12:32:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05052 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 12:32:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03303; Wed, 27 Feb 2002 12:05:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03265 for ; Wed, 27 Feb 2002 12:04:56 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03404 for ; Wed, 27 Feb 2002 12:04:51 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 27 Feb 2002 17:05:10 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Draft -08 comments, part 3: "major" issues Date: Wed, 27 Feb 2002 17:07:33 -0000 Message-ID: <45730E094814E44488F789C1CDED27AEC552BB@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Draft -08 comments, part 3: "major" issues Thread-Index: AcG/qivVU/v3m3LBSCq2NQ8IDBLurAABYWOw From: "James Undery" To: "Robert Sparks" , "Jonathan Lennox" Cc: "Jonathan Rosenberg" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA03266 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, After reading 1703-07, I've a few comments, should the uri scheme and host be case-smashed to produce a canonical form; and I am a bit concerned about unescaping sip:james%00@ubiquity.net (although would be surprised at any legitimate use). James > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: 27 February 2002 16:12 > To: Jonathan Lennox > Cc: Jonathan Rosenberg; sip@ietf.org > Subject: Re: [Sip] Draft -08 comments, part 3: "major" issues > > > Look at lines 1703-1707 of bis-08.pdf > > > > > > Section 19.1.4: > > > > What was the motivation for making URI comparisons > non-transitive, and > > > > special casing certain uri-parameters? It seems like > it just makes a > > > > lot of implementation things much harder. Wouldn't it > be simpler just > > > > to say that uri parameters must match? This would mean > that the URI > > > > comparison code could be completely ignorant of the > semantics of URI > > > > parameter names, and old and new parameters are treated equally. > > > > > > This is a general mechanism for backwards compatibility. > I agree that > > > transitivity would be nice in theory, but it seemed a riskier > > > proposition. > > > > I realized last night the real problem with this. It means > you can't > > canonicalize a SIP URI. > > > > Here's an example. In our server, we use a SQL database as > the back end to > > our registration service. Since SQL doesn't understand SIP > URIs, only > > strings, we convert all URIs into a canonical string form > before inserting > > them into the database. In the previous spec this meant > case-smashing all > > CI elements, deleting default parameters, and > lexicographically sorting all > > the parameters and headers. Then, to accomplish > registration updates, we > > just use the address-of-record and the contact URI as > database keys, and the > > database does everything correctly. > > > > With bis-08's URI comparison rules, there's *no way* to do > this. (Trivial > > proof: string equality is an equivalence relation.) We'd > have to somehow > > put knowledge of these URI comparison rules into the > database access code. > > I *guess* this means putting both a > all-nonstandard-parameters-stripped form > > and a nonstandard-parameters-present form in the database, > querying for > > both, updating both, deleting as necessary...it's going to > be a rat's nest, > > and probably a lot less efficient. > > > > I imagine a whole lot of implementations are using string or hash > > comparisons of canonicalized URIs, in some form or another, > for their > > location services... > > > > -- > > Jonathan Lennox > > lennox@cs.columbia.edu > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Wed Feb 27 12:43:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05775 for ; Wed, 27 Feb 2002 12:43:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05771 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 12:43:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04221; Wed, 27 Feb 2002 12:25:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04190 for ; Wed, 27 Feb 2002 12:25:33 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04553 for ; Wed, 27 Feb 2002 12:25:25 -0500 (EST) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA23938; Wed, 27 Feb 2002 12:25:27 -0500 (EST) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1RHPQ6X018996; Wed, 27 Feb 2002 12:25:26 -0500 (EST) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.1/8.12.1/Submit) id g1RHPP8p018993; Wed, 27 Feb 2002 12:25:26 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15485.5765.155887.685582@grandcentral.cs.columbia.edu> Date: Wed, 27 Feb 2002 12:25:25 -0500 To: Robert Sparks Cc: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Draft -08 comments, part 3: "major" issues In-Reply-To: <1014826298.1201.5.camel@rjs.dynamicsoft.com> References: <15484.7512.130861.813280@grandcentral.cs.columbia.edu> <3C7CB1FC.7C1D7283@dynamicsoft.com> <15485.507.891867.980497@bart.cs.columbia.edu> <1014826298.1201.5.camel@rjs.dynamicsoft.com> X-Mailer: VM 6.98 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On , February 27 2002, "Robert Sparks" wrote to "Jonathan Lennox, Jonathan Rosenberg, sip@ietf.org" saying: > Look at lines 1703-1707 of bis-08.pdf Okay -- that solves it for the address-of-record. But line 1733 still invokes the URI comparison rules for the contact addresses. > > > > Section 19.1.4: > > > > What was the motivation for making URI comparisons non-transitive, and > > > > special casing certain uri-parameters? It seems like it just makes a > > > > lot of implementation things much harder. Wouldn't it be simpler just > > > > to say that uri parameters must match? This would mean that the URI > > > > comparison code could be completely ignorant of the semantics of URI > > > > parameter names, and old and new parameters are treated equally. > > > > > > This is a general mechanism for backwards compatibility. I agree that > > > transitivity would be nice in theory, but it seemed a riskier > > > proposition. > > > > I realized last night the real problem with this. It means you can't > > canonicalize a SIP URI. > > > > Here's an example. In our server, we use a SQL database as the back end to > > our registration service. Since SQL doesn't understand SIP URIs, only > > strings, we convert all URIs into a canonical string form before inserting > > them into the database. In the previous spec this meant case-smashing all > > CI elements, deleting default parameters, and lexicographically sorting all > > the parameters and headers. Then, to accomplish registration updates, we > > just use the address-of-record and the contact URI as database keys, and the > > database does everything correctly. > > > > With bis-08's URI comparison rules, there's *no way* to do this. (Trivial > > proof: string equality is an equivalence relation.) We'd have to somehow > > put knowledge of these URI comparison rules into the database access code. > > I *guess* this means putting both a all-nonstandard-parameters-stripped form > > and a nonstandard-parameters-present form in the database, querying for > > both, updating both, deleting as necessary...it's going to be a rat's nest, > > and probably a lot less efficient. > > > > I imagine a whole lot of implementations are using string or hash > > comparisons of canonicalized URIs, in some form or another, for their > > location services... -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 12:59:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06618 for ; Wed, 27 Feb 2002 12:59:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06711 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 12:59:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05581; Wed, 27 Feb 2002 12:40:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05550 for ; Wed, 27 Feb 2002 12:40:07 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05436 for ; Wed, 27 Feb 2002 12:40:01 -0500 (EST) Received: (qmail 14488 invoked from network); 27 Feb 2002 17:42:44 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 27 Feb 2002 17:42:44 -0000 Received: from stake.com (unknown [10.50.1.52]) by cam-relay.atstake.com (Postfix) with SMTP id 1261A22817 for ; Wed, 27 Feb 2002 12:39:29 -0500 (EST) Message-ID: <3C7D1A04.7060200@stake.com> Date: Wed, 27 Feb 2002 17:40:20 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: SIP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Question about section 12.2.2 bis-08 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Section 12.2.2: "...If the request has a tag in the To header field, the UAS core computes the dialog identifier corresponding to the request and compares it with existing dialogs...", if there is a match than this is a mid-dialog request. My question is as follows: For the computation of the dialog identifier are we ONLY looking at the Call-ID, From Tag and To Tag to make the match? So other fields and values not being looked at? -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 13:10:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07351 for ; Wed, 27 Feb 2002 13:10:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA07728 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 13:10:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06342; Wed, 27 Feb 2002 12:54:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06306 for ; Wed, 27 Feb 2002 12:54:50 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06366 for ; Wed, 27 Feb 2002 12:54:47 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1RHskB17970; Wed, 27 Feb 2002 18:54:46 +0100 (MET) Received: from lmf.ericsson.se ([131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1RHsjmK009810; Wed, 27 Feb 2002 19:54:45 +0200 (EET) Message-ID: <3C7D1DA1.75CE5FF0@lmf.ericsson.se> Date: Wed, 27 Feb 2002 19:55:45 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ofir Arkin CC: SIP Subject: Re: [Sip] Question about section 12.2.2 bis-08 References: <3C7D1A04.7060200@stake.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > Section 12.2.2: > > "...If the request has a tag in the To header field, the UAS core > computes the dialog identifier corresponding to the request and compares > it with existing dialogs...", if there is a match than this is a > mid-dialog request. > > My question is as follows: > For the computation of the dialog identifier are we ONLY looking at the > Call-ID, From Tag and To Tag to make the match? So other fields and > values not being looked at? Yes. Regards, Christer Holmberg Ericsson Finland > > > -- > Ofir Arkin > Managing Security Architect > @stake, Limited. > http://www.atstake.com > email: > ofir@stake.com > Tel: > +44 (0) 207 495 7002 > Fax: > +44 (0) 207 495 7062 > Mobile: +44 (0) 779 630 8632 > > ----------------------------- > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, re transmission, 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 any computer. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Wed Feb 27 13:30:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08663 for ; Wed, 27 Feb 2002 13:30:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17155 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 13:30:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07840; Wed, 27 Feb 2002 13:13:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07809 for ; Wed, 27 Feb 2002 13:13:11 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07509 for ; Wed, 27 Feb 2002 13:13:06 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1RICum12662; Wed, 27 Feb 2002 13:12:56 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAF87912; Wed, 27 Feb 2002 13:15:48 -0500 (EST) Message-ID: <3C7D2005.CA5EB31F@cisco.com> Date: Wed, 27 Feb 2002 13:05:57 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Re: [Sip-implementors] bis-08 is born References: <3C759F50.6685D5B0@cisco.com> <3C7CA270.3DC194F9@dynamicsoft.com> <3C7CF5FD.3A60A92E@cisco.com> <15484.64986.605083.538859@bart.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > > On Wednesday, February 27 2002, "Paul Kyzivat" wrote to "Jonathan Rosenberg, sip@ietf.org" saying: > > > That language about Contact:* fails to exclude the semantically invalid > > case of: > > > > REGISTER ... > > ... > > Expires: 0 > > Contact:*;expires=3600 > > This is forbidden by the Contact BNF. If you read it closely, you'll see > that "Contact: *" can't have any parameters at all. Yeah, you are right. I should have checked before writing. Even so, the following was (I think) technically legal before, though exactly what it meant might not have been clear: REGISTER ... ... Expires: 0 Contact: * Contact: ;expires=3600 > > I don't know if this is necessarily a good idea, but it's what the spec > says, and it resolves the issue. *If* we were to permit Contact:* to be mixed with other Contact headers, then I think it would be better to permit the expires= parameter on it, and simply require that the effective expiration time be zero. 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 daemon@optimus.ietf.org Wed Feb 27 13:30:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08721 for ; Wed, 27 Feb 2002 13:30:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17276 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 13:30:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07544; Wed, 27 Feb 2002 13:08:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07514 for ; Wed, 27 Feb 2002 13:08:21 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07059 for ; Wed, 27 Feb 2002 13:08:18 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1RI5iZq021368; Wed, 27 Feb 2002 13:05:44 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 13:07:50 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36300B2@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach Reply-To: sip@ietf.org To: "'sip@ietf.org'" Cc: "'simple@mailman.dynamicsoft.com'" Date: Wed, 27 Feb 2002 13:07:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] New Version: draft-ietf-sip-events-04 complete Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org FYI: a new version of the SIP Events draft is available. Until it appears in the archives, a copy is available from the locations listed below. WGLC has already concluded; this announcement is for information purposes only. I am not soliciting comments from the working group at this time. Official version: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-04.txt Unofficial PDF version w/changebars: http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-04.pdf Changes from -03 are nominal, and are documented at: http://pages.sbcglobal.net/roaches/ietf/event-changes.html /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 daemon@optimus.ietf.org Wed Feb 27 13:49:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09755 for ; Wed, 27 Feb 2002 13:49:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19756 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 13:49:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16951; Wed, 27 Feb 2002 13:29:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16923 for ; Wed, 27 Feb 2002 13:29:11 -0500 (EST) Received: from web11601.mail.yahoo.com (web11601.mail.yahoo.com [216.136.172.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08521 for ; Wed, 27 Feb 2002 13:29:07 -0500 (EST) Message-ID: <20020227182908.77666.qmail@web11601.mail.yahoo.com> Received: from [131.107.3.78] by web11601.mail.yahoo.com via HTTP; Wed, 27 Feb 2002 10:29:08 PST Date: Wed, 27 Feb 2002 10:29:08 -0800 (PST) From: Sean Olson Subject: RE: [Sip] Draft -08 comments, part 3: "major" issues To: James Undery , Robert Sparks , Jonathan Lennox Cc: Jonathan Rosenberg , sip@ietf.org In-Reply-To: <45730E094814E44488F789C1CDED27AEC552BB@GBNEWP0758M.eu.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --- James Undery wrote: > Hi, > > After reading 1703-07, I've a few comments, should > the uri scheme and > host be case-smashed to produce a canonical form; > and I am a bit > concerned about unescaping sip:james%00@ubiquity.net > (although would be > surprised at any legitimate use). > > James > This is not the first time this has come up. I've always been of the opinion that you must unescape to get a canonical form. Otherwise we will potentially run into comparison problems because two different implementations decided to escape different sets of chararcters. Sean ===== Sean Olson __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.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 daemon@optimus.ietf.org Wed Feb 27 14:06:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10736 for ; Wed, 27 Feb 2002 14:06:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21434 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 14:06:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19631; Wed, 27 Feb 2002 13:48:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19600 for ; Wed, 27 Feb 2002 13:48:35 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09675 for ; Wed, 27 Feb 2002 13:48:30 -0500 (EST) Received: (qmail 15253 invoked from network); 27 Feb 2002 18:51:12 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 27 Feb 2002 18:51:12 -0000 Received: from stake.com (unknown [10.50.1.52]) by cam-relay.atstake.com (Postfix) with SMTP id 5F97322819 for ; Wed, 27 Feb 2002 13:47:26 -0500 (EST) Message-ID: <3C7D29F1.4080401@stake.com> Date: Wed, 27 Feb 2002 18:48:17 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: SIP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Question about Section 12.2 Requests within a Dialog Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI". First Question: When a UAS produce a reply to a request within a dialog will it use the via to route back to the sending UA or will it consult its 'state' and grab the route from there? Second Question: Why this might change the target URI? I must admit that the target refresh thing got me really confused... Thanks! -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 14:06:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10753 for ; Wed, 27 Feb 2002 14:06:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21448 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 14:06:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18953; Wed, 27 Feb 2002 13:44:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18871 for ; Wed, 27 Feb 2002 13:44:37 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.174]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09445 for ; Wed, 27 Feb 2002 13:44:33 -0500 (EST) Received: (from rjsparks@localhost) by rjs.dynamicsoft.com (8.11.2/8.11.2) id g1RIgm707810; Wed, 27 Feb 2002 12:42:48 -0600 X-Authentication-Warning: rjs.dynamicsoft.com: rjsparks set sender to rsparks@dynamicsoft.com using -f Subject: Re: [Sip] Draft -08 comments, part 3: "major" issues From: Robert Sparks To: Jonathan Lennox Cc: Jonathan Rosenberg , sip@ietf.org In-Reply-To: <15485.5765.155887.685582@grandcentral.cs.columbia.edu> References: <15484.7512.130861.813280@grandcentral.cs.columbia.edu> <3C7CB1FC.7C1D7283@dynamicsoft.com> <15485.507.891867.980497@bart.cs.columbia.edu> <1014826298.1201.5.camel@rjs.dynamicsoft.com> <15485.5765.155887.685582@grandcentral.cs.columbia.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Feb 2002 12:42:48 -0600 Message-Id: <1014835368.1201.13.camel@rjs.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2002-02-27 at 11:25, Jonathan Lennox wrote: > On , February 27 2002, "Robert Sparks" wrote to "Jonathan Lennox, Jonathan Rosenberg, sip@ietf.org" saying: > > > Look at lines 1703-1707 of bis-08.pdf > > Okay -- that solves it for the address-of-record. But line 1733 still > invokes the URI comparison rules for the contact addresses. And how is -08 making things harder than, say -02? (Transitivity went away way back then - see section 2.1 of bis-02). > > > > > > > Section 19.1.4: > > > > > What was the motivation for making URI comparisons non-transitive, and > > > > > special casing certain uri-parameters? It seems like it just makes a > > > > > lot of implementation things much harder. Wouldn't it be simpler just > > > > > to say that uri parameters must match? This would mean that the URI > > > > > comparison code could be completely ignorant of the semantics of URI > > > > > parameter names, and old and new parameters are treated equally. > > > > > > > > This is a general mechanism for backwards compatibility. I agree that > > > > transitivity would be nice in theory, but it seemed a riskier > > > > proposition. > > > > > > I realized last night the real problem with this. It means you can't > > > canonicalize a SIP URI. > > > > > > Here's an example. In our server, we use a SQL database as the back end to > > > our registration service. Since SQL doesn't understand SIP URIs, only > > > strings, we convert all URIs into a canonical string form before inserting > > > them into the database. In the previous spec this meant case-smashing all > > > CI elements, deleting default parameters, and lexicographically sorting all > > > the parameters and headers. Then, to accomplish registration updates, we > > > just use the address-of-record and the contact URI as database keys, and the > > > database does everything correctly. > > > > > > With bis-08's URI comparison rules, there's *no way* to do this. (Trivial > > > proof: string equality is an equivalence relation.) We'd have to somehow > > > put knowledge of these URI comparison rules into the database access code. > > > I *guess* this means putting both a all-nonstandard-parameters-stripped form > > > and a nonstandard-parameters-present form in the database, querying for > > > both, updating both, deleting as necessary...it's going to be a rat's nest, > > > and probably a lot less efficient. > > > > > > I imagine a whole lot of implementations are using string or hash > > > comparisons of canonicalized URIs, in some form or another, for their > > > location services... > > -- > Jonathan Lennox > lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 14:17:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11528 for ; Wed, 27 Feb 2002 14:17:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22308 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 14:17:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20081; Wed, 27 Feb 2002 13:55:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20051 for ; Wed, 27 Feb 2002 13:55:52 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10070 for ; Wed, 27 Feb 2002 13:55:49 -0500 (EST) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA03929; Wed, 27 Feb 2002 13:55:45 -0500 (EST) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g1RIti6X020229; Wed, 27 Feb 2002 13:55:44 -0500 (EST) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.1/8.12.1/Submit) id g1RIthBn020226; Wed, 27 Feb 2002 13:55:43 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15485.11183.157104.936121@grandcentral.cs.columbia.edu> Date: Wed, 27 Feb 2002 13:55:43 -0500 To: Sean Olson Cc: James Undery , Robert Sparks , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] Draft -08 comments, part 3: "major" issues In-Reply-To: <20020227182908.77666.qmail@web11601.mail.yahoo.com> References: <45730E094814E44488F789C1CDED27AEC552BB@GBNEWP0758M.eu.ubiquity.net> <20020227182908.77666.qmail@web11601.mail.yahoo.com> X-Mailer: VM 6.98 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Wednesday, February 27 2002, "Sean Olson" wrote to "James Undery, Robert Sparks, Jonathan Lennox, Jonathan Rosenberg, sip@ietf.org" saying: > > --- James Undery wrote: > > Hi, > > > > After reading 1703-07, I've a few comments, should > > the uri scheme and > > host be case-smashed to produce a canonical form; > > and I am a bit > > concerned about unescaping sip:james%00@ubiquity.net > > (although would be > > surprised at any legitimate use). > > > > James > > > > This is not the first time this has come up. > I've always been of the opinion that you must > unescape to get a canonical form. Otherwise we > will potentially run into comparison problems > because two different implementations decided > to escape different sets of chararcters. If you're just worrying about your internal representations, though, there's nothing wrong with unescaping and then re-escaping, so long as you use a consistent set of escaping characters for your re-escaping. The spec only dictates behavior, not implementation. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 14:27:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12178 for ; Wed, 27 Feb 2002 14:27:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22806 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 14:27:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21896; Wed, 27 Feb 2002 14:11:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21846 for ; Wed, 27 Feb 2002 14:11:08 -0500 (EST) Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11161 for ; Wed, 27 Feb 2002 14:11:04 -0500 (EST) Message-ID: <20020227191105.69815.qmail@web11603.mail.yahoo.com> Received: from [207.46.137.9] by web11603.mail.yahoo.com via HTTP; Wed, 27 Feb 2002 11:11:05 PST Date: Wed, 27 Feb 2002 11:11:05 -0800 (PST) From: Sean Olson Subject: RE: [Sip] Draft -08 comments, part 3: "major" issues To: Jonathan Lennox Cc: James Undery , Robert Sparks , Jonathan Rosenberg , sip@ietf.org In-Reply-To: <15485.11183.157104.936121@grandcentral.cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Internal representation is of course an implemenation detail. However, the rules for comparison of URIs is not. If you implement this behaviour using an un-escape/re-escape sequence, that's fine. As long as the behaviour is described to indicate that comparisons occur on the un-escaped URI. /sean --- Jonathan Lennox wrote: > On Wednesday, February 27 2002, "Sean Olson" wrote > to "James Undery, Robert Sparks, Jonathan Lennox, > Jonathan Rosenberg, sip@ietf.org" saying: > > > > > --- James Undery wrote: > > > Hi, > > > > > > After reading 1703-07, I've a few comments, > should > > > the uri scheme and > > > host be case-smashed to produce a canonical > form; > > > and I am a bit > > > concerned about unescaping > sip:james%00@ubiquity.net > > > (although would be > > > surprised at any legitimate use). > > > > > > James > > > > > > > This is not the first time this has come up. > > I've always been of the opinion that you must > > unescape to get a canonical form. Otherwise we > > will potentially run into comparison problems > > because two different implementations decided > > to escape different sets of chararcters. > > If you're just worrying about your internal > representations, though, there's > nothing wrong with unescaping and then re-escaping, > so long as you use a > consistent set of escaping characters for your > re-escaping. > > The spec only dictates behavior, not implementation. > > -- > Jonathan Lennox > lennox@cs.columbia.edu ===== Sean Olson __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.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 daemon@optimus.ietf.org Wed Feb 27 14:33:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12614 for ; Wed, 27 Feb 2002 14:33:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23463 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 14:33:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22218; Wed, 27 Feb 2002 14:15:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22186 for ; Wed, 27 Feb 2002 14:15:39 -0500 (EST) Received: from rjs.dynamicsoft.com ([63.110.3.174]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11424 for ; Wed, 27 Feb 2002 14:15:35 -0500 (EST) Received: (from rjsparks@localhost) by rjs.dynamicsoft.com (8.11.2/8.11.2) id g1RJEt507876; Wed, 27 Feb 2002 13:14:55 -0600 X-Authentication-Warning: rjs.dynamicsoft.com: rjsparks set sender to rsparks@dynamicsoft.com using -f Subject: Re: [Sip] Question about Section 12.2 Requests within a Dialog From: Robert Sparks To: Ofir Arkin Cc: SIP In-Reply-To: <3C7D29F1.4080401@stake.com> References: <3C7D29F1.4080401@stake.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Feb 2002 13:14:55 -0600 Message-Id: <1014837295.1201.20.camel@rjs.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2002-02-27 at 12:48, Ofir Arkin wrote: > "Requests within a dialog MAY contain Record-Route and Contact header > fields. However, these requests do not cause the dialog's route set to > be modified, although they may modify the remote target URI". > > First Question: > When a UAS produce a reply to a request within a dialog will it use the > via to route back to the sending UA or will it consult its 'state' and > grab the route from there? Responses always return following the Via stack. > > Second Question: > Why this might change the target URI? > I must admit that the target refresh thing got me really confused... This mechanism allows an endpoint to change the URI it wants to be handed in future requests within this dialog. This can be used as a place to store state for future requests. The original proponents planned to use this as part of the mechanics to deal with mobility (address mobility in particular). I don't believe those ideas have been fleshed out. > > Thanks! > -- > Ofir Arkin > Managing Security Architect > @stake, Limited. > http://www.atstake.com > email: > ofir@stake.com > Tel: > +44 (0) 207 495 7002 > Fax: > +44 (0) 207 495 7062 > Mobile: +44 (0) 779 630 8632 > > ----------------------------- > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, re transmission, 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 any computer. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Wed Feb 27 15:32:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16211 for ; Wed, 27 Feb 2002 15:32:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27187 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 15:32:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26056; Wed, 27 Feb 2002 15:12:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26025 for ; Wed, 27 Feb 2002 15:12:03 -0500 (EST) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14995 for ; Wed, 27 Feb 2002 15:11:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] draft-ietf-sip-events-04; Questions Date: Wed, 27 Feb 2002 14:11:31 -0600 Message-ID: Thread-Topic: [Sip] New Version: draft-ietf-sip-events-04 complete thread-index: AcG/vB/RCq4nW0+fRsO/G7zKqWqvaQACplJA From: "Chiou, Mark" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA26026 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Adam, I have the following questions regarding to 7.4 new Method: 1. Why the Contact header is mandatory for SUBSCRIBER and NOTIFY? If the Contact is not applicable to these methods, then "-" should be applied to R, 1xx, 2xx, 3xx, and 485. 2. I don't think 3xx is applicable to these two methods, such that contact 3xx should have "-" instead of "o". Regards, Mark Chiou _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 16:39:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20031 for ; Wed, 27 Feb 2002 16:39:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01519 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 16:39:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29848; Wed, 27 Feb 2002 16:14:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29819 for ; Wed, 27 Feb 2002 16:14:44 -0500 (EST) Received: from localhost ([211.217.173.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18696 for ; Wed, 27 Feb 2002 16:14:38 -0500 (EST) Message-Id: <200202272114.QAA18696@ietf.org> Reply-To: gotours@dreamwiz.com From: 여행가자 To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Feb 2002 06:09:02 +0900 Subject: [Sip] [이벤트광고]무료 회원가입 하시면 해외 무료 여행권을 드립니다. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 여행가자 오픈 기념으로 회원 가입시 [태국,필리핀,사이판] 무료 해외 여행권을 드립니다.


[이벤트1] = 여행가자 홈페이지 오픈 기념으로 회원 가입시 [태국,필리핀,사이판]
무료 해외 여행권을 드립니다.   [항공권 별도 ]
기간 : 2002년 2월18일 ~ 4월 30일 까지 대상 : 여행가자 신규회원 가입자 전원증정

[이벤트2] = 주위의 결혼하시는 분들에게 저희 여행가자를 소개시켜 주셔서 신혼여행이 
계약되면 계약과 동시에 계좌로 일금 50,000원을 입금해 드립니다.
(단 제주도 신혼여행은 20,000원) 
 여행가자 홈페이지 바로가기
 

귀하의 승락없이 홍보성 전자 우편을 보내게 된 점 정중히 사과 드립니다.
정보통신망이용촉진법 규정을 준수하여 광고메일임을 표시하였으며, 수신거부 장치를 마련하고 있습니다.
귀하의 전자 우편 주소는 인터넷 상의 공개된 장소에서 습득하였으며, 저희는 귀하의 전자우편 주소 외 어떠한 개인정보도 가지고 있지 않으므로 안심하시기 바랍니다. 수신을 원치 않으시면 를 클릭해 주십시요.  

 
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 16:39:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20048 for ; Wed, 27 Feb 2002 16:39:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01533 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 16:39:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29781; Wed, 27 Feb 2002 16:14:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29639 for ; Wed, 27 Feb 2002 16:14:04 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18668 for ; Wed, 27 Feb 2002 16:13:58 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1RLDUB05491; Wed, 27 Feb 2002 15:13:30 -0600 Message-ID: <012801c1bfd3$8dea45f0$bc036e3f@TXDWILLIS2> From: "Dean Willis" To: Cc: References: <73B855B4F72FD411A1CF009027B113C40199F6AF@taxis.materna.de> Subject: Re: [Sip] AW: Why Proxies are Good and B2BUAs May Not Be --> NO Date: Wed, 27 Feb 2002 15:13:05 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thomas further discussed: > True. But what about a thing, that would not change the "upper layers" > of SIP. Say, translating the SIP messages received over XML/HTTP to > standard SIP over UDP. > This could be coupled with a "standard" SIP proxy of course. So it would > then be a proxy that accepted only a new transfer encoding of SIP. That's an interesting metaphysical question. As the SIP specification does specify the transfer encoding at layer 3, so it's an open question whether a different encoding would still be "standard". But one could theoretically preserve feature transparency over such a coding, so a "proxy" in this mode is not completely ridiculous. > > > Essentially, anything that does SIP->somethingelse->SIP can > > be considered a > > form of B2BUA. > No. Only *if* it changes the data. Or if it changes the timing characteristics, etc. > > >Feature transparency across such a stucture > > requires a fully > > homomorphic mapping between SIP and somethingelse. > It does not map SIP to something else, > it only encapsulates the SIP header fields into XML-tags. So what does it do if it sees a SIP message type that it's never seen before? . . . . > As I said before, I was a bit stuck to the SIMPLE view... > Perhaps the semantics of SIP are a bit strained by SIMPLE with regard > to the REGISTER process. The semantics of SIP, in general, are a bit strained by the REGISTER process. REGISTER is a very different operation from everything else SIP does. Arguments have been made that if we were inventing SIP today, we might not include REGISTER at all. > And, could you give me a pointer, which 3G doc defines the relation > between SIP user registry (shouldn't it be in VHE?) and HSS? Thanks. ;) You know, I don't actually know exactly where this is. I'd start with 23.228, I believe. Any of you CN1 guys know more precisely? > Anyway, I would still like to know how you think about an XML-transmission > of SIP messages. It could do a lot good. Just think about the big number of > clients that support XML, and the overwhelming support of servlets, which > can easily be used for XML, but not for SIP-over-UDP nor SIP-over-TCP. Actually, there is a SIP Servlet specification. -- 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 daemon@optimus.ietf.org Wed Feb 27 16:39:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20097 for ; Wed, 27 Feb 2002 16:39:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01547 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 16:39:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29655; Wed, 27 Feb 2002 16:14:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29624 for ; Wed, 27 Feb 2002 16:14:01 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18666 for ; Wed, 27 Feb 2002 16:13:55 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1RLDOB05486; Wed, 27 Feb 2002 15:13:25 -0600 Message-ID: <012701c1bfd3$8b501310$bc036e3f@TXDWILLIS2> From: "Dean Willis" To: Cc: References: <73B855B4F72FD411A1CF009027B113C40199F6AF@taxis.materna.de> Subject: Re: [Sip] AW: Why Proxies are Good and B2BUAs May Not Be --> NO Date: Wed, 27 Feb 2002 15:13:01 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thomas further discussed: > True. But what about a thing, that would not change the "upper layers" > of SIP. Say, translating the SIP messages received over XML/HTTP to > standard SIP over UDP. > This could be coupled with a "standard" SIP proxy of course. So it would > then be a proxy that accepted only a new transfer encoding of SIP. That's an interesting metaphysical question. As the SIP specification does specify the transfer encoding at layer 3, so it's an open question whether a different encoding would still be "standard". But one could theoretically preserve feature transparency over such a coding, so a "proxy" in this mode is not completely ridiculous. > > > Essentially, anything that does SIP->somethingelse->SIP can > > be considered a > > form of B2BUA. > No. Only *if* it changes the data. Or if it changes the timing characteristics, etc. > > >Feature transparency across such a stucture > > requires a fully > > homomorphic mapping between SIP and somethingelse. > It does not map SIP to something else, > it only encapsulates the SIP header fields into XML-tags. So what does it do if it sees a SIP message type that it's never seen before? . . . . > As I said before, I was a bit stuck to the SIMPLE view... > Perhaps the semantics of SIP are a bit strained by SIMPLE with regard > to the REGISTER process. The semantics of SIP, in general, are a bit strained by the REGISTER process. REGISTER is a very different operation from everything else SIP does. Arguments have been made that if we were inventing SIP today, we might not include REGISTER at all. > And, could you give me a pointer, which 3G doc defines the relation > between SIP user registry (shouldn't it be in VHE?) and HSS? Thanks. ;) You know, I don't actually know exactly where this is. I'd start with 23.228, I believe. Any of you CN1 guys know more precisely? > Anyway, I would still like to know how you think about an XML-transmission > of SIP messages. It could do a lot good. Just think about the big number of > clients that support XML, and the overwhelming support of servlets, which > can easily be used for XML, but not for SIP-over-UDP nor SIP-over-TCP. Actually, there is a SIP Servlet specification. -- 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 daemon@optimus.ietf.org Wed Feb 27 17:02:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21260 for ; Wed, 27 Feb 2002 17:02:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03130 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 17:02:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01774; Wed, 27 Feb 2002 16:41:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01745 for ; Wed, 27 Feb 2002 16:41:36 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20251 for ; Wed, 27 Feb 2002 16:41:31 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1RLeUB05705; Wed, 27 Feb 2002 15:40:31 -0600 Message-ID: <01a201c1bfd7$543d1e50$bc036e3f@TXDWILLIS2> From: "Dean Willis" To: "Pete Cordell" Cc: References: <004201c1bee1$d7350620$8b036e3f@DWILLISS1> <00a201c1bf79$c449bf40$0200000a@tkw> Subject: Re: Why Proxies are Good and B2BUAs May Not Be (was Re: [Sip] bis-07.9: proxies are not allowed to modify message body) Date: Wed, 27 Feb 2002 15:40:08 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Pete Cordell" To: "Dean Willis" Cc: Sent: Wednesday, February 27, 2002 2:46 AM Subject: Re: Why Proxies are Good and B2BUAs May Not Be (was Re: [Sip] bis-07.9: proxies are not allowed to modify message body) > Dean, > > Seeing as you are the king of analogy, I'll try and put my concerns thusly:- > > You can legislate against drinking, but that doesn't mean that it won't > happen. > I also believe in personal freedom to vote for a candidate from a major political party or commit suicide, but I generally try to discourage my friends from doing either one. That's why we put labels on beer bottles saying "do not operate equipment or gestate new units while drinking" (or something like that). The definition of a proxy is just such a label. We don't expect it will stop people from doing dangerous/stupid things, but at least they'll be making an informed decision to do something dangerous/stupid. We can't make any protocol perfectly safe for all usages and all potentialities of forward and backward compatibility. But we can put a border around the map, and write "Here there be dragons" beyond the edge. Explore to your heart's content. Maybe you'll discover a new continent and get to be declared Important. But don't complain if you come back with tooth-and-scorch marks. -- 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 daemon@optimus.ietf.org Wed Feb 27 17:40:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22872 for ; Wed, 27 Feb 2002 17:40:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05479 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 17:40:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04089; Wed, 27 Feb 2002 17:21:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04063 for ; Wed, 27 Feb 2002 17:21:46 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22145 for ; Wed, 27 Feb 2002 17:21:42 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1RMKiB05940; Wed, 27 Feb 2002 16:20:44 -0600 Message-ID: <01d601c1bfdc$f21c3610$bc036e3f@TXDWILLIS2> From: "Dean Willis" To: Cc: References: <15485.2223.696388.295457@harjus.eng.song.fi> Subject: Re: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenari o outside of 3GPP requirements) Date: Wed, 27 Feb 2002 16:20:21 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha wrote: > it is totally unacceptable for 3gpp folks to waste sip working group's > time with proposals that in numerous ways break the sip service > model. if that service model is not acceptable to 3gpp, then please > destroy it on your own mailing lists. Curse of the capitalist model. In many ways, I'm sympathetic to your position. But it may be relevant to point out that with the downturn of Internet technology businesses, the 3Gish folks are actually paying for much of the current development and deployment of SIP specifications and systems. Look at the people who worked on the SIP spec rewrite and its compatriots now in Last Call. 3G covers my pay check as well as those of Jonathan Rosenberg, Brian Rosen (Marconi was a 3G provider last time I looked), Robert Sparks, Gonzalo Camarillo and Adam Roach, and the employers of Alan Johnston and Jon Peterson are into enough different things that I woudn't be surprised to learn that they're involved in 3G as well. I doubt anybody's boss would sign off on the hours that have been poured into this if they didn't see some sort of business opportunity developing from it. This same kind of pattern holds across the working group. Some of the people are paid for by surviving wireline operators who still have plans to move beyond SS7, and who in many cases sell terrestrial bandwidth to the mobile operators. Then there's the traditional Internet equipment providers who hope to sell a whole lot of gear to mobile operators, and the software companies that deliver operating systems, tools, and so on. There are applications guys (media servers, etc.) who want to build systems that can work in a converged environment. There are probably lots of other relationships I haven't even noticed. This accounts for a fairly broad set of interest in achieving some kind of success for 3G's needs. The 3Gish people also represent a huge share of the constituency for the protocol -- as Andrew Allen pointed out, the 3G adoption of IETF protocols potentially more than doubles the reach of the Internet. If a tree falls in the woods and there is nobody there to hear it does it still make a noise? Who cares? How about a protocol that nobody uses? So it's potentially important to have a constituency. I don't think Jonathan would have spent the last five years inventing a protocol that he didn't want a lot of people to use. So we find ourselves in a balancing act -- trying to build a protocol that 3G will actually use that does not REQUIRE (but perhaps allows) subversion of the Internet model, and that allows (and encourages) increasing adoption of the Internet model when the business can be made to prove out and the operators reach the maturity needed to do business in that environment. We must do so without damaging the utility of the protocol for people with more traditionally Internet business models. Nobody said this was going to be easy. I suppose it would be possible to just pack all ths work off somewhere else, but do you really want that? It might get lonely for you. -- 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 daemon@optimus.ietf.org Wed Feb 27 18:37:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24439 for ; Wed, 27 Feb 2002 18:37:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08952 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 18:37:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07178; Wed, 27 Feb 2002 18:09:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07145 for ; Wed, 27 Feb 2002 18:09:23 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23652 for ; Wed, 27 Feb 2002 18:09:19 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1RN8rS06656 for ; Wed, 27 Feb 2002 17:08:53 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1RN8qx20814 for ; Wed, 27 Feb 2002 17:08:52 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g1RN8qE19831 for ; Wed, 27 Feb 2002 18:08:52 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 18:09:16 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C03748C@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: sip@ietf.org Date: Wed, 27 Feb 2002 18:08:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] UPDATE Method & Glare Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Within the current draft on UPDATE method, glare can occur within a dialogue. I mean it is perfectly okay for 2 UAs to send simultaneous UPDATES causing glare. I dont see anywhere where this case is covered in the current draft. Can that be added to the draft to specify the procedures to be followed should that situation arise. Thanks George Foti Ericsson Canada _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Feb 27 20:08:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26719 for ; Wed, 27 Feb 2002 20:08:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA13329 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 20:08:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11996; Wed, 27 Feb 2002 19:45:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11949 for ; Wed, 27 Feb 2002 19:45:08 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26170 for ; Wed, 27 Feb 2002 19:45:04 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1S0iah10499 for ; Wed, 27 Feb 2002 16:44:36 -0800 (PST) Received: from cj14 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACD23554; Wed, 27 Feb 2002 16:44:45 -0800 (PST) From: "Cullen Jennings" To: Date: Wed, 27 Feb 2002 16:46:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <15485.5765.155887.685582@grandcentral.cs.columbia.edu> Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Irrelevant nit on call-id and IPs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bis 8, line 399. Thought we had decided to not encourage people to use IP address to build the Call-ID. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Feb 27 22:11:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00535 for ; Wed, 27 Feb 2002 22:11:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA19380 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 22:11:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18082; Wed, 27 Feb 2002 21:42:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18050 for ; Wed, 27 Feb 2002 21:42:17 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00081 for ; Wed, 27 Feb 2002 21:42:12 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1S2feh15168; Wed, 27 Feb 2002 18:41:40 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA22050; Wed, 27 Feb 2002 18:41:38 -0800 (PST) Message-ID: <3C7D98E1.8D6A7F58@cisco.com> Date: Wed, 27 Feb 2002 21:41:37 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Remote-Party-Id extensibility Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Please read and comment quickly: As you may know, the privacy-04 draft will contain an applicability statement that points out the environments in which the draft may be usable. Suffice it to say, that these environments do not include the general Internet at large, but rather resemble service provider like models with transitive trust relationships. Presently, the Remote-Party-Id header field consists of a bunch of parameters, each of which is extensible. The concern that has been raised is, that by allowing for all this extensibility, we are opening ourselves up to duplicating existing (and perhaps future and more general) headers and also to go beyond the applicability statement. It has therefore been suggested, that we remove all this extensibility from Remote-Party-ID, except for the rpi-privacy parameter. In essence, we would prevent the Remote-Party-Id header from containing any kind of identity (or other) information not currently defined in the draft. As a consequence of that, the Nature of Party indication provided in Appendix A would be removed from the draft as well. Instead, the idea would be to provide these as part of a tel-url. Your prompt feedback on this would be appreciated. Thanks Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Feb 27 23:04:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02899 for ; Wed, 27 Feb 2002 23:04:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA21607 for sip-archive@odin.ietf.org; Wed, 27 Feb 2002 23:04:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20790; Wed, 27 Feb 2002 22:45:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20759 for ; Wed, 27 Feb 2002 22:45:13 -0500 (EST) Received: from odin.ietf.org (pcp809562pcs.nrockv01.md.comcast.net [68.49.82.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02494 for ; Wed, 27 Feb 2002 22:45:08 -0500 (EST) From: "customer_service@childcareprograms.com" Date: Wed, 27 Feb 2002 22:44:41 To: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_OWUZEGIKCJ" Content-Transfer-Encoding: 7bit Message-ID: PM200010:44:41 PM Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is an HTML email message. If you see this, your mail client does not support HTML messages. ------=_NextPart_OWUZEGIKCJ Content-Type: text/html;charset="iso-8859-1" Content-Transfer-Encoding: 7bit ChildcarePrograms Home Page

           

| Full/Part Time Program | Weekends Program | Go Out Club | Vacation Club | Summer Program | Gold Membership |

Log In.jpg (1493 bytes)

http://www.childcareprograms.com/BABY16.GIF (6379 bytes)

http://www.childcareprograms.com/Button_Registration_1.jpg (1813 bytes)

http://www.childcareprograms.com/Button_Programs_4.jpg (1722 bytes)

http://www.childcareprograms.com/Button_Pratners_3.jpg (1785 bytes)

http://www.childcareprograms.com/Button_Contact_2.jpg (1751 bytes)

http://www.childcareprograms.com/Button_Payment_1.jpg (1810 bytes)

 

  

WHAT IS THIS SITE ABOUT?

HOW TO FIND CHILDCARE PROGRAM APPROPRIATE TO YOU USING THIS SITE

Are you tired looking for mature reliable babysitter? You can’t find someone to leave your children with when you go out? You don’t know what to do with your schoolchild, when summer camp is over but school doesn’t start yet? You are not alone. There are plenty of people having the same problems and living close to you!

Our purpose is to help these people.

The first in the line of our service products is a Whole/Part Day Program. The basic version of the program is for 5 working mothers to provide day care to 5 kids 1 day per week, in their own house. There are variations of this program for a particular case. First, there may be different numbers of participants: from 2 to 5. There may be variations in the place of the childcare: change house for each mother every day or use only one (2, 3 or 4) house(s) as agreed with other participants ...... (see whole text)

� 1996-2000, People2People Technology, Inc.

 

Full/Part Time Program

Weekends Program

Go Out Club

Vacation Club

Summer Program

Gold Membership

To be removed from this mailing list, please click on this link: http://www.childcareprograms.com/unsubscribe.htm
You must use your exact address in the box to ensure
you will be unsubscribed.

------=_NextPart_OWUZEGIKCJ-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Feb 28 01:17:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04912 for ; Thu, 28 Feb 2002 01:17:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA06710 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 01:17:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA25830; Thu, 28 Feb 2002 00:48:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA25803 for ; Thu, 28 Feb 2002 00:48:21 -0500 (EST) Received: from services.dasecurenetworks.com (adsl-64-217-199-174.dsl.rcsntx.swbell.net [64.217.199.174]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04637 for ; Thu, 28 Feb 2002 00:48:11 -0500 (EST) Received: from dasecurenetworks.com (main1.dasecurenetworks.com [192.168.0.151] (may be forged)) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g1S5AdX19899; Wed, 27 Feb 2002 23:10:45 -0600 Message-ID: <3C7DC67F.1D9384E9@dasecurenetworks.com> Date: Wed, 27 Feb 2002 23:56:15 -0600 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: Mark Watson , Andrew Allen , "'Dean Willis'" , Christian Huitema , sip@ietf.org Subject: Re: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenario outside of 3GPP requirements) References: <15485.2223.696388.295457@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Comments inline jh@lohi.eng.song.fi wrote: > > Mark Watson writes: > > > If you prefer that the IETF have no say in how 3GPP use SIP for this > > application, you can bury your head in the sand and leave 3GPP to get on > > with it. On the other hand, if you think that it would be valuable for this > > potentially vast constituency of SIP users to be able to interwork with > > other SIP users on the Internet, and for the 3GPP extensions to be designed > > in a way which aligns with the principles of SIP, you would be wise to take > > the opportunity that is offered to influence the 3GPP work. This implies > > constructive suggestions on how to meet the 3GPP requirements, which is what > > most people on this list have been devoting their time to, rather than > > repeated statements that 3GPP has the wrong arhitecture. > > i have no desire to influence 3gpp work. they have already made up > their minds to build yet another walled garden, this time using ip to do > it. if they would have wanted an open architecture, then they would > have designed generic means by which *anyone* on equal terms can request > the qos that is needed to setup real time session. these means would > have been independent of the "home" or "visited" wireless *network* > service provider and would have allows anyone on the internet to provide > the value added services. this is how internet operates today and this > is how 3gpp should have designed their architecture. > > it is totally unacceptable for 3gpp folks to waste sip working group's > time with proposals that in numerous ways break the sip service > model. if that service model is not acceptable to 3gpp, then please > destroy it on your own mailing lists. > A little off the topic of this particular email, but it gives such a good lead in.... You, and many others keep referring to walled gardens. In todays world of "insecurity" do you really think that firewalls and the like are going to dissappear, ever? Even during the migration from IPv4 to IPv6 there is a NAT function....is it going to break SIP??? :^) You know, they (firewalls/private nets/walled gardens) arent only used for NAT (which is where I hear the walled garden comment so often referred to), they actually are used in non nat environments as well for the purpose of protecting assets. Even when installed on a personal computer they often present the same walled garden effect..... As technology advances so do the middleboxes, often with more enabling power to reduce the walled in effect while still protecting the assets. With that said, rather than constantly debunking middleboxes and the like an effort should be made to insure that they are developed in parallel with the standard to insure that SIP a protocol that adds the vulnerability to the firewall, as opposed to the firewall breaking SIP. SIP is a good thing, but you can't berate security in the advancement of it, or it is sure to fail, unless you know of a good, realistic, short term, secure solution to bring it to the masses that the firewall vendors, enterprise, ISP, and home users, and myself are unaware of. In closing, selection of acceptable authentication mechnisms, confidentiality mechanisms, trust mechanisms would be a good thing; SMIME, TLS, Digest whatever. I am sure that each of these has their place in SIP development, depending on client type etc, as with any other type of development there is no "one" perfect silver bullet. Why not make a compromise and include provisions to permit development of each in order to address different UA implementation types? MAY...MAY...MAY....???? While making these provisions why not try to plan for the future, yes many say PKI is an impossibility today, but you know, its really not that far off as a reality....many firewall vendors support many of a PKI's feature-set today, as do client vendors (VPN)... ...perhaps thinking in terms of a policy model, in preparation for X.509 certificates perhaps, for the SIP architecture, wouldnt be a bad idea either. Since SMIME/TLS/SSL all can take advantage of these, as well as the network layer equivalent, IPSec. Chris. > -- 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 daemon@ns.ietf.org Thu Feb 28 03:02:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14145 for ; Thu, 28 Feb 2002 03:02:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA11640 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 03:02:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10201; Thu, 28 Feb 2002 02:34:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10172 for ; Thu, 28 Feb 2002 02:34:01 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13630 for ; Thu, 28 Feb 2002 02:33:57 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g1S7Xwd19950 for ; Thu, 28 Feb 2002 08:33:59 +0100 (MET) Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g1S7Xwk29711 for ; Thu, 28 Feb 2002 08:33:58 +0100 (MET) Received: from mhpaba5c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail-k.mchp.siemens.de with ESMTP id g1S7XxmQ010546 for ; Thu, 28 Feb 2002 08:33:59 +0100 (MET) From: "Steffen Fries" Organization: Siemens AG To: sip@ietf.org Date: Thu, 28 Feb 2002 08:33:50 +0100 MIME-Version: 1.0 Reply-to: steffen.fries@mchp.siemens.de Message-ID: <3C7DEB6E.7468.9DE4A89@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Subject: [Sip] S/MIME in SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hi, by reading the current SIP draft I've got a question. The S/MIME option described in the current bis-08 seems to be only thought for end-to-end usage. Is there any scenario/option where it would be used for securing messages hop-by-hop. If yes, how is this realised technically. For instance when a UA would send a message with S/MIME tunneled authentication and integrity to a Proxy, how does the Proxy determine that he is in charge of checking the integrity of the message and also to calculate an ICV for the next hop? This example assumes that all entieties have the appropriate certificates available. Regards Steffen ___________________________________________________________ Steffen Fries, Siemens AG, CT IC 3 Otto-Hahn-Ring 6, D-81730 Munich, Germany Phone: (+49) 89 / 636-53403, Fax : (+49) 89 / 636-48000 Email: Steffen.Fries@mchp.siemens.de ___________________________________________________________ This email was written on 100% recycled bytes! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Feb 28 03:09:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14207 for ; Thu, 28 Feb 2002 03:09:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA12040 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 03:09:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10821; Thu, 28 Feb 2002 02:53:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10788 for ; Thu, 28 Feb 2002 02:53:06 -0500 (EST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13951 for ; Thu, 28 Feb 2002 02:53:02 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g1S7r3p17367; Thu, 28 Feb 2002 08:53:03 +0100 (MET) Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g1S7r2k11143; Thu, 28 Feb 2002 08:53:02 +0100 (MET) Received: from mhpaba5c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail-k.mchp.siemens.de with ESMTP id g1S7r4mQ010816; Thu, 28 Feb 2002 08:53:04 +0100 (MET) From: "Steffen Fries" Organization: Siemens AG To: "Peterson, Jon" Date: Thu, 28 Feb 2002 08:52:54 +0100 MIME-Version: 1.0 Subject: RE: [Sip] S/MIME in SIP Reply-to: steffen.fries@mchp.siemens.de CC: sip@ietf.org Message-ID: <3C7DEFE6.24665.9EFC142@localhost> Priority: normal In-reply-to: <70565611B164D511957A001083FCDD5601870111@VA02> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Thast true, TLS is one option, but it relies on the usage of TCP. When TLS is used for hop-by-hop security, also the link between the UA and the Poxy must be TCP (which is still optional in bis08). Steffen From: "Peterson, Jon" To: "'steffen.fries@mchp.siemens.de'" , sip@ietf.org Subject: RE: [Sip] S/MIME in SIP Date sent: Thu, 28 Feb 2002 01:46:50 -0600 > > TLS, among other things, can secure SIP on a hop-by-hop basis. This is > discussed in the Security Considerations of bis08. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Steffen Fries [mailto:steffen.fries@mchp.siemens.de] > > Sent: Wednesday, February 27, 2002 11:34 PM > > To: sip@ietf.org > > Subject: [Sip] S/MIME in SIP > > > > > > Hi, > > > > by reading the current SIP draft I've got a question. > > The S/MIME option described in the current bis-08 seems to be > > only thought for end-to-end usage. > > Is there any scenario/option where it would be used for > > securing messages hop-by-hop. If yes, how is this realised > > technically. > > For instance when a UA would send a message with S/MIME > > tunneled authentication and integrity to a Proxy, how does the > > Proxy determine that he is in charge of checking the integrity > > of the message and also to calculate an ICV for the next hop? > > This example assumes that all entieties have the appropriate > > certificates available. > > > > Regards > > Steffen > > ___________________________________________________________ > > Steffen Fries, Siemens AG, CT IC 3 > > Otto-Hahn-Ring 6, D-81730 Munich, Germany > > Phone: (+49) 89 / 636-53403, Fax : (+49) 89 / 636-48000 > > Email: Steffen.Fries@mchp.siemens.de > > ___________________________________________________________ > > This email was written on 100% recycled bytes! > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Thu Feb 28 03:16:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14304 for ; Thu, 28 Feb 2002 03:16:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA12325 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 03:16:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10699; Thu, 28 Feb 2002 02:47:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10668 for ; Thu, 28 Feb 2002 02:47:39 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13899 for ; Thu, 28 Feb 2002 02:47:35 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1S7l6822483; Thu, 28 Feb 2002 02:47:06 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 01:47:01 -0600 Message-ID: <70565611B164D511957A001083FCDD5601870111@VA02> From: "Peterson, Jon" To: "'steffen.fries@mchp.siemens.de'" , sip@ietf.org Subject: RE: [Sip] S/MIME in SIP Date: Thu, 28 Feb 2002 01:46:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org TLS, among other things, can secure SIP on a hop-by-hop basis. This is discussed in the Security Considerations of bis08. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Steffen Fries [mailto:steffen.fries@mchp.siemens.de] > Sent: Wednesday, February 27, 2002 11:34 PM > To: sip@ietf.org > Subject: [Sip] S/MIME in SIP > > > Hi, > > by reading the current SIP draft I've got a question. > The S/MIME option described in the current bis-08 seems to be > only thought for end-to-end usage. > Is there any scenario/option where it would be used for > securing messages hop-by-hop. If yes, how is this realised > technically. > For instance when a UA would send a message with S/MIME > tunneled authentication and integrity to a Proxy, how does the > Proxy determine that he is in charge of checking the integrity > of the message and also to calculate an ICV for the next hop? > This example assumes that all entieties have the appropriate > certificates available. > > Regards > Steffen > ___________________________________________________________ > Steffen Fries, Siemens AG, CT IC 3 > Otto-Hahn-Ring 6, D-81730 Munich, Germany > Phone: (+49) 89 / 636-53403, Fax : (+49) 89 / 636-48000 > Email: Steffen.Fries@mchp.siemens.de > ___________________________________________________________ > This email was written on 100% recycled bytes! > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Thu Feb 28 03:40:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14623 for ; Thu, 28 Feb 2002 03:40:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA13789 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 03:40:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12504; Thu, 28 Feb 2002 03:22:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12468 for ; Thu, 28 Feb 2002 03:22:04 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14374 for ; Thu, 28 Feb 2002 03:22:00 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2708B6A904; Thu, 28 Feb 2002 10:21:57 +0200 (EET) Message-ID: <3C7DE8F1.8040203@piuha.net> Date: Thu, 28 Feb 2002 10:23:13 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Peterson, Jon" Cc: "'steffen.fries@mchp.siemens.de'" , sip@ietf.org Subject: Re: [Sip] S/MIME in SIP References: <70565611B164D511957A001083FCDD5601870111@VA02> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon wrote: > TLS, among other things, can secure SIP on a hop-by-hop basis. This is > discussed in the Security Considerations of bis08. We seem to have relatively good coverage of hop-by-hop and end-to-end, but sometimes I miss more functionality for end-to-middle, such as the ability for me to encrypt something and deliver it to my home / home operator proxy without evil intervening proxies (e.g. the P-CSCF) seeing it... I know this can be done with B2BUAs but I'm told it isn't always so desireable to take the B2BUA approach either (see Dean's heart surgery analogy in some recent thread about that). Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Feb 28 04:39:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15480 for ; Thu, 28 Feb 2002 04:39:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16772 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 04:39:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15618; Thu, 28 Feb 2002 04:19:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15590 for ; Thu, 28 Feb 2002 04:19:20 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15251 for ; Thu, 28 Feb 2002 04:19:16 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA25523; Thu, 28 Feb 2002 10:19:17 +0100 (MET) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA04211; Thu, 28 Feb 2002 10:19:07 +0100 (MET) Received: by mchh159e.mch.pn.siemens.de with Internet Mail Service (5.5.2653.19) id <1M5GC13X>; Thu, 28 Feb 2002 10:19:19 +0100 Message-ID: <5B4D0C5BA65ECA46969C1419122317E608179A@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Cullen Jennings'" , sip@ietf.org Subject: RE: [Sip] Irrelevant nit on call-id and IPs Date: Thu, 28 Feb 2002 10:19:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Moreover, the IP address has been removed from the Call-ID in line 467 (200 OK) but not in line 381 (INVITE). | -----Original Message----- | From: Cullen Jennings [mailto:fluffy@cisco.com] | Sent: 28 February 2002 01:46 | To: sip@ietf.org | Subject: [Sip] Irrelevant nit on call-id and IPs | | | | Bis 8, line 399. | | Thought we had decided to not encourage people to use IP | address to build | the Call-ID. | | | _______________________________________________ | Sip mailing list https://www1.ietf.org/mailman/listinfo/sip | This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Thu Feb 28 04:44:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15564 for ; Thu, 28 Feb 2002 04:44:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17016 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 04:44:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15552; Thu, 28 Feb 2002 04:17:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15508 for ; Thu, 28 Feb 2002 04:17:40 -0500 (EST) Received: from smtp01ffm.de.uu.net (smtp01ffm.de.uu.net [192.76.144.150]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15183 for ; Thu, 28 Feb 2002 04:17:36 -0500 (EST) Received: from penelope.materna.de (penelope.materna.de [193.96.115.65]) by smtp01ffm.de.uu.net (5.5.5/5.5.5) with ESMTP id KAA03342; Thu, 28 Feb 2002 10:18:10 +0100 (MET) Received: from ganymed (ganymed.materna.de [139.2.34.141]) by penelope.materna.de (Postfix) with ESMTP id ABC6467ED; Thu, 28 Feb 2002 10:17:35 +0100 (MET) Received: from pdc-gp.materna.de (actually localhost) by ganymed with Internet with ESMTP; Thu, 28 Feb 2002 10:17:36 +0100 Received: by pdc-gp.materna.de with Internet Mail Service (5.5.2653.19) id <16P6TRMB>; Thu, 28 Feb 2002 10:17:34 +0100 Message-ID: <73B855B4F72FD411A1CF009027B113C40199F6D6@taxis.materna.de> From: thomas.nagel@materna.de To: sip@ietf.org Cc: dean.willis@softarmor.com Date: Thu, 28 Feb 2002 10:17:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Let's discuss a change in the bis. WAS: Why Proxies are Good and B2BUAs May Not Be Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello Dean, thanks for your comments. I'd like to add some more thoughts. Dean says: > As the SIP specification does > specify the transfer encoding at layer 3, so it's an open > question whether a different encoding would still be > "standard". But one could theoretically > preserve feature transparency over such a coding, so a > "proxy" in this mode is not completely ridiculous. Right. I would like to add just a general idea. ;) In my view it may have been sensible that time to include an encapsulation in the SIP RFC, but in the long run it does more hinder further evolution of SIP in an ever changing protocol world. A longlasting successful protocol should be able to interchange mappings (or encodings, encapsulations) of it's respective lower layers if need arises. SIP-architects could have looked at the way PPP was designed for example, e.g. the layering. (Not a perfect example of course, but it gives hints ;) SO, as it already has been defined as it is, I would like to formaly suggest a change in the RFC-bis ;) Let's put it that way, that the encoding of the SIP verbs and the needed 'header fields' can be changed, as long as all values are transmitted in their proper sequence without alteration by a lower layer. Also, the lower layer protocols must be capable of transporting MIME-compliant payloads with the SIP messages. One example of an alternative encapsulation would then be an XML-encoding transmitted over standard HTTP. Others are possible. .. Phew, a bold step :;) > > > Essentially, anything that does SIP->somethingelse->SIP can > > > be considered a > > > form of B2BUA. > > No. Only *if* it changes the data. > > Or if it changes the timing characteristics, etc. You are right, but are timing characteristics defined sufficiently complete in the RFC at all? What has been defined, at least what I know, is not protocol-dependant. Do you agree? [The only timing component relating to the transport layer is the usage of UDP instead of TCP, but that is an implicit feature of UDP, and TCP is at least allowed as well.] As a sidenote, has the proposed usage of the Stream Control Protocol (i do hope I spelled it right ;) ever been checked against this? At least not that I've read about... > > >Feature transparency across such a stucture > > > requires a fully > > > homomorphic mapping between SIP and somethingelse. > > It does not map SIP to something else, > > it only encapsulates the SIP header fields into XML-tags. > > So what does it do if it sees a SIP message type that it's never seen > before? The SIP messages must be encapsulated in a way that does not define values of higher layers in a lower one. SO, you would NOT use code like this: --- --- but rather like this: --- --- > > . . . . > The semantics of SIP, in general, are a bit strained > by the REGISTER process. That's the fate of an all-purpose-protocol ;) In a way any, SIP-semantics are also non-orthogonal since user-data can be sent in-band ;) ... > Actually, there is a SIP Servlet specification. Oh, where can I find that? [And, may I add, where is a Servlet-Container supporting it? As far as I've found up to now, there is not a single application server of servlet container around that really supports Non-HTTP servlets. ] Best greetings, Thomas Nagel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Feb 28 05:27:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16295 for ; Thu, 28 Feb 2002 05:27:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA19077 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 05:27:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17960; Thu, 28 Feb 2002 05:02:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17927 for ; Thu, 28 Feb 2002 05:01:57 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15822 for ; Thu, 28 Feb 2002 05:01:52 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA22233; Thu, 28 Feb 2002 11:01:51 +0100 (MET) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA17195; Thu, 28 Feb 2002 11:01:42 +0100 (MET) Received: by mchh159e.mch.pn.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 11:01:32 +0100 Message-ID: <5B4D0C5BA65ECA46969C1419122317E608179B@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: Tan Ya-Ching ICM N PG U ID A 1 , "'Cullen Jennings'" , sip@ietf.org Subject: RE: [Sip] Irrelevant nit on call-id and IPs Date: Thu, 28 Feb 2002 11:01:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org To be more exact, the Call-ID's in the messages for this example do not match. It contains a FQDN of the softphone in the INVITE, but not in the 200 OK. And if Section 24.2 shows the full details of all the messages of this example, the Call-ID should be the same too. | -----Original Message----- | From: Tan Ya-Ching ICM N PG U ID A 1 | Sent: 28 February 2002 10:19 | To: 'Cullen Jennings'; sip@ietf.org | Subject: RE: [Sip] Irrelevant nit on call-id and IPs | | | Moreover, the IP address has been removed from the Call-ID in | line 467 (200 | OK) but not in line 381 (INVITE). | | | | -----Original Message----- | | From: Cullen Jennings [mailto:fluffy@cisco.com] | | Sent: 28 February 2002 01:46 | | To: sip@ietf.org | | Subject: [Sip] Irrelevant nit on call-id and IPs | | | | | | | | Bis 8, line 399. | | | | Thought we had decided to not encourage people to use IP | | address to build | | the Call-ID. | | | | | | _______________________________________________ | | Sip mailing list https://www1.ietf.org/mailman/listinfo/sip | | This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Thu Feb 28 06:48:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17213 for ; Thu, 28 Feb 2002 06:48:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA22770 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 06:48:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21488; Thu, 28 Feb 2002 06:20:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21457 for ; Thu, 28 Feb 2002 06:20:47 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16921 for ; Thu, 28 Feb 2002 06:20:41 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SBKrZ28871 for ; Thu, 28 Feb 2002 13:20:53 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 13:20:44 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 13:20:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 28 Feb 2002 13:20:44 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB777908E@esebe019.NOE.Nokia.com> Thread-Topic: Expires in 2xx response to SUBSCRIBE (Events-04) Thread-Index: AcHASfYvR9RVz9BZTOenVGR/mYDINA== To: , X-OriginalArrivalTime: 28 Feb 2002 11:20:44.0252 (UTC) FILETIME=[F66C41C0:01C1C049] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA21458 Subject: [Sip] Expires in 2xx response to SUBSCRIBE (Events-04) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit After a discussion with Robert Sparks here on the list about what an Expires header actually means in a 200 response for a REGISTER. It was concluded that it has no meaning. So, the following extract from section 4.1.6.1 in the events draft is wrong: The "Expires" values present in SUBSCRIBE 200-class responses behave in the same way as they do in REGISTER responses: the server MAY shorten the interval, but MUST NOT lengthen it. REGISTER responses now rely on expires-param in a Contact header. Below is an extract of the discussion Sparks and I had: >>Yes - the Expires header field in a 200 response to a REGISTER request is >>allowed. It also has no meaning with respect to the Contacts in >>the response >>since each provided Contact MUST contain an ;expires= parameter. >>(Note to casual readers - this is a statement about the _response_, not >> the REGISTER request) >> >>So - help me understand your original question. Is it "why don't you allow >>the "use the expires parameter if present, otherwise use the >>Expires header >>value in REGISTER responses like you do in REGISTER requests?". >> > > Yes, that was exactly what I asked. If its not so, what does an Expires > header in a 200 OK for a REGISTER mean? As I note above, with the current text an Expire header field has no meaning if it appears in a 200 response to a REGISTER request. So? Regards, Hisham Khartabil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Feb 28 07:37:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19522 for ; Thu, 28 Feb 2002 07:37:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25664 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 07:37:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24172; Thu, 28 Feb 2002 07:08:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24142 for ; Thu, 28 Feb 2002 07:08:45 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18418 for ; Thu, 28 Feb 2002 07:08:42 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1SC8hh14184 for ; Thu, 28 Feb 2002 07:08:43 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Feb 2002 12:08:42 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00481D999@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: sip@ietf.org Date: Thu, 28 Feb 2002 12:08:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Question regarding event-04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Sorry to ask this questioin again if it was answered before. In 4.1.6.1, it says that the notifier sends 202 if it can not accepte the subscribe immediately. In 4.1.6.2, it says that "Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY message immediately to communicate the current resource state to the subscriber." and Note that a NOTIFY message is always sent immediately after any 200-class response to a SUBSCRIBE request, regardless of whether the subscription has already been authorized. These sentences confuse me. So what is the real criteria to send the NOTIFY? It is upon accepting a subscription or sent immediately unconditionally? What happen if I receives a 202 and then gets a NOTIFY immediately, at that moment, my subscribtion is accepted or not? Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Feb 28 07:40:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19691 for ; Thu, 28 Feb 2002 07:40:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25828 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 07:40:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24700; Thu, 28 Feb 2002 07:21:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24669 for ; Thu, 28 Feb 2002 07:21:23 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18917 for ; Thu, 28 Feb 2002 07:21:18 -0500 (EST) Received: (qmail 20840 invoked from network); 28 Feb 2002 12:23:57 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 28 Feb 2002 12:23:57 -0000 Received: from stake.com (unknown [10.50.1.52]) by cam-relay.atstake.com (Postfix) with SMTP id 1AE8422817 for ; Thu, 28 Feb 2002 07:20:58 -0500 (EST) Message-ID: <3C7E20E2.4080704@stake.com> Date: Thu, 28 Feb 2002 12:21:54 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: SIP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Multiple 200 OKs for an INVITE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Section 13.2.2.4 2xx responses (for INVITE): "Multiple 2xx responses may arrive at a UAC for a single INVITE request...each response is distinguished by the tag parameter in the TO header field and each represents a distinct dialog identifier". In this phase there is no tag in the 'To' field held in the 'state' if I understand this correctly. Actually the 200OK is the first message to carry the value back from a UAS. "If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the "confirmed" atate..." Ok, but what will happen if we receive in the same time two 200OKs from two different UASs? The state is still not "confirmed"... Is this is first arrived first processed therefore won situation? Also - after the first 200OK will be processed, the state will change to "confirmed" and further 200OKs will not match a dialog identifier any more... Thoughts? -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Feb 28 08:14:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21175 for ; Thu, 28 Feb 2002 08:14:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA27641 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 08:14:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25962; Thu, 28 Feb 2002 07:43:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25917 for ; Thu, 28 Feb 2002 07:43:05 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19798 for ; Thu, 28 Feb 2002 07:43:01 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1SCgrB22327; Thu, 28 Feb 2002 13:42:53 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1SCgrmK009224; Thu, 28 Feb 2002 14:42:53 +0200 (EET) Message-ID: <3C7E2609.1ACFBA13@lmf.ericsson.se> Date: Thu, 28 Feb 2002 14:43:53 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ofir Arkin CC: SIP Subject: Re: [Sip] Multiple 200 OKs for an INVITE References: <3C7E20E2.4080704@stake.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Ofir, If you receive multiple 200 OK, you would normally accept the first. Then you would ACK/BYE any other 200OK you may receive. Regards, Christer Holmberg Ericsson Finland Ofir Arkin wrote: > Section 13.2.2.4 2xx responses (for INVITE): > > "Multiple 2xx responses may arrive at a UAC for a single INVITE > request...each response is distinguished by the tag parameter in the TO > header field and each represents a distinct dialog identifier". > > In this phase there is no tag in the 'To' field held in the 'state' if I > understand this correctly. Actually the 200OK is the first message to > carry the value back from a UAS. > > "If the dialog identifier in the 2xx response matches the dialog > identifier of an existing dialog, the dialog MUST be transitioned to the > "confirmed" atate..." > > Ok, but what will happen if we receive in the same time two 200OKs from > two different UASs? The state is still not "confirmed"... > > Is this is first arrived first processed therefore won situation? > > Also - after the first 200OK will be processed, the state will change to > "confirmed" and further 200OKs will not match a dialog identifier any > more... > > Thoughts? > > -- > Ofir Arkin > Managing Security Architect > @stake, Limited. > http://www.atstake.com > email: > ofir@stake.com > Tel: > +44 (0) 207 495 7002 > Fax: > +44 (0) 207 495 7062 > Mobile: +44 (0) 779 630 8632 > > ----------------------------- > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, re transmission, 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 any computer. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@ns.ietf.org Thu Feb 28 08:27:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21795 for ; Thu, 28 Feb 2002 08:27:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28503 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 08:27:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26971; Thu, 28 Feb 2002 08:01:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26940 for ; Thu, 28 Feb 2002 08:01:51 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20613 for ; Thu, 28 Feb 2002 08:01:47 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A9FE1A3001D2; Thu, 28 Feb 2002 08:00:46 -0500 Message-ID: <006301c1c057$c734d260$2300000a@acmepacket.com> From: "Bob Penfield" To: "Ofir Arkin" , "SIP" References: <3C7E20E2.4080704@stake.com> Subject: Re: [Sip] Multiple 200 OKs for an INVITE Date: Thu, 28 Feb 2002 07:59:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Ofir Arkin" > Section 13.2.2.4 2xx responses (for INVITE): > > "Multiple 2xx responses may arrive at a UAC for a single INVITE > request...each response is distinguished by the tag parameter in the TO > header field and each represents a distinct dialog identifier". > > In this phase there is no tag in the 'To' field held in the 'state' if I > understand this correctly. Actually the 200OK is the first message to > carry the value back from a UAS. The arrival of a response from a UAS (1xx or 2xx) with a To-tag establishes a dialog. For a 1xx, it is an "early" dialog. For a 2xx it is a "confirmed" dialog. If you get responses (with To-tags) from multiple UASs, you have multiple dialogs. > > "If the dialog identifier in the 2xx response matches the dialog > identifier of an existing dialog, the dialog MUST be transitioned to the > "confirmed" atate..." > > Ok, but what will happen if we receive in the same time two 200OKs from > two different UASs? The state is still not "confirmed"... Each 200 OK represents/established a separate dialog. An existing dialog would be matched if the UAS sending the 200-OK has previously sent a 1xx with a To-tag. These pre-existing dialogs would be in the "early" state. The matched dialog would transition from "early" to "confirmed" state. Any other "early" dialogs would remain "early" dialogs. > > Is this is first arrived first processed therefore won situation? This is up to the implementation and local policy in the UAC. It may choose to keep all dialogs up (in which case it would have to mix the streams) or it could choose to keep one and send BYE to all the rest (after ACKing the 200 OK). I would imagine that a basic SIP Phone would keep the first and send BYE to all the rest. > > Also - after the first 200OK will be processed, the state will change to > "confirmed" and further 200OKs will not match a dialog identifier any > more... They won't match that dialog, but might match other "early" dialogs or establish a new dialog. If the UAC does not want to keep it. It ACKs and then sends a BYE. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 28 08:46:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22500 for ; Thu, 28 Feb 2002 08:46:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA29832 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 08:46:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27526; Thu, 28 Feb 2002 08:12:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27495 for ; Thu, 28 Feb 2002 08:12:07 -0500 (EST) Received: from zctfs063.nortelnetworks.com (h90s131a237n47.user.nortelnetworks.com [47.237.131.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21064 for ; Thu, 28 Feb 2002 08:12:03 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1SDBMH00387; Thu, 28 Feb 2002 14:11:22 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 13:11:29 -0000 Message-ID: From: "Mark Watson" To: "'Flemming Andreasen'" , "'sip@ietf.org'" Date: Thu, 28 Feb 2002 13:11:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C059.69AA37F0" Subject: [Sip] RE: Remote-Party-Id extensibility Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C059.69AA37F0 Content-Type: text/plain Flemming, all, My opinion is that 95% of the value of the Remote-Party-ID header is in this extensibility. The extensibility provides a general purpose platform for handling of identity information which is subject to privacy restrictions (in the applicable environment), because we can add new types of identity and be sure that the privacy handling will be applied to these even if the actual identity type is not recognised by downstream systems. If you remove this extensibility, you might as well define separate headers for each identity ('Private-Calling-Party:' etc.), with separate Require: tags, and then any SLAs between Service Providers with respect to privacy would have to list the headers that were guaranteed to be respected. Such SLAs would need extension every time new identities were added. As it stands, we need only include support of the 'privacy' tag in the SLAs. I can promise you that the lack of such extensibility in the PSTN has be a nightmare. It was predicated on the assumption that we know a priori that a given set of identity parameters are sufficient for present and future purposes - an assumption which has proved wrong time and time again. I would also hope that the envisioned future privacy support for the pure Internet environment could be as backwards-compatible with Remote-Party-ID as possible cf Dean's ideas about signing the RPID etc. If we rule out extensibility now, we tie our hands somewhat with regards to this future solution. I would prefer to have the extensibiity left as in privacy-02. Regards, Mark > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: 28 February 2002 02:42 > To: sip@ietf.org > Subject: Remote-Party-Id extensibility > > > Please read and comment quickly: > > As you may know, the privacy-04 draft will contain an applicability > statement that points out the environments in which the draft may be > usable. Suffice it to say, that these environments do not include the > general Internet at large, but rather resemble service provider like > models with transitive trust relationships. > > Presently, the Remote-Party-Id header field consists of a bunch of > parameters, each of which is extensible. The concern that has been > raised is, that by allowing for all this extensibility, we are opening > ourselves up to duplicating existing (and perhaps future and more > general) headers and also to go beyond the applicability statement. It > has therefore been suggested, that we remove all this > extensibility from > Remote-Party-ID, except for the rpi-privacy parameter. In essence, we > would prevent the Remote-Party-Id header from containing any kind of > identity (or other) information not currently defined in the > draft. As a > consequence of that, the Nature of Party indication provided > in Appendix > A would be removed from the draft as well. Instead, the idea > would be to > provide these as part of a tel-url. > > > Your prompt feedback on this would be appreciated. > > > Thanks > > Flemming > > -- > Flemming Andreasen > Cisco Systems > > > ------_=_NextPart_001_01C1C059.69AA37F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Remote-Party-Id extensibility

Flemming, all,

My opinion is that 95% of the value of the = Remote-Party-ID header is in this extensibility.

The extensibility provides a general purpose platform = for handling of identity information which is subject to privacy = restrictions (in the applicable environment), because we can add new = types of identity and be sure that the privacy handling will be applied = to these even if the actual identity type is not recognised by = downstream systems.

If you remove this extensibility, you might as well = define separate headers for each identity ('Private-Calling-Party:' = etc.), with separate Require: tags, and then any SLAs between Service = Providers with respect to privacy would have to list the headers that = were guaranteed to be respected. Such SLAs would need extension every = time new identities were added.

As it stands, we need only include support of the = 'privacy' tag in the SLAs.

I can promise you that the lack of such extensibility = in the PSTN has be a nightmare. It was predicated on the assumption = that we know a priori that a given set of identity parameters are = sufficient for present and future purposes - an assumption which has = proved wrong time and time again.

I would also hope that the envisioned future privacy = support for the pure Internet environment could be as = backwards-compatible with Remote-Party-ID as possible cf Dean's ideas = about signing the RPID etc. If we rule out extensibility now, we tie = our hands somewhat with regards to this future solution.

I would prefer to have the extensibiity left as in = privacy-02.

Regards,

Mark


> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]=
> Sent: 28 February 2002 02:42
> To: sip@ietf.org
> Subject: Remote-Party-Id extensibility
>
>
> Please read and comment quickly:
>
> As you may know, the privacy-04 draft will = contain an applicability
> statement that points out the environments in = which the draft may be
> usable. Suffice it to say, that these = environments do not include the
> general Internet at large, but rather resemble = service provider like
> models with transitive trust = relationships.
>
> Presently, the Remote-Party-Id header field = consists of a bunch of
> parameters, each of which is extensible. The = concern that has been
> raised is, that by allowing for all this = extensibility, we are opening
> ourselves up to duplicating existing (and = perhaps future and more
> general) headers and also to go beyond the = applicability statement. It
> has therefore been suggested, that we remove = all this
> extensibility from
> Remote-Party-ID, except for the rpi-privacy = parameter. In essence, we
> would prevent the Remote-Party-Id header from = containing any kind of
> identity (or other) information not currently = defined in the
> draft. As a
> consequence of that, the Nature of Party = indication provided
> in Appendix
> A would be removed from the draft as well. = Instead, the idea
> would be to
> provide these as part of a tel-url.
>
>
> Your prompt feedback on this would be = appreciated.
>
>
> Thanks
>
>         = Flemming
>
> --
> Flemming Andreasen
> Cisco Systems
>
>
>

------_=_NextPart_001_01C1C059.69AA37F0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 28 08:49:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22782 for ; Thu, 28 Feb 2002 08:49:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA29975 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 08:49:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28260; Thu, 28 Feb 2002 08:23:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28156 for ; Thu, 28 Feb 2002 08:23:23 -0500 (EST) Received: from web14107.mail.yahoo.com (web14107.mail.yahoo.com [216.136.172.137]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21639 for ; Thu, 28 Feb 2002 08:23:18 -0500 (EST) Message-ID: <20020228132321.83308.qmail@web14107.mail.yahoo.com> Received: from [216.191.234.70] by web14107.mail.yahoo.com via HTTP; Thu, 28 Feb 2002 05:23:21 PST Date: Thu, 28 Feb 2002 05:23:21 -0800 (PST) From: Mark Taylor Subject: Re: [Sip] Multiple 200 OKs for an INVITE To: SIP In-Reply-To: <85256B6E.00489C09.00@kanmta01.software.mitel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This may be a silly question but multiple INVITES are sent out which cause telephones to ring. Two of these telephones are answered by human beings at the same time and send a 200 OK. One of these telephones is connected to the voice path but the other experiences an immediate hang up. Isn't this extremely rude and will cause major emabarassment to the caller since his name and possibly picture have been dispayed on the receiving device. It could also be considered a form of criminal harrassment to call and imediately hang up on answer. It should be noted that for calls to human beings as oposed to machines that all end points that send a 200K must be conferenced into the connection. > > Subject: Re: [Sip] Multiple 200 OKs for an INVITE > > > > > Hi Ofir, > > If you receive multiple 200 OK, you would normally > accept the first. Then > you would ACK/BYE any other 200OK you may receive. > > Regards, > > Christer Holmberg > Ericsson Finland > > > Ofir Arkin wrote: > > > Section 13.2.2.4 2xx responses (for INVITE): > > > > "Multiple 2xx responses may arrive at a UAC for a > single INVITE > > request...each response is distinguished by the > tag parameter in the TO > > header field and each represents a distinct dialog > identifier". > > > > In this phase there is no tag in the 'To' field > held in the 'state' if I > > understand this correctly. Actually the 200OK is > the first message to > > carry the value back from a UAS. > > > > "If the dialog identifier in the 2xx response > matches the dialog > > identifier of an existing dialog, the dialog MUST > be transitioned to the > > "confirmed" atate..." > > > > Ok, but what will happen if we receive in the same > time two 200OKs from > > two different UASs? The state is still not > "confirmed"... > > > > Is this is first arrived first processed therefore > won situation? > > > > Also - after the first 200OK will be processed, > the state will change to > > "confirmed" and further 200OKs will not match a > dialog identifier any > > more... > > > > Thoughts? > > > > -- > > Ofir Arkin > > Managing Security Architect > > @stake, Limited. > > http://www.atstake.com > > email: > > ofir@stake.com > > Tel: > > +44 (0) 207 495 7002 > > Fax: > > +44 (0) 207 495 7062 > > Mobile: +44 (0) 779 630 8632 > > > > ----------------------------- > > The information transmitted is intended only for > the person or entity to > > which it is addressed and may contain confidential > and/or privileged > > material. Any review, re transmission, > 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 any computer. > > > > _______________________________________________ > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > 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!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.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 daemon@optimus.ietf.org Thu Feb 28 09:10:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23746 for ; Thu, 28 Feb 2002 09:10:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA01306 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 09:10:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29270; Thu, 28 Feb 2002 08:33:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29237 for ; Thu, 28 Feb 2002 08:33:10 -0500 (EST) Received: from uni03mr.unity.ncsu.edu (uni03mr.unity.ncsu.edu [152.1.1.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22031 for ; Thu, 28 Feb 2002 08:33:06 -0500 (EST) Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116]) by uni03mr.unity.ncsu.edu (8.8.8/8.8.8/UR01Feb99) with SMTP id IAA21088; Thu, 28 Feb 2002 08:33:07 -0500 (EST) Message-ID: <00d401c1c05c$757683b0$743c0198@ecew2k.ncsu.edu> From: "Prabhas Sinha" To: "Ofir Arkin" , "SIP" References: <3C7E20E2.4080704@stake.com> Subject: Re: [Sip] Multiple 200 OKs for an INVITE Date: Thu, 28 Feb 2002 08:33:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit If you have drawn some finite state machine for the INVITATION protocol, you will realise that UAC can send many INVITE requests and go to (say) "WAIT FOR INVITE RESPONSE ONLY" state. Provisional responses (1xx) to the INVITE request wont cause the state machine to leave this state. However they would stop the UAC from transmitting the INVITE request further. Now multiple 2xx responses will be primarily due to proxy forking downstream. The UAC will ACK the first 200 OK or even BYE if it doesnt want to talk. The state will obviously change but then UAC should be capable of handling other 200 OK responses which will come to it as a result of forking. Probably UAC might maintain state machine for each possible forked request but then it might not know the amount of forking that has been done. Certainly other 2xx responses needs to be BYEed, how it would be achieved could be an implementation issue. Does it make sense ? Prabhas Research Assistant Dept of Computer Engineering North Carolina State University Raleigh, NC 27695 USA ----- Original Message ----- From: "Ofir Arkin" To: "SIP" Sent: Thursday, February 28, 2002 7:21 AM Subject: [Sip] Multiple 200 OKs for an INVITE > Section 13.2.2.4 2xx responses (for INVITE): > > "Multiple 2xx responses may arrive at a UAC for a single INVITE > request...each response is distinguished by the tag parameter in the TO > header field and each represents a distinct dialog identifier". > > In this phase there is no tag in the 'To' field held in the 'state' if I > understand this correctly. Actually the 200OK is the first message to > carry the value back from a UAS. > > "If the dialog identifier in the 2xx response matches the dialog > identifier of an existing dialog, the dialog MUST be transitioned to the > "confirmed" atate..." > > Ok, but what will happen if we receive in the same time two 200OKs from > two different UASs? The state is still not "confirmed"... > > Is this is first arrived first processed therefore won situation? > > Also - after the first 200OK will be processed, the state will change to > "confirmed" and further 200OKs will not match a dialog identifier any > more... > > Thoughts? > > -- > Ofir Arkin > Managing Security Architect > @stake, Limited. > http://www.atstake.com > email: > ofir@stake.com > Tel: > +44 (0) 207 495 7002 > Fax: > +44 (0) 207 495 7062 > Mobile: +44 (0) 779 630 8632 > > ----------------------------- > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, re transmission, 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 any computer. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org Thu Feb 28 10:09:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27184 for ; Thu, 28 Feb 2002 10:09:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05310 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 10:09:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03433; Thu, 28 Feb 2002 09:43:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03405 for ; Thu, 28 Feb 2002 09:43:38 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25517 for ; Thu, 28 Feb 2002 09:43:33 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SEhiZ27972 for ; Thu, 28 Feb 2002 16:43:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 16:43:35 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 16:43:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 28 Feb 2002 16:43:35 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7779098@esebe019.NOE.Nokia.com> Thread-Topic: NOTIFY behaviour Thread-Index: AcHAZkyBq+tUXWotRuCK6ouAEERsig== To: , X-OriginalArrivalTime: 28 Feb 2002 14:43:35.0403 (UTC) FILETIME=[4CFE83B0:01C1C066] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA03406 Subject: [Sip] NOTIFY behaviour Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Section 4.2.1 states "When present, the body of the NOTIFY request MUST be formatted into one of the body formats specified in the "Accept" header of the corresponding SUBSCRIBE request. This body will contain either the state of the subscribed resource or a pointer to such state in the form of a URI." Is the Accept header mandatory in SUBSCRIBE? INVITE mandates its but say that UAS should be ready to receive Requests without an Accept header. In that case, the spec should state that any extension to the events draft should specify the default content-type just in case the accept header was missing. Section 4.2.2 I believe this section should talk a little about how a NOTIFY is constructed when a SUBSCRIBE with expires 0 is received. specifically the way the subscription-state header is constructed. After all, its the NOTIFY that terminates the dialog, Not the 200 OK to a SUBSCRIBE with expires 0. Regards, Hisham Khartabil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 28 11:03:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00265 for ; Thu, 28 Feb 2002 11:03:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08676 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 11:03:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07407; Thu, 28 Feb 2002 10:43:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07376 for ; Thu, 28 Feb 2002 10:43:55 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29144 for ; Thu, 28 Feb 2002 10:43:51 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1SFiF6Y020205; Thu, 28 Feb 2002 10:44:16 -0500 (EST) Message-ID: <3C7E5018.97744C0D@dynamicsoft.com> Date: Thu, 28 Feb 2002 10:43:20 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sip@ietf.org Subject: Re: [Sip] T4 References: <2038BCC78B1AD641891A0D1AE133DBB7779085@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > All this is fine, but T4 as you define it (Max RRT between request and > response) is too short in my opinion. Perhaps it should be set to a > higher value. 5s? I thought it was maybe too high... what is your reasoning for thinking it is too low? > > The other alternative is for the spec to say that timer K must be reset > after every retransmission. That is not needed. It is easier, implementation wise and specification wise, to do it as specified. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 28 11:45:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03129 for ; Thu, 28 Feb 2002 11:45:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11830 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 11:45:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10003; Thu, 28 Feb 2002 11:26:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09978 for ; Thu, 28 Feb 2002 11:26:51 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01782 for ; Thu, 28 Feb 2002 11:26:46 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1SGOBZq029421; Thu, 28 Feb 2002 11:24:11 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGK53>; Thu, 28 Feb 2002 11:26:18 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36300B5@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Chen, Xin (Xin)'" , sip@ietf.org Subject: RE: [Sip] Question regarding event-04 Date: Thu, 28 Feb 2002 11:26:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Chen, Xin (Xin) [mailto:xchen2@lucent.com] > > Hi, > > Sorry to ask this questioin again if it was answered before. > > In 4.1.6.1, it says that the notifier sends 202 if it can not > accepte the > subscribe immediately. Correct. > In 4.1.6.2, it says that > > "Upon successfully accepting or refreshing a > subscription, > notifiers MUST > send a NOTIFY message immediately to > communicate the current > resource state to the subscriber." Correct. > Note that a NOTIFY message is always sent > immediately after > any 200-class > response to a SUBSCRIBE request, regardless of > whether the > subscription > has already been authorized. Correct. > These sentences confuse me. So what is the real criteria to > send the NOTIFY? > It is upon accepting a subscription or sent immediately > unconditionally? Both. If a notifier does not yet know wheter it can authorize a subscription, it would generally send a 202 response to the INVITE, and a NOTIFY with a "Subscrition-State" header of "pending". Once the subscription is authorized, it would send a second NOTIFY, this time with a "Subscription-State" header of "active". > What happen if I receives a 202 and then gets a NOTIFY > immediately, at that > moment, my subscribtion is accepted or not? You'd need to check the "Subscription-State" header in the NOTIFY to know the answer to that question. Note that I answered the question for the general case. For privacy reasons, SIMPLE treats authorization in a slightly different fashion; see section 6.2 of the events draft. /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 daemon@optimus.ietf.org Thu Feb 28 11:52:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03604 for ; Thu, 28 Feb 2002 11:52:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12330 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 11:52:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10622; Thu, 28 Feb 2002 11:30:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10577 for ; Thu, 28 Feb 2002 11:30:52 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02014 for ; Thu, 28 Feb 2002 11:30:48 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1SGUoh21774; Thu, 28 Feb 2002 10:30:50 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1SGUjo09183; Thu, 28 Feb 2002 10:30:45 -0600 (CST) Received: from lmf.ericsson.se (rmt160160.am.ericsson.se [138.85.160.160]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA03943; Thu, 28 Feb 2002 10:30:42 -0600 (CST) Message-ID: <3C7E5B62.14F52B25@lmf.ericsson.se> Date: Thu, 28 Feb 2002 18:31:30 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ofir Arkin CC: SIP Subject: Re: [Sip] Multiple 200 OKs for an INVITE References: <3C7E20E2.4080704@stake.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ofir Arkin wrote: > > Section 13.2.2.4 2xx responses (for INVITE): > > "Multiple 2xx responses may arrive at a UAC for a single INVITE > request...each response is distinguished by the tag parameter in the TO > header field and each represents a distinct dialog identifier". > > In this phase there is no tag in the 'To' field held in the 'state' if I > understand this correctly. Actually the 200OK is the first message to > carry the value back from a UAS. > > "If the dialog identifier in the 2xx response matches the dialog > identifier of an existing dialog, the dialog MUST be transitioned to the > "confirmed" atate..." > > Ok, but what will happen if we receive in the same time two 200OKs from > two different UASs? The state is still not "confirmed"... > > Is this is first arrived first processed therefore won situation? > > Also - after the first 200OK will be processed, the state will change to > "confirmed" and further 200OKs will not match a dialog identifier any > more... > You are talking about the state of the INVITE transaction. Take into account that the ACK for a 2xx response is not part of the INVITE transaction, but a transaction by itself. Therefore, it is handled by the TU. Further 2xx resposes for the INVITE will be also passed to the TU. Regards, Gonzalo > Thoughts? > > -- > Ofir Arkin > Managing Security Architect > @stake, Limited. > http://www.atstake.com > email: > ofir@stake.com > Tel: > +44 (0) 207 495 7002 > Fax: > +44 (0) 207 495 7062 > Mobile: +44 (0) 779 630 8632 > > ----------------------------- > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, re transmission, 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 any computer. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Thu Feb 28 12:02:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04393 for ; Thu, 28 Feb 2002 12:02:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14302 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 12:02:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11003; Thu, 28 Feb 2002 11:33:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10973 for ; Thu, 28 Feb 2002 11:32:56 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02172 for ; Thu, 28 Feb 2002 11:32:50 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1SGU9Zq029508; Thu, 28 Feb 2002 11:30:10 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <14NNGK5V>; Thu, 28 Feb 2002 11:32:15 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36300B6@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Chiou, Mark'" , sip@ietf.org Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] RE: [Sip] draft-ietf-sip-events-04; Questions Date: Thu, 28 Feb 2002 11:32:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Chiou, Mark [mailto:MChiou@Santera.com] > > 1. Why the Contact header is mandatory for SUBSCRIBER and > NOTIFY? If the Contact is not applicable to these methods, > then "-" should be applied to R, 1xx, 2xx, 3xx, and 485. Contact headers form an important part of the route. This behavior mirrors that of the bis draft. > 2. I don't think 3xx is applicable to these two methods, such > that contact 3xx should have "-" instead of "o". 3xx responses are applicable to all methods, and there's nothing that an extension can do about it. Redirect servers will always redirect unknown methods. I could also argue that 3xx responses can be quite useful for SUBSCRIBE, with some fairly compelling examples, but the above fact makes it a rather moot point. /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 daemon@optimus.ietf.org Thu Feb 28 12:16:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05636 for ; Thu, 28 Feb 2002 12:16:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15806 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 12:16:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11882; Thu, 28 Feb 2002 11:45:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11849 for ; Thu, 28 Feb 2002 11:45:53 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03165 for ; Thu, 28 Feb 2002 11:45:48 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1SGhDZq029758; Thu, 28 Feb 2002 11:43:13 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 11:45:20 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36300B7@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Adam Roach , sip@ietf.org Date: Thu, 28 Feb 2002 11:45:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: NOTIFY behaviour Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Section 4.2.1 states > > Is the Accept header mandatory in SUBSCRIBE? INVITE mandates > its but say that UAS should be ready to receive Requests > without an Accept header. In that case, the spec should state > that any extension to the events draft should specify the > default content-type just in case the accept header was missing. INVITE has that behavior for backwards compatibility with INVITE behavior in RFC 2543. SUB/NOT isn't shackled to providing backwards compatibility with a previous specification. > Section 4.2.2 > I believe this section should talk a little about how a > NOTIFY is constructed when a SUBSCRIBE with expires 0 is > received. specifically the way the subscription-state header > is constructed. After all, its the NOTIFY that terminates the > dialog, Not the 200 OK to a SUBSCRIBE with expires 0. Section 4.2.2 refers to section 4.2.4 on the topic (since there's no reason to duplicate the description of "Subscription-State" values and the processing is far more relevant to subscriber implementation than notifier implementation). As far as I can tell, 4.2.4 is fairly exhaustive in its description of how to form this header. The Cliff's notes answer to your specific question is in section 4.3.6: Note that the NOTIFY messages triggered by SUBSCRIBE messages with "Expires" headers of 0 will contain a "Subscription-State" value of "terminated", and a "reason" parameter of "timeout". I'd like to thank you very much for taking the time to look over the document -- but working group last call expired back on the 19th, and the document is now in a semi-static state awaiting its presentation by the ADs to the IESG. Unless someone discovers a fatal flaw, the document is effectively frozen. /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 daemon@optimus.ietf.org Thu Feb 28 12:23:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06186 for ; Thu, 28 Feb 2002 12:23:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16336 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 12:23:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12665; Thu, 28 Feb 2002 11:58:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12635 for ; Thu, 28 Feb 2002 11:58:36 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04021 for ; Thu, 28 Feb 2002 11:58:32 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id DC1F81E046; Thu, 28 Feb 2002 11:58:35 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA11413; Thu, 28 Feb 2002 11:58:32 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id LAA96111; Thu, 28 Feb 2002 11:57:59 -0500 (EST) Date: Thu, 28 Feb 2002 11:57:59 -0500 (EST) Message-Id: <200202281657.LAA96111@fish.research.att.com> To: adam@dynamicsoft.com Cc: sip@ietf.org, hisham.khartabil@nokia.com Subject: [Sip] RE: NOTIFY behaviour Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Adam Roach wrote: > I'd like to thank you very much for taking the time to look over > the document -- but working group last call expired back on the > 19th, and the document is now in a semi-static state awaiting its > presentation by the ADs to the IESG. Unless someone discovers a > fatal flaw, the document is effectively frozen. On Feb 22 the IETF-wide last-call was announced for events-03, along with 2543bis-08, 100rel-05, and srv-05. So I think the comment period is still open, but possibly they should be Cc'd to ietf@ietf.org. Bill Marshall wtm@research.att.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 daemon@optimus.ietf.org Thu Feb 28 12:29:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06757 for ; Thu, 28 Feb 2002 12:29:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16916 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 12:29:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15288; Thu, 28 Feb 2002 12:10:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15258 for ; Thu, 28 Feb 2002 12:10:47 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05176 for ; Thu, 28 Feb 2002 12:10:42 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A495892A01D2; Thu, 28 Feb 2002 12:10:45 -0500 Message-ID: <009901c1c07a$b10c4900$2300000a@acmepacket.com> From: "Bob Penfield" To: "Mark Taylor" , "SIP" References: <20020228132321.83308.qmail@web14107.mail.yahoo.com> Subject: Re: [Sip] Multiple 200 OKs for an INVITE Date: Thu, 28 Feb 2002 12:09:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Mark Taylor" > > This may be a silly question but multiple INVITES are > sent out which cause telephones to ring. Two of these > telephones are answered by human beings at the same > time and send a 200 OK. One of these telephones is > connected to the voice path but the other experiences > an immediate hang up. > > Isn't this extremely rude and will cause major > emabarassment to the caller since his name and > possibly picture have been dispayed on the receiving > device. It could also be considered a form of criminal > harrassment to call and imediately hang up on answer. I think it is a rather common occurance that you pick up a phone and say hello and noone is there because they decided the call was a mistake or got tired of waiting for it to answer. It happens to me quite often, particularly if I don't pick up for 3 or 4 rings. I should also point out that proxies are required to CANCEL the other branches when one of them answers. Therefore, the other unanswered phones would likely stop ringing with a second or two. You might consider it rude, but the reason that more than one phone rang is because a user wanted all those phones to ring when he/she got called. The theory being that the user would answer the phone he/she is next to and there would be noone next to the other devices. However, some polite person might decide they want to answer the user's unattended phone for them. > > It should be noted that for calls to human beings as > oposed to machines that all end points that send a > 200K must be conferenced into the connection. This is not always possible, particularly on a small device with limited resources. cheers, (-:bob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 28 12:33:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06977 for ; Thu, 28 Feb 2002 12:33:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17421 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 12:33:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15862; Thu, 28 Feb 2002 12:17:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15838 for ; Thu, 28 Feb 2002 12:17:46 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05665 for ; Thu, 28 Feb 2002 12:17:40 -0500 (EST) Received: (qmail 22810 invoked from network); 28 Feb 2002 17:20:19 -0000 Received: from softdnserror (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 28 Feb 2002 17:20:19 -0000 Received: from stake.com (unknown [10.50.1.52]) by cam-relay.atstake.com (Postfix) with SMTP id 6EA6222819; Thu, 28 Feb 2002 12:14:24 -0500 (EST) Message-ID: <3C7E65AB.2080006@stake.com> Date: Thu, 28 Feb 2002 17:15:23 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Sparks Cc: SIP Subject: Re: [Sip] Question about Section 12.2 Requests within a Dialog References: <3C7D29F1.4080401@stake.com> <1014837295.1201.20.camel@rjs.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit What 'state' information does this change? For example if I send a Re-INVITE within a dialog what 'state' information will the Re-INVITE change? >>Second Question: >>Why this might change the target URI? >>I must admit that the target refresh thing got me really confused... >> > > This mechanism allows an endpoint to change the URI it wants to be > handed in future requests within this dialog. This can be used as a > place to store state for future requests. The original proponents > planned to use this as part of the mechanics to deal with mobility > (address mobility in particular). I don't believe those ideas have > been fleshed out. -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 28 12:34:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07088 for ; Thu, 28 Feb 2002 12:34:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17460 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 12:34:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15910; Thu, 28 Feb 2002 12:18:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15881 for ; Thu, 28 Feb 2002 12:18:02 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05717 for ; Thu, 28 Feb 2002 12:17:53 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1SHHQS17476; Thu, 28 Feb 2002 11:17:26 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1SHHQf04148; Thu, 28 Feb 2002 11:17:26 -0600 (CST) Received: from lmf.ericsson.se (rmt160160.am.ericsson.se [138.85.160.160]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA08387; Thu, 28 Feb 2002 11:17:24 -0600 (CST) Message-ID: <3C7E6653.11400300@lmf.ericsson.se> Date: Thu, 28 Feb 2002 19:18:11 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: sip , jdrosen@dynamicsoft.com References: <200202262107.QAA54295@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Section 5.2 of manyfolks Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Bill has requested me to send a mail to the mailing list in order to bring your attention to section 5.2 of manyfolks (desired strength paragraph). We have changed the way the strength tag is negotiated by the UAs. In manyfolks 03 the answerer could downgrade it, but now it can only upgrade it. I introduced this change because it allows an answerer to request qos preconditions for an offer that did not have them but supported them. This reduces the number of RTTs needed. Bill is happy with this decision, but he thought an explanatory note to the mailing list would be needed. Regards, 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 daemon@optimus.ietf.org Thu Feb 28 12:47:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08033 for ; Thu, 28 Feb 2002 12:47:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17934 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 12:47:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16323; Thu, 28 Feb 2002 12:23:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16275 for ; Thu, 28 Feb 2002 12:23:19 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06166 for ; Thu, 28 Feb 2002 12:23:14 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A785E1DB01D2; Thu, 28 Feb 2002 12:23:17 -0500 Message-ID: <00ac01c1c07c$71541ca0$2300000a@acmepacket.com> From: "Bob Penfield" To: , References: <2038BCC78B1AD641891A0D1AE133DBB7779098@esebe019.NOE.Nokia.com> Subject: Re: [Sip] NOTIFY behaviour Date: Thu, 28 Feb 2002 12:22:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: > Section 4.2.1 states > > "When present, the body of the NOTIFY request MUST be formatted > into one of the body formats specified in the "Accept" header of > the corresponding SUBSCRIBE request. This body will contain either > the state of the subscribed resource or a pointer to such state in > the form of a URI." > > Is the Accept header mandatory in SUBSCRIBE? INVITE mandates its > but say that UAS should be ready to receive Requests without an > Accept header. In that case, the spec should state that any > extension to the events draft should specify the default content- > type just in case the accept header was missing. The spec already has this requirement for Event Packages in section 5.4.5: Event packages also MUST define which MIME type is to be assumed if none are specified in the "Accept" header of the SUBSCRIBE request. > > Section 4.2.2 > I believe this section should talk a little about how a NOTIFY is > constructed when a SUBSCRIBE with expires 0 is received. > specifically the way the subscription-state header is constructed. > After all, its the NOTIFY that terminates the dialog, Not the 200 > OK to a SUBSCRIBE with expires 0. Section 4.3.6 has this. Note that the NOTIFY messages triggered by SUBSCRIBE messages with "Expires" headers of 0 will contain a "Subscription-State" value of "terminated", and a "reason" parameter of "timeout". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 28 13:15:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09962 for ; Thu, 28 Feb 2002 13:15:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19505 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 13:15:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18094; Thu, 28 Feb 2002 12:50:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18063 for ; Thu, 28 Feb 2002 12:50:03 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08279 for ; Thu, 28 Feb 2002 12:50:00 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.62]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1SHoP6Y020342; Thu, 28 Feb 2002 12:50:25 -0500 (EST) Message-ID: <3C7E6DA9.35F227C9@dynamicsoft.com> Date: Thu, 28 Feb 2002 12:49:29 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ofir Arkin CC: Robert Sparks , SIP Subject: Re: [Sip] Question about Section 12.2 Requests within a Dialog References: <3C7E65AB.2080006@stake.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ofir Arkin wrote: > > What 'state' information does this change? > For example if I send a Re-INVITE within a dialog what 'state' > information will the Re-INVITE change? The re-INVITE changes the remote URI. Here is an example. I send an INVITE with a Cotnact header of sip:@. The call is established. A BYE, re-INVITE, or other mid-dialog request will arrive to me with this URI in the request URI. I can use that for whatever purposes I like. If I wish to change it, I can issue a re-INVITE, which updates it at the other side. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.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 daemon@optimus.ietf.org Thu Feb 28 13:19:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10154 for ; Thu, 28 Feb 2002 13:19:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19614 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 13:19:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18151; Thu, 28 Feb 2002 12:51:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18120 for ; Thu, 28 Feb 2002 12:51:04 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08344 for ; Thu, 28 Feb 2002 12:51:01 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1SHoxh13533; Thu, 28 Feb 2002 11:50:59 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1SHoxf26476; Thu, 28 Feb 2002 11:50:59 -0600 (CST) Received: from lmf.ericsson.se (rmt160160.am.ericsson.se [138.85.160.160]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA12203; Thu, 28 Feb 2002 11:50:56 -0600 (CST) Message-ID: <3C7E6E30.B7766146@lmf.ericsson.se> Date: Thu, 28 Feb 2002 19:51:44 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ofir Arkin CC: Robert Sparks , SIP Subject: Re: [Sip] Question about Section 12.2 Requests within a Dialog References: <3C7D29F1.4080401@stake.com> <1014837295.1201.20.camel@rjs.dynamicsoft.com> <3C7E65AB.2080006@stake.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It will change the last hop (the target) for the route of the dialog. Gonzalo Ofir Arkin wrote: > > What 'state' information does this change? > For example if I send a Re-INVITE within a dialog what 'state' > information will the Re-INVITE change? > > >>Second Question: > >>Why this might change the target URI? > >>I must admit that the target refresh thing got me really confused... > >> > > > > This mechanism allows an endpoint to change the URI it wants to be > > handed in future requests within this dialog. This can be used as a > > place to store state for future requests. The original proponents > > planned to use this as part of the mechanics to deal with mobility > > (address mobility in particular). I don't believe those ideas have > > been fleshed out. > > > > -- > Ofir Arkin > Managing Security Architect > @stake, Limited. > http://www.atstake.com > email: > ofir@stake.com > Tel: > +44 (0) 207 495 7002 > Fax: > +44 (0) 207 495 7062 > Mobile: +44 (0) 779 630 8632 > > ----------------------------- > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, re transmission, 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 any computer. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Thu Feb 28 13:57:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12802 for ; Thu, 28 Feb 2002 13:57:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21853 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 13:57:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20725; Thu, 28 Feb 2002 13:36:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20694 for ; Thu, 28 Feb 2002 13:36:07 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11285 for ; Thu, 28 Feb 2002 13:36:03 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1SIZZE03366; Thu, 28 Feb 2002 10:35:35 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACN69483; Thu, 28 Feb 2002 10:35:32 -0800 (PST) Date: Thu, 28 Feb 2002 10:33:53 -0800 (Pacific Standard Time) From: Rohan Mahy To: mwatson@nortelnetworks.com cc: fandreas@cisco.com, Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Mark, We've already discussed to some extent the applicability statement proposed for privacy-04. This draft obviously doesn't address pure user-to-user privacy (it never intended to, and there is nothing wrong with that). However, I'm sure the IESG will have a problem approving a document that defines the "general purpose platform" for privacy that you propose, but that only addresses the requirements in a specific environment. How do you intend to make a general purpose platform acceptable for publication by the IESG? Are you proposing that we delay last call to incorporate a full privacy scheme? Please see a few additional comments inline with ##. Please feel free to call me if you want to talk about this. +1 408 307 1866 thanks, -rohan To: "'Flemming Andreasen'" , "'sip@ietf.org'" Subject: [Sip] RE: Remote-Party-Id extensibility From: "Mark Watson" Date: Thu, 28 Feb 2002 13:11:20 -0000 List-Id: Session Initiation Protocol Sender: sip-admin@ietf.org -------------------------------------------------------------------------------- Title: RE: Remote-Party-Id extensibility Flemming, all, My opinion is that 95% of the value of the Remote-Party-ID header is in this extensibility. The extensibility provides a general purpose platform ## ^^^^^^^^^^^^^^^^^^^^^^^^ for handling of identity information which is subject to privacy restrictions (in the applicable environment), because we can add new types of identity and be sure that the privacy handling will be applied to these even if the actual identity type is not recognised by downstream systems. If you remove this extensibility, you might as well define separate headers for each identity ('Private-Calling-Party:' etc.), with separate Require: tags, and then any SLAs between Service Providers with respect to privacy would have to list the headers that were guaranteed to be respected. Such SLAs would need extension every time new identities were added. ## why is this a problem (additional headers) if it meets the ## requirements? As it stands, we need only include support of the 'privacy' tag in the SLAs. I can promise you that the lack of such extensibility in the PSTN has be a nightmare. It was predicated on the assumption that we know a priori that a given set of identity parameters are sufficient for present and future purposes - an assumption which has proved wrong time and time again. I would also hope that the envisioned future privacy support for the pure Internet environment could be as backwards-compatible with Remote-Party-ID as possible cf Dean's ideas about signing the RPID etc. If we rule out extensibility now, we tie our hands somewhat with regards to this future solution. ## syntax is always the least important aspect of a protocol. i don't see ## any compelling reason why future privacy work would have to use the ## same header name. In fact this may hamper our ability to add new ## features. Of course, a new RFC could always update or obsolete the ## current draft if we decided that the syntax of the more general privacy ## document should use the Remote-Party-ID header I would prefer to have the extensibiity left as in privacy-02. Regards, Mark _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 28 14:02:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13074 for ; Thu, 28 Feb 2002 14:02:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22526 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 14:02:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20119; Thu, 28 Feb 2002 13:30:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20073 for ; Thu, 28 Feb 2002 13:30:13 -0500 (EST) Received: from zctfs063.nortelnetworks.com (h90s131a237n47.user.nortelnetworks.com [47.237.131.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10984 for ; Thu, 28 Feb 2002 13:30:09 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1SITcY23258; Thu, 28 Feb 2002 19:29:38 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 18:29:38 -0000 Message-ID: From: "Mark Watson" To: "George Foti (LMC)" , sip@ietf.org Subject: RE: [Sip] UPDATE Method & Glare Date: Thu, 28 Feb 2002 18:29:27 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C085.DAD5E9C0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C085.DAD5E9C0 Content-Type: text/plain; charset="iso-8859-1" I agree - this needs to be described. If I remember some earlier discussions correctly, then if you receive an UPDATE whilst waiting for a response to an UPDATE that you send yourself, the you should immediately reject the UPDATE, but with what failure response I do not know. Do we require a specific failure response for glare ? I guess you need to know that it is worth retrying after some random interval. Also, if you are waiting for a repsonse to an UPDATE you have sent, and you receive an UPDATE which is a retransmit of one you have previously responded to (presumably because your original response was lost), I believe you should just repeat your original response and continue waiting for the response to your UPDATE. Your UPDATE will probably be rejected, because the other guy thinks there is glare, but it is possible for both UPDATES to suceed if messages swap order in transit, but this is not a problem. Is this taken care of by the transaction layer in SIP or does it need to be explicitly described ? Regards, Mark > -----Original Message----- > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > Sent: 27 February 2002 23:09 > To: sip@ietf.org > Subject: [Sip] UPDATE Method & Glare > > > Hi, > > Within the current draft on UPDATE method, glare can occur within a > dialogue. > I mean it is perfectly okay for 2 UAs to send simultaneous > UPDATES causing > glare. > > I dont see anywhere where this case is covered in the current draft. > Can that be added to the draft to specify the procedures to > be followed > should that situation arise. > > Thanks > > George Foti > Ericsson Canada > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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_01C1C085.DAD5E9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] UPDATE Method & Glare

I agree - this needs to be described.

If I remember some earlier discussions correctly, = then if you receive an UPDATE whilst waiting for a response to an = UPDATE that you send yourself, the you should immediately reject the = UPDATE, but with what failure response I do not know.

Do we require a specific failure response for glare ? = I guess you need to know that it is worth retrying after some random = interval.

Also, if you are waiting for a repsonse to an UPDATE = you have sent, and you receive an UPDATE which is a retransmit of one = you have previously responded to (presumably because your original = response was lost), I believe you should just repeat your original = response and continue waiting for the response to your = UPDATE.

Your UPDATE will probably be rejected, because the = other guy thinks there is glare, but it is possible for both UPDATES to = suceed if messages swap order in transit, but this is not a = problem.

Is this taken care of by the transaction layer in SIP = or does it need to be explicitly described ?

Regards,

Mark

> -----Original Message-----
> From: George Foti (LMC) [mailto:George.Foti@ericsson.ca]
> Sent: 27 February 2002 23:09
> To: sip@ietf.org
> Subject: [Sip] UPDATE Method & Glare
>
>
> Hi,
>
> Within the current draft on UPDATE method, = glare can occur within a
> dialogue.
> I mean it is perfectly okay for 2 UAs to send = simultaneous
> UPDATES causing
> glare.
>
> I dont see anywhere where this case is covered = in the current draft.
> Can that be added to the draft to specify the = procedures to
> be followed
> should that situation arise.
>
> Thanks
>
> George Foti
> Ericsson Canada
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP 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_01C1C085.DAD5E9C0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 28 14:17:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14052 for ; Thu, 28 Feb 2002 14:17:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23332 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 14:17:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21802; Thu, 28 Feb 2002 13:56:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21771 for ; Thu, 28 Feb 2002 13:56:33 -0500 (EST) Received: from zctfs063.nortelnetworks.com (h90s131a237n47.user.nortelnetworks.com [47.237.131.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12632 for ; Thu, 28 Feb 2002 13:56:29 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1SIthY24300; Thu, 28 Feb 2002 19:55:43 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 18:55:43 -0000 Message-ID: From: "Mark Watson" To: "'Rohan Mahy'" Cc: fandreas@cisco.com, sip@ietf.org Date: Thu, 28 Feb 2002 18:55:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C089.85819880" Subject: [Sip] RE: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C089.85819880 Content-Type: text/plain Rohan, I guess I worded my statement a little strongly, I meant that *within the applicable environment* it would provide a general-purpose capability. I am hopeful that future work will extend the 'applicable environment', but I wasn't suggesting that this draft be delayed for that work to be completed. If that work were never completed, then RPID would remain applicable only within the environment stated. Or if future work decides that different header(s) be used in other environments. But re-use is good, so we should not rule it out until we find out whether it is appropriate. To answer your question about why extensibility of RPID is better than new headers: imagine I am an Internet Telephony Service Provider and I have parnerships with a number of other Service Providers who will route SIP calls to the PSTN for me. Part of my agreements with these Service Providers is that they will support the privacy draft. So I can send them information which my subscribers want kept private (see previous discussions for why I might want to do this). If someone comes up with a great idea for a new identity type, we can either define a new rpi-id-type or a new header: a) New rpi-id-type: I can just send this new identity to all my partner Service Providers - I know that even if they do not support the new rpi-id-type value, they will respect the rpi-privacy values. b) New header: I cannot send this to my partners until I have agreed with each of them that they will respect the privacy information within the header. I will need a capability to selectively remove this header based on who I am sending it to & I need to maintain data about who supports it and who does not etc. - this becomes a massive pain and introduces even more scope for error. The point is that the privacy problem, in this environment, whatever you think of it, is independent of the identity type. So there should be a single solution into which we can plug future identity types, rather then re-inventing it again and again. ...Mark > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: 28 February 2002 18:34 > To: Watson, Mark [MDN05:EP10:EXCH] > Cc: fandreas@cisco.com; sip@ietf.org > Subject: > > > Mark, > > We've already discussed to some extent the applicability statement > proposed for privacy-04. This draft obviously doesn't address pure > user-to-user privacy (it never intended to, and there is nothing wrong > with that). However, I'm sure the IESG will have a problem > approving a > document that defines the "general purpose platform" for privacy > that you propose, but that only addresses the requirements in a > specific environment. How do you intend to make a general purpose > platform acceptable for publication by the IESG? > > Are you proposing that we delay last call to incorporate a > full privacy > scheme? > > Please see a few additional comments inline with ##. > > Please feel free to call me if you want to talk about this. > +1 408 307 1866 > > thanks, > -rohan > > > To: "'Flemming Andreasen'" , "'sip@ietf.org'" > > Subject: [Sip] RE: Remote-Party-Id extensibility > From: "Mark Watson" > Date: Thu, 28 Feb 2002 13:11:20 -0000 > List-Id: Session Initiation Protocol > Sender: sip-admin@ietf.org > > -------------------------------------------------------------- > ------------------ > > Title: RE: Remote-Party-Id extensibility > Flemming, all, > > My opinion is that 95% of the value of the Remote-Party-ID > header is in > this extensibility. > > The extensibility provides a general purpose platform > ## ^^^^^^^^^^^^^^^^^^^^^^^^ > > for handling of > identity information which is subject to privacy restrictions (in the > applicable environment), because we can add new types of > identity and be > sure that the privacy handling will be applied to these even > if the actual > identity type is not recognised by downstream systems. > > If you remove this extensibility, you might as well define separate > headers for each identity ('Private-Calling-Party:' etc.), > with separate > Require: tags, and then any SLAs between Service Providers > with respect to > privacy would have to list the headers that were guaranteed to be > respected. Such SLAs would need extension every time new > identities were > added. > > ## why is this a problem (additional headers) if it meets the > ## requirements? > > As it stands, we need only include support of the 'privacy' tag in the > SLAs. > > I can promise you that the lack of such extensibility in the > PSTN has be a > nightmare. It was predicated on the assumption that we know a > priori that > a given set of identity parameters are sufficient for present > and future > purposes - an assumption which has proved wrong time and time again. > > I would also hope that the envisioned future privacy support > for the pure > Internet environment could be as backwards-compatible with > Remote-Party-ID > as possible cf Dean's ideas about signing the RPID etc. If we rule out > extensibility now, we tie our hands somewhat with regards to > this future > solution. > > ## syntax is always the least important aspect of a protocol. > i don't see > ## any compelling reason why future privacy work would have to use the > ## same header name. In fact this may hamper our ability to add new > ## features. Of course, a new RFC could always update or obsolete the > ## current draft if we decided that the syntax of the more > general privacy > ## document should use the Remote-Party-ID header > > I would prefer to have the extensibiity left as in privacy-02. > > Regards, > > Mark > > > > ------_=_NextPart_001_01C1C089.85819880 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE:

Rohan,

I guess I worded my statement a little strongly, I = meant that *within the applicable environment* it would provide a = general-purpose capability.

I am hopeful that future work will extend the = 'applicable environment', but I wasn't suggesting that this draft be = delayed for that work to be completed.

If that work were never completed, then RPID would = remain applicable only within the environment stated. Or if future work = decides that different header(s) be used in other = environments.

But re-use is good, so we should not rule it out = until we find out whether it is appropriate.

To answer your question about why extensibility of = RPID is better than new headers: imagine I am an Internet Telephony = Service Provider and I have parnerships with a number of other Service = Providers who will route SIP calls to the PSTN for me.

Part of my agreements with these Service Providers is = that they will support the privacy draft. So I can send them = information which my subscribers want kept private (see previous = discussions for why I might want to do this).

If someone comes up with a great idea for a new = identity type, we can either define a new rpi-id-type or a new = header:
a) New rpi-id-type: I can just send this new = identity to all my partner Service Providers - I know that even if they = do not support the new rpi-id-type value, they will respect the = rpi-privacy values.

b) New header: I cannot send this to my partners = until I have agreed with each of them that they will respect the = privacy information within the header. I will need a capability to = selectively remove this header based on who I am sending it to & I = need to maintain data about who supports it and who does not etc. - = this becomes a massive pain and introduces even more scope for = error.

The point is that the privacy problem, in this = environment, whatever you think of it, is independent of the identity = type. So there should be a single solution into which we can plug = future identity types, rather then re-inventing it again and = again.

...Mark


> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: 28 February 2002 18:34
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: fandreas@cisco.com; sip@ietf.org
> Subject:
>
>
> Mark,
>
> We've already discussed to some extent the = applicability statement
> proposed for privacy-04.  This draft = obviously doesn't address pure
> user-to-user privacy (it never intended to, and = there is nothing wrong
> with that).  However, I'm sure the IESG = will have a problem
> approving a
> document that defines the "general purpose = platform" for privacy
> that you propose, but that only addresses the = requirements in a
> specific environment.  How do you intend = to make a general purpose
> platform acceptable for publication by the = IESG?
>
> Are you proposing that we delay last call to = incorporate a
> full privacy
> scheme?
>
> Please see a few additional comments inline = with ##.
>
> Please feel free to call me if you want to talk = about this.
> +1 408 307 1866
>
> thanks,
> -rohan
>
>
> To: "'Flemming Andreasen'" = <fandreas@cisco.com>, "'sip@ietf.org'"
> <sip@ietf.org>
> Subject: [Sip] RE: Remote-Party-Id = extensibility
> From: "Mark = Watson"<mwatson@nortelnetworks.com>
> Date: Thu, 28 Feb 2002 13:11:20 -0000
> List-Id: Session Initiation Protocol = <sip.ietf.org>
> Sender: sip-admin@ietf.org
>
> = --------------------------------------------------------------
> ------------------
>
> Title: RE: Remote-Party-Id extensibility
> Flemming, all,
>
> My opinion is that 95% of the value of the = Remote-Party-ID
> header is in
> this extensibility.
>
> The extensibility provides a general purpose = platform
> = ##           &nbs= p;           &nbs= p;   ^^^^^^^^^^^^^^^^^^^^^^^^
>
> for handling of
> identity information which is subject to = privacy restrictions (in the
> applicable environment), because we can add new = types of
> identity and be
> sure that the privacy handling will be applied = to these even
> if the actual
> identity type is not recognised by downstream = systems.
>
> If you remove this extensibility, you might as = well define separate
> headers for each identity = ('Private-Calling-Party:' etc.),
> with separate
> Require: tags, and then any SLAs between = Service Providers
> with respect to
> privacy would have to list the headers that = were guaranteed to be
> respected. Such SLAs would need extension every = time new
> identities were
> added.
>
> ## why is this a problem (additional headers) = if it meets the
> ## requirements?
>
> As it stands, we need only include support of = the 'privacy' tag in the
> SLAs.
>
> I can promise you that the lack of such = extensibility in the
> PSTN has be a
> nightmare. It was predicated on the assumption = that we know a
> priori that
> a given set of identity parameters are = sufficient for present
> and future
> purposes - an assumption which has proved wrong = time and time again.
>
> I would also hope that the envisioned future = privacy support
> for the pure
> Internet environment could be as = backwards-compatible with
> Remote-Party-ID
> as possible cf Dean's ideas about signing the = RPID etc. If we rule out
> extensibility now, we tie our hands somewhat = with regards to
> this future
> solution.
>
> ## syntax is always the least important aspect = of a protocol.
>  i don't see
> ## any compelling reason why future privacy = work would have to use the
> ## same header name.  In fact this may = hamper our ability to add new
> ## features.  Of course, a new RFC could = always update or obsolete the
> ## current draft if we decided that the syntax = of the more
> general privacy
> ## document should use the Remote-Party-ID = header
>
> I would prefer to have the extensibiity left as = in privacy-02.
>
> Regards,
>
> Mark
>
>
>
>

------_=_NextPart_001_01C1C089.85819880-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 28 16:10:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19810 for ; Thu, 28 Feb 2002 16:10:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA00675 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 16:10:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28992; Thu, 28 Feb 2002 15:43:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28959 for ; Thu, 28 Feb 2002 15:43:01 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18745 for ; Thu, 28 Feb 2002 15:42:56 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1SKgSt00990; Thu, 28 Feb 2002 12:42:28 -0800 (PST) Received: from fluffyw2k (dhcp-128-107-142-47.cisco.com [128.107.142.47]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACD43200; Thu, 28 Feb 2002 12:42:37 -0800 (PST) From: "Cullen Jennings" To: "Gonzalo Camarillo" , "Gordon Ledgard" , "sip" Subject: RE: [Sip] UPDATE versus (re)INVITE Date: Thu, 28 Feb 2002 12:42:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C7B5918.531352CC@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Perhaps this would better be done by sending a REFER that tells the other end to send and UPDATE or and INVITE. Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Gonzalo > Camarillo > Sent: Tuesday, February 26, 2002 1:45 AM > To: Gordon Ledgard > Cc: sip > Subject: Re: [Sip] UPDATE versus (re)INVITE > > > Hi, > > re-INVITEs are still needed. In 3pcc scenarios it is often needed to > send an empty re-INVITE in order to get an offer in the response. > > Regards, > > Gonzalo > > Gordon Ledgard wrote: > > > > I've been looking over > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-update-00.txt > > > > Is the intent of the UPDATE method to completely obviate the > > necessity for reinvites? Or would there always be distinct reasons > > to use one versus another? > > > > Gordon Ledgard > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Thu Feb 28 16:11:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19894 for ; Thu, 28 Feb 2002 16:11:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA00822 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 16:11:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29177; Thu, 28 Feb 2002 15:47:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29146 for ; Thu, 28 Feb 2002 15:47:44 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18930 for ; Thu, 28 Feb 2002 15:47:38 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1SKlch00054; Thu, 28 Feb 2002 14:47:38 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1SKlbO16115; Thu, 28 Feb 2002 14:47:37 -0600 (CST) Received: from lmf.ericsson.se (rmt160160.am.ericsson.se [138.85.160.160]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA28303; Thu, 28 Feb 2002 14:47:35 -0600 (CST) Message-ID: <3C7E9793.75CB5EC4@lmf.ericsson.se> Date: Thu, 28 Feb 2002 22:48:19 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cullen Jennings CC: Gordon Ledgard , sip Subject: Re: [Sip] UPDATE versus (re)INVITE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The idea behind 3pcc is not to use extensions like REFER. Gonzalo Cullen Jennings wrote: > > Perhaps this would better be done by sending a REFER that tells the other > end to send and UPDATE or and INVITE. > > Cullen > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Gonzalo > > Camarillo > > Sent: Tuesday, February 26, 2002 1:45 AM > > To: Gordon Ledgard > > Cc: sip > > Subject: Re: [Sip] UPDATE versus (re)INVITE > > > > > > Hi, > > > > re-INVITEs are still needed. In 3pcc scenarios it is often needed to > > send an empty re-INVITE in order to get an offer in the response. > > > > Regards, > > > > Gonzalo > > > > Gordon Ledgard wrote: > > > > > > I've been looking over > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-update-00.txt > > > > > > Is the intent of the UPDATE method to completely obviate the > > > necessity for reinvites? Or would there always be distinct reasons > > > to use one versus another? > > > > > > Gordon Ledgard > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.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 > > -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Thu Feb 28 17:27:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23308 for ; Thu, 28 Feb 2002 17:27:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05518 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 17:27:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03853; Thu, 28 Feb 2002 17:00:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03678 for ; Thu, 28 Feb 2002 17:00:07 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21964 for ; Thu, 28 Feb 2002 17:00:02 -0500 (EST) Received: (qmail 25302 invoked from network); 28 Feb 2002 22:02:40 -0000 Received: from softdnserror (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 28 Feb 2002 22:02:40 -0000 Received: from stake.com (unknown [10.1.64.73]) by cam-relay.atstake.com (Postfix) with SMTP id BB30722818; Thu, 28 Feb 2002 16:57:44 -0500 (EST) Message-ID: <3C7EA816.8040702@stake.com> Date: Thu, 28 Feb 2002 21:58:46 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Gonzalo Camarillo Cc: Robert Sparks , SIP Subject: Re: [Sip] Question about Section 12.2 Requests within a Dialog References: <3C7D29F1.4080401@stake.com> <1014837295.1201.20.camel@rjs.dynamicsoft.com> <3C7E65AB.2080006@stake.com> <3C7E6E30.B7766146@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit So, there is no way to change other state information other than the last hop (target URI)? Ofir Gonzalo Camarillo wrote: > It will change the last hop (the target) for the route of the dialog. > > Gonzalo > > Ofir Arkin wrote: > >>What 'state' information does this change? >>For example if I send a Re-INVITE within a dialog what 'state' >>information will the Re-INVITE change? >> >> >>>>Second Question: >>>>Why this might change the target URI? >>>>I must admit that the target refresh thing got me really confused... >>>> >>>> >>>This mechanism allows an endpoint to change the URI it wants to be >>>handed in future requests within this dialog. This can be used as a >>>place to store state for future requests. The original proponents >>>planned to use this as part of the mechanics to deal with mobility >>>(address mobility in particular). I don't believe those ideas have >>>been fleshed out. >>> >> >> >>-- >>Ofir Arkin >>Managing Security Architect >>@stake, Limited. >>http://www.atstake.com >>email: >>ofir@stake.com >>Tel: >>+44 (0) 207 495 7002 >>Fax: >>+44 (0) 207 495 7062 >>Mobile: +44 (0) 779 630 8632 >> >>----------------------------- >>The information transmitted is intended only for the person or entity to >>which it is addressed and may contain confidential and/or privileged >>material. Any review, re transmission, 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 any computer. >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, 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 any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Feb 28 17:28:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23363 for ; Thu, 28 Feb 2002 17:28:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05547 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 17:28:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04831; Thu, 28 Feb 2002 17:10:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04800 for ; Thu, 28 Feb 2002 17:10:15 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22511 for ; Thu, 28 Feb 2002 17:10:07 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1SMA3h10966; Thu, 28 Feb 2002 16:10:04 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1SMA3O05026; Thu, 28 Feb 2002 16:10:03 -0600 (CST) Received: from lmf.ericsson.se (rmt160160.am.ericsson.se [138.85.160.160]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA06031; Thu, 28 Feb 2002 16:10:01 -0600 (CST) Message-ID: <3C7EAAE5.D7D72526@lmf.ericsson.se> Date: Fri, 01 Mar 2002 00:10:45 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ofir Arkin CC: Robert Sparks , SIP Subject: Re: [Sip] Question about Section 12.2 Requests within a Dialog References: <3C7D29F1.4080401@stake.com> <1014837295.1201.20.camel@rjs.dynamicsoft.com> <3C7E65AB.2080006@stake.com> <3C7E6E30.B7766146@lmf.ericsson.se> <3C7EA816.8040702@stake.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, That's right. The only thing that you can change in the target... well, if you consider the local and remote cseqs as pieces of state as well, they change in every request. Gonzalo Ofir Arkin wrote: > > So, there is no way to change other state information other than the > last hop (target URI)? > > Ofir > > Gonzalo Camarillo wrote: > > > It will change the last hop (the target) for the route of the dialog. > > > > Gonzalo > > > > Ofir Arkin wrote: > > > >>What 'state' information does this change? > >>For example if I send a Re-INVITE within a dialog what 'state' > >>information will the Re-INVITE change? > >> > >> > >>>>Second Question: > >>>>Why this might change the target URI? > >>>>I must admit that the target refresh thing got me really confused... > >>>> > >>>> > >>>This mechanism allows an endpoint to change the URI it wants to be > >>>handed in future requests within this dialog. This can be used as a > >>>place to store state for future requests. The original proponents > >>>planned to use this as part of the mechanics to deal with mobility > >>>(address mobility in particular). I don't believe those ideas have > >>>been fleshed out. > >>> > >> > >> > >>-- > >>Ofir Arkin > >>Managing Security Architect > >>@stake, Limited. > >>http://www.atstake.com > >>email: > >>ofir@stake.com > >>Tel: > >>+44 (0) 207 495 7002 > >>Fax: > >>+44 (0) 207 495 7062 > >>Mobile: +44 (0) 779 630 8632 > >> > >>----------------------------- > >>The information transmitted is intended only for the person or entity to > >>which it is addressed and may contain confidential and/or privileged > >>material. Any review, re transmission, 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 any computer. > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > >> > > > > -- > Ofir Arkin > Managing Security Architect > @stake, Limited. > http://www.atstake.com > email: > ofir@stake.com > Tel: > +44 (0) 207 495 7002 > Fax: > +44 (0) 207 495 7062 > Mobile: +44 (0) 779 630 8632 > > ----------------------------- > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, re transmission, 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 any computer. -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.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 daemon@optimus.ietf.org Thu Feb 28 22:01:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01131 for ; Thu, 28 Feb 2002 22:01:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA19108 for sip-archive@odin.ietf.org; Thu, 28 Feb 2002 22:01:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18015; Thu, 28 Feb 2002 21:32:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17990 for ; Thu, 28 Feb 2002 21:32:13 -0500 (EST) Received: from orgio.net ([61.81.60.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29574 for ; Thu, 28 Feb 2002 21:32:06 -0500 (EST) Message-Id: <200203010232.VAA29574@ietf.org> Reply-To: yupgishop@orgio.net From: 엽기샵 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 1 Mar 2002 11:32:38 +0900 X-User: 2.63-jmknhpnu-hprnpu-Hhmkl Subject: [Sip] [광고]엽기전문 쇼핑몰 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org
안녕하세요?정말 원치 않는 메일을 보내드려서 죄송합니다.
저 또한 기가막힌 쇼핑몰이 오픈했는데 알릴 방법이 없어서
이렇게 염치 불구 하고 메일을 보냅니다.
아래 상품은 대표적인 상품이고
사이트로 가시면 500여가지의 상품이 있습니다.
어려운 상황에서 오픈하거라 많이 방문하여 주시고
격려해 주시면 감사하겠습니다.
메일을 받으신 모든분
항상 행복하시고 건강하시고
언제나 건승하시기를 진심으로 기원합니다.


사이트로 이동하시려면 그림 또는 글을 클릭하세요 독특한 상품 기발한 상품 엽기적 상품 엽기전문 쇼핑몰

수신거부

 본 메일은 정보통신부 권고사항 법률 제 50조에 의거하여 [광고] 메일임을 밝힙니다.
귀하의 메일 주소는 검색엔진과 일반 사이트의 공개적인 곳에서 추출한 것이며,
메일주소 이외에는 다른 정보는 일체 모르니 안심하시기 바랍니다.
사전 허락없이 메일을 보내게 된 점 사과드립니다. 감사합니다.




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